6 ms·

What learning Lisp taught me about other languages

32 points by mqt 19y ago

ddelony 19y ago
I've played with Lisp a little, and I'm amazed at how many complex things such as Emacs can be built from a few simple axioms.
- tptacek 19y ago
  A few simple axioms and a whole lot of C code.
  - brlewis 19y ago
    apt-cache show emacs22-el Installed-Size: 13080 The wonders of emacs are embodied for the most part in the most primitive Lisp dialect still in widespread use. Emacs Lisp doesn't even have lexical scoping, and it's still amazing. Not that I have anything against C, when it's used to bootstrap a Lisp implementation, at least.
tptacek 19y ago
I did not like this post. Of his four insights: * two of them are common to almost all high-level languages (Python, Ruby, and Tcl all have regular syntax that deliberately improves on C/C++, and dynamic types practically define "scripting" languages), * one of them is spurious (Visual Studio programmers don't care how much precious memory they waste as long as Intellisense keeps working, and plenty of C programmers use vim), and * the only insight here that has enough valence to be interesting --- on the scoping and binding rules of variables --- is covered so superficially that it's hard to tell whether the author actually understands what he's saying. You mean "learning lisp" didn't teach you enough to evaluate Python's closures, or Ruby's block/lambda idiom? This article won't be a total loss if it prompts somebody to write a more knowledgeable and useful article on the lessons a Lisp education brings to bear on modern languages. I'd love to read that.
- nazgulnarsil 19y ago
  I agree. He's seeming to gloss over the fact that the whole point of higher level languages is that they exchange some simplicity for power.
  - eb 19y ago
    No, the point of high-level languages is that you exchange speed for simplicity and power.
    - tptacek 19y ago
      You forgot the words "the illusion of".
    - nazgulnarsil 19y ago
      speed and simplicity are roughly interchangeable.
      - gruseom 19y ago
        If that were true, we'd all be writing fast, simple programs in assembler.
- gruseom 19y ago
  I'm interested in your critique but it seems to me you've misrepresented two of his points. #2 compares Lisp's minimalism to any language with more complicated syntax, not just C/C++. So I don't think this insight is "common to almost all high-level languages". (The idiosyncracies he mentions are from Ruby and Python.) #3 isn't about Visual Studio's memory usage, it's about it being slow [1]. When I work in C#, many times a day VS is unresponsive enough to break my flow, so much so that I go off and check a website like this one (it's better than sitting there feeling angry). This is disastrous in a programming tool, so I don't think the author is being precious. (There's also a deeper point to be made here, which is that the ultra-interactiveness of Lisp and Smalltalk environments is so different from what one experiences in the likes of Visual Studio that it makes a qualitative difference in one's programming.) There may even be a little more to #1 than you give him. "In Lisp it feels like types are a tool I can employ when I need it" refers not just to static-vs-dynamic typing but also to the fact that one can easily write functions without having to make up types to hang them on (i.e. programs don't have to be organized into object models). That's not true of all high-level languges. I share your desire to read more knowledgeable and useful writing on this topic. But I did like the post because it's clearly coming from real experience. [1] Admittedly, much of this slowness is due to the add-in bizarrely known as Resharper. But that's Visual Studio's fault too - for being so backward and provincial that it needs a humongous third-party workaround to achieve bare tolerability even compared to Java.
andrewparker 19y ago
I don't get all the love for lisp. In my lisp experience I remember being in debugging hell trying to count out between 18 and 19 close-parentheses to add some parameter I'd forgotten. Bad memories.
- tl 19y ago
  Most text editors have some sort of parenthesis matching highlighter. I don't usually find counting () to be that difficult. I see that the greater problem is that lisp (and a lot of languages that empower functional programming ideals), undermine the idea of lines of code that other tools like source control and debuggers take advantage of.
- xlnt 19y ago
  if you're having that much trouble debugging paren, put them all on their own lines and use indentation. then it'll be easy enough to fix.
  - brlewis 19y ago
    If he used an editor that auto-indented parens, he would probably be using an editor that had M-x forward-sexp and M-x backward-sexp too, so the debugging wouldn't be a problem. Still, 18-19 close parens sounds excessive. The source for ourdoings.com has 1 place with 9 close parens in a row, 4 places with 8, and 7 with 7. That's in 13KLOC.
    - apgwoz 19y ago
      I looked and discovered you were using Jetty, does that mean you're using SISC or JScheme?
      - brlewis 19y ago
        http://brl.codesimply.net/ http://brl.codesimply.net/
        19y ago
allertonm 19y ago
Given that this guy's main complaint with C#/.NET (as opposed to VS) is essentially that it allows the designer of a library to enforce hiding of the implementation (see http://ryepup.unwashedmeme.com/blog/2008/02/13/brief-list-of-things-that-make-working-in-c-frustrating/ http://ryepup.unwashedmeme.com/blog/2008/02/13/brief-list-of...) I'm not sure the rest is worth taking seriously.
- gruseom 19y ago
  That's not his main complaint at all. His complaint is that C#/.NET inhibits him from building abstractions natural to his problem. He gives three good examples of this, obviously drawn from real experience working on real problems. He also gives good examples of the kind of workarounds one is forced into when blocked by a language or library from growing one's own program in a sensible way. I'll add that, in my experience, most claims about programming that talk about "enforcing" are rooted in theories or processes about programming that bear little relation to what hackers actually do.
  - allertonm 19y ago
    That's one way of interpreting it. But it does seem that what he felt was natural was to override methods marked as "do not override" and access members marked "private" or "protected". Does your experience include creating a public binary API and shipping multiple versions of it? Just asking.
carterschonwald 19y ago
Speaking as someone who's happiest with haskell and scheme, I have to say that what he needs to learn is that bad type/macro systems are oppressive, but good one's are amazingly powerful and expressive. (As that would be much better than simplistic types = bad but macros in general = good continuum) The question is, how do you develop an aesthetic sense for these without say reading the research literature on both topics? I mean, it suffices to use the good examples of each for a while, pushing their strengths to the limit, but that at best gives folks a one dimensional view of the design of linguistic features, rather than a richer sense of strength, weaknesses, and tradeoffs. As some other folks have mentioned, the other points are sort of irrelevant to the core of C#/++/java et al experience. One point that seems to be missing is the (I think standard) point that interactively testing code by being able to interactively define or execute functions is FANTASTIC for developing, because it facilitates (IMHO) an easier process of evolving the software

32 points by mqt 19y ago

I've played with Lisp a little, and I'm amazed at how many complex things such as Emacs can be built from a few simple axioms.

tptacek 19y ago
A few simple axioms and a whole lot of C code.
- brlewis 19y ago
  apt-cache show emacs22-el Installed-Size: 13080 The wonders of emacs are embodied for the most part in the most primitive Lisp dialect still in widespread use. Emacs Lisp doesn't even have lexical scoping, and it's still amazing. Not that I have anything against C, when it's used to bootstrap a Lisp implementation, at least.

tptacek 19y ago

I did not like this post. Of his four insights: * two of them are common to almost all high-level languages (Python, Ruby, and Tcl all have regular syntax that deliberately improves on C/C++, and dynamic types practically define "scripting" languages), * one of them is spurious (Visual Studio programmers don't care how much precious memory they waste as long as Intellisense keeps working, and plenty of C programmers use vim), and * the only insight here that has enough valence to be interesting --- on the scoping and binding rules of variables --- is covered so superficially that it's hard to tell whether the author actually understands what he's saying. You mean "learning lisp" didn't teach you enough to evaluate Python's closures, or Ruby's block/lambda idiom? This article won't be a total loss if it prompts somebody to write a more knowledgeable and useful article on the lessons a Lisp education brings to bear on modern languages. I'd love to read that.

nazgulnarsil 19y ago
I agree. He's seeming to gloss over the fact that the whole point of higher level languages is that they exchange some simplicity for power.
- eb 19y ago
  No, the point of high-level languages is that you exchange speed for simplicity and power.
  - tptacek 19y ago
    You forgot the words "the illusion of".
  - nazgulnarsil 19y ago
    speed and simplicity are roughly interchangeable.
    - gruseom 19y ago
      If that were true, we'd all be writing fast, simple programs in assembler.
gruseom 19y ago
I'm interested in your critique but it seems to me you've misrepresented two of his points. #2 compares Lisp's minimalism to any language with more complicated syntax, not just C/C++. So I don't think this insight is "common to almost all high-level languages". (The idiosyncracies he mentions are from Ruby and Python.) #3 isn't about Visual Studio's memory usage, it's about it being slow [1]. When I work in C#, many times a day VS is unresponsive enough to break my flow, so much so that I go off and check a website like this one (it's better than sitting there feeling angry). This is disastrous in a programming tool, so I don't think the author is being precious. (There's also a deeper point to be made here, which is that the ultra-interactiveness of Lisp and Smalltalk environments is so different from what one experiences in the likes of Visual Studio that it makes a qualitative difference in one's programming.) There may even be a little more to #1 than you give him. "In Lisp it feels like types are a tool I can employ when I need it" refers not just to static-vs-dynamic typing but also to the fact that one can easily write functions without having to make up types to hang them on (i.e. programs don't have to be organized into object models). That's not true of all high-level languges. I share your desire to read more knowledgeable and useful writing on this topic. But I did like the post because it's clearly coming from real experience. [1] Admittedly, much of this slowness is due to the add-in bizarrely known as Resharper. But that's Visual Studio's fault too - for being so backward and provincial that it needs a humongous third-party workaround to achieve bare tolerability even compared to Java.

andrewparker 19y ago

I don't get all the love for lisp. In my lisp experience I remember being in debugging hell trying to count out between 18 and 19 close-parentheses to add some parameter I'd forgotten. Bad memories.

tl 19y ago
Most text editors have some sort of parenthesis matching highlighter. I don't usually find counting () to be that difficult. I see that the greater problem is that lisp (and a lot of languages that empower functional programming ideals), undermine the idea of lines of code that other tools like source control and debuggers take advantage of.
xlnt 19y ago
if you're having that much trouble debugging paren, put them all on their own lines and use indentation. then it'll be easy enough to fix.
- brlewis 19y ago
  If he used an editor that auto-indented parens, he would probably be using an editor that had M-x forward-sexp and M-x backward-sexp too, so the debugging wouldn't be a problem. Still, 18-19 close parens sounds excessive. The source for ourdoings.com has 1 place with 9 close parens in a row, 4 places with 8, and 7 with 7. That's in 13KLOC.
  - apgwoz 19y ago
    I looked and discovered you were using Jetty, does that mean you're using SISC or JScheme?
    - brlewis 19y ago
      http://brl.codesimply.net/ http://brl.codesimply.net/
      - 19y ago

allertonm 19y ago

Given that this guy's main complaint with C#/.NET (as opposed to VS) is essentially that it allows the designer of a library to enforce hiding of the implementation (see http://ryepup.unwashedmeme.com/blog/2008/02/13/brief-list-of-things-that-make-working-in-c-frustrating/ http://ryepup.unwashedmeme.com/blog/2008/02/13/brief-list-of...) I'm not sure the rest is worth taking seriously.

gruseom 19y ago
That's not his main complaint at all. His complaint is that C#/.NET inhibits him from building abstractions natural to his problem. He gives three good examples of this, obviously drawn from real experience working on real problems. He also gives good examples of the kind of workarounds one is forced into when blocked by a language or library from growing one's own program in a sensible way. I'll add that, in my experience, most claims about programming that talk about "enforcing" are rooted in theories or processes about programming that bear little relation to what hackers actually do.
- allertonm 19y ago
  That's one way of interpreting it. But it does seem that what he felt was natural was to override methods marked as "do not override" and access members marked "private" or "protected". Does your experience include creating a public binary API and shipping multiple versions of it? Just asking.

carterschonwald 19y ago

Speaking as someone who's happiest with haskell and scheme, I have to say that what he needs to learn is that bad type/macro systems are oppressive, but good one's are amazingly powerful and expressive. (As that would be much better than simplistic types = bad but macros in general = good continuum) The question is, how do you develop an aesthetic sense for these without say reading the research literature on both topics? I mean, it suffices to use the good examples of each for a while, pushing their strengths to the limit, but that at best gives folks a one dimensional view of the design of linguistic features, rather than a richer sense of strength, weaknesses, and tradeoffs. As some other folks have mentioned, the other points are sort of irrelevant to the core of C#/++/java et al experience. One point that seems to be missing is the (I think standard) point that interactively testing code by being able to interactively define or execute functions is FANTASTIC for developing, because it facilitates (IMHO) an easier process of evolving the software