
John Hughes Contrasts Erlang and Haskell - fogus
http://www.infoq.com/interviews/Erlang-Haskell-John-Hughes
======
silentbicycle
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
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"

------
jcl
_...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.

~~~
silentbicycle
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.)

------
itgoon
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
Yeah, there's a "show all" button at the bottom of the transcript to expand
all the answers at once.

~~~
itgoon
D'oh! Yep. There it is.

------
lsb
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?

~~~
silentbicycle
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.

------
jganetsk
_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.

