Hacker News new | past | comments | ask | show | jobs | submit login

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.




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.


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.


"Half of the Lisp programmers I know had Lisp as one of their first languages (MIT or Berkeley alum)."

We also learn Scheme as our first language at Indiana University computer science@


Lots of Smalltalkers don't have Lisp envy. I'm not one of those, however.


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?


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))
      ...)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: