I'm reminded of the following quote by the co-author of SICP - Gerry Sussman...
"Remember a real engineer doesn't want just a religion about how to solve a problem, like object-oriented or functional or imperative or logic programming. This piece of the problem wants to be a functional program, this piece of the program wants to be imperative, this piece wants to be object-oriented, and guess what, this piece wants to be logic feed based and they all want to work together usefully. And not because of the way the problem is structured, whatever it is. I don't want to think that there's any correct answer to any of those questions. It would be awful bad writing a device driver in a functional language. It would be awfully bad writing anything like a symbolic manipulator in a thing with complicated syntax."
The problem is sometimes you lose a lot of functionality when you allow for that flexibility. For example, let's say you want your functional language to allow for side effects. Immediately you've lost locality: the explicit arguments of a function no longer guarantee their results. Or maybe you want to allow mutability: there goes thread safety. The fewer hard restraints a language can impose, the less lifting the language can do on your behalf. Give up on Lisp's S-expressions, and the macro system becomes vastly more complicated.
Likewise, a language has a limited amount of space for syntax before you end up a mess. So languages adopt a paradigm, and optimize the language for that paradigm. Functional-style Java is bloated to hell, because Java is built for Object Oriented programming.
Frankly, I'm of the opposite mind of the quote: the middle ground is often worse than either extreme. I'll happily write Object Oriented C#, or Functional Haskell, over a tepid mess of C++.
isn't it amazing in this day and age we can just google a 7 year old quote and basically pull up the actual video of it instantly and send it around timestamped?
some days technology sucks, but other days its a wonder it works as well as it does
> A refreshingly pragmatic position for an academic.
There are plenty of pragmatic academics. It just happens that academia is about the only place that the non-pragmatic people can find long-term career success, but that doesn't mean there aren't many pragmatic people in the same space.
"Remember a real engineer doesn't want just a religion about how to solve a problem, like object-oriented or functional or imperative or logic programming. This piece of the problem wants to be a functional program, this piece of the program wants to be imperative, this piece wants to be object-oriented, and guess what, this piece wants to be logic feed based and they all want to work together usefully. And not because of the way the problem is structured, whatever it is. I don't want to think that there's any correct answer to any of those questions. It would be awful bad writing a device driver in a functional language. It would be awfully bad writing anything like a symbolic manipulator in a thing with complicated syntax."