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