Live data from Hacker News

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

mail-archive.com

151–160 of 177 posts

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

#151

Earlier quoted context omitted.

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. Lo…

Those are good examples of inheritance. However, I think they'd be better served with mixins, which is another form of composition.

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

#152

After 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.…

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…

Small thought from someone that's spent lots of time messing with embedded C.

I feel like classic OOP is a mistake because you're binding data objects with functional objects. The latter being a collection of functions that performs operations on the former.

If you break them up you can have multiple widgets for dealing with a data object. Each of them with whatever dependencies they need and nothing else. I feel like this style of programing has become more important because it fits in the the idea of computing as an assembly line. Passing data through a data pipelines. Steps which often happen on different processes or machines.

Dependency injection is also really really useful for clean C code.

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

#153
post #21

I actually like to ask people in interviews to model a car and car factory because I want to see right away if they go deep into the nonsense of extending everything, or if they can use composition, or get away with something focused on maintainable code that meets requirements. I've seen it all. Prius extends Car extends vehicle extends motor extends ... Right within the first five minutes of the interview. But I al…

So you literally say "can you model a car and a car factory?" because that's a pretty meaningless question so I'm not surprised they think "what is he talking about? ohhh he's referring to the classic car inherits vehicle thing and wants to see if I understand inheritance. ok I'll show him some inheritance!"

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

#154

Earlier quoted context omitted.

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?

>(records)

Agreed, although this a recent addition in Java and a step away from old school OOP

>- List comprehensions

Enumerable.Range is not equivalent to list comprehensions. For example, in F# you can build a list using a comprehension containing more or less any code you like. It's incredibly powerful for things like building HTML.

>- Custom operators (used sparingly for building DSLs)

These are used in many places, but to give one example https://www.cs.tufts.edu/~nr/cs257/archive/simon-peyton-jone...

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

#155

Earlier quoted context omitted.

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

> he's against the extreme "everything is an object" version of OOP

I totally agree with you. I think he focuses on this style because it's generally what's taught in Universities, and he also has tons of tutorials geared towards students. So he's exposing his audience to the idea that some OOP principles are good, but overly adhering to the paradigm (in the way that would get you a 100% grade in an OOP class in college) is actually a bad way to program in general.

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

#156
post #118

Earlier quoted context omitted.

>OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. - Alan Kay - Other remarks from him about OOP are (paraphrased): - OOP is a recursion on the notion of the computer itself - The internet\Erlang is more OOP than java His vision for OOP is something akin to distributed computing: Each object is a seperate computer with its own private m…

I respect Alan Kay as a programmer and an intellectual, but the plain and simple reality is that his definition of OO is not the one that carried the day, and his definition has very little relevance in the world today. If one squints hard enough, one could argue that we are continuing to move in his direction even so, slowly and in fits. But it's not because we have an Alay-Kay-OO language, and to the extent it is h…

Modern OOP was introduced later. From what I can tell, the only new technical capability was implementation inheritance, which is strongly frowned upon these days.

Rust is a bit closer to the older OO ideal in that each object is its own private machine that encapsulates/protects its own state, and is late bound. The borrow checker allows the compiler to statically check that each use case of a given class is memory/threadsafe, and enforces basic state machines like "finish using this reference before calling next on the iterator", or "give up the ability to read() this network handle before transferring it to another thread". Modern OO completely fails to provide safety for those sorts of APIs (e.g. Java's ConcurrentModificationException is a compile time error in Rust)

On top of that base, you can build progressively more expressive OO-style API contracts, such as connection pools.

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

#157

Earlier quoted context omitted.

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

You are talking about game theory without any precise definition of "abstraction", which it seems like one can define it to be whatever one wants it to be.

One abstraction that is very useful is linear algebra which is an abstraction without errors. Same goes for category theory. Grothendiecks work wasn't about tolerating errors in abstractions either. Simple abstractions like generic containers are also not about ignoring errors.

Honestly, the random segues to diagonalization arguments, game theory, continuous functions, RL and Bellman equations(WTF!) sound like stream of conciousness random ramblings and an attempt at "out jargoning", much less a "formal proof". Reminds me of this story by Tadelis.

https://thecorrespondent.com/100/the-new-dot-com-bubble-is-h...

"We use Lagrange multipliers," one of them said. And for a second, Tadelis was astounded. What? Lagrange multipliers? But Lagrange multipliers don’t have anything to do with ..."Then it hit me," Tadelis recalled. "This guy is trying to out-jargon me!"

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

#158

Earlier quoted context omitted.

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

> he's against the extreme "everything is an object" version of OOP I totally agree with you. I think he focuses on this style because it's generally what's taught in Universities, and he also has tons of tutorials geared towards students. So he's exposing his audience to the idea that some OOP principles are good, but overly adhering to the paradigm (in the way that would get you a 100% grade in an OOP class in coll…

That's a fair point, and as I mentioned I do agree with his conclusion.

Being self-taught, I was already a proficient programmer in Delphi and C++ by the time I went to University. So to me OOP has always been "OOP when you need it".

Though now that you mention it, even by the time I started University I had a profound dislike for Java's "OO all the things" approach. It has not subsided...

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

#159

Earlier quoted context omitted.

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

You are talking about game theory without any precise definition of "abstraction", which it seems like one can define it to be whatever one wants it to be. One abstraction that is very useful is linear algebra which is an abstraction without errors. Same goes for category theory. Grothendiecks work wasn't about tolerating errors in abstractions either. Simple abstractions like generic containers are also not about ig…

> One abstraction that is very useful is linear algebra which is an abstraction without errors.

Bullshit. Your claim that there is no abstraction error in linear algebra (when run on computers - we're in subdiscussion related to programming) is false.

Computers can't represent all numbers [1]. They can only represent the computable numbers in theory and even then only a subset of computable numbers can actually be computed. Therefore, there is abstraction error in linear algebra on computers. This isn't at all a theoretical thing. This regularly has implication on algorithm design. You ought to have known this, because the truth about floating point numbers has been well publicized [2].

> Same goes for category theory. Grothendiecks work wasn't about tolerating errors in abstractions either. Simple abstractions like generic containers are also not about ignoring errors.

You're just ignoring that these things when implemented in computers actually do have error, because you find it convenient. You're also apparently not self-aware enough to realize that this agrees with my central premise. Think about your thinking and you'll notice that this failure is indicative of your own minds belief in wrong abstractions being right - otherwise you wouldn't have been able to make this error.

> Honestly, the random segues to diagonalization arguments, game theory, continuous functions, RL and Bellman equations(WTF!) sound like stream of conciousness random ramblings and an attempt at "out jargoning", much less a "formal proof". Reminds me of this story by Tadelis.

We're talking about learning as it relates to abstraction. If you can't see why a learning problem formulation is relevant to discussion about whether learning an abstraction is appropriate that says a lot more about your reasoning than it does my articulation.

As a reminder the OP said:

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

I've disagreed with the claim that teaching a bad abstraction that has to be unlearned is bad. I've shown that in learning problems, teaching a bad abstraction can actually be good. I've given proofs to the effect that there are times in which teaching a bad abstraction produces algorithms which terminate in situations where teaching a perfect abstraction doesn't terminate. I've given you links to mathematics showing that given a bad abstraction as a starting point you can produce agents which outcompete something which doesn't use an abstraction. The paper in question takes a bad abstraction and improves upon it after getting it during the challenge of a more specific problem.

> "We use Lagrange multipliers," one of them said.

Hacker News guidelines call for more thoughtful points, not less thoughtful points, as threads get deeper. It also calls for assumption of good faith. It calls for increasing nuance [3]. What you are doing here - it isn't that. At the risk of starting something painfully obvious, talking about random shit people that aren't me said that you found dumb isn't actually relevant to the discussion. This is a subthread that is on the topic of learning and abstraction. I'm talking about both topics. You aren't.

> random ramblings

I'm sharing something deeply counterintuitive but true because I think people might find it interesting. Right algorithm + correct data can be worse than right algorithm + wrong data. This is deeply counterintuitive and I find it very fascinating, but it falls out of the formal definitions of utility under multiple different learning frameworks. Something isn't bad because it has abstractions with error in it. Teaching an abstraction with error in it isn't bad either. It isn't even bad when you can find the error - because you're in a more specific situation the learning problem changes, in the general case it was too hard to compute the unabstracted best thing to do, but you can reduce the error in your abstraction when you get more specific because there are less states and so the learning problem becomes more tractable.

[1]: https://www.cs.virginia.edu/~robins/Turing_Paper_1936.pdf

[2]: https://floating-point-gui.de/

A person might try to respond to this point by claiming arbitrary precision numbers exist. That person is lying to themselves. They don't exist. The abstraction error is just in a different place. Go back to the definition of Turing Machines and observe again that not all numbers are computable - we are in an abstraction subject to error and you can't escape this while staying in the Turing framework [1].

[3]: https://news.ycombinator.com/newsguidelines.html

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

#160

Earlier quoted context omitted.

You are talking about game theory without any precise definition of "abstraction", which it seems like one can define it to be whatever one wants it to be. One abstraction that is very useful is linear algebra which is an abstraction without errors. Same goes for category theory. Grothendiecks work wasn't about tolerating errors in abstractions either. Simple abstractions like generic containers are also not about ig…

> One abstraction that is very useful is linear algebra which is an abstraction without errors. Bullshit. Your claim that there is no abstraction error in linear algebra (when run on computers - we're in subdiscussion related to programming) is false. Computers can't represent all numbers [1]. They can only represent the computable numbers in theory and even then only a subset of computable numbers can actually be co…

> Bullshit. Your claim that there is no abstraction error in linear algebra (when run on computers - we're in subdiscussion related to programming) is false.

The fact that you had to change my statement to add computers to it already makes it clear that you know my statement is correct. Don't put words into my mouth to prove statements that I have never made false. You also failed to realize that the tweaked statement you put in to my mouth is still correct!

You fail to realise that we can prove theorems about linear algebra using computers without actually using floating point numbers. Linear algebra can be infinite dimensional and not just be defined on the complex field, and this doesn't introduce any errors in to the abstraction or theorems being proved, with or without computers. Your assumption that linear algebra on computers is exclusively about floating point number crunching tells me that you don't understand what abstraction linear algebra represents. Linear algebra is the study of linear maps. This is a good book for you to get started [1]

You also failed to address the gazillions of abstractions that don't have errors, some of which I have listed along with linear algebra. For those familiar with proofs, Just one counter example can prove your sweeping statement "all abstractions have errors" false. We are discussing math, not physics. And if you want to restrict yourself to computable functions- modulo arithmetic with groups, rings and fields suffices as a counter example.

It isn't even clear what you mean by abstraction at all.

> We're talking about learning as it relates to abstraction.

The OP was not discussing learning at all. Your segue into machine learning concepts is completely unrelated to the topic being discussed. So is game theory. I am familiar with virtually all the topics you are discussing, so you can skip the citations. I find no coherence to any of your segues.

> You're just ignoring that these things when implemented in computers actually do have error, because you find it convenient.

You are completely out of touch [2][3]

[1] https://linear.axler.net/LinearAbridged.pdf

[2] https://en.wikipedia.org/wiki/Univalent_foundations

[3] Mathematician Kevin Buzzard https://www.microsoft.com/en-us/research/video/the-future-of...

Post reply on HN