Women in Technology

Hear us Roar



Article:
  What I Hate About Your Programming Language
Subject:   Learn Common Lisp
Date:   2003-05-13 15:19:25
From:   anonymous2
The ultimate dynamic language--superb object system with incredible introspection facilities through the MOP, good commercial compilers (www.franz.com, www.lispworks.com, www.scieneer.com), good free compilers (www.cons.org/cmucl), the speed benefits of a typed language (if you use type declarations and declare the appropriate optimization level), the ability to patch running programs, first-class closures, hash-tables, lists, arrays, strings, etc., numbers never over flow, and so much more... The only thing to hate is that relatively few people truly know it.
Full Threads Newest First

Showing messages 1 through 5 of 5.

  • Learn Common Lisp
    2003-05-13 20:17:04  anonymous2 [View]

    I have to second this recommendation. I have not been fortunate enough to land a job writing in Lisp, but I regularly use it from within Emacs. More importantly, if you can understand the similarities between Paul Graham's book On Lisp (http://www.paulgraham.com/onlisp.html) and Andrei Alexandrescu's Modern C++ Design (http://www.moderncppdesign.com/), you are ready to program in any language.
    • Learn Common Lisp
      2003-05-14 05:21:27  anonymous2 [View]

      Just plain truth.
  • Learn Scheme!
    2003-05-14 01:15:56  anonymous2 [View]

    Scheme is a bit cleaner, isn't it?
  • Learn Common Lisp
    2003-05-14 07:16:23  anonymous2 [View]

    You forgot one thing: macros! To the programmers of other languages the word "macro" probably brings to mind something quite different. But lisp macros are an incredibly powerful abstraction tool.
  • Learn Common Lisp
    2003-05-14 07:39:06  anonymous2 [View]

    I agree that CL is very good. It's my first choice for most programs, and I'm familiar with a lot of choices.

    CL has one unusual strength that the earlier poster didn't mention: the syntax of CL programs ("Lots of Infernal Stupid Parentheses") makes it extremely easy for CL programs to manipulate CL program source as data (correctly, and without writing a parser). This makes program-writing programs extremely easy to implement. Even lowly one-liner macros end up being much more powerful and useful in CL than one would expect from experience in other languages, and more advanced uses are startlingly powerful. (One common example is to write one's own object system -- inheritance, polymorphism, encapsulation -- from scratch. It's easy to do this in a page or two of CL code, and before CLOS was standardized, it was quite common.)

    CL is not perfect, however. It suffers from the usual library weakness of languages with small user communities. The flipside of its dynamic nature -- things like the aforementioned ability to patch running programs -- is that there are various correctness checks and performance optimizations that the compiler can't make. It's pretty efficient, with good native compilers, but for various reasons (including GC and dynamic typing) it can sometimes be anywhere from annoying to impossible to get the last factor of two in portable performance relative to C/C++. And it's a fairly big language, which is pretty common and mostly uncontroversial these days, but which still provokes some friction with people who want something more like the austere elegance of Scheme.

    CL also has the weaknesses and strengths of an old language, since it has evolved since the 60s and since it was standardized starting in the 1980s. These weaknesses include various warts in its design (for backwards compatibility or because design tradeoffs looked different in 1987). The strengths include having gotten a lot of things right long ago, like GC by 1970 (?) and lexical closures by the mid-1970s. (It has been sort of interesting watching the semantics of other languages like Perl and Python recapitulate the evolution of Lisp toward GC and lexical closures.)

    So for small stable systems where microefficiency is a big issue, I might prefer C or C++ instead; for some things where ML's static type checking model is a good fit I might prefer ML instead (so e.g. I have no trouble understanding why many compiler writers like ML); but mainly I prefer CL. When I don't use CL the usual reason is that I'm working on a problem where suitable libraries or legacy code already exist in another language but not in CL.

    Incidentally, for even more free Lisp resources, see www.cliki.net.