
Lisp for the Web - Tutorial - _grrr
http://www.adampetersen.se/articles/lispweb.htm
======
gregwebs
article is from 2008.

I do web development professionally in Rails and am doing a side project in
Haskell. I would have been done in a fraction of the time in Rails, but I
wouldn't have become a better programmer. Unfortunately it doesn't matter that
much how great your language is and even if it has some of the basics of web
development down well. At the end of the day it is really about how much
existing code can be quickly reused.

~~~
Xurinos
_At the end of the day it is really about how much existing code can be
quickly reused._

I used to think this was true, and then after I became a bit experienced with
web development, I realized that the bulk of code (JavaScript, in particular)
released for public use ("reusable") is garbage. Complete, utter garbage. Poor
APIs, terrible abstractions, namespace contamination, a lot of assumptions
that those packages are the only ones in use.

Yes, you can slap something together quickly with the bits of turds available
online, but when it comes to customization and fine-tuning, you will either
spend a lot of time undoing half of what some other developer did with their
package or writing one of your own. For writing my own widgets, tools, and
frameworks, I want a great language. And when I build tools with a great
language AND with a good language design approach (it takes both), I have
things I can reuse.

More available reusable code is not an advantage. I am coming to think that
the more accessible a language is for just anyone to use, we get lesser
quality shared code.

There are gems, for sure -- I will happily name jQuery as an excellent,
extensible framework. A lot of the community's jQuery plugins, on the other
hand...

~~~
jules
I agree, better tools are often very quick to write. I'll plug what I think is
a lovely piece of code now ;) Here is a tiny toy Ruby framework inspired by
Arc <https://github.com/julesjacobs/Raamwerk> (29 loc, if you don't count
blank and end lines). In the examples you can see that even though the
framework is a toy you can write interesting applications much more concisely
and logically than with e.g. Rails. For example a page that displays a
counter, and a link to increase the counter and a link to decrease the
counter:

    
    
        def counter(i)
          puts "the counter is #{i}"
          link("increase") { counter(i+1) }
          link("decrease") { counter(i-1) }
        end
    

The quality of the code you're reusing is much more important than the
quantity.

Edit. Another example: a stack based calculator.

    
    
        def calc(stack)
          tag(:p){ puts stack }
          %w{+ - * /}.each do |op|
            link(op){ calc([stack[0].send(op, stack[1])] + stack[2..-1]) }
          end
          10.times{|n| link(n){ calc([n] + stack) } }
        end
    

Video demonstration: <http://dl.dropbox.com/u/388822/calculator.avi>

------
xarch
It's interesting, though quite old (I think Hunchentoot's API changed since
the article was published).

------
Leynos
This actually does a really good job of explaining to me why clisp macros are
important. Something that I haven't really been able to absorb from any of the
other tutorials I've read. Thanks.

------
bergie
The interesting thing seems to be that he is achieving framework-like
productivity by using mere libraries. That shows some power.

