
Hello Haskell, Goodbye Lisp - dons
http://www.newartisans.com/2009/03/hello-haskell-goodbye-lisp.html
======
critic
Well written article, but it would be more relevant, IMHO if it compared
Haskell and Clojure, not CL.

~~~
andreyf
Not really, the criticism apply in both cases. The main area where clojure
wins against CL is that clojure is not bloated and that wasn't where the
author of the article had major problems. Also, to his additions, I would like
to add in the lack of decent data-structures in lisp. Cons cells are nice but
they are no match for algebraic data-types and pattern matching.

~~~
mdemare
Clojure has great support for parallellism, and Clojure's community is very
friendly. Haskell has nothing on Clojure in these specific regards.

~~~
chancho
As a longtime GHC user and sometime #haskell visitor, I find your troll
HILARIOUS. One thing though, you forgot "Clojure has a better library of
persistent data structures." That would have sent dons into an epic flameout.

~~~
Zak
I'm not sure if mdemare's post was a troll, or just poorly worded. Clojure has
a friendly community and very good support for parallelism. Haskell does also.

~~~
mdemare
I think my post was neither, and I'm confused at the reactions. You summarized
it perfectly.

------
ntoshev
Is the "parallelism" section theoretical, or you can get the Haskell compiler
to actually generate multi-core code automatically?

~~~
dons
No, its not theoretical. However, do not assume the Haskell compiler
automatically parallelises _arbitrary_ non-parallel code. That's simply not
possible to do well, and is really a dead end.

What GHC does do is semi-implicit multicore parallelism for particular subsets
of the language.

The GHC runtime is a parallel runtime supporting a range of parallel
abstractions from semi-implicit parallelism to explicit task parallelism, in a
three level hierarchy of OS threads -> Haskell lightweight threads -> fine
grained thread sparks.

The most automated mechanisms are:

* thread sparks - you hint which code to run in parallel with `par`, and the runtime uses that hint to parallelise your code, distributing it across cores. * data parallel arrays - if your algorithm is expressible as an array program, use DPH and the array operations will be automatically parallelised (alpha!)

To more explicit paralelism with: * threads * transactional memory * mvars *
message passing

An example of the semi-implicit multicore parallelism is given in the "Haskell
in 5 minutes" tutorial here:

[http://haskell.org/haskellwiki/Haskell_in_5_steps#Write_your...](http://haskell.org/haskellwiki/Haskell_in_5_steps#Write_your_first_parallel_Haskell_program)

------
DenisM
Is there analog to List macros in Haskell?

edit: yes, there is! <http://www.haskell.org/th/>

~~~
shrughes
A lot of (but not all of) what you end up getting from Lisp macros ends up
being not needed to be implemented with macros in Haskell anyway.

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

~~~
jrockway
Sure. Consider the case of defining an instance of a type class:

    
    
         instance Foo Bar where
             quux = quuxifyBar -- terrible example
    

Now, you want to follow the same pattern to declare "Foo Baz", "Foo Quux" and
"Foo CannedAir". I hope you like copying and pasting, because that's how you
do it without Template Haksell.

In Lisp, it would be a simple matter of writing a macro, like this:

    
    
        (defmacro make-my-type-thing (type)
             `(instance Foo ,type
                  ((quux (x) (,(intern (format nil "quuxify-~A" type)) x)))))
    

Then you can:

    
    
        (eval-when (:compile-toplevel)
            (loop for i in '(Bar Baz Quux CannedAir)
                  do (make-my-type-thing i)))
    

Yes, the example is very contrived, and yes, Haskell ships with a lot of
abstractions to make this case very uncommon. But in Haskell, you just can't
treat your code as data -- it's code.

