[kangdolit]

It is worth learning, but the chances of using it for more than toy scripts are slim. Unless your workplace has already bought into it, you'll find it a hard sell. There are several other functional languages out there with more vibrant communities that have useful libraries.

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

[tathougies]

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

[vinylkey]

A monad is just a monoid in the category of endofunctors, what's the problem?

[mrob]

Design patterns are usually taught by describing several example problems, and then introducing the design pattern as something to solve all of them. The value of the abstraction is obvious. Haskell is more often taught as though flexible abstraction is an end in itself, and practical uses for it are somehow distasteful. This teaching style only appeals to people who think mathematics is "elegant" or "beautiful" instead of just a useful tool.

[tathougies]

Perhaps you're reading the wrong documentation. I've personally never found it that way. Most documentation on hackage is very concrete, and for the ones that aren't (i.e., lens), there are plenty of tutorials.

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.

[kangdolit]

"All non-trivial abstractions, to some degree, are leaky." - Joel Spolsky

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

[lmm]

> "All non-trivial abstractions, to some degree, are leaky." - Joel Spolsky

If you learn Haskell you will see this is total bollocks.

[mrob]

What's the Haskell code for preventing me touching the power switch?

[runT1ME]

I think you fundamentally misunderstand what the word abstraction means and the point of it.

[lmm]

Touching the power switch will not lead to an incorrect result being returned.

[mrob]

A late result is an incorrect result in real-time systems. And if time isn't an issue, what's the Haskell code that stops me overclocking the CPU enough to make it unreliable?

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.

[tempodox]

> it's not required to understand machine assembly to program in C++

Yes, it is. If you don't get this, you'll be a lousy C++ programmer.

[tathougies]

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

[nightski]

It's not like you avoid the problem by going to languages with less foundation in math. You just tend to end up with leaky abstractions (which break the laws found in this math disdained so much) and hard to maintain code (technical debt). It might be worth the trade off some times but we do waste a lot of time on this. Probably more than it would take to learn these concepts.

[kangdolit]

I've seen just as many FP projects strain under technical debt as I have OO projects. Technical debt is a product of the developers, not the language. And FP developers are just as imperfect as OO developers.

[nightski]

We have not invented a language that is immune to technical debt or leaky abstractions. Haskell's type system is not rich enough to let us impose all the constraints implied by the mathematics.

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.

[dkarl]

There is a kind of technical "debt" imposed when you can't express the simplest solution in a straightforward way in the language you're using. I put "debt" in quotes because in a strict sense it isn't really debt, because you can't escape the payments by paying off the principle. It's more like a tax that drains away a portion of your effort every time you touch the code.

[runT1ME]

I find this claim dubious. I have been in the industry a long time and I have found the opposite.

[ddito]

Could you elaborate?

[runT1ME]

I've worked on teams of various sizes and skills writing OO applications and trying to use inheritance and OO to get code reuse is always a nightmare. I currently work on large project with hundreds of Scala engineers of various abilities, and structuring our code in functional ways has bought us a ton of reuse and prevented a lot of technical debt.

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.

[cies]

> the chances of using it for more than toy scripts are slim

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.

[kangdolit]

Ruby was a hard sell, but not Rails, which is how Ruby slipped into the fold.

[runT1ME]

>Beyond the magic of map/flatmap/etc, the things that allow you to achieve terseness

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.

[dmix]

Well, the more people learn it the more this answer is less true. So there's also that.

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.

[PopsiclePete]

I haven't written a single non-toy Haskell line, but I really believe it's somehow made me a better programmer overall. Few languages can do that.

[WillPostForFood]

Haskell does have some corporate adoption. Facebook uses it, and one of their Clojure based projects just switched over to Haskell.

https://wit.ai/blog/2017/05/01/new-duckling

[ajsdlfkjklasdj]

This is the common generic response to Haskell evangelism. It's so boring and yet yields so many responses because of its provocativeness.

[kangdolit]

I agree. It's because Haskell evangelism is often the tech equivalent of gluten-free or vegetarianism - It's great because it's something not mainstream! It'll solve problems you never knew you had!

However, on the bright side, at least we're not discussing LISP.

[dom0]

> Unless your workplace has already bought into it, you'll find it a hard sell.

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.

[nbouscal]

My company just hired a Haskell developer; it took less than a month and we had plenty of highly qualified applicants. It actually made us reconsider how many engineers we were planning to hire, because it was easier than we expected. By comparison, we also have Ruby code, and finding equally talented Ruby developers has been much more difficult.

[haskellandchill]

Well they did a bad job. The market is flooded with decent Haskell devs right now.

[kowdermeister]

> ...know abstract algebra and category theory

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?