Mahmud is one of the few HNers that actually has practicle experience deploying Lisp in the real world. You might be interested in what he has to say on the issue of practicality:
"Today, Lisp is nothing like what it was 8,7,6, even 2 years ago. It's not just "good" in the well-explored text book fashion; no, it's _good shit_. Get work done good. Think, hack, ship, bill for it good. 2-3 products per month good. You still have to know where things are, who is working on what, what's maintained and what's obsoleted by what. Sure. But there is absolutely no lack of libraries." (http://news.ycombinator.com/item?id=972423).
I'm curious if the author of the article has similar experience deploying CL or if this article is just theorycrafting. I notice some experience with Clojure, but this article was written in 2008.
Before people go around upvoting this article mindlessly. This article is from 2008, before Brian rewrote this blog twice in Clojure and got the hell off WordPress. I'd be interested to hear what he has to say now about this article (though it may be that his opinion has remained largely the same).
This remains a big problem with the web: Timelessness. It turns out that the ephemeral nature of offline commentary is a big feature. If I say something offhand in a bar I don't have to curate that statement forever, going back every few months to add some editorial comment about how my opinion has changed.
It struck me the other day that this is why archivists have trouble with the web. Old links go dead all the time. Various people have tried to convince web publishers that they should take the preservation of old links seriously - we are destroying history! But it isn't just that preserving old links is hard work - which it is - but that history is a terrible burden for the living. You are forced to curate and disclaim it, or risk having it held against you. It's much more comfortable to just walk away from your history and hope that it biodegrades.
Forgetfulness is a blessing, and few online systems provide it in any well-thought-out fashion. Users are forced to use hacks to achieve it.
My opinion today is largely the same, yes. I love Clojure and in my spare time I use it for everything. If I tried to do a web app in Common Lisp again, I'd probably have an easier time of it today than in 2008, because I know a bit more.
But I couldn't justify using either for a project for work. I generally choose Ruby instead nowadays. In Clojure I still end up rolling my own libraries for a lot of things, which is really quite fun in my spare time, but not justifiable if I'm billing by the hour and there are a dozen Ruby gems already written to do it.
We have seemingly constant threads on HN saying "I can't hire a good programmer!" What are the chances of my non-programmer boss hiring a good Lisp programmer? At the small non-profit at which I work? Good freaking luck.
I'm still using some PHP scripts at work today, and I still cringe to see the code, and I whine a little (to myself) whenever I have to edit it, and my boss still loves the end result, and it's done its job well for 2 years. What else matters? I believe in "Worse is Better" in this case.
I do sneakily use Clojure at work for small data-munging tasks. But not for code anyone else ever needs to see.
(I do also wonder why this blog post from 2008 made it to HN.)
"PHP is overly verbose and terribly inconsistent and lacks powerful methods of abstraction and proper closures and easy-to-use meta-programming goodness"
Sometimes I wonder how much closures and meta-programming is just code for coding sake. I've seen lots of examples of 5 line LISP code that does something totally amazing but you don't really know what it means but it's so abstract. If you have a quick job to do, I don't see that it's a limitation in using a language that requires to build the most straight forward solution.
PHP is ugly, but for the most part it isn't horrible -- these days you can easily avoid some of the worst parts and concentrate on making code that would be very equivalent to the same code in, say, Java. PHP is very straight forward -- it means what it says.
"Your web framework in PHP probably isn't continuation-based, it probably doesn't compile your s-expression HTML tree into assembler code before rendering it."
This just sounds like over-engineering the problem.
Sometimes I wonder how much closures and meta-programming is just code
for coding sake. I've seen lots of examples of 5 line LISP code that does
something totally amazing but you don't really know what it means but it's
so abstract
You could the same for so many PHP frameworks. Why are there so many classes? Why do I have to inherit from a class I don't understand? Why am I forced to define classes at all? Why are my custom classes 50% getters/setters? Why are my objects mutable? etc. etc. etc.
(map :last-name people)
The point is if the language provides the proper level of abstraction, you end writing less of your own hand rolled abstractions.
Again the only thing I'm hearing here is arguments from people who are too lazy to actually see how things are done from a functional perspective. Get off your ass and find out. Then tell me you have a problem with it.
I can't forget to fetch the next row from the database. I can't forget to check that I'm at the end of the result set. Grouping the results is easy and straightforward. The statement and connection objects are automatically closed when the request is done. Compare that to PHP.
I'm getting better, but even today I feel a little irritated when someone says PHP was designed for simple web/database apps. I know what a language designed for simple web/db apps looks like, and PHP is not it.
I find e.g. closures in Lisp overly verbose. The ML family of languages has a much lighter weight syntax for functions. This makes amazing stuff look less like code for code's sake.
(Though I do admit that I immensely like Lisp's macros.)
In e.g. Haskell abstractions are the straightforward way to solve a problem. Abstractions are cheap.
The problem is most people building meaningful programs are not people with "just a quick job to do". For those people, having abstractions available allows them to focus on the harder problems that actually matter, instead of constantly reinventing the wheel.
The mental energy is probably not worth it if you are just building a blog for yourself, but in that case, the mental energy of learning PHP is not worth it either. If the job is really that quick, why are you using dynamically generated content in the first place? HTML one-off's are the most straight forward solution.
On the other hand, if you want to build a bulletproof web application, you should probably use powerful tools, figure them out once, and then actually solve your problem.
"This just sounds like over-engineering the problem."
Except the problem was never defined. Of the five commercial Lisp applications I've worked on, two are addressing domains (large-scale financial calculations, and a web platform/OS) where using PHP makes absolutely no sense, and the current one (ERP) where PHP was previously attempted and found not to make any sense. All three use basic techniques like closures, markup generation and metaprogramming, and one of them is continuation-based (which I think is a mistake, but opinions differ).
This illustrates a far greater point that every once in a while returns to the surface of HN as well:
A tool is seldom more than a tool. In regard to languages, for most projects there are more than enough constraints to begin with, so you can pick a language of your choice in no time. Sure there are languages that suck and languages that are awesome. But most of these comparisons only work in a vacuum. And in practice, no project ever starts in a vacuum.
One of the first posts I wrote on my blog last year was about tools - the first lines were:
Use tools appropriate to your skills and to the job you are trying to get done. Learning to use more powerful tools is one of the best ways to increase your effectiveness.
That is the best tool depends on both the job and your skills. (Most of the post was about my main illustration though, which was drafting versus CAD.)
So the comparison is between starting from absolute scratch with Lisp -- having to choose a framework, get a dev environment set up, choosing your libraries etc vs an experienced PHP person just using PHP?
This article could easily be turned around to something like "use emacs, lisp and the trusted framework you already know, or try to learn PHP with its inconsistent naming and verbose syntax and ..."
Essentially he's judging languages by "wall-clock time", but only including time-to-learn in one of them.
From the article: "You can learn PHP in a day or two if you're familiar with any other language. You can write PHP code in any editor or environment you want. Emacs? Vim? Notepad? nano? Who cares? Whatever floats your boat. Being a stupid language also means that everyone knows it. "
The author didn't spend a lot of time talking about learning PHP because there's not much to learn. There's nothing surprising in the components in the PHP stack. If you know HTML, adding PHP has low overhead. DB reads and writes are simple. If you can program in another language, you know all of the logic statements you need to write an application. If you need an example, there are probably tens of thousands of bad PHP tutorials online with bad sample code that still manages to work.
I've learned PHP and Common Lisp from scratch at different points in my life, and PHP had a much lower barrier to entry. I installed and configured PHP on my local machine and made a stats-tracking webpage all on the same day. This was my first server-side web application ever, plus my first database program ever.
Fast forward 4 years, and I worked through "ANSI Common Lisp" for a month before I felt comfortable writing regular applications in Lisp. Then I installed Hunchentoot and stumbled around for a while, but was able to figure out how to generate static content. Most of the Hunchentoot tutorials online were for older versions, but I found one that proved invaluable. I then ended up patching S-XML, because it was only written to support 5 or 6 of the 250+ "&" style HTML character codes. I sent that patch to the mailing list, but I bet nobody ever got it. I tried to hook up a database, and found Postmodern, which was nice. Thank God I already knew Emacs, but I wasted more than a day fighting with upgrading SLIME and SBCL at the same time.
The Common Lisp path doesn't sound so bad, but compare it to my PHP experience - I wrote an application on the same day I first looked at PHP. By the time I was integrating Database code, I was well over a month into learning Common Lisp.
Isn't the problem with Common Lisp that you have to start with a lot less?
I've dabbled with Common Lisp for webdevelopment and I failed, miserably. I tried various the Mandriva package manager, downloading latest releases from the web, automatically and manually. It was already hard to get a bunch of packages together that where stable, somewhat current and compatible so I eventually quit.
If someone in the Common Lisp community could put together a web stack to get started it would help people like me tremendously. Lisps superiority is no point of discussion for me.
> use emacs, lisp and the trusted framework you already know
It took me 2 years to finally get comfortable with Emacs to the point I trust doing stuff in it, and I still don't know what I'm going to do if I ever start working in a language that doesn't have an editing mode available (it's not Textmate where you can define a syntax file in an hour).
For a whole month I studied Clojure, trying to wrap my head around it. I still have problems.
And now if I'd want to do stuff in Clojure, all web frameworks available suck for me (no, I don't like Compojure) ... which would mean I'd have to write my own ... or use Django, Rails 3, or even asp.net mvc 2 (even that is preferable).
Of course, being the yak-shaver that I am, I'll probably attempt to write a web-framework for Clojure of my own, but not when the clock is ticking.
On PHP ... doing PHP programming / copying popular websites was my first job. It took me exactly 1 week for going from a complete zero to someone that could get the job done.
I don't love PHP as there are truly better options out there, but libraries/frameworks are more important than languages. If Java frameworks would've been designed with an eye towards their users and not to please managers, it would've crushed all other high-level languages by now (and it did in many ways).
Buyer beware: PHP documentation is not always as extensive as is boasted and the user comments often times are very dangerously wrong. For an example of this see the comments to json_encode where many wrong PHP implementations are suggested (they don't take care of escaping non-ASCII data), or the read/write/socket functions where bizarre timeout behavior is suggested, or the microtime and usleep functions where even more bizarre things are suggested.
I fully agree. For instance, PHP implements it's own round function. Now there very well may be a good reason they don't just use/implement the C99 round - but one can at least expect it not to change. This isn't true, in some version (I forget which), they changed their implementation and that caused all sorts of headaches to us and our users that depend on these numbers.
As with most comments on the internet, you have to be careful not to take it all as stated fact, they are moderated which is good but I doubt they go into the implications of code snippets on edge cases when approving.
I haven't found anything misleading enough in the actual documentation to remember.
Despite the claims PHP is ugly. It's very easy to use. I've seen newb programmers able to do simple if statements and read data from a database with little coaching. It's really a delight to use for simple websites. The other factor is it's standard on ALL shared hosting. If they started to make rails or django standard I would have started with that instead.
The biggest strength of PHP has always been that a non-programmer who already has an HTML page can start adding dynamic code by inserting a simple tag into their HTML file and continue working as they have been (edit the HTML file, reload page, repeat). That's the lowest barrier to entry of any language except maybe javascript.
Most programmers aren't paid to revolutionize the world of computer science. Most programmers are code monkeys, or to put it more nicely, they're craftsmen who build things that other people pay them to create.
To say most programmers are craftsmen is a huge overstatement. Most programmers have no sense of craftsmenship.
Reading that article was pretty frustrating for me. Sure, if somebody decides to sit down and start writing a complex WebApp or program in direct PHP it can be a hodge-podge, however, if you were to use many of the frameworks out there you can get a very positive, and consistent experience, while also enjoying all the benefits of PHP's widespread adoption and support.
For example NOLOH (http://www.noloh.com), which provides just that sort of abstraction. NOLOH devs never even need to really know that they're in PHP. You would never know it from the consistent and elegant code, or the numerous syntactic sugars that make coding in it a joy. While none of this is out of the box in PHP, once you add NOLOH, poof, wonderful, clean, and consistent language, with language features that rival many others. Furthermore, any PHP environment can benefit from this, including all shared hosting users.
Thus in my opinion it's never that clear cut to suggest, oh PHP is crap, it's terrible, I hate working with it, because the language is flexible enough that you can write a framework that makes programming in it a joy. Now, if you were to ask me if I would use PHP without NOLOH that would be difficult. I've done it before, and it isn't so bad, but I would likely only go so far to a small script, or a small WebApp.
Solution? A framework which allows you to write lisp which turns into php written in php? Below is how I would do this in what I am calling "lisphp" http://github.com/shaunxcode/lisphp
(map-dict
[k v | tag :li (tag :strong k) (join "," (map [get :name _] v))]
(group-by :color (sql-query "select * from favcolor order by color, name")))
Another way to put it is that people don't learn lisp because it is never the local maxiumum, the nearest, easiest hill to climb. That's probably true, but always settling for local maximums has bad consequences over the long term. Periodically you should invest in figuring out how to do things better overall.
This is so true, and it's also valid for non-web uses of common lisp. Except Racket they are no user friendly lisp/scheme package. And heck, even Racket is far from ideal.
Lisp may be a superior langage, but setting it up is impractical for anybody who isn't used to hack emacs and bash scripts all day.
> but setting it up is impractical for anybody who
> isn't used to hack emacs and bash scripts all day
This is Hacker News right?
Having built websites in PHP, Python, Ruby, and Clojure ... guess what? They all present you with equal challenges if you're not building trivial small websites on shared hosting.
Getting a website up and running in Clojure is as simple as it gets. Compojure ships with a good webserver baked right in.
Well I'll assume by 'user' friendly, you mean 'developer' friendly.
PHP is ridiculously easy to get started with. I believe it was the first 'real' language and ecosystem that I really knew well [enough]. There's a huge body of knowledge associated with it that you can find on the web or in the bookstore.
PHP is ridiculously easy to grok because it's in the C family when it comes to syntax. PHP essentially enforces no control over the style you must employ while using it and doesn't even suggest a style to use. I made some awesome stuff in PHP but the code behind it was terrible.
Contrast this all with Lisp (which I'm still learning). I've never tried to do web dev with Common Lisp or anything, but getting started with Compojure was comparatively much harder than it was with PHP.
Lisp is conceptually more complex than PHP. You have to think at a higher level. It becomes easier but I definitely could not have grasped it at 12 or 13. Lisp isn't purely functional but afaik (from what I've seen), but it encourages a functional style. It's not as easy to grok as PHP and so I would imagine this creates a barrier for most 'code monkeys'. Why learn to use a new tool when the one you got ain't broken?
Using a good PHP MVC framework such as CodeIgniter or KohanaPHP can go a long way towards making your PHP code cleaner and more maintainable. PHP clearly does not match the expressiveness and elegance of Ruby or Python nor does it match the power of Lisp, but as the author points out, it does "get the job done". Using a good framework will help you avoid reinventing the "well written" PHP code wheel.
Why is PHP offered as the only other solution? I've used PHP in plenty of projects, and after years of experience with that, it would absolutely not be my first choice to solve what the author describes.
How about Ruby/ + Sinatra or Rails, or Python + Django or Pylons?
Over here, I wanted to try doing some web dev with Lisp, but couldn't find a CL implementation that would compile on FreeBSD/sparc64, so I guess I'm boned.
[+] [-] tsally|15 years ago|reply
"Today, Lisp is nothing like what it was 8,7,6, even 2 years ago. It's not just "good" in the well-explored text book fashion; no, it's _good shit_. Get work done good. Think, hack, ship, bill for it good. 2-3 products per month good. You still have to know where things are, who is working on what, what's maintained and what's obsoleted by what. Sure. But there is absolutely no lack of libraries." (http://news.ycombinator.com/item?id=972423).
I'm curious if the author of the article has similar experience deploying CL or if this article is just theorycrafting. I notice some experience with Clojure, but this article was written in 2008.
[+] [-] swannodette|15 years ago|reply
[+] [-] mechanical_fish|15 years ago|reply
It struck me the other day that this is why archivists have trouble with the web. Old links go dead all the time. Various people have tried to convince web publishers that they should take the preservation of old links seriously - we are destroying history! But it isn't just that preserving old links is hard work - which it is - but that history is a terrible burden for the living. You are forced to curate and disclaim it, or risk having it held against you. It's much more comfortable to just walk away from your history and hope that it biodegrades.
Forgetfulness is a blessing, and few online systems provide it in any well-thought-out fashion. Users are forced to use hacks to achieve it.
[+] [-] briancarper|15 years ago|reply
But I couldn't justify using either for a project for work. I generally choose Ruby instead nowadays. In Clojure I still end up rolling my own libraries for a lot of things, which is really quite fun in my spare time, but not justifiable if I'm billing by the hour and there are a dozen Ruby gems already written to do it.
We have seemingly constant threads on HN saying "I can't hire a good programmer!" What are the chances of my non-programmer boss hiring a good Lisp programmer? At the small non-profit at which I work? Good freaking luck.
I'm still using some PHP scripts at work today, and I still cringe to see the code, and I whine a little (to myself) whenever I have to edit it, and my boss still loves the end result, and it's done its job well for 2 years. What else matters? I believe in "Worse is Better" in this case.
I do sneakily use Clojure at work for small data-munging tasks. But not for code anyone else ever needs to see.
(I do also wonder why this blog post from 2008 made it to HN.)
[+] [-] wvenable|15 years ago|reply
Sometimes I wonder how much closures and meta-programming is just code for coding sake. I've seen lots of examples of 5 line LISP code that does something totally amazing but you don't really know what it means but it's so abstract. If you have a quick job to do, I don't see that it's a limitation in using a language that requires to build the most straight forward solution.
PHP is ugly, but for the most part it isn't horrible -- these days you can easily avoid some of the worst parts and concentrate on making code that would be very equivalent to the same code in, say, Java. PHP is very straight forward -- it means what it says.
"Your web framework in PHP probably isn't continuation-based, it probably doesn't compile your s-expression HTML tree into assembler code before rendering it."
This just sounds like over-engineering the problem.
[+] [-] swannodette|15 years ago|reply
Again the only thing I'm hearing here is arguments from people who are too lazy to actually see how things are done from a functional perspective. Get off your ass and find out. Then tell me you have a problem with it.
[+] [-] brlewis|15 years ago|reply
http://brl.codesimply.net/brl_4.html#SEC31
I can't forget to fetch the next row from the database. I can't forget to check that I'm at the end of the result set. Grouping the results is easy and straightforward. The statement and connection objects are automatically closed when the request is done. Compare that to PHP.
I'm getting better, but even today I feel a little irritated when someone says PHP was designed for simple web/database apps. I know what a language designed for simple web/db apps looks like, and PHP is not it.
[+] [-] eru|15 years ago|reply
(Though I do admit that I immensely like Lisp's macros.)
In e.g. Haskell abstractions are the straightforward way to solve a problem. Abstractions are cheap.
[+] [-] oconnore|15 years ago|reply
The mental energy is probably not worth it if you are just building a blog for yourself, but in that case, the mental energy of learning PHP is not worth it either. If the job is really that quick, why are you using dynamically generated content in the first place? HTML one-off's are the most straight forward solution.
On the other hand, if you want to build a bulletproof web application, you should probably use powerful tools, figure them out once, and then actually solve your problem.
[+] [-] sedachv|15 years ago|reply
Except the problem was never defined. Of the five commercial Lisp applications I've worked on, two are addressing domains (large-scale financial calculations, and a web platform/OS) where using PHP makes absolutely no sense, and the current one (ERP) where PHP was previously attempted and found not to make any sense. All three use basic techniques like closures, markup generation and metaprogramming, and one of them is continuation-based (which I think is a mistake, but opinions differ).
[+] [-] ulf|15 years ago|reply
A tool is seldom more than a tool. In regard to languages, for most projects there are more than enough constraints to begin with, so you can pick a language of your choice in no time. Sure there are languages that suck and languages that are awesome. But most of these comparisons only work in a vacuum. And in practice, no project ever starts in a vacuum.
[+] [-] billswift|15 years ago|reply
Use tools appropriate to your skills and to the job you are trying to get done. Learning to use more powerful tools is one of the best ways to increase your effectiveness.
That is the best tool depends on both the job and your skills. (Most of the post was about my main illustration though, which was drafting versus CAD.)
[+] [-] bonaldi|15 years ago|reply
This article could easily be turned around to something like "use emacs, lisp and the trusted framework you already know, or try to learn PHP with its inconsistent naming and verbose syntax and ..."
Essentially he's judging languages by "wall-clock time", but only including time-to-learn in one of them.
[+] [-] jakevoytko|15 years ago|reply
From the article: "You can learn PHP in a day or two if you're familiar with any other language. You can write PHP code in any editor or environment you want. Emacs? Vim? Notepad? nano? Who cares? Whatever floats your boat. Being a stupid language also means that everyone knows it. "
The author didn't spend a lot of time talking about learning PHP because there's not much to learn. There's nothing surprising in the components in the PHP stack. If you know HTML, adding PHP has low overhead. DB reads and writes are simple. If you can program in another language, you know all of the logic statements you need to write an application. If you need an example, there are probably tens of thousands of bad PHP tutorials online with bad sample code that still manages to work.
I've learned PHP and Common Lisp from scratch at different points in my life, and PHP had a much lower barrier to entry. I installed and configured PHP on my local machine and made a stats-tracking webpage all on the same day. This was my first server-side web application ever, plus my first database program ever.
Fast forward 4 years, and I worked through "ANSI Common Lisp" for a month before I felt comfortable writing regular applications in Lisp. Then I installed Hunchentoot and stumbled around for a while, but was able to figure out how to generate static content. Most of the Hunchentoot tutorials online were for older versions, but I found one that proved invaluable. I then ended up patching S-XML, because it was only written to support 5 or 6 of the 250+ "&" style HTML character codes. I sent that patch to the mailing list, but I bet nobody ever got it. I tried to hook up a database, and found Postmodern, which was nice. Thank God I already knew Emacs, but I wasted more than a day fighting with upgrading SLIME and SBCL at the same time.
The Common Lisp path doesn't sound so bad, but compare it to my PHP experience - I wrote an application on the same day I first looked at PHP. By the time I was integrating Database code, I was well over a month into learning Common Lisp.
[+] [-] Bootvis|15 years ago|reply
I've dabbled with Common Lisp for webdevelopment and I failed, miserably. I tried various the Mandriva package manager, downloading latest releases from the web, automatically and manually. It was already hard to get a bunch of packages together that where stable, somewhat current and compatible so I eventually quit.
If someone in the Common Lisp community could put together a web stack to get started it would help people like me tremendously. Lisps superiority is no point of discussion for me.
[+] [-] bad_user|15 years ago|reply
It took me 2 years to finally get comfortable with Emacs to the point I trust doing stuff in it, and I still don't know what I'm going to do if I ever start working in a language that doesn't have an editing mode available (it's not Textmate where you can define a syntax file in an hour).
For a whole month I studied Clojure, trying to wrap my head around it. I still have problems.
And now if I'd want to do stuff in Clojure, all web frameworks available suck for me (no, I don't like Compojure) ... which would mean I'd have to write my own ... or use Django, Rails 3, or even asp.net mvc 2 (even that is preferable).
Of course, being the yak-shaver that I am, I'll probably attempt to write a web-framework for Clojure of my own, but not when the clock is ticking.
On PHP ... doing PHP programming / copying popular websites was my first job. It took me exactly 1 week for going from a complete zero to someone that could get the job done.
I don't love PHP as there are truly better options out there, but libraries/frameworks are more important than languages. If Java frameworks would've been designed with an eye towards their users and not to please managers, it would've crushed all other high-level languages by now (and it did in many ways).
[+] [-] blaix|15 years ago|reply
[+] [-] IgorPartola|15 years ago|reply
[+] [-] mifrai|15 years ago|reply
Moral of the story? Don't use PHP for stats.
[+] [-] robryan|15 years ago|reply
I haven't found anything misleading enough in the actual documentation to remember.
[+] [-] adamilardi|15 years ago|reply
[+] [-] scottjad|15 years ago|reply
[+] [-] thejay|15 years ago|reply
To say most programmers are craftsmen is a huge overstatement. Most programmers have no sense of craftsmenship.
[+] [-] asnyder|15 years ago|reply
For example NOLOH (http://www.noloh.com), which provides just that sort of abstraction. NOLOH devs never even need to really know that they're in PHP. You would never know it from the consistent and elegant code, or the numerous syntactic sugars that make coding in it a joy. While none of this is out of the box in PHP, once you add NOLOH, poof, wonderful, clean, and consistent language, with language features that rival many others. Furthermore, any PHP environment can benefit from this, including all shared hosting users.
Thus in my opinion it's never that clear cut to suggest, oh PHP is crap, it's terrible, I hate working with it, because the language is flexible enough that you can write a framework that makes programming in it a joy. Now, if you were to ask me if I would use PHP without NOLOH that would be difficult. I've done it before, and it isn't so bad, but I would likely only go so far to a small script, or a small WebApp.
Disclaimer: I'm a co-founder of NOLOH
[+] [-] jacquesm|15 years ago|reply
[+] [-] mahmud|15 years ago|reply
http://quicklisp.org/
[+] [-] shaunxcode|15 years ago|reply
[+] [-] adamc|15 years ago|reply
[+] [-] norswap|15 years ago|reply
Lisp may be a superior langage, but setting it up is impractical for anybody who isn't used to hack emacs and bash scripts all day.
[+] [-] swannodette|15 years ago|reply
Having built websites in PHP, Python, Ruby, and Clojure ... guess what? They all present you with equal challenges if you're not building trivial small websites on shared hosting.
Getting a website up and running in Clojure is as simple as it gets. Compojure ships with a good webserver baked right in.
[+] [-] unknown|15 years ago|reply
[deleted]
[+] [-] michaelfairley|15 years ago|reply
[+] [-] briancarper|15 years ago|reply
[+] [-] invisible|15 years ago|reply
[+] [-] ww520|15 years ago|reply
[+] [-] Tichy|15 years ago|reply
[+] [-] sigzero|15 years ago|reply
[+] [-] jfager|15 years ago|reply
[+] [-] tkahn6|15 years ago|reply
PHP is ridiculously easy to get started with. I believe it was the first 'real' language and ecosystem that I really knew well [enough]. There's a huge body of knowledge associated with it that you can find on the web or in the bookstore.
PHP is ridiculously easy to grok because it's in the C family when it comes to syntax. PHP essentially enforces no control over the style you must employ while using it and doesn't even suggest a style to use. I made some awesome stuff in PHP but the code behind it was terrible.
Contrast this all with Lisp (which I'm still learning). I've never tried to do web dev with Common Lisp or anything, but getting started with Compojure was comparatively much harder than it was with PHP. Lisp is conceptually more complex than PHP. You have to think at a higher level. It becomes easier but I definitely could not have grasped it at 12 or 13. Lisp isn't purely functional but afaik (from what I've seen), but it encourages a functional style. It's not as easy to grok as PHP and so I would imagine this creates a barrier for most 'code monkeys'. Why learn to use a new tool when the one you got ain't broken?
[+] [-] neovive|15 years ago|reply
[+] [-] code_duck|15 years ago|reply
How about Ruby/ + Sinatra or Rails, or Python + Django or Pylons?
[+] [-] jff|15 years ago|reply
[+] [-] rubinelli|15 years ago|reply