The sad thing is nobody ever makes that complaint when talking about everything you'd need to know to build a bridge, or to place an IV, or even to build a table. There's a huge part of the software community that's self taught, but also a gigantic part with degrees in computer science. If there was enough value in these ideas and critical mass of wide adoption, we could just add it to the curriculum, and it'd just be yet another of those things you need to learn to get into the software industry.

>The sad thing is nobody ever makes that complaint when talking about everything you'd need to know to build a bridge

If we're talking about the software engineering equivalent of bridges, I think it would be much more valuable add TLA+ or similar to the curriculum.

Why not both? They are not mutually exclusive and they both would advance the status quo.

If there was unlimited time, sure.

OP was complaining about having to understand Functors, Monoids, etc... like they are nuisances in the way of writing real code. In response 6gvONxR4sf7o and I were saying that programmers really ought to be taught these incredibly useful abstractions. After more than a decade of coding professionally in popular languages and then 4 years of writing Haskell I cannot begin to tell you how amazing it is that we have these abstractions to rely on. There are virtually endless data types out there and instead of having to study each and every one of them I can just look at whether something is a Monoid and immediately know that I can append them and there is a unit. I can look at whether something is a Functor and immediately know that I can map any function over it. I only need to know a few of these generic patterns and "magically" I can write functions that operate on any of the countless data structures out there. This is true code reuse. Not teaching these to future programmers, not exploiting the timeless, powerful knowledge behind these is in my opinion a disservice to them.

I've been writing Haskell for 12 years so I'm aware of the abstractions it offers. At the end of the day though, either we're building a bridge or we're not.

If we're building a bridge (i.e. a distributed database, a real time system, fly by wire system, etc.) Haskell is useless if for no other reason than how it does memory allocation.

Dependent types are also a dead end for building bridges in my opinion. Proving any non trivial invariants is basically impossible in the real world (http://web.archive.org/web/20200113205635/http://blog.parall...).

And even if it wasn't, dependent types are for a program. But our "bridges" aren't programs, they're systems! If there's one thing that the Haskell community don't understand, it's that. The scary issues that crop up in large scale distributed systems aren't from the nodes, they're from the edges. So any system of correctness that is focused on the nodes [i.e. type systems] is avoiding the real issue.

That's the power of TLA+ by the way. By modeling the system, you have a specification that gives you some confidence what you're building is correct before beginning to implement your bridge.

And if we're not building a bridge? The business doesn't really care about correctness, they care about shipping features. Rollbacks are an acceptable cost. Our job is to sit down and bang out a solution to the problem at hand, not build the perfect abstraction to the problem. When we use languages like Haskell, we take that power out of product's hands.

At work we're building a novel DSL and its ecosystem for a specific industry. Not sure if you consider that a bridge or not, the naive part of me likes to think it's akin to one but maybe i'm deluding myself. Of course we could use any language under the sun but imho Haskell is a really great fit for this project. It also helped hiring some truly great talent (I'm the hiring manager for this team so I know first hand). I don't have much experience with TLA+. From the little I know and learnt about it over the years I think it's brilliant which is why i agreed it should be taught and used more. For the record I've also been involved in multiple large-scale micro-service-obsessed projects in the past, none of them used Haskell or TLA+ and they all were a terrible mess of hidden entangled complexity. Not sure if there's any takeaway just an anecdote.

Honestly, there is already too damn much stuff to learn to get into the software industry.

One can make a point in that senior developers could use different tools than juniors. That happens on other industries, and development avoids it like the plague, with clearly bad consequences. But the industry will never standardize on high-knowledge tools.

That sentiment is so strange to me. There's a ton to learn to get into the industry, but "too much" requires some real thought. If an extra month of full time study could fix some software issue 95% of the time, are there any issues that you can think of that would be worth raising the bar? I'm not advocating that learning monads is the thing, but that a high barrier to entry isn't in and of itself bad.

I sincerely hope that software as a field matures to the point where maybe 50 years from now, hiring most of us working in it with our knowledge today would be like hiring a mathematician who never learned calculus.

What software issue does category theory and abstract algebra solve?

Don't get me wrong, it's cool and it has expanded my appreciation and understanding of math. But I just don't see what engineering problem it's solving besides mathematical elegance.

If you're thinking monads and IO -- separating side effects is nice and useful, but it doesn't solve any real problem IMO. It's not like people are losing sleep because they don't know which code is side effecting. Side effects are where a lot of engineering complexity is, but IO doesn't wrangle it much better than anything else. Maybe Erlang does the best job at it IMO.

And plus monads don't compose. Algebraic effects (ie multicore Ocaml), or even Actors, does "IO" in a better way without the math jargon.

> It's not like people are losing sleep because they don't know which code is side effecting

I’m pretty sure many people are, since this will be a likely cause of them losing money in their businesses. They could be losing money directly, and they could be losing money as a consequence of having to invest more developer time in solving unexpected effectful behaviour.

In fact, I can think of one comedic case where a programmer literally lost sleep because he programmed his garage door to respond to HTTP GET requests, instead of POST requests which are conceptually meant to be the ones that are effectful.

I always found the IO barrier a good distinction at code level. In fact, I started to work on something to that end for Elixir because of it.

Monads come with their own share of problems that's true. Composability isn't really one of them in my opinion though, we got transformers for that purpose.

> What software issue does category theory and abstract algebra solve?

They address (not solve) the problem of lack of code reuse. I have never seen a language where I can put to use so much code written elsewhere without knowledge of my particular use case. They also address the problem of reasoning about the behaviour of code being difficult.

I think it's true that there's too much in the way of faddy tools and products, frameworks, libraries, ecosystems.. and at the same time people are perhaps not investing enough into theory/fundamentals.

Where programming languages fit on this spectrum is a bit controversial. I think most people treat learning a programming language as an ecosystem problem, but that's only because these people tend to consider only mainstream languages that just don't have a lot going for them in the "language proper."

The result seems to be that if you propose a programming language a competent programmer can't pick up in a weekend or three (mostly by learning the syntax & types and then just applying prior knowledge from other languages), there's going to be a lot of complaining and whining about it. Maybe it's justified as long as we don't see advanced languages that really change software engineering in a big way; 'til then, a language is just another (more or less faddy) tool.

If we had a language that could offer guaranteed productivity boost (without any nasty tradeoffs other than the required up-front mental investment) for anyone who takes a few months to study it, then hell yes we should!

So it boils down to: is there really enough values in those ideas or not? I think not, or else both academia and the entire industry is just extremely dumb for not seeing that value. And I'm dumb too :(

The other point to note is that some valuable concepts just slowly creep into mainstream languages over time. Like mainstream languages today have a decent set of constructs that you primarily associated with functional languages 2-3 decades ago. Those things are probably not valuable enough in isolation to justify switching languages.

> So it boils down to: is there really enough values in those ideas or not?

Up front, it depends one which ideas "those ideas" are. If you're referring to monads etc, I don't know. It's not obvious to me either way. In the broader sense, I hope what we're seeing with things like rust's ownership stuff, or haskell's hardcore folks dreaming up new ways to do generic things soundly, the zig and co folks separating compile time code from runtime code, or even the bleeding edge dependent type folks letting you write provably correct code, I hope it's just the beginning. In terms of programming language developments, it seems like there are a lot of new ideas happening now. It's not that academia and the industry are dumb, it's just that this shit is hard and we're just starting. So I worry when I see "it's another thing to learn, and there's already to much, so no" as a justification against the hard parts in new ideas. I can't wait to see what the next few decades of languages and tooling bring us. Who cares whether it means we have to study?

> I think not, or else both academia and the entire industry is just extremely dumb for not seeing that value.

I don’t think we should discount that possibility, although I don’t think it’s true that academia doesn’t see the value in more sophisticated technology.

Industry, yes. I can accept the idea that a large proportion of industry is just extremely dumb. This isn’t an original idea though.

A month is probably enough to learn the meaning of those terms, and how to implement instances of them... but for learning how to actually apply them on real code, an year is more likely.

Most professions require less than an year of training in total, the ones that require more training have less employment positions and command better salaries. You want software development to migrate up, with good salaries to few people, and the industry is stubborn in pushing it down, with low salaries to many people. But both of those options are bad, software development has a huge amount of possibilities, that can only be exploited by employing many people, and also has a huge reward for competence; it needs to spread through all the spectrum.

A world where software developers were are few as mathematicians would be a very boring one.

> But... most people who look into Haskell lose steam as soon as they realize they actually must understand functors, applicative functors, monoids, monads, and (god forbid) lens-things like prisms, traversals, isos, etc. to do anything useful.

Why? Why does everyone think that you have to understand the mathematical underpinnings of Haskell to program in it, but not that you have to understand the assembler to which C compiles to program in it, or the internals of your car's engine to drive it?

Of course, in each of these cases, someone who has that knowledge will probably have some power available that will be denied to those who don't; but that doesn't mean you can't use it. The great thing about this mathematical knowledge is that it can be filled in on demand, and, unlike a lot of knowledge that you don't even know you don't have, when you realise you want to understand what these objects are, you've already got the terminology to look it up in research papers.

Those abstractions are like the steering wheels and pedals for Haskell, not like the car's engine.

> Those abstractions are like the steering wheels and pedals for Haskell, not like the car's engine.

Agreed, but you also don't have to understand anything about the mechanics of the steering wheels and pedals to drive a car, only about when to use which. Monads and other scary-sounding terminology are the same. People really do know these patterns from other programming languages, and attaching a name might be scary, but it doesn't make them intrinsically harder. On the contrary, it makes it easier for people who want to peer into the theoretical internals to do so—though no one has to do it.