4 ms·
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 h
by pron 6y ago
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 https://pron.github.io/posts/correctness-and-complexity
The one unanswered question is how far are we from the best we can do?
- trumpeta 6y agoWouldn'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?
- astrobe_ 6y agoLogic 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.
- pron 6y agoFirst, 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. [1]: https://pron.github.io/tlaplus https://pron.github.io/tlaplus