Comment by michaelochurch | Hacker News Reader

Comment by michaelochurch | Hacker News Reader

Parent Full thread

Haskell isn't "overdone". It's extremely principled and requires that, for example, you put the existence of stateful effects (e.g. I/O) in the type system. It requires you to specify state (to a degree, and with escape hatches); it doesn't eliminate it.

Haskell isn't that much of an investment when you consider what is gained. See, learning any new code base takes 3-6 months, and if the code is great, you learn a lot. If the code is garbage, well... perhaps you learn what not to do. Compared to the slog of learning a new corporate codebase, the effort involved in learning Haskell isn't that much... and the hope with Haskell is that the next software project you write won't be unmanageable... and I think that even average-case Haskell realizes it. (I focus on the average case because, of course, you can write shitty code in any language and you can write good code in any language, but languages differ in what tends to happen on average.)

I would be interested in your thoughts here because Haskell has always seemed, theoretically, a great fit for me but it has never panned out in practice.

I believe you and I have a common-enough mental framework (theoretical-leaning applied math Ph.D., happy to hold forth on e.g. algebraic geometry, information theory, nonlinear dynamical systems etc.). I look at Haskell and it certainly feels clean and beautiful like all the mathematics that I love. But then I try to use it and, objectively, I get less done (even though I knew what an endofunctor was before even seeing Haskell!).

My longest stretch of trying to use Haskell every day was about 3 months at which point I was still substantially less productive than my preferred mix of C/Python/Lua (I mainly do heavy-lifting numerical work coupled with low-latency server designs). I also feel like I get more done in OCaml.

So, you being someone whom I identify as similar in skills to myself, I ask you: what gives? :-)

I've never taken a calculus class and I'm very productive in Haskell. Maybe knowing all of the applied Math and that there is a better solution available in Haskell keeps you from being productive?

I take the route of solving problems the first (or second) way I come up with, then take advantage of how easy it is to refactor Haskell code when I have a better solution later.

For instance I didn't understand Monads too well while writing my first Haskell program and just did everything in continuation passing style.

Haskell took me a while, because there weren't many great resources on how to write many kinds of "real" code in Haskell. The quality of material is getting steadily better.

I think you've got a good 6-12 months before Haskell is more productive for you than OCaml or a C/Python/Lua stack. If you're coming from Java, you're more productive than you were at 1 month in Haskell (you still know very little Haskell, but you're pwning your former Java-toting self)... but in your case, you already know quite a few high-level languages. So it's not surprising that you get less done in a language that forces you to contend with monads (which aren't as hard as they're made out to be, but they're one more new concept) just to have state. If you're coming from Java, you're more productive in Haskell almost instantaneously, before you really even know it. If you're coming from Python, you're less productive day-by-day because the compiler keeps burning you, but you find long-term development going faster due to fewer code breakages. If you're coming from Ocaml... the short answer is that they're both great languages with more in common than not (although I prefer Haskell) so it's not surprising that it takes a while to get up to your prior speed (because your prior speed is so much higher than that of someone from Java).

Real World Haskell is a good book, though a bit slow and dated. Learn You a Haskell is a decent intro book but it has some gaps. I'm working on a Summer Haskell Course at my company and will be publishing the slides. And Chris Allen recommends the CS 194 course that Penn offers (you can find it online). Resources are out there.

I think you've got a good 6-12 months before Haskell is more productive for you than OCaml or a C/Python/Lua stack.

Though merely anecdotal, that data point eases my mind a bit. I come from Assembler, Lisp, C, OCaml, so maybe my difficulties are par for the course.

Well, depending on your problems, Haskell may simply not be the correct answer. It shines complex behavior for example, but "numerical work" normally means simple behavior (but highly optimized), and I'd be wary of it on low latency applications.

Haskell is powerful, but won't solve all the problems on the world.

This is an excellent point and maybe you gave me a good compact summary of the situation. Perhaps you can tell me if you agree.

The kind of work I do tends to involve a small number of low-variability data types, and the ROI on complex logic (w.r.t. computational performance) has to be very high for it to be accepted into a project. We don't shy away from complex logic, but we do have a high hurdle for it to cross before it becomes a net win.

In contrast, Haskell is perhaps best for large numbers of high-variability datatypes where complex logic is inevitable, regardless of performance costs. And it helps precisely by encoding as much of the complex logic (e.g. safety rules) into the variability and expressiveness of the type system.

I guess all that may be obvious, in hindsight. But I think your comment helped me crystallize the distinction. So, thanks :)

That's what I was trying to say (and much more precise).

Yet, I'd look at codygman's answer. It's a library that tries to improve memory locality by using more complex logic, and hides everything under Haskell abstractions so it's easy to use.

I'm not currently working on this area, so I can't really tell what it's good for.

> Well, depending on your problems, Haskell may simply not be the correct answer. It shines complex behavior for example, but "numerical work" normally means simple behavior (but highly optimized)

To give a rebuttal to Haskell not being good for "numerical work", you might be interested in this pre-alpha numerics library:

https://github.com/wellposed/numerical#performance-faq

I'm tempted to agree with you re: low latency, then I run across stuff like this:

https://github.com/tomahawkins/atom

I believe it (or a similar library) are used in quite a few of a certain companies (or multiples) flagship applications, though I can't recall the details.

Reply on news.ycombinator.com