9 ms·

A startup's "Why we use Lisp" story

113 points by zachbeane 17y ago

gaius 17y ago
This is the key point: I started programming in LISP way back in 1971 on a Univac 1108 mainframe and also implemented a 68000-based Lisp system (~50K lines of real-time assembly) for mobile-robotics use in 1983 - and so know my way around the language. All Lisp (or Smalltalk, or...) success stories I've read hinge on someone with an enormous amount of experience with the language. I'd argue that someone with that much experience could get the job done in (almost) any language. I'm surprised that someone with that much experience would put it down to language choice rather than deep knowledge of the problem domain.
- olavk 17y ago
  That is close to saying that all languages are equivalent given the same amount of experience. I don't buy that. For a specific task some languages may be better suited / more productive than other languages, even given equivalent levels of experience. I don't believe in a global linear scale of language power ("the blub theory"), but I do believe that some language may be better than others for a specific task given specific constraints. E.g. if I have equivalent levels of experience in C++ and Python, I'm pretty sure I can write small webapp quicker in Python. OTOH if the languages are very similar, like Python and Ruby, the level of experience is much more important that the relative strengths and weaknesses of the languages. Of course, it is seldom that you get that kind of fair comparison between two languages - usually everyone has a favorite language they know better than any other.
  - gaius 17y ago
    That is close to saying that all languages are equivalent given the same amount of experience. Not quite - there are a bunch of languages that are "up there" in terms of expressivity: Lisp, Smalltalk, Haskell, ML, etc. There's no data to say "learning Lisp will give you an enormous productivity boost". There is only data to say "people with 30 years experience in Lisp/Smalltalk/whatever tend to be very good programmers". And, well, duh. Also, if he had to do it in C, say, could he really not? Even if he needed to invoke Greenspun's Law in the process...
    - dmoney 17y ago
      Even if he needed to invoke Greenspun's Law in the process... The question is whether that always happens for a complex system. Because if it does, then every sufficiently advanced programmer is a lisp programmer.
  - coliveira 17y ago
    In some place I read that differences in languages could account for at most 30% of improvements in speed of development. This is an epsilon if compared to differences between programmers. Another issue is that, if you are talking about small-to-medium sized applications then clearly there is a difference in languages. For example, it is pretty clear that writing a script is easier in perl than in C, or writing a medium sized expert system is easier in LISP than in Pascal. However, if you consider large scale applications (100k+ LOC), then I don't believe there is any difference between writing in C, C++, Java, or Common LISP, as long as the programmer(s) have deep experience with the used language. Just notice that the language is not going to solve the large-scale problem by itself. As long as such language has tools for creating abstractions, the code will have about the same complexity no matter what. If that complexity will be encapsulated in simple concepts (structs and functions) or higher level concepts (closures and continuation) depends on the taste of the developers and the language used.
    - deleted 17y ago
      [deleted]
    - loup-vaillant 17y ago
      30% is an understatement. Think of the productivity gain when you go from assembly to C. Now, consider the fact (I do mean fact) that the jump from assembly to C and the jump from C to LISP are comparable. The choice of abstraction do matter. If you use weak ones, your productivity is taking a serious hit: your program will be bigger, more complex, and have more errors (squared). C++ abstractions, for instance, are incredibly weak. Take the function abstraction, which isn't even complete: you have no way to write anonymous functions the way you write literal integers[1]. Higher level concepts, as you call them, aren't more complicated than the "simple" ones. Often, they are just less familiar and more consistent. [1]: Anonymous functions should actually be called "literal functions": (fun x -> 7 x + 42) -- a literal function 357 -- a literal integer 2 + 3 -- expression which yields a integer f . g -- expression which yields a function Nothing "high order" about that. This is just acknowledging that functions are mathematical objects like any other.
  - chipsy 17y ago
    I am starting to arrive at my own conclusion to language power which is that if you already know the "$1,000,000 concepts" embedded in the language, the only things the language itself offers above that are dev environment and ecosystem improvements - better debugging features and tools, more libraries, more solutions to corner case problems, platform deployment options, etc. So features that are mostly implementation-dependent, like incremental development, static type checking, contracts, CPAN/gem/easy_install type code repositories, reference books and mailing list discussions, etc. are the things that give a language value. Exposing powerful key concepts(like common data structures, garbage collection, reflection, macro systems...) directly through the language is also a win but not something impossible to work around. To paraphrase a oft-abused quote, "every sufficiently complex program contains a Lisp." But that doesn't mean the conclusion is "start with Lisp, since you'll end up with one anyway." It may be that Ruby (for example) has a really cool library you want to use for a core part of your app, so you start writing the code in Ruby, and things are good and you make progress....and once you come across a problem requiring Lisp-type power, just by knowing how the solution would work in Lisp, you can usually devise a worse-is-better 80% solution that is right for your specific application. The final result may not be beautiful or pure, but it lets you do things incrementally without the up-front misgivings of "it would have saved so much time to start in Ruby..." tl;dr: Learn languages to learn concepts, but build applications in an "environmentally-friendly" way. Perceived "potential power" is not a good reason to sweat and strain to build apps in your favorite language when you could go over to the current "industry standard" and save yourself months of effort. On the other hand, nobody has an omniscient view of all languages and environments, hence people tend to stick with what they know....
- lispm 17y ago
  I would say that he has an enormous amount of experience with several languages. He lists on his webpage: "Programming languages used over the past 39-years include C/C++, Common Lisp/CLOS/MOP (and other Lisp varients), ALGOL, FORTRAN, PL/1, SNOBOL, numerous assembly languages, and others." So, he probably could have written it in C++ (or SNOBOL ;-) ), but he chose to do it in Lisp.
  - loup-vaillant 17y ago
    No, he could not have (short of bootstraping a Lisp system from C++). I, for one, have much more C++ experience than Ocaml experience. I am far more efficient with Ocaml: typically, my Ocaml programs are 3 to 5 times shorter, takes half the time to program, and almost no time to debug.
    - gridspy 17y ago
      I have 10 years of C++ experience, and 1 year of part-time Python experience. I needed to create a simple graph algorithm to find maximum Hamiltonian paths. It took me 1hr to get it running in Python and 6 hours to translate it to C++. It is amazing how much Python (and other high level languages such as lisp, Ocaml) allow you to focus on the problem you are solving not the irrelevant details of the solution.
- anonjon 17y ago
  All things being equal, lisp was in use much more back in the 70s and 80s than it was in the 90s or 00s. It makes sense for the majority of people who would think to use lisp to be a bit grayer.
  - lispm 17y ago
    Fortunately, since 2000, a new generation of young hackers has shown increased passion for Lisp.
    - sfk 17y ago
      Enthusiasm, yes, but where is the output? Usually, when I read about a Lisp success story, there's a paragraph: ... and we could not have done this without A, B, C ... by Edi Weitz. Lisp needs more people like him who actually release software instead of blogging about its virtues.
      - lispm 17y ago
        But you have seen the article that we are talking about? It is just such an output where the software is written in Lisp and the result is sold commercially. People have asked Jack to explain why he used Lisp for an embedded application. You can read the result in the linked article. The guy who has posted the story also has written a bunch of Lisp based internet applications. If you look among the hardcore Common Lisp users, quite a lot are writing software. The once that are blogging superficial stuff not so much. Read the stuff on planet.lisp.org - that's usually quite useful.
      - anonjon 17y ago
        Why do you assume people don't release software in Common Lisp? When you buy a piece of no one writes on the packaging "we did this in C++!" or "We did this in Java!" Why would you expect a big "Common Lisp!" sticker on the packaging? The deliverable is machine code, not source code. The customer doesn't care what the source is written in.
        17y ago
- dkersten 17y ago
  Heres why I like Lisp: I recently (~5 months ago) started using Clojure heavily and now find myself much more productive using it than using any of the languages that I have considerably more experience with (I used C++ almost exclusively for 4 years for hobby (mostly game related) projects and toy virtual machines/interpreters; Python for ~4 years for prototyping, web development and GUI development; Java for 2.5 years for server (non-web) development - total programming time including hobby, uni and professional = ~10 years). As an example, I'm very much interested in compilers, virtual machines, programming language design and such, so have been plying around with these in various languages over the years. I wrote my first toy language in VB; wrote a few interpreters, virtual machines and simple parsers in C++ and some parsers, interpreters and assembly code generators in Python; for uni, I implemented a parser and code generator (instruction selection, using maximal munch) in JavaCC - recently I wrote an assembly code generator in Clojure. It took me a weekend and it surpassed the power of anything[1] I'd written in VB, C++, Python or Java. Its flexible and can be easily be extended, its pretty smart and can do some basic optimisation (caching data in registers, function inlining...). I tried writing something similar in Python before, but gave up. My point is that I have much much deeper knowledge of C++, Python and Java, yet I was able to build something MORE complex and extensible in Clojure, in less time, even though I'd only been using it for a few months. Yes, my previous experience played some part in this, but I attribute most of it to the flexibility and power Lisp provides me through easy to use and powerful abstractions, flexible and convenient syntax and interactive development. [1] Of the same scale - any interpreter, code generator, compiler etc. I've written much more powerful systems, of course, but they are huge in comparison and took a lot lot longer than a weekend to write.
skilldrick 17y ago
I don't understand why a Lisp hacker wouldn't match parens properly when ending a parenthetical statement with a smiley: (commentless, of course :) Hasn't he seen xkcd: http://xkcd.com/541/ http://xkcd.com/541/ ?
- mbrubeck 17y ago
  If you do it the double-chinned XKCD way, it messes up your auto-balancing text editor.
  - loup-vaillant 17y ago
    …which you obviously use to write your e-mails.
    - LogicHoleFlaw 17y ago
      I use my text editor for typing everything. Scratch buffers are a wonderful thing.
    - BrandonM 17y ago
      Apparently you don't know anyone who spends 90% of their working time in emacs.
      - loup-vaillant 17y ago
        I do. :-(whoops, I don't : he uses the other editor).
  - skilldrick 17y ago
    Of course! I take it all back.
  - praptak 17y ago
    If you read XKCD and use an auto-balancing editor for plaintext then you should have no problems modding it to recognize emoticons.
mojuba 17y ago
Lisp is a beautiful language but I think the biggest problem with it is its proponents failing to explain the merits. I'm sorry, this post would have probably made a bit more sense 15 years ago, but definitely not now. > (a) Very fast development that is enabled by CL (e.g., everything from hash tables to string-operators to memory management is automatically included - there is nothing that is not included). Name a modern mainstream language that doesn't have these things. > (b) Excellent programming environments - e.g., parentheses-savvy editor. You haven't seen XCode, Delphi or MS Visual Studio, where, for example, you can jump to the definition of a symbol with "one click", allow interactive step-by-step debugging with variable watch, disassembly, stack trace, etc - I shouldn't really name all the things that are possible in a typical modern IDE. And I don't know any text editor which is not paren-savvy. > (c) Excellent compiler, especially with declarations, enables very fast code. A compiler which doesn't "enable very fast code" has no place under the sun nowadays. > (d) Excellent system stability with no random crashes at all. Very exciting, although GC-based languages (i.e. those usually lacking pointers) should not crash at all, or if they do crash that's a shame. Stability and robustness of your compiler and your runtime system shouldn't really be mentioned as a merit. If it doesn't meet stability standards, it shouldn't be released. > (e) Macros and all that. Finally getting to the point and you say "and all that"? Btw, "all that" includes unification of code and data - something no other language provides, let's say, idiomatically. This is an amazing feature, and in fact Lisp macros are Lisp macros thanks to just that - unification of code and data and symbolic nature of the language. Memory footprint: megabytes do matter because of the CPU cache. A 30,000 LOC program should take a few megabytes at most and fit a modern CPU cache entirely. Compared to a 50MB program the performance gain can be enormous.
- malkia 17y ago
  LW (I have LW6) is really great system, for coding, experimenting, and the CAPI user interface is platform-independent (almost, there are some differences, but you can handle them). I do use MSVC all the time at work, XCode occasionally at home, and have used Delphi quite a lot before my current work. But I also bought Lispworks Mac/Win32 versions, and I feel much more productive there. Why? Because I have listener, I can quickly recompile the current buffer (Ctrl+Shift+B), or the current enclosing function (Ctrl+Shift+C), or if I'm at the end of expression evaluate it (Alt+X E). I can keep recompiling the buffer, and all variables declared with defvar would retain their values, I can change object definitions on the fly. It's just easier to experiment. Weaknesses - I'm so much used to the MSVC debugging (I Actually used to be Turbo Debugger junkie in the past), that I miss that - it's simply not easy to debug in LW (or EMACS + slime + any other lisp). But do I need to debug that much more? No - I don't, but that could be because I'm yet at the amateur level.
idlewords 17y ago
"Excellent system stability with no random crashes at all" This holds for pretty much any language you care to use.
- aharrison 17y ago
  People keep saying that, and I can understand where they are coming from, but this isn't the case. Just yesterday, I managed to segfault python 2.6.something. I have no idea why (I really should have figured it out) but my hypothesis is that I freaked out the parser. It was vanilla python code; it should never segfault. I have had the same experience with the JVM: I once segfaulted the parser by incorporating a static string that was hundreds of lines long. Curiously, Eclipse "compiled" it just fine. Sometimes environments have bugs. If you need an underlying runtime that simply will not crash, using something tried and true may be at the top of your priority list. That might be overkill for most projects, but I can see a guy who wants something so robust he knows its his fault when it breaks.
  - Luyt 17y ago
    Could you post the code with which you were able to segfault Python 2.6? I succeeded in that only by using ctypes and messing up parameter passing.
    - aharrison 17y ago
      I wish I could. I was in the middle of a lab when I did it, and as I fixed it I thought "I should really save this and figure out why it is segfaulting." Alas, the lazy part of me prevailed and I just fixed it so I could demo the assignment. Next time I run into one of those issues I am going to write about it as an example for the argument I just made.
  - idlewords 17y ago
    So based on your experience (as a comp sci student, I'm assuming, based on your other comment), Python and the JVM are both 'crashy', but you don't happen to remember exactly why? Reminds me of a bunch of compiler bugs I found back in the day. Strangely the longer I program, the fewer of these compiler bugs I seem to be able to find.
motters 17y ago
Apparently iRobot also uses Lisp in an embedded context.
- jjwiseman 17y ago
  iRobot used to do embedded Lisp (back when they called themselves IS Robotics), but I haven't heard anything indicating that they still are. See http://lemonodor.com/archives/2004/08/l_mars_venus.html http://lemonodor.com/archives/2004/08/l_mars_venus.html They had L, their Lisp dialect, and Mars, the macro layer for doing robotics in L. The paper "L - A Common Lisp for Embedded Systems" is available at http://www.cs.cmu.edu/~chuck/pubpg/luv95.pdf http://www.cs.cmu.edu/~chuck/pubpg/luv95.pdf
  - motters 17y ago
    The last I heard Rod Brooks said all the pacbots software was written in Lisp.
zandorg 17y ago
A friend of mine keeps asking me to dump Lisp and "Get modern" with C#, and I try to explain why I prefer Lisp, but he won't accept it. It was Paul Graham's essay that encouraged me to try Lisp in 2005.
- gridspy 17y ago
  I'm just dreading the day that Microsoft decides that C# isn't modern enough and they want to sell a whole bunch of seats of Visual Studio (insert new name here)
  - icey 17y ago
    They release new versions of Visual Studio every few years, and C# is updated almost as regularly. C# / .net 4.0 will be released this year (as will Visual Studio 2010). The differences between C# 1.0 and 4.0 are enormous. Microsoft isn't shy about making changes to the language.
  - philwelch 17y ago
    They have an ML dialect called F# as well.
zck 17y ago
>(d) Excellent system stability with no random crashes at all. This is interesting, considering one of the main reasons Reddit switched from Lisp to Python was because it was crashing often.
- lispm 17y ago
  that was another Lisp implementation
vii 17y ago
Seems to me this discussion is missing one of the main points of the original post: a massive plug for an unfairly under-appreciated book: > "Let Over Lambda" > (which is really quite scary to read - I can't say that I understand > 100% of it - maybe 60% and I am very happy with that level of > comprehension) -- you end up with an enormously powerful set of > programming tools unlike anything else out there. I really like this book too and recommend it. http://letoverlambda.com/index.cl/toc http://letoverlambda.com/index.cl/toc

113 points by zachbeane 17y ago

gaius 17y ago

This is the key point: I started programming in LISP way back in 1971 on a Univac 1108 mainframe and also implemented a 68000-based Lisp system (~50K lines of real-time assembly) for mobile-robotics use in 1983 - and so know my way around the language. All Lisp (or Smalltalk, or...) success stories I've read hinge on someone with an enormous amount of experience with the language. I'd argue that someone with that much experience could get the job done in (almost) any language. I'm surprised that someone with that much experience would put it down to language choice rather than deep knowledge of the problem domain.

olavk 17y ago
That is close to saying that all languages are equivalent given the same amount of experience. I don't buy that. For a specific task some languages may be better suited / more productive than other languages, even given equivalent levels of experience. I don't believe in a global linear scale of language power ("the blub theory"), but I do believe that some language may be better than others for a specific task given specific constraints. E.g. if I have equivalent levels of experience in C++ and Python, I'm pretty sure I can write small webapp quicker in Python. OTOH if the languages are very similar, like Python and Ruby, the level of experience is much more important that the relative strengths and weaknesses of the languages. Of course, it is seldom that you get that kind of fair comparison between two languages - usually everyone has a favorite language they know better than any other.
- gaius 17y ago
  That is close to saying that all languages are equivalent given the same amount of experience. Not quite - there are a bunch of languages that are "up there" in terms of expressivity: Lisp, Smalltalk, Haskell, ML, etc. There's no data to say "learning Lisp will give you an enormous productivity boost". There is only data to say "people with 30 years experience in Lisp/Smalltalk/whatever tend to be very good programmers". And, well, duh. Also, if he had to do it in C, say, could he really not? Even if he needed to invoke Greenspun's Law in the process...
  - dmoney 17y ago
    Even if he needed to invoke Greenspun's Law in the process... The question is whether that always happens for a complex system. Because if it does, then every sufficiently advanced programmer is a lisp programmer.
- coliveira 17y ago
  In some place I read that differences in languages could account for at most 30% of improvements in speed of development. This is an epsilon if compared to differences between programmers. Another issue is that, if you are talking about small-to-medium sized applications then clearly there is a difference in languages. For example, it is pretty clear that writing a script is easier in perl than in C, or writing a medium sized expert system is easier in LISP than in Pascal. However, if you consider large scale applications (100k+ LOC), then I don't believe there is any difference between writing in C, C++, Java, or Common LISP, as long as the programmer(s) have deep experience with the used language. Just notice that the language is not going to solve the large-scale problem by itself. As long as such language has tools for creating abstractions, the code will have about the same complexity no matter what. If that complexity will be encapsulated in simple concepts (structs and functions) or higher level concepts (closures and continuation) depends on the taste of the developers and the language used.
  - deleted 17y ago
    [deleted]
  - loup-vaillant 17y ago
    30% is an understatement. Think of the productivity gain when you go from assembly to C. Now, consider the fact (I do mean fact) that the jump from assembly to C and the jump from C to LISP are comparable. The choice of abstraction do matter. If you use weak ones, your productivity is taking a serious hit: your program will be bigger, more complex, and have more errors (squared). C++ abstractions, for instance, are incredibly weak. Take the function abstraction, which isn't even complete: you have no way to write anonymous functions the way you write literal integers[1]. Higher level concepts, as you call them, aren't more complicated than the "simple" ones. Often, they are just less familiar and more consistent. [1]: Anonymous functions should actually be called "literal functions": (fun x -> 7 x + 42) -- a literal function 357 -- a literal integer 2 + 3 -- expression which yields a integer f . g -- expression which yields a function Nothing "high order" about that. This is just acknowledging that functions are mathematical objects like any other.
- chipsy 17y ago
  I am starting to arrive at my own conclusion to language power which is that if you already know the "$1,000,000 concepts" embedded in the language, the only things the language itself offers above that are dev environment and ecosystem improvements - better debugging features and tools, more libraries, more solutions to corner case problems, platform deployment options, etc. So features that are mostly implementation-dependent, like incremental development, static type checking, contracts, CPAN/gem/easy_install type code repositories, reference books and mailing list discussions, etc. are the things that give a language value. Exposing powerful key concepts(like common data structures, garbage collection, reflection, macro systems...) directly through the language is also a win but not something impossible to work around. To paraphrase a oft-abused quote, "every sufficiently complex program contains a Lisp." But that doesn't mean the conclusion is "start with Lisp, since you'll end up with one anyway." It may be that Ruby (for example) has a really cool library you want to use for a core part of your app, so you start writing the code in Ruby, and things are good and you make progress....and once you come across a problem requiring Lisp-type power, just by knowing how the solution would work in Lisp, you can usually devise a worse-is-better 80% solution that is right for your specific application. The final result may not be beautiful or pure, but it lets you do things incrementally without the up-front misgivings of "it would have saved so much time to start in Ruby..." tl;dr: Learn languages to learn concepts, but build applications in an "environmentally-friendly" way. Perceived "potential power" is not a good reason to sweat and strain to build apps in your favorite language when you could go over to the current "industry standard" and save yourself months of effort. On the other hand, nobody has an omniscient view of all languages and environments, hence people tend to stick with what they know....
lispm 17y ago
I would say that he has an enormous amount of experience with several languages. He lists on his webpage: "Programming languages used over the past 39-years include C/C++, Common Lisp/CLOS/MOP (and other Lisp varients), ALGOL, FORTRAN, PL/1, SNOBOL, numerous assembly languages, and others." So, he probably could have written it in C++ (or SNOBOL ;-) ), but he chose to do it in Lisp.
- loup-vaillant 17y ago
  No, he could not have (short of bootstraping a Lisp system from C++). I, for one, have much more C++ experience than Ocaml experience. I am far more efficient with Ocaml: typically, my Ocaml programs are 3 to 5 times shorter, takes half the time to program, and almost no time to debug.
  - gridspy 17y ago
    I have 10 years of C++ experience, and 1 year of part-time Python experience. I needed to create a simple graph algorithm to find maximum Hamiltonian paths. It took me 1hr to get it running in Python and 6 hours to translate it to C++. It is amazing how much Python (and other high level languages such as lisp, Ocaml) allow you to focus on the problem you are solving not the irrelevant details of the solution.
anonjon 17y ago
All things being equal, lisp was in use much more back in the 70s and 80s than it was in the 90s or 00s. It makes sense for the majority of people who would think to use lisp to be a bit grayer.
- lispm 17y ago
  Fortunately, since 2000, a new generation of young hackers has shown increased passion for Lisp.
  - sfk 17y ago
    Enthusiasm, yes, but where is the output? Usually, when I read about a Lisp success story, there's a paragraph: ... and we could not have done this without A, B, C ... by Edi Weitz. Lisp needs more people like him who actually release software instead of blogging about its virtues.
    - lispm 17y ago
      But you have seen the article that we are talking about? It is just such an output where the software is written in Lisp and the result is sold commercially. People have asked Jack to explain why he used Lisp for an embedded application. You can read the result in the linked article. The guy who has posted the story also has written a bunch of Lisp based internet applications. If you look among the hardcore Common Lisp users, quite a lot are writing software. The once that are blogging superficial stuff not so much. Read the stuff on planet.lisp.org - that's usually quite useful.
    - anonjon 17y ago
      Why do you assume people don't release software in Common Lisp? When you buy a piece of no one writes on the packaging "we did this in C++!" or "We did this in Java!" Why would you expect a big "Common Lisp!" sticker on the packaging? The deliverable is machine code, not source code. The customer doesn't care what the source is written in.
      - 17y ago
dkersten 17y ago
Heres why I like Lisp: I recently (~5 months ago) started using Clojure heavily and now find myself much more productive using it than using any of the languages that I have considerably more experience with (I used C++ almost exclusively for 4 years for hobby (mostly game related) projects and toy virtual machines/interpreters; Python for ~4 years for prototyping, web development and GUI development; Java for 2.5 years for server (non-web) development - total programming time including hobby, uni and professional = ~10 years). As an example, I'm very much interested in compilers, virtual machines, programming language design and such, so have been plying around with these in various languages over the years. I wrote my first toy language in VB; wrote a few interpreters, virtual machines and simple parsers in C++ and some parsers, interpreters and assembly code generators in Python; for uni, I implemented a parser and code generator (instruction selection, using maximal munch) in JavaCC - recently I wrote an assembly code generator in Clojure. It took me a weekend and it surpassed the power of anything[1] I'd written in VB, C++, Python or Java. Its flexible and can be easily be extended, its pretty smart and can do some basic optimisation (caching data in registers, function inlining...). I tried writing something similar in Python before, but gave up. My point is that I have much much deeper knowledge of C++, Python and Java, yet I was able to build something MORE complex and extensible in Clojure, in less time, even though I'd only been using it for a few months. Yes, my previous experience played some part in this, but I attribute most of it to the flexibility and power Lisp provides me through easy to use and powerful abstractions, flexible and convenient syntax and interactive development. [1] Of the same scale - any interpreter, code generator, compiler etc. I've written much more powerful systems, of course, but they are huge in comparison and took a lot lot longer than a weekend to write.

skilldrick 17y ago

I don't understand why a Lisp hacker wouldn't match parens properly when ending a parenthetical statement with a smiley: (commentless, of course :) Hasn't he seen xkcd: http://xkcd.com/541/ http://xkcd.com/541/ ?

mbrubeck 17y ago
If you do it the double-chinned XKCD way, it messes up your auto-balancing text editor.
- loup-vaillant 17y ago
  …which you obviously use to write your e-mails.
  - LogicHoleFlaw 17y ago
    I use my text editor for typing everything. Scratch buffers are a wonderful thing.
  - BrandonM 17y ago
    Apparently you don't know anyone who spends 90% of their working time in emacs.
    - loup-vaillant 17y ago
      I do. :-(whoops, I don't : he uses the other editor).
- skilldrick 17y ago
  Of course! I take it all back.
- praptak 17y ago
  If you read XKCD and use an auto-balancing editor for plaintext then you should have no problems modding it to recognize emoticons.

mojuba 17y ago

Lisp is a beautiful language but I think the biggest problem with it is its proponents failing to explain the merits. I'm sorry, this post would have probably made a bit more sense 15 years ago, but definitely not now. > (a) Very fast development that is enabled by CL (e.g., everything from hash tables to string-operators to memory management is automatically included - there is nothing that is not included). Name a modern mainstream language that doesn't have these things. > (b) Excellent programming environments - e.g., parentheses-savvy editor. You haven't seen XCode, Delphi or MS Visual Studio, where, for example, you can jump to the definition of a symbol with "one click", allow interactive step-by-step debugging with variable watch, disassembly, stack trace, etc - I shouldn't really name all the things that are possible in a typical modern IDE. And I don't know any text editor which is not paren-savvy. > (c) Excellent compiler, especially with declarations, enables very fast code. A compiler which doesn't "enable very fast code" has no place under the sun nowadays. > (d) Excellent system stability with no random crashes at all. Very exciting, although GC-based languages (i.e. those usually lacking pointers) should not crash at all, or if they do crash that's a shame. Stability and robustness of your compiler and your runtime system shouldn't really be mentioned as a merit. If it doesn't meet stability standards, it shouldn't be released. > (e) Macros and all that. Finally getting to the point and you say "and all that"? Btw, "all that" includes unification of code and data - something no other language provides, let's say, idiomatically. This is an amazing feature, and in fact Lisp macros are Lisp macros thanks to just that - unification of code and data and symbolic nature of the language. Memory footprint: megabytes do matter because of the CPU cache. A 30,000 LOC program should take a few megabytes at most and fit a modern CPU cache entirely. Compared to a 50MB program the performance gain can be enormous.

malkia 17y ago
LW (I have LW6) is really great system, for coding, experimenting, and the CAPI user interface is platform-independent (almost, there are some differences, but you can handle them). I do use MSVC all the time at work, XCode occasionally at home, and have used Delphi quite a lot before my current work. But I also bought Lispworks Mac/Win32 versions, and I feel much more productive there. Why? Because I have listener, I can quickly recompile the current buffer (Ctrl+Shift+B), or the current enclosing function (Ctrl+Shift+C), or if I'm at the end of expression evaluate it (Alt+X E). I can keep recompiling the buffer, and all variables declared with defvar would retain their values, I can change object definitions on the fly. It's just easier to experiment. Weaknesses - I'm so much used to the MSVC debugging (I Actually used to be Turbo Debugger junkie in the past), that I miss that - it's simply not easy to debug in LW (or EMACS + slime + any other lisp). But do I need to debug that much more? No - I don't, but that could be because I'm yet at the amateur level.

idlewords 17y ago

"Excellent system stability with no random crashes at all" This holds for pretty much any language you care to use.

aharrison 17y ago
People keep saying that, and I can understand where they are coming from, but this isn't the case. Just yesterday, I managed to segfault python 2.6.something. I have no idea why (I really should have figured it out) but my hypothesis is that I freaked out the parser. It was vanilla python code; it should never segfault. I have had the same experience with the JVM: I once segfaulted the parser by incorporating a static string that was hundreds of lines long. Curiously, Eclipse "compiled" it just fine. Sometimes environments have bugs. If you need an underlying runtime that simply will not crash, using something tried and true may be at the top of your priority list. That might be overkill for most projects, but I can see a guy who wants something so robust he knows its his fault when it breaks.
- Luyt 17y ago
  Could you post the code with which you were able to segfault Python 2.6? I succeeded in that only by using ctypes and messing up parameter passing.
  - aharrison 17y ago
    I wish I could. I was in the middle of a lab when I did it, and as I fixed it I thought "I should really save this and figure out why it is segfaulting." Alas, the lazy part of me prevailed and I just fixed it so I could demo the assignment. Next time I run into one of those issues I am going to write about it as an example for the argument I just made.
- idlewords 17y ago
  So based on your experience (as a comp sci student, I'm assuming, based on your other comment), Python and the JVM are both 'crashy', but you don't happen to remember exactly why? Reminds me of a bunch of compiler bugs I found back in the day. Strangely the longer I program, the fewer of these compiler bugs I seem to be able to find.

motters 17y ago

Apparently iRobot also uses Lisp in an embedded context.

jjwiseman 17y ago
iRobot used to do embedded Lisp (back when they called themselves IS Robotics), but I haven't heard anything indicating that they still are. See http://lemonodor.com/archives/2004/08/l_mars_venus.html http://lemonodor.com/archives/2004/08/l_mars_venus.html They had L, their Lisp dialect, and Mars, the macro layer for doing robotics in L. The paper "L - A Common Lisp for Embedded Systems" is available at http://www.cs.cmu.edu/~chuck/pubpg/luv95.pdf http://www.cs.cmu.edu/~chuck/pubpg/luv95.pdf
- motters 17y ago
  The last I heard Rod Brooks said all the pacbots software was written in Lisp.

zandorg 17y ago

A friend of mine keeps asking me to dump Lisp and "Get modern" with C#, and I try to explain why I prefer Lisp, but he won't accept it. It was Paul Graham's essay that encouraged me to try Lisp in 2005.

gridspy 17y ago
I'm just dreading the day that Microsoft decides that C# isn't modern enough and they want to sell a whole bunch of seats of Visual Studio (insert new name here)
- icey 17y ago
  They release new versions of Visual Studio every few years, and C# is updated almost as regularly. C# / .net 4.0 will be released this year (as will Visual Studio 2010). The differences between C# 1.0 and 4.0 are enormous. Microsoft isn't shy about making changes to the language.
- philwelch 17y ago
  They have an ML dialect called F# as well.

zck 17y ago

>(d) Excellent system stability with no random crashes at all. This is interesting, considering one of the main reasons Reddit switched from Lisp to Python was because it was crashing often.

lispm 17y ago
that was another Lisp implementation

vii 17y ago

Seems to me this discussion is missing one of the main points of the original post: a massive plug for an unfairly under-appreciated book: > "Let Over Lambda" > (which is really quite scary to read - I can't say that I understand > 100% of it - maybe 60% and I am very happy with that level of > comprehension) -- you end up with an enormously powerful set of > programming tools unlike anything else out there. I really like this book too and recommend it. http://letoverlambda.com/index.cl/toc http://letoverlambda.com/index.cl/toc