Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C Object Oriented Programming (2014)

nullprogram.com

Post reply on HN
Print view View original

51–60 of 61 posts

Re: C Object Oriented Programming (2014)

#51

Post by randomdata »

alex_smart wrote: post #45
randomdata wrote: post #34

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.

> Not sure what you mean. Could you please elaborate?

I'm not sure where your understanding falls short. Which part are you unsure of?

> The idea of using dynamic dispatch as a means of taming complexity.

Erlang utilizes the idea of dynamic dispatch as a means of taming complexity. What is it in particular about its dynamic dispatch mechanisms that you want me to know when you call attention to its OOP properties?

C++ also utilizes the idea of dynamic dispatch. When you call attention to its OOP properties, are the particulars being pointed to the same as in Erlang, or does it mean something different in the context of that language?

Re: C Object Oriented Programming (2014)

#52

Post by 1bent »

One domain that a little OO seems to map to without too much pain is GUI libraries. The first OO-flavoured API I ever used was Sunview, the early GUI I used on Sun-3 workstations with SunOS. It was a beautiful API; I was never tempted to mess with the verbose, complex "Intrinsics-based" toolkits that followed it. It carried on with xview; that's what I'd try if I wanted to write a GUI in C today.

Re: C Object Oriented Programming (2014)

#53

Post by mpweiher »

andai wrote: post #47
mpweiher wrote: post #42

Earlier quoted context omitted.

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…

So what are the benefits? (I'm assuming you mean benefits to Smalltalk, not Java.)

https://www.dreamsongs.com/ObjectsHaveNotFailedNarr.html

Re: C Object Oriented Programming (2014)

#54

Post by mpweiher »

rramadass wrote: post #49
mpweiher wrote: post #42

Earlier quoted context omitted.

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…

> 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, 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 suffi…

> Most people who cargo-cult "OO is bad" don't get this [that OO programs are meta programs that build the system].

Alas, many people who advocate OO don't get this either, and in particular they don't see this as a problem to be solved.

Having to do things indirectly is not a good state of affairs. See "goto statement considered harmful". [1]

It is similar to the way we had to work with text editors made for printing terminals: "...requires a mental skill like that of blindfold chess; the user must keep a mental image of the text he is editing, which he cannot easily see, and calculate how each of his editing command `moves' changes it." [2]

> OOD/OOP has been a great success that has led to the explosion of software that we take for granted today.

Yes, people forget that the problems we are now having are the ones that are due to OO success.

> At language source level (eg. DSL) or binary component level (needs runtime support a la COM)

Language level. At the systems level we know how to build these types of system (COM, Smalltalk, Objective-C, Unix pipes and filter, REST, notification systems, ...), what we lack is the ability to express them in the program text: https://objective.st/

[1] https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.p...

[2] https://www.gnu.org/software/emacs/emacs-paper.html

Re: C Object Oriented Programming (2014)

#55

Post by o11c »

nemetroid wrote: post #44
o11c wrote: post #18

Earlier quoted context omitted.

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…

Successful dynamic_casts are fast. But failing dynamic_casts usually involve at least one strcmp and are extremely expensive. https://gcc.gnu.org/legacy-ml/gcc-patches/2009-07/msg01239.h...

For the particular set of tradeoffs made by C++. When rolling your own you don't have to do make the same choices.

Re: C Object Oriented Programming (2014)

#56

Post by rramadass »

mpweiher wrote: post #54
rramadass wrote: post #49

Earlier quoted context omitted.

> 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, 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 suffi…

> Most people who cargo-cult "OO is bad" don't get this [that OO programs are meta programs that build the system]. Alas, many people who advocate OO don't get this either, and in particular they don't see this as a problem to be solved. Having to do things indirectly is not a good state of affairs. See "goto statement considered harmful". [1] It is similar to the way we had to work with text editors made for printin…

> Having to do things indirectly is not a good state of affairs.

One key point to note here is that "Indirection" is often the mechanism used to design and express an "Abstraction". Given that Abstraction is the key to taming complexity and building large Systems they often go together i.e. Indirection becomes a key element in the design of Abstractions. It is only the non-designer of the Abstraction/Indirection who finds it hard to understand the System in the absence of Documentation/Communication.

Re: C Object Oriented Programming (2014)

#57

Post by meheleventyone »

alex_smart wrote: post #36
meheleventyone wrote: post #35

Earlier quoted context omitted.

Yeah, the callee doesn’t have to have the method defined for it to be called and Smalltalk objects have a default you can use to do things with messages you don’t handle for example forward them on to another object.

You can definitely do that in Java too. This is how, e.g., Spring framework handles transactional behavior. It injects a proxy for each bean that is marked as @Transactional and the proxy object handles the coordination with the transaction manager and passes all the arguments to the real object.

Right but it’s not a core part of the language, anything Turing complete can implement this sort of thing. The comment I was replying to was asking about the difference between method calls and message passing.

Re: C Object Oriented Programming (2014)

#58

Post by alex_smart »

meheleventyone wrote: post #57
alex_smart wrote: post #36

Earlier quoted context omitted.

You can definitely do that in Java too. This is how, e.g., Spring framework handles transactional behavior. It injects a proxy for each bean that is marked as @Transactional and the proxy object handles the coordination with the transaction manager and passes all the arguments to the real object.

Right but it’s not a core part of the language, anything Turing complete can implement this sort of thing. The comment I was replying to was asking about the difference between method calls and message passing.

I don't think ability to forward arbitrary messages is any more a core part of Smalltalk than it is of Java.

Re: C Object Oriented Programming (2014)

#59

Post by mpweiher »

rramadass wrote: post #56
mpweiher wrote: post #54

Earlier quoted context omitted.

> Most people who cargo-cult "OO is bad" don't get this [that OO programs are meta programs that build the system]. Alas, many people who advocate OO don't get this either, and in particular they don't see this as a problem to be solved. Having to do things indirectly is not a good state of affairs. See "goto statement considered harmful". [1] It is similar to the way we had to work with text editors made for printin…

> Having to do things indirectly is not a good state of affairs. One key point to note here is that "Indirection" is often the mechanism used to design and express an "Abstraction". Given that Abstraction is the key to taming complexity and building large Systems they often go together i.e. Indirection becomes a key element in the design of Abstractions. It is only the non-designer of the Abstraction/Indirection who…

Yes and no.

Yes, indirection in the source "abstraction" is the way to get to a new abstraction.

However, the result has to be an actual abstraction for that to work, and it often isn't. Often it's just indirection. And once you have the new abstraction, you have to be able to express yourself using that abstraction with little or no leakage.

For example, the "procedure" abstraction works that way, we really and truly don't have to care how it is constructed from assembly language instructions roughly 99.999% of the time.

But here's the kicker: since the actual abstraction mechanism in our languages is procedural, we can only create essentially procedural abstractions. For all other kinds of abstractions, the leakage is close to 100% and we are left with just indirection.

In the code.

Which means we need to take our abstractions and hand-compile them to fit our procedural languages, which we do with varying degrees of deftness. And then mechanisms of communicating the actual but mostly implicit "source" program become crucial, as you point out.

I'd rather be able to create and express those abstractions in the code itself. And then be able to program with those abstractions, rather than having to program in the target language of the human compiler.

Re: C Object Oriented Programming (2014)

#60

Post by meheleventyone »

alex_smart wrote: post #58
meheleventyone wrote: post #57

Earlier quoted context omitted.

Right but it’s not a core part of the language, anything Turing complete can implement this sort of thing. The comment I was replying to was asking about the difference between method calls and message passing.

I don't think ability to forward arbitrary messages is any more a core part of Smalltalk than it is of Java.

It’s the basis of the design of Smalltalk (see http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-...) and needs scaffolding in Java to work which does seem significant.
Post reply on HN