| ▲ | nottorp 10 days ago |
| Any way to find out what the 35 year mistake was without being "engaged" for hours on that video? |
|
| ▲ | chrisg23 6 days ago | parent | next [-] |
| Really short: ECS existed in the earliest implementations of OOP in 1963 and was being used in the software he showed. When OOP went mainstream it pretty much was entirely about "compile time hierarchy of encapsulation that matches the domain model" and nothing else. His opinion is the standard way of doing OOP is a bad match for lots of software problems but became the one-size-fits-all solution as a result of ignorance. Also he claims that history is being rewritten to some extent to say this wasn't the case and there was never a heavy emphasis on doing things that way. |
|
| ▲ | isotropy 10 days ago | parent | prev | next [-] |
| OOPs = "object-oriented programming", BUT it's a more restrained and thoughtful complaint than just "objects suck" or "inheritance sucks". He cabins it pretty clearly at 11:00 minutes in: "compile-time hierarchy of encapsulation that matches the domain model was a mistake" |
| |
| ▲ | ocrow 10 days ago | parent | next [-] | | To unpack that a little, he looks to the writings of the early developers of object oriented programming and identifies the ways this assumption became established. People like Bjarne Stroustrup (developer of C++) took on and promulgated the view that the inheritance hierarchy of classes in an object oriented system can be or should be a literal instantiation of the types of objects from the domain model (e.g. different types of shapes in a drawing program). This is a mistake is because it puts the broad-scale modularization boundaries of a system in the wrong places and makes the system brittle and inflexible. A better approach is one where large scale system boundaries fall along computational capability lines, as exemplified by modern Entity Component Systems. Class hierarchies that rigidly encode domain categorizations don't make for flexible systems. Some of the earliest writers on object encapsulation, e.g. Tony Hoare, Doug Ross, understood this, but later language creators and promoters missed some of the subtleties of their writings and left us with a poor version of object-oriented programming as the accepted default. | | |
| ▲ | igouy 6 days ago | parent | next [-] | | > This is a mistake is because https://news.ycombinator.com/item?id=44638183 | |
| ▲ | mariodiana 6 days ago | parent | prev [-] | | Is Objective-C discussed at all? | | |
| ▲ | tmp10423288442 6 days ago | parent | next [-] | | Only as a brief aside (don't have the timestamp right now) to talking about Smalltalk, which he mostly discusses to argue that Smalltalk was not different from C++ in seeking (most of the time) to model programs in terms of static hierarchies (according to the primary source documentation from the time of Smalltalk's design): > And another thing is if you look at the other branch, > the branch that I'm not really covering very much > in this talk, because again, > we don't program in small talk these days, right? > The closest thing you would get > is maybe something like Objective-C. > If there's some people out there using Objective-C, > you know, like Apple was using that for a little while, > so Objective-C kind of came > from a small talk background as well. Objective-C is basically Smalltalk retrofitted onto C, even more than C++ was Simula retrofitted onto C (before C++ gained template metaprogramming and more modern paradigms), so it makes sense that Muratori doesn't go much into it, given that he doesn't discuss Smalltalk much. | | |
| ▲ | Jtsummers 6 days ago | parent [-] | | >> you know, like Apple was using that for a little while, If we discount NeXT's time using it, Apple's only been using Objective-C for 28 years, just a little while. It also (barely) preceded C++. |
| |
| ▲ | 6 days ago | parent | prev [-] | | [deleted] |
|
| |
| ▲ | lisbbb 6 days ago | parent | prev [-] | | Inheritance sucks if you wish to write good unit tests easily. It just totally freaking sucks due to encapsulation. When you step back, you realize that composition is a far better approach to writing testable code. |
|
|
| ▲ | nine_k 6 days ago | parent | prev | next [-] |
| In short, in my opinion: - Encapsulation / interfaces is a good idea, a continuation of the earlier ideas of structured programming. - Mutable state strewn uncontrollably everywhere is bad idea, even in a single-threaded case. - Inheritance-based polymorphism is painful, both in the multiple (C++) and single (Java) inheritance cases. Composable interfaces / traits / typeclasses without overriding methods are logically and much more useful. |
| |
| ▲ | lisbbb 6 days ago | parent [-] | | Over multiple decades, I have come to reject all of it! Even interfaces. I watched over and over again people writing code to interfaces, particularly due to Spring, and then none of those interface ever got a second implementation done and were never, ever going to! It was a total waste of time, even for testing it was almost a total waste of time, but I guess writing stubbed test classes that could pretend to return data from a queue or a database was somewhat useful. The thing is, there were easier ways to achieve that. | | |
| ▲ | zaphar 5 days ago | parent [-] | | Those interfaces that never got a second implementation were still defining the contract for interacting with another part of your system and that compile time enforced contract provides value. I have plenty of complaints about Spring but interfaces is not one of them. | | |
|
|
|
| ▲ | kragen 6 days ago | parent | prev | next [-] |
| Basically his “35-year mistake” thesis is that we almost had ECS, the entity/component/system pattern, in 01963 with Sketchpad, but it took until 01998. He explains this near the end of the talk proper, and explains how Looking Glass in 01998 introduced the pattern in Ultima II Underworld, but really introduced it with Tom Leonard’s Thief: The Dark Project. Later though he seems to be saying that he's not sure ECS is actually a good idea, but he thinks encapsulation is, if not a bad idea, at least an idea that should be applied carefully to keep it from getting in your way, and definitely not in a way that reflects a division among problem-domain objects such as cars, trucks, bridges, circular arcs, lanterns, etc. |
|
| ▲ | constantcrying 5 days ago | parent | prev | next [-] |
| The 35 year mistake was the idea that in order to have a well structured program, your compile time hierarchies have to represent real world relationships. The talk traces that mistake to Simula, where it was appropriately used, because it was intended to simulate the real world hierarchies. Then to C++ where it started to become used inappropriately, then to Java, where it became a universal Praxis to model all real world relationship as compile time hierarchies. |
|
| ▲ | nijuashi 6 days ago | parent | prev | next [-] |
| Stroustrup took out object hierarchy introspection feature that was available before, which turned out to be a pretty handy feature that people kept trying to reimplement. |
| |
| ▲ | pjmlp 5 days ago | parent [-] | | Finally coming into C++26, but boy the syntax, C++ keeps competing with Perl on that regard, and I say this as someone that enjoys coding in C++ on my free time. |
|
|
| ▲ | lproven 10 days ago | parent | prev [-] |
| I don't know, but given the page, I think it is OOPS. Object oriented programming. |
| |
