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.
"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"
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.
...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.
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.)
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.
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.
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.
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.