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

121–130 of 177 posts

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

#121

Post by Symmetry »

bighuh wrote: post #99
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…

Any OOP course covers the 'reasons' for OOP (such as they are). Polymorphism, inheritance, and encapsulation. Yes, you can model much the same behavior with structs and associated functions (which is really still OOP to some extent, just without any language support), but it's quite a bit of additional work.

Late binding polymorphism and encapsulation are both very important concepts but there's no particular reason that your unit of inheritance should be your unit of polymorphism, often the boundaries should be drawn differently. And inheritance is just a way of achieving code re-use that tends to make suboptimal tradeoffs between flexibility and DRY.

There's a certain conceptual and implementation elegance to OoO so I understand why it became popular. But in practice all the new languages moving away from it are doing so for good reason.

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

#122

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.

The formal proofs aren't in a Hacker News comment; just go read game theory research papers. For example, https://www.cs.cmu.edu/~noamb/papers/17-NIPS-Safe.pdf

Or go try and solve a moderately complicated anything without allowing yourself abstractions with error. I won't wait on you, because your solutions will never terminate in my lifetime for even things as simple as chess which is a hell of a lot simpler than reality.

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

#123

Post by tester756 »

substation13 wrote: post #42
fabian2k wrote: post #40

Earlier quoted context omitted.

The only real difference is that inheritance as explicit language support while composition is something you can easily implement with common language features. It's not really more difficult to use composition than inheritance. As an example, if I want to use composition in C# using ASP.NET, I simply inject the class I want to use into my new class using the built-in DI. This is as simple as extending the class.

Some features are plain missing (or must be implemented in a convoluted manner): - Discriminated unions - Immutable data types (records) - Free functions (or modules of free functions) - Software transactional memory (STM), atoms - Ad-hoc polymorphism (traits) - Custom operators (used sparingly for building DSLs) - List comprehensions Instead we get anti-features like automatic properties, implementation inheritance,…

>(records)

there are

>- List comprehensions

Enumerable.Range?

>- Custom operators (used sparingly for building DSLs)

Could you please show what kind of DSL you'd want to write?

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

#124

Post by jzwinck »

bighuh wrote: post #98

> We make class hierarchies in order to simplify the code by allowing different parts of it to be changed independently of each other, and to eliminate duplication (which comes to the same thing). Yeah. Exactly. Which is why Dog extends Animal. It has a set of common features (code/behaviors, and data like number of legs, amount of fur, and so on). It is a really good analogy and a really good point to give someone a…

Here are a car and a motorcycle each with three wheels:

https://en.m.wikipedia.org/wiki/Reliant_Robin

https://en.m.wikipedia.org/wiki/Piaggio_MP3

What shall we do with them in our class hierarchy?

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

#125

Post by czx4f4bd »

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

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.

I finally broke through it after being forced to write a ton of enterprise Java, which helped me come to realize that classes and objects are useful units of abstraction for encapsulating related sets of data and behavior, as well as finally grasping the idea of composition and the utility of things like dependency injection, but I could've avoided years of pain if someone had actually explained that properly with concrete examples of useful object-oriented code. Since then, I've seen the same conceptual misunderstandings over and over from beginners and all of it comes down to the fact that these inane `Cat extends Animal` examples are simply wrong.

> When you've never written a line of code in your life, abstract things like "network protocols" and "file I/O" and "ImageDisplay" (which is neither an image nor a display) are confusing, and so frustrating, and so not useful for teaching a complete novice.

The solution here is not to teach them something that dooms them to even more frustration and confusion in the future. Also, if someone has never written a line of code ever, why are you teaching them OOP? If someone can't yet grasp concepts like network protocols and file I/O, OOP is literally not useful to them. It's like teaching someone calculus when they haven't even learned algebra yet. Start with the basics and then build up from there.

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

#126

Post by lelandbatey »

bighuh wrote: post #98

> We make class hierarchies in order to simplify the code by allowing different parts of it to be changed independently of each other, and to eliminate duplication (which comes to the same thing). Yeah. Exactly. Which is why Dog extends Animal. It has a set of common features (code/behaviors, and data like number of legs, amount of fur, and so on). It is a really good analogy and a really good point to give someone a…

> A vehicle can have any number of wheels and any number of doors.

Does that mean zero doors and zero wheels? Because a jet ski is surely a vehicle, right, and it has zero wheels and zero doors.

Likewise, what about a cable car (aerial lift)? It has doors (maybe), but probably not an internal engine. It's definitely a vehicle, but it has almost nothing that's similar about it compared to the car (automobile) you described earlier. If it where a class, the "vehicle class" could really only meaningfully have some attributes related to transport (like human/cargo capacity) and some methods around movement in the most general sense. If we keep breaking this down, we'll find a huge taxonomical network, a vast sea of interlocking Venn-diagrams of attributes and capabilities. This is the corner that those OOP tutorials force people into: trying to turn a network into a tree, and it doesn't ever really work (at least not without awkward compromises).

Sure, for a beginner who's never grappled with trying to map concepts to things, this can be a nice contained way to start. Eventually though, that beginner will need to learn some the next levels of more general thinking; e.g. one where they can start modeling interfaces/protocols and their relationships.

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

#127

Post by czx4f4bd »

bighuh wrote: post #98

> We make class hierarchies in order to simplify the code by allowing different parts of it to be changed independently of each other, and to eliminate duplication (which comes to the same thing). Yeah. Exactly. Which is why Dog extends Animal. It has a set of common features (code/behaviors, and data like number of legs, amount of fur, and so on). It is a really good analogy and a really good point to give someone a…

> it's not difficult to imagine cases where you might actually use it. c.f. basically any game with dogs in it where they're a subclass of NPCs.

Except even in game design it's a bad idea once you get more than a handful of entity types. https://gameprogrammingpatterns.com/type-object.html

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

#128

Post by pphysch »

random314 wrote: post #119
pphysch wrote: post #101

Earlier quoted context omitted.

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 kinda agree. But my personal take is different. Functions can be invoked in at least 3 different ways or a mixture of the three 1. Prefix - C style f(x,y,z) 2. Infix - x + y; x.f(y,z); a join b 3. Post fix- (x,y,z) $ f Infix is the best style in most cases, OOP accidentally helped programmers use a more readable infix style. A lot of the benefits of OOP can be had by allowing good infix invocation support and inter…

Yes, you put it better.

Infix is tricky because it doesn't scale well to complex expressions. I think Python does it right with plenty of infix keywords a la "if thing not in myset: ...".

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

#129

Post by Konohamaru »

igouy wrote: post #108
qsort wrote: post #39

Earlier quoted context omitted.

For all its blemishes it's still the most natural way to represent the concept of "user-defined data type" in a procedural language. "Modeling the world as OOP", OTOH, is a load of bull.

"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?

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

#130

Post by hellohowareu »

corrral wrote: post #94
202206241203 wrote: post #28

Earlier quoted context omitted.

OOP still rules the GUI. Even if you spread some functional sauce all over it.

As one can see in React, which contorted itself to be "functional" and ended up inventing bad, new syntax for objects in a language that already had objects built-in. They evidently couldn't figure out a better way to handle it, and landed on reinventing the wheel, badly, and but calling it something else.

Eh, considering its popularity I suppose it is a "least bad" if one chooses a cynical yet realistic perspective.

Personally, after working with vanilla JS, then jquery, I looked at angular and react. I liked react so much better

Post reply on HN