John Hughes Contrasts Erlang and Haskell

http://www.infoq.com/interviews/Erlang-Haskell-John-Hughes

by fogus • 17 years ago

23 15 17 years ago

jcl• 17 years ago

...I do spend some time looking for errors that the Haskell type checker would tell me about immediately. But what that means, is that I have to find my type errors by thorough testing. Oh, wait a minute, I'm working with a testing tool! I actually find that the type errors are found very quickly by QuickCheck tests, so I need to write QuickCheck properties for testing, anyway, so that it's not as big a problem as I might have expected not to have the type checker.

I'm sure it's perfectly logical in context, but I find it amusing that he's writing a program that finds errors in itself.

silentbicycle3• 17 years ago

That's the point at which you know it works. :)

I wrote a port of QuickCheck for Lua, and it caught a fencepost error in its own random value generation code. (The documentation is still pretty crappy, though - I need to rewrite that first.)

silentbicycle3• 17 years ago

Interesting interview, though I must admit I can't stand the format of the site - I always copy the whole transcript into Emacs, m-x fill-individual-paragraphs, and read it there.

This part really jumped out at me:

"If you do generic programming in Haskell, you can write a paper about it. If you do generic programming in Erlang, it's 4 lines - one for lists, one for tuples, one for basic values."

I'd like to hear from someone with more Haskell experience (it's not my thing), but it helps here that Erlang matches and dispatches by structure, not types per se. It's common to use a tagged tuple, like { point, 1.5638, -2.4144 }, for informal type annotations, but they're not mandatory.

Another significant difference between Erlang vs. Haskell and OCaml is that since Erlang is dynamically typed, it can far more easily accommodate incremental changes without having to stop it. Doing static validation of changing types in a running, distributed system adds major complexity, with many of the same problems as handling schema changes in a database. Erlang's design reflects that it's probably simpler to let it fail and put effort into recovering gracefully, rather than trying to make it bulletproof.

plinkplonk• 17 years ago

This bit was interesting.

"With Haskell you've been always thinking it's side effect free, right? Writing a function is side effect free. In Erlang just the fact of passing a message is a side effect. Don't you find it a bit of a problem or a difficulty when programming with Erlang?

Most of my Erlang programming is side effect free. I think I probably write very unusual Erlang programs that look a lot like Haskell ones. Now and then, I do write side effecting code. For example, when I use the random number generation libraries that comes with Erlang, it has a side effecting interface. It's very tempting when you are building something on top of the library with a stateful interface to build code on top of that that also has a stateful interface. "

I find that one of the key advantages of programming in Haskell is that you think in terms of the minimum stateful interaction your program needs and most of the program is not "side effecting code"

Agent101• 17 years ago

There is nothing stopping you using tagged tuples in haskell. I don't think it is done so much because type signatures are very useful and cross:: (Num b)=>(a,b, b) -> (a, b, b) -> (a, b, b) is more wordy than cross :: (Point p) => p -> p -> p.

You can use newtypes but then you lose the genericness.

jganetsk2• 17 years ago

Dynamic typing is merely a mode of use of static typing. All you have to do is add one line of code to your Haskell program:

data Dyn = I Int | C Char | S [Char] | F (Dyn -> Dyn) | P (Dyn, Dyn)

Now you can do matching "by structure" in Haskell just as easily is you can in Erlang.

lsb• 17 years ago

Lispers, I found this interesting, from 1:30:

-- "Do you miss laziness, from Haskell?" -- "Yes. Absolutely. I have macros in Erlang to simulate it, and I used them all the time."

Are Lisp's macros more popular for transforming code, or for introducing laziness?

gruseom• 17 years ago

The former.

alec• 17 years ago

Lisp's macros are foremost a cheap anonymous lambda - with-open-file, dolist, and the like don't need to be macros, but it's much more convenient and efficient than passing a lambda to another function.

Certainly, though, transforming code is more popular than introducing laziness.

richcollins• 17 years ago

You should check out Io. It is an OO language with laziness: http://www.iolanguage.com/scm/git/checkout/Io/docs/IoGuide.h... (see the Messages section).

silentbicycle3• 17 years ago

As an aside, the reason that laziness isn't as popular a strategy in Erlang is probably because it conflicts with the language's priority on (soft) real-time behavior. Being reasonably certain about upper bounds for time (and space) is very important in Erlang's niche.

itgoon2• 17 years ago

Am I the only one that found that two-frame, click the + to read the answer format really irritating?

Did I miss a link where I could've avoided that.

Good interview, otherwise. Just a PITA to read.

mbrubeck• 17 years ago

Yeah, there's a "show all" button at the bottom of the transcript to expand all the answers at once.

itgoon2• 17 years ago

D'oh! Yep. There it is.

jganetsk2• 17 years ago

thanks to the lack of a type system in Erlang.

Lack of a type system? What about Erlang's dynamic type system that can blow up in your face unexpectedly during execution?

I hate this stupid misnomer. Dynamically typed languages have HUGE type systems that provide lots of critical guarantees. You still get type safety and memory safety. You can still do non-conservative GC. You can still be certain that you're not going to misinterpret integer data as a string.

It's weakly typed assembly languages, like C, that are the best candidates for being accused of having a lack of type system.

John Hughes Contrasts Erlang and Haskell

Related Stories