Universities are failing us.
From a paper entitled Parameterized Notions of Computation:
Examples of such are composable continuations, side-effects where the type of the state varies and input/output where the range of inputs and outputs varies. By also considering structured parameterisation, we extend the range of effects to cover separated side-effects and multiple independent streams of I/O. We also present two typed λ-calculi that soundly and completely model our categorical definitions — with and without symmetric monoidal parameterisation — and act as prototypical languages with parameterised effects.
Whoa! Pretty heavy reading. Now let's look at a description of Moose from the manual:
Moose is a complete object system for Perl 5. Consider any modern object-oriented language (which Perl 5 definitely isn't). It provides keywords for attribute declaration, object construction, inheritance, and maybe more. These keywords are part of the language, and you don't care how they are implemented.
Moose aims to do the same thing for Perl 5 OO. We can't actually create new keywords, but we do offer "sugar" that looks a lot like them. More importantly, with Moose, you define your class declaratively, without needing to know about blessed hashrefs, accessor methods, and so on.
Assuming you know Perl, that's pretty accessible. But looking at the first definition, what's "symmetric monoidal parameterisation"? I have no idea. The thing is, that's OK. I'm not the target audience.
I admit that I've been very annoyed at times with articles which present really cool ideas but do so in such tedious language that I can't follow it, but if it's not aimed at me, I can't blame the author. Other times we have works aimed at casual users, but the author fails to adequately address that.
So what I see a lot of is "comp-sci" people sneering at us for not using their elegant and beautiful tools and "I have stuff to do" people who sneer at those would don't understand the risks of implementing production code that you can't find developers for. This is unfortunate. To a certain extent, I see this as the divide between theoretical and experimental physicists. The first come up with grand ideas and the second cuts 'em off at the knees.
A better analogy, though, would be the difference between theoretical and applied physics. The former thinks about how things work. The second has to make things work. Neither can really function at peak efficiency if they don't have some grounding in what the other does.
In programming, I'm still struck by a comment that a really good programmer I know made about the Liskov Substitution Principle. He said "yeah, it's good in theory". In practice, we had some methods which had varying interfaces and we were using if/else statements to catch the differences. Admittedly, Liskov is sometimes problematic to apply because real-world conditions don't always map well to a class hierarchy, but like "using strict", you need to understand why it's important and, crucially, why you're not using it.
The problem here is ultimately the issue which Joel Spolsky has regarding "Java Schools". It's not Java per se which is the problem. It's the fact that people are learning to be McProgrammers and some programmers are turning out incomprehensibly complex frameworks that McProgrammers can't use, but are still aimed at them.
It's a serious divide in the software world. Many excellent "comp-sci" tools can make for simple, elegant code, but we're not teaching McProgrammers those tools. This appears to largely be a failing of our universities, but given that it's largely been easy to get programming jobs without a degree, I'm unsure of how we can solve this problem. We need the McProgrammers (and to be fair, there's nothing wrong with wanting to have a life outside of dense computer science papers), we need the computer scientists, but there's an awfully sparse array in the gulf between them and this group isn't able to do enough to bridge the gap.
We need universities to start addressing this. They need to start teaching:
(I was tempted to add "manners" to that list)
Believe it or not, the best programming language instructors I had in college were two old COBOL programmers. They had real-world experience and they taught us things we were actually going to use. The worst instructors I had were my Java instructors. One was fresh out of university and had trouble explaining the difference between a class and instances of said class. One claimed real world experience but didn't understand MVC and had never done automated testing.
When I talk to new "university" programmers, they can write a heap sort from memory, they can explain complicated algorithms they've memorized, but they've often never programmed with anyone else and don't understand why deadlines are so important. (One was so steeped in his "one true way" that he mocked Perl programmers for not using linked lists regularly).
Business pressures mean that we'll always need the casual programmers who can churn out that log analysis tool because that's a real-world need and for the sorts of jobs that I work on, I often want them. Unfortunately, when I work on larger systems, I need to work with programmers who understand the importance of complexity management (watch the blank stares from many uni grads on that one), OO design and automated testing and deployment.
For those few times that (most) businesses need complexity, where do we find programmers who understand how to use adaptive resonance theory for recommendation systems? Where do we find the programmers who can take an ant algorithm and apply it to your delivery driver schedules? We need computer science and computer science needs implementers, but universities aren't churning out the graduates who can bridge this gap. Business suffers for it, no one really seems to care. We're limping along to where we need to go when we could at least walk, if not run.