Comment by cletus | Hacker News Reader

Comment by cletus | Hacker News Reader

Parent Full thread

This kind of comment kinda misses the point.

Haskell (IMHO) won't ever be mainstream for much the same reasons Lisp never was (or will be?): it has an incredibly high learning curve (eg [1]).

This is really the problem of the "pure" functional languages. Functional programming is suited to some tasks. With others the fit is almost tortuous. Imperative programming is well-suited to how we think and how we break down tasks.

If you look at the popular languages they're pretty much all multi-paradigm (eg Ruby, Python, Go, C#, arguably even C++/Java) meaning they give you the low-hanging fruit of functional programming while still being in a relative sweet spot of being easy to learn yet reasonably expressive.

Why I think Go has a very bright future ahead of it is that it is the first of these multi-paradigm language to combine all these features:

- easy to learn (seriously, go look at how short [2] is; you can knock that out in an afternoon);

- it is minimal. I LOVE Go's minimal OO model for example; and

- it is statically typed.

If you look at the other statically typed multi-paradigm languages you have C#, which is generally well-regarded... except (Mono notwithstanding) it is very Windows-centric. Java is, well, Java. C++ is incredibly complicated.

The only thing Go is missing is a mode for (semi-)manual memory management. I'm thinking something like Obj-C's ARC (in iOS 5+) and it could well supplant C/C++ for the vast majority of their (already shriking) use cases... eventually (Go has some work to do on speed).

[1]: http://stackoverflow.com/questions/377082/how-long-does-it-t...

[2]: http://www.miek.nl/projects/learninggo/

Haskell (IMHO) won't ever be mainstream for much the same reasons Lisp never was (or will be?): it has an incredibly high learning curve (eg [1]).

Bingo. Anybody that thinks Haskell will ever escape its niche has not spent enough time working with rank & file programmers. That doesn't mean you shouldn't consider it or that it can't find a large enough niche to sustain itself but it does mean that it's unlikely to ever overcome what Carmack refers to as "externalities" for a lot of prospective users.

This kind of comment kind of misses the point. The monadic style of threading error values is perfectly compatible with imperative programming if only language designers knew about it.

Problem is that you then have to explain monads to average programmers who'll be using the language.

I love monads (I love arrows more, but that's another issue). I'm a language design geek. My level of expertise is different from someone who has just been hired into a new job and wants to get things done.

I suspect that most language designers know about monads - I'm not sure Rob Pike did, but it's pretty common knowledge among folks who do this stuff. Until you can explain them to the folks who'll be using the language in a way that doesn't make them seem like arcane black magic, though, you'll find programmers will just say "I don't get this" and use what they're familiar with.

>Problem is that you then have to explain monads to average programmers who'll be using the language.

No you don't, this is exactly what you don't need to do. Do we explain the finer points of stream implementation to would-be C++ programmers? No, when they need to do something non-standard with a stream/monad, that's the time to talk about them. For the majority of programmers it's just "when you need to write to a file you do it like this".

The Either type described in the first comment is also a Monad. They are more important in Haskell than just "when you need to write to a file..." and I don't think you can totally grasp the error handling method without understanding them.

I couldn't disagree more. The Either type may have a Monad interface, but it's a Sum type and languages that don't have thousands of Monad tutorials also have Sum types. There's no need to explain Monad theory to someone just to explain Sum types or even why chaining do expressions doesn't do unnecessary computations in the face of errors. Just show them the code for join and >> and they'll see why it works. No need to bring up Monads.

I don't know what a thread is, but I can still use Executors in Java.

You can write Haskell programs entirely in IO, and the result looks and works almost exactly like Python, but type safe.

The dangerous part of Haskell, like Scala and C++, is that it also has super scary dark magical parts.

Reply on news.ycombinator.com