pull down to refresh
269 sats \ 6 replies \ @SimpleStacker 29 Nov \ on: Early object oriented programming languages devs
Please, I would like to hear.
I recently had to slog through some super hard to read code because 90% of the code was templating out abstract objects with multiple levels of inheritance, just to perform some simple operations like an API call. I sort of understood why the abstractions were useful, but at the same time it made figuring out what was going on really hard.
And this was a Microsoft repo so I'm guessing it's good programming practice? At least I assume Microsoft engineers are considered good in the industry
reply
I felt I may have overstated how much of a rant I have, but it looks like I didn't ...
OOP is best suited to problems where you have lots of varied and complex state and many instances of complex state. The history of OOP certainly suggests that at least - it was initially used for simulations, ie many instances of varied complex state evolving over time. Then it found market-fit in GUI frameworks which have a similar problem. Then programmers, with this hammer, treat everything like a nail. They use OOP to solve problems with primitive and singular state, tightly coupling logic to state merely out of habit.
OOP programmers spend most of their time building more and more complex, and abstract, families of logic-state chimera. As a result OOP code tends to be the hardest to read and reason about because at any point of execution there's a bunch of implicit bespokely organized state. OOP encourages state and state organization rather than state minimization. It rejects electing the simple, predictable, and obvious execution stack from carrying a program's state. When the execution stack carries state:
- the complexity of a program's ephemeral state is roughly proportional to its execution depth
- state is defined by simple, often primitive, explicit statements exactly where the state begins being used
I think what OOP wants to be is declarative (ie understand these classes, objects, and organization and you know what the code does), which is the way most programming languages and frameworks have evolved, but instead often ends up being the opposite - state mutates state that mutates state that mutates state, times a million, and all according to some random OOP engineer/state architect. Very few problems require ephemeral, complex, kind-numerous, interdependent state like this.
reply
OOP code tends to be the hardest to read and reason about because at any point of execution there's a bunch of implicit bespokely organized state
Yep that's my experience too
reply
Really? You consider MicroSloth engineers as good programmers? The only place I would ever use MicroSloth products is in a virtual box after I have acquired them for free. Just don’t trust them.
reply
I would assume that Microsoft programmers are considered good because Microsoft offers high salaries. Doesn't mean their products are good but I would have assumed the programmers are skilled and the product issues are more due to incentives at a large org. I don't work in the industry so I wouldn't really know
reply
I am not sure that high salaries equate to excellent programmers and engineers. Perhaps large monopolistic companies have too much spare cash that they have to distribute, or they get accused of monopoly profiteering. There are lots of reasons for paying people highly and not receiving commensurate services. Could that be one of the reasons for the high salaries?
reply