The Lisp function has called itself again, it seems. Or maybe it calls itself often, and I have just failed to notice it until now (see http://xkcd.com/297/). In any case, Lisp is the programming language that programmers are taught to venerate. Ogle its perfection, its code and data dual nature, its simplicity, its elegance, and so on.
I wholeheartedly support bashing new concepts into programmer brains using Lisp. However, I fail to see its appeal for writing real software. Part of developing software systems involves programmers typing in code, reading that code, and re-reading that code 6 months later. Other programmers are going to come along and read that code, too. If you've ever looked at the source code for a large Lisp system, you may notice that its syntax does not lend itself to being understood. It is difficult to read, and even more difficult to interpret, because there is SO MUCH LIST PROCESSING GOING ON (Lisp = List Processing).
Lisp is difficult, in part because it represents new concepts to most programmer brains, but also in part because it's just tedious. Very nice that you can represent every data structure as a list or list of lists, but that doesn't mean you should. Just because it is possible to treat all things as exactly the same and have no keywords doesn't mean it makes for better software. I think it just makes for easier compilers. Lists just aren't a natural way to represent data to humans.
All that list processing produces code that is syntax-heavy (parentheses and list processing) in a language that essentially has no innate syntax. It's difficult to read, just like almost every Perl script is difficult to read. There's a lot of syntax happening. Why? Because it makes the compiler's job really easy. Ummm, why do I care if the compiler has an easy time of things? The compiler should work hard to make my life easy, and to make it possible for me to write better, more maintainable, more legible, simpler code. In Lisp, the programmer is responsible for constructing the entire AST himself.
Programming doesn't have to be difficult to be powerful. I reject that notion as the supposition of lesser programmers who've bought into a culture that worships Lisp and its kin. Learning Lisp may grow your brain (a good thing), but deploying real software in it seems like less of a good idea. To think that we've failed to come up with any more good programming language ideas in 40 years is ridiculous.
The Lisp culture reminds me of the "if you only knew what we knew" arguments that get trotted out by "national security" people every so often.
Tell you what... let's have a contest. You (hypothetical Lisp worshiper) implement a Twitter clone in Lisp, and I will implement it in a language of my choice (NOT Lisp, probably Erlang). You must provide an HTTP-based API in addition to a pleasing web UI. Both must support username/password authentication. You must be able to demonstrate support for 500,000 concurrent users with sustained message rates over 1000 messages/sec. You must store all messages. 50% of the users will have 50 followers. 35% will have 200 followers. 10% will have 1000 followers. 5% will have 10,000 followers.
When both systems are complete, we will note how many hours (roughly) it took to build each system, and how many lines of code (this is not always a good metric, but we won't abuse its relevance), and what deployment requirements there are to reach the scalability goals.
Then we will take a good programmer who has not programmed extensively in either language, and ask him to understand each set of source code and ask him to make some modifications. We'll subjectively analyze how things go in each system.
I think we will find that the non-Lisp system is less code, more intelligible, easier to extend, faster, and easier to deploy.
Lisp as a religion needs to die. Lisp as a set of interesting ideas worth learning should stay.
Technorati Tags:
programming, software, lisp
Recent Comments