9 ms·

I gave haskell a shot as some of my earlier github repos indicate: https://github.com/substack https://github.com/substack. I even wrote my blog in haskell with

I gave haskell a shot as some of my earlier github repos indicate: https://github.com/substack https://github.com/substack. I even wrote my blog in haskell with happstack, since snap hadn't gotten popular yet. Haskell is very hard, but even after 3 years of pretty intensive use, I never really felt productive with haskell in the same way that I've felt in other languages. Anything I did in haskell required a lot of thinking up-front and tinkering in the REPL to make sure the types all agreed and it was rather time-consuming to assemble a selection of data types and functions that mapped adequately onto the problem I was trying to solve. More often than not, the result was something of an unsightly jumble that would take a long time to convert into nicer-looking code or to make an API less terrible to use. I built an underwater ROV control system in haskell in 2010 which went well enough, but I had to tinker with the RTS scheduling constantly to keep the more processor-hungry threads from starving out the other ones for CPU. The system worked, but I had no idea what horrors GHC was performing on my behalf. Later I built the first prototype of my startup with haskell, but the sheer volume of things that I didn't know kept getting in the way of getting stuff done in a reasonable time frame. Then we started to incrementally phase out haskell in favor of node. I write a lot of node.js now and it's really nice. The whole runtime system easily fits into my head all at once and the execution model is simple and predictable. I can also spend more time writing and testing software and less time learning obscure theories so that the libraries and abstractions I use make sense. The point in the article about haskell being "too clever for this benchmark" sums up haskell generally in my experience.

dsharpdiabetes 15y ago
I had a similar experience with Erlang. Node has totally taken over the erlang shaped hole in my life ;)
MatthewPhillips 15y ago
Did you perhaps jump into the water too quickly? I'm currently learning a couple of functional languages (including Haskell) and using it in production environments but my current use is restricted to "I have an input that will always produce a certain output. There are no database or environmental dependencies, this is straight computation. I want to never have to worry about this function ever again". And so far, knock on wood, haskell has been killer for that scenario. I'll probably eventually transition a lot more of my code to functional languages, but will do so slowly (using Go otherwise).
- substack 15y ago
  Haskell is great for pure algorithms like that. As for jumping in too quickly? I was a pretty heavy haskell user for about 3 years.
- danieldk 15y ago
  Haskell is beautiful, I love it, but I can easily see his points. There are a few traps one can easily fall in: - Reach a point in a complex application where it becomes hard to reason what laziness will do to performance. - End up in type-hell. E.g. some libraries extensively use existential quantification of type variables. Before you know it, you are chasing "type variable x would escape its scope"-type or error messages, in perfectly fine looking code. - Pattern matching is nice, but if you extensively use it, adding a constructor argument is a lot of work. - No-one uses the same data type for common things. For instance, for textual data, there is String, Data.Text, Data.Text.Lazy, Data.ByteSting, and Data.ByteString.Lazy. These days there is more or less consensus on when to use which type, but you are often converting things a lot. There are also types of data for which no consensus is yet reached (e.g. lenses). - Artificially pure packages. There are some packages that link to C libraries, but (forcefully) provide a pure interface. (Or in other words: purity is just convention). - For a lot of code you end up using monads plus 'do' notation, making your programs look practically imperative, but an oddball variation of it. - Using functions with worse time or space complexity, to maintain purity. - I/O looks simple, but for predictable and safe I/O you'd usually end up using a library for enumerators. Writing enumerators, enumeratees, and iteratees is unintuitive and weird, especially compared to (less powerful) iterators/generators in other languages. Learning Haskell is something I'd certainly recommend. It provides a glimpse of how beautifully mathematical programs could be in a perfect world. Unfortunately, the world is not perfect, and even Haskell needs a lot of patchwork to deal with it.
  - anothermachine 15y ago
    > Artificially pure packages. There are some packages that link to C libraries, but (forcefully) provide a pure interface. (Or in other words: purity is just convention) Explain? What would the alternative be? > Using functions with worse time or space complexity, to maintain purity. This seems like the opposite of your previous complaint. > For a lot of code you end up using monads plus 'do' notation, making your programs look practically imperative, but an oddball variation of it. This seems to be a "psychological problem" with Haskell: the idea that because Haskell supports declarative, it's not OK to be imperative. It makes beginners tear their hair out looking for 'do'-free solutions when they could just use 'do'. C.f., "Lambda: the Ultimate Imperative" (and the rest of that series of LtU papers) http://dspace.mit.edu/handle/1721.1/5790 http://dspace.mit.edu/handle/1721.1/5790
bobfunk 15y ago
It's pretty much what I mean when calling Haskell hard to learn. For me it's also been a steep learning curve, and my experience hasn't been altogether different than yours. I started out maybe 5 years ago following tutorials, reading up on all the metaphors about Monads and doing project Euler problems. After a while I started to tackle some small web related things with Haskell and had exactly your experience of running into a lack of understanding of how the system works and wrapping my head around functional datatypes. I pretty much gave up on Haskell as a practical language at that point, but something kept me coming back once in a while. Then at a point I had a use for making a small web service fast and the Node prototype I made performed badly and crashed in spectacular ways under high loads. I found Snap and made a quick prototype in Haskell. At that point the experience of years of small experiments must finally have made something click. In a very short time I had a very fast service using almost no memory. It's deployed in production (as a part of http://www.webpop.com http://www.webpop.com) and has been extremely stable. By now I think I've crossed some kind of barrier, and feel like I'm both being productive and having fun when writing Haskell, but it really didn't come easy to me and all else being equal my experience tells me that a good deal of my colleagues would have an even harder time.
- quinedstatement 15y ago
  I recently had that same epiphany. For fun, I decided to re-implement a simple chat server I wrote a while back in Erlang. I found that everything clicked - the type system worked with me instead of against me, and I was able to create prototypes as quickly as I could think of them. But, it took two years of thinking about Haskell before I could synthesize code in it. (code here: https://github.com/dmansen/haskell-chat https://github.com/dmansen/haskell-chat)
- Homunculiheaded 15y ago
  I think part of the issue with learning haskell is that it seems to invert the typical learning strategy for programming languages. Usually the best advice is read a little, then write a lot. Typically you can just look and some published code and go "ah yes that's how you do it". But I find, for better or worse, Haskell really requires you to understand before you code. Which in the end means your study to code ratio is very different than almost any other language. Most languages, even lisps, are somewhat tolerant of 'programming by guessing' for beginners. Usually you write terrible code that works, learn more and see what you did wrong. Haskell is very unforgiving of this, if you don't understand why it works it probably won't
gregwebs 15y ago
I believe you are attributing a library issue to a language. Before today (and by today I literally mean a month ago when Yesod released a cross-platform development server that automatically re-compiles your web application) there wasn't a productive set of libraries and tools to build a web application with in Haskell. 3 years ago when you started, and even until 1-2 years ago the library situation was absolutely horrible. Web frameworks with very little to offer, mediocre templating languages, not even an attempt at a database ORM. Tutorials would have you write a bunch of code to achieve a detail taken for granted in libraries used in web frameworks of other languages. Please take a look at doing real-world, productive web development with Yesod. http://www.yesodweb.com http://www.yesodweb.com You are still going to take a productivity hit in Haskell due to lack of libraries in comparison to Ruby, Python, etc. So the practical reason for using Haskell today is to take advantage of the amazing performance, take advantage of Haskell non-web libraries in the backend, or for a high assurance project where its type system can rule out most common web development bugs. oh, and Yesod is even faster than the mentioned Snap framework which is already much faster than Node (and unlike Haskell, Node does not scale to multi-core). Although Yesod isn't going to automatically cache the fibonacci sequence for this artificial benchmark because in the real world I have never once been tasked with writing code like that for a web application.
- danieldk 15y ago
  I believe you are attributing a library issue to a language. Reasoning about laziness? Polymorphism that can only be implemented using existential types plus Typable? Even purity is a double-edged sword (some algorithms are inherently mutable)[1]. Some of Haskell's problems in real-life projects can definitely be attributed to the language itself. So the practical reason for using Haskell today is to take advantage of the amazing performance, My experience with everything from simple checksum functions to parameter estimators (ML) is that Haskell is generally at least 2-10x slower than C (even when introducing strictness where necessary, unboxing constructors, etc.). So, in practice you'll often end up doing heavy lifting in C anyway (whether it is a database server or a classifier that works in the background), and in the end it doesn't matter so much whether you use Haskell or a dynamic language (performance-wise) if a significant amount of time is required processing requests. where its type system can rule out most common web development bugs Right, this is where Haskell currently has an edge, because it does not only make it easy to make DSLs (as e.g. Ruby), but typechecks everything as well. oh, and Yesod is even faster than the mentioned Snap framework which is already much faster than Node Yes, but the benchmarks you implicitly point to (the pong benchmark) is very synthetic and says fairly little about real-life use. Until we see Snap and Yesod more in production, the jury is still out. [1] Sure, you can do quicksort in the ST monad, but it will require a lot of unnecessary copying.
fab13n 15y ago
I've also never been productive with Haskell. It's cute, it raises interesting problems if you enjoy wrangling with mathy problem for the sake of it, but when it comes to getting stuff done in a deeply imperative, eager world, the impedance mismatch is simply overwhelming. Moreover, I was very proficient in OCaml before I discovered Haskell, and it just spoiled be. It has all of Haskell's qualities which matter (type inference, algebraic data structures, a naturally functional mindset) without the parts you regularly have to fight (mandatory monads and monad transformers, algorithmic complexity in a lazy context, tedious interfacing to the underlying OS). If you felt like Haskell had many amazing qualities, spoiled by a couple of unacceptable flaws, especially when it comes to acknowledging how the real world works, I'd suggest that you give a try to OCaml. You should be proficient with it within a couple of days.

dsharpdiabetes 15y ago

I had a similar experience with Erlang. Node has totally taken over the erlang shaped hole in my life ;)

MatthewPhillips 15y ago

Did you perhaps jump into the water too quickly? I'm currently learning a couple of functional languages (including Haskell) and using it in production environments but my current use is restricted to "I have an input that will always produce a certain output. There are no database or environmental dependencies, this is straight computation. I want to never have to worry about this function ever again". And so far, knock on wood, haskell has been killer for that scenario. I'll probably eventually transition a lot more of my code to functional languages, but will do so slowly (using Go otherwise).

substack 15y ago
Haskell is great for pure algorithms like that. As for jumping in too quickly? I was a pretty heavy haskell user for about 3 years.
danieldk 15y ago
Haskell is beautiful, I love it, but I can easily see his points. There are a few traps one can easily fall in: - Reach a point in a complex application where it becomes hard to reason what laziness will do to performance. - End up in type-hell. E.g. some libraries extensively use existential quantification of type variables. Before you know it, you are chasing "type variable x would escape its scope"-type or error messages, in perfectly fine looking code. - Pattern matching is nice, but if you extensively use it, adding a constructor argument is a lot of work. - No-one uses the same data type for common things. For instance, for textual data, there is String, Data.Text, Data.Text.Lazy, Data.ByteSting, and Data.ByteString.Lazy. These days there is more or less consensus on when to use which type, but you are often converting things a lot. There are also types of data for which no consensus is yet reached (e.g. lenses). - Artificially pure packages. There are some packages that link to C libraries, but (forcefully) provide a pure interface. (Or in other words: purity is just convention). - For a lot of code you end up using monads plus 'do' notation, making your programs look practically imperative, but an oddball variation of it. - Using functions with worse time or space complexity, to maintain purity. - I/O looks simple, but for predictable and safe I/O you'd usually end up using a library for enumerators. Writing enumerators, enumeratees, and iteratees is unintuitive and weird, especially compared to (less powerful) iterators/generators in other languages. Learning Haskell is something I'd certainly recommend. It provides a glimpse of how beautifully mathematical programs could be in a perfect world. Unfortunately, the world is not perfect, and even Haskell needs a lot of patchwork to deal with it.
- anothermachine 15y ago
  > Artificially pure packages. There are some packages that link to C libraries, but (forcefully) provide a pure interface. (Or in other words: purity is just convention) Explain? What would the alternative be? > Using functions with worse time or space complexity, to maintain purity. This seems like the opposite of your previous complaint. > For a lot of code you end up using monads plus 'do' notation, making your programs look practically imperative, but an oddball variation of it. This seems to be a "psychological problem" with Haskell: the idea that because Haskell supports declarative, it's not OK to be imperative. It makes beginners tear their hair out looking for 'do'-free solutions when they could just use 'do'. C.f., "Lambda: the Ultimate Imperative" (and the rest of that series of LtU papers) http://dspace.mit.edu/handle/1721.1/5790 http://dspace.mit.edu/handle/1721.1/5790

bobfunk 15y ago

It's pretty much what I mean when calling Haskell hard to learn. For me it's also been a steep learning curve, and my experience hasn't been altogether different than yours. I started out maybe 5 years ago following tutorials, reading up on all the metaphors about Monads and doing project Euler problems. After a while I started to tackle some small web related things with Haskell and had exactly your experience of running into a lack of understanding of how the system works and wrapping my head around functional datatypes. I pretty much gave up on Haskell as a practical language at that point, but something kept me coming back once in a while. Then at a point I had a use for making a small web service fast and the Node prototype I made performed badly and crashed in spectacular ways under high loads. I found Snap and made a quick prototype in Haskell. At that point the experience of years of small experiments must finally have made something click. In a very short time I had a very fast service using almost no memory. It's deployed in production (as a part of http://www.webpop.com http://www.webpop.com) and has been extremely stable. By now I think I've crossed some kind of barrier, and feel like I'm both being productive and having fun when writing Haskell, but it really didn't come easy to me and all else being equal my experience tells me that a good deal of my colleagues would have an even harder time.

quinedstatement 15y ago
I recently had that same epiphany. For fun, I decided to re-implement a simple chat server I wrote a while back in Erlang. I found that everything clicked - the type system worked with me instead of against me, and I was able to create prototypes as quickly as I could think of them. But, it took two years of thinking about Haskell before I could synthesize code in it. (code here: https://github.com/dmansen/haskell-chat https://github.com/dmansen/haskell-chat)
Homunculiheaded 15y ago
I think part of the issue with learning haskell is that it seems to invert the typical learning strategy for programming languages. Usually the best advice is read a little, then write a lot. Typically you can just look and some published code and go "ah yes that's how you do it". But I find, for better or worse, Haskell really requires you to understand before you code. Which in the end means your study to code ratio is very different than almost any other language. Most languages, even lisps, are somewhat tolerant of 'programming by guessing' for beginners. Usually you write terrible code that works, learn more and see what you did wrong. Haskell is very unforgiving of this, if you don't understand why it works it probably won't

gregwebs 15y ago

I believe you are attributing a library issue to a language. Before today (and by today I literally mean a month ago when Yesod released a cross-platform development server that automatically re-compiles your web application) there wasn't a productive set of libraries and tools to build a web application with in Haskell. 3 years ago when you started, and even until 1-2 years ago the library situation was absolutely horrible. Web frameworks with very little to offer, mediocre templating languages, not even an attempt at a database ORM. Tutorials would have you write a bunch of code to achieve a detail taken for granted in libraries used in web frameworks of other languages. Please take a look at doing real-world, productive web development with Yesod. http://www.yesodweb.com http://www.yesodweb.com You are still going to take a productivity hit in Haskell due to lack of libraries in comparison to Ruby, Python, etc. So the practical reason for using Haskell today is to take advantage of the amazing performance, take advantage of Haskell non-web libraries in the backend, or for a high assurance project where its type system can rule out most common web development bugs. oh, and Yesod is even faster than the mentioned Snap framework which is already much faster than Node (and unlike Haskell, Node does not scale to multi-core). Although Yesod isn't going to automatically cache the fibonacci sequence for this artificial benchmark because in the real world I have never once been tasked with writing code like that for a web application.

danieldk 15y ago
I believe you are attributing a library issue to a language. Reasoning about laziness? Polymorphism that can only be implemented using existential types plus Typable? Even purity is a double-edged sword (some algorithms are inherently mutable)[1]. Some of Haskell's problems in real-life projects can definitely be attributed to the language itself. So the practical reason for using Haskell today is to take advantage of the amazing performance, My experience with everything from simple checksum functions to parameter estimators (ML) is that Haskell is generally at least 2-10x slower than C (even when introducing strictness where necessary, unboxing constructors, etc.). So, in practice you'll often end up doing heavy lifting in C anyway (whether it is a database server or a classifier that works in the background), and in the end it doesn't matter so much whether you use Haskell or a dynamic language (performance-wise) if a significant amount of time is required processing requests. where its type system can rule out most common web development bugs Right, this is where Haskell currently has an edge, because it does not only make it easy to make DSLs (as e.g. Ruby), but typechecks everything as well. oh, and Yesod is even faster than the mentioned Snap framework which is already much faster than Node Yes, but the benchmarks you implicitly point to (the pong benchmark) is very synthetic and says fairly little about real-life use. Until we see Snap and Yesod more in production, the jury is still out. [1] Sure, you can do quicksort in the ST monad, but it will require a lot of unnecessary copying.

fab13n 15y ago

I've also never been productive with Haskell. It's cute, it raises interesting problems if you enjoy wrangling with mathy problem for the sake of it, but when it comes to getting stuff done in a deeply imperative, eager world, the impedance mismatch is simply overwhelming. Moreover, I was very proficient in OCaml before I discovered Haskell, and it just spoiled be. It has all of Haskell's qualities which matter (type inference, algebraic data structures, a naturally functional mindset) without the parts you regularly have to fight (mandatory monads and monad transformers, algorithmic complexity in a lazy context, tedious interfacing to the underlying OS). If you felt like Haskell had many amazing qualities, spoiled by a couple of unacceptable flaws, especially when it comes to acknowledging how the real world works, I'd suggest that you give a try to OCaml. You should be proficient with it within a couple of days.