John Hughes Contrasts Erlang and Haskell(infoq.com)
infoq.com
John Hughes Contrasts Erlang and Haskell
http://www.infoq.com/interviews/Erlang-Haskell-John-Hughes
15 comments
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.
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.
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"
"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.
You can use newtypes but then you lose the genericness.
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.
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.
...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'm sure it's perfectly logical in context, but I find it amusing that he's writing a program that finds errors in itself.
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.)
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.)
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?
-- "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?
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.
Certainly, though, transforming code is more popular than introducing laziness.
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).
The former.
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.
Did I miss a link where I could've avoided that.
Good interview, otherwise. Just a PITA to read.
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.