I am not sure that OOP "isn't helping". I am not exactly an OOP fanboy, but we have to admit that, both inside and outside the industry (I'm thinking open source and hobby projects), OOP has contributed something. The industry has a lot of inertia, but it did eventually moved from assembly to high-level procedural languages, and from high-level procedural languages to OO languages.
However to what extent the move to OOP rather than FP (or logic programming) for instance is accidental rather than rational is a question one may ask. Javascript has nothing special but is wildly used just because it benefited from its quasi-monopoly on web scripting.
I think the problem is efficient, easy, correct: pick two.
With "easy" meaning not only "easy to program with" but also "easy to learn" and "easy to hire people".
Programming paradigms are false dichotomies. One can do pseudo-OOP with a procedural language, imperative in FP, FP-style in OOP. Not to mention the existence of multi-paradigm languages. Paradigms are merely about which programming style a language make easier, what is supported "out of the box".
The problem is then for the user to pick the right main paradigm for the task at hand. This is where programming becomes a craft - just like a proof strategy in mathematics is not dictated by the formalism, but is chosen based on intuitions (that is, expertise).
If there is no silver bullet, then maybe, from a programming language perspective, one can have a language that let us chose different pairs in (efficient, easy, correct) at different times. It is well-known that dynamic scripting languages make prototyping easier, but may not be viable in terms of efficiency and correctness for a finished product (Gradual typing tries to reduce this gap, it seems). Automatic memory management (garbage collectors) and more recently, languages with built-in concurrency features (instead of direct manipulation of OS threads) makes it easier to make less incorrect programs at the expense of some efficiency.
If we admit there is no silver bullet, then can we however to build silver bullet factories?
I agree with most of what you've said, except that programming paradigm and languages have not helped with anything significantly beyond a certain point. They helped early on, FORTRAN was more productive than Assembly, FP/OOP helped after C etc., but we're seeing diminishing returns. And guess what: some predicted that this is exactly what would happen, incidentally, the very same person who said there's no silver bullet.
I'm not saying it's not possible to help, just that in a world of diminishing returns, it means that finding stuff that helps is very, very hard, and I think we're at a point where we can say that FP and OOP are not "the answer" to getting us further than where we already are, and start looking for other things.
> If we admit there is no silver bullet, then can we however to build silver bullet factories?
I would say that the answer is no, for a similar reason we can't build halting-problem-deciding factories. If we had silver-bullet factories, then unless picking the right bullet is very hard -- in which case we've solved nothing -- then we have a silver bullet. There are some fundamental reasons for that, and I tried to cover some of them here: https://pron.github.io/posts/correctness-and-complexity
The one unanswered question is how far are we from the best we can do?
Wouldn't you say that the next logical step is to go up an abstraction then? Assembly -> C -> OOP/FP -> ??? In that case, wouldn't it make more sense if that abstraction was build on top of something which you can mathematically reason about?
First, you can mathematically reason about a program written in any language; I do it all the time with TLA+ [1]. It is certainly not the case that FP is more amenable to mathematical reasoning than imperative code, although the kind of reasoning is different: FP mostly relies on equational reasoning while imperative mostly relies on assertional reasoning. Synchronous programming, for example, relies on temporal reasoning.
Second, mathematical reasoning has its limits, especially as we're dealing with intractable problems. It doesn't matter if you can somewhat more easily reason about a simple three-line program in one paradigm than in another if most important programs are six orders of magnitude bigger. Unfortunately, program correctness (aside from some very simple properties) does not compose tractably (i.e. even if reasoning about components A1...An is "easy", reasoning about the composition A1 ∘ ... ∘ An can be more difficult than any computable function of n. So I would not put ease of mathematical reasoning about simple cases as necessarily the main priority, let alone the only one.
Logic programming immediately comes to mind. I've always had trouble to see the difference between imperative programming and procedural programming, and in a way OOP is procedural with lipstick (I'll wait that it is fashionable to bash FP to say the same about FP :-). Logic and declarative programming, on the other hand, are whole different beasts.
However to what extent the move to OOP rather than FP (or logic programming) for instance is accidental rather than rational is a question one may ask. Javascript has nothing special but is wildly used just because it benefited from its quasi-monopoly on web scripting.
I think the problem is efficient, easy, correct: pick two.
With "easy" meaning not only "easy to program with" but also "easy to learn" and "easy to hire people".
Programming paradigms are false dichotomies. One can do pseudo-OOP with a procedural language, imperative in FP, FP-style in OOP. Not to mention the existence of multi-paradigm languages. Paradigms are merely about which programming style a language make easier, what is supported "out of the box".
The problem is then for the user to pick the right main paradigm for the task at hand. This is where programming becomes a craft - just like a proof strategy in mathematics is not dictated by the formalism, but is chosen based on intuitions (that is, expertise).
If there is no silver bullet, then maybe, from a programming language perspective, one can have a language that let us chose different pairs in (efficient, easy, correct) at different times. It is well-known that dynamic scripting languages make prototyping easier, but may not be viable in terms of efficiency and correctness for a finished product (Gradual typing tries to reduce this gap, it seems). Automatic memory management (garbage collectors) and more recently, languages with built-in concurrency features (instead of direct manipulation of OS threads) makes it easier to make less incorrect programs at the expense of some efficiency.
If we admit there is no silver bullet, then can we however to build silver bullet factories?