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

Instance Model Programming in C

slkpg.byethost7.com

Post reply on HN
Print view View original

11–20 of 22 posts

Re: Instance Model Programming in C

#11

Post by skrebbel »

Drifting from the topic, but I never understood this urgent need for so much inheritance when doing OO, especially when using languages that don't natively have it, like C and JavaScript.

I really like OO programming (i.e. I'm particularly not one of the functional-fundamentalist OO-haters here on HN), but as I've grown more experienced, I've started to use inheritance less and less, and composition more and more. This is trivially supported in C structs, and you don't need any fancy approach for it, plus you can do with way less void pointer casting, which means less runtime errors.

Inheritance is very useful for a small set of relatively complex problems, such as language parsing or UI frameworks or particle simulations. For many other problems, including most applications (as opposed to libraries), however, my experience is that you can do fine without. This holds especially these days, when many of said complex problems are solved in excellent freely available open source projects, in nearly any language.

Re: Instance Model Programming in C

#12

Post by 616c »

skrebbel wrote: post #11

Drifting from the topic, but I never understood this urgent need for so much inheritance when doing OO, especially when using languages that don't natively have it, like C and JavaScript. I really like OO programming (i.e. I'm particularly not one of the functional-fundamentalist OO-haters here on HN), but as I've grown more experienced, I've started to use inheritance less and less, and composition more and more. Th…

That is funny because my limited experience with Python, on-off over the years, it was impressed upon me many, many times composition is superior to inheritance, and the language even has both built-in.

And yes, for all the pointy-hairs around, I know there are exceptions to the rule. I am speaking generally.

Re: Instance Model Programming in C

#13

Post by pjmlp »

twoodfin wrote: post #8

Much of C++ made more sense to me when I read Inside the C++ Object Model by Stanley Lippman[1]. It helped me internalize the fact that C++ was originally implemented as a preprocessor transformation into C (Stroustrup's Cfront). Thus many C++ mechanisms can be understood as elaborate syntactic sugar. [1] http://www.amazon.com/Inside-Object-Model-Stanley-Lippman/dp...

Another good read are The Annotated C++ Reference Manual[1] and The Design and Evolution of C++[1].

They help understand all design compromises that were done to keep compatibility with C, which is was part of what brought C++ into the mainstream, but also the main cause of many of its warts.

[1] http://www.amazon.com/The-Annotated-C-Reference-Manual/dp/02...

[2] http://www.amazon.com/The-Design-Evolution-Bjarne-Stroustrup...

Re: Instance Model Programming in C

#14

Post by aninteger »

gfalcao wrote: post #10

This is pretty awesome. GNOME itself is all written in pure C using glib, which also contains GObject, a beautiful OOP approach for the C programming language. It has a dynamic type system, supports meta programming... Very few people know it, but GNOME's GTK interface is fully object oriented, and BTW when you click a GTK button you are clicking on an instance of the class GtkButton that inherits from GtkBin which i…

GTK is often used as the example of what not to do when designing interfaces. A better pure C example would be Wine's implementation of the Win32 API (specifically take a look at user32.dll). Or the Tk toolkit.

Re: Instance Model Programming in C

#15

Post by Someone »

skrebbel wrote: post #11

Drifting from the topic, but I never understood this urgent need for so much inheritance when doing OO, especially when using languages that don't natively have it, like C and JavaScript. I really like OO programming (i.e. I'm particularly not one of the functional-fundamentalist OO-haters here on HN), but as I've grown more experienced, I've started to use inheritance less and less, and composition more and more. Th…

That is far from an uncommon idea. The phrase to search for to learn more about this is "Composition over Inheritance". That leads you to e.g. http://en.wikipedia.org/wiki/Composition_over_inheritance or, combined with "site: c2.com" to http://c2.com/cgi/wiki?CompositionInsteadOfInheritance or http://c2.com/cgi/wiki?UseCompositionAndInterfacesWithoutCla....

In some sense, deep inheritance hierarchies were a thing of the 80's, when inheritance was new (at least, in the mainstream), just like the tag was a thing of the '90s (or was that the 00's?). Now, deep hierarchies are a code smell.

Re: Instance Model Programming in C

#16

Post by camus2 »

skrebbel wrote: post #11

Drifting from the topic, but I never understood this urgent need for so much inheritance when doing OO, especially when using languages that don't natively have it, like C and JavaScript. I really like OO programming (i.e. I'm particularly not one of the functional-fundamentalist OO-haters here on HN), but as I've grown more experienced, I've started to use inheritance less and less, and composition more and more. Th…

Javascript supports prototypal inheritance natively and it works well. The problem is people trying to fit every java oo concept in js, ending up writing unreadable mess.

Re: Instance Model Programming in C

#17

Post by gfalcao »

aninteger wrote: post #14
gfalcao wrote: post #10

This is pretty awesome. GNOME itself is all written in pure C using glib, which also contains GObject, a beautiful OOP approach for the C programming language. It has a dynamic type system, supports meta programming... Very few people know it, but GNOME's GTK interface is fully object oriented, and BTW when you click a GTK button you are clicking on an instance of the class GtkButton that inherits from GtkBin which i…

GTK is often used as the example of what not to do when designing interfaces. A better pure C example would be Wine's implementation of the Win32 API (specifically take a look at user32.dll). Or the Tk toolkit.

I disagree that GTK is an example of what NOT to do when designing interfaces. But anyways I just mentioned GTK as an example of GObject usage, which was my original point.

GObject is independent of GTK.

Also here is the link for the introspection tool that generates bindings to other languages: https://wiki.gnome.org/action/show/Projects/GObjectIntrospec...

Re: Instance Model Programming in C

#18

Post by discreteevent »

skrebbel wrote: post #11

Drifting from the topic, but I never understood this urgent need for so much inheritance when doing OO, especially when using languages that don't natively have it, like C and JavaScript. I really like OO programming (i.e. I'm particularly not one of the functional-fundamentalist OO-haters here on HN), but as I've grown more experienced, I've started to use inheritance less and less, and composition more and more. Th…

I agree and I think that this is what Go gets right. The thing that's valuable about objects are the interfaces (Alan Kay said it was the messages). Microsoft's COM is similar in this regard.

Re: Instance Model Programming in C

#19

Post by brandonbloom »

humanrebar wrote: post #5

> Except in a database, the data in most programs is a minor player. I guess that depends on what your definition of "most" is. A large portion of C code either depends on hardware interfaces or is intended to be optimized. In both cases, the layout of your memory (data) is extremely important to an implementation. One of the biggest criticisms of OOP is that it tends to obscure data layout, which isn't always an imp…

Also from that same paragraph:

> The design and implementation of algorithms constitutes the vast bulk and difficulty in developing software.

That's just a crazy statement to me. In my experience, the bulk of developing software is anything but the design and implementation of algorithms. And I've worked on some pretty algorithm-heavy projects!

I don't even know where to start rebuking the rest of this article's discussion of data and I suspect that the author and I simply have dramatically different definitions of the word.

Regarding your comment:

> One of the biggest criticisms of OOP is that it tends to obscure data layout, which isn't always an implementation detail.

I'd argue that OOP obscures data representations more broadly than just data layout. Encapsulation is great, but it's simply the wrong default: Representations and the scope of their exposure should be carefully considered. Further, immutability greatly reduces the value of encapsulation.

Re: Instance Model Programming in C

#20

Post by signa11 »

pjmlp wrote: post #13
twoodfin wrote: post #8

Much of C++ made more sense to me when I read Inside the C++ Object Model by Stanley Lippman[1]. It helped me internalize the fact that C++ was originally implemented as a preprocessor transformation into C (Stroustrup's Cfront). Thus many C++ mechanisms can be understood as elaborate syntactic sugar. [1] http://www.amazon.com/Inside-Object-Model-Stanley-Lippman/dp...

Another good read are The Annotated C++ Reference Manual [1] and The Design and Evolution of C++ [1]. They help understand all design compromises that were done to keep compatibility with C, which is was part of what brought C++ into the mainstream, but also the main cause of many of its warts. [1] http://www.amazon.com/The-Annotated-C-Reference-Manual/dp/02... [2] http://www.amazon.com/The-Design-Evolution-Bjarne-St…

> Another good read are The Annotated C++ Reference Manual[1] and The Design and Evolution of C++[1].

Annotated C++ Reference Manual as well as D&E is severely dated. Quite a while back there was some talk of stroustrup co-authoring a revision of the reference-manual with andrew-koenig, but it never came to fruition...

Post reply on HN