3 ms·

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

by Arwill 5y ago

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.

lou1306 5y ago
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.
kitd 5y ago
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.
- js8 5y ago
  > which was a bit of an unguided mess at the time Oh, come on. There was https://en.wikipedia.org/wiki/Structured_program_theorem https://en.wikipedia.org/wiki/Structured_program_theorem and https://en.wikipedia.org/wiki/Modular_programming 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 https://dl.acm.org/doi/pdf/10.1145/359576.359579.
  - kitd 5y ago
    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.
    - deleted 5y ago
      [deleted]
- Someone 5y ago
  Simula 67 is (surprise) from 1967, Smalltalk-76 from 1976. Both supported objects and inheritance (http://progopedia.com/language/simula-67/ http://progopedia.com/language/simula-67/, http://worrydream.com/refs/Ingalls%20-%20The%20Smalltalk-76%20Programming%20System.pdf 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 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.
Tade0 5y ago
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 5y ago
  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 5y ago
    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 5y ago
    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.
rusk 5y ago
> 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?

by Arwill 5y ago

lou1306 5y ago

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.

kitd 5y ago

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.

js8 5y ago
> which was a bit of an unguided mess at the time Oh, come on. There was https://en.wikipedia.org/wiki/Structured_program_theorem https://en.wikipedia.org/wiki/Structured_program_theorem and https://en.wikipedia.org/wiki/Modular_programming 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 https://dl.acm.org/doi/pdf/10.1145/359576.359579.
- kitd 5y ago
  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.
  - deleted 5y ago
    [deleted]
Someone 5y ago
Simula 67 is (surprise) from 1967, Smalltalk-76 from 1976. Both supported objects and inheritance (http://progopedia.com/language/simula-67/ http://progopedia.com/language/simula-67/, http://worrydream.com/refs/Ingalls%20-%20The%20Smalltalk-76%20Programming%20System.pdf 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 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.

Tade0 5y ago

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 5y ago
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 5y ago
  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 5y ago
  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.

rusk 5y ago

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