begin quoting David Brown as of Sun, Feb 17, 2008 at 06:53:11PM -0800: > On Sun, Feb 17, 2008 at 06:36:41PM -0800, SJS wrote: > > >http://groups.google.com/group/fa.haskell/msg/b1e0673a38ce3995? > > > >An article by a guy who really wanted to make Haskell work, but he's > >having some difficulties, and so he offers up some criticism of Haskell. > > I don't get the impression he's really gotten that far with Haskell.
He comes right out and says it's only been a couple of weeks. How much time does it take to become minimally proficient in the language? If two weeks of continuous study and experimentation can't get someone past the point of "OMG this sucks" and within sight of the promised land, then there's a problem somewhere. It's a matter of /where/ the problem lies. > He has hit one difficulty of Haskell right on the head, the notion of > higher-level programming. When good Haskell programmers write modules to > use, they are generally done with lots of abstraction and meta-programming. > This essentially means that learning how to just use their library involves > learning the new meta-language they've created for its purpose. The result > is quite elegant once you've learned it. That's the claim. That's what the author of the article appeared to believe. He's just not seeing the return on his investment of time and effort. I think his criticisms of documentation and the lack of _good_ tutorials is probably more on the money. Good documentation is important, and hard. (I had much the same reaction to J2EE... at first, not much documentation; then lots of documentation that was basically useless, because the folks that actually understood the system *and* had the skills to write clearly weren't the ones writing the documentation. The result was, mostly, utter crap for documentation, and a whole lot of hype.) > >I find the criticism about a small change requiring a significant rewrite > >to really catch my eye; I further find his point about SQL to be really > >appropriate. > > With Haskell's strong type-checker, refactoring the code is fairly easy to > do. Unfortunately, the design model behind it tends to lend to that > needing to be done more often than other models. If you're rewriting, then it's no longer refactoring. If you want to make a small change in the behavior, that's not refactoring either; and if you have to redesign and rewrite (which is the assertion being made, as I read the article) to extend or modify some functionality, then all the refactoring support in the world won't help. > However, I think it is more a sign of someone writing code who doesn't know > the language very well. Haskell is a very hard language to learn, and in > most languages you tend to write pretty bad code when you don't know the > language. If it's THAT hard of a language to learn, then it's doomed to utter failure. > >I *like* the idea of making some of these new languages embeddable or > >trivially callable from existing languages. > > The problem is that Haskell's entire execution model is so completely > different this is pretty hard to do. Given that, it's not that bad at both > calling to C and calling back into Haskell, at least once I learned the > meta-language for doing so :-) Note that he's talking about IDL -- so one can reasably be assured that he's willing to adopt a relatively decoupled system. The execution model is irrelevent, given that a programmer could provide a parameterized call and receive some sort of an answer. > In Haskell, calls to functions don't necessarily do work, and infinite > recursion is often fine. In languages like C and Java, the programmer often doesn't CARE what really happens on the far side of the function call. "Here's my parameters, what's my answer?" If Haskell can't bend itself to that sort of an interface, then it's really not very useful at all. > What's interesting is that he didn't even mention the usual problems people > have with Haskell: space leaks. It's not always very clear when > computations will run and it can be very easy to build up a large data > structure of potential computations, instead of computing the desired > result. Maybe he's not as stupid as you seem to think he is. -- Haskell wouldn't even compile for me back when I looked at it; An uber-lame compilation error demonstrating a lack of testing. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
