superseded by c++?

[alansnow]

I am still a die hard C programmer. I did a C++ course a few years ago
but I have never seriously coded in the language.

Is C ever going to be superseded by OOP?

 

[Rico Secada]

On Wed, 02 Jan 2008 17:47:52 +0000

I am still a die hard C programmer. I did a C++ course a few years ago
but I have never seriously coded in the language.

Is C ever going to be superseded by OOP?

No.

 

[Mike Wahler]

I am still a die hard C programmer. I did a C++ course a few years ago
but I have never seriously coded in the language.

Is C ever going to be superseded by OOP?

That is not a rational question. C and C++ are
programming languages. OOP is a design strategy.
One can choose to write OOP programs or not, using
C, C++ or some other language. C++ does have specific
features intended to facilitate OOP which C does not
have, so if your design is OOP, C++ might be the better
choice. Finally, don't believe the myth that OOP
is the solution to all problems. Choose the right
tool for the job.

-Mike

 

[Martin Ambuhl]

I am still a die hard C programmer. I did a C++ course a few years ago
but I have never seriously coded in the language.

Is C ever going to be superseded by OOP?

a) C is perfectly capable of being used for object-oriented programming.
b) No language designed specifically for object-oriented programming
shows any promise of being able to replace C in any of its preferred
domains (perhaps Objective-C had the best shot).

Thank you for spelling "superseded" correctly.

 

[Richard Heathfield]

(e-mail address removed) said:

I am still a die hard C programmer. I did a C++ course a few years ago
but I have never seriously coded in the language.

Is C ever going to be superseded by OOP?

Will baking ever be replaced by Cordon Bleu?

 

[Tomás Ó hÉilidhe]

I am still a die hard C programmer. I did a C++ course a few years ago
but I have never seriously coded in the language.

Is C ever going to be superseded by OOP?

As time goes by and people of less and less aptitude for programming
actually take up programming, a greater proportion of programmers
globally are air-headed and subscribe to "paradigms" rather than using
their own intelect. Thankfully, there are many watered-down mickey-mouse
languages coming to the fore to wick these "programmers" away from real
programming language communities like C and C++.

I learned how to use a class in C++ long before I knew what "object-
orientated programming" meant. I used classes where I thought they fit
well, not because I thought it'd be cool to throw the term, "OO", around.
I think it's a little pathetic that a programmer would be so rigid and
non-fluidic that they'd actually subscribe to a particular programming
paradigm rather than just writing the program and deciding on a case-by-
case basis what would be the best language feature to use.

Learn all the features of a language, and then when you're faced with
a problem, use the best-fitting feature.

But as regards then need for OO. Well I'm comfortable writing code in
C, but there are specific projects that make me think, "yeah I'd
definitely use a class here instead". Then it's just a case of deciding:

1) Do I want to code it in C++ and have the extra features?
2) Or do I want to code it in C and have it more portable, and less
susceptible to compiler bugs (because a C compiler is so much simpler).

Myself though, I tend to use C++ for "desktop applications", and C
for command line programs and for microcontrollers.

But if you're asking about the worth of C++, then its features
*definitely* are valuable... just play around with template functions for
a couple of minutes and you'll... and that's before you've even touched
its standard library.

 

[Tim Smith]

I am still a die hard C programmer. I did a C++ course a few years ago
but I have never seriously coded in the language.

Is C ever going to be superseded by OOP?

The question is not really answerable, because:

(1) You can use C++ without doing OOP.

(2) You can do OOP in C.

 

[Chris Dollin]

(2) You can do OOP in C.

You /can/; that doesn't make it convenient or robust. Mere possibility
isn't enough.

 

[Chris Thomasson]

I am still a die hard C programmer. I did a C++ course a few years ago
but I have never seriously coded in the language.

Is C ever going to be superseded by OOP?

The question is not really answerable, because:
[...]

(2) You can do OOP in C.

Indeed you can:

http://groups.google.com/group/comp.lang.c/browse_frm/thread/1b106926ba5db19f

The trick is to _keep_things_as_minimal_as_possible_!

 

[user923005]

The question is not really answerable, because:

(1) You can use C++ without doing OOP.

Or take the train to the store, 3 blocks away.

(2) You can do OOP in C.

You can also use a butter knife as a screwdriver.

Meanwhile, back at the farm, most of the lines of code in the world
are still in COBOL.

Languages do not go away if they accomplish a useful purpose.

 

[Chris Hills]

Meanwhile, back at the farm, most of the lines of code in the world
are still in COBOL.

I think that is now a myth.

Languages do not go away if they accomplish a useful purpose.

True.

One of my lecturers (some 15 years ago) said:

"COBOL is dead!..... We have buried it every year for the past 15
years!"


However I think that whilst it was true that there were more lines of
COBOL than anything else I think that now it may not be.

I think C probably has more lines of code running now. If only because
"anything" with electrical power anywhere near it has an MCU that is
using C. Most cars each have several million lines of C code in them.

 

[user923005]

I think that is now a myth.


True.

One of my lecturers (some 15 years ago)   said:

"COBOL is dead!..... We have buried it every year for the past 15
years!"

However I think that whilst it was true that there were more lines of
COBOL than anything else I think that now it may not be.

I think C probably has more lines of code running now. If only because
"anything" with  electrical power anywhere near it has an MCU that is
using C.   Most cars each have several million lines of C code in them.

No, it's assembly by the time it gets to the chip. The lines of C are
back at Ford, Chrysler, Chevrolet, etc. (or the vendors who wrote it).
But you are right that I do not know for sure if COBOL still holds the
record.
And when I look at the claims closer they tend to decorate it with
"business" -- whatever that may mean:

e.g. http://www.ensoftcorp.com/Press/FactSheet.gen.html
"200 billion lines of COBOL code (as much as 70 percent of the world's
active business applications) existed in the year 2000, with an
expected growth of 5 billion lines of code per year for the next four
years. (www.gartner.com)"

It also used to be true that most of the data in the world was non-
relational data running on IBM mainframes.

But with the explosion of the internet and with things like Gene banks
and Protein folding banks, I guess that it probably is not true any
more.

 

[Paul Hsieh]

The question is not really answerable, because:

(1) You can use C++ without doing OOP.

Well if C went ahead an adopted some of the simpler things from C++
which have nothing to do with OOP (name spaces, references) then the
*real* dichotomy would be clearer, and this scenario would be truly
marginal.

(2) You can do OOP in C.

How do you declare an abstract class, and inherit in C? (Its kind of
like saying you can do all the abstract data types from C in assembly
language: you can, but without language enforced type safety and
language facilities, its not a scalable programming exercise.)

 

[Chris Hills]

No, it's assembly by the time it gets to the chip.

No, its binary on the chip if we are being pedantic (or
Heathfield-CJB-esque

The lines of C are
back at Ford, Chrysler, Chevrolet, etc. (or the vendors who wrote it).

Surely the same is true with COBAL (isn't a compiler language too?)

But you are right that I do not know for sure if COBOL still holds the
record.

I doubt any one can know for sure any more.

And when I look at the claims closer they tend to decorate it with
"business" -- whatever that may mean:

e.g. http://www.ensoftcorp.com/Press/FactSheet.gen.html
"200 billion lines of COBOL code (as much as 70 percent of the world's
active business applications) existed in the year 2000, with an
expected growth of 5 billion lines of code per year for the next four
years. (www.gartner.com)"

Hmmm that is 7 years ago. I think as people change hardware and or
develop new systems they move on from COBOL... though in 1995 I did come
across "Object COBOL"!

It also used to be true that most of the data in the world was non-
relational data running on IBM mainframes.
But with the explosion of the internet and with things like Gene banks
and Protein folding banks, I guess that it probably is not true any
more.

"Probably" I have no real idea other than gut feeling. It might be worth
asking on a COBOL NG if they are seeing a reduction in the use of COBOL
.. I don't know of any universities still teaching COBOL. are there any
other training places that do?

 

[Chris Hills]

Well if C went ahead an adopted some of the simpler things from C++
which have nothing to do with OOP (name spaces, references) then the
*real* dichotomy would be clearer, and this scenario would be truly
marginal.


How do you declare an abstract class, and inherit in C? (Its kind of
like saying you can do all the abstract data types from C in assembly
language: you can, but without language enforced type safety and
language facilities, its not a scalable programming exercise.)

You can do "Object Based" in C which is modular but not OOP.

My contention is that good modular programming is very close to OOP in
many ways. When people say OOP they get stuck in a particular view. (UML
and the like)

Modular is basically OOP without the inheritance and instantiating
classes on the fly.

 

[user923005]

"Probably" I have no real idea other than gut feeling. It might be worth
asking on a COBOL NG if they are seeing a reduction in the use of COBOL
.   I don't know of any universities still teaching COBOL. are there any
other training places that do?

Universities:
http://www.cobug.com/cobug/docs/courses0023.html

I guess most COBOL training is coming from the junior colleges:
http://www.google.com/search?hl=en&rls=GGLJ,GGLJ:2007-42,GGLJ:en&q=community+college+cobol

 

[Richard Bos]

I think that is now a myth.

Even if it's not, LOC is a bogus measurement of code size, especially
between different languages, and in particularly when one of them is the
overly bloated COBOL.

Richard

 

[Chris Hills]

Even if it's not, LOC is a bogus measurement of code size, especially
between different languages, and in particularly when one of them is the
overly bloated COBOL.

Is COBOL bloated? It's not as though its VC++

 

[James Kuyper]

Even if it's not, LOC is a bogus measurement of code size, especially
between different languages, and in particularly when one of them is the
overly bloated COBOL.

I think that may have been the actual point of the original claim -
COBOL (at some unspecified time) had the largest LOC count precisely
because it is an absurdly bloated language. I've been told that one of
the key design goals of COBOL is to allow developers to write code that
a manager who knows nothing about programming could read and understand.

 

[James Kuyper]

How do you declare an abstract class, and inherit in C? (Its kind of
like saying you can do all the abstract data types from C in assembly
language: you can, but without language enforced type safety and
language facilities, its not a scalable programming exercise.)

I won't deny that using OOP is much easier in C++ than in C; but it is
feasible in C.

The key component of OOP is that methods are associated with objects,
and it's quite feasible to do that in C, by putting members into
structures which are pointers to functions which take a pointer to the
structure type as an argument. You can implement inheritance by having
the first element of a derived struct type be a member of the base
struct type - that allows pointers to the two struct types to be
interconverted.

It is very convenient that in C++ constructors and destructors are
called automatically for variables with static and automatic storage
durations, and by the new and delete operators. However, the fact that C
doesn't have those features that doesn't prevent you from defining
constructors and destructors. You just have to remember to call them
explicitly, rather than having the convenience of having them called
automatically. The constructor for a derived struct type would call the
constructor for the base struct type, and would fill in some of the
function pointers in the base struct type with values pointing to
functions appropriate for the derived struct type.

These, and many other similar tricks, is why it was feasible for some of
the most important early C++ compilers to function by producing C code
as an intermediate step.