Hacker News Reader

Comment by heretohelp | Hacker News Reader

I would very much like an answer to these questions.

I have been struggling to understand the appeal of all this Haskell-mania (I say this as a long-time Lisp coder) and only come up short for an explanation.

View on HN

Haskell only becomes interesting once you start using it for real code, and the characteristics people are talking start manifesting in your designs and code reuse. All the short snippets you've seen are trivially surface translatable to Lisp, after all. For that matter a lot of the "Oh! Haskell! Wow!" blog posts have code trivially translatable to Perl.

You may also find it interesting to start with this: http://learnyouahaskell.com/functors-applicative-functors-an... That's Learn You A Haskell, jumping you past the part of the book that is teaching simple first-order functional programming and cutting straight to the stuff that makes Haskell Haskell.

By my reckoning, despite superficial similarities and similar heritages, Lisp and Haskell are actually polar opposites at a philosophical level, so you will certainly encounter a lot of difficulty trying to understand Haskell through a Lisp lens. I go more into this at http://www.jerf.org/iri/post/2908 .

>By my reckoning, despite superficial similarities and similar heritages, Lisp and Haskell are actually polar opposites at a philosophical level, so you will certainly encounter a lot of difficulty trying to understand Haskell through a Lisp lens.

That has been my suspicion and my experience.

Never understood the Lisp-mania: how could you like a language where you won't get a type error until after you run the program?

You'd be amazed how little that matters in Lisp.

It bites me in Ruby/Python, but not in Lisp.

Could you explain why is that?

Arbitrary interfacing in Ruby and Python, method_missing, TypeError, ValueError, operations, etc.

Most of the time, you're just map, car, cdr, mapcar, reduce, fold, etc in Lisp. Functional iteration/processing semantics are the default in Lisp. Common Lisp makes it VERY obvious when you're not using a standard data structure so it's hard to mess up.

Ruby and Python proliferate arbitrary Object-Oriented interfaces, combined with dynamic typing, it's easy to get the wrong instance of something-or-other and fuck it up.

Contrary to popular belief, Common Lisp code tends to be more consistent in terms of how you interact with your data, even if they go on flights of fancy re: Reader Macros.

That's dodging the point. If you forget whether your list A is an association list ((key value)) or a reverse association list ((value key)), your cars and cdrs won't crash the program, but your program will still fail to produce a correct result, and the source of the bug is a type error.

The universe of common errors you can have in Common Lisp due to dynamic typing is constrained compared to Python and Ruby.

I say this as someone who works with Python daily as my working language and grew up with a copy of this:

http://www.cs.cmu.edu/afs/cs/Web/Groups/AI/lang/lisp/impl/cl...

I'm fully aware of the errors that can arise from dynamic typing in Common Lisp. It's just not my experience that it's that big of a deal.

The reverse association list is contrived compared to the issues one can have in Python or Ruby. Most people just use association lists the normal way and use rassoc as needed.

Lets not kid ourselves and pretend that a reversed assoc list is used in place of a normal rassoc or find :key #'cdr.

Reply on news.ycombinator.com