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