For all the talk of abstraction by so many programmers, I wonder how many of us just really want metaphors. Ways of organizing and relating to code that are at least vaguely familiar.
But then some programmers start talking about abstract math and category theory, and many people recoil because it is too abstract, or because it is so abstract that it is more general than the most immediately obvious metaphor (Functors are kind of like boxes, but not always. You should think of them like computational contexts instead).
Of course metaphors have their place; there is no need in making things less relatable just because. But at some point you may have to abandon the comfort zone of trucks being a specialization of a more general car blueprint.
I think it's more concrete. FactoryProviderProviderProviders provide a common set of procedures for programmers to provide programs [sorry, second cup of coffee]. All that framework makes the landscape familiar and allows the procedures which worked for generating Java code to work when a person wants to generate JavaScript. It provides space for algorithms for writing programs.
The tradeoff is that it will never be done in a way that optimizes on logical insight. Simple currying would be simpler but the boss still might not understand it, and it's better culturally if the boss doesn't understand sixty lines of boiler plate than twelve lines of mathematical reasoning.
The advantage is that the programmer can know, if I do these things I will get close to the result without worrying over much about the degree to which I might lack deep understanding. On HN there are plenty of people comfortable with the idea of factories as curried dispatch constructors. But that's not the typical case.
Simple currying would be simpler but the boss still might not understand it, and it's better culturally if the boss doesn't understand sixty lines of boiler plate than twelve lines of mathematical reasoning.
That's the whole problem, the notion that "the boss" needs to understand how the code works. OOP patterns are designed to "model" real-world business objects and processes so that they can be documented on a UML diagram that business analysts and managers can look at to grasp how the software works without having to understand how computers work. This is a big reason why the software gets unnecessarily complex--the real world is infinitely complex.
Most of the time, what you actually need the software to do is not nearly as complex, though, so it would be better to just write simpler code that does the thing that needs doing rather than models all the things. But in that case it's harder for the non-technical boss to understand the logic without a handy metaphor.
The layer of abstraction that seems to be most frequently violated in enterprise contexts, is the software developer's job itself.
For whom is the idea that the boss needs to understand the program a problem and why?
The typical answer is for programmers and because then the boss might have specific technical input rather than requirements and under bad management that could be a problem - i.e. keeping the boss from understanding the code is a defence to mitigate bad management which has the added benefit of UML diagrams a likely first place for a bad manager to cut costs.
Much of the last 40 years has seen software engineers exchanging the human parsablility of Cobol for the utter impenetrability of regex's - culminating in Perl which was so impenetrable to even programmers that Java had to be invented. Anyway, the idea that a computer language should allow an intelligent lay person to follow an algorithm written in it died with Cobol. It - the idea not Cobol - might be worth revisiting in language design.
Of course the idea I was trying to express is that the boss will feel better at not understanding 60 lines of boilerplate javascript than not understanding a dozen lines of elegant Haskell.
It's bad for everyone involved because the programmer loses the ability to make decisions about how to structure the program he/she is working on, and the manager and/or business analyst waste lots of time worrying about intricate technical details of someone else's job, when they should be tending to their own responsibilities. It's a violation of separation of concerns and a disrespect for the software developer's domain expertise.
The trend I have seen in enterprise software is that, because good software developers are expensive and in high demand, the business attempts to commoditize them by having lower paid, semi-technical staff (like business analysts) do everything except for write the actual code, limiting the developer's job description to simply translating a diagram and a list of features and business rules into Java--like some sort of human compiler.
That approach is doomed to produce terrible software forever, because you can't write good software without thinking deeply and understanding both the problem to be solved and the tools available to solve it. And you just can't commoditize a job that requires that much thinking.
On the other hand, I do agree that software development needs to be made easier than it currently is. It is currently very hard because the current tools we have are built on layers upon layers of leaky abstractions that still require a highly trained and experienced individual to understand first, in order to be productive. Making programming languages more easily comprehensible to humans, is a big part of that. Programming languages are for humans, after all.
But then some programmers start talking about abstract math and category theory, and many people recoil because it is too abstract, or because it is so abstract that it is more general than the most immediately obvious metaphor (Functors are kind of like boxes, but not always. You should think of them like computational contexts instead).
Of course metaphors have their place; there is no need in making things less relatable just because. But at some point you may have to abandon the comfort zone of trucks being a specialization of a more general car blueprint.