Re: haskell -- very frank HN discussion about haskell's alleged "impedan

Re: haskell -- very frank HN discussion about haskell's alleged "impedance mismatch"

i speculate almost all the money in building software is centered around "enterprise" problems, whatever that is. enterprises have out-of-band problems like, who will maintain this when the subcontractor folds? who will maintain this when the guy who wrote half the code decides to quit and study zen on a mountain in india? what if, after a few cycles of the project, the enterprise re-orgs and a young manager gives the project to someone cheaper? or a democrat gets elected president and defense contracts get cut, is the half-finished project able to be leveraged somewhere else? executive leadership looks at these problems and perceives risk with languages that aren't already proven in their domain, and franky (need to reflect more) their estimation of risk may even be correct. the comments in that HN thread certainly demonstrate that there isn't clear consensus on haskell's place in the market.

On Wed, Oct 5, 2011 at 12:12 PM, Ben Karel <eschew@gmail.com> wrote:

Amen :-)

On Tue, Oct 4, 2011 at 5:51 PM, Dan Mead <d.w.mead@gmail.com> wrote:

OR

if you want to write a compiler, Haskell is the best.

-Dan

On Tue, Oct 4, 2011 at 5:50 PM, Dan Mead <d.w.mead@gmail.com> wrote:

I can think of three answers to explain this:

1) the OP isn't trying hard enough, or doesn't get it. alot of people read the intro haskell tutorials and don't dig deeper into the core parts of the language (pattern matching, laziness, monads). this bites them in the ass later when they try to do something serious with it (I speak from personal experience). While this does happen, I doubt it was true in this case.

2) haskell has features that make it easier to do proofs of correctness, be secure and and to clearly enunciate your thoughts. This is if you think about it, very anti-agile and does require alot of up-front design. It's not until much later that you get good at making your types pass the type checker very quickly. noob haskellers tend to spend more time fixing compiler time errors than anything else. You could argue that this is better than finding problems at compile time, but absolutely nothing will work about your code unless it passes the type checker.

this means you don't even have code to do unit testing on unless it passes the type-checker.

3) A more serious answer would be that Haskell is not actually supposed be used in production environments. It better serves as a sandbox for language and compiler features that eventually make it's way into industry. This is a serious view that Simon Peyton-jones seems to support.

He even says it in an interview along with Joe Armstrong (the erlang creator)

http://www.infoq.com/interviews/armstrong-peyton-jones-erlang-haskell

However, none of these reasons is grounds enough to not learn Haskell (or lisp) as you should let it better inform how you write imperative code.

Dan

On Tue, Oct 4, 2011 at 2:13 PM, Jonathan Tran <jonnytran@gmail.com> wrote:

Thanks for the link, Dustin. I've had a very similar experience with Haskell. It was fun to learn in the beginning, but I've since abandoned it in favor of other things.

On Tue, Oct 4, 2011 at 1:34 PM, Dustin <dustin.getz@gmail.com> wrote:

lots of intelligent debate in the comments about the "impedance
mismatch" when "getting stuff done in a deeply imperative, eager
world". i post this with no opinion, but i think it's interesting
because a lot of the blogs and papers are somewhat evangelistic, and
here we have opinions from developers who were initially attracted to
haskell like us, but the attraction faded with time.

http://news.ycombinator.com/item?id=3065672

cheers!
Dustin