Is C good enough - or can the world survive w/o OOP

[Beej Jorgensen]

most of what I saw in, and still do see in, OOP, was the creation of
large convoluted class heirarchies, lots of classes digging deep into
the internals of other classes, ...

This seems like design and programming mistakes, though. And these
issues can absolutely crop up in "objected-oriented" C, of course.

it doesn't help much that, in the Java style of OOP, it is common for
people to use lots of "static public" variables in classes.

And I'd take issue with "the Java style of OOP", here. I don't think
abusing static public is an officially condoned style by the Java
Powers-That-Be. It certainly doesn't have to be that way to write
applications in Java.

I mean, languages can have genuine faults and programming paradigms can
have weak applications, but blaming them for programmer mistakes isn't
really fair. And if it were fair, I doubt C would be the one left
smelling like roses!

-Beej

 

[BGB / cr88192]

This seems like design and programming mistakes, though. And these
issues can absolutely crop up in "objected-oriented" C, of course.

granted, but they are less likely.

in C, we would call the equivalent of this "crap code", whereas, from what I
remember, in late 90s Java books, a lot of stuff like this was promoted.

And I'd take issue with "the Java style of OOP", here. I don't think
abusing static public is an officially condoned style by the Java
Powers-That-Be. It certainly doesn't have to be that way to write
applications in Java.

I mean, languages can have genuine faults and programming paradigms can
have weak applications, but blaming them for programmer mistakes isn't
really fair. And if it were fair, I doubt C would be the one left
smelling like roses!

ok, programmer issue or not, it may still be the case in many cases.

in C, we see it as bad style, and elsewhere, people can hide between the
magic word "OOP" and think all is well, even if their code is, itself, not
particularly OO as such...


so, in reality here, I am neither taking issue with Java or OO, rather, the
people who don't really know either very well but still hold a sense of
superiority due to their particular language choice (which, from what I have
seen, would seem to be fairly common in both Java and C++ land...).

 

[BGB / cr88192]

C can do what C does.

etc..

[snip the good stuff]

Thanks for the insight! So what would be *your* recommendation as the
quintessential OOP language?

this is a hard one...

I would probably recommend looking at a number of different languages:
C, C++, Java, C#, JavaScript, SmallTalk, Self, ... and maybe get an idea of
the generalities (and possibilities).

as well, it is helpful to at least gloss over very different programming
styles: Scheme & Lisp, PostScript, ...

books can be helpful, but some I would be less sure of. if the book seems
overly evangelistic and the advice sounds suspect, caution is advised ("best
thing since sliced bread" != "solid coding advice").


ultimately though, one may not necessarily choose a language because it is
"best" (if one were to find such a language that is), but more because it
best meets ones' particular needs.


for example, I mostly use C, but I don't claim it is a perfect language by
any means.
another may choose C++, Java, or C#, finding it better fits their needs.

but, ok, this is not a great answer...

 

[Tom St Denis]

You can do anything with C (as well as in asm), but that is not
practical nowadays unless the problem is somewhat trivial. OOP brings
maintainability, readability and also productivity.

If you equate C with asm in your head you're doing C wrong.

To me, most OO languages are more understandable than C or PHP. I just
can't understand most/those script languages. I prefer strong typing and
a compiler warning about errors before they happen.

You're looking at [or writing] bad C code.

OO languages bind together 'things' (objects) and possible actions upon
them. The connection is easily understood by reading the code.

In any decent API this is also accomplished with proper function
naming, feature abstraction, and functional refactoring. It's just as
possible to write a horrible API in C++ as C.

When you see a 'struct' in C language, you see the 'thing', but you have
no idea what can be done with it.

So? And when you see a class has a "put" method that doesn't mean you
know what it does with the data you pass it. Big deal.

Usually when examining an API you look at the functions, not the
structures. Structures are just a tool to organize data, functions
are where the action is.

Tom

 

[Tom St Denis]

Not really. You can indeed do that and get remarkably similar ASM output
from the compiler if you know what you're doing.

If you equate C with asm in your head you're doing C wrong.

Worth saying once, worth saying twice.

More so. We are in agreement. Operator overloading, multiple inheritance
all combine to make reading OO code from printout almost impossible IMO.

Name your methods better, inherit from classes that make sense, etc.
There is nothing wrong with what C++ provides. The fact you're
missing from the argument is the vast majority of software developers
out there are trained [if that] as programmers not developers. There
is a difference.

Think of building architect versus hammer wielding day labourer. The
day labourer still has a skill (welding for instance is not easy) but
you wouldn't ask them to design the building.

Similarly, many "developers" are just programmers who know the syntax
of their language of choice, but aren't really qualified to lay out an
API or make structural design decisions on a project scale. As a
result they plow through the work best they know how and "fix things"
as they go along. Result: Shit code that looks like it was patched
together.

Like I said previously, if you started from scratch your C++ and C
solutions to the same problem might look vastly different. People
compare the two with the after product. E.g. "my C++ solution
wouldn't map well to C, clearly C++ is superior" and vice versa. I
personally don't code in C++ since I find C works for what I want to
do (and I express myself better in terms of the C language than OOP
like C++). But that doesn't mean I think C++ is inferior to C.

So to answer the OPs question again, I think the world can survive
without OOP just fine. Most code that runs the world is ASM or C
anyways. But that doesn't mean OOP (Java, C++, perl6, etc...) are
worthless. If you know how to use them, and use them well, they're
just as legitimate as C is.

Tom

 

[Donkey Hottie]

To me, most OO languages are more understandable than C or PHP. I just
can't understand most/those script languages. I prefer strong typing and
a compiler warning about errors before they happen.

You're looking at [or writing] bad C code.

LOL actually I meant to write "perl or PHP", that was a disgust on
script languages.

I have nothing against C, I started by career with, wrote two years,
until Borland and MS got their C++ versions out sometimes '92 or so.

When I saw C++, I immediately starter my own class library and went with
OO. That class library was very Java style and I worked with it some 10
years, until I went Java (EE).

More so. We are in agreement. Operator overloading, multiple inheritance
all combine to make reading OO code from printout almost impossible IMO.

Modern OO languages like Java or C# do not have those imbecile features.


--
http://www.iki.fi/jarif/

Q: "What is the burning question on the mind of every dyslexic
existentialist?"
A: "Is there a dog?"

 

[Tom St Denis]

Wrong. In many cases C is used to do just that because of the nature of
the language. And my C is pretty handy. How do I know this? Because I
have done projects where asm was moved into C with a strong look at the
compiled ASM output in order to maintain driver efficiency. Sure not
totally portable etc but your claims are plain wrong.

Profile <=> optimize, it's called a feedback cycle dude. Sure there
will be small segments of code that need to be scrutinized for
performance (which may include looking at the asm that the compiler
generates) but overall, people should choose efficient algorithms and
let the compiler worry about how to express that in machine code.

Yes, but you're wrong. Thats twice you've had to be told. Same as you
were wrong about macros and inlines.

No, I still think one-liners should be macros, that there are naming
conventions, that code doesn't go in headers, I just let the issue
drop because I'm not an anti-social loser like you are. Some things
are just not worth arguing over. Let it go.

<snip>

Tom

 

[Duke Normandin]

[snip ]

Name your methods better, inherit from classes that make sense, etc.
There is nothing wrong with what C++ provides. The fact you're
missing from the argument is the vast majority of software developers
out there are trained [if that] as programmers not developers. There
is a difference.

Think of building architect versus hammer wielding day labourer. The
day labourer still has a skill (welding for instance is not easy) but
you wouldn't ask them to design the building.

Similarly, many "developers" are just programmers who know the syntax
of their language of choice, but aren't really qualified to lay out an
API or make structural design decisions on a project scale. As a
result they plow through the work best they know how and "fix things"
as they go along. Result: Shit code that looks like it was patched
together.

Your point-of-view makes sense to me. A tool-and-die maker was once a humble
machinist, e.g. A person may be a hot-shot machinist, but never have the
inclination or wherewithal to "graduate" to the level of tool-and-die
maker. Similarly, a cat operator building a highway, *is not* a civil engineer
laying out same. I get it!

Applying this to myself (and I'm not a professional programmer), I find my
biggest stumbling blocks are designing / crafting / sculpturing the program
I'm working on, and not the actual coding. Sure, I still get acid
indigestion with pointers to structs that contain arrays. However,
by-and-large I go round-n-round, chasing my friggin tail, when I'm trying to
*design* the bloody thing.

[snip ]

So to answer the OPs question again, I think the world can survive
without OOP just fine. Most code that runs the world is ASM or C
anyways. But that doesn't mean OOP (Java, C++, perl6, etc...) are
worthless. If you know how to use them, and use them well, they're
just as legitimate as C is.

Tom

I was thinking of that very thing last night! What language is C++ written
in? Java? Objective-C? Smalltalk? Isn't C the common denominator here; and
maybe some asm for speed? At any rate, I'm forging ahead with C, but I've
installed Squeak on my system. What the hell, you only live once..

 

[Keith Thompson]

I was thinking of that very thing last night! What language is C++ written
in? Java? Objective-C? Smalltalk?

I think the specifications for all those languages are written in
English.

Isn't C the common denominator here; and
maybe some asm for speed? At any rate, I'm forging ahead with C, but I've
installed Squeak on my system. What the hell, you only live once..

Yes, many *implementations* for those languages are written in C,
though I can't speak for all of them. But I certainly wouldn't be
surprised if some C++ compilers, for example, were written in C++.

 

[Nobody]

history is in line here:
first, there was Simula.

then, C++ borrowed from Simula,

Between those two steps was Smalltalk. Although C++ mostly ignored it,
Smalltalk was largely responsible for popularising the concept of OOP.

Objective-C (which takes a more Smalltalk-like approach to OOP than C++)
is the preferred language for MacOSX GUI development (and before that,
NeXTStep).

 

[Nobody]

When you see "foo" in OO:

o is this the base class "foo"?
o is it instance->foo()?
o is it a freidn's class foo()?

Then you discover that you have no idea which foo is being called. See
above.

If you actually need to know, either the design is flawed or OOP isn't the
right paradigm.

OOP is primarily an abstraction mechanism. If you want to foo an object,
you call object.foo(). As for what happens from there on ... you have no
need to know.

 

[BGB / cr88192]

I think the specifications for all those languages are written in
English.


Yes, many *implementations* for those languages are written in C,
though I can't speak for all of them. But I certainly wouldn't be
surprised if some C++ compilers, for example, were written in C++.

GCC compiles C++ and was written in C.
LLVM+CLang compiles C and was written in C++...


in GCC, the C++ runtime is written in mixed C and C++, and FWIW in my
attempts to compile GCC from sources, this was one of those parts I just
couldn't get to rebuild.

hell, maybe C++'s syntax and semantics are so unstable that GCC's C++
runtime can't even be built with GCC...

then again, I guess it can be noted that, just as the C runtime tends to be
nastier than most C code, the C++ runrime is nastier than most C++ code.

std::hell...

 

[Nobody]

And for the record, you can do a lot of OOP like things (like anonymous
interfaces) through pointers to functions and structures. A lot of the
higher level ideas like inheritance, friends, derived objects are less
straightforward but honestly, I have yet to see a case where they actually
are "required" to proficiently solve a problem.

Inheritance isn't exactly a higher-level idea. If you don't use
inheritance (at least inheriting the interface, if not any
implementations), there probably isn't much point in using OOP.

It's certainly easy enough to implement in C: the class and instance
structures for a derived class begin with the corresponding structure
for the base class. At least two C GUI libraries (Xt and GTK+) are
implemented this way.

Friend classes just provide an opt-out from private/protected members,
eliminating the need to make a member public for a small number of special
cases.

Probably the most significant feature of C++ which can't easily be
emulated in C is destructors, which are central to the RAII (resource
acquisition is initialisation) paradigm. This dramatically simplifies
clean-up on premature exits, particularly exceptions. It's easy enough
to emulate exceptions themselves with setjmp/longjmp; what you can't do
easily is arrange for code to be executed when leaving a variable's
scope via an exception.

 

[Default User]

To me, most OO languages are more understandable than C or PHP. I
just can't understand most/those script languages.

Ummm, PHP supports OOP.



Brian

 

[BGB / cr88192]

Between those two steps was Smalltalk. Although C++ mostly ignored it,
Smalltalk was largely responsible for popularising the concept of OOP.

yes, but I didn't include Smalltalk here because, as I see it, ST
represented a different branch of OO development which was unrelated to the
development of C++.

AFAIK, Stroustrup had based C++ on Simula, and so I said as I did.

to have mentioned ST at this point would have confused matters, as ST in
many ways goes in a different direction from C++.


it would have been like claiming Self was the predecessor to Java.
sure, both projects were developed at Sun, and Self did precede Java, but
Self and Java have almost nothing in common...

hence, the issue...

Objective-C (which takes a more Smalltalk-like approach to OOP than C++)
is the preferred language for MacOSX GUI development (and before that,
NeXTStep).

yep.

of course, Obj-C was not the exact topic.

part of the downside I think with Obj-C is the syntax:
bolting ST-style syntax onto C is not pretty.

 

[BGB / cr88192]

If you actually need to know, either the design is flawed or OOP isn't the
right paradigm.

OOP is primarily an abstraction mechanism. If you want to foo an object,
you call object.foo(). As for what happens from there on ... you have no
need to know.

in concept, yes.


in practice, it is more something for many Java and C++ programmers to
obsess over and use to belittle anyone who doesn't use their preffered
language of choice. more so, it is not so much about abstraction as it is
about throwing terms around and using a particular coding style (common Java
and C++ style coding practices).

so, in concept, OOP is more about using some sort of "objects", and
abstracting an interface from its implementation.

in practice, it is more about putting everything in classes (even if they
are just being used as shared globals), making fancy inheritence trees, and
demanding that everyone put only a single class per file (granted, this is
more the case in C++ land, since in Java these are justified on account of
being imposed by the compiler...).

this is mostly why I dislike "OOP", but this does not mean that I dislike OO
by any means, more the common sets of dogmas, abuse, and percieved sense of
superiority which revolves around it.


it is much like how, traditionally, European culture has abused the name of
Christianity, using this as a grand title for themselves while meanwhile
being bastards to whatever peoples they came across (nevermind whether ot
not their actions had anything to do with what was actually taught in the
Bible...).


so, now there is a new religion, where they bow to OOP in the religion of
Java'ism...
not that Java is inherently bad either, only that enshrining it is not quite
the right idea...

one needs to be careful to know the true programmer from the Javaist, lest
they come and make a horrible mess of ones' code all in the name of "OOP"...

maybe, it all looks so nice in the beginning, as their C++ codebase is
organized all nicely according to some neat little heirarchy with every
class individually wrapped in its own file, but this may be indeed only the
start of the terror...


or such...

 

[Stefan Ram]

so, in concept, OOP is more about using some sort of "objects", and
abstracting an interface from its implementation.

The term »object-oriented programming« was coined by Alan Kay.

In 2003, I became aware that no one knew how he defined it.
I have asked him about this, and his reply is given in:

http://www.purl.org/stefan_ram/pub/doc_kay_oop_en

 

[Noob]

To me, most OO languages are more understandable than C or PHP. I just
can't understand most/those script languages. I prefer strong typing and
a compiler warning about errors before they happen.

Relying too much on strong typing may damage your keyboard.

 

[Nick Keighley]

yep, too many people learned "OOP" from Java books...

this whole early Java experience had made me despise OOP for years, until
much later that I realized I had already been using OO, just in a very
different way...

for example, some of my early code had, actually, made use of a lot of
structs full of function pointers to allow allow plugging the same front-end
interface into different backends.

I had ideas like, say, carving up code into anonymous pieces with the policy
of not having one piece of code dig around in the other code's internals,
...

similarly, another language I had been using some at the time had a
semi-prototype approach to OO (it was sort of like, but not quite, P-OO,
differing mostly in that it lacked delegation, and in that there was only a
single object type where each object contained the union of all possible
fields, and so creating a field would silently add it to EVERY object...).

most of what I saw in, and still do see in, OOP, was the creation of large
convoluted class heirarchies, lots of classes digging deep into the
internals of other classes, ...

it doesn't help much that, in the Java style of OOP, it is common for people
to use lots of "static public" variables in classes.

now, what does this amount to?
oh, right, a shared global...

there was once something I remembered reading which was touting as a great
merit of OOP, that everything could inherit from everything else (and that
there was this amazing Object class from which all others were derived).

the cost:
what if, say, someone should ever want to, say, reorganize the code?...
well, then they risk shattering the precious class heirarchy.

can't have that, now can we?...

one may even go so far as to find, hell, I don't know, relationships which
are not heirarchies...

"Design patterns : elements of reusable object-oriented software"

Gamma et al

 

[Nick Keighley]

Can you give an example of something for which OOP is a very poor
model?

big mathematical calculations?
reusable containers?
symbolic computation?
databases?