Fri, 17 Sep 2010 20:47:51 GMT
Its bloated, its old, it has only few common modern extensions, it can run code from the 1960s. Things that can be said about Common Lisp. I already heard people recommend to "forget about Common Lisp" and use one of the shiny (new) other lisp dialects.
Still, I prefer Common Lisp to others.
Well, firstly of course, the mighty object system, the CLOS, is one reason for me to do. Few other languages have an object system so versatile and still so easy to deal with, and so well-optimized. I saw QT implementing its own C++-Preprocessor to have proper signal-passing-mechanisms, and the GLib doing similar things programmatically. Well, CL has it.
And one reason why I prefer it especially to Clojure: It encourages functional programming, but does not try to enforce it. Sometimes, a statefull loop is the easiest way to express something. Purely functional programming is - in my opinion - useful when I want to have formally verified code using strong type-systems, because thats something I am willing to put more effort into. And of course, good functional code can look pretty. But I dont share the ideology of everything having to be functional without any further use.
Well, with purely functional programming, there is a major lack of Common Lisp: When really programming purely functional, lazy evaluation is something desirable (its also desirable in other situations). There are some projects trying to implement lazy evaluation, but of course thats extremely hard without having to re-implement half of the language. Maybe that one will stay a lack of CL. But maybe not. At least lazy lists are not a real problem.
Something similar to this problem are continuations which also appear to be hard to implement - but there is a library, called cl-cont, which has some minor limitations but works.
For a larger community, the main problem of Common Lisp, I think, is the lack of libraries. With the many new "standards" that evolve every day, with the many new programming libraries doing magic that is not portable, it is hard to stay up to date. The IT-World changes every day, so software that isnt maintained will soon be deprecated.
And here is the one major advantage of Common Lisp: It is a stable standard. This is sometimes criticized, but in my opinion, thats a major advantage. Common Lisp offers a lot of high-level and low-level-features, there is one CL for almost every platform, and still its a standard that has been stable for a long time and is not likely to change.
But even though the ANSI-Standard hasnt changed, there are a few extensions that are de-facto-standards which are supported by vitally every implementation. For example gray-streams, the metaobject protocol and the common foreign function interface. And there are some portable libraries for threads, weak references, file access and sockets.
Any of these extensions defines as much as necessary, but not more. Most features that one may want can be implemented by the mighty macro system. Just today, I read about a new project "SPARK" on reddit - well, some nice ideas, and I hope that this project will achieve its aims (but to be honest, I doubt it). One idea mentioned is special syntax for regular expressions - something that can also be done comparably easy in Common Lisp, using reader macros.
Maybe also a major problem of Common Lisp: You can do almost everything. Therefore, there is no need for extending the standard, which is why some API-designs appear very old-fashioned.
But I prefer stable old-fashioned but sufficient API to API that constantly changes.
Still, I prefer Common Lisp to others.
Well, firstly of course, the mighty object system, the CLOS, is one reason for me to do. Few other languages have an object system so versatile and still so easy to deal with, and so well-optimized. I saw QT implementing its own C++-Preprocessor to have proper signal-passing-mechanisms, and the GLib doing similar things programmatically. Well, CL has it.
And one reason why I prefer it especially to Clojure: It encourages functional programming, but does not try to enforce it. Sometimes, a statefull loop is the easiest way to express something. Purely functional programming is - in my opinion - useful when I want to have formally verified code using strong type-systems, because thats something I am willing to put more effort into. And of course, good functional code can look pretty. But I dont share the ideology of everything having to be functional without any further use.
Well, with purely functional programming, there is a major lack of Common Lisp: When really programming purely functional, lazy evaluation is something desirable (its also desirable in other situations). There are some projects trying to implement lazy evaluation, but of course thats extremely hard without having to re-implement half of the language. Maybe that one will stay a lack of CL. But maybe not. At least lazy lists are not a real problem.
Something similar to this problem are continuations which also appear to be hard to implement - but there is a library, called cl-cont, which has some minor limitations but works.
For a larger community, the main problem of Common Lisp, I think, is the lack of libraries. With the many new "standards" that evolve every day, with the many new programming libraries doing magic that is not portable, it is hard to stay up to date. The IT-World changes every day, so software that isnt maintained will soon be deprecated.
And here is the one major advantage of Common Lisp: It is a stable standard. This is sometimes criticized, but in my opinion, thats a major advantage. Common Lisp offers a lot of high-level and low-level-features, there is one CL for almost every platform, and still its a standard that has been stable for a long time and is not likely to change.
But even though the ANSI-Standard hasnt changed, there are a few extensions that are de-facto-standards which are supported by vitally every implementation. For example gray-streams, the metaobject protocol and the common foreign function interface. And there are some portable libraries for threads, weak references, file access and sockets.
Any of these extensions defines as much as necessary, but not more. Most features that one may want can be implemented by the mighty macro system. Just today, I read about a new project "SPARK" on reddit - well, some nice ideas, and I hope that this project will achieve its aims (but to be honest, I doubt it). One idea mentioned is special syntax for regular expressions - something that can also be done comparably easy in Common Lisp, using reader macros.
Maybe also a major problem of Common Lisp: You can do almost everything. Therefore, there is no need for extending the standard, which is why some API-designs appear very old-fashioned.
But I prefer stable old-fashioned but sufficient API to API that constantly changes.