[chriszf]

I did some work programming a sequence for a Siemens magnet, and while I can't comment on the quality of the code driving the hardware, the OOP API they exposed for sequence creation was as bad as it gets. There was no sense of abstraction at all; it was very much like someone took an old C-style library then systematically hid all the functions in different classes for fun. Now, I could imagine that someone somewhere declared the magnets would be cutting-edge C++, and that's exactly what happened.

The point is that OOP is not necessarily the obviously correct way to manage the complexity of an MRI sequence. Any other style could have easily been substituted and not done worse.

[anuraj]

The point is - OO was developed for managing complexity of large projects which were using procedural model at the time. Large teams found it easy to work in the OO paradigm as each component could be abstracted down to a facade they need to call. Obviously if you don't do it right - it is not going to work. But Functional Programming exposes exactly the same pitfalls of procedural model (it is just another name) which OO tried to address.

[chriszf]

It seems to me that you're talking about modularization for managing complexity, which FP does just fine. OOP doesn't have a monopoly on that. It takes discipline, but you can write well-structured code in any paradigm.

To say that functional is the same as procedural programming is a complete misunderstanding of both. To say OO tried to solve the pitfalls of the other two paradigms is a misunderstanding of OO on the entire spectrum, from Alan Kay's original vision to modern implementations.

Even forgiving those confusions for a moment, if it takes discipline to prevent your OO code from degrading to procedural code, how is it any better from just enforcing discipline on procedural code? If OO is quantifiably better, the default state of the code should be obviously better than with other techniques.