Kicking and Screaming Towards Lisp
A great article, worthy of it’s own pullout (not just an anonymous del.icio.us bookmark link):
My point is that it may be too late to start with Lisp so you don’t have to reimplement all of its features. Because all of those new languages have already implemented them. At least what most people consider the important ones.
I imagine people will disagree with this view. People might say that although Java and C# have many of the features that made Lisp great, it doesn’t have the essence that makes Lisp still the best choice for discriminating programmers. That essence might include meta-programming facilities, or first-class closures, or macros.
Macros let you subsume more code into less code. Macros let you write more functionality with fewer lines. Macros let you abstract away boilerplate into new syntax.
But the corporate manager will say: if everyone writes their own syntax, my programmers can’t read each other’s code. So instead of having to learn a language once, they will have to learn a new language each time they approach a program for the first time. And the value of macros is lessened.
Code as data lets you manipulate code at runtime. It means you can optimize it, count it, store it, send it somewhere, and more importantly, write it in itself. The possibilities are endless.
But the corporate manager again has an answer: Java is already written. Why would I want to rewrite it? I have a program to develop—-and you’re worried about optimization? Let the folks at Sun worry about that. We’re not language developers!
And so do each of the features fall like dominoes. Either they hinder some unforeseen corporate best-practice, or they just aren’t really as powerful in that environment as one would really hope their expressive purity would like.
[source…]
…really great article talking about essential lispy-ness. C and C++ are dead to me (an interesting thing to say, and I’ll probably regret it :^). Java replaces C++ … C is OK, but it’s like adding salt to a dish- put it into a well-written library off to the side and write everything else in a different language that is ~easier~ or ~better~. The cases where machine efficiency outweighs development or maintenance efficiency are limited (and valuable!), but brutal machine-efficiency is steamrolling the less-people-efficient languages for many cases.
People seem to groove on Objective-C, I haven’t had a chance to use it and comment, but perhaps it strikes a better balance between people-efficiency and machine efficiency. Certainly any language that drives against people-efficience is now doomed to failure. I just hope we don’t go to drag+drop flowchart programming. :^)
16:54 CST | category / entries / links
permanent link | comments?