[thewickedaxe]

I'm a little confused. Inheritance, types and all that stuff are just language concepts right? Simula may have been one of the first to implement inheritance as a means to an end, but how could they have "invented" inheritance? I'm sure the idea of inheritance was already there in language proofs.

[I might be really really wrong here]

[username90]

Theory usually comes after practice. People create something that works, then theorists formalizes it into a well defined concept.

[Arwill]

I hold the view that programming patterns were invented as solutions to technical problems. It was then later that some theoretical "usefulness" or "elegance" was attached to them.

One should know the technical benefits and drawbacks of programming patterns before applying them. Just because some language or environment or majority of programmers promotes it, doesn't mean that its ok to apply it. Without knowing the technical reason for applying a pattern is just cargo cult programming.

[kitd]

I hold the view that programming patterns were invented as solutions to technical problems. It was then later that some theoretical "usefulness" or "elegance" was attached to them.

IIRC, there was impetus from Christopher Alexander's architectural "pattern language", and the desire to do something similar in software, which was a bit of an unguided mess at the time.

[Someone]

Simula 67 is (surprise) from 1967, Smalltalk-76 from 1976. Both supported objects and inheritance (http://progopedia.com/language/simula-67/, http://worrydream.com/refs/Ingalls%20-%20The%20Smalltalk-76%...)

“A pattern language” is from 1977; its application to programming from 1987 (http://c2.com/doc/oopsla87.html)

So, in the context of “Simula may have been one of the first to implement inheritance as a means to an end, but how could they have "invented" inheritance?”, I think this discussion is diverging a bit.

I would guess the idea of inheritance was already used in some assembly programs. It would start with people using structures that shared initial fields, and passing them to functions that didn’t care about the other fields (functions handling intrusive linked lists, for example). Passing a pointer to a function that _does_ know the exact type of the fields would be the next step.

The next step would be to allow heterogenous collections and use logic to discern between the various variants (many lisps do that by going through an “is it an atom?, is it a number? etc. chain, and likely did that years before Simula 67 appeared)

Chances are somebody also embedded a function pointer or two inside such objects, but I guess that would have come fairly late, as a function pointer in each object would have been expensive, memory-wise in the ‘60s and ‘70s.

Anyway, I think ‘inheritance’ indeed was invented/discovered, but gradually, and without explicitly naming it.

[js8]

> which was a bit of an unguided mess at the time

Oh, come on. There was https://en.wikipedia.org/wiki/Structured_program_theorem and https://en.wikipedia.org/wiki/Modular_programming. There was a discussion about functional programming, for example famous John Backus article - https://dl.acm.org/doi/pdf/10.1145/359576.359579.

[kitd]

I was really thinking lower-level, specifically OOP, though yes I should've said it. OOP was going to save the world but no one knew how to design properly with it. GoF patterns were a set of off-the-shelf tactical designs intended to get you started in the right direction.

[Tade0]

The other day I got into a heated debate with a C# developer on the merits (or lack thereof) of adding an "I" prefix to interfaces.

Turns out in C# there's no syntactic difference between implementing an interface and inheritance, so it makes sense in C# to explicitly state that something is an interface but, arguably, only there.

[layer8]

The argument against “I” is that the user (client code) of an instance shouldn’t have too care whether the type of the reference is an interface or a class. Concerns of the implementor shouldn’t determine the naming visible to the client code.

Of course, it’s an established C# convention (and inspired by the naming convention for COM interfaces) so one better sticks with it, but I think the convention was a bad choice for the reason stated above.

[dragonwriter]

Yeah, IMV its a similar problem to the convention of prefixing DB objects with T (table) or V (view), but not as bad because refactoring between class and interface should be rare.

[Tade0]

100% agreed. My day job is in front-end development and we unfortunately had this convention in a few projects.

Problem is, sometimes the are changes in how types are composed and what used to be an interface can end up as a type alias and vice versa.

[lou1306]

Many language features followed that route, yes. Languages themselves are typically first introduced, and then (maybe) formalized. Meanwhile, some other "patterns" or features, like higher-order functions or recursion, were originally introduced in the context of theoretical CS (e.g. they can be described in the lambda calculus), and it took some effort to implement them in practice.

[rusk]

> It was then later that some theoretical "usefulness" or "elegance" was attached

This Chicken v Egg pondering is interesting. I mean, surely the term "inheritance" was used in this instance because it already resembled something that had been established in theory?

[vincnetas]

Just like some artists create art? First they do then they explain.

[nathias]

idea > practice > formalization or idea > formalization > practice

[rusk]

I share your confusion to a degree. To me it always seemed that the concept emerged from the work on Semantic Networks [0] by Collins and Quinlan.

What's interesting is, looking at this now that these two different aspects of what we nowadays consider to be a fairly well defined computer science concept both seem to have emerged around the same time.

Could it be C & Q were inspired by the Simula guys, or vice versa maybe Simula adopted the term because the implementation "resembled" the semantic definition. Or perhaps they independently emerged from concepts that were popular at the time!

[0] https://en.wikipedia.org/wiki/Semantic_network

[morelisp]

I would put OOP's solid theoretical foundations at the Liskov Substitution Principle invented in ~1988. This seems relatively late compared to OO's popularity. It was less than ~10 years between "structured programming" and the structured programming theorem (and lots of useful formal steps on the way), vs. 20+ for OOP and LSP (and at least at today's distance, LSP along with Meyer's contemporary substitution principles seems more like a sea change).