Andrew Lentvorski wrote: > Christopher Smith wrote: >>> http://wagerlabs.com/2006/01/01/haskell-vs-erlang-reloaded >> >> I remember reading this when it first came out. I think in a lot of ways >> this guy wasn't comfortable with the Haskell paradigm. He seemed to be >> wanting a dynamically typed language, and as long as you are looking at >> the problem that way, a statically typed language is gonna hurt you bad. >> He also had problems with memory consumption which tends to go better >> with a) newer versions of GHC and b) programming Haskell "the Haskell >> Way". I have observed on many occasions that when things weren't >> efficient in Haskell it was because I was formulating my code the wrong >> way. Same point goes for his problems with serialization. > > No huge argument. I will point out, though, that he had two of the > biggest Haskell guns helping him, and they really couldn't crack the nut.
Fair point, although the effectiveness of "getting help" tends to have a lot to do with how you ask for help and how flexible you are to answers along the ways of, "this is the wrong design for Haskell". > In addition, "you have to think the Haskell way to be efficient" smacks > of "you have to think the XXX way to be efficient". Generally, I find > that argument means "We're not very flexible. We fit a certain class of > problems and ignore the rest". That's not necessarily a bad thing, but > people should be aware of it. I disagree with this pretty strongly. It is a common problem with porting solutions from one language/framework to another. If you just do a straight translation you almost inevitably end up with an inefficient system. I've seen it when translating from almost any language to any other. To get efficiency, you inevitably have to give up assumptions about of efficiency that apply to the old tool and embrace new ones that apply to the new tool. > I'm going to express an opinion here: good languages should unfold > themselves with use. You should be able to get your job done, albeit > inefficiently, with a reasonable investment of time. As you do more, > you should get better and more efficient. With one week in Haskell, another programmer and I were able to get programs that worked. Of course, it took us more time than to do it in other languages. That seems to be improving rather rapidly. > This may be some of the gripe a lot of programmers have with "pure" > languages like Haskell. You have to move a long way up the learning > curve to do anything useful. In Haskell, you must understand Monads > before being able to handle I/O. That's a slog even for functional > programmers with some decent experience. Monads aren't that bad. There are like a billion tutorial on monads these days, because Haskell advocates are wrongly convinced that this is the killer for adopting Haskell. Once you've read a couple of the better ones, monads make a lot of sense and save you from several layers of pain that can be found in other languages (although I'd agree that Erlang addresses most of these issues in its own elegant way). >> My point is that there is a fair bit of impedance mismatch between >> Erlang's runtime model and the JVM's, particularly when it comes to >> concurrency. Believe it or not the JVM is even more troublesome than the >> standard POSIX runtime. > > I agree. That's why I want it *even more*. If you can't port that > runtime, then you're eventually going to stumble over that impedance > mismatch somewhere else. I'm not sure that is really true. The JVM is a lot less language/runtime agnostic than just about any other platform I can think of, and it is particularly unkind to dynamic languages and languages with their own concurrency models like Erlang. Even the CLR is better. The Erlang runtime is already available for a lot of different platforms, including some in the embedded space (which tend to have a lot of the fairly painful restrictions that occur when you port to new hardware). That ought to be enough to give you confidence that the runtime doesn't have much of an impedance mismatch with real hardware. --Chris -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
