
Hello Haskell, Goodbye Lisp (2009) - psibi
http://newartisans.com/2009/03/hello-haskell-goodbye-lisp/
======
ColinWright
An interesting question[0] was asked by ntoshev[1] in the discussion that
ensued when this was submitted a little over five years ago[2]:

    
    
        > Can you give an example of something you can
        > implement with a Lisp macro, but you can't
        > implement with Haskell?
    

Much of that discussion is worth reading. The other submissions don't have
much discussion.

[0]
[https://news.ycombinator.com/item?id=516208](https://news.ycombinator.com/item?id=516208)

[1]
[https://news.ycombinator.com/user?id=ntoshev](https://news.ycombinator.com/user?id=ntoshev)

[2]
[https://news.ycombinator.com/item?id=516038](https://news.ycombinator.com/item?id=516038)

~~~
cynicalkane
My somewhat neglected library Clearley
([https://github.com/mthvedt/clearley](https://github.com/mthvedt/clearley))
uses a macro system, that lets you write parsers that look a little like
pattern-matching functions. To do this, you need to be able to introspect,
bind and lookup symbols, and data structures containing symbols, at compile
time. You can't do this in Haskell. Template Haskell doesn't help, since IIRC
it doesn't support looking up symbols in the same file.

With Clojure, If you understand the JVM type system and performance, you can
also write high performance DSLs using Clojure macros.
[https://github.com/clojure/core.logic](https://github.com/clojure/core.logic)
allegedly is a project along these lines, but I haven't looked too much into
it. It heavily uses Clojure protocols (which map to Java interfaces) for
performance. I had been working on a code generator for Clearley, which sits
neglected on my hard drive, but is able to perform just a little slower than
unoptimized hand-written parsers. Since in Clojure compile/runtime separation
is optional and off by default, you can use Clojure to generate Clojure code,
making life a lot easier.

~~~
Peaker
Template Haskell does support looking up the namespace in the same file.

------
ademarre
It's interesting to read old introductory posts like this, and then look ahead
at future blog posts to see how his opinion evolved.

He still loves Haskell:
[http://newartisans.com/category/haskell/](http://newartisans.com/category/haskell/)

~~~
chrisdone
That's John Wiegley. Worked with him at FP Complete for over a year. He loves
Haskell more and more every day.

------
xmonkee
I use Clojure for almost everything now, but I must say Haskell looks
interesting. My issue is that Clojure is _thriving_ right now, and Haskell has
been around longer than I've been and the world sees it as some arcane
science. Is it really worth investing my time to learn it if it's really not
being used that much?

~~~
lkrubner
Relative to Haskell, Clojure is certainly thriving. Consider:

[http://www.indeed.com/jobtrends?q=clojure%2C+haskell%2C+scal...](http://www.indeed.com/jobtrends?q=clojure%2C+haskell%2C+scala&l=)

But they both lag Scala.

~~~
louthy
A sense of perspective?

[http://www.indeed.com/jobtrends?q=clojure%2C+haskell%2C+scal...](http://www.indeed.com/jobtrends?q=clojure%2C+haskell%2C+scala%2C+c%23%2C+java&l=)

------
ced
As a long-time Lisper in AI, Haskell does look intriguing, but I'm more
worried about what I would lose. In particular, I'm curious about how DSLs
fare in Haskell. I can write first-order logic sentences in Lisp, and they
look and behave _just like any other Lisp code_. I can use evolutionary
programming to generate new code on the fly, and send it to the compiler. And
I can get really down to the metal if I ever need C-level performance.

How do these look in Haskell?

~~~
gizmo686
I've never learned Lisp, but my motivation for learning Haskell (after briefly
toying around with it) was to create a DSL. Specifically, I was designing a
DSL with the intention of implementing it in python, when I realized that my
DSL seemed a lot like a monad in do notation. Implementing it didn't fail to
dissapoint in just how easy it was. Having said that, a DSL implemented as a
monad does not behave like any other haskell code, in that it is a monad, and
only looks like a DSL when used in do notation.

------
orthecreedence
Except macros are great for _more_ than just lazy evaluation. For instance,
completely altering syntax to make your app make a lot more sense and remove
any amount of boilerplate.

As far as parallelism, sure Haskell can give that for free. The cost is you
have to be pure about everything, which just seems obnoxious to
me...especially when you don't necessarily care about parallelism or
performance.

With lisp, I can use macros to make parallelism just as natural as programming
regular lisp. Yes, I have to be explicit about when I'm being parallel and
when I'm not. But that doesn't seem like such a big deal to me, and sometimes
you want explicit control over your threads.

As far as community, I have no doubts the Haskell community is great. But so
is the lisp community. There are a lot of bright people who jump at any chance
to help out others, and in the past 5 years the CL implementations and
community-built libraries have been making leaps and bounds.

This isn't to say Haskell isn't a great choice for many, many applications and
requirements. But it's not a replacement for lisp, just as lisp isn't a
replacement for Haskell. They are two different beasts that are great at
different things.

~~~
coolsunglasses
>Except macros are great for more than just lazy evaluation.

Haskellers agree, that's why we have Template Haskell. We use it for all sorts
of things, like automatically implementing typeclasses (interface'ish) at
compile-time.

> parallelism, sure Haskell can give that for free

Not really.

>The cost is you have to be pure about everything

Nonsense.

Boom, mutable variables:

[http://bitemyapp.com/posts/2014-03-25-when-nested-io-
actions...](http://bitemyapp.com/posts/2014-03-25-when-nested-io-actions-are-
wanted.html)

>sometimes you want explicit control over your threads.

You can have that in Haskell. You can use green threads or OS threads and
optionally pin OS threads to a particular CPU to avoid context-switching.

So you can know what you're talking about next time, my recommended guide for
Haskell:

[https://gist.github.com/bitemyapp/8739525](https://gist.github.com/bitemyapp/8739525)

The concurrency primitives in Haskell are broad and deep, check this book out:
[http://chimera.labs.oreilly.com/books/1230000000929](http://chimera.labs.oreilly.com/books/1230000000929)

\--- an ex-Lisper

~~~
djur
> So you can know what you're talking about next time, my recommended guide
> for Haskell:

I like your guide, but is this really necessary? This isn't the first time
you've been aggressively hostile to people expressing a preference for Lisp
over Haskell, either.

~~~
coolsunglasses
There were untrue statements, I corrected them.

Also you can't express a preference (up or down) for something you've never
used.

I'll elide the snark next time, but I'm not going to stop correcting false
statements or sharing learning resources.

------
pjmlp
_Why Calculating is Better than Scheming. (1987)_

[http://cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf](http://cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf)

A paper by Phil Wadler about why ML languages are better than Lisp ones for
teaching.

------
greenyoda
The comments of this article include a lengthy and interesting reply by Daniel
Weinreb (of MIT Lisp Machine and Symbolics fame):

[http://newartisans.com/2009/03/hello-haskell-goodbye-
lisp/#c...](http://newartisans.com/2009/03/hello-haskell-goodbye-
lisp/#comment-766)

The author's reply to Weinreb can be found here:

[http://newartisans.com/2009/03/the-jvm-and-costs-vs-
benefits](http://newartisans.com/2009/03/the-jvm-and-costs-vs-benefits)

------
jonathansizz
I keep hearing over and over about how great Haskell is, and yet nobody can
ever show me anything written in it other than yet another compiler.

Haskell is never going to go mainstream. Stop pushing it, because it's getting
really tedious.

~~~
phaer
> and yet nobody can ever show me anything written in it other than yet
> another compiler.

[http://johnmacfarlane.net/pandoc/](http://johnmacfarlane.net/pandoc/)

[http://git-annex.branchable.com/](http://git-annex.branchable.com/)

[http://jaspervdj.be/hakyll/](http://jaspervdj.be/hakyll/)

You are welcome :)

~~~
jonathansizz
Best of luck. Let me know if any of your projects gain any traction.

~~~
Pacabel
It's a shame to see that comment getting modded down. It's absolutely valid
and correct. The three examples given in that other comment are pretty much
unknown. xmonad might be a slightly better example, but it's still pretty much
unknown, too.

While Haskell has seen some usage, of course, we really haven't seen any major
and widely-used non-compiler software developed using it. It's perfectly
legitimate to point this out, and using very obscure counterexamples doesn't
change this reality.

~~~
xooyoozoo
I don't use or know about any of the other tools mentioned, but Pandoc isn't
exactly someone's pet project.

It may be _niche_ , but it's not unknown. If you need to convert
markdown/rest/latex/etc to pdf/html/epub/etc, Pandoc's gonna come up.

