
Practicality: PHP vs Lisp - sajid
http://briancarper.net/blog/386/practicality-php-vs-lisp
======
tsally
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.

~~~
jwr
I think many people who defend Common Lisp in this thread never actually
deployed web applications written in CL.

I have.

I had to seriously hack on Weblocks just to get things to work they way they
should. I had to work around various bugs and omissions. And worst of all,
every once in a while I discovered that I am clearly the only user of said
software.

A good example is when I discovered that the database interface (to CLSQL)
isn't thread-safe. It was a quick hack intended for a single thread only.
Obviously you'd never notice it in a demo setup. Turns out I noticed it just
when somebody else had that problem and wrote CLSQL-FLUID.

But there is more — after running the application for several months I
discovered two things:

a) there are obscure bugs related to caching in CLSQL, which I don't have time
to hunt down (stale content is being served),

b) there are bugs somewhere either in CLSQL or Weblocks that blocked part of
my admin interface and they are obscure enough that I don't even know where to
start looking,

c) every once in a while SBCL will crash on me and land me in the LDB.

Don't get me wrong — I like CL and I invested a significant amount of work in
to Weblocks — but I agree with Brian here: I don't want to discovere somewhere
along the way that I'm the first real user. At least not when I am on a
deadline.

I do most of my work in Clojure now, but when there is a simple web
application to write — hey, we get our hands dirty and we do it using PHP.
Because life is too short.

~~~
Ixiaus
PHP works well as a DSL for web applications; I recently switched from PHP to
Python + Pylons and am noticing significant differences in workflow. So
significant that I can see, precisely, why PHP is so dominant. Python's
features as a language completely overthrow those of PHP, though - I have no
reason to go back.

I've had my eye on Scheme as a potential web application environment for a
year now. Maybe I'll make the jump soon, Racket (PLT-Scheme) looks like it
would beat CL + Weblocks in maturity.

~~~
jacquesm
> I recently switched from PHP to Python + Pylons and am noticing significant
> differences in workflow.

Can you elaborate ?

~~~
Ixiaus
I'm noticing that the idiom for WSGI based frameworks, is to "layer"
applications (middleware), a lot like an onion. Certain actions/functionality
is only available within specific layers of that onion. I quickly found out
you can't just call _redirect(url('some_route'))_ from within your helpers (or
any module outside of the callable controller); the exception will be caught,
but instead of redirecting it will display it as an error.

In PHP, unless headers have already been sent, you can call this:
_header("Location: blablablabl")_ from wherever.

That's just one example of the difference in workflow, it took me some getting
used to before I could appreciate it. There are many other "little" things
such as above, that are different.

I'm loving Python + Pylons, the more I use it the more I get used to the
workflow too...

------
swannodette
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).

~~~
mechanical_fish
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.

~~~
jherdman
How is this a problem with the web any more than anything? As soon as a
thought leaves your mind and is engraved on some sort of medium (be it
someone's memory, paper, or a webpage) it's out there for good.

Publishing thoughts on web, like print, demands rigour from the author and the
reader. Read actively, write like you have an audience, and be skeptical.

~~~
mechanical_fish
_As soon as a thought leaves your mind... it's out there for good._

This is another mindset endemic to engineers like myself: First-order
thinking. The notion that, because a bit in a piece of flash RAM, a memory in
someone's brain, and an etching on the wall of a thousand-year-old church are
all the same to first order -- "persistent" storage of information -- they can
therefore safely be treated as the same thing.

The second-order differences are pretty important. To pick just one particular
example: Human memory is not just an incredibly fallable medium (you remember
events that never happened, and your memory of events that did happen gets
distorted over time and is situational, dependent on your current mood) but it
is inevitably filtered through the personality of the rememberer. The only way
to learn what a World War II veteran remembers about the war is to listen to
what the veteran tells you. If the veteran happens to have been a personal
friend of General Patton, they will tell you certain things about Patton. If
the veteran was a sworn enemy of Patton, they will tell you other things about
Patton. If you strive to prevent them from doing this consciously, they will
do so unconsciously. Such is the nature of human memory and communication.

A photograph of Patton, or a written memoir, is an entirely different beast.

And, similarly, there is a big qualitative difference between a third-hand
account of a conversation in a bar, an entry in a handwritten diary that is
stored in your basement someplace, and a popular web page that has been
downloaded a thousand times and is available on Bittorrent in case the
original is taken down.

------
wvenable
"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.

~~~
brlewis
Say you want to connect to a database, fetch some data, and present it using
HTML. Here's how it can be done using a DSL based on Scheme macros:

<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.

~~~
jacquesm

      sql_apply("select id,somefield from sometable","applicator_function");
    

PHP is a programming language, it was not designed for 'simple web/database
apps' any more than any other language, you can use the building blocks
provided to create access at the level you require. But you can customize it
so that it does become usable for 'simple web/database apps'.

The above is a short sample of how I'd do the thing you describe and I don't
have to remember to fetch the next row from the table and I don't have to
check that I'm at the end of the result set, grouping is as easy as SQL will
make it and all cleanup is automatic.

~~~
btilly
_PHP is a programming language, it was not designed for 'simple web/database
apps' any more than any other language..._

Um, yes it was. See <http://en.wikipedia.org/wiki/PHP#History> to verify that
PHP started as a bunch of CGI binaries to serve some simple dynamic web pages.
The database bit came later, but at the start it was explicitly designed for
quick and dirty web pages.

~~~
jacquesm
You can't seriously compare the state of PHP today with the first released
version.

You could make such statements about every other mainstream language.

~~~
eru
At least the Lisp guys have figured out how to write parsers and lexers by
now. (They even grok lexical scoping.)

I guess we can't blame PHP for preserving the $ in front of variable-names
with all the legacy code lying around. But the following should parse in a
sane language:

    
    
      $width = getimagesize($filename)[0];
    

Adding support for this would not break legacy code. Nobody can tell me that
naming all intermediate results like

    
    
      $sizes = getimagesize($img);
      $width = $sizes[0];
    

is such a preferable style, that the parser should enforce it.

By the way, this is how PHP pretends to support higher order functions:

    
    
      function cube($n) {return($n * $n * $n);}
      $a = array(1, 2, 3, 4, 5);
      $b = array_map("cube", $a);

------
ulf
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.

~~~
billswift
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.)

------
bonaldi
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.

~~~
jakevoytko
He's not making that argument!

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+
"&amp;" 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.

~~~
eru
Learning bad PHP may be easy. But from my exposure to PHP I find learning to
write good PHP code to be fairly hard. Because you have to work around all the
limitations of the language.

Common Lisp may not be a paragon of elegance, but it's not nearly as awful as
PHP. And Common Lisp is a fairly conventional, mostly imperative language.
Nothing as scary as Haskell or Prolog, or even Scheme.

~~~
scott_s
It's not an argument over which language helps a programmer produce better
code. It's an argument over which language helps a programmer generate an
almost-correct solution faster.

It's the same as Worse Is Better:
<http://www.dreamsongs.com/WorseIsBetter.html>

~~~
eru
Yes. I buy your argument, if you say "small-scale good-enough solution".

~~~
scott_s
To be clear, it's not _my_ argument. I'm just trying to clarify what argument
the author is making.

~~~
eru
Understood.

------
IgorPartola
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.

~~~
mifrai
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.

Moral of the story? Don't use PHP for stats.

------
adamilardi
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.

------
scottjad
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.

------
thejay
_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.

------
asnyder
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.

Disclaimer: I'm a co-founder of NOLOH

~~~
jacquesm
NOLOH looks great by the specs, I'd probably put some time in to evaluating it
if it were open source.

~~~
asnyder
We do offer open-source projects license, and have an open-source guarantee.
Meaning that if anything should happen to us the source-code would be opened.
We're currently designing a clearer product section that details the guarantee
along with clearer descriptions of the free and commercial license options.

------
mahmud
Xach has a new toy under-wraps that's gonna revolutionize the state of Lisp
deployment. Really awesome stuff. Stay tuned ;-)

<http://quicklisp.org/>

------
shaunxcode
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")))

------
adamc
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.

------
norswap
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.

~~~
swannodette
Wow people are upvoting this FUD?

    
    
      > 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.

~~~
Raphael_Amiard
> Getting a website up and running in Clojure is as simple as it gets.

Well you first have to get clojure running. And that's not as simple as it
gets

~~~
masomenos
You piqued my curiosity, never having tried Clojure.

My time from 0 to getting (the correct!) result of (+2 2) from Clojure's REPL
was approximately 60 seconds.

Pretty simple.

~~~
randallsquared
It took you less than 60 seconds to install Java, compile Clojure, and start
the REPL? :) I haven't actually used (or installed) Clojure, but most of the
complaints (here and on proggit) appear to be by people who don't already know
Java, and so have to figure out enough of the Java build process to build
Clojure in the first place, even though a touted advantage of Clojure is that
you don't have to deal with Java.

~~~
golwengaud
I have no java (programming) experience, and it took me ~45 s:

#apt-get install closure

#closure

user=> (+ 2 2)

4

Most of that 45 s was waiting for apt-get.

Now it's not going to be this easy on platforms that don't have such nice
package management (e.g. Windows). Furthermore, Raphael_Amiard makes a good
point that there's a lot more infrastructure that has to go into web
application development (or any other kind of application development, for
that matter) than computing the sum of 2 and 2.

Nonetheless, it just doesn't seem that hard. At worst, put a "clojure
/path/to/project.lisp" in rc.local or equivalent.

(Caveat: my web development experience consists entirely of a couple of toy
projects I ran on my laptop for my own amusement. Take all this with a grain
of salt.)

EDITed for formatting.

~~~
Raphael_Amiard
There is _no_ cloJure package, neither on debian, neither on ubuntu repos, and
it's called clojure, not closure, so either you are full of shit, either you
installed closure common lisp, either you have non standart repos. This is a
scary example of how a post can be upvoted when _nobody_ in presence
understands what they are talking about.

~~~
mfukar
<http://bit.ly/bbzeYP>

and

<http://bit.ly/bB1sVG>

You could use those.

------
michaelfairley
"LAMP stack on Windows"?

~~~
briancarper
A perverse case of <http://en.wikipedia.org/wiki/RAS_syndrome>. Please forgive
me.

------
Tichy
But why is it so - why is there no user friendly LISP, why did PHP win
instead?

~~~
sigzero
PHP won for two reasons. PHP is easy to pick up and ISPs installed mod_php
which gave it good performance.

~~~
ramy_d
very true. Also, this "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)"

sometimes i feel lisp is like an exercise in barrier of entry. "Let's make an
awesome language that is as inaccessible out of the box as possible" not just
application wise. knowledge wise too.

~~~
aerique
I've replied to these arguments before on HN but it bears repeating: You
really do not have to use Emacs and Slime to get going with Common Lisp. There
are many options including using whatever you're already familiar with or just
plain Notepad.

It's unfortunate that people advocating Lisp also advocate Emacs+Slime as the
only option (although it is a good option).

~~~
asciilifeform
> using whatever you're already familiar with or just plain Notepad.

This is disastrously bad advice. This is how to create parentheses-phobia.

~~~
aerique
Oh please. Most programmers already somewhat decent editors like Textmate,
Notepad++ or Vim.

------
neovive
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.

------
code_duck
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?

------
jff
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.

------
rubinelli
I only see a "File not found" now. Did we break it?

------
c00p3r
Yes, it is that simple - you need some prepackaged basic stuff, like mysql
connector, xml, json parser and other commonly used modules. You need dumb-
easy install and integration with web server, and you need a quite large and
active community. In that case all cheap hostings will support it. PHP is
coming with all distros nowadays, so newbies and managers makes a choice
without thinking at all. _sudo yum install php-_ * - that is why.

btw, take the arc, add a buzzword (llvm) and easy api to write extensions with
fast FFI, and it will get as much hype as clojure - llvm is better buzzword
than jvm ^_^

