Comment by mpweiher | Hacker News Reader

Comment by mpweiher | Hacker News Reader

Parent Full thread

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-9.html

The starting position of the "Objects have not failed" panelists is also on dreamsongs: 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.

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.

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.

None of that seems at-all like the discussions I recollect from those decades.

Who were those "certain advocates"?

yes, well, that illustrates the quality of many "consultants"

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.

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

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.

"Heavier than air flying machines are impossible" -- Lord Kelvin, 1895

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.

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/

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

That was 1997, and arguably we haven't really made progress in that area since then, and even regressed. Sad.

this is a famous quote that illustrates that this very famous scientist must have been mentally impaired at the time. did he look around? birds? paper planes? thrown beermats? kites?

machines

well, a bird is a machine, as are we. a modern glider is a machine (and Lilienthal had flown prior to the quote).

you need to specify what you think or don't think is a machine. as kelvin should have done.

> bird

"The term is commonly applied to artificial devices,.."

It seems he figured out that his audience was smart enough to figure out he wasn't deviating from common usage. And was mostly right.

> Lilienthal

Unpowered.

"A machine is a physical system using power to apply forces and control movement to perform an action."

https://en.wikipedia.org/wiki/Machine

Cheers.

also from same paragraph:

"but also to natural biological macromolecules, such as molecular machines. Machines can be driven by animals and people, by natural forces such as wind and water, and by chemical, thermal, or electrical power"

commonly

Bye now.

> Hidden. Invisible in the program's source text

where else should it be?

Actually in the source text.

It currently isn't.

how so? please provide an example.

See: 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)

Reply on news.ycombinator.com