3 ms·

Lisp is good, and every good programmer needs to be familiar with it-- if nothing else, in order to know what she's missing in other languages-- but I find that

Lisp is good, and every good programmer needs to be familiar with it-- if nothing else, in order to know what she's missing in other languages-- but I find that a lot of Lisp people start using Lisp (in a humorous reversal) as their own Blub. To them, it's Lisp-versus-Shit. I find this mentality incredibly short-sighted. Strong, static typing is really great. It may not be appropriate to every problem, but it saves a lot of time in the long run. Just as every programmer ought to spend a year in Lisp, every programmer should spend a year in a Hindley-Milner static-typing language. My feeling about dynamic typing is that it test-drives really well, but it's not great for a 6,000-mile road trip. Lisp definitely beats Haskell and Ocaml in the former regard, and for small projects, I don't think there's any language that can be faster. On the other hand, for a large project with 5 developers, experience has led me to conclude that I'd much rather be using a statically-typed language.

brlewis 16y ago
If you're right about Lisp's suitability for small projects and Haskell and Ocaml's suitability for long projects, then that answer's oconnore's question about why the strongly-typed academic (as of 2011; not inherently academic) languages don't attract the same mythology: Seeing something get done in half an hour that you expect to take all day leaves a much stronger impression than seeing something get done in a month that you expect to take six months.
- michaelochurch 16y ago
  Correct. Another problem languages like Ocaml and Haskell have is this: most programmers have a very predictable trajectory through increasingly more powerful languages: C++, then Java (garbage collection), then Python or Ruby (more abstraction and power), then Lisp, which has the aura of being the pinnacle of languages, one that removes all the accidental complexity and leaves programmers able to tackle the intrinsic complexity of the problem. Strong, static typing seems like a step backward-- some seatbelt that was thrown away at the Java-to-Python transition. It's not, and Hindley-Milner type inference ensures that the static typing doesn't even eat up much developer time, but the benefits of static typing don't appear until you work on a larger project where debugging and testing become major concerns. The difference between a 40% and an 80% debug/test overhead is enormous, but aren't going to show up on a 500-line project. Strong static typing is an awesome tool that the language forces you to use. Lispers don't like being "forced" to do anything. However, on a project of sufficient size, the relatively minor drawbacks of static typing are more than paid off by the reduced test/debug overhead.
  - oconnore 16y ago
    It seems to me that most successful lisp programs use voluntary expressive names to cope with the lack of type information. (defun turn-cat-into-dog (cat-or-nil) ...) From such a definition, it is clear that this is f:[cat,nil]→dog, but the compiler isn't required to help you if you pass in a 4. This may cause some run time overhead in non-optimized code, but from my experience, is rarely a source of bugs. Has your experience been different? Perhaps then, the biggest benefit of the type system is that it forces the programmer towards expressive code?
    - lispm 16y ago
      Lispers have moved this to object systems sometime in the mid 70s of the last century (starting with Flavors), here CLOS: (defmethod turn-cat-into-dog ((a-cat cat)) ...) (defmethod turn-cat-into-dof ((a-cat null)) ...) or declarations in the mid 80s of the last century: (defun turn-cat-into-dog (thing) (declare (type (or cat null) thing)) ...)
  - swannodette 16y ago
    Strong static typing and Lisp are not mutually exclusive. * Strong Static Type Checking for Functional Common Lisp http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.54.6958 * Qi/Shen http://en.wikipedia.org/wiki/Qi_(programming_language) * Typed Racket I think what is at issue is that Lispers aren't willing to have static-typing completely baked in. Haskell's various type system extensions show that people are still working hard to figure out how to get the expressive benefits of generic programming in a strongly typed language. Personally, I'm particularly interested in supporting a la carte type systems for Clojure and have started work towards that end.
  - kenjackson 16y ago
    most programmers have a very predictable trajectory through increasingly more powerful languages: C++, then Java (garbage collection), then Python or Ruby (more abstraction and power), then Lisp I've seen virtually no one take this trajectory. Half of the Lisp programmers I know had Lisp as one of their first languages (MIT or Berkeley alum). Most C++ devs that went on to Java or C# did NOT go to Ruby or Python. Most C# devs would consider that a step backwards unless you were using a specific framework for a specific task, e.g., Rails. The only thing I do tend to agree with is that Ruby/Python devs seem to have Lisp envy. But very few others classes of developers do.
daniel-cussen 16y ago
I knew Lisp and nothing else until I learned Python and Java years later, and the only reason I've missed statically typed code after finding out what it is is that optimizing Lisp is rough. Improving the algorithms is fast in Lisp, but time and space improvements that involve type declarations are IMO poorly documented. But for a 6000-mile road trip? Are you kidding? That's when Lisp shines brightest because of macros. If you get 3 or 4 Lisp programmers together and none of them has ADD (on second thought, this may not be possible) you'll get that project done much faster and better than you would otherwise. Because of functional programming, bugs will be easy to deal with, too. I would speculate that, with regard to development time as a function of complexity, Lisp is O(n) whereas other languages are O(n^2) or worse.

brlewis 16y ago

If you're right about Lisp's suitability for small projects and Haskell and Ocaml's suitability for long projects, then that answer's oconnore's question about why the strongly-typed academic (as of 2011; not inherently academic) languages don't attract the same mythology: Seeing something get done in half an hour that you expect to take all day leaves a much stronger impression than seeing something get done in a month that you expect to take six months.

michaelochurch 16y ago
Correct. Another problem languages like Ocaml and Haskell have is this: most programmers have a very predictable trajectory through increasingly more powerful languages: C++, then Java (garbage collection), then Python or Ruby (more abstraction and power), then Lisp, which has the aura of being the pinnacle of languages, one that removes all the accidental complexity and leaves programmers able to tackle the intrinsic complexity of the problem. Strong, static typing seems like a step backward-- some seatbelt that was thrown away at the Java-to-Python transition. It's not, and Hindley-Milner type inference ensures that the static typing doesn't even eat up much developer time, but the benefits of static typing don't appear until you work on a larger project where debugging and testing become major concerns. The difference between a 40% and an 80% debug/test overhead is enormous, but aren't going to show up on a 500-line project. Strong static typing is an awesome tool that the language forces you to use. Lispers don't like being "forced" to do anything. However, on a project of sufficient size, the relatively minor drawbacks of static typing are more than paid off by the reduced test/debug overhead.
- oconnore 16y ago
  It seems to me that most successful lisp programs use voluntary expressive names to cope with the lack of type information. (defun turn-cat-into-dog (cat-or-nil) ...) From such a definition, it is clear that this is f:[cat,nil]→dog, but the compiler isn't required to help you if you pass in a 4. This may cause some run time overhead in non-optimized code, but from my experience, is rarely a source of bugs. Has your experience been different? Perhaps then, the biggest benefit of the type system is that it forces the programmer towards expressive code?
  - lispm 16y ago
    Lispers have moved this to object systems sometime in the mid 70s of the last century (starting with Flavors), here CLOS: (defmethod turn-cat-into-dog ((a-cat cat)) ...) (defmethod turn-cat-into-dof ((a-cat null)) ...) or declarations in the mid 80s of the last century: (defun turn-cat-into-dog (thing) (declare (type (or cat null) thing)) ...)
- swannodette 16y ago
  Strong static typing and Lisp are not mutually exclusive. * Strong Static Type Checking for Functional Common Lisp http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.54.6958 * Qi/Shen http://en.wikipedia.org/wiki/Qi_(programming_language) * Typed Racket I think what is at issue is that Lispers aren't willing to have static-typing completely baked in. Haskell's various type system extensions show that people are still working hard to figure out how to get the expressive benefits of generic programming in a strongly typed language. Personally, I'm particularly interested in supporting a la carte type systems for Clojure and have started work towards that end.
- kenjackson 16y ago
  most programmers have a very predictable trajectory through increasingly more powerful languages: C++, then Java (garbage collection), then Python or Ruby (more abstraction and power), then Lisp I've seen virtually no one take this trajectory. Half of the Lisp programmers I know had Lisp as one of their first languages (MIT or Berkeley alum). Most C++ devs that went on to Java or C# did NOT go to Ruby or Python. Most C# devs would consider that a step backwards unless you were using a specific framework for a specific task, e.g., Rails. The only thing I do tend to agree with is that Ruby/Python devs seem to have Lisp envy. But very few others classes of developers do.

daniel-cussen 16y ago

I knew Lisp and nothing else until I learned Python and Java years later, and the only reason I've missed statically typed code after finding out what it is is that optimizing Lisp is rough. Improving the algorithms is fast in Lisp, but time and space improvements that involve type declarations are IMO poorly documented. But for a 6000-mile road trip? Are you kidding? That's when Lisp shines brightest because of macros. If you get 3 or 4 Lisp programmers together and none of them has ADD (on second thought, this may not be possible) you'll get that project done much faster and better than you would otherwise. Because of functional programming, bugs will be easy to deal with, too. I would speculate that, with regard to development time as a function of complexity, Lisp is O(n) whereas other languages are O(n^2) or worse.