3 ms·

In our startup due to earlier experience working with pandoc, we tried to give Haskell a try. It was very difficult for team to pick up and then they took long

In our startup due to earlier experience working with pandoc, we tried to give Haskell a try. It was very difficult for team to pick up and then they took longer to accomplish very little. It did drain out confidence and make us think, we are not so clever. So later moved to Python, and suddenly things changed. In the meantime on personal level at present learning lisp. Once finish will try to work on Haskell again. I think Haskell along with lisp will be good on learning functional programming for my team. It will help them solve logical problems using functional paradigm as well. So in future they can pick up procedural or functional paradigm to solve logical problems better suited to problem at hand.

willtim 7y ago
There is unfortunately a large learning curve for production Haskell. It's a very different language to most imperative object-oriented ones, that are all broadly very similar. However, the concepts that folks will learn (Monads, Monoids, Functors, Profunctors etc etc) are taken from math and will likely be around for another 100 years. This is not disposable knowledge, and for me at least, it made a refreshing change from learning ad-hoc concepts from each successive OO fad framework I had to deal with.
- alephu5 7y ago
  I have been learning Haskell from these two books over the last 4 months: "Practical Haskell by Alejandro Serrano" and "Practical Web Development with Haskell" by Ecky Putrady. With other languages I usually just skim through a book figuring out how the basic data structures, flow control and operations then start writing a toy CLI app or server but with haskell I felt completely lost when trying to follow examples in library documentation, even after several weeks of reading books. So I found it's really worth carefully going through the programming book and doing the exercises, at least beyond the monad transformers section, before diving into real code. I'm over the hump and am writing & understanding working code now, but still a long way from the level of mastery I have with imperative programming.
  - ratww 7y ago
    I think the problem with Haskell are not the concepts per se, but rather the terrible ergonomics (too many cryptic operators, point-free syntax, language extensions) and TERRIBLE learning material. Monads, for instance, are hard to invent but are easier to use than most libraries. Most people won't come up with Monads and will only consume them. But books and Monad tutorials focus instead on explaining what they are and how they were invented. This is unnecessary. Another problem is that the coolest things (monads, lenses, syntax extensions) are bolt-on, rather than built-in. So we compromise syntax (and sometimes consistency) in the name of extensibility. Such fundamental things should be in the StdLib. This is the same problem Javascript suffers from. I strongly believe that a new language with the same semantics but a more approachable syntax and better learning materials (like Python) would be way more successful. Maybe that's OCaml but I'm not too experienced in it.
    - vkazanov 7y ago
      Syntax-wise Ocaml is waaaay weirder than Haskell. In fact, Haskell is a pretty typical representative of the whole ML language family, with StandardML being the cleanest of them all.
      - ernst_klim 7y ago
        Actually, OCaml is much closer to the original ML that SML.
choeger 7y ago
> It did drain out confidence and make us think, we are not so clever. I don't want to sound arrogant, but maybe that is the truth right here? Maybe what you struggled with was not what you should have actually done the way you did? I see everyday that "quick" solutions in Python are woefully incomplete and tend to just ignore the complicated corner cases. You don't get away with that in Haskell in my experience. So maybe you just underestimated your problem domain? I understand that the ecosystem of Haskell is much smaller than for instance python, but an experienced programmer should recognize that. So if your team struggled it could indicate that your initial specification was just too shallow?
- dragonsh 7y ago
  No you don't sound arrogant, our team is still learning. You are right we shouldn't have approached the way we did due to inexperience. My team only did C, C++ and bit of Java in University and majority of the things they learned were more object oriented and procedural programming. As none of them were trained in haskell, it took them a while to get to do anything. Moreover we were just working on web application bakcend, so they felt instantly productive in Python. We were not cracking compiler or some hard computer science problem, we were just doing run of the mill web application like Amazon marketplace. So I said may be in future may try Haskell. Right now on a personal level trying lisp.
  - speedplane 7y ago
    > No you don't sound arrogant, our team is still learning. ... So I said may be in future may try Haskell. I'm conflicted as to whether functional programming like Haskell a right business solution to real-world problems. Businesses need to hire developers, and almost all of them taught procedural programming in school. Is functional programming innately more intellectual / hard to grasp than procedural programming? Or is it just not taught enough in school? I'm not really sure. Procedural programming more closely matches the real world with one thing happening after the next. Functional programming more closely matches math with one thing represented as a transformation of another. To me, one does not seem any more difficult than another, but clearly, many more devs understand procedural programming better than functional. In a real-world business, you need to hire developers with the skills they have. Junior devs are far more comfortable in procedural programming than functional programming. Most businesses can't afford a team of senior devs. So regardless of whether one is easier/harder/better/etc., we get procedural programming, not functional.

willtim 7y ago

There is unfortunately a large learning curve for production Haskell. It's a very different language to most imperative object-oriented ones, that are all broadly very similar. However, the concepts that folks will learn (Monads, Monoids, Functors, Profunctors etc etc) are taken from math and will likely be around for another 100 years. This is not disposable knowledge, and for me at least, it made a refreshing change from learning ad-hoc concepts from each successive OO fad framework I had to deal with.

alephu5 7y ago
I have been learning Haskell from these two books over the last 4 months: "Practical Haskell by Alejandro Serrano" and "Practical Web Development with Haskell" by Ecky Putrady. With other languages I usually just skim through a book figuring out how the basic data structures, flow control and operations then start writing a toy CLI app or server but with haskell I felt completely lost when trying to follow examples in library documentation, even after several weeks of reading books. So I found it's really worth carefully going through the programming book and doing the exercises, at least beyond the monad transformers section, before diving into real code. I'm over the hump and am writing & understanding working code now, but still a long way from the level of mastery I have with imperative programming.
- ratww 7y ago
  I think the problem with Haskell are not the concepts per se, but rather the terrible ergonomics (too many cryptic operators, point-free syntax, language extensions) and TERRIBLE learning material. Monads, for instance, are hard to invent but are easier to use than most libraries. Most people won't come up with Monads and will only consume them. But books and Monad tutorials focus instead on explaining what they are and how they were invented. This is unnecessary. Another problem is that the coolest things (monads, lenses, syntax extensions) are bolt-on, rather than built-in. So we compromise syntax (and sometimes consistency) in the name of extensibility. Such fundamental things should be in the StdLib. This is the same problem Javascript suffers from. I strongly believe that a new language with the same semantics but a more approachable syntax and better learning materials (like Python) would be way more successful. Maybe that's OCaml but I'm not too experienced in it.
  - vkazanov 7y ago
    Syntax-wise Ocaml is waaaay weirder than Haskell. In fact, Haskell is a pretty typical representative of the whole ML language family, with StandardML being the cleanest of them all.
    - ernst_klim 7y ago
      Actually, OCaml is much closer to the original ML that SML.

choeger 7y ago

> It did drain out confidence and make us think, we are not so clever. I don't want to sound arrogant, but maybe that is the truth right here? Maybe what you struggled with was not what you should have actually done the way you did? I see everyday that "quick" solutions in Python are woefully incomplete and tend to just ignore the complicated corner cases. You don't get away with that in Haskell in my experience. So maybe you just underestimated your problem domain? I understand that the ecosystem of Haskell is much smaller than for instance python, but an experienced programmer should recognize that. So if your team struggled it could indicate that your initial specification was just too shallow?

dragonsh 7y ago
No you don't sound arrogant, our team is still learning. You are right we shouldn't have approached the way we did due to inexperience. My team only did C, C++ and bit of Java in University and majority of the things they learned were more object oriented and procedural programming. As none of them were trained in haskell, it took them a while to get to do anything. Moreover we were just working on web application bakcend, so they felt instantly productive in Python. We were not cracking compiler or some hard computer science problem, we were just doing run of the mill web application like Amazon marketplace. So I said may be in future may try Haskell. Right now on a personal level trying lisp.
- speedplane 7y ago
  > No you don't sound arrogant, our team is still learning. ... So I said may be in future may try Haskell. I'm conflicted as to whether functional programming like Haskell a right business solution to real-world problems. Businesses need to hire developers, and almost all of them taught procedural programming in school. Is functional programming innately more intellectual / hard to grasp than procedural programming? Or is it just not taught enough in school? I'm not really sure. Procedural programming more closely matches the real world with one thing happening after the next. Functional programming more closely matches math with one thing represented as a transformation of another. To me, one does not seem any more difficult than another, but clearly, many more devs understand procedural programming better than functional. In a real-world business, you need to hire developers with the skills they have. Junior devs are far more comfortable in procedural programming than functional programming. Most businesses can't afford a team of senior devs. So regardless of whether one is easier/harder/better/etc., we get procedural programming, not functional.