4 ms·

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 bel

by _dps 11y ago

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? :-)

codygman 11y ago
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.
michaelochurch 11y ago
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.
- tempodox 11y ago
  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.
marcosdumay 11y ago
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.
- _dps 11y ago
  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 :)
  - marcosdumay 11y ago
    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.
- codygman 11y ago
  > 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 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 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.

by _dps 11y ago

codygman 11y ago

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.

michaelochurch 11y ago

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.

tempodox 11y ago
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.

marcosdumay 11y ago

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.

_dps 11y ago
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 :)
- marcosdumay 11y ago
  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.
codygman 11y ago
> 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 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 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.