| You are making a lot of unsubstantiated claims. 1. Unity did not move to FP. FP might be "easier" to optimise, but it starts off from such a disadvantage that the relative ease usually can't make up for it. (The same is true for Swift, by the way: they also make great claims for how much it optimises, and those claims are largely true, but its base performance is so horrible that those heroic optimisations leave it slower than the language it replaces) The claimed advantages of FP for parallel processing are still vastly outweighed by the imposed overhead. I remember a talk by SPJ where he also made vast claims for the advantages of FP for parallel processing. At the end of the talk, he had to admit that the FP version needed 6 cores to become equivalent to a single core with C. He also claimed that some technique was "only possible with FP", but an audience member informed him that this very technique had been standard in HPC FORTRAN for quite some time. So these unsubstantiated claims have to be taken with a HUGE grain of salt. For high-performance, you still turn to tuned, mechanically sympathetic low-level code, not to FP. FP is about as mechanically antipathetic as possible. 2. Hand-waving. Have you heard of "object composition"? While you might believe that OO doesn't compose, for theoretical reasons, the fact is that it does, in practice. If your theory predicts something that turns out to be wrong, it is time to update the theory, rather than complain about the world. Also this "reason about" canard gets bandied abound a lot, but it is mostly just that: a canard. It refers to a very specific type of mechanical reasoning that is rarely done when actually trying to understand real code. FP code tends to be very hard for humans to understand. 3. It might be "obvious" to you, but: "It ain't the things that you don't know that kill you. It's the things you know that just ain't so". Every study purporting to show increased safety for statically typed languages compared to dynamic languages has been shown to be incorrect, sometimes comically so. What has been shown is a documentation effect. The idea that Smalltalk got most of its expressiveness from closures is laughable. What is true is that you absolutely do not need FP to reap the benefits of higher order code such as blocks. 4. Straw man. Nobody claimed that OO is a silver bullet. But once again, the very person who coined the phrase and wrote the paper "No Silver Bullets" said that he viewed OO as the closest thing to such a silver bullet. And 10 years later, he said that his belief had been shown to be correct. |
As are you!
1. I did not claim unity moved to FP, I said they dropped OOP and went to a data-centric processing. Even C (with Clang) now gets transformed into SSA form (static single assignment) in order to make optimising easier. The compiler is literally undoing the imperative programming! You claimed FP was a worse fit for modern hardware than OOP. That is an unsubstantiated claim.
2. I've done OOP for a decade professionally before another decade of FP. The OOP systems were by far the hardest to reason about and maintain. I can therefore argue this both theoretically and anecdotally. Industry is also (slowly) moving away from OOP. More recent languages like Rust and Go are no longer OO.
3. I guarantee that you will not see any future systems programming language that does not use static types. Dynamic languages will occupy niches were reliability and security are less important.
4. Fred Brookes is just one US academic. I'm sure Alan Kay likes OOP too. My point was that the US is very heavily invested in OOP, it's what the universities exclusively teach. Outside the US, OOP has always been much less popular.