3 ms·

> See also OO, which also has a similar story where if you learn OO in 2022, you're learning a genteel and tamed OO that has been forced to tone down its promis

by msla 5y ago

> See also OO, which also has a similar story where if you learn OO in 2022, you're learning a genteel and tamed OO that has been forced to tone down its promises and adapt to the real world. The OO dogma of the 1980s and 1990s was bad and essentially impossible, and only a faint trace of it remains. Unfortunately, that "faint trace" is still in a few college programs, so it has an outsized effect, but for the most part the real world seems to break new grads of it fairly quickly nowadays. Are you talking about the notion that OO is about making an ontology, and that recapitulating a poorly-thought-out subset of the Dewey Decimal System in your codebase will somehow make it easier to reason about and extend? The core of OO, that some types have shared behavior and Wouldn't It Be Nice If it were possible to have only one implementation of that behavior which could be shared among all types which share it, is, at best, orthogonal to that ontological notion, and sometimes actively anathema to it. (For example, what ontology includes, as a top-level concept, Things Which Can Be Compared To Each Other, or Things Which Can Be Collected Into A List?) I also have another example: GOTO as a programming construct now is essentially not comparable to GOTO as it was in FORTRAN 66 or contemporary languages. Skipping ahead a few lines within a function is mostly anodyne, if not outright laudable if it gets you out of a loop without messy flag varibles; skipping three pages back to the middle of a different function is the kind of thing Wirth was ranting about. Do not even mention computed or assigned GOTOs.

jerf 5y ago
"Are you talking about the notion that OO is about making an ontology, and that recapitulating a poorly-thought-out subset of the Dewey Decimal System in your codebase will somehow make it easier to reason about and extend?" I'm referring to the origin of OO in Simula, a language for writing simulations. From that early OO had an extremely strong bias in favor of modelling "domain objects". In that model of OO, having an "iterator" class is actively wrong, because there's no physical corresponding to an object. That's where the Car/Engine/Tires example comes from, and to a lesser extent the Animal/Mammal/Cow etc. examples. It's been 25 years or so, but I think when I took my software engineering class I was actively told my OO should model real things. The irony is that I think OO shines most brightly in the abstract machinery of programming like iterators and other machinery like that. It has problems when you try to connect it to the real world by "exporting" the purely internal state changes out to something real. This is a general problem in software and it's not like I have perfect solution, but the OO tools tend to not be anywhere near as helpful here. (By that I mean, yes, we write the code that does this in an OO context, but inheritance/private/public/etc. isn't really that helpful in terms of keeping a particular variable in your object in sync with the database value it's supposed to reflect, for instance.) Simula somewhat deceived the early practitioners, because in Simula, state changes within the object are the desired outcome; when your Engine object flips its On flag from false to true, the object's job is done. This does not necessarily translate into the real world anywhere near as well. And yes, goto is definitely another one of those things were you can't understand the old criticisms through a modern language lens, because the goto we have today has been tamed and brought to heel under structured program's constraints. However, unlike alephnan's objection that he doesn't see the point of the RPC criticisms which I think is the common case, the goto criticisms continue to live on as zombies long after the thing being criticized is actually dead and buried, injuring the more modern version.

by msla 5y ago

jerf 5y ago

"Are you talking about the notion that OO is about making an ontology, and that recapitulating a poorly-thought-out subset of the Dewey Decimal System in your codebase will somehow make it easier to reason about and extend?" I'm referring to the origin of OO in Simula, a language for writing simulations. From that early OO had an extremely strong bias in favor of modelling "domain objects". In that model of OO, having an "iterator" class is actively wrong, because there's no physical corresponding to an object. That's where the Car/Engine/Tires example comes from, and to a lesser extent the Animal/Mammal/Cow etc. examples. It's been 25 years or so, but I think when I took my software engineering class I was actively told my OO should model real things. The irony is that I think OO shines most brightly in the abstract machinery of programming like iterators and other machinery like that. It has problems when you try to connect it to the real world by "exporting" the purely internal state changes out to something real. This is a general problem in software and it's not like I have perfect solution, but the OO tools tend to not be anywhere near as helpful here. (By that I mean, yes, we write the code that does this in an OO context, but inheritance/private/public/etc. isn't really that helpful in terms of keeping a particular variable in your object in sync with the database value it's supposed to reflect, for instance.) Simula somewhat deceived the early practitioners, because in Simula, state changes within the object are the desired outcome; when your Engine object flips its On flag from false to true, the object's job is done. This does not necessarily translate into the real world anywhere near as well. And yes, goto is definitely another one of those things were you can't understand the old criticisms through a modern language lens, because the goto we have today has been tamed and brought to heel under structured program's constraints. However, unlike alephnan's objection that he doesn't see the point of the RPC criticisms which I think is the common case, the goto criticisms continue to live on as zombies long after the thing being criticized is actually dead and buried, injuring the more modern version.