Live data from Hacker News

In Praise of Haskell

drdobbs.com

1–10 of 64 posts

Re: In Praise of Haskell

#2

  What's not to like?
Cabal, which unsurprisingly is not mentioned. Dependency hell makes it stupidly difficult to rely on other people's code on a large scale. I'd rather write uglier code in JavaScript if it means having access to other people's packages immediately and without complications.

Re: In Praise of Haskell

#5
post #2

What's not to like? Cabal, which unsurprisingly is not mentioned. Dependency hell makes it stupidly difficult to rely on other people's code on a large scale. I'd rather write uglier code in JavaScript if it means having access to other people's packages immediately and without complications.

Also, after a week I still didn't understand its type system completely.

It may be that I am simply too dumb, or that I didn't find the right resources, but 'easy to learn' this language is not.

Re: In Praise of Haskell

#6
This is yet another shallow puff piece on Haskell. Reading it, you would think that the author has only ever used Ruby and Haskell, as he gives the impression Haskell is the only language that supports functional/declarative style programming.

In actuality the author is trying to sell Haskell because he sells Haskell IDEs.

I'm not knocking Haskell, but let's not pretend that this is a useful piece of journalism.

Re: In Praise of Haskell

#7
I have and will continue to maintain that it's Haskell's operational challenges that are holding it back from wide adoption, at least on the web. In a lazy language, your cost model is all out of whack. When your program consumes resources, you can't unambiguously identify the line of code that caused your program to consume those resources. That's because a function application itself does nothing. Needing the result of the application is what causes work to be done. And that function application could be floating through your program as a thunk for who knows how long until its result (probably a partial result at that) is forced. So who's to blame for the work? The function application or the code that forced its result? Who knows.

The typical solution to this problem in production Haskell systems, by the way, is to run the application with profiling turned on.

Re: In Praise of Haskell

#8
post #5
post #2

What's not to like? Cabal, which unsurprisingly is not mentioned. Dependency hell makes it stupidly difficult to rely on other people's code on a large scale. I'd rather write uglier code in JavaScript if it means having access to other people's packages immediately and without complications.

Also, after a week I still didn't understand its type system completely. It may be that I am simply too dumb, or that I didn't find the right resources, but 'easy to learn' this language is not.

If you're stuck, asking questions on the Haskell irc channel on freenode is a great way to get feedback. Learning new things is a social process, not something to be done in a padded room. :-)

Re: In Praise of Haskell

#9
One important thing in the article that was a bit obfuscated: modern OOP languages introduce a staggering amount of dependency and complexity. Things like TDD are then layered on top to try to ensure solid code is being built.

In a pure functional environment, you don't have those dependency issues. Your problems boil down to types -- do you have the correct fields and definitions in your inputs? -- and transforms -- are your symbolic transformations what is desired?

In practice, pure FP is the closest I've seen to stuff that "just works". While FP can be a huge pain in the ass mentally, it beats the heck out of the spaghetti dependency issues in OOP. [insert long discussion here about whether pure FP can actually scale in a large organization]

Re: In Praise of Haskell

#10
post #2

What's not to like? Cabal, which unsurprisingly is not mentioned. Dependency hell makes it stupidly difficult to rely on other people's code on a large scale. I'd rather write uglier code in JavaScript if it means having access to other people's packages immediately and without complications.

The latest version of Cabal (1.18) includes built-in sandboxing support, which alleviates this problem to a significant extent. Prior to that, there were/are tools [^1][^2] for doing the same thing external to Cabal itself. Dependency hell has without a doubt been problematic with Cabal, but it is fast becoming a solved issue.

[^1]: http://hackage.haskell.org/package/cabal-dev [^2]: http://hackage.haskell.org/package/hsenv (Disclosure: I am the current maintainer of this project, though I am happy to see it becoming obsolete)

Post reply on HN