4 ms·

It should be noted that this documented one of the starting positions of a panel discussion at OOPSLA 2002: Resolved: Objects have Failed. http://www.oopsla.o

It should be noted that this documented one of the starting positions of a panel discussion at OOPSLA 2002: Resolved: Objects have Failed. http://www.oopsla.org/2002/fp/files/pan-1.html http://www.oopsla.org/2002/fp/files/pan-1.html http://www.oopsla.org/2002/fp/files/pan-9.html http://www.oopsla.org/2002/fp/files/pan-9.html The starting position of the "Objects have not failed" panelists is also on dreamsongs: https://www.dreamsongs.com/ObjectsHaveNotFailedNarr.html https://www.dreamsongs.com/ObjectsHaveNotFailedNarr.html And if you take both of these seriously, I think it becomes clear that the main failure of object-orientation is that it hasn't really been done yet. From Guy Steele's remarks: Procedural programming still has its place in the coding of methods. This is true, but it is an understatement. And the crux of the problem. The place that procedural programming has is absolutely central, and there is actually little else, because even object oriented programming is ~90% writing (attached) procedures, except we call them methods. So in a way OO wrote a check that it then didn't let us cash. We should be able to construct structures of objects, with attributes and substructure, and then connect those objects to each other using various communication mechanisms. But we can't. Well, we can implement it, but we cannot express it. All we can express is procedures and procedure invocations. So we can invoke procedures to create an object, and capture creating that object in a procedure. We can connect that object to another object using another procedure call, and the communication will also be mediated using procedure calls. Where's the structure, the connecting, the communication? Hidden. Invisible in the program's source text. ("In the comments". Ha!) Just like loops and other control structures were hidden in the patterns of gotos that Dijkstra complained about. So while OOP has delivered a lot it actually has failed to deliver on one of its core promises. Because it wasn't fully implemented.

jeremyjh 4y ago
A distinction without a difference; what is the difference between failure of the paradigm and failure to implement the paradigm? If it hasn’t been implemented after 4-5 decades then maybe the idea just isn’t workable.
- mpweiher 4y ago
  "Heavier than air flying machines are impossible" -- Lord Kelvin, 1895
  - jeremyjh 4y ago
    And if, in 1895, you said "flying machines have failed" that statement would be 100% accurate. And if you suggested that a business should be built on the failed flying machines, you'd be laughed out of the room.
    - mpweiher 4y ago
      Which is why, in 2023, I wrote: "So while OOP has delivered a lot it actually has failed to deliver on one of its core promises." And of course Lord Kelvin, in 1985, didn't say "Flying machines have failed" he said "Flying machines are impossible". And you, in 2023: > If it hasn’t been implemented after 4-5 decades then maybe the idea just isn’t workable. Maybe. But also maybe not. First of all, it's not exactly like OO hasn't achieved anything in 4-5 decades. Nothing could be further from the truth. Just look around you! Or maybe let's see what Fred Brooks of "No Silver Bullet" fame had to say: "A burst of papers came and said “Oh yes, there is a silver bullet, and here it is, this is mine!” When ‘96 came and I was writing the new edition of The Mythical Man-Month and did a chapter on that, there was not yet a 10 fold improvement in productivity in software engineering. I would question whether there has been any single technique that has done so since. If so, I would guess it is object oriented programming, as a matter of fact." https://www.infoq.com/articles/No-Silver-Bullet-Summary/ https://www.infoq.com/articles/No-Silver-Bullet-Summary/ So for Fred Brooks, the one thing closest to an actual Silver Bullet according to his definition in software engineering was, drumroll, object oriented programming. Pretty impressive for an "unworkable" idea. Secondly, it has managed to achieve all of that while not even being fully developed yet! And I am not the only one saying that. Alan’s famous quip “I made up the term ‘object-oriented’, and I can tell you I did not have C++ in mind” was followed immediately with the far less quoted “The important thing here is I have many of the same feelings about Smalltalk”. https://www.youtube.com/watch?v=oKg1hTOQXoY&t=633s https://www.youtube.com/watch?v=oKg1hTOQXoY&t=633s That was 1997, and arguably we haven't really made progress in that area since then, and even regressed. Sad.
rprospero 4y ago
To provide a bit of context for some of the younger readers, certain advocates of OO in the early 90's argued that it would be an end of ALL procedural code. At the time, I listened to a talk by a computing consultant who asserted that, by the year 2000, all programming would be objects with no methods. Methods were just a crutch for programmers who didn't understand proper OO methodology. The same went for message passing, by the way. He believed that later versions of SmallTalk would eliminate message passing, as passing a message was just a procedure with extra steps. The programmer of the 21st century would merely define a class that inherits from other classes containing the desired behaviour. For example, at the base level, a language might have a "PrintH" class that prints the letter H where instantiated (with similar classes for other classes). You might then simply write your program class Main : inherits PrintH, PrintELower, PrintLLower, PrintLLower, PrintOLower, PrintComma, PrintSpace, PrintW, PrintOLower, PrintRLower, PrintLLower, PrintDLower Now, the above code is obviously tedious, but most programming would be done via higher level libraries. The important part was that a class was purely defined by what it inherits - the language would have no operation beyond inheritance. This was the only way to ensure that all code would be reusable.
- zabzonk 4y ago
  yes, well, that illustrates the quality of many "consultants"
- mpweiher 4y ago
  Oh boy! Good story. And of course he just reinvents a procedure with all this. There are things that are procedural, they should probably be expressed as procedures. The problem is that there are many things we want to express that are not really naturally procedural, yet we have to express them procedurally as well. 2nd order problem is that when there is another mechanism, people then want to use that as the "this can do everything"-mechanism. Yes, you're clever, now sit down. I have seen fibonacci expressed as dataflow more times than I care to remember. It's not a pretty sight. But dataflow expressed procedurally also not so cool.
- igouy 4y ago
  None of that seems at-all like the discussions I recollect from those decades. Who were those "certain advocates"?
zabzonk 4y ago
> Hidden. Invisible in the program's source text where else should it be?
- mpweiher 4y ago
  Actually in the source text. It currently isn't.
  - zabzonk 4y ago
    how so? please provide an example.
    - mpweiher 4y ago
      See: https://2020.programming-conference.org/details/salon-2020-papers/5/Can-Programmers-Escape-the-Gentle-Tyranny-of-call-return- https://2020.programming-conference.org/details/salon-2020-p... Very briefly: what we currently have is procedures that implement these things, but that's not the same thing. Just like having a loop implemented by gotos is not the same thing as having a loop. (See Dijkstra)
msla 4y ago
We have those things, we call them spreadsheet cells. A spreadsheet cell is an object in that it has a state tied to some procedural code that computes the state, possibly in reference to other cells, possibly just in that the identity function is, indeed, a function. The point is, the vast majority of the procedural stuff, the state updates and the method invocations, are implicit, just as the gotos become implicit when you use while loops. Using objects to represent real-world entities was always a somewhat loopy idea, and one that obscured the real power of OO as it is now: The ability to abstract over kinds of behavior using inheritance or mix-ins. "This type has the Ordinal behavior set" or "This function can accept any value of any type with the Printable behavior set" is a powerful leg-up for procedural programming and shouldn't be ignored, but it is, fundamentally, an improvement to procedural programming, and not a wholly new way to think about code.
rileyphone 4y ago
NetKernel seemed to have gotten close to this state, it's too bad it stayed commercial and now seems dead. https://www.youtube.com/watch?v=1O8PwkXfDJg https://www.youtube.com/watch?v=1O8PwkXfDJg

jeremyjh 4y ago

A distinction without a difference; what is the difference between failure of the paradigm and failure to implement the paradigm? If it hasn’t been implemented after 4-5 decades then maybe the idea just isn’t workable.

mpweiher 4y ago
"Heavier than air flying machines are impossible" -- Lord Kelvin, 1895
- jeremyjh 4y ago
  And if, in 1895, you said "flying machines have failed" that statement would be 100% accurate. And if you suggested that a business should be built on the failed flying machines, you'd be laughed out of the room.
  - mpweiher 4y ago
    Which is why, in 2023, I wrote: "So while OOP has delivered a lot it actually has failed to deliver on one of its core promises." And of course Lord Kelvin, in 1985, didn't say "Flying machines have failed" he said "Flying machines are impossible". And you, in 2023: > If it hasn’t been implemented after 4-5 decades then maybe the idea just isn’t workable. Maybe. But also maybe not. First of all, it's not exactly like OO hasn't achieved anything in 4-5 decades. Nothing could be further from the truth. Just look around you! Or maybe let's see what Fred Brooks of "No Silver Bullet" fame had to say: "A burst of papers came and said “Oh yes, there is a silver bullet, and here it is, this is mine!” When ‘96 came and I was writing the new edition of The Mythical Man-Month and did a chapter on that, there was not yet a 10 fold improvement in productivity in software engineering. I would question whether there has been any single technique that has done so since. If so, I would guess it is object oriented programming, as a matter of fact." https://www.infoq.com/articles/No-Silver-Bullet-Summary/ https://www.infoq.com/articles/No-Silver-Bullet-Summary/ So for Fred Brooks, the one thing closest to an actual Silver Bullet according to his definition in software engineering was, drumroll, object oriented programming. Pretty impressive for an "unworkable" idea. Secondly, it has managed to achieve all of that while not even being fully developed yet! And I am not the only one saying that. Alan’s famous quip “I made up the term ‘object-oriented’, and I can tell you I did not have C++ in mind” was followed immediately with the far less quoted “The important thing here is I have many of the same feelings about Smalltalk”. https://www.youtube.com/watch?v=oKg1hTOQXoY&t=633s https://www.youtube.com/watch?v=oKg1hTOQXoY&t=633s That was 1997, and arguably we haven't really made progress in that area since then, and even regressed. Sad.

rprospero 4y ago

To provide a bit of context for some of the younger readers, certain advocates of OO in the early 90's argued that it would be an end of ALL procedural code. At the time, I listened to a talk by a computing consultant who asserted that, by the year 2000, all programming would be objects with no methods. Methods were just a crutch for programmers who didn't understand proper OO methodology. The same went for message passing, by the way. He believed that later versions of SmallTalk would eliminate message passing, as passing a message was just a procedure with extra steps. The programmer of the 21st century would merely define a class that inherits from other classes containing the desired behaviour. For example, at the base level, a language might have a "PrintH" class that prints the letter H where instantiated (with similar classes for other classes). You might then simply write your program class Main : inherits PrintH, PrintELower, PrintLLower, PrintLLower, PrintOLower, PrintComma, PrintSpace, PrintW, PrintOLower, PrintRLower, PrintLLower, PrintDLower Now, the above code is obviously tedious, but most programming would be done via higher level libraries. The important part was that a class was purely defined by what it inherits - the language would have no operation beyond inheritance. This was the only way to ensure that all code would be reusable.

zabzonk 4y ago
yes, well, that illustrates the quality of many "consultants"
mpweiher 4y ago
Oh boy! Good story. And of course he just reinvents a procedure with all this. There are things that are procedural, they should probably be expressed as procedures. The problem is that there are many things we want to express that are not really naturally procedural, yet we have to express them procedurally as well. 2nd order problem is that when there is another mechanism, people then want to use that as the "this can do everything"-mechanism. Yes, you're clever, now sit down. I have seen fibonacci expressed as dataflow more times than I care to remember. It's not a pretty sight. But dataflow expressed procedurally also not so cool.
igouy 4y ago
None of that seems at-all like the discussions I recollect from those decades. Who were those "certain advocates"?

zabzonk 4y ago

> Hidden. Invisible in the program's source text where else should it be?

mpweiher 4y ago
Actually in the source text. It currently isn't.
- zabzonk 4y ago
  how so? please provide an example.
  - mpweiher 4y ago
    See: https://2020.programming-conference.org/details/salon-2020-papers/5/Can-Programmers-Escape-the-Gentle-Tyranny-of-call-return- https://2020.programming-conference.org/details/salon-2020-p... Very briefly: what we currently have is procedures that implement these things, but that's not the same thing. Just like having a loop implemented by gotos is not the same thing as having a loop. (See Dijkstra)

msla 4y ago

We have those things, we call them spreadsheet cells. A spreadsheet cell is an object in that it has a state tied to some procedural code that computes the state, possibly in reference to other cells, possibly just in that the identity function is, indeed, a function. The point is, the vast majority of the procedural stuff, the state updates and the method invocations, are implicit, just as the gotos become implicit when you use while loops. Using objects to represent real-world entities was always a somewhat loopy idea, and one that obscured the real power of OO as it is now: The ability to abstract over kinds of behavior using inheritance or mix-ins. "This type has the Ordinal behavior set" or "This function can accept any value of any type with the Printable behavior set" is a powerful leg-up for procedural programming and shouldn't be ignored, but it is, fundamentally, an improvement to procedural programming, and not a wholly new way to think about code.

rileyphone 4y ago

NetKernel seemed to have gotten close to this state, it's too bad it stayed commercial and now seems dead. https://www.youtube.com/watch?v=1O8PwkXfDJg https://www.youtube.com/watch?v=1O8PwkXfDJg