superseded by c++?

[Randy Howard]

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.

That's impossible. No wonder it fell flat long term.

 

[Paul Hsieh]

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,

No ... that's just C with classes, and I did that for years before I
really picked up any C++. Doing that does barely anything for you.
You are thinking about it from the compiler's point of view, not the
programmer's point of view. The main benefit of OOP is deriving
classes from abstract classes. Without that, OOP is an entirely
vacuous exercise.

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.

Yes, but now you are walking backwards into the argument. This is the
same as saying that assembly is just as good as C because you can
provide all the same functional implementations. What makes these
mechanisms work in C++ is the fact that its all *TYPE CHECKED* at
compile time. Tracking *which* of the inherited classes a given
abstract class is, can be enforced perfectly at compile time through
type checking. In C you have to check that you are inheriting
properly at run time. Trying to track down a bug in a C simulation of
a class inheritance error is extremely difficult (you need to figure
out that you've called the wrong function pointer somehow, even though
it was supplied with a full complement of seemingly correct
parameters.) This bug isn't even possible in C++ because of type
enforcement.

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.

This kind of actually annoys me. Its a syntactical and semantic
*restriction*, that while well motivated, inevitably can lead to
design constraints that hurt performance. For example, vector on
objects without default constructors becomes of limited value. In any
event, this is not a OOPism, its a C++ism.

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

Ok, this is nonsense. Because C supports fopen() and fclose() doesn't
mean using files in C is inherently OOP. Something has got to give
you a clue here. All the stuff that you can essentially do in C is
*NOT* OOP.

Its all about the type enforced class inheritance. Without that
single feature, I would declare OOP as, essentially a non-existent
idea.

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.

Uh ... I was under the impression that g++ continues to do this.
Perhaps they have changed this.

 

[Charlton Wilbur]

PH> The main benefit of OOP is deriving classes from abstract
PH> classes. Without that, OOP is an entirely vacuous exercise.

*One* benefit.

Paul Graham has some comments on object orientation here, in the
context of why the dialect of Lisp he was designing at the time wasn't
especially object-oriented:

http://www.paulgraham.com/noop.html

And Jonathan Rees responded to that, criticizing the vagueness of the
concept "object orientation," and listing a set of traits that
languages and approaches referred to as "object oriented" often have:

http://www.paulgraham.com/reesoo.html

What you're referring to is a combination of trait #7, specification
inheritance, and #8, implementation inheritance.

If the definition of object oriented language necessarily includes
deriving classes from abstract classes, then Javascript, Python, Ruby,
and Objective-C, having no concept of "abstract class," can not be
object-oriented, and that strikes me as a ludicrous assertion.

Charlton

 

[jameskuyper]

No ... that's just C with classes, and I did that for years before I
really picked up any C++. Doing that does barely anything for you.

Nonetheless, that is the defining characteristic of OOP. The original
claim was "You can do OOP in C". If you're talking about C++ in
particular, rather than OOP in general, then of course "You can do C++
programming in C" is clearly false. However, the features that C++
adds on top of C are merely extremely valuable syntactic sugar that
makes OOP much easier to do; they are not required to use OOP
techniques.

Yes, but now you are walking backwards into the argument. This is the
same as saying that assembly is just as good as C because you can

I didn't say "Just as good". I said "OOP Is much easier in C++", or in
other words, "OOP is much harder in C".

I've run into this problem before - I once mentioned that a pebble has
a mass, just like a mountain has a mass - the mass of the pebble is
just a whole lot smaller than a mountain. To which I got an
argumentative reply telling me that I was spouting nonsense - that a
pebble is nothing like a mountain, because the mountain has an
immensely larger mass. I don't understand the thinking that leads to
these responses. Would you care to explain it?

....

Uh ... I was under the impression that g++ continues to do this.
Perhaps they have changed this.

I deliberately avoided wording that message in a way that would
require me to be sure whether or not modern compilers still do this,
because I was not sure. Did I fail in that avoidance?

 

[santosh]

I deliberately avoided wording that message in a way that would
require me to be sure whether or not modern compilers still do this,
because I was not sure. Did I fail in that avoidance?

As far as I understand g++ does not generate intermediate C code.

 

[Ian Collins]

As far as I understand g++ does not generate intermediate C code.

<OT>g++ may not, but one of the best C++ compilers (Comeau) does in
order to provide maximum portability.</OT>

 

[user923005]

(e-mail address removed) wrote:


<OT>g++ may not, but one of the best C++ compilers (Comeau) does in
order to provide maximum portability.</OT>

We use the SAS compiler for our mainframe, and it produces C as the
intermediate (I believe that it is a C-Front derived compiler).

So we have proof that OO is possible in C.

But it's kind of like doing an engine overhaul with a plumber's pipe
wrenches, some pliers and a crowbar. Sure, you might be able to do
it. But why would anyone in their right mind try to do it? The only
reason that has any legs at all is that a C++ compiler is not
available for the platform in question. Even then, I think I would
try to do things procedurally if I only had a C compiler.

 

[Ian Collins]

We use the SAS compiler for our mainframe, and it produces C as the
intermediate (I believe that it is a C-Front derived compiler).

So we have proof that OO is possible in C.

But it's kind of like doing an engine overhaul with a plumber's pipe
wrenches, some pliers and a crowbar. Sure, you might be able to do
it. But why would anyone in their right mind try to do it? The only
reason that has any legs at all is that a C++ compiler is not
available for the platform in question. Even then, I think I would
try to do things procedurally if I only had a C compiler.

The best example of OO C that I know well is the venerable XView toolkit
from Sun, which was written before C++ was widely available. I learned
all of my early OO concepts developing XView applications. I used a
number of XView ideas and used them in a family of generic device drivers.

So OO can be done and done well in C. I'm not saying they couldn't be
done better in a language with designed in OO support (my first
tentative C++ project was a wrapper for XView), but that one can write
quality OO code in C.

I'm sure there are other decent OO C projects that were written before
OO languages or C++ escaped from the lab.

 

[Chris Thomasson]

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 abstract interfaces:

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

Any more than that is going to be overkill in C, IMHO at least...

 

[cr88192]

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

by similar reasoning, people declare that languages like JavaScript are not
OO, and thus try to demand that JS drop the existing object system and pick
up a more traditional one...

none the less, I am in some rare minority that would rather be doing large
amounts of JS or Self style OO, rather than the C++/Java/C# definition of
OO...


the mainstream languages are almost like this:
people, rather than moving on to free-form mathematical expressions, got
stuck on the idea of having to do loads of fixed-form calculations or
similar, and then glorified this with extra syntax and special modifier
keywords and other formalisms.

so, someone comes along and says:
c=sqrt(a*a+b*b);

and everyone is like, preposterous, it is not math unless written like this:
tmp float x=a*a;
tmp float y=b*b;
tmp float z=1*x+y;
c=sqrt(z);


I argue, what we currently think of as OO, is actually a bunch of glorified
syntax over features, in reality, designed to be efficient (absent a
compiler knowing how to optimize them), and not most general.

and, 'OOP' is a shrine set up to these rigidly-defined fixed forms.


so, what then do we term as "OO":
all of these various features and terms;
all of these various fixed forms and patterns;
solidly defined class hierarchies that can be diagrammed with lots of lines
and boxes;
....


and, apparently, without these things, many programmers feel lost, and write
stupid crap, and then feel it is the fault of the system that they wrote
something stupid and it doesn't work well...

but, of course, Prototype OO is something almost doomed to be rejected by
most people...


maybe in time, remaining bits and pieces will be stuck onto the existing
class/instance model, and be touted as new innovative features.

"wow, what is this!?... class A can dynamically inherit methods from any
other class implementing the B interface!...". maybe a new fancy term
"polytransmorphism"...

that is, after all, the mainstream way.

just like they can, after all, rediscover closures and rename them
delegates.

....

 

[Ian Collins]

by similar reasoning, people declare that languages like JavaScript are not
OO, and thus try to demand that JS drop the existing object system and pick
up a more traditional one...

Each family of languages have their own mindset, those coming from one
often try and impose their preferred way on the new language. In time
they "get" the new language and realise what they have been doing in
nonsense.

but, of course, Prototype OO is something almost doomed to be rejected by
most people...

Until they come to understand it. It took me a while and a lot of bad
code to reach that point. Concepts like prototype inheritance are one
of many reasons to work with as many languages as one can.

 

[Paul Hsieh]

by similar reasoning, people declare that languages like JavaScript are not
OO, and thus try to demand that JS drop the existing object system and pick
up a more traditional one...

Well I would call that a credible argument. Indeed, dynamically typed
languages are something entirely different. How does one encapsulate
an "interface" for example? I don't consider Javascript a real OO
language at all. Its a nice slow, HTML embeded dynamic language that
includes objects.

none the less, I am in some rare minority that would rather be doing large
amounts of JS or Self style OO, rather than the C++/Java/C# definition of
OO...

I have a problem with complicated languages that don't include a
compile time type checker. They may have taken away seg faults, but
they also make every variable of type "void *". Only the PhDs at
Google have the ability to actually scale that to medium size
applications.

dynamic programming language have their place, but objects without
strict typing offer too little in comparison to ordinary modular
programming.

 

[Ian Collins]

I have a problem with complicated languages that don't include a
compile time type checker. They may have taken away seg faults, but
they also make every variable of type "void *". Only the PhDs at
Google have the ability to actually scale that to medium size
applications.

Not void*, you can ask an object what it is.

They also open up other doors that remain closed to strictly typed
languages. Generic programming is way more natural for one, no ugly
templates.

I'm not a PhD, but I have written complex applications in JavaScript and
PHP. Dynamic programming languages are different, not better or worse,
just different.

dynamic programming language have their place, but objects without
strict typing offer too little in comparison to ordinary modular
programming.

There we disagree, each has its place.

 

[cr88192]

Well I would call that a credible argument. Indeed, dynamically typed
languages are something entirely different. How does one encapsulate
an "interface" for example? I don't consider Javascript a real OO
language at all. Its a nice slow, HTML embeded dynamic language that
includes objects.

that is the issue, some people define OO in some overly narrow way (must
includes classes, instances, inheritence, ...).

now, not everyone agrees with this set of definitions...

I have a problem with complicated languages that don't include a
compile time type checker. They may have taken away seg faults, but
they also make every variable of type "void *". Only the PhDs at
Google have the ability to actually scale that to medium size
applications.

comparring dynamic types to 'void *' is, IMO, more than a little too lax.

additionally, not all languages with dynamic types, have only dynamic types
(though in many languages, it is one or the other). not all of them, have
purely runtime checking either (many systems using 'type inference' are
capable of handling both a dynamic type system, and also detecting known
type errors at compile time, and generating code that, in many cases, works
much the same as in some other statically-typed language).


the last of my dynamicly-typed languages (my following effort was a C
compiler), included both JIT and type inference, and in some
narrowly-defined cases could approach "C-like" levels of performance...

a pure C compiler turned out to present many new and interesting issues, and
turned into a fairly interesting, if different, project.

my compiler turns out to be sometimes faster and sometimes slower than gcc
with fairly 'generic' compiler options (in development, I had slightly
overestimated the speed gains of going "SSE everywhere", and there are more
than a few cases where good old ugly x87 outperforms my sometimes slightly
awkward vector-based code...).

dynamic programming language have their place, but objects without
strict typing offer too little in comparison to ordinary modular
programming.

I personally, like using hybrid approaches.

in C, sadly, there is not a lot one can do (using a customeized dynamic type
system is possible, but is awkward, compromises optimization, and type
safety). even as such, this is a common practice in my case (I write
primarily statically-typed code, using the dynamic type system if/when it
makes sense).


however, it is more than possible that a language could natively include
both systems, handling static types in the good old constraint-driven
manner, and dynamic types through a combination of inference and with
occasional dynamic type checks (in cases where the type is not statically
provable).


as for OO, one idea I had considered was to use a hybrid object system as
well, where, rather than the objects themselves being statically defined,
they need only conform to a statically defined interface.

this can allow much of the usual checking mechanics (for example, raising a
type error if an incompatible object is passed, allowing type-optimized slot
and method access, ...), while still allowing dynamic features (ad-hoc
object construction, delegation, ...), and allowing dynamically changing the
'class' of a pre-existing object.

however, this would likely be a somewhat different beast than either
class/instance or prototype OO.

 

[cr88192]

That's impossible. No wonder it fell flat long term.

X 10 PIC(9)
Y 50 PIC(X)

yes, they could have done a little better...


X HOLDS 10 DECIMAL DIGITS
Y HOLDS 50 TEXT CHARS

then maybe a manager could at least make a guess what he is looking at...

 

[Ben Bacarisse]

Not void*, you can ask an object what it is.

They also open up other doors that remain closed to strictly typed
languages. Generic programming is way more natural for one, no ugly
templates.

I know you are talking about C++, but I think it is worth saying --
for the record so to speak -- that strict type checking need not get
in the way of generic programming; it just requires a very much more
sophisticated type system than most languages have had up to now.
Haskell's type classes are one very nice way to get the benefits of
both strict compile-time type checking and flexible generic
programming.

 

[CBFalconer]

.... snip ...

I know you are talking about C++, but I think it is worth saying
-- for the record so to speak -- that strict type checking need
not get in the way of generic programming; it just requires a
very much more sophisticated type system than most languages
have had up to now. Haskell's type classes are one very nice way
to get the benefits of both strict compile-time type checking
and flexible generic programming.

No it doesn't, if you are talking about compiler complications.
Examine the basic ISO7185 Pascal compiler(s). The major difference
is in the language design. Pascal was designed for proper
checking. C was built for absolute minimum interference with the
writers designs. It wasn't designed.

 

[Ben Bacarisse]

No it doesn't, if you are talking about compiler complications.

What part are you disagreeing with?

Examine the basic ISO7185 Pascal compiler(s). The major difference
is in the language design. Pascal was designed for proper
checking.

Yes, but in ISO 7195 Pascal you can't do generic programming (by which
I mean some form of function or module type polymorphism) so I don't
see what I would gain from looking at these compilers. What have I
missed?

C was built for absolute minimum interference with the
writers designs. It wasn't designed.

I disagree (I think there is much design in the various compromises
that C strikes) but that has no bearing on what I was saying.

 

[CBFalconer]

What part are you disagreeing with?

Underlined above.

Yes, but in ISO 7195 Pascal you can't do generic programming (by
which I mean some form of function or module type polymorphism)
so I don't see what I would gain from looking at these compilers.
What have I missed?

Well, when I was using Pascal solidly, I never missed those
abilities. In general, if I needed some sort of special
peripheral, I could build a driver that fitted it into the Pascal
view of files. The file was no longer a text file. For example,
for timed input, I might create:

timedata = RECORD {
data : integer;
time : integer;
END;

tdfile = FILE OF timedata;

and then I created a driver that used the interrupt system,
inputted data and marked it with the time, and put it in a buffer.
The main program just had to read the buffer often enough to avoid
it overfilling. I also created a system known file status call,
for input data available, which handled all the peculiar
interface. get and f^ did it all nicely, fopen connected the
interrupts, fclose disconnected them. fopen failed if the hardware
wasn't installed.

This was on an ISO7185 system running under either CP/M or from ROM
on a diskless machine. Some of the data is available on my page,
as salvaged after a disk disaster some years ago.

 

[Bart C]

however, it is more than possible that a language could natively
include both systems, handling static types in the good old
constraint-driven manner, and dynamic types through a combination of
inference and with occasional dynamic type checks (in cases where the
type is not statically provable).

Interesting, I'm working on such a language at the moment. My last effort
sort of worked but being still statically linked lacked the spontaneity of a
proper dynamic language.

as for OO, one idea I had considered was to use a hybrid object
system as well, where, rather than the objects themselves being
statically defined, they need only conform to a statically defined
interface.

All I can get out of OO are examples of things I've been able to do in
dynamic/interpreted languages for years. Maybe a bit of nice syntax and the
ability to package things neatly.

Getting back to C (this is c.l.c), that's great as an implementation/target
language. For that purpose it should stay simple (ideally get even simpler
and shed baggage, but that's not going to happen).