Live data from Hacker News

Inheritance was invented as a performance hack (2021)

catern.com

241–250 of 252 posts

Re: Inheritance was invented as a performance hack (2021)

#241
post #204
post #192

Earlier quoted context omitted.

1992 "Interfaces and Specifications for the Smalltalk Collection Classes" https://dl.acm.org/doi/pdf/10.1145/141936.141938

Very interesting work! It is an attempt to extract the interfaces that were in the minds of the implementors of the Smalltalk-80 system's collection classes, but which couldn't be expressed in the language itself, because it has no interface construct. That's what I meant by "Languages like Smalltalk (...) don't have interfaces at all."

Don't have manifest types and don't have manifest interfaces.

Someone has already referenced "Adding Dynamic Interfaces to Smalltalk" [0] and looking back there doesn't seem to be any kind of demonstration that use of interfaces makes software faster to develop or less error prone or... [1]

    [0] https://www.jot.fm/issues/issue_2002_05/article1/
    [1] https://www.cs.utexas.edu/~wcook/papers/OOPSLA89/interfaces.pdf

Re: Inheritance was invented as a performance hack (2021)

#242

Earlier quoted context omitted.

To my mind, the challenge is not "sharing behavior"; it is "sharing behavior in a way that capture human-understandable semantics and make code easier to reason about instead of harder." I suspect part of the problem of inheritance is that it is a way to share behavior that some humans, especially visual thinkers who understand VMTs, find easy to reason about. In my experience verbal thinkers struggle with inheritanc…

> In my experience verbal thinkers struggle with inheritance, because it requires jumping between levels of abstraction and they aren't thinking in terms of semantic units. This is too dismissive of the criticism. The problem with inheritance is it makes control flow harder to understand and it spreads your logic all over a bunch of classes. Ironically, inheritance violates encapsulation - since a base class is usual…

I do not believe "it makes the control flow harder to understand" is as universal as you claim. If used badly any flow tool (including if-statements) can be be confusing. But "it can be complicated" doesn't mean we shouldn't use the tool when it is appropriate. One of the reasons I like Java Enums is because they provide much more structured guidance on what communicative inheritance looks like.

But we may also disagree on what "productive" means in the context of writing software.

The "taxonomy of code" you are dismissing is I believe what Fred Brooks describes as the "essential tasks" of programming: "fashioning of the complex conceptual structures that compose the abstract software entity".

It's not that I don't sympathize with your concern: being explicit and clear about "what the code is trying to do" is why TDD is popular among OOP programmers. But the step after "green" is "refactor", where the programmer stops focusing on what the code is trying to do and refines the taxonomy of the system that implements those tasks.

Re: Inheritance was invented as a performance hack (2021)

#243
post #241
post #204

Earlier quoted context omitted.

Very interesting work! It is an attempt to extract the interfaces that were in the minds of the implementors of the Smalltalk-80 system's collection classes, but which couldn't be expressed in the language itself, because it has no interface construct. That's what I meant by "Languages like Smalltalk (...) don't have interfaces at all."

Don't have manifest types and don't have manifest interfaces. Someone has already referenced "Adding Dynamic Interfaces to Smalltalk" [0] and looking back there doesn't seem to be any kind of demonstration that use of interfaces makes software faster to develop or less error prone or... [1] [0] https://www.jot.fm/issues/issue_2002_05/article1/ [1] https://www.cs.utexas.edu/~wcook/papers/OOPSLA89/interfaces.pdf

Unfortunately, in general, there is not much convincing proof that one way of developing software is better than another in such ways.

Re: Inheritance was invented as a performance hack (2021)

#245
post #83

Earlier quoted context omitted.

Java wasn't the first to do that Objective-C (10? years before) had interfaces. Even C++ has that with multiple inheritance - some parents can just be interfaces. As to whether Smalltalk needs interfaces see https://stackoverflow.com/a/7979852/151019 and https://www.jot.fm/issues/issue_2002_05/article1/

Objective-C and Smalltalk were always niche languages, at least by comparison to Java and C#, and I think Smalltalk fans underestimate the value of many things. C++ does not (or at least did not at the time) have a concept of interfaces. There was a pattern in some development communities for defining interfaces by writing classes that followed particular rules, but no first-class support for them in the language.

Java's object model is based on Objective-C's so a direct descendant and Objective-C's object model is based on Smalltalk so there is a direct connection there.

Re: Inheritance was invented as a performance hack (2021)

#246

IMHO Inheritance (especially the C++ flavored inheritance with its access specifiers and myriad rules) has always scared me. It makes a codebase confusing and hard to reason with. I feel the eschewing of inheritance by languages such as Go and Rust is a step in the right direction. As an aside, I have noticed that the robotics frameworks (ROS and ROS2) heavily rely on inheritance and some co-dependent C++ features li…

To be fair, deleting a derived object through a base class pointer is pretty basic C++. Slicing and virtual destructors are usually the first couple of things you learn about after virtual methods and copy constructors/assignment.

Quite a few sections of C++ can be classified as "pretty basic C++". None of the rules are complicated in isolation but that doesn't necessarily make it easy to reason about it.

Re: Inheritance was invented as a performance hack (2021)

#248

Earlier quoted context omitted.

To me, inheritence makes sense if you view your codebase as actual "Objects" The reality is that a codebase is not that simple. Many things you create are not representable as realworld "objects" - to me, this is where is gets confusing to follow especially when the code gets bigger. I remember those OOP books (I cannot comment on modern OOP books) where the first few chaptors would use Shapes as an example. Where A…

I’m not on the cutting edge of gamedev, but I still believe that ECS is a solid pattern with lots of use cases.

I do make games at home and dont follow ECS religiously, but it is there depsing on how I solve a problem.

:-)

Re: Inheritance was invented as a performance hack (2021)

#249

Earlier quoted context omitted.

I’m not on the cutting edge of gamedev, but I still believe that ECS is a solid pattern with lots of use cases.

Sounds like relational databases: Entities are IDs. Components are tables with an ID column.

EXACTLY!

It is very much like building a database.

Each class I created is very much like creating a table.

I had my "Objects" which was a simple class with an Id. In ECS land, this would be better known as an entity.

I would then create classes (or tables) for each "feature" to support.

A feature could be

Is it Solid? Is it Visible Is is a Shape/Model Does it has Position Does it have Children

etc.

Each feature an object supports gives it extra data. So each feature is essentially a table with an Id, ObjectId, and additional fields.

Basically, I am "creating my object hierarchy" at runtime, not at compile time with OOP methods. This made it sooo more flexible when more Companies wanted to use the software, especially with their unique approaches to shop management. All configurations were in XML files -- much better than trying to change an OOP hierarchy to suit ALL companies rulesets.

This is going back a few years, now. Its amazing what comes back to memory.. how I wrote most of this entirely in Javascript to eventually moving to a backend language using AJAX.. to simplifying code with jQuery.

Fond memories.

Re: Inheritance was invented as a performance hack (2021)

#250

I think many developers, especially in the range on 1999-2020, has gone through many pitfalls in programming. More specifically.. OOP. As someone who was blessed/lucky to learn C and Pascal.. with some VB6.. I understood how to write clean code with simple structs and functions. By the time I was old enough to get a job, I realised most (if not all) job adverts required OOP, Design Patterns, etc. I remember getting m…

I learned about OOP from a Turbo Pascal v5.5 book circa 1993. Drawing triangles, squares, circles, all the good stuff. Turbo Vision library was a powerful demonstration of the power of OOP which made MSFT MFC look like a mess in comparison.

I am convinced the The Turbo Pascal I had (I cannot remember the version) did not support OOP. If it did, the books I was reading never covered it. I did use Delphi a few years later during the College days. It was OK but I never loved the language. I thought it added the OOP side of things pretty well. To me, compared to C, Pascal was just a little bloated to write by comparison.

I think syntax has improved since then. Last time I touched Delphi was 2002.

Yes, MFC is a mess. As the years pass I would have been interested in trying NextStep during the prime years. It looked 10 years ahead over Microsofts Visual Studio in the mid-to-late 90s. A tool that evolved well into the Apple world.

Post reply on HN