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

Object-Oriented Programming in C (2019) [pdf]

state-machine.com

Post reply on HN
Print view View original

51–60 of 95 posts

Re: Object-Oriented Programming in C (2019) [pdf]

#51

Post by vbtemp »

ncmncm wrote: post #21

Back in the '90s, "Object-Oriented" got redefined in popular imagination to "good". If your language or system was good , it was then by definition object-oriented . Anything good had therefore to be called OO. Saying something was not actually OO (e.g. this) was taken to mean it was not good , generating spurious conflict. The fiction has largely dissipated, except among pundits and the aggressively ignorant. Meanwh…

> Back in the '90s, "Object-Oriented" got redefined in popular imagination to "good". If your language or system was good, it was then by definition object-oriented. Anything good had therefore to be called OO. Saying something was not actually OO (e.g. this) was taken to mean it was not good, generating spurious conflict.

Excellent point, and I think in our contemporary age something similar is happening with "Agile". It has ceased to become a project management technique useful for a certain class of products. It has instead become redefined to mean "good" - for example, in popular imagination, if a team is not "Agile" then they are somehow backwards or out-of-the-loop. Now teams, products, and situations where Agile is not appropriate are finding themselves having it forced upon them, or spinning what they do as agile.

Re: Object-Oriented Programming in C (2019) [pdf]

#52

Post by cowanon22 »

The paper does not specify message passing or reflection, both of which are essential to OOP. I think OOP lost its way as soon as C++ reinterpreted it in terms of only encapsulation, inheritance, and polymorphism.

According to Alan Kay (one of the creators of Smalltalk, the first OOP), message passing is more important to OOP than inheritance. If you listen to his old speeches, what he is describing sounds a lot more like microservices and VMs/containers than what most of the later languages turned it into. (He describes objects as "mini computers" that interact with each other using only public interfaces)

Re: Object-Oriented Programming in C (2019) [pdf]

#53

Post by kitkat_new »

_old_dude_ wrote: post #45
pjmlp wrote: post #38

Earlier quoted context omitted.

https://microsoft.github.io/microsoft-ui-xaml > WinUI is powered by a highly optimized C++ core that delivers blistering performance, long battery life, and responsive interactivity that professional developers demand. Its lower system utilization allows it to run on a wider range of hardware, ensuring your sophisticated workloads run with ease. Apparently Microsoft does care about OOP in C++. As does Apple, https://…

OOP is great when you write APIs/libraries (your examples), but is useless or even counter productive when writing applications, where encapsulation or inheritance just obfuscate everything. My main grip with Java is that everything is by default a library. But there is hope, recent changes in Java, records and pattern matching move away from that idea.

saying OOP is only useless and counter productive is as short sighted as saying it is the golden hammer for everything.

PS: WinUI apps use plenty OOP

Re: Object-Oriented Programming in C (2019) [pdf]

#54

Post by heresie-dabord »

mst wrote: post #44
WalterBright wrote: post #35

Earlier quoted context omitted.

There is one advantage to doing OOP in C. Once you figure it out, the mystery of how OOP works all falls away. Frankly, I didn't understand how OOP worked before doing that. None of the tutorials explained what was going on under the hood. As an engineer, I'm never comfortable using something when I don't know how it works.

While it's hardly a complete object system, perl's bless() operator associating a package name with a data structure, where the package is (for bless()'s purposes at least) basically just a global hash mapping method names to subroutines, was pretty much how I first got my brain around the concept. I wish more "introduction to OO" things would start by demonstrating a dispatch table and then showing how the vtable co…

> it's hardly a complete object system

While other programming languages became mired in OOP dispute, opinion-battles, and all the ensuing problems[1], Perl 5's built-in OO is easy to learn and understand and makes the difficult things simple. It has been stable and effective for decades.

OO is just a pattern; it can be useful or misused, some aspects are more useful than others. But the defining goalposts are moved all the time. They tend to follow the hype machine.

[1] Members of the Perl community know that OO discussions have become harsh there too.

Re: Object-Oriented Programming in C (2019) [pdf]

#55

Post by _old_dude_ »

kitkat_new wrote: post #53
_old_dude_ wrote: post #45

Earlier quoted context omitted.

OOP is great when you write APIs/libraries (your examples), but is useless or even counter productive when writing applications, where encapsulation or inheritance just obfuscate everything. My main grip with Java is that everything is by default a library. But there is hope, recent changes in Java, records and pattern matching move away from that idea.

saying OOP is only useless and counter productive is as short sighted as saying it is the golden hammer for everything. PS: WinUI apps use plenty OOP

It's not what i've said, OOP is great for creating APIs like WinUI, not great for writing applications

Re: Object-Oriented Programming in C (2019) [pdf]

#56

Post by ctrlp »

vbtemp wrote: post #51
ncmncm wrote: post #21

Back in the '90s, "Object-Oriented" got redefined in popular imagination to "good". If your language or system was good , it was then by definition object-oriented . Anything good had therefore to be called OO. Saying something was not actually OO (e.g. this) was taken to mean it was not good , generating spurious conflict. The fiction has largely dissipated, except among pundits and the aggressively ignorant. Meanwh…

> Back in the '90s, "Object-Oriented" got redefined in popular imagination to "good". If your language or system was good, it was then by definition object-oriented. Anything good had therefore to be called OO. Saying something was not actually OO (e.g. this) was taken to mean it was not good, generating spurious conflict. Excellent point, and I think in our contemporary age something similar is happening with "Agile…

Agile has meant 'bad' for years now ever since Agile processes were formalized and adopted by big orgs. At least that's how I've thought of it: 'Agile' means the worst of all worlds. Run if you can.

Re: Object-Oriented Programming in C (2019) [pdf]

#57

Post by vbtemp »

ctrlp wrote: post #56
vbtemp wrote: post #51

Earlier quoted context omitted.

> Back in the '90s, "Object-Oriented" got redefined in popular imagination to "good". If your language or system was good, it was then by definition object-oriented. Anything good had therefore to be called OO. Saying something was not actually OO (e.g. this) was taken to mean it was not good, generating spurious conflict. Excellent point, and I think in our contemporary age something similar is happening with "Agile…

Agile has meant 'bad' for years now ever since Agile processes were formalized and adopted by big orgs. At least that's how I've thought of it: 'Agile' means the worst of all worlds. Run if you can.

Well it's become the exact corporate management hell that the original manifesto authors sought to fight back against. I personally avoid joining teams or companies that drank the kool-aid, and additionally find agile to be a particularly counter-productive way to deliver value to customers quickly. About 7 years or so ago I had the first inkling things were wrong when "Agile Coaches" appeared who were not developers.

It does, at least, facilitate micro management and burnout.

Re: Object-Oriented Programming in C (2019) [pdf]

#58

Post by ByteJockey »

ctrlp wrote: post #56
vbtemp wrote: post #51

Earlier quoted context omitted.

> Back in the '90s, "Object-Oriented" got redefined in popular imagination to "good". If your language or system was good, it was then by definition object-oriented. Anything good had therefore to be called OO. Saying something was not actually OO (e.g. this) was taken to mean it was not good, generating spurious conflict. Excellent point, and I think in our contemporary age something similar is happening with "Agile…

Agile has meant 'bad' for years now ever since Agile processes were formalized and adopted by big orgs. At least that's how I've thought of it: 'Agile' means the worst of all worlds. Run if you can.

The rule of thumb I've noticed.

If they use "agile" as a noun, they generally have no idea what they're talking about and you should be careful.

Re: Object-Oriented Programming in C (2019) [pdf]

#59

Post by ByteJockey »

ncmncm wrote: post #27
enduku wrote: post #7

1. Creating a struct with desired state data 2. Creating functions that take a pointer to the struct as the first parameter 3. Declaring a variable with that struct type to create an instance of the object 4. Declaring another variable with that struct type for another object instance

... is not, in fact, OO at all, by any meaningful definition. 1..4 is just programming. People have done it since long before there was any "OO" buzzword. There are formal definitions of OO. The above satisfy exactly none of them.

There's usually a formal definition of something and a common definition of something, and most languages that get traction follow the common definition.

For example, the formal definition of the Liskov Substitution Principal:

> Let ϕ(x) be a property provable about objects x of type T. Then ϕ(y) should be true for objects y of type S where S is a subtype of T.

This doesn't allow any change in behavior when subclassing. Not even the addition of logging, which makes the overriding of methods generally useless. Yet languages still provide this feature (perhaps to their detriment, but they still do).

There's also a common definition of the Liskov Substitution Principal:

> Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.

This is, generally speaking, what people are talking about when the mention the Liskov Substitution Principal, unless they're actively writing an academic paper on the topic.

Bringing up the academic definition when someone is using the common definition is 1. not relevant and 2. usually not helpful.

Re: Object-Oriented Programming in C (2019) [pdf]

#60

Post by zozbot234 »

ByteJockey wrote: post #59
ncmncm wrote: post #27

Earlier quoted context omitted.

... is not, in fact, OO at all, by any meaningful definition. 1..4 is just programming. People have done it since long before there was any "OO" buzzword. There are formal definitions of OO. The above satisfy exactly none of them.

There's usually a formal definition of something and a common definition of something, and most languages that get traction follow the common definition. For example, the formal definition of the Liskov Substitution Principal: > Let ϕ(x) be a property provable about objects x of type T. Then ϕ(y) should be true for objects y of type S where S is a subtype of T. This doesn't allow any change in behavior when subclassi…

> This doesn't allow any change in behavior when subclassing.

Generally correct, but that's why you should only be "subclassing" abstract interfaces in the first place. Subclassing concrete object methods is a footgun, precisely because you have no way of enforcing which of these "properties" any code will actually be relying on, either at any given point in time or in the future. (Including code that's itself part of the base objects hierarchy and calling possibly-overridden methods, which means subclassing also breaks encapsulation!)

Concrete inheritance is very hard to make sense of semantically in the fully general case; if it's viable at all it is as a kind of mere specialization, and that's what the LSP is trying to get at.

Post reply on HN