Hacker News Reader

Comment by dragonsh | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

Actually, OCaml is much closer to the original ML that SML.

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

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.

> 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.

It's worth bearing in mind that when writing something side effecting (reading and writing to a database for example) in Haskell, it will be done imperatively.

There's definitely a bias towards the familiar however, it took me a while to get my head around the "FP way" as it were. The frustrating thing is that like you say most people are just trained in procedural programming with often at most minimal contact with anything functional which causes a kind of pressure on the whole industry.

Sure, if you never had any exposure to Haskell, you should probably not start your business with it ;). I wonder though, did the team know what to do and struggled only with the how or did they also struggle with the what and shadowed this problem by doing something (a.k.a. "agile development" ;) )

Reply on news.ycombinator.com