
Paul Graham: Lisp in Web-Based Applications (2001) - bkudria
http://lib.store.yahoo.net/lib/paulgraham/bbnexcerpts.txt
======
helium
Counterpoint: Use any language you want, as long as you keep in mind that you
might have to re-write libraries that are available to you in more mainstream
languages or use inferior or incomplete alternatives.

On many projects this isn't as much of a problem, but I think it's dangerous
to assume that one can easily use 'any language' when developing web-based
software.

~~~
dchest
This is not a counterpoint. Actually, I think it's a point of the article: use
any language that better suits your needs. If your web app needs a library
that's not available in language A, use language B. Or mix languages -- write
feature X in language A, and feature Y in language B. The point is -- you can
do whatever you want, as you control the environment, unlike with desktop
apps.

See, for example, my comment in this thread:
<http://news.ycombinator.com/item?id=595513>

~~~
Retric
Note the 2001. I think his point had more to do with a lack of library's
making any powerful language useful. Ruby on rails vs Lisp is not really in
favor of lisp, but there is a reason nobody has good C web frameworks.

PS: Which is something to think about, if you are spending as much money on HW
as Google it might be a good idea to use C or other fast but hard to write
language for some of your core functions.

~~~
wheels
Well, in 2001 the hot web languages were Perl and PHP and CPAN was already
riding high.

I think this argument in some ways hinges on how far from the tree you're
falling. If you're doing essentially a variation on a common theme, you'll be
the fastest by picking a language where the bulk of the work is already done
for you in a variety of reusable modules. It'd have to be a really poor
language for its badness to outweigh having most of the work done for you up
front.

If, however, you're starting from scratch on something relatively novel, e.g.
where Viaweb was in _1996_ (and not so much in 2001), then it's true, you
should write in the language that fits the bill rather than following the
course of momentum.

One proviso I would add there though is that Lisp is in the position of being
fairly mature _and_ non-traditional, unlike many flavor-of-the-weeks. There
are many pains to be found in using tools which haven't stabilized yet, even
if they do have a gee-whiz-bang factor.

As to your postscript, Google does also extensively use C++; I think that's
still fairly common in high-performance stuff at the lower levels.

------
pmarin
If you have curiosity, many of these ideas are implemented in Arc:

Macros for generating HTML: <http://arcfn.com/doc/html.html>

Closures Simulate Subroutines: <http://arcfn.com/doc/srv.html>

~~~
vegashacker
Does someone know offhand why these HTML generators are macros and not just
functions? If I need to RTFSC that's fine, but thought I'd ask in case it's a
quick answer.

~~~
pmarin
Just try to imitate the behaviour of this library in your favorite language. I
tried in Tcl, simulating macros with upvar, uplevel and even with sugar and is
not easy to get the same result.

<http://tverdeforge.googlepages.com/ahtml.tcl.txt>

~~~
vegashacker
Not sure I buy it. My favorite language is Scheme (specifically, PLT Scheme).
You'll find no macros below:

    
    
      (define (whitepage . content)
        `(html (body ,@content)))
    
      (define (para)
        `(p))
    
      (define (link prose url)
        `(a ((href ,url)) ,prose))
    
      (define (prbold text)
        `(strong ,text))
    

So the example from the Arc link

    
    
      (whitepage "Hello world!" (para) (link "Click here" "http://news.ycombinator.com")
                 "for" (prbold "more stuff"))
    

yields

    
    
      (html
       (body
        "Hello world!"
        (p)
        (a ((href "http://news.ycombinator.com")) "Click here")
        "for"
        (strong "more stuff")))
    

which is a valid expression that PLT's web server will render as a web page.

~~~
gms
Judging by the HTML macros he talks about in ANSI Common Lisp, they had to be
macros since they output HTML to file using a bunch of FORMAT calls. Since
side-effects were involved and the calls had to be evaluated at specific
points before and after other such calls, they had to be macros.

~~~
vegashacker
Ah ha! Thanks, gms. But this brings us to the question... are we getting
anything by using side-effecty print statements to make web pages? I don't see
it. I think I vastly prefer building up my markup functionally, and then
handing it off to the web server when done. Plus, with the PLT way, you avoid
writing macros. And a wise man once wrote, "It's considered to be bad style to
use [macros] when they're not necessary." ;)

Okay...I'll leave my "Are we getting anything" question there, but it probably
shouldn't be answered. Or at least not here. It's essentially the pure-
functional versus side-effect debate. To be fair, you get benefits from both,
and both have downsides that the others are better at.

~~~
gms
Yes I prefer your approach too (I use a similar approach with the Elisp I use
to publish posts on my blog). You are also right that one shouldn't use a
macro where a function would do.

When looking at PG's approach in ACL, it's worth remembering that he came up
with it more than 10 years ago, and consider it in that context. The
surrounding ecosystem for web development was a lot more primitive back then
(which serves to highlight how impressive his idea is/was).

------
stonemetal
I find the argument rather faulty. If you found your own company where does
this "strong bias" to write software in the same language as the OS come
from(just about every language out there has FFI to C so system libraries
should be accessible)? If I am now writing Web software, I am now writing an
application that runs on an OS that is primarily written in C so why does this
"strong bias" magically disappear?

~~~
jerf
"(just about every language out there has FFI to C so system libraries should
be accessible)"

Just about every language _NOW_ has a good FFI to C. Subtract several years
for when that essay was written, then subtract ten years for when the
statement is set in, and you'll encounter a different world.

 _Today_ there's no great reason not to write your desktop app in PyQT or
Clojure or on top of XULRunner. (Although I'd point out that surprisingly few
people have noticed this!) ViaWeb was born into a different world. I didn't do
much desktop programming in the 1996 timeframe, but you did not have many
choices, especially if you were a student that couldn't drop ~$1000
2009-dollars into a programming language environment. (Now my new
supercomputer-laptop costs less than that and superior environments are free.
Vive la progress!) A couple that weren't C and, as it turns out, all doomed to
be unsupported within a few years anyhow, like Delphi. I talk about 1996
because it's when I got into the game; the essay is a talk given in 2001 which
means "ten years ago" is 1991.

------
10ren
_By looking at the way these users modified our built-in templates, we knew
what we needed to add to them._

Big companies outsource their R&D like this too, letting startups detect
problems and solve them. Then the big corp. buys that startup (or copies it),
and absorbs the solution into the platform, so the platform is constantly
improving. It's a great thing for users.

------
JabavuAdams
Continuation passing style: "Do this, then go here".

------
Zarathu
PG is a Lisp fanboy.

And before you down-vote this... well, I suppose I deserve it. Carry on.

