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