41–50 of 61 posts
Earlier quoted context omitted.
Which C++ modules fix. Plus that same C pattern compiles in C++ without problems.
C++ modules sound incredibly hard to use.
VC++ and clang 17 mostly works now.
Earlier quoted context omitted.
>Few languages utilize message passing Yet most of them call themselves object-oriented! I'm reminded of the Alan Kay quote, "I invented the term object-oriented, and I can tell you that C++ wasn't what I had in mind."
Is Smalltalk’s message passing really all that different from methods from other OOP languages? Seems like quite an arbitrary distinction to me.
https://www.youtube.com/watch?v=oKg1hTOQXoY&t=653s
(go back a little for the original quote)
For me, the problem with OO as is is that it really is just a Better Old Thing, not an actual New Thing, as the "object" part is quite underdeveloped.
When you have an object-oriented system, it is objects that are connected (somehow) and that then communicate (somehow).
But our object-oriented languages really only still have algorithms (procedures) and data structures. We do get to group and scope those procedures with the data structures, but that's not really too different from what we do in procedural coding.
So when we build a true OO system, we don't have any language support with it, so the program we write is a meta program that constructs the OO system procedurally. The system is not visible in the program text, it is created as a side effect of running the procedures and remains invisible, unless we develop tooling to make it visible.
And when that OO system runs, after you've built it procedurally, how is the communication between object mediate? Also procedures. Again, if there are other communication patterns, they can only be implemented using procedures in the language, they cannot be expressed in the language.
So with current programming languages (even OO ones), a good OO system will, by necessity, be highly indirect compared to the program text. A good OO system will also have sufficient benefits that this trade-off is very much worthwhile, but it is a significant trade-off. And when systems are not good the trade-off is not worth it. What's worse, people get confused and see the indirection not as the trade-off, but as the point of OO. I think those are the examples that people who are extremely jaded by OO have been exposed to: layers upon layers of indirection without a point. Indirection for indirection's sake.
And so they say that this is all BS and you should just not use OO. And they have a point, though they are not correct. Good OO developers handle this tradeoff by getting the benefits of OO with the minimum amount of indirection needed. Tooling like that found in modern Smalltalk systems can help you interact with the OO system that is not visible in the program text.
My approach to the tradeoff is to remove the indirection in the program text by making it possible to directly express components, connectors and systems in the program text, rather than having to build them all procedurally.
Earlier quoted context omitted.
I've also seen template hierarchies so deep it was a major effort trying to figure out which template did anything besides forward to another template.
Ugh yes. This has beeb my experience with Java code in large corporate projects. Just endless layers of seemingly pointless abstraction
People then get confused and think that indirection is the point. It's not.
It would be better if the indirection weren't needed and we could express more than just procedural abstraction in our PLs.
Earlier quoted context omitted.
Is there anything you need multimethods for that can't be patched with visitors and other design patterns? They have always seemed to me like a neat feature that are devilishly tricky to implement and difficult to reason about for the average programmer.
You don't need multimethods per se, but you need something and `dynamic_cast` is usually easiest (and with reasonable restrictions, most efficient). Overloaded operators is a major category of problem here. The "which subclass (if any) is more derived" might be done by the compiler proper, but that still needs to use the cast internally. And of course if you ignore operator overloading, you're just pulling a Java and…
https://gcc.gnu.org/legacy-ml/gcc-patches/2009-07/msg01239.h...
Earlier quoted context omitted.
I mean that, to me, the difference between message passing and method calling is not significant enough to say that these languages are following different programming paradigms - like you say OOP vs languages with objects. Afaict the difference between Smalltalk and Objective-C style message passing and Java and C# style method calling is purely syntactic.
> Afaict the difference between Smalltalk and Objective-C style message passing and Java and C# style method calling is purely syntactic. doesNotUnderstand:/forwardInvocation: isn't different? That is not just syntactical. How would you even begin to orient your objects without like functionality? I agree that if you squint really hard they look the same. But if we say "they are all the same", what are you trying to…
Not sure what you mean. Could you please elaborate?
> what are you trying to communicate when you say OOP?
The idea of using dynamic dispatch as a means of taming complexity.
>Object oriented programming, polymorphism in particular, is essential to nearly any large, complex software system. Without it, decoupling different system components is difficult. (Update in 2017: I no longer agree with this statement.) The author doesn't seem to elaborate on this. I was taught OOP in university and then promptly learned that it's frowned upon in performance sensitive code, which is my main interes…
I've found OOP can increase coupling. I actually have this problem at work. Say I have class A and B. I could write `int x = A:FunctionOfAandB(B b)`, but in this case. So now A depends on B. It would be much preferable to have free function of A and B. A and B are no longer dependent on each other, just the function to compute the result dependent on A and B. IMO: The real thing of value OOP provides is calling with…
Earlier quoted context omitted.
Is Smalltalk’s message passing really all that different from methods from other OOP languages? Seems like quite an arbitrary distinction to me.
It's a little different, and a little better. But not that much. In fact, right after that famous quote, Alan goes on to say: "I have many of the same feelings about Smalltalk". https://www.youtube.com/watch?v=oKg1hTOQXoY&t=653s (go back a little for the original quote) For me, the problem with OO as is is that it really is just a Better Old Thing, not an actual New Thing, as the "object" part is quite underdeveloped…
>Object oriented programming, polymorphism in particular, is essential to nearly any large, complex software system. Without it, decoupling different system components is difficult. (Update in 2017: I no longer agree with this statement.) The author doesn't seem to elaborate on this. I was taught OOP in university and then promptly learned that it's frowned upon in performance sensitive code, which is my main interes…
When programmers faced the "Software Crisis" in the 1960s (https://en.wikipedia.org/wiki/Software_crisis) the idea of "Software as Components" was born as the solution (https://en.wikipedia.org/wiki/Component-based_software_engin...). This was a direct result of research on "Separation of Concerns/Information Hiding/Modularization/Structured Programming" design requirements. The idea was to make it similar to how "Components" were used in the Hardware Industry where you could substitute different components across different products/product families and all can be developed independently but used in a drop-in/plug-and-play manner to build up an entire System.
OOD/OOP turned out to be a natural architecture for Components since they provided the necessary support for the above-mentioned design requirements. There are two aspects to this architecture a) Source/Language level b) Binary/Usage level. The latter was the "holy grail" and people invented complete binary runtime architectures like COM/DCOM/CORBA/etc.(eg. https://en.wikipedia.org/wiki/Component_Object_Model) with language-neutral interfaces defined via a IDL (https://en.wikipedia.org/wiki/Interface_description_language). You could now have binary software components publish well defined interfaces which clients could call at runtime to discover and use services. The OO idea of encapsulation of data+procedures in a single "Object" keeps the model clean. But note that OO itself is merely a way of composing/structuring procedural code with a strong emphasis on a certain method of architecting the whole System.
Thus OOD/OOP helps greatly in designing systems where components can be kept well decoupled and extensible. The same can be done in a non-OO way (depending on your definition of OO) but is much harder. The design requirements mentioned above have to be satisfied whichever path you take. The role of a OO language merely facilitates the ease with which you can/cannot architect such a System.
Earlier quoted context omitted.
Is Smalltalk’s message passing really all that different from methods from other OOP languages? Seems like quite an arbitrary distinction to me.
It's a little different, and a little better. But not that much. In fact, right after that famous quote, Alan goes on to say: "I have many of the same feelings about Smalltalk". https://www.youtube.com/watch?v=oKg1hTOQXoY&t=653s (go back a little for the original quote) For me, the problem with OO as is is that it really is just a Better Old Thing, not an actual New Thing, as the "object" part is quite underdeveloped…
Great way of stating it! Most people who cargo-cult "OO is bad" don't get this.
> a good OO system will, by necessity, be highly indirect compared to the program text. A good OO system will also have sufficient benefits that this trade-off is very much worthwhile,
Very true. This is the reason OOD/OOP has been a great success that has led to the explosion of software that we take for granted today.
> My approach to the tradeoff is to remove the indirection in the program text by making it possible to directly express components, connectors and systems in the program text, rather than having to build them all procedurally.
At language source level (eg. DSL) or binary component level (needs runtime support a la COM) ?
Earlier quoted context omitted.
> Afaict the difference between Smalltalk and Objective-C style message passing and Java and C# style method calling is purely syntactic. doesNotUnderstand:/forwardInvocation: isn't different? That is not just syntactical. How would you even begin to orient your objects without like functionality? I agree that if you squint really hard they look the same. But if we say "they are all the same", what are you trying to…
>doesNotUnderstand:/forwardInvocation: isn't different? That is not just syntactical. How would you even begin to orient your objects without like functionality? Not sure what you mean. Could you please elaborate? > what are you trying to communicate when you say OOP? The idea of using dynamic dispatch as a means of taming complexity.