Entity-Component-System is so much nicer paradigm than any hierarchy. I wonder why it's not used much outside of gamedev.
I would have agreed with this whole-heartedly when I first started using ECS. It has its own difficulties though.
Like what?
Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
141–150 of 177 posts
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#142I disagree with the article, which talks about building a holistic understanding when learning, and then ironically misses the forest for the trees regarding programming metaphors. The author is obviously an experienced programmer, so I suspect they've forgotten what the mindset of an absolute novice is like, and to start programming with zero prior exposure to the concepts. For the novice being introduced OOP, the `…
The problem here is that that "a-ha!" moment is completely fallacious and not actually helpful. You think you've gained some deeper insight, but any attempt to apply that understanding is all but guaranteed to result in pain and frustration. The mental model that OOP objects map directly onto real physical objects plagued me for years, because I could not understand how I was supposed to translate it into real code.…
> It's like teaching someone calculus when they haven't even learned algebra yet. Start with the basics and then build up from there.
I mostly agree in principle with the idea of building up a foundation. Going right into the deep end without decent guidance may leave one with horrible heuristics.
However, (IMO) a crawl->walk->run abstraction does not always work well. I hate to say "it's case by case," but pedagogy is not easy. Algebra, IMO, should be taught either near or with its uses (modern calculus being one of them). Otherwise, one may be learning a bunch of abstract concepts without much reification.
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#143Earlier quoted context omitted.
Nature doesn't do design, period.
True but irrelevant. The fact is nature "subclasses" (in the OOP sense) animals all the time in evolution even if it is an unintelligent process ultimately due to chance modification.
> The fact is…
Perhaps you mean — The analogy is…
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#144OOP != class hierarchies. Unfortunately when the industry shifted from procedural programming to OO they chose C++ and Java. These languages are mostly procedural languages with classes bolted on. They pretty much forced you to write hierarchies - it was the only way to get the good parts of OO - loose coupling, polymorphism, inversion of control, etc. Since inheritance was the only tool in the toolbox industry programmers naturally were driven to try and leverage inheritance for everything even though it is the worst part of OO.
Modern multi-paradigm langues do a much better job of letting you use OO when OO works, functional when functional works, etc.
You should use the tool that works when it works. I do plenty of functional and OO programming in ruby, declarative programming in SQL, mostly functional style in JS. There are plenty of places where each one works great.
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#145Earlier quoted context omitted.
"It should be clear to anyone that models of the world are completely different from models of software. The world does not consist of objects sending each other messages, and we would have to be seriously mesmerised by object jargon to believe that it does. … we use different sets of building blocks for modelling the world and modelling the software …" 1994 "Designing Object Systems" https://www.google.com/books/edi…
What software would you use if you wanted to model the world?
Sorry, I'm not up-to-date with modelling software.
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#146After many years of OOP, I'm not sure if we gained anything from OOP, and if it wasn't a solution in search for a problem. At first I was enthusiastic. Then I've realized that there might be better ways to solve problems than trying to fit everything in a "everything is an object" mentality. OOP can lead to overly complex code, uneeeded abstractions and design patterns thrown on top of each other for no good reason.…
OOP was a big step up from the procedural programming that dominated at the time. Unfortunately that step was kicked out from underneath us because the industry chose C with Class and Java, rather than Smalltalk, or CLOS, or even objective C.
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#147Earlier quoted context omitted.
It's not a million miles from it though. If you start from DRY as an approach to OO design you'll produce something vaguely reasonable and be close enough to where you want to be that you can learn the differences.
I should have been a bit more precise. There are essentialy two ways to approach DRY in OO. One is to inherit implementation, which isn't the best way to go about things since it leads to more brittle code. The other way is to make sensible use of polymorphism and composition. There are aspects of DRY that are worth pursuing (like reducing the number of places you need to get things right) and some that aren't worth…
Yes, to be fair the simplest advice to new programmers about how to use inheritance should be "don't". Aggregation good, polymorphism good, inheritance bad more often than not.
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#148Earlier quoted context omitted.
The problem here is that that "a-ha!" moment is completely fallacious and not actually helpful. You think you've gained some deeper insight, but any attempt to apply that understanding is all but guaranteed to result in pain and frustration. The mental model that OOP objects map directly onto real physical objects plagued me for years, because I could not understand how I was supposed to translate it into real code.…
> It's like teaching someone calculus when they haven't even learned algebra yet. Start with the basics and then build up from there. I mostly agree in principle with the idea of building up a foundation. Going right into the deep end without decent guidance may leave one with horrible heuristics. However, (IMO) a crawl->walk->run abstraction does not always work well. I hate to say "it's case by case," but pedagogy…
Yeah, I actually had a similar thought as I wrote that, but I was too lazy to come up with a better analogy. I guess a clearer analogy would be "trying to teach someone to differentiate a function when they don't know what a function or a variable is".
I derinitely agree pedagogy is hard. I have many thoughts about how the pedagogy of programming is deeply broken that are far too numerous to drop in an HN comment. I would say I'm not arguing for a purely linear approach so much as making sure there's actual conceptual understanding at each phase of the learning process. Teaching OOP before someone really grasps programming well enough to actually need it feels very premature, but there are lots of elements of it that can be sprinkled in throughout the learning process.
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#149Earlier quoted context omitted.
I just wrote 60k lines of C code and have never once felt the need for OOP. And I say that as someone who has spent their whole career with OOP. If I need some functionality, I write a function and pass it a struct. I’ve yet to find a time when this approach is too limiting, or chaotic. Even for interfaces, function pointers achieve that goal entirely. I do miss type safe vectors, e.g templating. Thats above and beyo…
Bound methods simply has the potential to be a tiny bit more readable: `thing.doWork(arg)` `doWork(thing, arg)` `doThingWork(thing, arg)` The first example is marginally more readable IMO. The second one sucks from a human perspective because we don't immediately know (unlike the IDE) that the function signature only accepts Things. The last one addresses this but is even longer, and we still have to mentally unpack…
I agree with you about that.
Long function invocations are an annoying consequence.
Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)
#150Earlier quoted context omitted.
"It should be clear to anyone that models of the world are completely different from models of software. The world does not consist of objects sending each other messages, and we would have to be seriously mesmerised by object jargon to believe that it does. … we use different sets of building blocks for modelling the world and modelling the software …" 1994 "Designing Object Systems" https://www.google.com/books/edi…
What software would you use if you wanted to model the world?
ANSYS, Dymola, Simulink, FAST, CESM, Drake, to name a few.