Lisp for the Web - Tutorial(adampetersen.se)
adampetersen.se
Lisp for the Web - Tutorial
http://www.adampetersen.se/articles/lispweb.htm
4 comments
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.
The interesting thing seems to be that he is achieving framework-like productivity by using mere libraries. That shows some power.
It's interesting, though quite old (I think Hunchentoot's API changed since the article was published).
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.
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.
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...
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...
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:
Edit. Another example: a stack based calculator.
def counter(i)
puts "the counter is #{i}"
link("increase") { counter(i+1) }
link("decrease") { counter(i-1) }
end
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
I think you are really just picking an easy target with JavaScript. I hope that kind of analysis doesn't hold for other languages.
I am in complete agreement that the code re-use needs to be efficient, and that sometimes I spend more time looking for re-usable code then it would take to implement it myself. I was using Rails as an example. Sure, I have my problems with the libraries I use, but overall they help me get 10x the work done that I would if I didn't have them at my disposal.
I think the future of programming languages is: those that enable the easiest code re-use will gain a huge advantage. There will be cross-language tools like github that all languages can use, but if I were to design a language that 1 principle would always be favored.
I am in complete agreement that the code re-use needs to be efficient, and that sometimes I spend more time looking for re-usable code then it would take to implement it myself. I was using Rails as an example. Sure, I have my problems with the libraries I use, but overall they help me get 10x the work done that I would if I didn't have them at my disposal.
I think the future of programming languages is: those that enable the easiest code re-use will gain a huge advantage. There will be cross-language tools like github that all languages can use, but if I were to design a language that 1 principle would always be favored.
"... I am coming to think that the more accessible a language is for just anyone to use, we get lesser quality shared code. ..."
"C" is pretty accessible.
"C" is pretty accessible.
Should we stick to Java or C/C++ then?
that's something you could do, but you don't have to. There is a reason many successful programming languages are backwards combitable (a word, ironically enough, not in the android dictionary). You can use scala or groovy to do the development.