Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

mail-archive.com

Post reply on HN
Print view View original

131–140 of 177 posts

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#131

Post by JoshCole »

random314 wrote: post #116
JoshCole wrote: post #109

Earlier quoted context omitted.

Abstractions are useful because they simplify and if you don't allow error you don't allow maximization of simplification. You can formally relate this to learning problem formulation complexity. When you do you encounter things like branching factors which effect solution times which lead to natural results like fast but finishes being better than optimal but never terminates. This can hold even despite error in the…

I don't think this constitutes a formal proof on any way at all.

Take the simplest problem of searching over a continuous range between zero and one exhaustively. Let the value you search for be 0.1. By a diagnolization argument we can realize that even a search carried on for an infinite amount of time and granted an infinite amount of space would not terminate. After all, to find 0.1 you need to make it past 0.01. But to reach that you have to reach 0.001. And so on. Let abstraction map from N to 1 over this space. As N goes up, abstraction error goes up, but the problem is no longer impossible because the diagnolization proof no longer holds. Let b be a branching factor in a game. As b goes to infinity, the game graph becomes continuous. In learning formulations under the game theoretic school of thought you have to search the game graph to get the average of your policies proportional to your counterfactual regret. That implies walking the continuous game graph. In reinforcement learning the bellman equations give you your values. This is also defined in terms of the game graph. So again we fall prey to the problem. We've shown that walking continuous things is impossible even under conditions that are ideal - infinite speed and memory and we've shown that this relates to the learning problem formulations I spoke of.

Obviously this only gets worse when we impose reality - we don't actually have infinite space on our computers. They don't compute for an infinite amount of time either. But notice that before we searched for infinite space and time and we failed? When we move down to finite space and finite time we still have the property of completing after full enumeration. We have a finite amount of computing capacity. We have a finite amount of computational storage. Yet the growth rate for unabstracted game trees is exponential. Let c be our constraints.

An abstracted game maps n states to one state. So it has log_n(X) where X is your state count. An abstracted game has X states. Since log_n(x) This is actually much less than the real world gains. Since in learning we get the policy expectations multiple times over the game graph and the convergence guarantees relate to the complexity of the graph you get a much more worthwhile window than just the difference of log_n(X) versus X. For much tighter bounds check out game theory research. They get error bounds on the abstraction error too by choosing clustering solutions with provable properties. So it really has a much stronger formal treatment than you might imagine.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#132

Post by blinzy »

pphysch wrote: post #101
randyrand wrote: post #90

Earlier 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…

Is your first/native language SVO (subject-verb-object)? Mine isn't, it's VSO (verb-subject-object) or SOV (subject-object-verb), and for me the first example isn't more readable so I wonder if that also changes our perspective on what option we see as the most natural.

I can admit though that from an IDE point of view having auto-completion upon writing thing and typing the dot and seeing the results is very useful, whereas there is nothing (as far as I know) that comes even close in functional languages where the second example is more typical.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#133

Post by jhbadger »

igouy wrote: post #112
jhbadger wrote: post #93

Earlier quoted context omitted.

I disagree. Nature does practice OOP and taxonomic hierarchies are real things in nature if they are based on their evolutionary history. People say penguins are "flightless birds", but look how they swim. They don't swim like fishes. They basically are flying in water because they share the same genetic programming as other birds, just slightly modified to use a different medium. Nature doesn't re-implement things f…

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.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#134

Post by Jcowell »

jhbadger wrote: post #133
igouy wrote: post #112

Earlier 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.

I think I understand what your saying. In this context a penguin is implementing a quality it’s inherited from the gene it has as a bird. A Penguin may not be a bird in the same way we may thing a fly method should work , but it’s fly method derived from the fact that it’s genetically a bird.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#135

Post by BoorishBears »

Avshalom wrote: post #100
BoorishBears wrote: post #44

Earlier quoted context omitted.

Every example you listed would be dodging an enormous bullet. The exact example the grandparent used was essentially a wrong answer, so our "old-school interviewer" (that sounds kind of ageist doesn't it?) marking us down for not using it is a bad thing. An interviewer who loves functional programming and doesn't communicate any preference then marks you down for not reading their mind is someone to avoid. An intervi…

"Sure I missed rent and now I have an eviction on my record and I'm sleeping in a car but at least I didn't get a job, bullet dodged"

"Your advice doesn't work out in every single situation ever experienced by a human so I'm going to come up with a sarcastic comment that says nothing of value to point that out."

You'd think common sense would tell one not to define what's good for them in general based on what's good for you when they're "missing rent with an eviction and sleeping in your car".

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#136

Post by moron4hire »

redisman wrote: post #96
dymk wrote: post #88

I 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 `…

I disagree. Teaching people to think about abstractions wrong is not in any way helpful. Everyone I know including myself had to spend years writing bad code before realizing that this way of thinking is counterproductive. It reminds me of this quote from Kung Pow Don’t worry about Wimp Lo, he’s an idiot. We’ve purposefully taught him wrong… as a joke. Composition is an infinitely better method to teach if you have t…

I'm so sick of this "composition is so much better than inheritance" talking point that seems to have become dogma in the last 5 years. You use both. They are completely different things.

Look at a classically inheritance-based system: a GUI library. You'll see lots of inheritance. Buttons and Checkboxes extend ClickableThing, ClickableThing extends Control. Whatever.

And then you compose those controls on a Form.

Look at a classically composition-based system: a video game entity-component system. You'll see Monsters composed of GraphicsObjects and Animations and WeaponSlots and AIAgents.

And you implement all of those components in an inheritance hierarchy, or else your GameObjectThinger can't have a list of them that can grow or shrink at runtime.

So keep saying "teach composition, not inheritance". You might as well tell musicians to study "rhythm, not tempo".

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#137

Post by magicalhippo »

codemonkey-zeta wrote: post #111
mynameisash wrote: post #38

Earlier quoted context omitted.

I'm reminded of the "Object oriented programming is bad" series: https://youtu.be/QM1iUe6IofM

For anyone unfamiliar, I recommend the whole series, but it also culminates in the presenter rewriting an entire nontrivial OOP program into a procedural one and saving whopping amounts of code/complexity. The big example helps to show this isn't just abstract rambling against OOP. https://m.youtube.com/watch?v=V6VP-2aIcSc

To me, his title is somewhat misleading though. It seems he's against the extreme "everything is an object" version of OOP. I think taking things to the extreme is almost always a bad thing. Sometimes goto is a good solution.

I do agree with most of his points though, which just so happens to be closely aligned with how I've ended up programming. I like to use interfaces, so my objects hierarchies are very shallow and use a lot of delegation, overriding few if any methods.

I also write a lot of free-standing functions, some long, when I feel that's best. I also mix in a fair bit of functional-like programming, especially when massaging data.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#138

Post by scotty79 »

torginus wrote: post #68
scotty79 wrote: post #9

Entity-Component-System is so much nicer paradigm than any hierarchy. I wonder why it's not used much outside of gamedev.

It is - it's just called SQL and is considered the opposite of cool.

It's kinda shame that people try to cram it into rigid object model instead embracing flexibility on the code side too.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#139

Post by cloogshicer »

dls2016 wrote: post #71
cloogshicer wrote: post #66

Does anybody have some actual good examples for teaching inheritance to beginners? I've thought about this for quite some time and couldn't come up with anything that strikes a nice balance between simple and actually useful.

Any sort of plugin architecture, e.g. VST audio plugins. Often there's an interface which you could implement directly, or you could inherit from an abstract class which provides some common functionality. I like this because it stresses that deep hierarchies aren't necessary to be useful. Also, if you're refactoring and see a "switch on type" then a little bit of inheritance is probably OK. I admit I taught intro to…

Thanks for your suggestion!

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#140

Post by scotty79 »

viktorcode wrote: post #74
scotty79 wrote: post #9

Entity-Component-System is so much nicer paradigm than any hierarchy. I wonder why it's not used much outside of gamedev.

It does not replace OOP because there are no answers to other questions like: does it support polymorphism? Or data encapsulation? Etc. It's a data access design principle, and that's about it.

To the same degree that SQL does. The answer is, "yes, no, does it matter? is that even interesting?"
Post reply on HN