Practicality: PHP vs. Lisp?
Eric at LispCast wrote an article about why PHP is so ridiculously dominant as a web language, when arguably more powerful languages like Common Lisp linger in obscurity.
I think the answer is pretty easy. In real life, practicality usually trumps everything else. 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. The code is a tool to help people do a job. The code is not an end in itself.
In real life, here's a typical situation. You have to make a website for your employer that collects survey data from various people out in the world, in a way that no current off-the-shelf program quite does correctly. If you could buy a program to do it that'd be ideal, but you can't find a good one, so you decide to write one from scratch. The data collection is time-sensitive and absolutely must start by X date. The interface is a web page, and people are going to pointy-clicky their way through, and type some numbers, that's it; the backend just doesn't matter. For your server, someone dug an old dusty desktop machine out of a closet and threw Linux on there for you and gave you an SSH account. Oh right, and this project isn't your only job. It's one of many things you're trying to juggle in a 40-hour work week.
One option is to write it in Common Lisp. You can start by going on a quest for a web server. Don't even think about mod_lisp, would be my advice, based on past experience. Hunchentoot is good, or you can pay a fortune for one of the commercial Lisps. If you want you could also look for a web framework; there are many to choose from, each more esoteric, poorly documented and nearly impossible to install than the last. Then you get to hunt for a Lisp implementation that actually runs those frameworks. Then you get to try to install it and all of your libraries on your Linux server, and on the Windows desktop machine you have to use as a workstation. Good luck.
Once you manage to get Emacs and SLIME going (I'm assuming you already know Emacs intimately, because if you don't, you already lose) you get to start writing your app. Collecting data and moving it around and putting it into a database and exporting it to various statistics packages is common, so you'd do well to start looking for some libraries to help you out with such things. In the Common Lisp world you're likely not to find what you need, or if you're lucky, you'll find what you need in the form of undocumented abandonware. So you can just fix or write those libraries yourself, because Lisp makes writing libraries from scratch easy! Not as easy as downloading one that's already been written and debugged and matured, but anyways. Then you can also roll your own method of deploying your app to your server and keeping it running 24/7, which isn't quite so easy. If you like, you can try explaining your hand-rolled system to the team of sysadmins in another department who keep your server machine running.
Don't bet on anyone in your office being able to help you with writing code, because no one knows Lisp. Might not want to mention to your boss that if you're run over by a bus tomorrow, it's going to be impossible to hire someone to replace you, because no one will be able to read what you wrote. When your boss asks why it's taking you so long, you can mention that the YAML parser you had to write from scratch to interact with a bunch of legacy stuff is super cool and a lovely piece of Lisp code, even if it did take you a week to write and debug given your other workload.
Be sure to wave to your deadline as it goes whooshing by. If you're a genius, maybe you managed to do all of the above and still had time to roll out a 5-layer-deep Domain Specific Language to solve all of your problems so well it brings tears to your eye. But most of us aren't geniuses, especially on a tight deadline.
Another option is to use PHP. Apache is everywhere. MySQL is one simple apt-get away. PHP works with no effort. You can download a single-click-install LAMP stack for Windows nowadays. PHP libraries for everything are everywhere and free and mature because thousands of people already use them. The PHP official documentation is ridiculously thorough, with community participation at the bottom of every page. Google any question you can imagine and you come up with a million answers because the community is huge. Or walk down the hall and ask anyone who's ever done web programming.
The language is stupid, but stupid means easy to learn. 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. If you jump ship, your boss can throw together a "PHP coder wanted" ad and replace you in short order.
And what do you lose? You have to use a butt-ugly horrid language, but the price you pay in headaches and swallowed bile is more than offset by the practical gains. PHP is overly verbose and terribly inconsistent and lacks powerful methods of abstraction and proper closures and easy-to-use meta-programming goodness and Lisp-macro syntactic wonders; in that sense it's not a very powerful language. 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.
But PHP is probably the most powerful language around for many jobs if you judge by the one and only measure that counts for many people: wall clock time from "Here, do this" to "Yay, I'm done, it's not the prettiest thing in the world but it works".
The above situation was one I experienced at work, and I did choose PHP right from the start, and I did get it done quickly, and it was apparently not too bad because everyone likes the website. No one witnessed the pain of writing all that PHP code, but that pain doesn't matter to anyone but the code monkey.
If I had to do it over again I might pick Ruby, but certainly never Lisp. I hate PHP more than almost anything (maybe with the exception of Java) but I still use it when it's called for. An old rusty wobbly-headed crooked-handled hammer is the best tool for the job if it's right next to you and you only need to pound in a couple of nails.
The PHP might be easy to learn but I find it really ugly and hard to use.
I have got a different situation: started writing a web site in PHP and then found out that it is much more easier to program certain things in Common Lisp. As a result, the site is mainly PHP with a major toolset in Common Lisp used to process data for that site.
And in the future I would like to have the whole site written in Common Lisp, because it is much more easier and straightforward to express common algorithms in Common Lisp than PHP. (that array() thingy drives me mad)
You forgot to mention how PHP is practically ubiquitous in many shared hosting environments.
> I think the answer is pretty easy. In real life, practicality usually trumps everything else. 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. The code is a tool to help people do a job. The code is not an end in itself.
And for large projects, Common Lisp will let you get it done with less pain than PHP.
> Once you manage to get Emacs and SLIME going (I'm assuming you already know Emacs intimately, because if you don't, you already lose)
It takes time to get yourself trained in good technology.
> undocumented abandonware
Really? Which library exactly are you referring to? This smells like FUD.
> Don't bet on anyone in your office being able to help you with writing code, because no one knows Lisp
More FUD…
> Another option is to use PHP.
Sure. Or several other programming languages: Java, Python, Ruby and others.
> Apache is everywhere.
Yes.
> MySQL is one simple apt-get away.
Yes.
> PHP works with no effort.
Hm. In a large environment, you may have problems.
Maintaining PHP code is painful, unless you've been trained in good design and programming practices (which most people familiar with Lisp and Smalltalk are familiar with).
Migrating to a new version of PHP (for example, 4 to 5) can be HELL. I've seen this is a big company. Big effort. Stop several engineers, tell them to start “migrating code”. (Does that happen with Common Lisp?)
I agree with this article. PHP is from a practical point of view dominant for the http://www.
Lisp has faded because for too long it has not given the www the practical importance it required.
The www is very important. EVERY language that wants to compete with php needs to understand that.
The www IS IMPORTANT.
Or does anyone see many webshops in lisp, or in php?
Last but not least, to the guy
who commented before me:
“And for large projects, Common Lisp will let you get it done with less pain than PHP.”
And this is valid for many other languages like Ruby too. So what is your point? I also do not like PHP but we have to be realistic - PHP was a big success.
> It takes time to get yourself trained in good technology.
Experience makes many things easier, better etc… but a bad language will help you less than a good language. I had quite some trouble to write an IRC bot in php but it was really easy in Ruby. (Mind you, i have not touched that old code anymore but my point is that after some time the BETTER language will help you more than a worse language. It helps you achieve MORE.)
> More FUD…
Lisp is still there, jobs in lisp still exist, but from a practical point of view perl/php/python/ruby are a MUCH closer “family” of programming languages than lisp. If you can not understand this, I have a simple suggestion - visit the websites of these languages. Especially ruby and python have nice websites. PHP has a rather practical website, with good online docu. Perl is showing its age on its website, but please compare that with lisp websites… they are so 1990. (Perl website is 1992…)
> Maintaining PHP code is painful
Wait a second! The author said himself that php is a horrible language! I agree with him. There is no point in listing all of php problems. Years ago I jumped the boat away from php. These days I recommend ruby or python to people (personally I clearly favour ruby but I have no real problem with python.)
Excellent post. Exactly the problem with Lisp.
When Java has teached us one thing - and I guess PHP is the same :
Since the mid-90s we don't develop software but we assemble software
from existing libraries. As with Java in PHP there are lots of
excellent libraries for all tasks. Development is a minor point.
So at least for us developers who need to earn money and don't have
a vendor lock-in with airplane carriers or work at NASA with an
- former -unlimited flow of money, we best stick to Java, PHP or
other ready to use and assemble languages
“Maintaining PHP code is painful, […]”
And Lisp isn't, why? Or do you propose the standard Lisp answer: Because all Lisp developers are geniuses so they don't make errors and always write beautifully architectured code.
Peace
-stephan
This is all so true.
For small, simple, dynamic web sites, nothing beats LAMP. It has — to quote Larry Wall — on-ramps.
I don't think this applies so much to more complicated sites, where the simplicity of PHP means you have to do more work.
For a long-term project, I would choose Lisp. I think, in the end, I would come out ahead in terms of frustration.
Java here, Java there, Java everywhere…
Use ABCL (or Clojure) and you get the Java “batteries” available on [Common] Lisp.
“For a long-term project, I would choose Lisp. I think, in the end, I would come out ahead in terms of frustration.”
Where do you recruit 50 Lisp developers?
Peace
-stephan
You can download a single-click-install LAMP stack for Windows nowadays.
Lispbox includes a AllegroServe, which means you cat get the whole set (Lisp/Emacs+Slime/webserver) in one package, too.
@Stephan Schmidt:
off-the-top-of-head-response: comp.lang.lisp? #lisp (IRC)?
after-more-thought-response: I am a developer with over 12 years of work experience (I was into computers way before I ever was employed to write software for them). I have worked for multiple businesses and have a lot of friends who are developers also. I have never once known anyone who worked for a company that was recruiting 50 developers at the same time (and I've worked mostly with very popular languages — C, C++, perl, and yes, a little PHP). I have worked on desktop applications, web applications, and applications for handheld devices). All the recruiting efforts I can think of were for 5 or less developers (many, perhaps most, were for 1 or 2 developers). I'm not saying that there aren't teams out there with larger numbers (I know there are), but in my estimation, those teams are the minority. I would guess that most groups in a company that actually work together on projects consist of a team of 10 or less individuals — with a large percentage of those being teams of 5 or less). Yes, I have worked for small businesses, but I have also worked for large million-dollar and even billion-dollar corporations.
No, it will not be as easy to find Lisp developers as it will be to find Java or C++ developers. However, I doubt very seriously that most people will *ever* be recruiting for 50 developers at the same time.
One solution to the recruiting problem is this: Hire good programmers who are willing to learn, pay them well, and give them the time to learn Lisp from more experienced developers who already know it (small projects, or small new features on existing projects). Companies do this every day with Java and C++ developers. There is no reason it can't be done with Lisp programmers. In fact, from what I've read, this is exactly what companies like ITA software do all the time (http://itasoftware.com).
I will not argue against the fact that many Lisp libraries need better documentation. That is true. It is also true that it will probably take many developers a longer time to get the hang of Lisp. No argument there. If you are just wanting to create a single one-off application, and are not willing to invest a significant amount of time in learning to use Lisp, then by all means use a more popular language that you already know. However, I have never known of anyone who spent a significant amount of time learning and *using* Lisp (and yes, I do know quite a few) who did not find it extremely productive and useful for everyday projects — this is despite the difficulties one might have with library documentation, etc. The key is that you have to invest the time, which most people appear to not be willing to do (or they are not given the opportunity to do it in a work setting). It is not much different than spending the time to learn a powerful text editor, like vim or emacs (I've personally been using vim for about 10 years). Yes, they operate differently than most other applications. Yes, they both feel “weird” and “unconventional” to new users. However, if you spend 6-8 hours a day, 5 days a week (or more) using one of these editors, you can become “fluent” in either of them fairly quickly, and you will probably soon find that you are able perform complex editing tasks in them faster and easier than you could in a more “standard” type text editor. I am *very* fast with vim and I have close friends who are very fast in emacs (and all of us work or have worked with multiple languages in multiple environments — including Windows, Linux, Solaris, etc). Both editors are powerful, but both have a steep learning curve (with vim's curve being perhaps a bit steeper, but others might disagree with that). The situation is the same with Lisp. Powerful tools often require an investment in time to learn to use well. The situation with Lisp requires a very significant investment, and a good deal of patience, but I know of many people who would argue that the payout is big enough to be more than enough to make up for the required investment to get to that payout.
true. It is like whether or not accept lesser evil. If one wants to marry wrong woman and live with her his entire life - you can't argue with that.
I program in Common Lisp, because this is what I want to do. I like programming, I like Common Lisp - and I would never code in language I don't like unless forced to. At the moment, I have the freedom to choose.
luxury, eh? Well - OK, maybe, dunno.
I think PHP is fine for what it is… a tool to put together a reasonably functional website quickly. I like your comment: “An old rusty wobbly-headed crooked-handled hammer is the best tool for the job if it's right next to you and you only need to pound in a couple of nails.”. What I see far too often though is application developers seeing everything and anything as a nail just because they have this “wobbly-headed-crooked-handled hammer” nearby. I see this all the time… we hired this guy to build a series of complicated business transactions to be executed as cron jobs… AND HE DID IT IN PHP! We hire a person to do memory caching as a service… AND HE DID IT IN PHP! We wanted to build a domain specific language parser… AND DID IT IN PHP!!! YIKES! Right tool for the job people… yes, take proximity and availability and cost into consideration, but hey, let's not be stupid!
Also worth noting - it is not the speed or practicality or getting the job done, it is cost of maintenance and time-to-response for change requests ten years from now that matters. At least, for some applications
@a programmer: Not 50 at one time, but it's difficult even over serveral years to recruit 50 lisp developers in one city I guess.
“All the recruiting efforts I can think of were for 5 or less developers (many, perhaps most, were for 1 or 2 developers).”
We're a small website with 50 developers and - when looking at our jobs page - we currently search for 5 more Java developers. Perhaps we're just in two different industries.
Peace
-stephan
Lal, a LAMP stack in Windows. The problem with using buzzwords and buzz-acronyms instead of actually naming the technologies is that you start forgetting what they mean and start attaching other, largely incorrect connotational meanings to them.
You can never have a LAMP stack under anything but Linux. By definition. Try to remember that those letters mean things.
Clojure is an interesting hybrid that may give a best-of-both-worlds approach. It will be interesting to see how the experiment plays out.
@Stephan Schmidt: Fair enough. I would suggest that you should be able over several years to recruit enough good programmers who will learn whatever technology you ask them to. You can be more picky about who you hire if you pay a good wage. Some companies are either unwilling or unable to do so (but given the waste I've seen at many companies, the real problem is that they put their money in the wrong places). Even when money-constrained, it is better to hire fewer good programmers who get real work done than to fill the quota with mediocre ones — which is all too common. And I think you can invest the money in training different technologies (just like companies do with Java/C++). If developers aren't willing to learn on the job, you're hiring the wrong ones. I can appreciate that this is more difficult to do for smaller operations, however. Bigger companies have the resources to do so, but are often too blind to see any possible benefits of making the investment.
We are at least in different niches, most likely. Some of my web application work has been for intranet web applications, rather than public internet ones. Much of the public internet web applications were for small companies with 10 or less total developers. The larger corporations I have worked for may have had 50 or more developers total, but most of the teams were broken down into groups of 10 or less that worked largely in isolation with limited joint projects.
Of course, most of the Lisp developers I know would argue that if you hire good programmers and train them to know Lisp well, you would never need 50 developers for a small site. I can, however, appreciate the difficulties in making that investment in a small company, where you may not have the time to invest up front — especially when the technology goes against what many will call “conventional wisdom”, whether or not the term “wisdom” is really appropriate in that instance.
adoption!=practicality
@John Haugeland: That would mean that on Windows you would have a WAMP stack, or perhaps a WIMP stack if you use IIS. Sorry I couldn't help myself.
Is Arc making server-side lisp easier?
Arc is largely vaporware. :(
my god this is so interesting
I wrote my thesis on LISP.
I helped start a company, Interleaf, that based its product on LISP.
These days I use PHP and JavaScript.
The thing about abandonware libraries is simply untrue, and unfair.
I once had some software wrote in PHP and I disliked it. The meshing up of things is “terrible”, I gave Lisp the “chance” but in the end I used Ruby + Rails. I wrote about APIs just be usable by thos having implemented the library. I've seen the problems with Common Lisp libraries all too often. There are still exceptions: If you'd use the stuff provided by the Common Lisp Vendors you usually can get through without too much headaches. The libraries from Edi Weitz can be seen as “standard”. But my experiences with UCW, Cells, McClim etc were devastating. I wrote about my problems with ucw at http://www.cliki.net/UCW.
So you better knwo which places to go to find “useful” Lisp stuff. And you just learn that by painful try+error mode…
Feel free to flame me for that
Friedirhc
try this: http://www.cliki.net/CoreServer
Sounds like there's a market for LispScript. :)
I recently wrote an app which had to compile arbitrary oblique specifications each into a plugin for a different application on some target machine (running either PHP5, ASP.NET or JSP). That plugin would, in turn, gather user input and compile a code instance elsewhere and that instance would then gather up whatever files/data it needed and output HTML.
I wrote that app in Lisp. It is well written, easy to read, easy to maintain. It is running well, the plug-ins it compiled are running well on whatever different servers they are at, the code instances that they build are running well. I know PHP very well and have coded in it for years. But make no mistake, if I had chosen to write that app in PHP instead of Lisp, I'd still be working on it and it'd probably never be working correctly.
PHP+Apache+MySQL is convenient and great. That convenience is a big advantage. But, as far as I can tell, it is PHPs only advantage when compared to Lisp.
I've used Lisp on several projects and have never felt poor for libraries. There is a fantastic library for handling regular expressions, several choices for XML parsing, several HTTP server and client options, SOAP, Amazon S3, image handling including bindings to GD, the list goes on and on.
If I'm building a data-driven web service will I choose Lisp over PHP? Not necessarily - do I have control over the server, or is it going to be put on some client's server? As I said, that convenience aspect of PHP is a big advantage. But if the app is anything more than flour-and-water pasting of some SQL queries/XML parsing to web output (a childs task that hardly deserves to be called programming anymore) then I choose a grown up language, and PHP is not that.
stupid lisper.
Lisp is the easiest language to use, If you are a real programmer you would under stand, lisp means LISt Processing. Everything is a list. Everything uses () which makes the code easier to figure out. Everything is just a plugin within a plugin. Just little pieces that fit in other peices
simple list
(list :namea “hello” :nameb “world”)
getting part from list
(getf yourlist :namea)
the real evaled code
(getf (list :namea “hello” :nameb “world”) :namea)
How difficult is it to figure out all you are playing with are strings. Once you figure this out any task is simple.
Instead of wasting time trying to figure out what premade package is out there that wastes memory every time it is loaded.
Time finding these premade functions is ridiculous.
Just know what you want your final result to be before you start working
To avert myself from exploding at the in-accurateness of this post, I composed my reply from keywords.
windows,clisp,hunchentoo,cl-who,quicker,better,easy - genius not required,emacs not required,libraries - http://www.cliki.net/web
Yeah, any company which wants a couple of web pages and a bit of script should use PHP, everyone knows that. Its economics, not technological wisdom, stupid.
I've coded PHP websites a lot, and CL for a very short time. I can tell you hands down CL beats PHP in productivity by orders of magnitude - if you can learn it for just a minimal amount of time.
Hey I know what'll add to my post…
FUDFUDFUDFUDFUDFUDFUDFUDFUDFUDFUDFUD
Much better.
Glad you feel better now!
An interesting, yet not really solid, post. I have been coding Common Lisp, Haskell, Ruby, PHP, Java, C,… the works. In my finding, I like lisp the most. Whenever I'm coding in another language, I feel sad because of the missed abstractions. Virtual limitation of my programming skills, solely due to the inexpressiveness of the language I was obliged to use.
Besides the fact that other languages frustrate me, I do acknowledge that there is a lack of standardized libraries in Common Lisp. This indeed makes many inferior languages quicker on the short run. It tends to be easy to write new libraries in lisp, but certainly, it is not always a welcome treat when the job needs to be done quickly.
I don't believe there is a shortage of Lisp programmers out there. It is hard to find experienced lispers, because no experience can be gained in a payed environment. Schools generally don't help either, with their overly hard emphasis on the more popular, yet feature-inferior languages (eg: Java). Yet I do know some that would do much to code in lisp, instead of php.
The conclusion of this post for youngsters or interested coders, is hopefully not one of ignorance towards Lisp. The poster makes clear that Lisp allows for greater abstractions. It is up to all of us, to use this power. To make better libraries in it. To make the language live. Therefore, I suggest newcomers to learn the language, to build in the language. Try to build libraries in Lisp, you'll never learn to build them that good in any other language.
--
Anyway, we all know chicks dig lispers.