Hacker News Reader

Comment by dreamcompiler | Hacker News Reader

I'm a Lisp expert. Learning Lisp (a long time ago) blew my mind. Learning Haskell (recently) blew my mind a second time. There are some things I can express in Haskell that I can't -- at least not easily -- in Lisp. And that had never happened before to me, with any other language.

View on HN

I must do a different type of programming than the masses. 99% of all of the work I do is API calls, map/filter/reduce, and maybe some database persistence of simple objects/arrays and it has been this way for years. CRUD calls, data in -> data out.

I don't see how any of Haskell's crazy syntax would make my life easier compared to node.js

I’m intrigued - can you share an example?

I'm not the parent so I can't answer from their experience, but I will say that laziness in Haskell lets you write functions that cannot be expressed in Lisp without macros.

Some simple examples are when and unless, which work like if...then and if not... then.

In most languages, these would be control flow statements built into the language (or not) and could not be written by the user. In Lisp you could implement these with macros, with all of the caveats that apply. In Haskell they're just ordinary functions with all of the benefits of being first class values at runtime.

> Lisp without macros

Why even consider that? Macros are IMO the main reason to use a LISP. As you suggested, they allow you to model laziness, or whatever else you might desire.

Because macros are not first class the way functions are. You can't map a macro over a list the way you can a function. Haskell functions give you the power of lisp macros at runtime.

Macros are IMO the main reason to use a LISP.

It's funny that you say that. I've heard it before and it sounds great but from the time I spent in the Clojure community, people would always say "the first rule of macros is that you do not write macros!"

Automatic currying: Haskell does it; Lisp doesn't. You can do partial evaluation in Lisp but it's not as convenient. This makes Haskell more functional than Lisp and eliminates one use case (or maybe more) for macros.

Laziness: You can build infinite data in Lisp but again, it's not as convenient.

Monads: Possibly the most mind-bogglingly useful programming pattern I've explored in the last 20 years, and you can't completely build them in Lisp. You can get about 75% of the way toward monads in Lisp but that last 25% requires manual one-off coding because Lisp functions don't automatically know the types they return. Even using macros I haven't figured out a way to solve this problem.

On the other hand, Lisp gives you variadic functions like (list) (list 1) (list 1 2 3 4). Lisp catches it in a straightforward way when you pass too many parameters to a non-variadic function, or fewer than the required number of parameters to any function. (cons 1) is a plain and simple error rather than a correct expression that evaluates to an unintended (lambda (x) (cons 1 x)) term. Macros can provide a clear explicit syntax for partial evaluation in which everything is visibly delimited, like (op cons 1).

I think you're highlighting the downside of ubiquitous laziness. In a lazy world there's nothing wrong with (lambda (x) (cons 1 x)). But if you want to call this an error earlier, I agree that Lisp defaults in that direction.

Reply on news.ycombinator.com