3 ms·

Interesting stuff, but I really miss explanations: > It (OOP) made it possible to develop much larger programs than before, maybe 10x larger. Why? This contr

Interesting stuff, but I really miss explanations: > It (OOP) made it possible to develop much larger programs than before, maybe 10x larger. Why? This contradicts my intuition, because the biggest problem is that OOP focuses on state changes (of objects). State change means complexity, so formally, you need to understand the set of all possible states to reason that the program is correct. This is an exponential problem in the number of pieces of state, unfortunately. So how would this enable larger programs? What's the reasoning here? It would mean some even more potent mechanism of OOP makes more state more manageable. The structuring of data does not strike me as that potent -- nice, yes, but, well -- please explain! > OOP provides a way for programmers to organize their code. I think it is primarily about organizing data. The organising of the corresponding code follows. When Java emerged, it did not even have functions -- every piece of code had to be attached to data. In SmallTalk, you could change the definition of the global 'true' or even extend bool to have three values -- definitely data centric, and introducing unmanageable state... > 100% pure functional programing doesn’t work. Even 98% pure functional programming doesn’t work. I believe this. Well, intuitively, I'd say no paradigm works well when applied 100% pure. It would still be nice to see examinations of this or reasoning or proof or at least examples.

Nursie 6y ago
> the biggest problem is that OOP focuses on state changes (of objects). State change means complexity, so formally, you need to understand the set of all possible states to reason that the program is correct. This is just not true. In fact that's the whole point - you encapsulate state. It becomes easier to reason about. When I write a webserver, do I need to know or care about the internal state of the classes dealing with the TLS protocol? Or do I encapsulate consistency and correct behavioir at that level and then use the interface elsewhere? I don't need to know everything at all layers.

Nursie 6y ago

> the biggest problem is that OOP focuses on state changes (of objects). State change means complexity, so formally, you need to understand the set of all possible states to reason that the program is correct. This is just not true. In fact that's the whole point - you encapsulate state. It becomes easier to reason about. When I write a webserver, do I need to know or care about the internal state of the classes dealing with the TLS protocol? Or do I encapsulate consistency and correct behavioir at that level and then use the interface elsewhere? I don't need to know everything at all layers.