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

D

dukeofperl

I'm learning C (after having taught myself Perl, Tcl, Bash etc). For me, OOP (i.e. C++, Objective-C, etc) is mind-bogling information overload. Seriously, does programming *need* to be as convoluted as OOP appears to me? Cannot C - all by its lonesome - do as good of a job as an OOP appraoch?

I'm just trying to set a course for myself. I realize that "languages" are simply tools in my toolset. However, some toos are simply way over the top, IMHO, for most jobs. Is that not so? TIA...
 
T

Tom St Denis

I'm learning C (after having taught myself Perl, Tcl, Bash etc). For me, OOP (i.e. C++, Objective-C, etc) is mind-bogling information overload. Seriously, does programming *need* to be as convoluted as OOP appears to me? Cannot C - all by its lonesome - do as good of a job as an OOP appraoch?

I'm just trying to set a course for myself. I realize that "languages" are simply tools in my toolset. However, some toos are simply way over the top, IMHO, for most jobs. Is that not so? TIA...

Think of languages as tools not quests. Learn C if it offers you what
you need to solve your problems, not because it sounds catchy and good
on a C.V.

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.

I think the problem is people look at things from the finished product
side and say "if I had to port this to C [or vice versa] it'd be a
mess," and then use that as a reason to prefer their language of
choice, when in reality if you started from scratch in the other
language your solution would take a vastly different course.

Tom
 
D

Donkey Hottie

I'm learning C (after having taught myself Perl, Tcl, Bash etc). For me, OOP (i.e. C++, Objective-C, etc) is mind-bogling information overload. Seriously, does programming *need* to be as convoluted as OOP appears to me? Cannot C - all by its lonesome - do as good of a job as an OOP appraoch?

I'm just trying to set a course for myself. I realize that "languages" are simply tools in my toolset. However, some toos are simply way over the top, IMHO, for most jobs. Is that not so? TIA...

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.

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.

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

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

Julienne Walker

Seriously, does programming *need* to be as convoluted as OOP appears to me?

More or less. Keep in mind that writing quality software is hard, and
keeps getting harder as software becomes more complex. Methodologies
like OOP were invented to help maintain quality as complexity grows.

I suspect your opinion is biased because you haven't seen OOP used
properly, or you don't have enough experience to see the benefits.
Despite what the books say, I think that OOP is not very intuitive,
and a *lot* of people abuse it unintentionally. In theory OOP is a
grand idea, but in practice I haven't seen many elegant uses of it at
all.
Cannot C - all by its lonesome - do as good of a job as an OOP appraoch?

Ignoring that many of the best practices for structured programming
run parallel to those of OOP, a well written C program is just as good
as a well written program in your OO language of choice. It's not so
much the tool that determines quality as it is the craftsman. There's
nothing inherent in C that makes it impossible to avoid losing quality
as the complexity grows, you just have to know what you're doing.
 
J

jacob navia

Donkey Hottie a écrit :
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.

Sure sure...
And it brings also a lot of unneeded baggage

The problem is that OO is OK when you have a problem that fits nicely within
the OO paradigm. When your problem does NOT fit within that, OO is an
obstacle.
To me, most OO languages are more understandable than C or PHP.

To you. You got used to OO. ANd I got used to the vi editor. And I
think it is more easy to use than emacs or others because...
well, because I am used to it.

I just
can't understand most/those script languages. I prefer strong typing and
a compiler warning about errors before they happen.

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

ALL the code. You have to know all the hierarchy and how this method fits
in that hierarchy, if its overloaded or not, etc. At the end you do not know
what are you calling unless you fire up the debugger.
When you see a 'struct' in C language, you see the 'thing', but you have
no idea what can be done with it.

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.

Good luck
 
D

Duke Normandin

On Dec 28, 10:27 am, (e-mail address removed) wrote:

Think of languages as tools not quests. Learn C if it offers you what
you need to solve your problems, not because it sounds catchy and good
on a C.V.

You bet! I said as much in my 2nd paragraph above ;)
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.

I don't know for sure (because I don't know OOP), but I sense that you're
correct in what you say. OOP is perhaps just another way of expressing a
solution to a problem - a way that makes sense to a subset of folks. Kinda
like using RPN calculators - makes damn good sense to a large subset, but is
a PITA to another subset.
 
D

Duke Normandin

Donkey Hottie a écrit :

Sure sure...
And it brings also a lot of unneeded baggage

The problem is that OO is OK when you have a problem that fits nicely within
the OO paradigm. When your problem does NOT fit within that, OO is an
obstacle.


To you. You got used to OO. ANd I got used to the vi editor. And I
think it is more easy to use than emacs or others because...
well, because I am used to it.



ALL the code. You have to know all the hierarchy and how this method fits
in that hierarchy, if its overloaded or not, etc. At the end you do not know
what are you calling unless you fire up the debugger.


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.

Good luck

I agree with everything you said, in the sense that my *gut feelings* tells
me it's so. OOP to means *looks* like a huge, convoluted, cluster-****; a
tangle of earthworms; a bloody mess. I don't grok it -- *but* I thought that
maybe I was giving up too quickly on perhaps a hell-of-a good tool. My guts
say "**** no!"; my head says "asks somebody who knows". ;)

For the time being, I'll learn C; then I'll give LISP (via newLisp) another
shot. ;)
 
D

Duke Normandin

More or less. Keep in mind that writing quality software is hard, and
keeps getting harder as software becomes more complex. Methodologies
like OOP were invented to help maintain quality as complexity grows.

I suspect your opinion is biased because you haven't seen OOP used
properly, or you don't have enough experience to see the benefits.
Despite what the books say, I think that OOP is not very intuitive,
and a *lot* of people abuse it unintentionally. In theory OOP is a
grand idea, but in practice I haven't seen many elegant uses of it at
all.

You're correct! I am biased because I've tried to learn OOP via Perl,
Javascript, and C++, and it always turns out to be a bunch of balck noise to
me - craptitude, really. *You* are correct in asserting that OOP is *not*
intuitive - as far as I'm concerned anyway. However, I thought that I would
ask in the event that my vision was blurred to a truely significant
programming gem.
Ignoring that many of the best practices for structured programming
run parallel to those of OOP, a well written C program is just as good
as a well written program in your OO language of choice. It's not so
much the tool that determines quality as it is the craftsman. There's
nothing inherent in C that makes it impossible to avoid losing quality
as the complexity grows, you just have to know what you're doing.

Too cool! Exactly what I wanted to hear! Now I can proceed with C, and
*know* that "I can do anything!". Like Crash - or was it Eddie - (the
opossoms!!) in the movie "Ice Age - Meltdown", when he "came to" after his
crash landing :)
 
S

Seebs

I'm learning C (after having taught myself Perl, Tcl, Bash etc).
For me, OOP (i.e. C++, Objective-C, etc) is mind-bogling information
overload. Seriously, does programming *need* to be as convoluted
as OOP appears to me? Cannot C - all by its lonesome - do as good
of a job as an OOP appraoch?

OOP is a very good model for some things, and a very poor model for
others.
I'm just trying to set a course for myself. I realize that
"languages" are simply tools in my toolset. However, some toos are
simply way over the top, IMHO, for most jobs. Is that not so? TIA...

I've done a lot of work for which OO programming is extremely useful
and expressive, although I don't care for C++. Still, OO languages
(I'm fond of Ruby) really are excellent for some kinds of work.

For others, I like C.

-s
 
K

Keith Thompson

Seebs said:
OOP is a very good model for some things, and a very poor model for
others.
[...]

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

Seebs

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

Depends on how "pure" the OOP is. But, for a concrete example: Consider
if you will the code which actually writes bits into status registers
and shoves data into buffers for a network card. I am pretty sure that
this is a very poor fit for most OOP models... Up to a point. You might
argue that the typical interface offered to these is a sort of primitive
OO model.

I think this is why hybridized languages like Objective-C and C++ are
finding a solid niche; it turns out that there's a lot of cases where you
want an object-like-model for interacting with something, but its internals
want to be bare metal or close to it.

Hmm. Okay, here's another example. The Unix 'tr' utility. I really don't
think that an OO model would make this simpler or easier to write. Basically,
small/simple stuff can be such that the OO model doesn't really pay off.
OO's at its best when it can model the problem space well; when the problem
space doesn't really need significant modeling, OO's generally a poor
fit.

-s
 
D

Duke Normandin

Seebs said:
OOP is a very good model for some things, and a very poor model for
others.
[...]

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

Let's not even go there, if you please! It never was my intention to start a
friggin flame war. I simply needed direction - I got it! Everything is
cool..

Once I find a language that appears to be the quintessence of OOP, I may
revisit the paradigm. However, my gut tells me that if I can manage to learn
C as well as a lot of you here on c.l.c, I should be able to make it
"dance".

Peace on earth, etc etc
 
K

Keith Thompson

Duke Normandin said:
Seebs said:
I'm learning C (after having taught myself Perl, Tcl, Bash etc).
For me, OOP (i.e. C++, Objective-C, etc) is mind-bogling information
overload. Seriously, does programming *need* to be as convoluted
as OOP appears to me? Cannot C - all by its lonesome - do as good
of a job as an OOP appraoch?

OOP is a very good model for some things, and a very poor model for
others.
[...]

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

Let's not even go there, if you please! It never was my intention to start a
friggin flame war.
[...]

Nor was I. We're just having a discussion here.
 
B

BGB / cr88192

I'm learning C (after having taught myself Perl, Tcl, Bash etc). For me,
OOP (i.e. C++, Objective-C, etc) is mind-bogling information overload.
Seriously, does programming *need* to be as convoluted as OOP appears to
me? Cannot C - all by its lonesome - do as good of a job as an OOP
appraoch?

I'm just trying to set a course for myself. I realize that "languages" are
simply tools in my toolset.
However, some toos are simply way over the top, IMHO, for most jobs. Is
that not so? TIA...

C can do what C does.

what C++ adds is largely syntax, and little stops similar from being done in
C (although, it is rather unlikely that anyone would write C in quite the
same way as C++, and most C++ / Java / ... devs' likely can't imagine doing
anything any differently...).


IMO, OOP, as we know it, is a little bit of a fluke.
it is not really necessary to perform tasks, or even to perform tasks well.
it was a language feature, and so many others turned it into a panacea.


nor is it even really the "best" way to do OO, IMO (personally, I regard
Prototype-OO is a model that is simpler, cleaner, and more powerful, but C/I
OO does have a few merits).

"OOP" / C/I OO basically tends to tie up a lot of the problem in meta-issues
(where the abstract model is not clearly separated from implementation
issues and performance concerns, and sadly it seems many who use it fail to
note the difference).


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

then, C++ borrowed from Simula, not strictly faithfully, but it was merged
with a C core and made really fast. this resulted in early C++ and OOP,
which was more the version I had "originally" learned, although eventually I
ended up mostly with plain C (I suspect this was due, in part, to most of
the code I had encountered and worked with having been in C).

in these early days, from what I remember, C++ had classes, ... but, for the
most part, stylistically it was something most C programmers would
recognize...

then Java came along, and was another big promoter of OOP, but their OOP was
"different" in many ways from the early C++ style. the object model was a
little different, and the language imposed many stylistic concerns directly
into the language design.

subsequently, this style merged back into C++ land, and now we have lots of
C++ code that looks and is organized (almost) just like Java code (and I
can't say I am exactly pleased with this style).

this is now what is generally called "OOP"...


elsewhere, there was SmallTalk, and then later Self, which developed a very
different "OO".

the style from Self (Prototype OO) was then later adapted, although once
again hardly faithfully, into JavaScript and later ActionScript.

and, many people encounter these languages, and have no idea what the hell
is going on... (and many will refuse to acknowledge that they are even
"OO").

I guess in many peoples' minds, OO revolves around the "class", and the
elaborate taxonomies and inheritence trees, and without these they are
lost...


granted, P-OO (as it exists in Self or JS) is not perfectly adapted to
C-family statically typed languages, and so a few adjustments are needed.

one such adjustment in my early considerations had been adding interfaces,
which had then become, among other things, the almost central structure
(objects were essentially amorphous and defined primarily in terms of their
interfaces).

although, at the time, this was actually a design more resulting from
consideration as to how to make P-OO objects accessible from Java (in a
custom VM framework where the underlying OO facilities can handle both
models).

(actually, I made a C/I implementation and hacked P-OO onto it, although
maybe it would have been better to have implemented efficient P-OO and
implemented C/I on top, as this would likely have allowed a cleaner
implementation without much performance impact, but oh well...).

 
J

Julienne Walker

And failed miserably in the majority of cases. At least in the early
adopters.

I'd be suspicious if any new methodology didn't have growing pains.
Our field is especially ripe with good ideas that don't work well
except on a whiteboard, and the only way to find that out is to put
them in practice and fail miserably.
 
B

BGB / cr88192

Richard said:
OO is misued time and time again. It is rare to find an efficient OO
framework which works AND is maintainable.

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...

 
B

BGB / cr88192

Duke Normandin said:
Seebs said:
I'm learning C (after having taught myself Perl, Tcl, Bash etc).
For me, OOP (i.e. C++, Objective-C, etc) is mind-bogling information
overload. Seriously, does programming *need* to be as convoluted
as OOP appears to me? Cannot C - all by its lonesome - do as good
of a job as an OOP appraoch?

OOP is a very good model for some things, and a very poor model for
others.
[...]

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

Let's not even go there, if you please! It never was my intention to start
a
friggin flame war. I simply needed direction - I got it! Everything is
cool..

Once I find a language that appears to be the quintessence of OOP, I may
revisit the paradigm. However, my gut tells me that if I can manage to
learn
C as well as a lot of you here on c.l.c, I should be able to make it
"dance".

shouldn't be a problem here, since this group is about C, and hence not
nearly so likely to be filled with hoards of mindless OO zombies...

it would be like, say, a bunch of raging liberals hanging around in the
midwest with people from the southern baptist convention...
 
B

Beej Jorgensen

I agree with everything you said, in the sense that my *gut feelings*
tells me it's so. OOP to means *looks* like a huge, convoluted,
cluster-****; a tangle of earthworms; a bloody mess. I don't grok it
--

Do you have things that do stuff? Then maybe OOP can help. The things
are your objects, and the stuff is their methods. I'd probably
recommend Java for learning OOP--I think it might have the fewest
distractions and might be most similar to what you've already done.

C can do it, but it's not exactly the cleanest syntax when you start
getting past the OOP basics. (Not that you can't go far with the
basics.)

"Use the right tool for the job" applies here. The Inform programming
language for text adventures is OOP--it would be nuts to have it any
other way. (One of my favorite projects quick projects to learn a new
language is to write a tiny text adventure engine in that language.) I'm
a C fan, but, IMHO, there's definitely a time and place for OOP
techniques and styles and it's not that rare, and an OOP language can
make the code in some cases significantly more readable. (Compare GTK+
to GTKmm[1], for example--GUIs are very naturally implemented using
OOP.)

All this being said, there's a bigger picture here than just "C or OOP".
Check out the right sidebar on this page:

http://en.wikipedia.org/wiki/Programming_paradigm

These programming paradigms were all created for a reason, and part of
that was because their creators felt that they could make a better tool
for the job. From time to time, evangelists get a little happy and say
that a particular tool is right for every job. Sure, some are more
"crescent wrenchy" than others, but I haven't found a language I think
is completely well-suited to /everything/.

-Beej

[1] GTK+ in C vs GTKmm in C++:

http://library.gnome.org/devel/gtk-tutorial/stable/c39.html#SEC-HELLOWORLD

http://library.gnome.org/devel/gtkmm-tutorial/unstable/sec-helloworld.html.en
 
D

Duke Normandin

I agree with everything you said, in the sense that my *gut feelings*
tells me it's so. OOP to means *looks* like a huge, convoluted,
cluster-****; a tangle of earthworms; a bloody mess. I don't grok it
--
[snip]

"Use the right tool for the job" applies here. The Inform programming
language for text adventures is OOP--it would be nuts to have it any
other way. (One of my favorite projects quick projects to learn a new
language is to write a tiny text adventure engine in that language.) I'm
a C fan, but, IMHO, there's definitely a time and place for OOP
techniques and styles and it's not that rare, and an OOP language can
make the code in some cases significantly more readable. (Compare GTK+
to GTKmm[1], for example--GUIs are very naturally implemented using
OOP.)

Good advice on using the tools! Need to look at Inform...
I followed the GTK links you provided. Personally, I grok "the big picture"
as to what the code is doing, reading the non-OOP version.

The article was a good refresher for me...
These programming paradigms were all created for a reason, and part of
that was because their creators felt that they could make a better tool
for the job. From time to time, evangelists get a little happy and say
that a particular tool is right for every job. Sure, some are more
"crescent wrenchy" than others, but I haven't found a language I think
is completely well-suited to /everything/.

I guess maybe I'm trying to find a paradigm AND a syntax that easily
digestible to me, with the expressiveness to solve *most* tasks. In that
process of looking, if I can stumble on an implementation of OOP that
doesn't appear to be a friggin huge Matryoshka doll from hell, then so much
the better. I'll have another toy to play with; or another tool, so that I
can "use a bigger hammer" when I have to. ;)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,579
Members
45,053
Latest member
BrodieSola

Latest Threads

Top