Why Haskell Is Worth Learning
spin.atomicobject.com
spin.atomicobject.com
One selling point, the terseness/simplicity of code, can be a specious one. Beyond the magic of map/flatmap/etc, the things that allow you to achieve terseness in a general sense often require more cryptic constructs as scaffolding.
One developer friend made a comment that summarizes functional languages well in practice: "They're very useful, but try to avoid code that requires your coworkers to know abstract algebra and category theory in order to contribute to a project."
Have you ever learned a 'design pattern' in Java, Python, C++, etc? What's the difference between learning this and learning about monoids (for example). Monoids are super easy and actually compose, unlike the majority of design patterns. In my experience, learning OO design patterns was substantially more difficult than learning algebra, but I think this is mainly due to how CS education is carried out in many universities. I feel if people start with mainly FP, then OOP is what seems odd and necessitating learning odd, abstract concepts, except there's the added bonus that all the abstractions are leaky.
Ultimately though, you don't even need to learn any algebra or category theory. It was multiple years after I had already learned and started using Haskell that I even began to become interested in these topics. My interest was mainly piqued by a desire to not duplicate code -- it certainly isn't required to learn algebra to understand Haskell, in the same way it's not required to understand machine assembly to program in C++, or GPU transistor layout to understand OpenGL.
> a general sense often require more cryptic constructs as scaffolding.
My professional experience is mainly as a Haskell dev. What is 'scaffolding'. I don't think I've ever used such a thing.
I've definitely encountered the abstraction-for-the-sake-of-abstraction types, but those are mainly academics, in my experience.
I mean, monads are (for some reason or the other) the killer feature of Haskell abstraction, and their use case is extremely concrete. map, fold, etc are also motivated by very concrete desires.
Even more advanced concepts, like zippers, generics, lenses, ftpe, etc are all motivated by extremely concrete problems.
> In my experience, learning OO design patterns was substantially more difficult than learning algebra, but I think this is mainly due to how CS education is carried out in many universities.
You supported my argument. In addition to this, there are many code academies that pump out graduates with almost no mathematical foundation work. Until that changes, functional languages will always take the back seat.
If you learn Haskell you will see this is total bollocks.
All software is leaky abstraction because it doesn't run on abstract mathematics, it runs on hardware. I can literally smash it with a hammer and then all the "guarantees" are worthless.
Man, if that were the only thing that could make software go wrong, we would live in a much better world.
Yes, it is. If you don't get this, you'll be a lousy C++ programmer.
Hmmm.... I mean I understand assembly, and did before I was a C++ developer, but really, you don't need to understand assembly to program C++ anymore than you need to know java bytecode to program java. If you stick to defined behavior, the program will work the way you expect it.
Perhaps you mean you need to understand assembly to debug C++ performance issues? I mean that's true of basically any language compiled to native code.
However it is a significant improvement on allowing one to express the constraints in the type system preventing large classes of bugs and towards providing proper abstractions.
Let's not throw the baby out with the bathwater. No one is claiming FP developers are "better" than OO developers. In fact why would anyone ever classify themselves as one or the other? Instead we should use the best tools for the job.
We primarily write libraries, and our 'applications' are more or less throw away code because of how small they end up being (because they can leverage many of our libraries). Testing is easier in functional land (for various reasons), which means regressions are much harder to introduce, which means refactoring can happen faster, which means less technical debt.
If you are proficient in Haskell and willing to relocate, I believe there are some amazing opportunities for you. You'll work with really smart people and be innovating. I see investment banks, startups and defense contractors using this language. Interesting mix.
> you'll find it a hard sell
So was Ruby at some point. But oh boy how much quicker was I writing those web apps in 2005 because of it!
> try to avoid code that requires your coworkers to know abstract algebra and category theory in order to contribute to a project
Good quote. But it does not "summarizes functional languages well" in my opinion. It shows that you should keep the clever stuff in libraries, such that colleagues do not have to trip over it.
I think if you assume 'terseness' is the goal of constructs such as map/flatMap you're missing the forest for the trees. Yes terseness can be a good thing, it sacrifices familiarity for the ability to understand more going on in a quicker amount of time. This can definitely reduce cognitive overheard for someone familiar with the constructs being used.
This however, is a secondary (but pleasant) side effect of the main goal which is (non leaky) abstraction. By using familiar abstractions it allows readers to reason about code in a powerful way, allowing for more reuse and composition.
I would have loved to used Clojure throughout the last 5-6 yrs but never found a company using it in Toronto. I'm sure everyone used the same rationale. The popularity of a language really does have a self-reinforcing aspect to it.
Although there's no guarantee it will always be that way if people really do find the development experience to be superior. Smart devs can learn new languages pretty quickly. I wish Haskell was easier to start using like Go was.
However, on the bright side, at least we're not discussing LISP.
I know a company that tried to hire a Haskell guy to support some existing Haskell software for more than a year with literally two applications.
Just finding professional devs for it seems to be hard.
How true is this? I never seen a FP tutorial that started with this or even mentioned it. Or is this simply an assumption that it should be known before even trying to take Haskell seriously?
I tried supporting haskell from within postgres as a new language for UDFs. I ran into many problems, but perhaps those were more with GHC than haskell itself.
Yeah + years of learning it, but that's not showing up as code. I'm glad he can express that in 4 lines. I'm still not convinced this is a good investment of time. I use functional style in JavaScript, but that's probably the farthest I'm willing to take it at the moment.
> “Do you want to be locked into tricycles because they’re easy to learn?”
That would be great ending quote if the next step he suggest wouldn't be a Penny-farthing.