Subject: Re: O'reilly subjugated to the Lisp juggenaut (well, almost ;-) From: Erik Naggum <erik@naggum.no> Date: 14 Jan 2004 07:33:27 +0000 Newsgroups: comp.lang.lisp Message-ID: <3283054407117609KL2065E@naggum.no> * Damien Kick | I would also love to see the Lisp equivalent of something like | _Large-Scale C++ Software Design_; i.e. a book that treats the | subject of developing large-scale applications with Common Lisp, | though I would imagine that it is the many idiosyncracies of C++ and | the relative comprehensiveness of CL that have produced the need for | the former the lack of the later. The most important difference would be that a large-scale Common Lisp project would increasingly be written in an application-domain language, while a large-scale C++ project would continue to be written in C++. | [...] is there a unique CL angle to this subject or is it really the | more general design principle of less coupling leads to better | testability? There is a unique Common Lisp angle which I believe only Scheme will share with it: Instead of working in the language delivered to you by some vendor, you will generally build your own development system in possibly multiple stages and then compile the application at some point in this multi-stage build process, and it might not even be the last step that produces the application as users will see it. If you want to do anything remotely similar to this in any other environment, regardless of how tightly coupled it is with the core language, you will have to resort to a multitude of tools that are loosely coupled instead of closely integrated. Brilliant inventions like the m4 macro processor under Unix (enter Gary Larson-mode and visualize the /rejected/ m1, m2, and m3) demonstrate what happens to large-scale projects like sendmail. Common Lisp itself grew out of several large projects (even by today's standards), and the various Lisp machines demonstrated what happened in the Lisp world when they needed to grow their own tools. Many people complain about the difficulty of integrating Common Lisp with other programming languages, but in a large-scale project, you will have different people working in different languages to talk to the different parts of the real world that it would be even more work to include in the Common Lisp world, and they are free to build the interface any way they like. Small-scale projects face tougher restrictions in this regard because the same programmers will work in the different languages and the kind of scaffolding that you set up when building something that cannot support itself until it nears completion will appear to consume a lot of resources that some naïve people think ought not to be consumed, and so they use Perl or some other horrible crock, instead. In many important ways, Common Lisp becomes a different language when the project becomes large enough, but those who have found Common Lisp to be to their liking in small projects will need a bit of attitude readjustment to cope with the products of other people's small projects in their large project. Common Lisp works so well on a small scale that many people strongly resist the differences in a large-scale project, and much of Common Lisp's perception problem is that it works too well on a small scale. It is self-evident to any working brain that C++ does not work well on a small scale, so it is easy to dupe oneself into believing that it is because it works so well on a large scale, but there is no credible evidence that it in fact does work on a large scale. That people /make/ something work can never be evidence of anything. The Lisp world has an incredibly strong proof-of-concept advantage in the Lisp machines, which died for a lot of reasons unrelated to the scalability of the languages; a careful reading of the history will reveal that they died because they were /too successful/. (I have found that the worst possible thing you could do wrong in this world is to give people something that is more powerful than they are prepared to understand. Back when I believed that SGML was a brilliant idea, I did not understand that the people who were the intended users were completely unable to understand it, and that only those who were stupid enough not to realize it in time, would continue to work with it, and so they sat there with their excellent document production system with a clever markup system and thought it had to be useful for something grander, and now we have XML, a non-solution to a non-problem so brilliant that m4 no longer seems like a prank. We really need Gary Larson- style cartoons on the history of computer science.) The only other large-scale projects that one should look at when trying to see the Common Lisp way, is entire programming systems, like the complete Debian GNU/Linux development system. It is not the individual languages or tools or programs that make it up, but a general sense of the entire system. Common Lisp is how such a system would be if it were done right. (Those who think Windows is a usable system may of course feel free to believe that it is also an instance of a large-scale project, but the distance to how it would be if done right may just be too large to visualize.) -- Erik Naggum | Oslo, Norway Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.