Derived classes as parameters
Don C. Hancock
understand how by using virtual functions a derived object knows
who it is and calls it's own member function. (Example given
below with function bar() .) But what I'd like to do is somehow
have the member function recognize the derived class of a
parameter and automatically call the correct member function, as
attempted below with the function foo(). My problem is
essentially that I've got a 'bag' of derived objects and only
have a pointer to the base class of the object. Now I'd like the
compiler (language) to sort out the derived object for me. Can
it be done? Is so how? Thanks for any help. Email to
'dhan...@aero.org' or post replys.
// sample code
class tiger;
class lady;
class door_prize {
public:
virtual foo(tiger *) = 0;
virtual foo(lady *) = 0;
virtual bar() = 0;
};
class tiger : public door_prize {
public:
foo(tiger *) {}
foo(lady *) {}
bar() {}
};
class lady : public door_prize {
public:
foo(tiger *) {}
foo(lady *) {}
bar() {}
};
void main() {
tiger kahn;
lady michele;
door_prize *dp1, *dp2;
dp1 = &kahn;
dp1->bar(); // calls tiger::bar();
dp2 = &michele;
dp2->bar(); // calls lady::bar();
// here it can't find the match for foo(door_prize *) and
// generates a compiler error
dp1->foo(dp2);
}
Rob Menke
In article <1992May7.2...@speedy.aero.org> d...@surtsey.aero.org
(Don C. Hancock) writes:
I understand how by using virtual functions a derived object
knows who it is and calls it's own member function... But what I'd
like to do is somehow have the member function recognize the
derived class of a parameter and automatically call the correct
member function...
This is the problem of multiple polymorphism, and is not directly
supported by C++. (In Booch, only CLOS is listed as supporting it).
The reason this is so is that C++ binds the types of the parameters
early (that is, at compile time) rather than at run-time. It needs
to, as this information is needed for overloading. The type of the
object receiving the message, however, can be bound late via the
virtual keyword. It can do this because the actual function to be
called is stored in the virtual function table.
So how do you get around this limitation?
Simple, actually: you ask the parameter to identify itself.
Per your example:
class door_prize {
public:
virtual foo(tiger *) = 0;
virtual foo(lady *) = 0;
protected:
virtual foo_helper(tiger *) = 0;
virtual foo_helper(lady *) = 0;
};
class tiger : public door_prize {
public:
foo(door_prize *param) { param -> foo_helper(this); }
foo(tiger *) {};
foo(lady *) {};
protected:
foo_helper(tiger *orig_target) { orig_target -> foo(this); };
foo_helper(lady *orig_target) { orig_target -> foo(this); };
};
class lady : public door_prize {
public:
foo(door_prize *param) { param -> foo_helper(this); }
foo(tiger *) {};
foo(lady *) {};
protected:
foo_helper(tiger *orig_target) { orig_target -> foo(this); };
foo_helper(lady *orig_target) { orig_target -> foo(this); };
};
// Some notes: You can't place the code for foo_helper in door_prize
// even though they appear identical-- they're not! 'this' in class
// tiger is of type 'tiger *', while this in class lady is of type
// 'lady *'.
void main() {
tiger kahn;
lady michele;
door_prize *dp1, *dp2;
dp1 = &kahn;
dp2 = &michele;
dp1->foo(dp2);
// this calls tiger::foo(door_prize *), which turns around and
// calls lady::foo_helper(tiger *), which finally calls
// tiger::foo(lady *). Whew!
}
--
"Gadget, love, do ya always carry a | Robert Menke
glass cutter?" | r...@cory.berkeley.edu
"No-- only when I want to cut glass." | ...!ucbvax!cory!rgm
Rob Menke
with my inline functions... some of the B methods reference C
methods, even though class C hasn't been defined. But if you move the
methods after the classes, it should work fine...
Don C. Hancock
Rick Taft (who gets the door prize) who provided the first
solution that worked. To summarize, the following provides
"virtualness" for two parameters. The only odd part is that the
call dp_tig->foo(dp_lad) gets resolved at runtime to
lady::foo(tiger *), which is backwards, but I can live with that.
------SAMPLE CODE---------
class tiger;
class lady;
class door_prize {
public:
virtual void foo(door_prize *) = 0;
virtual void foo(tiger *) = 0;
virtual void foo(lady *) = 0;
virtual void bar() = 0;
};
class tiger : public door_prize {
public:
void foo(door_prize * dp) {
dp -> foo(this);
}
void foo(tiger *) {}
void foo(lady *) {}
void bar() {}
};
class lady : public door_prize {
public:
void foo(door_prize * dp) {
dp -> foo(this);
}
void foo(tiger *) {}
void foo(lady *) {}
void bar() {}
};
void main() {
tiger kahn;
lady michele;
door_prize *dp_tig, *dp_lad;
dp_tig = &kahn;
dp_tig->bar(); // calls tiger::bar();
dp_lad = &michele;
dp_lad->bar(); // calls lady::bar();
dp_tig->foo(dp_lad); // calls lady::foo(tiger *);
dp_lad->foo(dp_tig); // calls tiger::foo(lady *);
}
Jim ADCOCK
>have the member function recognize the derived class of a
No problem ;-) Consider:
#include <iostream.h>
#define self (*this)
class Pet
{
char* name;
public:
Pet(char* p) : name(p) {}
virtual void operator >> (Pet&)=0;
virtual void operator () (char* act, Pet& p)
{ cout << name << ' ' << act << ' ' << p.name << '\n'; }
virtual void operator << (class Cat&)=0;
virtual void operator << (class Dog&)=0;
int operator == (Pet& p) { return this == &p; }
};
class Cat : public Pet
{
public:
Cat(char* p) : Pet(p) {}
void operator >> (Pet&);
void operator >> (Dog&);
void operator >> (Cat&);
void operator << (Cat&);
void operator << (Dog&);
};
class Dog : public Pet
{
public:
Dog(char* p) : Pet(p) {}
void operator >> (Pet& p2);
void operator >> (Dog& d);
void operator >> (Cat& d);
void operator << (Dog& d);
void operator << (Cat& c);
};
void Cat::operator >> (Pet& p) { p << self; }
void Cat::operator >> (Cat& c) { self (c == self ? "licks" : "snifs", c); }
void Cat::operator >> (Dog& d) { self ("scratches", d); }
void Cat::operator << (Cat& c) { c >> self; }
void Cat::operator << (Dog& d) { d >> self; }
void Dog::operator >> (Pet& p) { p << self; }
void Dog::operator >> (Dog& d) { self (d == self ? "scratches" : "barks at", d); }
void Dog::operator >> (Cat& c) { self ("chases", c); }
void Dog::operator << (Dog& d) { d >> self; }
void Dog::operator << (Cat& c) { c >> self; }
typedef Pet* PetPtr;
PetPtr pet[4] =
{
new Dog("Rover"),
new Cat("Sugar"),
new Dog("Spot"),
new Cat("Tiger")
};
main()
{
for (int i=0; i<4; ++i)
for (int j=0; j<4; ++j)
*pet[j] >> *pet[i];
return 0;
}
Tim Lister
>[If this is buried in the FAQ... sorry. I didn't see it.]
>
>In article <1992May7.2...@speedy.aero.org> d...@surtsey.aero.org
>(Don C. Hancock) writes:
>
> I understand how by using virtual functions a derived object
> knows who it is and calls it's own member function... But what I'd
> like to do is somehow have the member function recognize the
> derived class of a parameter and automatically call the correct
> member function...
>
>This is the problem of multiple polymorphism, and is not directly
>supported by C++. (In Booch, only CLOS is listed as supporting it).
>
>The reason this is so is that C++ binds the types of the parameters
>early (that is, at compile time) rather than at run-time. It needs
>to, as this information is needed for overloading. The type of the
>object receiving the message, however, can be bound late via the
>virtual keyword. It can do this because the actual function to be
>called is stored in the virtual function table.
>
I see this type of problem as an inherent limitation
of object orientation. Single dispatch enables suitable languages
to model abstract data types with attributes but not relations.
That is, a fundamental goal of computer science is attainable,
but only for extremely limited types.
For example, an abstract definition in C++ of a mathematical
group cannot be made, whereas, say, a definition of a stack (say
of int) can.
A language with multiple dispatch, in my view, is more than
object oriented.
There is another approach to this. Any 'ordinary' function
can be made an attribute of an object by packing all its parameters
into a structure. Thus
int less(T,T)
becomes
int T2.less(), where T2=T x T
If this could be done by the system, attributes (and hence OO) would
be sufficient. The problem then lies with inheritance, deriving D from
T has no effect on T2. In effect
T ==========> T x T
| |
| |
V V
D ===========> D x D
Fig 1.
must commute. In that case, defining an abstract group would be possible.
You will note that the diagram
T ============> T*
| |
| |
V V
D ============> D*
Fig 2.
does commute in C++. My question is: is it possible to make Fig 1 commute?
Is it possible to make a more general relation commute? (Where
a function has more than just two arguments of the same type?)
How does CLOS achieve multiple dispatching?
--
;----------------------------------------------------------------------
JOHN (MAX) SKALLER, max...@extro.ucc.su.oz.au
Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;-----------------------------------------------------------------------
Doug Morgan
[... previous postings ...]
I see this type of problem as an inherent limitation
of object orientation. Single dispatch enables suitable languages
to model abstract data types with attributes but not relations.
That is, a fundamental goal of computer science is attainable,
but only for extremely limited types.
For example, an abstract definition in C++ of a mathematical
group cannot be made, whereas, say, a definition of a stack (say
of int) can.
It certainly is a limitation. None of C++, Eiffel, Smalltalk, etc.
make it easy to practise polymorphism on the entire argument sequence.
This serious language failing has a disheartening history of being
often discussed and often brushed aside. It is sometimes touted as an
advantage (e.g., "encapsulation is maintained"), treated as solved
(e.g., "you can always add some extra-inheritance procedural code to
achieve the effect"), or treated a unimportant (e.g., "good designs
almost never specialize on more than one argument"). CommonLISP is
one of the few languages (I don't know the others) that simply gives a
real solution instead of excuses.
A language with multiple dispatch, in my view, is more than
object oriented.
Perhaps a language with single dispatch thinks it is object oriented
but actually suffers from mental encapsulation.
[... suggests packing multiple arguments into a structure (I'll
call it a cartesian product tuple) ...] The problem then lies with
inheritance, deriving D from T has no effect on T2. In effect
T ==========> T x T
| |
| |
V V
D ===========> D x D
Fig 1.
[...C++ example ...] My question is: is it possible to make Fig 1
commute? Is it possible to make a more general relation commute?
(Where a function has more than just two arguments of the same
type?)
How does CLOS achieve multiple dispatching?
Method dispatch in CLOS is based on (usually global scope) generic
functions with multiple executable methods. Generic functions
dispatch to methods based on the classes of all arguments. New
methods with different argument types are added directly to the
generic function. There is no concept of one class owning a generic
function or controlling its scope. When called to execute with an
argument sequence, a generic function essentially searches through all
its methods looking for applicable ones, those defined for
superclasses of each argument type. Method applicability and
combination rules then specify which methods to execute and, if more
than one, how to sequence them.
Most CLOS implementations give you a metaobject protocol. That is a
fancy name for a set handles into the class definition mechanisms ---
tools to let you change the default ways of ordering the inheritance
graph and managing slot (member data) access and method dispatch. The
metaobject protocol has a standard, but I think it is still a draft
(but am not at all sure).
The standard CLOS approach to your problem uses multiple argument
generic functions rather than tuples. You just add a method for the
(D, D) arguments to the relation operation generic function. This
works for more than two arguments and for mixed argument types (e.g.,
could be nice for defining a distributive law implementation for a
generic vector space; vector_out = distr(field_element, v1, v2)).
This approach is portable and should integrate well with software
developed elsewhere.
If you still really want to use tuples, you could use the metaobject
protocol to brute force change the class definition defaults to force
Fig 1. to commute. This requires some programming on your part, won't
be quite so portable, and may make your software harder to integrate
with someone else's that uses the metaobject protocol for other
purposes.
JOHN (MAX) SKALLER, max...@extro.ucc.su.oz.au
doug
P.S. Using CLOS will probably give you slower method dispatch. Some
limited timings I tried with single dispatch show about a factor of 10
slow down --- from about 0.7-3.6 usec (0.24 usec if the optimizer can
really get into it) to 7-24 usec on a 25 MHz SPARC. Interestingly,
object sizes may drop dramatically with CLOS if you use lots of
virtual base classes (C++ implementations usually trade off object
size for fast virtual function calls, CLOS implementations usually
don't). Object creation can be much slower in CLOS than C++.
P.P.S. If you think that C++ virtual base classes behave oddly and
suspect there ought be something better, check out CLOS. After
comparing them, you might well wonder whether C++ was designed in the
Twilight Zone. Well, at least it can run fast and is better than C.
/----------------------------------------------------------------------\
| Doug Morgan |
| Advanced Decision Systems (a division of Booz-Allen & Hamilton Inc.) |
| 1500 Plymouth St |
| Mountain View, CA 94043-1230 |
| do...@ads.com, Tele: (415) 960-7300, FAX: (415) 960-7500 |
\----------------------------------------------------------------------/
Thomas M. Breuel
I see this type of problem as an inherent limitation
of object orientation. Single dispatch enables suitable languages
to model abstract data types with attributes but not relations.
That is, a fundamental goal of computer science is attainable,
but only for extremely limited types.
For example, an abstract definition in C++ of a mathematical
group cannot be made, whereas, say, a definition of a stack (say
of int) can.
It certainly is a limitation. [...] CommonLISP is
one of the few languages (I don't know the others) that simply gives a
real solution instead of excuses.
Multiple dispatch does not solve the problems with the OO paradigm, it
compounds them. Even in the single dispatch, multiple inheritance
case, method selection and potential name conflicts are problematic
and tricky. This only gets much worse if you add multiple dispatch.
The issue of packaging related datatypes together and being able to
derive from, and typecheck, collections of datatypes and operations is
also completely orthogonal to the issue of dynamic method dispatch.
The SML module system, for example, lets you package related datatypes
together (you need that for common datatypes like graphs, rings, etc.,
and the lack of such a facility in C++ is a major flaw) and derive
from/to such collections, but it has (fortunately!) no built-in notion
of dynamic method dispatch.
Thomas.
Doug Morgan
In article <DOUG.92Ma...@monet.ads.com> do...@monet.ads.com (Doug Morgan) writes:
pie is ...]
Multiple dispatch does not solve the problems with the OO paradigm, it
compounds them. Even in the single dispatch, multiple inheritance
case, method selection and potential name conflicts are problematic
and tricky. This only gets much worse if you add multiple dispatch.
The issue of packaging related datatypes together and being able to
derive from, and typecheck, collections of datatypes and operations is
also completely orthogonal to the issue of dynamic method dispatch.
The SML module system, for example, lets you package related datatypes
together (you need that for common datatypes like graphs, rings, etc.,
and the lack of such a facility in C++ is a major flaw) and derive
from/to such collections, but it has (fortunately!) no built-in notion
of dynamic method dispatch.
Thomas.
How does the SML module system handle a simple task like "collect
several groups, rings, fields, etc, of different types into a single
set and display the various results of multiplying all element pairs
within each group-like substructure"? This task is like many ordinary
user interface and I/O tasks.
With multiple dispatch, the task can be done simply and extensibly.
No (zero, nada) existing code needs rewriting when new types of
groups, rings, etc are added to the set. Although many people seem to
always value static typechecking and/or single dispatch optimizations
over the ability to easily express such a set, I often want the set.
Unfortunately, out-of-the-box C++, Eiffel, and Smalltalk, etc. (SML?)
don't even give the option.
For a real aside: I would estimate the cost of getting the framework
for such an extensible set in place in C++ to be about 1-20 man-weeks
and a near-zero compatibility with externally developed code. (Just
consider the very impressive and very incompatible contortions shown
in "Advanced C++" and "Data Abstraction and Object-Oriented
Programming in C++" to get even the simplest extensions to the C++
object system). In CommonLISP it would be more like a man-hour to a
man-day and no loss in compatibility.
doug
Jim ADCOCK
|suspect there ought be something better, check out CLOS. After
|comparing them, you might well wonder whether C++ was designed in the
|Twilight Zone. Well, at least it can run fast and is better than C.
The C++ design argument would be that it's the people who insist
that a compiler be able to do all things equally badly that live in
the twilight zone. C++ has many shortcomings, but the reality is
is that the things people have to do commonly are handled very
easily and efficiently. If you ever programmed in Obj-C, you would
realize that a 10X slower dispatch in the virtual function case,
and a say 100X slower dispatch in the non-virtual case, just isn't acceptable
to "real world" programmers. Inline functions and vtable dispatches
may lose in the infrequent case, but most of the time they're a win.
Some Day we may have alternative languages and compilers that can
automatically, quickly, and efficiently wring needless generality
from their code. But, we're some way away from having such capabilities
in a usable, commercially viable compiler. And when such capabilities
do become available, chances are they'll show up in C++ compilers *first*
-- since its the C++ community that values efficiency in the first place!
Multiple dispatch is a pain no matter what the dispatch technique,
because so many different functions have to be written to cover the
various possibilities. You can't in general afford to write N*M
functions in the binary case, N*M*P functions in the trinary case, etc.
So, what functions "tile" what combinations of parm types has to be
pretty much designed on a case-by-case basis. It is not too hard to "design"
your own dispatch techniques in C++ if you don't like vtable dispatch.
Numerical precedence rules and dyn-casting are not a bad choice for
a lot of this stuff.
Doug Morgan
In article <DOUG.92Ma...@monet.ads.com> do...@monet.ads.com (Doug Morgan) writes:
|in the Twilight Zone ...]
The C++ design argument would be that it's the people who insist
that a compiler be able to do all things equally badly that live in
the twilight zone.
I thought the argument was always: "C++ is an engineering compromise
and is not designed to be all things to all people." Kind of a vague
statement, I translate it as: "it seemed like a good idea at the time
and it sure isn't going to change now."
The rest of your message does a good job of pointing out the
commercial realities of C++. C++ vendors view their customers, the
"C++ community," as "real world" programmers that demand maximum
execution speed, ease of doing some common things, and no "needless"
generality. Anyone outside this C++ core community is in the Twilight
Zone and cannot expect to have their specialized applications
influence the core product.
Your assessment of the economics is probably correct. I certainly
can't realistically ask a compiler vendor to do major extra work to
correct what I see as glaring design flaws when thousands happily buy
the existing product and do not often run up against those "flaws."
You followed a theme of "*all* C++ users want exactly such and such"
that, from my viewpoint, is an overstatement. The overwhelming
majority of the people I deal with here in the Twilight Zone (mostly
various university, corporate, and government research organizations)
really do want much more from C++. This Twilight Zone is small, but
but not empty.
[...]
If you ever programmed in Obj-C, you would realize that a 10X
slower dispatch in the virtual function case, and a say 100X slower
dispatch in the non-virtual case, just isn't acceptable to "real
world" programmers.
I couldn't resist this one: Then why is it so many "real world"
programmers seem to just touch a NeXT, become glued to it, and then
rave on and on for years about the fabulous NeXT applications, the
fabulous NeXTStep user interface, etc. etc.? (Must be the parts
written in C++ that work so well? No? Could be just Twilight Zone
people are impressed so I wouldn't know otherwise? Probably. BTW, I
have no connection with any Booz-Allen studies in this area.)
[..]
doug
Thant Tessman
In article <DOUG.92Ma...@monet.ads.com> do...@monet.ads.com (Doug Morgan) writes:
|P.P.S. If you think that C++ virtual base classes behave oddly and
|suspect there ought be something better, check out CLOS. After
|comparing them, you might well wonder whether C++ was designed in the
|Twilight Zone. Well, at least it can run fast and is better than C.
In article <1992May13....@microsoft.com>, ji...@microsoft.com (Jim ADCOCK) writes:
> The C++ design argument would be that it's the people who insist
> that a compiler be able to do all things equally badly that live in
> the twilight zone. C++ has many shortcomings, but the reality is
> is that the things people have to do commonly are handled very
> easily and efficiently.
You have cause and effect backwards.
[...]
> It is not too hard to "design"
> your own dispatch techniques in C++ if you don't like vtable dispatch.
> Numerical precedence rules and dyn-casting are not a bad choice for
> a lot of this stuff.
I am intimately familiar with two message dispatching systems
implemented on top of C++. The first I only worked with. It was
part of a UI toolkit that I was working on that got canceled for
political reasons, but it was extremely powerful and flexible,
relatively efficient. The people who implemented it were very smart
and went to great extremes to make as nice as it was. They went
through five revisions of the entire architecture until they were
satisfied. (I'll even say that one of the people working on it is
the single best programmer I've ever met.) And despite all this,
the task of learning to use it was overwhelming, and actually using
it was cumbersome at best. (I must admit that had we had templates
at the time the situation might have been a little better.)
The second was one I implemented myself. Although it wasn't nearly
as powerful, it was more efficient and much less intimidating to
figure out how to use. But I had to implement it by preprocessing
C++ code and machine-generating more code that got compiled into
the final product.
The point is that there was no reasonable way to do what I wanted
to do within the context of C++. Just because there was no way to
do what I wanted to do efficiently does not mean I didn't want to
do it. And just because some languages don't bother making it easy
to create efficient constructs does not mean that C++ is good
because it only allows constructs that can be implemented efficiently.
C++ is fast and it is better than C, but pretending that C++ supports
higher level constructs only viciously tricks people into wasting time
trying to get it to do what they want it to. And all this is not to
say that I think C++ can be saved by wedging in yet another feature.
It is far too late for that.
--
"I can assure you that orthogonality and simplicity are orthogonal concepts."
- Vincent Manis
Stephan Albert Missura
> A language with multiple dispatch, in my view, is more than
>object oriented.
I think that a language *without* multi-dispatch is not a real
object oriented language. how can we implement a generic
equality relation (a==b) only with single-dispatch?
(double-dispatch would be a solution but I don't think
that implementing this is the programmer's job!)
stephan
--
// Stephan Missura, smis...@iiic.ethz.ch, CS-student - ETH Zuerich \\
// "C combines the power of assembly with the flexibility of assembly" \\
\X/ "C++, the object-oriented assembler" \X/
Stephan Albert Missura
>The SML module system, for example, lets you package related datatypes
>together (you need that for common datatypes like graphs, rings, etc.,
>and the lack of such a facility in C++ is a major flaw) and derive
>from/to such collections, but it has (fortunately!) no built-in notion
>of dynamic method dispatch.
And how do you implement for example generic arithmetic?
I want to write a+b, where a and b has statical type Complex
(so dynamic type would be perhaps Rational or Integer),
and the program should find the correct addition-function
(and not the programmer).
> Thomas.
Jim ADCOCK
|I thought the argument was always: "C++ is an engineering compromise
|and is not designed to be all things to all people." Kind of a vague
|statement, I translate it as: "it seemed like a good idea at the time
|and it sure isn't going to change now."
I agree with both the original statement and your reading of it.
Personally, I believe there is more room for going back and "fixing"
"bad" decisions in C/C++ that others believe. BUT, C++ would still have to
remain an engineering compromise for a number of reasons: it is intended
to be a "smooth" upgrade path from C; if C++ is going to change all the
vendors making C++ compiler have to buy into the change; C++ is intended
for writing "commercially viable" software [which is what I meant by
"real world"] -- and people buying a written-in-C++ spreadsheets for example,
don't care that you wrote that spreadsheet in a language that supports
multiple dispatch. They do care a lot that your spreadsheet program takes
10X longer to do an update than the competitors. So "real world" programs
say: "to hell with the esoteric mumbo jumbo stuff, give me something better
than macros [inline functions] give me something better than switch
statements [virtual functions] give me someway to encapsulate the
ugly details [classes and overloading and constructors and destructors ....]
give me someway to organize and reuse my software [inheritence and templates]
and *forget* the rest [multiple inheritence, multiple dispatch, blah blah blah]"
|The rest of your message does a good job of pointing out the
|commercial realities of C++. C++ vendors view their customers, the
|"C++ community," as "real world" programmers that demand maximum
|execution speed, ease of doing some common things, and no "needless"
|generality.
Its not a question of how C++ vendors views C++ programmers, but rather
a question of how C++ programmers view *their* customers -- namely the
buyer on the street, or rather maybe the buyer walking into a software supermart
looking to buy a spreadsheet, or a game, or a wordprocessor or whatever.
The user on the street really doesn't care how the C++ programmer wrote
the software. SHe only cares that it works, that its cheap, and that it
runs quickly.
|Your assessment of the economics is probably correct. I certainly
|can't realistically ask a compiler vendor to do major extra work to
|correct what I see as glaring design flaws when thousands happily buy
|the existing product and do not often run up against those "flaws."
More importantly, the compiler vendor is unlikely to implement your
[or my] vision of how C++ *should* work if your vision or my vision
differs greatly from the ANSI/ISO-C++ standard-in-progress. If you
want multiple dispatch in C++, "simple"--just sell it to the ANSI C++ committee!
Let's see if they'll change the language one iota for *your* ideas!
[let alone *mine* ;-]
|You followed a theme of "*all* C++ users want exactly such and such"
|that, from my viewpoint, is an overstatement. The overwhelming
|majority of the people I deal with here in the Twilight Zone (mostly
|various university, corporate, and government research organizations)
|really do want much more from C++. This Twilight Zone is small, but
|but not empty.
Agreed. And there will be a continuing supply of professors writing
specialized languages to meet those specialized needs and teaching
programmers those specialized needs who then can't get a job in industry,
because they can't write something that sells to real-world customers.
|I couldn't resist this one: Then why is it so many "real world"
|programmers seem to just touch a NeXT, become glued to it, and then
|rave on and on for years about the fabulous NeXT applications, the
|fabulous NeXTStep user interface, etc. etc.?
So many programmers fall in love with NeXT, so many fall in love with Amigas,
so many fall in love with Fortran, so many fall in love with Forth, etc.
And it doesn't matter a hill of beans unless the person-on-the-street
is willing to fall in love with these things too.
I believe its important for people to try to keep a perspective on
these things lest they lose track of reality. For example, the
reality is is that according to the Computer Selutt database there
have been 5934 references to C++ in the major computer magazines in
the last year compared to 158 for Objective-C. It lists 319 C++-based
software products, compared to 5 for Objective-C.
So, there will always be a place for niche products. Just don't
try to use this as a justification for placing niche features into
mainstream languages.
Doug Morgan
[... C++ is great for and restricted to commercial SW
development...]
Maybe it is better to simply accept this view and forget trying to use
C++ for conceptually difficult problems.
... If you
want multiple dispatch in C++, "simple"--just sell it to the ANSI
C++ committee!...
For the record, my original Twilight Zone crack was directed at C++'s
handling of virtual base classes, not multiple dispatch. I really
can't imagine anyone designing an object oriented language in which
the ability to traverse the class hierarchy is so damaged by
introducing one special type of inheritance relation. The current
model is so poor, I predict that the ANSI C++ committee will do
something about it with no prodding from me.
doug
Tim Lister
>In article <1992May9.1...@ucc.su.OZ.AU> max...@extro.ucc.su.OZ.AU (Tim Lister) writes:
>>[...]
>> A language with multiple dispatch, in my view, is more than
>>object oriented.
>>[...]
>
>I think that a language *without* multi-dispatch is not a real
>object oriented language. how can we implement a generic
>equality relation (a==b) only with single-dispatch?
>(double-dispatch would be a solution but I don't think
>that implementing this is the programmer's job!)
>
>stephan
>
That is the point: OO is just a first step in the right
direction. As soon as you have 'multiple dispatch'
it no longer makes sense to dispatch from one object
or the other.
So such a facility is theoretically beyond Object Orientation.
It requires totally new concepts, OO is simply inadequate.
My point was that you can't easily fix it by taking the
product object of the arguments and doing a single dispatch
from that object, because then the inheritance mechanism
wouldn't work properly on the product object.
Thus we need 'relational' languages.
It would seem you can have this at the moment with CLOS.
(But thats not a static system like C++)
Thomas M. Breuel
And how do you implement for example generic arithmetic?
I want to write a+b, where a and b has statical type Complex
(so dynamic type would be perhaps Rational or Integer),
and the program should find the correct addition-function
(and not the programmer).
You can already do this in C++, without any additional language
support. Consider:
class A:Base { ...
virtual Base operator+(Base &other) {return other.plus_A(*this);}
virtual Base plus_A(A &other) {...}
virtual Base plus_B(B &other) {...}
};
class B:Base {...
virtual Base operator+(Base &other) {return other.plus_B(*this);}
virtual Base plus_A(A &other) {...}
virtual Base plus_B(B &other) {...}
};
Support for multiple dispatch will not reduce the work you have to do
at all. For each combination of types, you still have to write either
a function that handles it explicitly, or you have to take advantage
of single inheritance, or you have to take advantage of implicit type
conversions.
The question is, what would additional language support give you that
you don't already have? I can't see anything. If anything, I think
CLOS-style support for multiple dispatch makes it too easy to forget
to handle a case that you should have handled (*).
As I have argued before, the question of multiple dispatch is
completely separate from the question of packaging multiple, related
datatypes. For multiple dispatch, there are already adequate solutions
in C++.
For packaging multiple, related datatypes there are no good solutions
in C++ (or CLOS, despite the presence of multiple dispatch, but in
CLOS it isn't as much of an issue because CLOS is dynamically typed).
In fact, (and I'm getting tired of harping on this), the only module
system that I have ever seen that handles this case is the SML module
system.
I think a lot of this confusion between dispatch and modularization
comes from the narrow perspective of OOP. OOP, and C++ in particular,
use the single construct of a "class" for three purposes: for
modularization (packaging related items together), for describing
derivations among datatypes, and for describing type dispatch. Now,
OOP is a nice, clean paradigm when it happens to be suited to your
application.
But there are many problems in which modularization, derivations, and
type dispatch do not fit together in the way demanded by the OOP
paradigm, and the OOP paradigm is then inadequate for solving such
problems. Fortunately, you don't have to extend C++ to solve such
problems--there are already languages out there that have more
adequate facilities. CommonLisp/CLOS and SML are examples. Of course,
you pay for the capabilities: it is more difficult to provide
efficient implementations for those languages, and in many ways, they
are more complex than languages like C++.
Thomas.
(*) CLOS-style support does buy you something over explicit multiple
dispatch in terms of runtime extensibility, but C++ is not runtime
extensible even in the single-dispatch case, so that is irrelevant.
Tim Lister
I really liked the non-sexist pronouns used in the JOY of TEX but
lost my copy. If anyone out there has a copy, e might post a couple
(just for fun)
Stephan Albert Missura
>
> And how do you implement for example generic arithmetic?
> I want to write a+b, where a and b has statical type Complex
> (so dynamic type would be perhaps Rational or Integer),
> and the program should find the correct addition-function
> (and not the programmer).
>
>You can already do this in C++, without any additional language
>support.
I know how to implement it in C++ (I did it also; but the result
was not very elegant: similar to your solution).
>Consider:
>
>class A:Base { ...
> virtual Base operator+(Base &other) {return other.plus_A(*this);}
> virtual Base plus_A(A &other) {...}
> virtual Base plus_B(B &other) {...}
>};
>
>class B:Base {...
> virtual Base operator+(Base &other) {return other.plus_B(*this);}
> virtual Base plus_A(A &other) {...}
> virtual Base plus_B(B &other) {...}
>};
What you are doing is *explicitely* code the multi-dispatch
by using double-dispatch technique. But what I want to say
is: why can't the compiler do this *implicetely* ?
(perhaps using the same technique as in your example)
>Support for multiple dispatch will not reduce the work you have to do
>at all. For each combination of types, you still have to write either
>a function that handles it explicitly, or you have to take advantage
>of single inheritance, or you have to take advantage of implicit type
>conversions.
Multiple dispatch is only reasonable with inheritance.
But with inheritance it will often reduce the programmers work
because you give a default implementation of the function in your
base class and only a few of the subclasses will redefine it.
Example: Equalitity relation == (of type Object,Object-->Boolean)
which you will define once in your base class Object
(as returning False). Then the subclasses will overwrite ==
(now with type Sub,Sub-->Boolean) with its eq.relation.
The same applies to + and the complex numbers.
>The question is, what would additional language support give you that
>you don't already have? I can't see anything. If anything, I think
>CLOS-style support for multiple dispatch makes it too easy to forget
>to handle a case that you should have handled (*).
In assembler you can also implement single-dispatch;
so why do we need C++? (:-) The idea of additional language
support is to get more abstraction which helps programmer
to concentrate on the effective problem and not on "how must we
change the problem such that CC eats the source".
>As I have argued before, the question of multiple dispatch is
>completely separate from the question of packaging multiple, related
>datatypes.
That is true: The "module" history is something different
(in the previous lines I only spoke about multi dispatch)
>For multiple dispatch, there are already adequate solutions
>in C++.
I don't think implementing double-dispatch "by hand" is adequate.
>For packaging multiple, related datatypes there are no good solutions
>in C++
Files... ;-)
>(or CLOS, despite the presence of multiple dispatch, but in
>CLOS it isn't as much of an issue because CLOS is dynamically typed).
>In fact, (and I'm getting tired of harping on this), the only module
>system that I have ever seen that handles this case is the SML module
>system.
Do we need modules defined in the *language*? Are classes not enough?
I think "Modules" (as for example in Modula-2 defined) are reflecting
the file or file-system (but a bit more elegantly as C's or
C++'s #include). Why need the programmer to know *where* his
classes are stored? He is interested in classes and not files...
(I don't know SML; I only spoke about Modula-Modules)
>I think a lot of this confusion between dispatch and modularization
>comes from the narrow perspective of OOP. OOP, and C++ in particular,
>use the single construct of a "class" for three purposes: for
>modularization (packaging related items together), for describing
>derivations among datatypes, and for describing type dispatch. Now,
>OOP is a nice, clean paradigm when it happens to be suited to your
>application.
>
>But there are many problems in which modularization, derivations, and
>type dispatch do not fit together in the way demanded by the OOP
>paradigm, and the OOP paradigm is then inadequate for solving such
>problems.
I would be interested in such examples.
>Fortunately, you don't have to extend C++ to solve such
>problems--there are already languages out there that have more
>adequate facilities.
I don't think extending C++ is the proper way ;-)
>CommonLisp/CLOS and SML are examples. Of course,
>you pay for the capabilities: it is more difficult to provide
>efficient implementations for those languages, and in many ways, they
>are more complex than languages like C++.
For the compiler/interpreter-writer these languages
are more complicate. That's clear (so we need also
"theory-people" and not also "real-world-programmer"
to do research in this field ;-).
But I don't think to learn those languages is more complex than C++
because they are much more consistent.
> Thomas.
>
>(*) CLOS-style support does buy you something over explicit multiple
>dispatch in terms of runtime extensibility, but C++ is not runtime
>extensible even in the single-dispatch case, so that is irrelevant.
stephan
Stephan Albert Missura
>[...]
>Multiple dispatch is a pain no matter what the dispatch technique,
>because so many different functions have to be written to cover the
>various possibilities. You can't in general afford to write N*M
>functions in the binary case, N*M*P functions in the trinary case, etc.
>So, what functions "tile" what combinations of parm types has to be
>pretty much designed on a case-by-case basis.
Multi dispatch makes only sense with inheritance: You give in
your base class a default function definition. Some classes (and normally
not all) will redefine it (so N*M is the maximum but not the
average ;-)
>It is not too hard to "design"
>your own dispatch techniques in C++ if you don't like vtable dispatch.
>Numerical precedence rules and dyn-casting are not a bad choice for
>a lot of this stuff.
But that is the problem: you can always say:
"if we don't have feature X in C++ you can implement it somehow"
(as operator. ;-)
Stephan Albert Missura
>In article <1992May14.1...@neptune.inf.ethz.ch> smis...@iiic.ethz.ch (Stephan Albert Missura) writes:
>>In article <1992May9.1...@ucc.su.OZ.AU> max...@extro.ucc.su.OZ.AU (Tim Lister) writes:
>>>[...]
>>> A language with multiple dispatch, in my view, is more than
>>>object oriented.
>>>[...]
>>
>>I think that a language *without* multi-dispatch is not a real
>>object oriented language. how can we implement a generic
>>equality relation (a==b) only with single-dispatch?
>>(double-dispatch would be a solution but I don't think
>>that implementing this is the programmer's job!)
>>
>>stephan
>>
> You cant. (implement ==).
In a proper way it is not possible (except very few
languages).
> That is the point: OO is just a first step in the right
> direction. As soon as you have 'multiple dispatch'
> it no longer makes sense to dispatch from one object
> or the other.
That is now a question of definition:
are only oo-languages where "objects send messages to other
objects" (i.e.: single-dispatch) *real* oo-languages?
Is this sending of messages the key feature of oo-languages?
I don't think so: the key features are inheritance of classes
and polymorphism (*full* polym.,i.e. multi dispatch).
But as I said: a question of definition.
>
> So such a facility is theoretically beyond Object Orientation.
> It requires totally new concepts, OO is simply inadequate.
We have inheritance and polymorphism. So what are you missing?
(or what can't you implement in a proper way?).
And what is more important: How do you define oo?
>
> My point was that you can't easily fix it by taking the
> product object of the arguments and doing a single dispatch
> from that object, because then the inheritance mechanism
> wouldn't work properly on the product object.
>
> Thus we need 'relational' languages.
> It would seem you can have this at the moment with CLOS.
> (But thats not a static system like C++)
>
>--
>;----------------------------------------------------------------------
> JOHN (MAX) SKALLER, max...@extro.ucc.su.oz.au
> Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
>;-----------------------------------------------------------------------
stephan
Tim Lister
>I know how to implement it in C++ (I did it also; but the result
>was not very elegant: similar to your solution).
>
>>Consider:
>>
>>class A:Base { ...
>> virtual Base operator+(Base &other) {return other.plus_A(*this);}
>> virtual Base plus_A(A &other) {...}
>> virtual Base plus_B(B &other) {...}
>>};
>>
>>class B:Base {...
>> virtual Base operator+(Base &other) {return other.plus_B(*this);}
>> virtual Base plus_A(A &other) {...}
>> virtual Base plus_B(B &other) {...}
>>};
>
>What you are doing is *explicitely* code the multi-dispatch
>by using double-dispatch technique. But what I want to say
>is: why can't the compiler do this *implicetely* ?
>(perhaps using the same technique as in your example)
>
You argument is not strong enough. You are saying
"I can do this, but I might make errors, it is hard to read, I just
want the compiler to help".
A much stronger argument: the technique DOES NOT WORK.
It fails to obey the OPEN-CLOSED principle (Meyer). Try adding
class C to the above scheme WITHOUT modifying A or B.
>>Support for multiple dispatch will not reduce the work you have to do
>>at all. For each combination of types, you still have to write either
>>a function that handles it explicitly, or you have to take advantage
>>of single inheritance, or you have to take advantage of implicit type
>>conversions.
>
>Multiple dispatch is only reasonable with inheritance.
>But with inheritance it will often reduce the programmers work
>because you give a default implementation of the function in your
>base class and only a few of the subclasses will redefine it.
>
In other words, instead of defining N*M functions, some can
default. But in multiple dispatch it is not clear just how that should
work. The defaulting (to previously defined and not overridden) functions
only seems to work properly in single dispatch. In multiple dispatch
you need a database of implemented functions, and a logic language to
decide (using rules) which one to call. (CLOS meta objects?)
>Example: Equalitity relation == (of type Object,Object-->Boolean)
>which you will define once in your base class Object
>(as returning False). Then the subclasses will overwrite ==
>(now with type Sub,Sub-->Boolean) with its eq.relation.
>The same applies to + and the complex numbers.
But this might be DANGEROUS. How do you resolve say
complex + real?
Casting it down to real + real is plain WRONG.
Casting it UP to complex + complex is right in this case,
but is backwards from the normal scheme of things. The fact is,
one must examine the categories involved, determine the correct
functors, and then instruct the system how to do it. And that
requires M*N*P*Q in effect. So you use RULES (logic) to reduces
the storage requirements in favour of some inefficiency.
IMHO the one thing C++ left out was LOGIC. See Eiffel,
which has support for Invariants, Pre-Conditions, etc. Logic is
crucial NOT for correctness, but managing the correctness/efficiency
tradeoff. For example, suppose you insist on array bound checking.
Normally done at run-time. BUT suppose you and the compiler prove
that a particular index MUST be in range. THEN the compiler can
omit the range-check.
This changes the nature of programming in the sense that
efficiency is not obtained (at the expense of correctness) by
writing contorted code, but by using logic. If something is
shown by your profiler to be inefficient because of an unnecessary
range check, then PROVE the test is unnecessary and the compiler
will omit the run-time test.
>
>>The question is, what would additional language support give you that
>>you don't already have? I can't see anything. If anything, I think
>>CLOS-style support for multiple dispatch makes it too easy to forget
>>to handle a case that you should have handled (*).
>
>In assembler you can also implement single-dispatch;
>so why do we need C++? (:-) The idea of additional language
>support is to get more abstraction which helps programmer
>to concentrate on the effective problem and not on "how must we
>change the problem such that CC eats the source".
Not only this, but also "how can we reuse the code?".
We need the OPEN-CLOSED principle to WORK. Recall that virtual
function/inheritance does not just clean up long switch
statements. Switch statements cannot be extended without
modifying them. Virtual functions CAN BE. So this
is FUNDAMENTAL. (It is the ONLY fundamental thing IMHO in C++,
all else is prettiness, and could be done in C with ugly and error
prone operations.)
>
>>As I have argued before, the question of multiple dispatch is
>>completely separate from the question of packaging multiple, related
>>datatypes.
Well, not COMPLETELY separate. You have to have
somethingto package, and how you wrap it up depends on what you are
wrapping.
>
>That is true: The "module" history is something different
>(in the previous lines I only spoke about multi dispatch)
>
>>For multiple dispatch, there are already adequate solutions
>>in C++.
No, there are not (IMHO)
>
>I don't think implementing double-dispatch "by hand" is adequate.
Correct.
>
>>For packaging multiple, related datatypes there are no good solutions
>>in C++
>
>Files... ;-)
>
But because there was NO attempt to supply modules, we are
still free to impement a GOOD solution.
>
>Do we need modules defined in the *language*? Are classes not enough?
>I think "Modules" (as for example in Modula-2 defined) are reflecting
>the file or file-system (but a bit more elegantly as C's or
>C++'s #include). Why need the programmer to know *where* his
>classes are stored? He is interested in classes and not files...
>(I don't know SML; I only spoke about Modula-Modules)
What are modules? (Packages?)
1) Groups of related classes and other things (constants, etc)
2) Names in modules can be qualified to avoid ambiguity.
3) Names in modules can be renamed on importing to coerce
desired bindings.
4) Other things..Someone who knows, please post a summary?
>
>>I think a lot of this confusion between dispatch and modularization
>>comes from the narrow perspective of OOP. OOP, and C++ in particular,
>>use the single construct of a "class" for three purposes: for
>>modularization (packaging related items together), for describing
>>derivations among datatypes, and for describing type dispatch. Now,
>>OOP is a nice, clean paradigm when it happens to be suited to your
>>application.
>>
>>But there are many problems in which modularization, derivations, and
>>type dispatch do not fit together in the way demanded by the OOP
>>paradigm, and the OOP paradigm is then inadequate for solving such
>>problems.
>
>I would be interested in such examples.
Um, you already looked at them. Just consider how to
write a Group theory package. In fact, almost any mathematical
construction will suffice.
>
>>Fortunately, you don't have to extend C++ to solve such
>>problems--there are already languages out there that have more
>>adequate facilities.
>
>I don't think extending C++ is the proper way ;-)
The real question is: is extending OO the proper way.
>
>>CommonLisp/CLOS and SML are examples. Of course,
>>you pay for the capabilities: it is more difficult to provide
>>efficient implementations for those languages, and in many ways, they
>>are more complex than languages like C++.
>
>For the compiler/interpreter-writer these languages
>are more complicate. That's clear (so we need also
>"theory-people" and not also "real-world-programmer"
>to do research in this field ;-).
>But I don't think to learn those languages is more complex than C++
>because they are much more consistent.
Oh? Lisp sure isn't 'consistent'. I would think by
definition any powerful system isn't consistent (didn't Goedel prove that?)
>
>> Thomas.
>>
Please reconsider my original transformation of the problem
of multiple dispatch. Several function arguments can always be
packaged off into a single object, which can then be accessed with
SINGLE dispatch perfectly. Now the problem appears different:
how do you make the inheritance mechanism work to achieve the same
results? And remember---this is the SAME problem recast in a different
light. If you solve multiple dispatch, there is an equivalent solution
for inheritance and vice-versa.
If there is no solution, OO is flawed conceptually.
Tim Lister
>
>> That is the point: OO is just a first step in the right
>> direction. As soon as you have 'multiple dispatch'
>> it no longer makes sense to dispatch from one object
>> or the other.
>
>That is now a question of definition:
>are only oo-languages where "objects send messages to other
>objects" (i.e.: single-dispatch) *real* oo-languages?
>Is this sending of messages the key feature of oo-languages?
>I don't think so: the key features are inheritance of classes
>and polymorphism (*full* polym.,i.e. multi dispatch).
>But as I said: a question of definition.
>
>>
>> So such a facility is theoretically beyond Object Orientation.
>> It requires totally new concepts, OO is simply inadequate.
>
>We have inheritance and polymorphism. So what are you missing?
>(or what can't you implement in a proper way?).
>And what is more important: How do you define oo?
>
I would envisiage reducing the N*M*P*Q ... functions required by
multiple dispatch (since obviously that can't be implemented using
storage, or by writing all those functions) by writing procedures
to determine which of the available functions to select.
In single dispatch, each derivation only adds one more
function (at the most). And your 'rule' about selection is:
"If I define an override, use it, otherwise inherit"
This can't work in multiple dispatch.
>>
>> My point was that you can't easily fix it by taking the
>> product object of the arguments and doing a single dispatch
>> from that object, because then the inheritance mechanism
>> wouldn't work properly on the product object.
>>
>> Thus we need 'relational' languages.
>> It would seem you can have this at the moment with CLOS.
>> (But thats not a static system like C++)
>>
And LOGIC has another role. It is used (via proofs) to eliminate
or reduce run-time checking, ie. LOGIC=EFFICIENCY.
Thomas M. Breuel
> And how do you implement for example generic arithmetic?
> I want to write a+b, where a and b has statical type Complex
> (so dynamic type would be perhaps Rational or Integer),
> and the program should find the correct addition-function
> (and not the programmer).
>
>You can already do this in C++, without any additional language
>support. Consider:
>
>class A:Base { ...
> virtual Base operator+(Base &other) {return other.plus_A(*this);}
> virtual Base plus_A(A &other) {...}
> virtual Base plus_B(B &other) {...}
>};
>
>class B:Base {...
> virtual Base operator+(Base &other) {return other.plus_B(*this);}
> virtual Base plus_A(A &other) {...}
> virtual Base plus_B(B &other) {...}
>};
>
AND NOW
class C:Base { ...
woops: A+C doesn't work!! (Apart from the return type being wrong
in all cases)
I considered both of those questions when I made up this simple
example. Maybe _you_ can tell us:
(1) What would you _want_ "class C:Base { ... }" to behave wrt. addition?
(2) How would support for multiple dispatch help you do that?
(3) What would you _want_ the return type to be?
As far as I can tell, you still have to do the same amount of work
even if your language has multiple dispatch.
Thomas.
Thomas M. Breuel
A much stronger argument: the technique DOES NOT WORK.
It fails to obey the OPEN-CLOSED principle (Meyer). Try adding
class C to the above scheme WITHOUT modifying A or B.
Try doing that with multiple dispatch, and you will see that it won't
work either, since in C++, any method or function that has access to
the internals of a class must be mentioned in the class.
A hypothetical multiple-dispatch operator+(A,C) would normally need
equal access to the internals of both classes A and C. If class A has
already been written without class C in mind, class A would need to be
modified, support for multiple-dispatch notwithstanding.
Again, there are indeed good reasons for multiple dispatch support,
including runtime extensibility, the "open-closed" principle (as you
call it), and method lookup efficiency. But as far as I can tell, the
first two do not fit into a C++ framework, and the last is pretty much
unimportant: the overhead of two table lookups is pretty small
compared with the overhead of one lookup.
I think if you propose a language extension like this, the burden of
proof is on _you_ to demonstrate that it provides new functionality
not previously available, and to analyze how it integrates with the
rest of the language. Just waving your hands and saying "it would be
so nice" isn't enough.
Thomas.
Thomas M. Breuel
A much stronger argument: the technique DOES NOT WORK.
It fails to obey the OPEN-CLOSED principle (Meyer). Try adding
class C to the above scheme WITHOUT modifying A or B.
[...]
Not only this, but also "how can we reuse the code?".
We need the OPEN-CLOSED principle to WORK. Recall that virtual
function/inheritance does not just clean up long switch
statements.
There seems to be a weird notion that the "open-closed" principle can
only be supported in an OO programming language. This is, of course,
far from true.
A detailed discussion of those issues is rather complex, but there are
several general techniques available for making code reusable without
having to modify the original code textually:
(1) use type conversions (explicit or implicit, like C++ casts)
(2) parameterize your code by types (C++ templates)
(3) pass pointers to functions (C++ virtual functions)
All three approaches have been around since long before C++ or OOP
existed. OOP is merely one particular approach towards organizing item
(3).
Which of these methods is "the best" depends on your particular
application. Personally, in C++, I find myself using (1) and (2) much
more often than (3).
Thomas.
PS:
Switch statements cannot be extended without
modifying them. Virtual functions CAN BE. So this
is FUNDAMENTAL. (It is the ONLY fundamental thing IMHO in C++,
all else is prettiness, and could be done in C with ugly and error
prone operations.)
Switch statements are not the only way to implement methods; function
pointers stored in data structures or passed as arguments are another
approach. Because of various limitations of C/C++ runtime safety, of
C/C++ function pointers, and of the C/C++ type system, those common
approaches to code reuse by passing function pointers around are
especially cumbersome in C/C++. To me, this deficiency in the base
language (C) is the main justification for adding virtual functions in
C++.
Tim Lister
>
> A much stronger argument: the technique DOES NOT WORK.
> It fails to obey the OPEN-CLOSED principle (Meyer). Try adding
> class C to the above scheme WITHOUT modifying A or B.
>
>Try doing that with multiple dispatch, and you will see that it won't
>work either, since in C++, any method or function that has access to
>the internals of a class must be mentioned in the class.
>
>A hypothetical multiple-dispatch operator+(A,C) would normally need
>equal access to the internals of both classes A and C. If class A has
>already been written without class C in mind, class A would need to be
>modified, support for multiple-dispatch notwithstanding.
No it wouldn't. In my definition (maybe bad),
you CANT have multiple dispatch in an OO system in the first place.
If we have a language defined functor for X,Y -> X x Y
then + can be defined on A x C without changing A or C. And
then only SINGLE dispatch (on Base x Base) is required.
>
>Again, there are indeed good reasons for multiple dispatch support,
>including runtime extensibility, the "open-closed" principle (as you
>call it), and method lookup efficiency. But as far as I can tell, the
>first two do not fit into a C++ framework, and the last is pretty much
>unimportant: the overhead of two table lookups is pretty small
>compared with the overhead of one lookup.
The problem is not speed, but exponential growth of the
storage required for a matrix of N*M functions (and worse
if the dispatch is over several arguments).
>
>I think if you propose a language extension like this, the burden of
>proof is on _you_ to demonstrate that it provides new functionality
>not previously available, and to analyze how it integrates with the
>rest of the language. Just waving your hands and saying "it would be
>so nice" isn't enough.
>
> Thomas.
I'm not waving my arms, I never proposed multiple
dispatch --- others said : CLOS can do this with MD.
*I* said, what is needed for a proper operater + can't
be done in ANY object oriented language, because OO is simply
inadequate.
So the onus is on YOU to prove me wrong. Others replied,
you can do this with MD, and any OO system without MD isn't really
object oriented. Assuming they are right (it can be done with MD),
then they are confirming my original argument that, in terms of
my limited definition of OO, OO can't be used to implement +.
You gave a very good example of how one might attempt
to implement + using virtual functions. I had not seen this
technique before, it is much cleaner than using a switch.
I simply pointed out that the technique does not work
(given we are trying to put ADTs into a language)
More generally, OO can't be used to implement any but
trivial ADTs. The fact that it CAN implement trivial ADTs is a major
breakthrough in static language design, and my compliments
to Bjarne and Ellis for getting such a powerful technique into C.
Finally, I showed that you can recast the problem by
putting all the arguments of a function into an object, and using
single dispatch. The problem is then nothing to do with dispatch,
now it is that the inheritance mechanism doesn't work.
I actually STATED the problem nicely I thought,
in terms of the diagram. I will draw it again. The rule is:
The diagram
X =============> X x X |
| | V derivation
| |
V V ==> formation of product
Y =============> Y x Y
must commute. This is precisley the same as having 'multiple dispatch',
but it is done IN THE CURRENT SINGLE DISPATCH FRAMEWORK of C++.
(In practice, the explicit single dispatch would invoke the same sort
of operations that would be required in multiple dispatch.)
Your example was more complicated (since I show X-> X x X, you used
X,Y -> X x Y, which is harder to draw).
I believe X =====> X x X could easily and usefully added to C++.
But is is not general enough, I want a general solution.
To explain 'must commute', consider that
X ============> X*
| | ==> pointer to class
| |
V V
Y ============> Y*
does indeed commute in C++ right now. If, however, you substitute
smart pointer to X for pointer to X, then it doesn't commute.
Of course, in all these cases templates (genericity) is useful,
but it doesn't support polymorphism.
Ian Joyner
>In article <DOUG.92Ma...@monet.ads.com> do...@monet.ads.com (Doug Morgan) writes after reading something different than I wrote:
>|I thought the argument was always: "C++ is an engineering compromise
>|and is not designed to be all things to all people." Kind of a vague
>|statement, I translate it as: "it seemed like a good idea at the time
>|and it sure isn't going to change now."
I read "engineering compromise" as being a really feeble excuse for
the unacceptable. Basically, computers are useful tools, because
they idealise the world. You abstract away from the confusing
details of the world. We are using the idealised world of digital
systems. "Engineers" are used to dealing with imprecise analogue
materials. In this domain they must compromise, eg build the bridge
pier a bit thicker because there might be an earth quake. In software
development though, you entirely control the world you are building.
If we don't, computers become a far less useful tool. I suggest re-reading
the first chapter of Dijkstra's Discipline of Programming, on the role
of programming languages. Basically, this explains why such compromises
result in tools and languages which are less useful.
>I agree with both the original statement and your reading of it.
>Personally, I believe there is more room for going back and "fixing"
>"bad" decisions in C/C++ that others believe. BUT, C++ would still have to
>remain an engineering compromise for a number of reasons: it is intended
>to be a "smooth" upgrade path from C; if C++ is going to change all the
>vendors making C++ compiler have to buy into the change; C++ is intended
>for writing "commercially viable" software [which is what I meant by
>"real world"] -- and people buying a written-in-C++ spreadsheets for example,
>don't care that you wrote that spreadsheet in a language that supports
>multiple dispatch. They do care a lot that your spreadsheet program takes
>10X longer to do an update than the competitors. So "real world" programs
>say: "to hell with the esoteric mumbo jumbo stuff, give me something better
>than macros [inline functions] give me something better than switch
>statements [virtual functions] give me someway to encapsulate the
>ugly details [classes and overloading and constructors and destructors ....]
>give me someway to organize and reuse my software [inheritence and templates]
>and *forget* the rest [multiple inheritence, multiple dispatch, blah blah blah]"
If I hear this engineering compromise rubbish much more, I swear I am going
to scream. You are right that the customer does not care how you developed
the product. I don't care how a bridge was built when I drive over it. All
I care about is that is does not fall down. However that the bridge does
not fall down is a testimony to 'how' it was built.
There are two factors that are more important than the above blinkered
efficiency argument. Firstly, efficiency does not matter if the
program is not correct, or it is unreliable. Secondly, many products
do not even hit the streets, because the project fails. The practicality
of better approaches to software development is to have less project
failures. Efficiency just isn't important if your product doesn't even
hit the streets in the first place.
That C++ is based on C begs the question of do we want these 20 year old
"engineering compromises" in modern software development. There is also
the misconception that C/C++ can be the only efficient way to implement
software. There is nothing magic about C that makes it intrinsically 10
times faster than anything else. There are cases of C++ vs
Obj-C/Smalltalk, etc where this may be the case due to method dispatch,
but we need to get away from the assertion that if you want it to be
efficient then it must be written in C++.
And I agree, to hell with the esoteric mumbo jumbo stuff, give
us something better than C++.
>|You followed a theme of "*all* C++ users want exactly such and such"
>|that, from my viewpoint, is an overstatement. The overwhelming
>|majority of the people I deal with here in the Twilight Zone (mostly
>|various university, corporate, and government research organizations)
>|really do want much more from C++. This Twilight Zone is small, but
>|but not empty.
Those who are starting to demand better, modern ways of doing things
are not dreamers or academics out in the "Twilight Zone". We are
people who recognise that there are better ways of doing things
than C++.
--
Ian Joyner ACSNet: i...@syacus.acus.oz
ACUS (Australian Centre for Unisys Software) Internet: i...@syacus.acus.oz.au
115-117 Wicks Rd, North Ryde, N.S.W, Australia 2113.
Tel 61-2-390 1328 Fax 61-2-390 1391 UUCP: ...uunet!munnari!syacus.oz
Andrew Koenig
> Those who are starting to demand better, modern ways of doing things
> are not dreamers or academics out in the "Twilight Zone". We are
> people who recognise that there are better ways of doing things
> than C++.
It makes sense to talk about `better' only after supplying a context.
Which tool is better, a hammer or screwdriver?
Every language I have ever seen does some things particularly well
and others particularly badly. It behooves us all, as professionals,
to choose the tools most appropriate for the context, which includes
the application itself, the biases of the users, and the surrounding
community.
Do not, however, make the mistake of believing that your particular
context is universal.
--
--Andrew Koenig
a...@europa.att.com
Jim ADCOCK
|are not dreamers or academics out in the "Twilight Zone". We are
|people who recognise that there are better ways of doing things
|than C++.
It takes no genius to realize the shortcomings of C++ -- successful
C++ programmers are the ones who recognize its shortcomings and avoid
them. Its not that C++ programmers don't recognize C++'s shortcomings,
its that they recognize C++'s strengths. C++ strength's are pretty
pragmatic: it builds on the most popular previous language, it exists,
its available from a large number of vendors, compilers exist for it
that are pretty darned good, its fast, etc. Personally, I'd love to
see people [people who already know C++] start working on C++++ [or
C3, or whatever you want to call it] Not for multiple dispatch, but
to clean up what's already there and make it more regular.
Jim ADCOCK
|In article <1992May14.1...@microsoft.com> ji...@microsoft.com (Jim ADCOCK) writes:
| [... C++ is great for and restricted to commercial SW
| development...]
Your words, not mine. I would say that C++ features are restricted to
what commercial SW developers can afford. This in no way restricts C++
use to commercial SW developers. Lots of researchers have done lots of
things with C++ that are interesting but wouldn't cut it in the commercial
world. And some of the math stuff is successfully jumping the boundary
between acedemia and industry. So its not that acedemia can't write
fast software, or isn't interested in fast software. Its just that speed
isn't necessarily a do or die proposition during research projects.
Commercialize that research though, and speed will almost certainly become
a critical factor.
|For the record, my original Twilight Zone crack was directed at C++'s
|handling of virtual base classes, not multiple dispatch. I really
|can't imagine anyone designing an object oriented language in which
|the ability to traverse the class hierarchy is so damaged by
|introducing one special type of inheritance relation. The current
|model is so poor, I predict that the ANSI C++ committee will do
|something about it with no prodding from me.
I predict that hell will sooner freeze over :-)
On a serious note, I believe they are considering a very limited form
of overloading based on return type.
Jim ADCOCK
|In article <1992May13....@microsoft.com> ji...@microsoft.com (Jim ADCOCK) writes:
|Multi dispatch makes only sense with inheritance: You give in
|your base class a default function definition. Some classes (and normally
|not all) will redefine it (so N*M is the maximum but not the
|average ;-)
In which case the behavior C++ exhibits already represents that standard
case, and one then only needs to handle the exceptional cases.
|>It is not too hard to "design"
|>your own dispatch techniques in C++ if you don't like vtable dispatch.
|>Numerical precedence rules and dyn-casting are not a bad choice for
|>a lot of this stuff.
|
|But that is the problem: you can always say:
|"if we don't have feature X in C++ you can implement it somehow"
|(as operator. ;-)
People can always say this, but some people recognize the difference
in practicality between the various approaches: A "solution" that
maps an O(N) lines of programmer's code to an O(N) lines of programmer's
code is not terribly interesting. Whereas A "solution" that maps
O(N) [or O(N*M)] lines of programmer code to O(1) might be very interesting.
As Koenig among others have pointed out, it is possible to implement operator.()
functionality using a forwarding function per member function. Given N classes
with M members, this "only" takes N*M lines of code for someone to write and
try to maintain. As compared to one person one time implementing a
SmartReference template class given operator.()
So, the problem with multiple dispatch is that given it is *in* some
language, then how does one use it to reduce the amount of code that
people have to write? Unless there is some convenient and widely
applicable method of choosing the correct default method to invoke
for each [say] LHS and RHS, one still has to specify which function
to invoke in each case. In which case one might save a slight k factor
of effort not having to explicitly write the double [multiple] dispatch.
But just the effort of having to specify all those combinations of
functions would remain a daunting task....
So, my claim remains the real problem is not the multiple dispatch mechanism,
but rather the default-function-to-call mechanism. The solutions I've seen
to this second problem also solve the [IMHO much smaller] problem of
the underlying multiple dispatch mechanism, rendering that [sub-]problem
moot.
Tim Lister
>
>>In article <DOUG.92Ma...@monet.ads.com> do...@monet.ads.com (Doug Morgan) writes after reading something different than I wrote:
>>|I thought the argument was always: "C++ is an engineering compromise
>>|and is not designed to be all things to all people." Kind of a vague
>>|statement, I translate it as: "it seemed like a good idea at the time
>>|and it sure isn't going to change now."
>
>I read "engineering compromise" as being a really feeble excuse for
>the unacceptable. Basically, computers are useful tools, because
>they idealise the world.
No, computers are useful tools because I make my living
with them.
>You abstract away from the confusing
>details of the world. We are using the idealised world of digital
>systems. "Engineers" are used to dealing with imprecise analogue
>materials. In this domain they must compromise, eg build the bridge
>pier a bit thicker because there might be an earth quake. In software
>development though, you entirely control the world you are building.
This is only true if you write hex codes. As soon as you
write assembler (let alone C++) you are relying on OTHER people's
products. (Not to mention the hardware)
The real compromise is a human, not technical one. Technical
excellence will not necessarily ensure success. C++ is a compromise
because it is an upgrade from C. That is an advantage commercially.
Compatibility is what made IBM the giant that it was, even when
their systems were rubbish. It is why I have a decidedly inferior
CPU (486), instead of something nice (because everyone else has
and I have to make money).
>
>There are two factors that are more important than the above blinkered
>efficiency argument. Firstly, efficiency does not matter if the
>program is not correct, or it is unreliable.
No, this is backwards. Inefficient programs are totally
unusable. Incorrect programs might still be useable if you know
what their failings are. Just consider any operating system,
compiler, etc. All have faults, they are incorrect. But they still
get used and would be used in preference to a totally inefficient
but correct solution. There IS a trade-off--engineering compromise.
> Secondly, many products
>do not even hit the streets, because the project fails. The practicality
>of better approaches to software development is to have less project
>failures. Efficiency just isn't important if your product doesn't even
>hit the streets in the first place.
It is hard to disagree with this argument. None-the-less,
it is possible to work around flaws, and even if this is not
technically desirable, if the boss says portability NOW to
many systems is more important than correctness, well, e is paying
the wages...(one reason I'm my own boss is I hate this, but it happens)
>
>That C++ is based on C begs the question of do we want these 20 year old
>"engineering compromises" in modern software development.
Of course we don't. We want a 'perfect' language, or at
least something decent. But what? We HAVE to agree if there is to
be a major paradigm shift, otherwise the small improvements and
upward compatibility wins by default. Obtaining that consenus
is the real problem. People STILL write BASIC, FORTRAN, C and COBOL!
>There is also
>the misconception that C/C++ can be the only efficient way to implement
>software. There is nothing magic about C that makes it intrinsically 10
>times faster than anything else.
Yes there is. It trades standardisation, readability,
reliability, portability and other desirable attributes for efficiency,
pricipally by allowing types to be any convenient size, and providing
operators that correspond to machine instructions. That is important
if you are using it to write software for a microcontroller, and C
is used for that all the time. I write for microcontrollers,
and I usually write assembler for reasons of efficiency.
YOU try implementing a compiler for an 8 bit machine with 190 bytes
of RAM that's more efficient than my ugly hand written code.
Even 1 extra byte sometimes makes the difference. People use
these machines because they are cheap, only $10.
An inefficient solution is on these systems does not exist--
if you need 1 byte more than there is, or one clock cyclce more
time than there is, the system doesn't work, full stop.
Better that the lights go out every now and then when the micro
can't cope than not have the lights at all.
>There are cases of C++ vs
>Obj-C/Smalltalk, etc where this may be the case due to method dispatch,
>but we need to get away from the assertion that if you want it to be
>efficient then it must be written in C++.
Of course you can always write FORTRAN. <grin>
>
>And I agree, to hell with the esoteric mumbo jumbo stuff, give
>us something better than C++.
But what? I use C++ because I have a compiler for it, and
programs I write will port to Unix, Windows, and other systems,
and because it is fast, better than any other popular language,
and, because everyone else uses it which means competition and
thus product improvement.
>
>>|You followed a theme of "*all* C++ users want exactly such and such"
>>|that, from my viewpoint, is an overstatement. The overwhelming
>>|majority of the people I deal with here in the Twilight Zone (mostly
>>|various university, corporate, and government research organizations)
>>|really do want much more from C++. This Twilight Zone is small, but
>>|but not empty.
>
>Those who are starting to demand better, modern ways of doing things
>are not dreamers or academics out in the "Twilight Zone". We are
>people who recognise that there are better ways of doing things
>than C++.
Of course there are. Eiffel, for example, is probably better,
but it seems to have had a number of compromises added on because
the original 'pure' system just wasn't real-world. The same thing
happened to Prolog. Who is going to PAY for the new development,
and who is going to DECIDE what it is?
>--
>Ian Joyner ACSNet: i...@syacus.acus.oz
>ACUS (Australian Centre for Unisys Software) Internet: i...@syacus.acus.oz.au
>115-117 Wicks Rd, North Ryde, N.S.W, Australia 2113.
>Tel 61-2-390 1328 Fax 61-2-390 1391 UUCP: ...uunet!munnari!syacus.oz
IMHO, the whole idea of *a* language is wrong. The syntax should be
modifiable so you can CREATE a language suitable for your needs.
The compiler should be extensible---we need a good 'bootstrap' language,
but ultimately no language will be general purpose enough to suit
everyone.
Before we can have a decent language we need the right environment.
Unix isn't it. Why doesn't everyone change over to a much better
operating system (like, say Mach?). Because people are conservative,
and for good reasons (like cost, risk, etc---this is engineering
compromise. Engineers, I am comming to learn (from living with one)
are not principally concerned with the strength of materials in
bridges, but with purchasing the steel, organising quality control
systems, collating documents, repairing machines, dealing with
strikes, keeping the shop floor safe, getting money out of
the accountant, writing progress reports to the managing director...)
Academics should stop demanding better systems and write the damn
things themselves. Then they would realise just how hard it is,
and how unimportant (perhaps unfortunately) excellence
actually is in the scheme of things. Other constraints (like
collecting money and finishing the job by a deadline no matter
what else or you don't eat) tend to override the desire for
a perfect (or even excellent, indeed even good) program.
PS: basically, I agree with Ian's feelings, but experience has
taught me there are reasons why things aren't the way
I'd like them to be, and they have nothing to do with technical
excellence, and much more to do with engineering (read human) compromise.
I have learned to respect those skilled in these compromises,
because occasionally they manage to get some excellence into
things as well.
Eric Smith
>In article <1992May18.0...@syacus.acus.oz.au> i...@syacus.acus.oz.au (Ian Joyner) writes:
>
>> Those who are starting to demand better, modern ways of doing things
>> are not dreamers or academics out in the "Twilight Zone". We are
>> people who recognise that there are better ways of doing things
>> than C++.
>
>It makes sense to talk about `better' only after supplying a context.
>Which tool is better, a hammer or screwdriver?
Suppose your job is to do carpentry repair in high places that require
a lot of climbing, and suppose you find a screwdriver much easier to
carry than a hammer. Wouldn't it make sense to adapt the context to the
tool by using screws instead of nails? Actually, that isn't a good
example of what I mean, because a lot of such climbing repair people
carry hammers in their toolbelts, but my point should be fairly clear.
>
>Every language I have ever seen does some things particularly well
>and others particularly badly. It behooves us all, as professionals,
>to choose the tools most appropriate for the context, which includes
>the application itself, the biases of the users, and the surrounding
>community.
>
>Do not, however, make the mistake of believing that your particular
>context is universal.
>-- > --Andrew Koenig
> a...@europa.att.com
It's true that we should choose the most appropriate tools, but we should
also take into account the cost of using a large variety of tools. If
we can adapt fewer tools to more purposes, we might be able to reduce the
costs more than enough to outweigh the benefits of always having the best
tool for a specific job.
Programming languages are heavy. Learning C++ takes more effort than
hauling tons of bricks. Each additional language adds more weight.
You have to keep all the compilers handy, port them to different
platforms as needed, and reimplement general purpose class libraries in
each language. Each language has its own newsgroups, its own books
and magazines, its own user community, etc.
Why can't we design one programming language that does everything well
and nothing badly?
David (Lujun) Shang
(Don C. Hancock) writes:
> Thanks for all the help I received. Special thanks goes to
> Rick Taft (who gets the door prize) who provided the first
> solution that worked. To summarize, the following provides
> "virtualness" for two parameters. The only odd part is that the
> call dp_tig->foo(dp_lad) gets resolved at runtime to
> lady::foo(tiger *), which is backwards, but I can live with that.
>
> ------SAMPLE CODE---------
>
> class tiger;
> class lady;
>
> class door_prize {
> public:
> virtual void foo(door_prize *) = 0;
> virtual void foo(tiger *) = 0;
> virtual void foo(lady *) = 0;
> virtual void bar() = 0;
> };
>
> class tiger : public door_prize {
> public:
> void foo(door_prize * dp) {
> dp -> foo(this);
> }
> void foo(tiger *) {}
> void foo(lady *) {}
> void bar() {}
> };
>
> class lady : public door_prize {
> public:
> void foo(door_prize * dp) {
> dp -> foo(this);
> }
> void foo(tiger *) {}
> void foo(lady *) {}
> void bar() {}
> };
>
> void main() {
> tiger kahn;
> lady michele;
> door_prize *dp_tig, *dp_lad;
>
> dp_tig = &kahn;
> dp_tig->bar(); // calls tiger::bar();
> dp_lad = &michele;
> dp_lad->bar(); // calls lady::bar();
>
>
> dp_tig->foo(dp_lad); // calls lady::foo(tiger *);
> dp_lad->foo(dp_tig); // calls tiger::foo(lady *);
> }
It is not reasonalbe to require all the derived classes being listed
before a base class is specified. The above code can be simplified as:
class door_prize {
public:
virtual void foo(door_prize * dp) { dp->foo (this); };
};
class tiger : public door_prize {
public:
void foo (door_prize * dp) { printf ("This is tiger\n"); };
};
class lady : public door_prize {
public:
void foo (door_prize * dp) { printf ("This is lady\n"); };
};
void main() {
tiger kahn;
lady michele;
door_prize *dp;
dp = &kahn;
dp->door_prize::foo(&michele); // calls lady::foo(tiger *);
dp = &michele;
dp->door_prize::foo(&kahn); // calls tiger::foo(lady *);
}
David Shang
Systems Software Research Lab.
Motorola Inc.
Andrew Koenig
> Suppose your job is to do carpentry repair in high places that require
> a lot of climbing, and suppose you find a screwdriver much easier to
> carry than a hammer. Wouldn't it make sense to adapt the context to the
> tool by using screws instead of nails? Actually, that isn't a good
> example of what I mean, because a lot of such climbing repair people
> carry hammers in their toolbelts, but my point should be fairly clear.
So far, I think we are in agreement -- decisions about tools must
take context into account.
As another example, we had a room added onto our house a couple of
years ago. The guy who did most of the construction used a power
screwdriver (that looked like an electric drill but ran much more
slowly) and a power nailer that ran off compressed air. I'm sure those
tools have saved him a whole lot of time in that particular context,
even though I would never consider buying them myself for the tiny
amount of use I would give them.
> It's true that we should choose the most appropriate tools, but we should
> also take into account the cost of using a large variety of tools. If
> we can adapt fewer tools to more purposes, we might be able to reduce the
> costs more than enough to outweigh the benefits of always having the best
> tool for a specific job.
Again, I think we are in complete agreement -- the cost of using a large
variety of tools is part of the context. Suppose, for instance, you
are managing a large software project that has been going for five
years, turning out a new release a year in response to customer
requests. Suppose further that that project is in C and you would
like to try to move it towards a higher level of abstraction.
Realistically, you can't abandon your existing C code. Your choices
are therefore to recast it into C++ without changing it immediately,
and then gradually redesign it a piece at a time using C++ or to do
nothing and wait for something else to come along. You can't afford
to stop and rewrite everything from scratch in some other language,
because your customers won't sit still and wait for it.
Maybe you can start rewriting parts of it in some other language, but
then you need to make sure that that language interfaces flawlessly
with your existing C code -- and there aren't many languages around
that do such a great job of that.
As I said, context often heavily influences your choice of tools.
> Programming languages are heavy. Learning C++ takes more effort than
> hauling tons of bricks. Each additional language adds more weight.
> You have to keep all the compilers handy, port them to different
> platforms as needed, and reimplement general purpose class libraries in
> each language. Each language has its own newsgroups, its own books
> and magazines, its own user community, etc.
No argument there.
> Why can't we design one programming language that does everything well
> and nothing badly?
Well, for one thing, people don't always agree on the meaning of `well.'
You might have a look at comp.lang.functional, where the present debate
is whether strong typing is intrinsically good or evil -- completely
independent of any efficiency arguments. If we can't get people to agree
on something as fundamental as that, why do you think people will agree
when a language is doing something `well' or `badly?'
--
--Andrew Koenig
a...@europa.att.com
Ian Joyner
>In article <1992May18.0...@syacus.acus.oz.au> i...@syacus.acus.oz.au (Ian Joyner) writes:
>> Those who are starting to demand better, modern ways of doing things
>> are not dreamers or academics out in the "Twilight Zone". We are
>> people who recognise that there are better ways of doing things
>> than C++.
>It makes sense to talk about `better' only after supplying a context.
>Which tool is better, a hammer or screwdriver?
Well it also helps to interpret remarks in the context of the discussion.
I will clarify my above remark by saying I am comparing two hammers.
A craftsman will look at two hammers, and consider their weight, balance,
striking accuracy, and then choose the best tool. It's a shame we can't
do that when it comes to programming languages.
>Every language I have ever seen does some things particularly well
>and others particularly badly. It behooves us all, as professionals,
>to choose the tools most appropriate for the context, which includes
>the application itself, the biases of the users, and the surrounding
>community.
>Do not, however, make the mistake of believing that your particular
>context is universal.
That is why I am trying to dissuade people that C/C++ is a universal
context. It is about time we realised that to achieve the same effect,
we need better tools than C++.
Andrew Koenig
> Well it also helps to interpret remarks in the context of the discussion.
> I will clarify my above remark by saying I am comparing two hammers.
> A craftsman will look at two hammers, and consider their weight, balance,
> striking accuracy, and then choose the best tool. It's a shame we can't
> do that when it comes to programming languages.
Speak for youself :-)
Seriously, do you think NOBODY makes an effort to pick the best language
for a context? Seems implausible, to say the least. Or are you complaining
that SOME PEOPLE don't make the effort? If so, what did you expect?
That everyone should have perfect judgment all the time?
My experience has been that most people behave at least somewhat rationally
most of the time -- even when it is hard to understand their motivations
at first glance. If a whole bunch of people use a tool and continue to
use it, then it is doing something for at least some of them. They're
not all blind, or misled, or zombies.
> That is why I am trying to dissuade people that C/C++ is a universal
> context. It is about time we realised that to achieve the same effect,
> we need better tools than C++.
There you go, ignoring context again. Better tools FOR WHAT? The contexts
in which languages are useful are at least as different as the contexts that
are appropriate for hammers vs. screwdrivers, except possibly for languages
that are very similar such as Classic C and ISO C. Even there, judgment has
to be contextual, based for example on what compilers are available for the
particular machine one wishes to use.
Let me suggest an exercise. How about imagining a context in which C++ is
clearly the best possible choice and telling us what it is and why. If you
can't do that, it suggests that your background is so completely different
from most of the people on this newsgroup that it is hard to see a common
basis for discussion.
--
--Andrew Koenig
a...@europa.att.com
Bjarne Stroustrup
Ian Joyner (i...@syacus.acus.oz) writes
> I read "engineering compromise" as being a really feeble excuse for
> the unacceptable. Basically, computers are useful tools, because
> they idealise the world. You abstract away from the confusing
> details of the world. We are using the idealised world of digital
> systems. "Engineers" are used to dealing with imprecise analogue
> materials. In this domain they must compromise, eg build the bridge
> pier a bit thicker because there might be an earth quake. In software
> development though, you entirely control the world you are building.
...
> If I hear this engineering compromise rubbish much more, I swear I am going
> to scream.
...
> There are two factors that are more important than the above blinkered
> efficiency argument. Firstly, efficiency does not matter if the
> program is not correct, or it is unreliable. Secondly, many products
> do not even hit the streets, because the project fails.
...
> That C++ is based on C begs the question of do we want these 20 year old
> "engineering compromises" in modern software development.
...
> to hell with the esoteric mumbo jumbo stuff, give
> us something better than C++.
...
> Those who are starting to demand better, modern ways of doing things
> are not dreamers or academics out in the "Twilight Zone". We are
> people who recognise that there are better ways of doing things
> than C++.
Who are "we?" and why don't you just do it (the "better ways of doing things")
rather than posting repetitive tirades against C++? It takes much more than
screams and personal opinions and conjectures disguised as homebrew "principles"
to improve the state of software development.
Like all the other programming languages and systems, C++ is one part of a larger
picture of software development. C++ plays an imporant part represents a major
step forward compared to most languages in current wide use. Naturally, it is
not the last step, but it is the best choice - the best compromise - for large
groups of people today. Maybe it is not the best choice for Joyner? So what?
As I and others have said often enough: C++ isn't perfect and no single language
can serve all needs. C++ has, however, often proved more adequate than languages
and systems for which much more inflated claims were made.
Compromises are necessary. When the a compromise is made after careful examination
of the logic involved, the physical constraints, the actual practice, experiments,
etc., I call that an engineering compromise to distinguish it from a political
compromise. Naturally, nobody gets the compromises right every time and not every
compromise (or lack of compromise) can please everybody. When a compromise is made
for C++ is usually made to allow alternative ways of doing things rather than to
force a supposedly superior solutions on everybody. This seems to infuriate
idealists/purists who thinks they have the "one right answer" and consider it
their right (duty?) to prevent others from making different choices. Compromises
are necessary for co-existence of people with differing opinions.
Efficiency often matters. Projects have failed due to lack of attention to efficiency.
So have projects that indulged in premature optimization at the cost of overall
design. Some of the most beautiful systems I have seen or heard about ended up
as pitiful failures because their performance were better measured with a calendar
than with a stop watch. Others failed because the programmers kept finding better
"principles" to follow and thus never completed. "The best is the enemy of the good"
is a proverb well woth remembering. It is usefully applied to structure as well as
to efficiency.
C++ is significantly more efficient (sometimes even the factor 10 Joyner mentions)
that most langauges providing comparable abstraction facilities because it provides
mechanisms that allow programmers to make tradeoffs between generality and efficiency.
If you can only express generality (and very low coupling) you will get very poor
efficiency in the absense of "advanced optimization technology." Such technology
is usually absent or not very advanced - have a look at the Self project to see
what it takes to make a dynamically typed language perform. C++ was deliberately
designed to yield such performance in the absence of smart compilers and to give
traditional optimizers a good starting point.
The point is sometimes made - usually reasonably politely - that programmers are
too stupid to be given a choice. My opinion is that within very wide bounds people
grow and decline to meet expectation. The choices offered by C++ are manageable by
many and the rest will find other tools or other things to do. Some will choose to
do things "the bad old way" but most progress to adopt newer techniques - where
applicable - in time. Naturally, the transition to data abstraction and
object-oriented programming will only occur where suitable educational material
is available and only if the techniques recommended actually makes sense to the
programmers for their work. Simply standing on a soap box vermently demanding
that people abandon all their evil vices immediately isn't going to work very
reliably. Typically, programmers and designers demand some form of emperical
evidence before making a significant change. Unsupported personal opinion - even
when cloaked in impressive terminology - is insufficient to convince the more
experienced. Seeing hype meet reality have made sceptics of most of us. I consider
that healthy.
Programming, language design, system design, etc., is - ideally - engineering
disciplines; not mathematics. The end results are working systems with constraints,
tolerances, limited useful lives, failure modes, changing requirements, etc.; not
proofs or objects of abstract beauty. A system may be beautiful, but given a choice
between beauty and utility we must - as systems builders - prefer utility.
Also, programming languages are tools in the real world. A nice reference manual
by itself is of little use to a programmer.
EVERY successful major system is the result of an evolutionary process. If you
have something that looks like a contradiction to this principle (which I consider
one of the few real principles in this area), look again. It is probably a third
or fourth redesign. EVERY language goes through years of evolution before it meets
the needs of more than a small group of dedicated followers. This is true for every
language you could consider in the context of a major software project. Often, the
reason for a major failure or for a new language or system being rejected by an
organization is exactly that a new language has not been sufficiently used and
re-designed for its original "principles" and aims to be sufficiently modified
to fit real needs.
By the time a language becomes useful on a large scale is it usually more than a
decade old. This implies that there will be no shortage of people decrying its lack
of adherence to the latest fads, lack of the most advanced features, and imperfect
match to the latest understanding of techniques. This is necessary.
Transitions are important. We rarely have the luxury of starting from scratch and when
we do the results are not necessarily good. C++ carries the scars of its evolution and
those of the evolution of C. This can be infuriating. However, not all flaws are major
and not every inconvenience is significant. The basic structure of C++ is sound and
coherent. The language is a viable tool for many and often superior in real use to
every alternative. Because C++ supports a range of techniques - stretching from
traditional C styles, through data abstraction, to OOP techniques - it provides a path
for people to absorb the new ideas gradually and staying productive while they learn.
This works (to the disgust of of would-be revolutionaries), and is often essential
for people and organizations who cannot afford to stay unproductive for any considerable
length of time. This gradual approach takes time, but so does every other approach.
No approach is perfect for everyone or for every organization, but I think it essential
to offer a choice in this matter also.
There is a place for languages that break with tradition and (sometimes) deliver
spectacular results to a dedicated following in an application area. There is also
a place for languages, such as C++, that make facilities based on experience
learned from such languages accessible (this implies affordable) to main-stream
programmers. The world of programming is much larger and more diverse than most
people suspect. Even C and C++ cover only a small part of the total range of
applications.
For a more thourough exposition of some of these ideas and how they relate to C++ please
have a look at chapters 11, 12, and 13 of "The C++ Programming Language (2nd edition)."
PS My opinion in a nutshell:
Programming is engineering - not mathematics.
A language should offer choice - not coercion.
Efficiency is important - and a matter of design.
Good systems are grown - not just designed from first principles.
Transition is important - and very difficult.
People do learn - encourage them, don't force them, don't patronize them.
Ian Joyner
>In article <1992May18....@tfs.com> er...@tfs.com (Eric Smith) writes:
>> Suppose your job is to do carpentry repair in high places that require
>> a lot of climbing, and suppose you find a screwdriver much easier to
>> carry than a hammer. Wouldn't it make sense to adapt the context to the
>> tool by using screws instead of nails? Actually, that isn't a good
>> example of what I mean, because a lot of such climbing repair people
>> carry hammers in their toolbelts, but my point should be fairly clear.
>So far, I think we are in agreement -- decisions about tools must
>take context into account.
Ah, but this is getting off the track again. What I am talking about is
making the correct choice between tools that perform the SAME function.
There is an old adage that a bad workman always blames his tools.
However, this is balanced by the fact that a good craftsman will choose
quality tools to do the job, and then maintain that quality. So when
buying a screwdriver, he will look for one that has a square edge so it
does not slip out of the screw head, and one that has a comfortable
grip, and one that is made out of hard steel, so it does not loose
its edge. Screwdrivers of inferior quality he will leave on the shelf.
You are saying we are comparing apples and oranges, but my statements
relate to the comparison of apples and apples.
Why then is it that we do not have this standard of craftsmanship when
we choose programming language tools.
>Realistically, you can't abandon your existing C code. Your choices
>are therefore to recast it into C++ without changing it immediately,
>and then gradually redesign it a piece at a time using C++ or to do
>nothing and wait for something else to come along. You can't afford
>to stop and rewrite everything from scratch in some other language,
>because your customers won't sit still and wait for it.
In my experience, most C 'code' (and I use 'code' in its unreadable sense
here) is poorly written, and deserves to be tossed out. This in fact
fits with the early philosophy of Unix and C that instead of maintaining
code, throw it out and start again. So why has this suddenly changed? C
was not meant to be a language in which maintainable 'source' was written.
Throw it out start again!
Now I am talking of Apples and Oranges. Since C was not designed for
developing maintainable 'program text', then that suggests that C
is not the correct tool for the job that is now required. This has
been a fundamental change since C was developed over 20 years ago,
when systems were small and simple.
>> Programming languages are heavy. Learning C++ takes more effort than
>> hauling tons of bricks. Each additional language adds more weight.
>> You have to keep all the compilers handy, port them to different
>> platforms as needed, and reimplement general purpose class libraries in
>> each language. Each language has its own newsgroups, its own books
>> and magazines, its own user community, etc.
>No argument there.
But programming languages *needn't* be heavy and clumsy. A true professional
should be able to adapt between tools. Since learning C++ takes such effort,
I would rather forget it, and use something that is more reasonable. A
difficult to learn language will mean that I make even more mistakes in
program development.
>> Why can't we design one programming language that does everything well
>> and nothing badly?
>Well, for one thing, people don't always agree on the meaning of `well.'
>You might have a look at comp.lang.functional, where the present debate
>is whether strong typing is intrinsically good or evil -- completely
>independent of any efficiency arguments. If we can't get people to agree
>on something as fundamental as that, why do you think people will agree
>when a language is doing something `well' or `badly?'
Well C++ certainly seems to be a language that tries to do everything,
but it does most of it badly.
Edward Klimas
In a previous article, max...@extro.ucc.su.OZ.AU (Tim Lister) says:
>In article <1992May14.1...@neptune.inf.ethz.ch> smis...@iiic.ethz.ch (Stephan Albert Missura) writes:
>>In article <1992May9.1...@ucc.su.OZ.AU> max...@extro.ucc.su.OZ.AU (Tim Lister) writes:
>>>[...]
>>> A language with multiple dispatch, in my view, is more than
>>>object oriented.
>>>[...]
>>
>>I think that a language *without* multi-dispatch is not a real
>>object oriented language. how can we implement a generic
>>equality relation (a==b) only with single-dispatch?
>>(double-dispatch would be a solution but I don't think
>>that implementing this is the programmer's job!)
>>
>>stephan
>>
> You cant. (implement ==).
> That is the point: OO is just a first step in the right
> direction. As soon as you have 'multiple dispatch'
> it no longer makes sense to dispatch from one object
> or the other.
>
> So such a facility is theoretically beyond Object Orientation.
> It requires totally new concepts, OO is simply inadequate.
Double dispatching has been easily achieved in pure OOP languages.
For examples of how to do it see
Ingalls, D. "A Simple Technique For Handling Multiple
Polymorphism", Proc of OOPSLA '86 Portland Or. 86
&
"Tips for Improved Smalltalk Reuse and Reliability",
The Smalltalk Report Vol. 1. No. 6 March/April 92
Ed Klimas
Linea Engineering
Mark Mullin
>In article <DOUG.92Ma...@monet.ads.com> do...@monet.ads.com (Doug Morgan) writes:
>|In article <1992May14.1...@microsoft.com> ji...@microsoft.com (Jim ADCOCK) writes:
>| [... C++ is great for and restricted to commercial SW
>| development...]
Since such stress seems to be laid on real world programmers (I believe
defined as those who ship product into mass distribution channels
based on a schedule developed by some idiot in marketing) and I am
certainly one of those, I couldn't resist adding 2c.
First, I do wish the ANSI standard committee would hold up a little
better to the (most likely unpleasant) pressure being exterted by
commercial developers. I'd settle for a little less functionality
(well, at least *supported* functionality) at the expense of knowing
ANSI isn't going to be issuing a stream of *clarifications*, eg: Of
course inlines are a suggestion to the compiler, after all you can't
have a virtual inline, now can you (visions of chickens and eggs).
I realize being on such committees can be a serious drag and all that,
and I'm glad they are doing something, but sometimes something looks
suspiciously like a three ring circus.
Secondly, *everybody* is interested in fast code, given the choice. What
commercial developers want is fast *construction* of code. I know
commercial apps that can take hours to link in debug form, and days to
compile that way. Programmers waiting for compilers and linkers are
not productive programmers, too often they're reading 2600 :-)
The *real* issue is class libraries. The ANSI committee has paid
very little attention to the standardizations of elements of the
class libraries, therefore a regular horde of them now populate
the etherwaves, both from compiler vendors and third parties. It is
the presence of the class library that has the dramatic impacts on
both training and productivity costs, extremely negatively in the
short term and extremely positively in the long term. It is the
presence of the class library that causes compilers and linkers
hours to chew their way through "supposedly" trivial applications.
In short, commercial developers depend on organizations such as ANSI
to ensure we can leverage off of the communities shared technical
experiance, by ensuring we all share the same means for defining
concepts and operations. We are being bitten twice at this point,
first when we learn techniques that we later learn are incorrect,
and secondly when the vast majority of the data we learn is not
standard, but part of some proprietary architecture.
Oh, well. If the truth be told, I wouldn't fiddle to much with the
situation either. Much worse things could be happening. Every once
in a while I think this all starts to sound an awful lot like AI
in the 80's
MMM
Ian Joyner
>In article <1992May18.0...@syacus.acus.oz.au> i...@syacus.acus.oz.au (Ian Joyner) writes:
>>I read "engineering compromise" as being a really feeble excuse for
>>the unacceptable. Basically, computers are useful tools, because
>>they idealise the world.
> No, computers are useful tools because I make my living
>with them.
That is true, but this also illustrates that projects that fail don't
earn you a living. This is why, as demands of software systems are getting
more complex, that the job isn't getting easier. The traditional
approaches to software development have had enough failures in the
past, so how are we going to cope with the future?
>>If we don't, computers become a far less useful tool. I suggest re-reading
>>the first chapter of Dijkstra's Discipline of Programming, on the role
>>of programming languages. Basically, this explains why such compromises
>>result in tools and languages which are less useful.
>>
>>>...
>>
>>If I hear this engineering compromise rubbish much more, I swear I am going
>>to scream.
>
>...
>
>>
>>There are two factors that are more important than the above blinkered
>>efficiency argument. Firstly, efficiency does not matter if the
>>program is not correct, or it is unreliable.
> No, this is backwards. Inefficient programs are totally
>unusable. Incorrect programs might still be useable if you know
>what their failings are.
No, it is not backwards, you are quoting the extreme, not the norm. If
I ask a program to do a calculation, I am not too worried about the
fact that it takes 4 seconds rather than 2. It does worry me
though when the program crashes and reports -segmentation fault,
core dumped, and I get no answer at all. Usually, what the efficiency
debate means is saving a few milliseconds here and there. Who cares?
Machine cycles are cheap these days. However, that does not mean
that I think efficiency is not important at all. In fact choosing a
development environment where I can see the wood for the trees will
help produce more efficient systems, as it is usually algorithmic
efficiency that counts, not raw low level efficiency. If you can spot
the 10,000 time loop that is not needed, that far outweighs a few
measily machine cycles.
Finally, it is more important to get the program into the customer's hands,
rather than expend the effort trying to squeeze a few extra milliseconds.
How do you tell a customer, that the program will not be ready for another
six months, we are just optimising some more milleseconds for you. When
he asks how much more that is going to cost, and you say $100,000, he says
forget it, I'll buy another 5 processors for that. Or worse still perhaps
he is not paying, so isn't it better to hand over the product and the bill?
If the program doesn't work, he is far more likely to complain, than if
it runs (perhaps unoticeably) slower.
>An inefficient solution is on these systems does not exist--
>if you need 1 byte more than there is, or one clock cyclce more
>time than there is, the system doesn't work, full stop.
>Better that the lights go out every now and then when the micro
>can't cope than not have the lights at all.
Again this level of development on micro processors is an exception,
not the norm. But even now, powerful micros, and memory are so
cheap, that it does not make much difference, and this will continue
to be the trend in the future.
>>There are cases of C++ vs
>>Obj-C/Smalltalk, etc where this may be the case due to method dispatch,
>>but we need to get away from the assertion that if you want it to be
>>efficient then it must be written in C++.
>Before we can have a decent language we need the right environment.
>Unix isn't it. Why doesn't everyone change over to a much better
>operating system (like, say Mach?). Because people are conservative,
>and for good reasons (like cost, risk, etc---this is engineering
>compromise.
OK, I warned you... SCREAM :-).
Well, there is a correct time and place for compromise and trade-off,
and of course you must do it when developing a balanced design. So
I do not really take exception to your use of compromise as above.
The 'engineering' part I am not so sure about, because I am not so
sure that software development is an act of 'engineering'. Just the
term 'engineering' seems to appeal to those who dislike quiche-eating
wimps who program in Pascal ;-)
However, I do think the term 'engineering compromise' is a feeble
excuse for the flaws of C++, and it is its use in this context that
makes me feel I want to scream.
>PS: basically, I agree with Ian's feelings, but experience has
>taught me there are reasons why things aren't the way
>I'd like them to be, and they have nothing to do with technical
>excellence, and much more to do with engineering (read human) compromise.
>I have learned to respect those skilled in these compromises,
>because occasionally they manage to get some excellence into
>things as well.
Well, I glad we are almost back together on this one, our views seem
to digress on a few small points perhaps?
>;----------------------------------------------------------------------
> JOHN (MAX) SKALLER, max...@extro.ucc.su.oz.au
> Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
>;-----------------------------------------------------------------------
Eric Smith
>> and nothing badly?
>
>Well, for one thing, people don't always agree on the meaning of `well.'
>You might have a look at comp.lang.functional, where the present debate
>is whether strong typing is intrinsically good or evil -- completely
>independent of any efficiency arguments. If we can't get people to agree
>on something as fundamental as that, why do you think people will agree
>when a language is doing something `well' or `badly?'
>--
> --Andrew Koenig
> a...@europa.att.com
A big part of that debate seems to have been caused by confusion
between dynamic typing and weak typing. In any case, my unified
programming language should support both static and dynamic typing,
because both are very desirable, and they won't necessarily interfere
with each other, if the language is designed for them to cooperate.
Furthermore, everyone doesn't have to agree on the meaning of `well.'
To meet my requirement we only have to find any reasonably large group
of knowledgeable, reasonable people who agree that the language does
everything well and nothing badly. There will always be people to find
fault with such a language, but I want the language to be able to
withstand their arguments, such that you can find reasonable people who
understand both sides of each argument and still agree that the
language is right or the fault is not important. Present programming
languages don't meet that requirement.
Barry Margolin
>First, I do wish the ANSI standard committee would hold up a little
>better to the (most likely unpleasant) pressure being exterted by
>commercial developers.
The ANSI standardization process is a democracy. If you feel your needs
aren't being addressed, join the committee. If the failings of the ANSI
standard are likely to cost you money, then the expenses of membership (a
couple hundred dollars a year in dues, plus travel costs to attend
meetings) should be considered an investment towards preventing this. If
you don't join, then it ends up being a representative democracy, and it
doesn't work much better than the governments we have.
And even if you can't join, complain to the right people. Treating it as a
representative democracy, your representatives are your vendors. Tell them
the direction you want the standard to go in, and make it worth their
while; vote with your wallet by telling them how many more copies of their
product you'll buy if the standard goes your way. (Actually, this is an
ideal -- in reality, standards committee members are technical people,
pretty far removed from the sales people.)
>The *real* issue is class libraries. The ANSI committee has paid
>very little attention to the standardizations of elements of the
>class libraries, therefore a regular horde of them now populate
>the etherwaves, both from compiler vendors and third parties.
Given the proliferation of these class libraries, it doesn't seem like
there's enough concensus on the right design to make standardization
appropriate at this time. It's usually better for the ANSI committee to
wait for things to settle down and then adopt the de facto standard
(perhaps enhancing it to incorporate good ideas from the "losers").
--
Barry Margolin
System Manager, Thinking Machines Corp.
bar...@think.com {uunet,harvard}!think!barmar
Tim Lister
>
>Well C++ certainly seems to be a language that tries to do everything,
>but it does most of it badly.
>--
>Ian Joyner ACSNet: i...@syacus.acus.oz
GIVEN the constraint of compatibility with C, I think
Bjarne did quite a good job myself. And that compatibility
is really important to lots of people. I *personally* would
rather use a really good modern designed from scratch language,
but then I love learning new languages and reading technical
manuals. Most programmers (and their bosses) just want to
get on with the job with tools they are familiar with.
Look at the Ada fiasco, these people tried really
hard to design a good language, but it never achieved the
market penetration required for commercial success.
C++ started out with a big advantage---every C programmer
in the world could already write C++, and most C++ compilers
can be used as C compilers.
--
David S. Masterson
> My experience has been that most people behave at least somewhat rationally
> most of the time -- even when it is hard to understand their motivations
> at first glance. If a whole bunch of people use a tool and continue to
> use it, then it is doing something for at least some of them. They're
> not all blind, or misled, or zombies.
Quite true -- to a point. I've found that most people (in the non-research
development area) tend mostly to use the best tool or the tool they're most
used to from amongst the tools that they have locally. If they have to expend
effort to find *the* best tool, then they settle for a lesser tool.
--
====================================================================
David Masterson Consilium, Inc.
(415) 691-6311 640 Clyde Ct.
uunet!cimshop!davidm Mtn. View, CA 94043
====================================================================
Tim Lister
>In article <19...@nic.cerf.net> mul...@nic.cerf.net (Mark Mullin) writes:
>>First, I do wish the ANSI standard committee would hold up a little
>>better to the (most likely unpleasant) pressure being exterted by
>>commercial developers.
>
>The ANSI standardization process is a democracy. If you feel your needs
>aren't being addressed, join the committee. If the failings of the ANSI
>standard are likely to cost you money, then the expenses of membership (a
>couple hundred dollars a year in dues, plus travel costs to attend
>meetings) should be considered an investment towards preventing this. If
You put those travel costs in like an afterthought. I live
in Australia. Travel costs would be say 3x$2000=$6000 per year.
E-Mail is much cheaper ...
Mark Mullin
when people have a lot of money on the table, which is definitely
the case with todays vendors. An interesting analog to the issue
of representative democracy versus vested interests is playing out
every day on CNN :-)
MMM
Ian Joyner
> GIVEN the constraint of compatibility with C, I think
>Bjarne did quite a good job myself.
You may be correct there. I do not want to denigrate anyones work
personally. There is far too much malice in this industry. This does
not mean that there is not a place for fair and reasoned criticism. If
you are in the place that Bjarne is, perhaps you have to take it. He
must also have to take a lot of the anger that has built up over the
years as a reaction against the arrogance and bigotry that is common in
the C community. He is in a difficult situation, as he must see that
his efforts have been directed at something that is becoming a
historical dinosaur. Still if you are Frankenstein, you have to learn
to live with your monster.
It is time to assess how much further it is worth taking the C
experiment. The technology it made compromises for is now well over 20
years old. It is now not really applicable anymore, or at least in five
to ten years will not be. It is now looking old and tired like FORTRAN,
and it is time to seriously consider the future and alternatives.
Perhaps indeed we can encourage Bjarne to realise this, make the break
and use his expertise, and what he has learnt to create something
better. But I think that means a journey that leads quite a distance
away from C. Perhaps this may mean a denial of some ego as well.
> C++ started out with a big advantage---every C programmer
>in the world could already write C++, and most C++ compilers
>can be used as C compilers.
And as Bjarne himself has admitted, that is its biggest disadvantage.
--
Ian Joyner ACSNet: i...@syacus.acus.oz
Ian Joyner
>Ian Joyner (i...@syacus.acus.oz) writes
> > Those who are starting to demand better, modern ways of doing things
> > are not dreamers or academics out in the "Twilight Zone". We are
> > people who recognise that there are better ways of doing things
> > than C++.
>Who are "we?" and why don't you just do it (the "better ways of doing things")
Well, there are people 'doing it'. But they have a tough time making headway
against the closed mindedness of the C community. I by the way am not
'doing it', as if you cast your mind back a few months, you accused anyone
who criticised C++ of either ignorance, or being 'commercial sleezballs',
pushing their own interests. Well, I wrote my critique to show that C++
could be criticised fairly, not out of just ignorance or malice, and
having no connections with any other product, you cannot accuse me of
being a 'commercial sleezeball'.
>rather than posting repetitive tirades against C++?
"Tirades" is a very emotional word, as much criticism of C++ is well
reasoned. But are you really surprised at the "tirades"? C++ has many
faults, which you yourself admit, especially in the ARM. Do you really
consider that warnings of such potential disasters in the ARM can
be counted as good language definition? Perhaps, in all honesty, to
remain compatible with C, this is necessary, but it suggests one thing,
that C should just go away to die. Perhaps you should consider the tirades
of the C community against everything else, Pascal, Ada, Eiffel, etc.
Is the C community so scared of a little variety in the industry? As you
sow, so shall you reap.
>It takes much more than
>screams and personal opinions and conjectures disguised as homebrew "principles"
>to improve the state of software development.
What screams? What personal opinions? If you read my critique you will
find it is based on some widely accepted principles, and some "homebrew"
principles of Edsgar Dijkstra. But then I give more credence to his
homebrews, than many widely accepted principles. Perhaps the ANSI
standards committee may consider some of the suggestions in the critique
to improve C++. However, I think C provides really limited scope here.
>Like all the other programming languages and systems, C++ is one part of a larger
>picture of software development. C++ plays an imporant part represents a major
>step forward compared to most languages in current wide use. Naturally, it is
>not the last step, but it is the best choice - the best compromise - for large
>groups of people today.
Large groups of people are not given a choice. Things only change when there
is a large ground swell of opinion, not because of choice.
>Maybe it is not the best choice for Joyner? So what?
The so what? Bjarne, is that Joyner is a practical every day programmer,
working at the coal face. He just realises, that we are getting to the
stage, where systems are getting so complex, that the old C/C++ techniques
can no longer deal with the difficulty of the job. To be successful at
the creation of such complex systems, we need to be super organised, and
C does not provide an appropriate basis. I can do without having to track
down low level pointer errors. I don't like discipline, but we have to be
more disciplined.
Perhaps Joyner is further out in front of the programming field than most
having been involved in the complexities of music notation processors, and
X.500, among others. C++ is just too error prone to realise these kinds
of systems economically.
>Compromises are necessary. When the a compromise is made after careful examination
>of the logic involved, the physical constraints, the actual practice, experiments,
>etc., I call that an engineering compromise to distinguish it from a political
>compromise. Naturally, nobody gets the compromises right every time and not every
>compromise (or lack of compromise) can please everybody. When a compromise is made
>for C++ is usually made to allow alternative ways of doing things rather than to
>force a supposedly superior solutions on everybody.
Isn't this more noble than forcing a known inferior solution on everybody?
>This seems to infuriate
>idealists/purists who thinks they have the "one right answer" and consider it
>their right (duty?) to prevent others from making different choices. Compromises
>are necessary for co-existence of people with differing opinions.
But this is your 'political compromise'. C++ has gone beyond compromise. It has
moved into the area of being "compromised."
>Efficiency often matters. Projects have failed due to lack of attention to efficiency.
Let us say that projects fail due to 'lack of attention' (full stop). Most
fail due to non-technical reasons. Less often they fail due to technical
reasons, and a minority of those technical reasons is efficiency. Let's
put efficiency into the right perspective. It is often out of proportion,
especially in the C world. If efficiency is C's main consideration, then
it realistically is applicable to a much smaller market than it has. I will
not deny that need exists, but it does not address the correct issues that
need to be addressed for large scale, complex software development.
>So have projects that indulged in premature optimization at the cost of overall
>design. Some of the most beautiful systems I have seen or heard about ended up
>as pitiful failures because their performance were better measured with a calendar
>than with a stop watch.
Let's not draw the mistaken conclusion that elegant and beautiful systems are
slow, and ugly and dirty systems are fast. In fact in reality, more often than
not, the reverse is true. Do not base arguments on the minority of counter-
examples.
Those who think and work in an orderly, disciplined, organised and elegant
manner more often achieve efficiency than those that don't. (I am not
talking about the kind of person that has a tidy desk by the way, you should
see mine :-), or about those who draw beautiful, but meaningless structure
charts.)
Efficiency does not equate to quality. But often becuase efficiency is a
measurable thing, those that lack intrinsic discernment of quality resort
to that which they can measure. Such demands often result in such bogus
metrics as MIPS ratings. But it makes the number crunchers who lack
imagination feel comfortable.
>C++ is significantly more efficient (sometimes even the factor 10 Joyner mentions)
What factor 10 Joyner mentions? Please quote. What are you talking about?
You are getting as hard to read as the C++ ARM.
>that most langauges providing comparable abstraction facilities because it provides
>mechanisms that allow programmers to make tradeoffs between generality and efficiency.
But it doesn't mean they don't exist. Try Apple's Object Pascal for example.
>Simply standing on a soap box vermently demanding
>that people abandon all their evil vices immediately isn't going to work very
>reliably. Typically, programmers and designers demand some form of emperical
>evidence before making a significant change.
Universities, and some of us in the real world are trying to find and
teach and educate in better practices. These practices have been developed
to avoid commonly found pitfalls. Well that's what I thought, but obviously,
I am wrong, we are really standing on a soap-box, preaching about evil vices.
My apologies, I'll stop it at once.
>Unsupported personal opinion - even
>when cloaked in impressive terminology - is insufficient to convince the more
>experienced. Seeing hype meet reality have made sceptics of most of us. I consider
>that healthy.
Now this I agree with.
>Programming, language design, system design, etc., is - ideally - engineering
>disciplines; not mathematics. The end results are working systems with constraints,
>tolerances, limited useful lives, failure modes, changing requirements, etc.; not
>proofs or objects of abstract beauty. A system may be beautiful, but given a choice
>between beauty and utility we must - as systems builders - prefer utility.
>Also, programming languages are tools in the real world. A nice reference manual
>by itself is of little use to a programmer.
Design is the realisation of utility in an elegant and beautiful manner. By
saying otherwise, you are denying the basic human spirit. A sense of
aesthetics is essential, if we are to discern quality. When a city is
stripped of its beauty, it turns into a ghetto and a slum.
>Transitions are important. We rarely have the luxury of starting from scratch and when
>we do the results are not necessarily good. C++ carries the scars of its evolution and
>those of the evolution of C. This can be infuriating. However, not all flaws are major
>and not every inconvenience is significant.
The implication of this statement is that many are significant flaws. If you
find C++'s C base infuriating, how are the rest of us to feel?
>The world of programming is much larger and more diverse than most
>people suspect. Even C and C++ cover only a small part of the total range of
>applications.
Well if we can get the C community at large to realise this, then we
will be progressing. C++ however, is not a good solution for even those
few applications. Even if it were the only solution, that would not
automatically make it a good solution, just the only solution.
Ian Joyner
>PS My opinion in a nutshell:
> Programming is engineering - not mathematics.
So that's why most of us can't program, we are not engineers. I did one
year's engineering at university, but dropped it in favour of computer
science. I did final year mathematics as part of my science degree, so
I am more of a mathematician than an engineer. However, I do not
consider myself a mathematician. I suspect though that more programmers
are like me, they are closer to being a mathematician than an engineer.
I do not have a degree in engineering. I cannot claim to be an engineer.
Perhaps programming is closer to art than engineering. After all an artist
idealises and abstract the real world. Or perhaps architecture, as system
design is often referred to as architecture. It just so happens, that our
designs are executable by computer. In fact the closest thing to an
engineer in the process is automated as the compiler, as it decides how
exactly to implement the program specification on the raw materials of
the underlying target environment.
Mostly engineering is concerned with duplicating what has been built before.
Software development is mainly involved with building things that have
never been built before. If not, just copy the disk. This is why we are
so hopeless at estimating how long software development will take.
Saying "programming is engineering" is just simplistic nonsense. It has
elements of many more disciplines than that. The best you can say is
that "programming is programming'. Saying "programming is engineering"
is just simplistic rubbish tha management likes to hear. I expect one
who designs languages to have a much broader perspective than this.
Please consider this, then maybe you will realise why C++ is so flawed,
and perhaps your assumptions have been incorrect.
Ian Joyner
> Efficiency is important - and a matter of design.
Yes, but it is only one consideration. And it is not the most important
consideration. You must consider (often before efficiency):
Reliablity: Both meeting specifications and requirements, and resilience
to complete failure.
Maintainability: To be able to correct a non reliable systems, and to be
able to adapt to new requirements. This is directly driven
by commercial forces.
Reusable: Reusability depends on firstly being able to understand a software
component, and secondly, trusting that software component, that it
is reliable. A language must support sufficient expressive power
to help write understandable systems.
Portability: The ability to take a software component to a diverse environment,
more economically than it would be to rewrite the component. Note
by diverse environment, I do not mean from one unix system to
another. I am talking "real" open systems here, not unix.
Efficiency fits in here somewhere. But the average software project needs
to balance these goals.
Please reconsider your thinking on this. Then you may realise why C++ is
such a flawed language for realistic software development.
Mike Ball
>when people have a lot of money on the table, which is definitely
>the case with todays vendors.
In practice it works out much the same as in theory. I have served on two
different ANSI committees and observed a third, so I have some direct
experience with the practice. I also work for a very small C++ vendor.
The only advantage that the big vendors have is that they can devote more
people to working on the committee. Since there is LOTS of work required,
this lets them have a bit more say in the final outcome since they tend to
have written more of the paperwork. That is, however, the only real advantage
they have, and it's not a big one. There are other large companies on
the committee who are not language vendors and devote similar amounts of
resources.
Lest you think that the committees are dominated by big corporations,
both the secretary and the vice-chair are from small companies, and many
other representatives are representing themselves. Each organization gets
one vote no matter what its size.
The ANSI standardization process is slow and frequently painful, but it does
tend to draw on the best in the field and I feel it generally builds good
standards which will be followed. Since compliance with ANSI standards is
voluntary, the committees have to do a good job or be ignored.
People not in the US are definately at a disadvantage in attending meetings,
but X3J16 is now an international group working with an ISO working group.
In the ISO group each country gets one vote. If you have a problem, talk
with your ISO representative.
--
Michael S. Ball (mi...@taumet.com)
TauMetric Corporation
Tim Lister
>>>>>> On 19 May 92 12:39:05 GMT, a...@alice.att.com (Andrew Koenig) said:
>
>> My experience has been that most people behave at least somewhat rationally
>> most of the time -- even when it is hard to understand their motivations
>> at first glance. If a whole bunch of people use a tool and continue to
>> use it, then it is doing something for at least some of them. They're
>> not all blind, or misled, or zombies.
>
>Quite true -- to a point. I've found that most people (in the non-research
>development area) tend mostly to use the best tool or the tool they're most
>used to from amongst the tools that they have locally. If they have to expend
>effort to find *the* best tool, then they settle for a lesser tool.
>--
And most people in the research area spend so much time talking
about how to form the committee to decide what method is to be used to
assess proposals for measurement of tools that nothing ever gets built.
(<grin>)
No, I'm serious. This net is the best tool available for
standardisation of classes, yet it's not being done. This is not
really ANSI's job, its OURS. Reusability globally (and I mean
earth-wide) could be achieved if we started discussions on this.
For example: what attributes should a good string package
have? Abstract array class?
To work on this we would have to accept C++ as it is and
get cracking, we can't go on forever about what's wrong with the language.
(Actually, we should do both, and that means an enigineering compromise
<grin> in the class design. Like a string package without exceptions.)
mat@mole-end
> Ian Joyner (i...@syacus.acus.oz) writes
> > I read "engineering compromise" as being a really feeble excuse ...
> > "Engineers" [deal] with imprecise analogue materials. ... they must
> > compromise, ... In software ... you entirely control the world you
> > are building.
> ...
> > There are two factors that are more important than the above blinkered
> > efficiency argument. ...
> ...
> > That C++ is based on C begs the question of do we want these 20 year old
> > "engineering compromises" in modern software development.
> ...
> > to hell with the [mumbo jumbo], give us something better than C++.
> ...
> > Those who are starting to demand better, modern ways of doing things
> > are not dreamers or academics ... [but] people who recognise that
> > there are better ways of doing things than C++.
>
> Who are "we?" and why don't you just do it (the "better ways of doing
> things") rather than posting repetitive tirades against C++? It takes
> much more than screams and personal opinions and conjectures disguised
> as homebrew "principles" to improve the state of software development.
Here, here! I wonder what would happen if comp.modula3 were infested with
a disgruntled hoarde whose only goal was to denigrate Modula3? What if
(heavens forfend) they had the insight and creativity of Stroustrup and
Richie and Keonig and Plaugher? If you want to see what such people can
do, read the infamous _Why Pascal Is Not My Favorite Programming Language
Paper_. It will leave you doubting the IQ, common sense, and experience
of that language's author, and of everyone who uses it.
This is almost as bad as the `terrorism' that a band of anti-theists carried
out years ago against net.religion.christian.
Let's stop crying about how the world's language designers/social architects/
BanksMadeOfMarble owe us this or that thing that we want. As Ian points
out, this is pure thought-stuff, and you can create as much as you want.
When the Little Red Hen offers to share her bread with you, you shouldn't
complain that you don't like pumpernickel.
--
(This man's opinions are his own.)
From mole-end Mark Terribile
uunet!mole-end!mat, Somewhere in Matawan, NJ
David Cok
....
>
>People not in the US are definately at a disadvantage in attending meetings,
>but X3J16 is now an international group working with an ISO working group.
>In the ISO group each country gets one vote. If you have a problem, talk
>with your ISO representative.
>--
>Michael S. Ball (mi...@taumet.com)
>TauMetric Corporation
Not to mention the fact that non-US domiciled organizations don't get to
vote at ANSI.
David Cok
Eastman Kodak Company
c...@Kodak.COM
Bob Martin
daily reality. I am a software engineer. I do what engineers all
over the world do, I create, repair and maintain devices which serve
clients. I make trade-offs. I trade off development time for
efficiency, accuracy for time to market, perfect languages for
portability. I trade off lots and lots of things, because that't the
only way to get the job done.
C++ is an engineer's language. What does that mean? It means that
the trade-offs made in teh creation of the language appeal to
engineers. A. it uses a well known (if imperfect) base. B. It allows
me to maximize efficiency when need be. C. It allows me to use
some powerful (not complete or perfect) abstraction tools. D. It
allows me to use several different programming techniques to trade off
efficiency and development time.
Other factors which make C++ attractive to engineers: It is
widely supported. It is widely documented. It is widely
accepted.
---------
I am not a mathematician. I am not interested in perfection. I am
interested in sufficiency. I need a language which is sufficient for
the job, not necessarily perfect. It is the job of an engineer to
deal with imperfection to achieve an end.
Unfortunately, software engineering is still very young. There are
still alot of barnstormers out there, flying by the seat of their
pants. This sometimes makes programming appear to be an artform.
Moreover, the research aspects are breaking ground as fast as the
engineering disciplines, and this sometimes makes programming seem
like a science. But programming is neither art nor science, it is
engineering. It is the use of imperfect tools, imperfect materials,
and imperfect information to create and support something which will
be *used* for profit. And to do so within acceptable time frames.
------------
Bemoaning and Railing against the flaws of C++ in an attempt to get
engineers to "wake up" and use something better, is a useless effort.
We KNOW the flaws of the language, we deal with them daily. You
aren't telling us anything new. And you aren't very convincing,
because here we are using the language, profitably, in spite of all
its flaws.
If you want engineers to change to language X, then you must show them
why X will make their job easier. This is no mean feat. When it
comes down to it, the perfect applicability of the language to a
certain task is pretty far down on the list of priorities. It is much
more important that the language be well known enough that
knowledgable engineers can be recruited. It is more imporatant that
the language supports the needed platforms. It is more imporatant
that the language has more than one supplier. It is more imporant
that the language is widely deployed, widely used, widely documented
and widely accepted.
C++ has been fighting this battle of acceptance for many years now,
and its acceptance and utilization just now seems to be approaching
the knee of the curve.
--
+---Robert C. Martin---+-RRR---CCC-M-----M-| R.C.M. Consulting |
| rma...@rational.com |-R--R-C----M-M-M-M-| C++/C/Unix Engineering |
| (Uncle Bob.) |-RRR--C----M--M--M-| OOA/OOD/OOP Training |
+----------------------+-R--R--CCC-M-----M-| Product Design & Devel. |
Steve Clamage
>b...@alice.att.com (Bjarne Stroustrup) writes:
>> Efficiency is important - and a matter of design.
>Yes, but it is only one consideration. And it is not the most important
>consideration. You must consider (often before efficiency):
>Reliablity: ...
>Maintainability: ...
>Reusability: ...
>Portability: ...
And Ian claimed in another article that he was not an engineer, but
more of a mathematician! I submit that these are engineering, not
mathematical, concerns.
For example, mathematics is generally concerned with whether a solution
exists for a problem, and pure mathematicians generally are not
interested in finding practical solutions.
Engineers usually model physical systems, so it is known in advance
that there is a solution (after all, the system exists and does
*something* -- the question is *what*). Of utmost importance is a
solution which meets the considerations Ian mentions.
It's time to come out of the closet, Ian :-)
--
Steve Clamage, TauMetric Corp, st...@taumet.com
Vice Chair, ANSI C++ Committee, X3J16
Jerry Schwarz
|>
|> Perhaps indeed we can encourage Bjarne to realise this, make the break
|> and use his expertise, and what he has learnt to create something
|> better. But I think that means a journey that leads quite a distance
|> away from C. Perhaps this may mean a denial of some ego as well.
|>
Since Ian dislikes C++ I've been wondering why he was bothering
contributing to this group and now I see. He's trying to convince
Bjarne to abandon C++. This reeks of hubris. Ian is trying to
recruit Bjarne away form C++ to which Bjarne has devoted a large
part of his proffessional career just because C++ has been such
a commercial success.
Maybe at some time in the future Bjarne will turn from C++ to something else.
f he does so I predict it will not be another programming language. .
In any event given that C++ embodies many of Bjarne's ideas and given that
Ian dislikes it so much, why would anyone expect that a new language
designed by Bjarne would please Ian anymore than C++ does?
I have no doubt that eventually a new language will sweep the commercial
world, but I don't have any idea of what it will look like or where
it will come from. In the meantime there are a lot of interesting
new programming languages being developed in a lot of places.
As far as I can tell none of the "defenders" of C++ in this group
woudl discourage people from exploring other alternatives.
-- Jerry Schwarz
Ian Joyner
>From ian@syacus Fri May 22 12:26:12 1992
Subject: no subject (file transmission)
To: i...@syacus.acus.oz (Ian Joyner)
Date: Fri, 22 May 92 12:26:12 EST
To: ian
Subject: follow failed
Status: RO
/usr/lib/news/inews: article in /dss/acct/ian/dead.article
Your response has been saved in ~/dead.letter
Your article/letter follows:
Newsgroups: comp.lang.c++
Subject: Re: Limits of Object Oriented Paradigm?
References: <DOUG.92Ma...@monet.ads.com> <1992May13....@microsoft.com> <DOUG.92Ma...@monet.ads.com> <1992May14.1...@microsoft.com> <1992May18.0...@syacus.acus.oz.au> <22...@alice.att.com> <1992May19.030914.4872@syacus.a
cus.oz.au> <22...@alice.att.com>
>From i...@syacus.acus.oz Thu May 21 23:38:29 1992
>From ian@syacus Thu May 21 23:38:27 1992
Subject: no subject (file transmission)
To: i...@syacus.acus.oz (Ian Joyner)
Date: Thu, 21 May 92 23:38:26 EST
To: ian
Subject: follow failed
Status: RO
/usr/lib/news/inews: article in /dss/acct/ian/dead.article
Your response has been saved in ~/dead.letter
Your article/letter follows:
Newsgroups: comp.lang.c++
Subject: Re: Limits of Object Oriented Paradigm?
References: <DOUG.92Ma...@monet.ads.com> <1992May13....@microsoft.com> <DOUG.92Ma...@monet.ads.com> <1992May14.1...@microsoft.com> <1992May18.0...@syacus.acus.oz.au> <22...@alice.att.com> <1992May19.030914.4872@syacus.a
a...@alice.att.com (Andrew Koenig) writes:
>In article <1992May19....@syacus.acus.oz.au> i...@syacus.acus.oz.au (Ian Joyner) writes:
>> Well it also helps to interpret remarks in the context of the discussion.
>> I will clarify my above remark by saying I am comparing two hammers.
>> A craftsman will look at two hammers, and consider their weight, balance,
>> striking accuracy, and then choose the best tool. It's a shame we can't
>> do that when it comes to programming languages.
>Speak for youself :-)
>Seriously, do you think NOBODY makes an effort to pick the best language
>for a context?
Who said NOBODY? I would say that the majority don't make any effort. They
don't make the effort to recognise that we have problems in software
development, work out what the problems are, and make the effort to
look for better languages and techniques.
>Seems implausible, to say the least. Or are you complaining
>that SOME PEOPLE don't make the effort? If so, what did you expect?
>That everyone should have perfect judgment all the time?
>My experience has been that most people behave at least somewhat rationally
>most of the time -- even when it is hard to understand their motivations
>at first glance.
This seems a very naive view of human nature. There are many factors that
dictate that we do not behave rationally. There are such things as ego,
jealousy, passion. You must mix with very boring, personality free people. :-)
>If a whole bunch of people use a tool and continue to
>use it, then it is doing something for at least some of them. They're
>not all blind, or misled, or zombies.
Perhaps not blind, but there is a good deal of blinkered vision in the
industry. The measure of market size does not equate to a measure of
quality. There are some of us who are now finding our voice against
C/C++. Do you think we are blind, misled zombies?
>> That is why I am trying to dissuade people that C/C++ is a universal
>> context. It is about time we realised that to achieve the same effect,
>> we need better tools than C++.
>There you go, ignoring context again.
This is typical off the track argument. If you can't put up a decent
argument, acuse your opponent of ignoring the context. Well, I suppose
if you try to defend C/C++, it must be difficult to do any better. OK,
I'll point it out, the context is given by "to achieve the same effect"
(as C++), "we need better tools than C++." The (as C++) inserted to make
the context clear.
>Better tools FOR WHAT?
Must you shout? Please keep your upper case down. I think you and
others know what is being talked about here, or are you too much of a
blind misled zombie? Or are you asking, 'WHAT' does C++ achieve?
>The contexts
>in which languages are useful are at least as different as the contexts that
>are appropriate for hammers vs. screwdrivers, except possibly for languages
>that are very similar such as Classic C and ISO C. Even there, judgment has
>to be contextual, based for example on what compilers are available for the
>particular machine one wishes to use.
No, this is contradictory to the long term goals of portability, and
furthermore, the much demanded open systems. C and Unix, by the way, do
not equate to open systems, and the above assertion shows why, as you
should not choose languages and compilers based on the machine, but how
well they can express the problem domain at hand. This ensures portability
and open systems.
>Let me suggest an exercise. How about imagining a context in which C++ is
>clearly the best possible choice and telling us what it is and why. If you
>can't do that, it suggests that your background is so completely different
>from most of the people on this newsgroup that it is hard to see a common
>basis for discussion.
That sounds like a threat of excommunication. This is a discourteous
suggestion, and I will ignore it further.
I can think of what C++'s context is. If you want short term hacks, then
sure program in C++. If you want long term quality, then we need
something else.
Now let me suggest some exercises. Read, and attempt to understand my
40 page critique I posted several weeks ago. You may begin to understand why C++
is weak and flawed. The critique is from a practical, day to day programmer
perspective, at the coal face so to speak. What we need is less C gurus, and
more people who will face the real issues.
James A. Mullens
for the Memorial Day weekend, just before you add this topic to your
kill file :-)
Christian attitude:
C++, being born in the original sin of C, is imperfect. It must be born
again so that it can truly be remade in His image. Let's get to it!
Zen attitude:
The acceptance (so far) of C++ has proven that it fills some void in
the universe. If you don't see this void or don't understand how C++
fills it, go back and meditate further. [Hint: don't require that C++
be perfect in His image; see Zen literature for an alternate definition
of perfection]. Be cool, the universe is working properly!
My golden rule (from 15 years of experience): Never develop an emotional
relationship with a programming language. In the end she'll desert you and
leave you with nothing but dusty source code decks; you'll spend your last
days bending the ears of younger programmers about her wierd quirks, and
the young guys will just walk away with a fixed smile on their faces.
Operating systems are no better.
My apologies if I have offended fellow Christians or fellow Zen Buddists :-)
jim (idle hands) mullens
mul...@jamsun.ic.ornl.gov (128.219.64.31)
voice: 615-574-5564
Ronald Schoenberg
>
>I can think of what C++'s context is. If you want short term hacks, then
>sure program in C++. If you want long term quality, then we need
>something else.
>
People like you frighten me. I am a number-cruncher who used FORTRAN
for many years and then dramatically increased my productivity by
going to an interpreted array langugage (GAUSS, but S, or MATLAB would
have done just as well). Then I was introduced to C++. With the M++
tensor class libraries, which essentially turns C++ into an array
language, I had the increased productivity and a lot more - an ANSI
supported language with a huge user base, lots of books on its use,
many competitive compiler vendors, and so on. I don't want to learn
another marginalized language so I can write libraries nobody wants
because there into their own language.
C++ represents for me unlimited possibilities. I have about 20
years of useful effort ahead of me, and with C++ I won't run out of
possibilities before then. For example, I want to explore everything
that can be done with Interval arithmetic - something that has potential for
revolutionizing optimization - which FORTRAN will never have and
which I've got going in a few weeks of programming in C++.
But critics like you worry me. Whenever I encounter critics I find
that they do not have the interests of number-crunchers in mind. I
get the uneasy feeling that if you and your friends have your way,
all that exciting adventures I see in my future will evaporate into
something without numbercrunching capability and force me back to
FORTRAN, or some interpreted array language, a very depressing thought.
David Casseres
Joyner) writes:
> Saying "programming is engineering" is just simplistic nonsense. It has
> elements of many more disciplines than that. The best you can say is
> that "programming is programming'. Saying "programming is engineering"
> is just simplistic rubbish that management likes to hear.
Hear, hear! I heartily agree. I believe that programming will eventually be
recognized as one of the fundamental disciplines, not a branch of anything else.
My company calls me a "software engineer," but when people ask me I usually make
up something else. It's too bad "programmer" has come to mean something else,
but even so I sometimes call myself a programmer.
--
David Casseres
Exclaimer: Wow!
--
David Casseres
Exclaimer: Wow!
Dirk Grunwald
I hardly think it's fair to lambast someone because they don't feel
that C++ meets the general needs of computing-dom on the grounds that
they're not catering to numerical computing.
Fortran, C and C++ are intrinsically unsafe languages. For some
applications, e.g, predicting ariflow over wings, this is OK. People
test-fly the planes before I get on them.
For things like automated tellers, inventory control, stock/bond
accounting, hospital equipment montoring, etc, etc, numerical control
and speed are usually not the paramount issue. True, speed matters,
But recall 2-4 years ago when whatevercompanyitwas in NY had a massive
short-term debt because their accounting program overflowed an integer
w/o a warning. They closed shop for 1-2 days while they relogged the
requests, and paid millions on the short-term loans they needed to
cover their assests.
In situtations like these, being able to do things like
char *foo = (char *) bar;
are meaningless.
Which isn't to say C++ isn't a useless language, but heavens, with
modern compiler technology, it's not much more difficult to produce a
language that has the same effiency as C++ and less of the trouble
some features.
Half the ugliness of C++ was induced by ``pragmatic'' concerns that
were, in retrospect, rather short sighted. E.g., with reasonable
compiler technology (none of it new, but new to the Unix world), you
could easily have opaque types, enhanced interface specifications,
real inline functions, etc etc.
It would be interesting to compare the complexity of a full
proposed-ANDI C++ compiler and an ADA compiler.
Stephen Crane
David> My company calls me a "software engineer," but when people ask me I
David> usually make up something else. It's too bad "programmer" has come
David> to mean something else, but even so I sometimes call myself a
David> programmer.
Well Ken Thompson is reported as describing himself (on his tax
returns) as a programmer and if the term is good enough for *him*,
it's certainly good enough for me!
David> David Casseres
Steve,
--
Stephen Crane, Dept of Computing, Imperial College of Science, Technology and
Medicine, 180 Queen's Gate, London SW7 2BZ, UK:jsc@{doc.ic.ac.uk, icdoc.uucp}
"If it works, it's obsolete." -- Marshall McLuhan.
Tim Lister
>In article <1992May21.1...@syacus.acus.oz.au>, i...@syacus.acus.oz.au (Ian Joyner) writes:
>|>
>|> Perhaps indeed we can encourage Bjarne to realise this, make the break
>|> and use his expertise, and what he has learnt to create something
>|> better. But I think that means a journey that leads quite a distance
>|> away from C. Perhaps this may mean a denial of some ego as well.
>|>
>
>Since Ian dislikes C++ I've been wondering why he was bothering
>contributing to this group and now I see. He's trying to convince
>Bjarne to abandon C++. This reeks of hubris. Ian is trying to
>recruit Bjarne away form C++ to which Bjarne has devoted a large
>part of his proffessional career just because C++ has been such
>a commercial success.
>
Ian is contributing to this group because he is concerned that many
are too concerned with the details of C++ to see that it has fundamental
flaws, because he is concerned that this very commercial success will
hold back the progress of computing at a time when much better systems
are emerging.
I, for one, would like to see Ian encouraged to continue
contributing to this group. His technical critique was well received,
and the current 'discussion' illustrates just how difficult
it really is to design and have accepted a new language.
No one I hope thinks C++ is the greatest language around
technically, we all know it is a compromise, and a considerable one
at that. Just why that compromise has lead to market success is a very
important issue for designers of new languages, to what extent C++
can be 'fixed' is very important to all of us.
Most of the issues in C++ now are not technical but
political. Even small and 'obviously' beneficial changes are likely
to get knocked back by ANSI. There must be a reason for this,
and part of that is surely the very great difficulty of satisfying
the needs of diverse interests.
For example, I suggested to Bjarne (head of extension subcommittee)
that adding binary ! for power was the best compromise, surely
the need for a power operator is apparent and none would oppose it.
His response was not encouraging, since it would apply to
ordinary built in types, it would impact the C community somehow.
Now I couldn't care less about C myself...but that is just the
point. There might be others with legitimate concerns, perhaps the
C people would want something else that would then introduce
an incompatibility with C++.
In short, I hope Ian will continue contributing to this
group EVEN if he is trying to disuade us from using C++. There
is nothing wrong with a stong dissident voice, indeed, it the
basis of democracy that dissidents be not just tolerated but
encouraged. Sometimes, they might just have a point ...
Michael C. Grant
Give me a break! The term engineer is so general you're not being 'lumped'
into a particular group. Fields like civil engineering and electrical
engineering, for example, are quite far apart yet we still tack on that
name 'engineer' at the end. And a lot of electrical engineering these
days doesn't even deal with electricity! It's just a name, for crying out
loud, and it means less and less every day since as the line between
the pure sciences and engineering become blurred more and more.
The only reason that I might consider programming to be a more fundamental
science than engineering is that so many engineers have to BE programmers
(NOT computer scientists) to properly execute their work. It's almost a
craft in some sense.
Michael C. Grant
Thomas M. Breuel
In article <1992May22....@syacus.acus.oz.au> i...@syacus.acus.oz.au (Ian Joyner) writes:
>I can think of what C++'s context is. If you want short term hacks, then
>sure program in C++. If you want long term quality, then we need
>something else.
People like you frighten me. I am a number-cruncher who used
FORTRAN for many years and then dramatically increased my
productivity by going to an interpreted array langugage (GAUSS, but
S, or MATLAB would have done just as well). Then I was introduced
to C++. [...] C++ represents for me unlimited possibilities. I
have about 20 years of useful effort ahead of me, and with C++ I
won't run out of possibilities before then. For example, I want to
explore everything that can be done with Interval arithmetic -
something that has potential for revolutionizing optimization -
which FORTRAN will never have and which I've got going in a few
weeks of programming in C++.
FORTRAN-77 was already obsolete as a programming language in the 70's.
Its advantage was that it was stable, standardized, efficient, and
widely available.
It's no different with C++. As a programming language, C++ is already
obsolete today. It has no features that a lot of other languages
before and after it have not also had, and it has a lot of intrinsic
problems. However, there are many pragmatic advantages to using C++.
The new, better programming languages (numerical or otherwise) are
already here. They are languages like Scheme, Haskell, SML, SISAL,
Eiffel, Modula-3, Oberon, ... . Unfortunately, it isn't clear yet
which of the languages will catch on, which ones will become obsolete,
and which ones will remain stable enough that code you develop now
will continue to function for years to come. Furthermore,
implementations for those new languages are not yet as good as those
for FORTRAN-77 or C++.
Now, it's up to you to decide whether it is better for you to work in
a stable, standardized, efficient, and widely available, but obsolete,
language, or whether it is better for you to work in a modern but
unstable, non-standard, and less efficient language.
When faced with that choice for different projects, I personally use C
for its ability to interface, stability and efficieny; C++ for its
efficiency; and SML for its expressive power.
Thomas.
Eric Smith
>It is time to assess how much further it is worth taking the C
>experiment. The technology it made compromises for is now well over 20
>years old. It is now not really applicable anymore, or at least in five
I'm glad to find someone on the net finally who cares about language
elegance, and is willing to do whatever is necessary to get rid of bad
languages. I hope I can persuade you to join my crusade to get rid of
English. English is a horrible mess due to many centuries of disorganized
language evolution. The only reason I continue to use it myself is
because it's the only language compatible with a lot of the people who
read this newsgroup. If we can persuade them to drop English and start
using a more elegant language, the world will be better off. Are you
with me on this? (I haven't yet decided which language to promote in
place of English, but the important thing is to make sure everyone is
aware that English is a severely flawed language.)
Tim Lister
>In article <1992May21.1...@syacus.acus.oz.au> i...@syacus.acus.oz.au (Ian Joyner) writes:
>>It is time to assess how much further it is worth taking the C
>>experiment. The technology it made compromises for is now well over 20
>>years old. It is now not really applicable anymore, or at least in five
>
>I'm glad to find someone on the net finally who cares about language
>elegance, and is willing to do whatever is necessary to get rid of bad
>languages. I hope I can persuade you to join my crusade to get rid of
>English. English is a horrible mess due to many centuries of disorganized
>language evolution. The only reason I continue to use it myself is
>because it's the only language compatible with a lot of the people who
>read this newsgroup.
I believe Ian hoped C++ was not yet the international
standard language, in which case your argument holds no water.
Unfortunately perhaps, I think Ian is wrong, it is too late,
C++ IS the international standard language right now.
Ian Joyner
it up just in case you missed it...
Ian Joyner
>In article <22...@alice.att.com>, b...@alice.att.com (Bjarne Stroustrup) writes:
>Here, here! I wonder what would happen if comp.modula3 were infested with
>a disgruntled hoarde whose only goal was to denigrate Modula3? What if
>(heavens forfend) they had the insight and creativity of Stroustrup and
>Richie and Keonig and Plaugher? If you want to see what such people can
>do, read the infamous _Why Pascal Is Not My Favorite Programming Language
>Paper_. It will leave you doubting the IQ, common sense, and experience
>of that language's author, and of everyone who uses it.
(That should be "Hear hear", by the way :-))
The point that Bjarne makes is about tirades against C++. However, why does
valid criticism about C++ get greeted with screams about tirades. Most
other users of other languages are much more professional than a lot of the
C community, in that they recognise the shortcomings of their language, and
quite openly discuss them, without recourse to the long winded, and
unhealthy screaming matches that occur on this group.
I feel a bit sorry for Bjarne in the position that he is, because he is trying
to adapt this rather old tired language of C, which was suitable for the limited
machines of 25 years ago, as a better assembler. He may have done the best
possible job of introducing OO into this. But it is questionable, whether
an object-oriented better assembler is worth the effort, and C++ has
illustrated the many shortcomings of this approach. But Bjarne, as
Frankenstein must learn to live with his monster. The criticism is valid,
and will become more widespread, until the software community at large
learns the real lessons that can be learnt from C++. It is nothing personal
about Bjarne, or the amount of effort that he has put into C++, or the
amount of objective criticism that he himself has made of the language.
But that does not mean that others are not allowed to criticise the language.
I think that criticism is healthy, and that variety is healthy. Unfortunately,
it is my experience with the C world, that it issues 'tirades' against
anything that is not C (or unix for that matter), and seems to stomp
on any variety. And then when you dare to criticise C (objectively, and
in a non-tirading fasion), you get accused of exactly the thing that the
C world is so good at, ie unfounded slinging off at other languages.
If you read my C++ Critique, I think you will find that it is not based
on unfounded argument, and that I honestly tried to be dispassionate,
and as objective, as the human mind can be.
If it were easy to go away and 'do it', or use something else, I would.
But this requires convincing a lot of people that C++ leaves a lot to be
desired, and has many problems that need to be solved. C++ has been widely
adopted for large scale software development. It is highly questionable
that it has been so adopted, as it introduces into the OO world many of
the things that OO was trying to get away from.
>This is almost as bad as the `terrorism' that a band of anti-theists carried
>out years ago against net.religion.christian.
Well, I don't see this criticism as being religious fervour, or terrorism.
It is and must be a part of a profession.
>Let's stop crying about how the world's language designers/social architects/
>BanksMadeOfMarble owe us this or that thing that we want. As Ian points
>out, this is pure thought-stuff, and you can create as much as you want.
Those that set themselves up to design languages must accept this as
a responsibility. Where the languages have shortcomings with regards to
what it is they are trying to achieve, then they must be criticised. C++
sets the goal of large scale software development with the engineering
paradigm. It misses the mark.
>When the Little Red Hen offers to share her bread with you, you shouldn't
>complain that you don't like pumpernickel.
Aw, isn't that sweet :-) If AT&T charges us thousands of dollars for
a compiler, and we have to expend lots of time trying to understand this
obscure thing, I'd hardly call that a free slice of bread. Rather it is
a very expensive slice of bread, with mould on it.
Walter Bright
/Yes, but it is only one consideration. And it is not the most important
/consideration. You must consider (often before efficiency):
/Reliablity: ...
/Maintainability: ...
/Reusability: ...
/Portability: ...
And, lest we forget, the most important attribute of software is:
*USEFULLNESS*
!
Per Abrahamsen
>>>>> On 24 May 92 01:04:10 GMT, t...@arolla.idiap.ch (Thomas M. Breuel) said:
Thomas> The new, better programming languages (numerical or otherwise) are
Thomas> already here. They are languages like Scheme, Haskell, SML, SISAL,
Thomas> Eiffel, Modula-3, Oberon, ... .
Some questions:
- Which language is best: Scheme or Eiffel?
- Would you write a ray-tracer in Scheme?
- Would you use an Eiffel interpreter as an embedded language?
- Why do people insist on talking about ``better'' languages without
mentioning the application?
Per Abrahamsen
>>>>> On 24 May 92 04:24:13 GMT, i...@syacus.acus.oz.au (Ian Joyner) said:
Ian> Read, and attempt to understand my 40 page critique I posted
Ian> several weeks ago. You may begin to understand why C++ is weak
Ian> and flawed. The critique is from a practical, day to day
Ian> programmer perspective, at the coal face so to speak.
I did read and attempted to understand your 40 page C++ critique. It
is an impressive work, but unfortunately less useful than it could
have been. I expect that is why it has generated little response.
What you do is basically to examine how useful the various C++
features are for solving some never explicitly stated problems, and
how close they are to a never explicitly stated strategy for solving
these problems.
It quickly become clear that the problems you want to solve are not
identical to the problems C++ is designed to solve, and the strategy
used in C++ is different from the strategy you prefer. Given this, the
detailed critique becomes uninteresting.
I think a much more useful version of your C++ critique would have the
following parts:
- The Problem Domain
What problems do you believe are important to solve?
What problems are C++ trying to solve?
Argue why the problems you selected are important to solve, and why
the problems C++ is addressing are less important.
Example: Should we help competent programmers to write good code, or
should we hinder naive programmers in writing bad code?
- The Strategy
Given the C++ problem domain:
How do you believe those problems should be solved?
How does C++ attempt to solve them?
Argue why your strategy is better.
Example: Should we help the programmers transition to an OO language
by extending an language they already know, or designing a new
language which is easy to learn?
- The Implementation
Given the strategy used in C++, does the features of the language help
solving the problems C++ was designed to solve.
Example: Does unions and pointer casts help C++'s goal of being a
type-safe language?
Andrew Koenig
> >When the Little Red Hen offers to share her bread with you, you shouldn't
> >complain that you don't like pumpernickel.
> Aw, isn't that sweet :-) If AT&T charges us thousands of dollars for
> a compiler, and we have to expend lots of time trying to understand this
> obscure thing, I'd hardly call that a free slice of bread. Rather it is
> a very expensive slice of bread, with mould on it.
If you have a computer that runs MS-DOS, you can buy a copy of the USL
(the software subsidiary of AT&T) C++ compiler for hundreds, not thousands,
of dollars. You can also buy similarly-proced C++ compilers from several
other vendors for similarly prices. You can also obtain the source code
for the GNU compiler for no money at all; while that compiler implements
a language that differs from C++ in several significant ways, it's a pretty
good first-order approximation.
This is a good place to point out that neither Bjarne nor I have any influence
at all over the people who make pricing decisions about software products.
I have no doubt that it is possible to debate business strategy endlessly,
but it would be much more useful if that debate could be held strictly
separate from any technical discussion.
--
--Andrew Koenig
a...@europa.att.com
Andrew Koenig
In the following, my original comments are preceded by ->,
Ian Joyner's replies by >, and my responses by null strings.
-> Seriously, do you think NOBODY makes an effort to pick the best language
-> for a context?
> Who said NOBODY? I would say that the majority don't make any effort. They
> don't make the effort to recognise that we have problems in software
> development, work out what the problems are, and make the effort to
> look for better languages and techniques.
I expect that the majority of people who are in a position to choose
languages at all pick the language their colleagues are already using
for similar problems, for pretty much the same reason that people
living in London mostly speak English and people living in Paris
mostly speak French. There are some people who claim that, say,
Esperanto is far superior to any natural language and insist on speaking
it as their primary language, but by doing that they cut themselves
off from the people around them.
The languages used in a particular environment are part of the context,
and a very important part. Even if management doesn't decree what
language to use, the choice will still be heavily influenced -- and
rightly -- by social factors.
One effect of this, incidentally, is that it is exceedingly difficult
to get people to change their behavior by telling them why they shouldn't
do whatever it is they're doing when everyone around them is doing the
same thing. It is much easier -- and may be the only possible thing that
really works -- to offer them an alternative that is better in some sense
than what they already have and show them how they gain from it. That is
how C++ has been gradually persuading the C community, and also why I think
that no present language aside from C++ has any chance of supplanting C
regardless of the faults of either.
Putting it another way, the ability to ask one's neighbor for help when
one gets stuck is a powerful and legitimate reason to use the same language
as one's neighbors. It is not the only reason, but it would be dishonest
to ignore it.
-> Seems implausible, to say the least. Or are you complaining
-> that SOME PEOPLE don't make the effort? If so, what did you expect?
-> That everyone should have perfect judgment all the time?
-> My experience has been that most people behave at least somewhat rationally
-> most of the time -- even when it is hard to understand their motivations
-> at first glance.
> This seems a very naive view of human nature. There are many factors that
> dictate that we do not behave rationally. There are such things as ego,
> jealousy, passion. You must mix with very boring, personality free people. :-)
If you believe that people usually behave irrationally, why are you
wasting your time trying to convince them by logical argument?
-> If a whole bunch of people use a tool and continue to
-> use it, then it is doing something for at least some of them. They're
-> not all blind, or misled, or zombies.
> Perhaps not blind, but there is a good deal of blinkered vision in the
> industry. The measure of market size does not equate to a measure of
> quality. There are some of us who are now finding our voice against
> C/C++. Do you think we are blind, misled zombies?
No I don't. What I don't understand, though, is why you expend so much
effort in opposition to C++ instead of looking for something you think is
better (I'm tempted to add `for your purposes,' but you don't seem to
believe that different people can have different purposes).
It is easy to find flaws in programming languages if you've seen enough
of them. I wrote a whole book about problems with C and I'm now writing
a column about problems with C++. I believe I could do the same with any
of the 20 or so languages I know reasonably well. So what? The point is
that these languages all have things they do particularly well; if we want
to, we can learn how to exploit those things and understand which languages
belong in our tool kits and when to use them.
-> > That is why I am trying to dissuade people that C/C++ is a universal
-> > context. It is about time we realised that to achieve the same effect,
-> > we need better tools than C++.
-> There you go, ignoring context again.
> This is typical off the track argument. If you can't put up a decent
> argument, acuse your opponent of ignoring the context. Well, I suppose
> if you try to defend C/C++, it must be difficult to do any better. OK,
> I'll point it out, the context is given by "to achieve the same effect"
> (as C++), "we need better tools than C++." The (as C++) inserted to make
> the context clear.
My argument isn't off the track -- it is the track. Saying that one tool
is `better' than another, without saying better for what, is just rhetoric.
Now, if what you mean to say is that you think we need tools that will work
better than C++ in the contexts in which C++ is presently useful, then we
finally (for the first time!) have something that is a plausible subject
for discussion.
But then most of your critique is off the mark -- because if you are looking
for ways of improving on what C++ does well, you will not find them by
concentrating exclusively on what it does badly.
I note in passing that `need' is another of those words (like `better')
that often conceals a context. I might reply that we don't need computers
at all, humanity having existed without them for quite a long time.
-> Better tools FOR WHAT?
> Must you shout? Please keep your upper case down. I think you and
> others know what is being talked about here, or are you too much of a
> blind misled zombie? Or are you asking, 'WHAT' does C++ achieve?
This is an example of what I have heard called `the argument from intimidation.'
I ask you a question and you reply, in effect `Either you're a blind
misled zombie or you know what I'm talking about and are deliberately
pretending you don't.' One way to deal with such arguments is to point
them out. They don't add anything to the discussion.
I know quite well what C++ achieves: it raises the level of abstraction
of programmers who would otherwise be using C.
-> The contexts
-> in which languages are useful are at least as different as the contexts that
-> are appropriate for hammers vs. screwdrivers, except possibly for languages
-> that are very similar such as Classic C and ISO C. Even there, judgment has
-> to be contextual, based for example on what compilers are available for the
-> particular machine one wishes to use.
> No, this is contradictory to the long term goals of portability, and
> furthermore, the much demanded open systems. C and Unix, by the way, do
> not equate to open systems, and the above assertion shows why, as you
> should not choose languages and compilers based on the machine, but how
> well they can express the problem domain at hand. This ensures portability
> and open systems.
How's that again? Are you really saying that I can advance the cause of
portability by programming in a language that is not available on my machine?
-> Let me suggest an exercise. How about imagining a context in which C++ is
-> clearly the best possible choice and telling us what it is and why. If you
-> can't do that, it suggests that your background is so completely different
-> from most of the people on this newsgroup that it is hard to see a common
-> basis for discussion.
> That sounds like a threat of excommunication. This is a discourteous
> suggestion, and I will ignore it further.
It's not a threat; I have no power to threaten. But if your fundamental
position is `I don't think C or C++ are good for anything at all,' then
a lot of people are going to respond `What nonsense! I'll ignore this guy.'
> I can think of what C++'s context is. If you want short term hacks, then
> sure program in C++. If you want long term quality, then we need
> something else.
Let's try a concrete example.
Apple wrote System 7 in C++. They had written their previous operating
system releases in Object Pascal, but they decided that there was no future
in a home-grown captive language.
What language do you think they should have written System 7 in and why?
> Now let me suggest some exercises. Read, and attempt to understand my
> 40 page critique I posted several weeks ago. You may begin to understand why C++
> is weak and flawed. The critique is from a practical, day to day programmer
> perspective, at the coal face so to speak. What we need is less C gurus, and
> more people who will face the real issues.
I have read your critique quite thoroughly. I might even post a response
someday if I can find the time. Do not make the mistake of thinking that
because I disagree with you, I misunderstand your position.
For one thing, C++ starts with C as an assumption. In other words, because
C++ aims primarily at people who would otherwise be using C, it acknowledges
that there is this thing called the ISO C standard that is not going to change.
Therefore, for example, complaining that C uses semicolons as terminators
rather than separators is a waste of time; for better of worse, that's how
it is. For C++ to do otherwise would weaken its appeal to its intended audience.
If I can't get you to admit that C or C++ are good for anything, perhaps you
might tell us a few languages you think are `better' and why.
--
--Andrew Koenig
a...@europa.att.com
Andrew Koenig
> - Why do people insist on talking about ``better'' languages without
> mentioning the application?
I don't know for sure, but I suspect it is just one more example
of the universality of abstraction. In this context, abstraction
is the process of ignoring complexities of a situation that happen
to be inconvenient at the moment.
One of the keys to successful use of abstraction is knowing when
to use it and when not to. One can spend a lifetime learning to
do that in programming, and I don't see why it should be any easier
when dealing with people.
--
--Andrew Koenig
a...@europa.att.com
Ronald Schoenberg
>
>FORTRAN-77 was already obsolete as a programming language in the 70's.
>Its advantage was that it was stable, standardized, efficient, and
>widely available.
>
>It's no different with C++. As a programming language, C++ is already
>obsolete today. It has no features that a lot of other languages
>before and after it have not also had, and it has a lot of intrinsic
>problems. However, there are many pragmatic advantages to using C++.
>
>The new, better programming languages (numerical or otherwise) are
>already here. They are languages like Scheme, Haskell, SML, SISAL,
>Eiffel, Modula-3, Oberon, ... . Unfortunately, it isn't clear yet
>which of the languages will catch on, which ones will become obsolete,
>and which ones will remain stable enough that code you develop now
>will continue to function for years to come. Furthermore,
>implementations for those new languages are not yet as good as those
>for FORTRAN-77 or C++.
>
>Now, it's up to you to decide whether it is better for you to work in
>a stable, standardized, efficient, and widely available, but obsolete,
>language, or whether it is better for you to work in a modern but
>unstable, non-standard, and less efficient language.
>
>When faced with that choice for different projects, I personally use C
>for its ability to interface, stability and efficieny; C++ for its
>efficiency; and SML for its expressive power.
>
> Thomas.
I am an applied mathematician - not a programmer. In fact I don't
know any programmers. My colleagues, to the extent that they use
computers at all, are not very interested in being programmers.
Instead all we are really interested in is getting our work done. One
reason FORTRAN was popular among scientists was that it was
intellectually undemanding leaving more time and energy for what we
really want to do.
Because of unix and the popularity of C, we're starting to learn C.
In the last two years C code has been showing up more and more on NETLIB.
The result, however, is a dilemma - we can either take away time
and energy from what we were really interested in to become experts in
a language with features that we were unwilling to appreciate, or we can
encourage the formation of a subgroup of us who were willing to
specialize in C and upon whom we will develop a complete dependency, i.e.,
gurus.
Or we can abandon the use of computer languages altogether and turn
instead to the interpreted array languages - MATLAB (engineers), S
(statisticians), GAUSS (econometricians). The languages provide a
significant productivity advantage over other languages (including
FORTRAN) while being easy to use (i.e. gurus not required).
It seems to me that working scientists and engineers are dividing
into three types - people who still use FORTRAN (the largest group),
people who are completely dependent on programmers and gurus (they
either have the money or the budget to hire them, or they are lucky
enough to find graduate assistants who (unfortunately for their own
careers) are more interested in programming than doing real work), and
people who use the interpreted array languages. And in the process we
have lost one of the most important features of FORTRAN - its
unversality (at least among scientists and engineers). Will NETLIB be
able to keep up with the de-centralization now going on?
I see C++ as a solution to all this because it does something very
subtle that is very hard for computer scientists and programmers to
see. C++ creates a small but important shift in the division of labor
that may be more favorable to the people who want to get their work
done while not taking away from the gurus. There will now be two
groups of people, those who write the class libraries, and those who
use them. Programmers find this appalling, but it is possible to use
class libraries without looking at the source. I use the
class library M++ [a commercial product that I assisted in developing,
but which I now use in my consulting business] as if it were an array
language. One can use it to do the same things that MATLAB does
without knowing anything about memory allocation or even pointers.
Nor do I have to ever see the source code for M++ - I use the compiled
libraries; I don't even have the source code on my computer. My
productivity has tremendously improved, and I don't have to be an
expert in C++ programming!
Using C++ a programmer can design an interface that is as
intuitive, easy to use, and as productive as the interpreted array
languages. The interface of M++ was explicitly designed to mimic the
array languages. Then, as the scientist/engineer learns more about
the other features of C++, such as memory allocation and pointers,
they can increase their programming power and do things that the
person who has stayed with FORTRAN can never dream about doing - not
because it can't be done in FORTRAN, but because it would take too
much time and energy. With C++ class libraries we can be as expert as
we want to be and no more.
To me the computer scientists and language gurus appear like
the capitalists who decide how the wealth of a country is to be used
without considering the worker's interests. They pursue intellectual
goals while forgetting that the most important goal of the
scientist/engineer is their *scientific and engineering* productivity.
Two things contribute significantly to this - a powerful, intuitive
interface ( so I don't have to spend all my time learning how to use
it), and the universality of the language (so the work and effort that some
have put into programming can help save others from having to put out
the same work and effort). Eiffel, Modula3, etc. aren't going to
solve those problems primarily because they are marginal. C++ is not
marginal, and the code is re-usable. And I think it may become a
language of choice for numeric programming (and will replace FORTRAN
if it can solve the speed problems), as long as the computer
scientists and language gurus can be prevented from destroying its
universality by pushing more languages on us, or continue to force us
to become programmers to get our work done. If languages are to be
declared obsolete before the compilers have even worked out their bugs
then there is no hope - no language will every be around long enough
to establish itself as universal enough to matter.
Epilogue: would one of you critics of C++ name one feature that C++
can't possess that will matter to applied mathematicians (no fair
claiming lack of IEEE floating point numerics because that can be
fixed, Cf. Zortech Science and Engineering compiler)? Multiple
dispatch doesn't sound like one of them (why would an *applied*
mathematician care about groups?)
Ian Joyner
>In article <1992May21.1...@syacus.acus.oz.au>, i...@syacus.acus.oz.au (Ian Joyner) writes:
>|>
>|> Perhaps indeed we can encourage Bjarne to realise this, make the break
>|> and use his expertise, and what he has learnt to create something
>|> better. But I think that means a journey that leads quite a distance
>|> away from C. Perhaps this may mean a denial of some ego as well.
>|>
>Since Ian dislikes C++ I've been wondering why he was bothering
>contributing to this group and now I see. He's trying to convince
>Bjarne to abandon C++. This reeks of hubris.
Ah, yes I just love the smell of fresh hubris in the morning :-)
>Maybe at some time in the future Bjarne will turn from C++ to something else.
>f he does so I predict it will not be another programming language. .
Hopefully, yes. I can just see us in 20 years time cursing being
stuck with C++ in the same way we are stuck with COBOL now. We
should be working out a way of having a flexible industry, not
trying to paint ourselves into corners, just because that's what we
have always done.
>In any event given that C++ embodies many of Bjarne's ideas and given that
>Ian dislikes it so much, why would anyone expect that a new language
>designed by Bjarne would please Ian anymore than C++ does?
Bjarne himself admits the problems that basing his ideas on C have
brought about. I'm sure he has lots of good ideas, and certainly
good experience. It is a shame to see it wasted further on pushing
an old crippled language such as C to its limits.
>As far as I can tell none of the "defenders" of C++ in this group
>woudl discourage people from exploring other alternatives.
That has not been my experience in the last ten years, as the C camp
has often poured scorn (for the so called 'engineering', or maybe
that should be pseudo-engineering reasons), on anything else.
This has made it difficult for anyone to take a balanced, and
non-religious view of anything. I hope you are right though, and
that things are truly changing.
Ian Joyner
>It's no different with C++. As a programming language, C++ is already
>obsolete today. It has no features that a lot of other languages
>before and after it have not also had, and it has a lot of intrinsic
>problems.
Well, C.A.R. Hoare did remark that Algol was a significant improvement
over most of its successors.
Ken Yap
|to get people to change their behavior by telling them why they shouldn't
|do whatever it is they're doing when everyone around them is doing the
|same thing. It is much easier -- and may be the only possible thing that
|really works -- to offer them an alternative that is better in some sense
|than what they already have and show them how they gain from it. That is
|how C++ has been gradually persuading the C community, and also why I think
|that no present language aside from C++ has any chance of supplanting C
|regardless of the faults of either.
And lest we forget, C++ started life as C With Classes. C++ has been
through this persuasion phase.
It's so much easier to criticize than to improve. It's easy to point
out flaws in a language but harder to say what should be done instead
and even harder to make them work properly. We're waiting, Ian.
Ian Joyner
>In article <1992May22....@syacus.acus.oz.au> i...@syacus.acus.oz.au (Ian Joyner) writes:
>>
>>I can think of what C++'s context is. If you want short term hacks, then
>>sure program in C++. If you want long term quality, then we need
>>something else.
>>
>People like you frighten me. I am a number-cruncher who used FORTRAN
>for many years and then dramatically increased my productivity by
>....
> But critics like you worry me. Whenever I encounter critics I find
>that they do not have the interests of number-crunchers in mind. I
>get the uneasy feeling that if you and your friends have your way,
>all that exciting adventures I see in my future will evaporate into
>something without numbercrunching capability and force me back to
>FORTRAN, or some interpreted array language, a very depressing thought.
Ron,
Sorry to have caused you undue worry. I do hear the pleas of the number
crunchers, and I do believe you are a group that has needs that should
be catered for. I do not believe that in order to cater for number
crunchers, that you intrinsically need an ugly language like C++,
or like FORTRAN.
Peter Wegner in his paper "Object-oriented Concepts and Paradigms"
in the inaugural ACM OOPs Messenger, said he believes we can have
our cake and eat it. He expands that the goals of efficiency,
reliability and flexibility are not contrary. Compiler technology
is getting better by the moment (although outside of the Unix
world, it seemed to get better a long time ago.) We do know how
to generate good code out of high level languages now, without
having to resort to higher level assemblers like C.
Again, apologies for any undue alarm.
Ian Joyner
>That programming is engineering is not a doubt in my mind, it is a
>daily reality. I am a software engineer. I do what engineers all
>over the world do, I create, repair and maintain devices which serve
>clients. I make trade-offs. I trade off development time for
>efficiency, accuracy for time to market, perfect languages for
>portability. I trade off lots and lots of things, because that't the
>only way to get the job done.
Sure we have things in common with engineering, but we cannot equate the
programming profession, with the engineering profession. Creation, maintenance,
and trade off are all things which many other professions do as well. In fact
it is an insult to engineers that you draw a few similarities, and hey
presto, all these scruffy software types, are now engineers. But seriously,
I have a problem calling myself an engineer, as I do not have such a certificate
that I can hang on my wall. I do have a piece of paper that says I am a
scientist, so I can honestly say I am a software (or computer) scientist.
>C++ is an engineer's language. What does that mean? It means that...
It doesn't mean anything much, really does it? Engineering used in this
way is just a hollow catch phrase. It demeans the meaning of engineer, as
used by engineers. It is falsely trying to give software development some
form of respectibility by using the name of someone elses profession. We
must establish software production in its own right. We have not accomplished
this yet, and C++ certainly does not either.
If engineers made the same sort of compromises that C++ made, none of their
structures would stand up. In software, we are still building bridges out
of match sticks.
>Other factors which make C++ attractive to engineers: It is
>widely supported. It is widely documented. It is widely
>accepted.
Widely documented eh? Most of the reviews I have seen on C++ texts in
Computing Reviews have rated them pretty poorly. Basically, what I want
is to get to a state, where we have quality in software development, not to
sit back smugly, and believe that everything is OK, because it is widespread.
>---------
>I am not a mathematician. I am not interested in perfection.
Well you have chosen the right language there. (Sorry cheap shot,
couldn't resist :-))
>I am
>interested in sufficiency. I need a language which is sufficient for
>the job, not necessarily perfect. It is the job of an engineer to
>deal with imperfection to achieve an end.
But in the 'unreal' world of computers, where we are removed from the
natural and imperfect world, these imperfections are self imposed,
especially in the case of C++. The power of computers comes from the
ability to represent the real world, apart from the real world,
removing the imperfections of the real world. This is the process
of abstraction.
In the real world, engineers deal with imperfections that are beyond
their control. In software, we are building abstract worlds, that are
completely within our control. When we realise that, then we will
realise what software development is all about. In fact that is the
fundamental difference between engineering and software science. It is
not about excuses. Even average people don't accept the excuse of
'computer error' anymore, as they realise that we are 100% in control in
the world of computers.
It is strange however, that the engineers strive for perfection in the
hardware they build, that they try to make their processors, and storage
devices as close to 100% reliable as possible. Engineers are striving
for precision, while us software people seem to be striving for
compromise. We will end in a pile of mediocrity. Here we are in the
software 'profession' admitting more and more compromise. Engineers are
at least getting better, we are getting worse.
>Bemoaning and Railing against the flaws of C++ in an attempt to get
>engineers to "wake up" and use something better, is a useless effort.
I don't think so (obviously). But then I am not 'bemoaning and railing',
or presumptious enough to shake people into metaphorically 'waking up'.
However, it is worth pointing out the false assumptions upon which C
and C++ are based. One of those being that programming is engineering.
>We KNOW the flaws of the language, we deal with them daily. You
>aren't telling us anything new. And you aren't very convincing,
>because here we are using the language, profitably, in spite of all
>its flaws.
Well congratulations, your guru certificate is in the post ;-)
This is a relative argument though. When you find that some other
company is able to produce products five times faster, and ten
times cheaper, and you are losing customers to them, then the
commercial reality will sink in.
---------------------------
My original post may have seemed a little insulting to real engineers.
However, I was trying to get people thinking about what is otherwise
all to readily accepted terminology. We are in fact misusing the term
engineering when we apply it to software development. We are abusing it
by using 'engineering' to give the feeling of a good roll the sleeves up,
let's get dirty job. It is a shame that some must apply this
term to themselves to make them sound more relevant and practical than
the rest. My apologies to the engineering profession on behalf of the
programming profession.
In fact, the need to apply some other professions credentials to
programming is a sign of the professions insecurity, and immaturity.
If we are to gain true respectibility in our own right, we must
develop much better techniques than we have today.
There are similarities to engineering, and we can apply engineering
principles to software production, but 'programming = engineering' is
not the right equation. In fact programming and poetry have a lot in
common as both describe some reality, or system, and both should
be careful about diction (naming things). We need to be eclectic and
multi-disciplined, in the same way that Leonardo Da Vinci was.
Anyway, see my forthcoming book, "Confessions of a quiche eating,
Chopin playing Pascal Programmer", or "Quiche eating is OK, just
watch out for the lumpy bits" :-)
Ian Joyner
>i...@syacus.acus.oz.au (Ian Joyner) writes:
>>b...@alice.att.com (Bjarne Stroustrup) writes:
>>> Efficiency is important - and a matter of design.
>>Yes, but it is only one consideration. And it is not the most important
>>consideration. You must consider (often before efficiency):
>>Reliablity: ...
>>Maintainability: ...
>>Reusability: ...
>>Portability: ...
>And Ian claimed in another article that he was not an engineer, but
>more of a mathematician! I submit that these are engineering, not
>mathematical, concerns.
These (and efficiency) are practical concerns. But this does not necessarily
mean engineering. For example, a bank teller is interested in serving
customers efficiently, in that they don't have to wait too long in the
queue. Reliably, they get the right amount of money. Maintainably, that
the account is easy to update. Reusably, the customer will come back.
And portably, that the procedures in one branch are applicable if they
get transferred.
>It's time to come out of the closet, Ian :-)
Ok, I confess. I'm not sure what I'm confessing but anyway :-)
Ian Joyner
Ok, where do I sign up. The parallel with natural language is not altogether
relevant though. We have much more control over the definition of programming
language. We should exercise that control, and ensure that we are
getting the precision (safety and correctness) out of programming languages
that we require.
Ian Joyner
a...@alice.att.com (Andrew Koenig) writes:
>I expect that the majority of people who are in a position to choose
>languages at all pick the language their colleagues are already using
>for similar problems, for pretty much the same reason that people
>living in London mostly speak English and people living in Paris
>mostly speak French. There are some people who claim that, say,
>Esperanto is far superior to any natural language and insist on speaking
>it as their primary language, but by doing that they cut themselves
>off from the people around them.
The parallel to natural languages is not relevant. We really have no or little
control over natural language. Programming languages are a production that
we have control over. We need to make sure that they provide the required
precision and safety.
>Putting it another way, the ability to ask one's neighbor for help when
>one gets stuck is a powerful and legitimate reason to use the same language
>as one's neighbors. It is not the only reason, but it would be dishonest
>to ignore it.
And you are very likely to get stuck in C++. Then you will have to consult
your guru (read spiritual humbug) to help restore you on the right path
to obscurity.
>If you believe that people usually behave irrationally, why are you
>wasting your time trying to convince them by logical argument?
Good question. It is perhaps becuase I do feel it is important to start
thinking rationally about programming languages, and to give people the
feeling that languages are something within our control.
>-> If a whole bunch of people use a tool and continue to
>-> use it, then it is doing something for at least some of them. They're
>-> not all blind, or misled, or zombies.
>> Perhaps not blind, but there is a good deal of blinkered vision in the
>> industry. The measure of market size does not equate to a measure of
>> quality. There are some of us who are now finding our voice against
>> C/C++. Do you think we are blind, misled zombies?
>No I don't. What I don't understand, though, is why you expend so much
>effort in opposition to C++ instead of looking for something you think is
>better (I'm tempted to add `for your purposes,' but you don't seem to
>believe that different people can have different purposes).
>> Must you shout? Please keep your upper case down. I think you and
>> others know what is being talked about here, or are you too much of a
>> blind misled zombie? Or are you asking, 'WHAT' does C++ achieve?
>This is an example of what I have heard called `the argument from intimidation.'
>I ask you a question and you reply, in effect `Either you're a blind
>misled zombie or you know what I'm talking about and are deliberately
>pretending you don't.' One way to deal with such arguments is to point
>them out. They don't add anything to the discussion.
I agree, but who mentioned the terms blind, misled, and zombies to start
with? I'm just humourously playing with your words here :-). Anyway,
I agree enough of the mud slinging, this group is famous for it.
>I know quite well what C++ achieves: it raises the level of abstraction
>of programmers who would otherwise be using C.
Ah, I see, C is an end goal in itself.
>-> Let me suggest an exercise. How about imagining a context in which C++ is
>-> clearly the best possible choice and telling us what it is and why. If you
>-> can't do that, it suggests that your background is so completely different
>-> from most of the people on this newsgroup that it is hard to see a common
>-> basis for discussion.
>> That sounds like a threat of excommunication. This is a discourteous
>> suggestion, and I will ignore it further.
>It's not a threat; I have no power to threaten. But if your fundamental
>position is `I don't think C or C++ are good for anything at all,' then
>a lot of people are going to respond `What nonsense! I'll ignore this guy.'
No, that is not my fundamental position. My fundamental position is that
C++ lacks the precision required of a language, and lacks the control that
programmers need over a language. From the hundreds of personal positive
responses I have received, I am not the only one who thinks this, and I am
not being ignored.
>Let's try a concrete example.
>Apple wrote System 7 in C++. They had written their previous operating
>system releases in Object Pascal, but they decided that there was no future
>in a home-grown captive language.
They wrote the Finder in C++. Did they write the rest of the system in
C++? Not that I have heard of. Kent where are you? Previous systems were
not written in Object Pascal, they were written in 68000 assembler.
Object Pascal for all its limitations as an OO language was at least
nice compact and elegant, and Apple's MPW compiler happens to generate
very efficient code.
>If I can't get you to admit that C or C++ are good for anything, perhaps you
>might tell us a few languages you think are `better' and why.
OK, C and C++ are good for low level Unix hacking, and also C is a good
universal assembler. However these attributes (strengths?) do not in
general qualify them for large scale software development.
The applicability of C and C++ is a lot narrower than many people would
believe. It must be questioned whether C and C++ are relevant for the
future, or are we to be stuck with a white elephant like COBOL. That is
not to deny the usefulness of COBOL. At least COBOL abstracts away from the
underlying implementation details of the machine and OS environment.
Systems level programmers are beginning to realise that systems level
languages should do likewise.
Other languages and environments need to be given breathing space in
which to survive and prosper. It might be a while before it is realised
at large that you don't have to get dirty in order to implement
efficient systems. In fact in the future, it is exactly the high
level elegant systems that will run well on the concurrent processors
of the not too distant future.
I'm just doing my little bit to make sure that we don't get stuck with C++.
---
Ian Joyner ACSNet: i...@syacus.acus.oz
ACUS (Australian Centre for Unisys Software) Internet: i...@syacus.acus.oz.au
115-117 Wicks Rd, North Ryde, N.S.W, Australia 2113.
Tel 61-2-390 1328 Fax 61-2-390 1391 UUCP: ...uunet!munnari!syacus.oz
"Where is the man with all the great directions?...
You can't imagine it, how hard it is to grow
Can you imagine the order of the universe?" ABWH
Disclaimer:Opinions and comments are personal.
Ian Joyner
>I did read and attempted to understand your 40 page C++ critique. It
>is an impressive work, but unfortunately less useful than it could
>have been. I expect that is why it has generated little response.
Well, actually it has generated much response in my personal mail. I have
replied to over 400 mails, many of them with positive comments, so there
are many people who find this relevant.
>What you do is basically to examine how useful the various C++
>features are for solving some never explicitly stated problems, and
>how close they are to a never explicitly stated strategy for solving
>these problems.
>It quickly become clear that the problems you want to solve are not
>identical to the problems C++ is designed to solve, and the strategy
>used in C++ is different from the strategy you prefer. Given this, the
>detailed critique becomes uninteresting.
Well, I stated why I chose the explicit format of the Critique, and why
I avoided the things you are speaking about. In fact it is difficult to
say what particular problems should be solved by any particular programming
language (apart from COBOL perhaps). That is what makes languages so
powerful, the large set of problems they may be applied to. It is
the ease with which they are applied that is important, and I think
the critique addresses this ease, particularly within a large software
development environment.
Many people are aware of the problems of software development. We have
not succeeded in solving them yet. Basing our solutions on a 25 year
old language from another place and time is not helping.
Still, if you don't find my critique convincing that there are problems
with C++, you can always go and read the ARM. It shows you how imprecisely,
and unsafely you can design a language.
The nature of my critique was that I was trying to be accurate, thorough,
practical, reasoned, and to gather many criticisms of C++ into one place
to get an idea of the extent of the problem. There are many ways such a
critique could be arranged, perhaps mine does not work for you. However,
many of the points would be the same, and maybe even some more and
different ones.
Tim McClarren
> presto, all these scruffy software types, are now engineers. But seriously,
> I have a problem calling myself an engineer, as I do not have such a
certificate
> that I can hang on my wall. I do have a piece of paper that says I am a
> scientist, so I can honestly say I am a software (or computer) scientist.
>
Well, I have a piece of that says I am both a scientist and an engineer, and
so do thousands of UI graduates. I am a "Computer Science Engineer". But,
being a programmer and being a computer scientist are truly two different
things. You are a programmer, not a computer scientist. A computer scientist
is a scientist who is active doing research in computer science. That may
involve little, if any, actual programming. Programmers are in reality more
akin to engineers in what we do on a day-to-day basis, and I think of myself
as an engineer, not a scientist (I know little if anything about actual
computer science, beyond hash tables, trees, and good line drawing algorithms,
but I know a lot about programming particular architectures). Applied science
doesn't equal pure science. But, this doesn't belong on comp.lang.c++, I
apologize.
Mark Mullin
conferance, he made a comment that seemed indicative of his
attitude, at least at the time.
(said with a look of quiet disgust)
There is *nothing* worse than a medium size success. To big to
ignore, to small to get any resources.
MMM
Bob Martin
>Sure we have things in common with engineering, but we cannot equate
>the programming profession, with the engineering profession.
>Creation, maintenance, and trade off are all things which many other
>professions do as well. In fact it is an insult to engineers that you
>draw a few similarities, and hey presto, all these scruffy software
>types, are now engineers.
1. How can you determine what is insulting to egineers, when you are admitedly
not one.
2. Do you really feel that the people in your profession are all
scruffy? Why do you think that? I find it insulting that you have
sterotyped all software people in this demeaning fashion.
3. Why do you think that engineering is so well defined as to exclude
software professionals. There are so many different kinds of
engineers in the world. What is the fundemental difference between
all the them and software professionals? (A explanation unrelated
to "scruffiness" is preferred.)
>But seriously, I have a problem calling
>myself an engineer, as I do not have such a certificate that I can
>hang on my wall. I do have a piece of paper that says I am a
>scientist, so I can honestly say I am a software (or computer)
>scientist.
Thats you. I on the other hand have over 20 years experience in
engineering software solutions. I have no problem calling myself an
engineer. And the engineers who I work with who *do* have their
certificates have had no problem with it either.
>>C++ is an engineer's language. What does that mean? It means that...
>It doesn't mean anything much, really does it? Engineering used in this
>way is just a hollow catch phrase. It demeans the meaning of engineer, as
>used by engineers. It is falsely trying to give software development some
>form of respectibility by using the name of someone elses profession. We
>must establish software production in its own right. We have not accomplished
>this yet, and C++ certainly does not either.
It means exactly what I said it means. Your argument about the use of
the phrase engineer does not address the issues I presented. It was a
deflection, and a disparagement.
>If engineers made the same sort of compromises that C++ made, none of their
>structures would stand up. In software, we are still building bridges out
>of match sticks.
That is a baseless statement made in an authoritative tone. C++ was
designed by an engineer and has been accepted by engineers. Not as
the end of all computer languages amen. But as something useful for
now. We want more and we want better and we will use what we have
until we get it.
>>Other factors which make C++ attractive to engineers: It is
>>widely supported. It is widely documented. It is widely
>>accepted.
>Widely documented eh? Most of the reviews I have seen on C++ texts in
>Computing Reviews have rated them pretty poorly. Basically, what I want
>is to get to a state, where we have quality in software development, not to
>sit back smugly, and believe that everything is OK, because it is widespread.
Phooey! As if there aren't bad texts in every popular discipline.
There are also some very good texts on C++. The fact remains that C++
is well documented. You yourself have provided 40 more pages of such
documentation.
>>---------
>>I am not a mathematician. I am not interested in perfection.
>Well you have chosen the right language there. (Sorry cheap shot,
>couldn't resist :-))
You should, it hurts your credibility and raises people's ire against
you. Much of the time the good points you make are blown out of our
minds by the personal jibes and cheap shots you make. You should
strive for a higher road. IMHO.
>>I am
>>interested in sufficiency. I need a language which is sufficient for
>>the job, not necessarily perfect. It is the job of an engineer to
>>deal with imperfection to achieve an end.
>But in the 'unreal' world of computers, where we are removed from the
>natural and imperfect world, these imperfections are self imposed,
>especially in the case of C++. The power of computers comes from the
>ability to represent the real world, apart from the real world,
>removing the imperfections of the real world. This is the process
>of abstraction.
>In the real world, engineers deal with imperfections that are beyond
>their control. In software, we are building abstract worlds, that are
>completely within our control.
I have never worked on a software project that was completely within
my control. At the micro level, yes, I can make the computer do
anything that it is possible to make a computer do. But this is no
different than any othe form of engineering. At the micro level, an
electronics engineer can make a transistor do whatever a transistor is
capabable of doing.
Engineering is about defining what can be controlled, and then using
that control to make something work. Software engineers can control
the computer just as electronics engineers can control circuits. None
of us work in a perfect world.
> [completely within our control.] When we realise that, then we will
>realise what software development is all about. In fact that is the
>fundamental difference between engineering and software science. It is
>not about excuses. Even average people don't accept the excuse of
>'computer error' anymore, as they realise that we are 100% in control in
>the world of computers.
By this do you mean to say that there are no problems that computing
can't solve? No excuses are necessary? That's silly. Computing has
its limitations just as any othe engineering discipline does.
What is your point about excuses??? Are you saying that all other
engineering disciplines have to make excuses becuase they deal with
imperfection. While we in computing need no excuses because we deal
with perfection?
>It is strange however, that the engineers strive for perfection in the
>hardware they build, that they try to make their processors, and storage
>devices as close to 100% reliable as possible. Engineers are striving
>for precision, while us software people seem to be striving for
>compromise. We will end in a pile of mediocrity. Here we are in the
>software 'profession' admitting more and more compromise. Engineers are
>at least getting better, we are getting worse.
Compromise is a good thing, not a flaw. It is the bridge by which we
are able to cross into the future. Without the compromises made by
C++, the vast quantity of industrial software professionals would have
OO inaccessible to them. C++ provides a pathway to improvement.
Imperfect? Yes. But passable.
The fact that so many software professionals are willing to cross that
bridge belies your assertion that we are all ready to accept
mediocrity. Software professionals *are* getting better, and C++ is
one of the vectors of that improvement.
>>Bemoaning and Railing against the flaws of C++ in an attempt to get
>>engineers to "wake up" and use something better, is a useless effort.
>I don't think so (obviously). But then I am not 'bemoaning and railing',
>or presumptious enough to shake people into metaphorically 'waking up'.
>However, it is worth pointing out the false assumptions upon which C
>and C++ are based. One of those being that programming is engineering.
The term "false assumptions" is unfounded. There is no indication
that the authors or users of C++ are wearing blinders and beleive C++
to be software utopia. One has only to use the language to be rapidly
disuaded of that. The assumptions are that C++ provides a set of
tools for software development which are superior to C. This
assumption is borne out by much experience.
>>We KNOW the flaws of the language, we deal with them daily. You
>>aren't telling us anything new. And you aren't very convincing,
>>because here we are using the language, profitably, in spite of all
>>its flaws.
>Well congratulations, your guru certificate is in the post ;-)
:-p
>This is a relative argument though. When you find that some other
>company is able to produce products five times faster, and ten
>times cheaper, and you are losing customers to them, then the
>commercial reality will sink in.
When I see this, I will closely examine what that company is doing
right, and attempt to emulate them. Currently I am attempting to
emulate those which have chosen to move on from C to C++.
You are saying in effect: Look guys, there's a better way to do these
things. So lets not use the imperfect way, lets find out what the
better way is and use that.
This is laudable, but only to a certain extent. We cannot simply stop
producing until somebody finally decides what the best OOPL is. If we
were to all start using Eifel, then somebody would write a critique of
Eifel. If we all started using Modula III then somebody would write a
critique of that language. And that is good! But it does not mean
that everybody should stop becuase their current language sucks.
>---------------------------
>My original post may have seemed a little insulting to real engineers.
>However, I was trying to get people thinking about what is otherwise
>all to readily accepted terminology. We are in fact misusing the term
>engineering when we apply it to software development. We are abusing it
>by using 'engineering' to give the feeling of a good roll the sleeves up,
>let's get dirty job. It is a shame that some must apply this
>term to themselves to make them sound more relevant and practical than
>the rest. My apologies to the engineering profession on behalf of the
>programming profession.
This is very disparaging. Why do you insult those of us who call
ourselves software engineers. Your use of stereotypes is quite
offensive. You claim to have divined our intentions: "Give them the
feeling of a good roll the sleeves up..." but this assertion is
unfounded. I must interpret it as an attempt to discredit.
>In fact, the need to apply some other professions credentials to
>programming is a sign of the professions insecurity, and immaturity.
>If we are to gain true respectibility in our own right, we must
>develop much better techniques than we have today.
These are incendiary remarks. Are all sofware professionals who
consider themselves to be engineers really insecure and immature?
Why do we need to "gain true respectability"? When did we lose it?
These remarks appear to be attempts at "rabble rousing". Do you
really consider your audience to be scruffy "rabble"?
>There are similarities to engineering, and we can apply engineering
>principles to software production, but 'programming = engineering' is
>not the right equation. In fact programming and poetry have a lot in
>common as both describe some reality, or system, and both should
>be careful about diction (naming things). We need to be eclectic and
>multi-disciplined, in the same way that Leonardo Da Vinci was.
What you are saying is that we need disciplines. I agree.
Multi-displinary? Certainly. Why does this invalidate the
software=engineering equation? Are you saying that engineering
methods cannot be multi-disciplinary? Why do you keep stressing the
difference between software development and engineering. Can you
explain the differences?
--
+---Robert C. Martin---+-RRR---CCC-M-----M-| R.C.M. Consulting |
| rma...@rational.com |-R--R-C----M-M-M-M-| C++/C/Unix Engineering |
| (Uncle Bob.) |-RRR--C----M--M--M-| OOA/OOD/OOP Training |
+----------------------+-R--R--CCC-M-----M-| Product Design & Devel. |
fred j mccall 575-3539
>That programming is engineering is not a doubt in my mind, it is a
>daily reality. I am a software engineer. I do what engineers all
>over the world do, I create, repair and maintain devices which serve
>clients. I make trade-offs. I trade off development time for
>efficiency, accuracy for time to market, perfect languages for
>portability. I trade off lots and lots of things, because that't the
>only way to get the job done.
Sorry, but that's not engineering. Programming isn't engineering any
more than cabinetmaking is architecture. Now, if you elect to add in
things like requirements specification, design (real design, not just
programming off the top of your head) from sound mathematical
principles, etc., you might then be talking about engineering. But
programming as engineering? Nope, sorry, but it's just not so.
--
"Insisting on perfect safety is for people who don't have the balls to live
in the real world." -- Mary Shafer, NASA Ames Dryden
------------------------------------------------------------------------------
Fred....@dseg.ti.com - I don't speak for others and they don't speak for me.
fred j mccall 575-3539
>other users of other languages are much more professional than a lot of the
>C community, in that they recognise the shortcomings of their language, and
>quite openly discuss them, without recourse to the long winded, and
>unhealthy screaming matches that occur on this group.
Since WHEN? You must be getting a different Usenet News than I've
been seeing here.
fred j mccall 575-3539
>40 page critique I posted several weeks ago. You may begin to understand why C++
>is weak and flawed. The critique is from a practical, day to day programmer
>perspective, at the coal face so to speak. What we need is less C gurus, and
>more people who will face the real issues.
C++ is rather like democracy. It is terribly flawed and there are
many theoretically better things. The only thing it has going for it
is that it seems to work better in the real world than anything else
that's around.
fred j mccall 575-3539
>
>I agree, but who mentioned the terms blind, misled, and zombies to start
>with? I'm just humourously playing with your words here :-). Anyway,
>I agree enough of the mud slinging, this group is famous for it.
Ian, it seems to me that most of the 'mud' thrown around here is by
you. Does that mean that it is YOU who are responsible for this
'fame'?
>
>>I know quite well what C++ achieves: it raises the level of abstraction
>>of programmers who would otherwise be using C.
>
>Ah, I see, C is an end goal in itself.
Strawman, since no one said that but you. Typical of people more
interested in throwing mud than in discussion. Of course, I guess
given straw and mud you figure you can make bricks and build
something. The question is whether it is to be simply an edifice to
your own dislikes or if it is to be something constructive and useful
instead. So far, it looks like you're working on the former.
>
>No, that is not my fundamental position. My fundamental position is that
>C++ lacks the precision required of a language, and lacks the control that
>programmers need over a language. From the hundreds of personal positive
>responses I have received, I am not the only one who thinks this, and I am
>not being ignored.
Argumentum ad Populum. All this agreement in private while none is in
public seems just a LITTLE contrived, Ian.
>
>I'm just doing my little bit to make sure that we don't get stuck
with C++.
If you don't like it, Ian, please, by all means, don't use it. And
allow the rest of us a like privilege. If you can't say something
factual instead of argumentum ad hominem, perhaps we'd all be better
served not to waste the time and bandwidth. Of course, if you WOULD
like to point to specific things (i.e., WHY you see C++ as so
inadequate), that might perhaps be useful.
Per Abrahamsen
>>>>> On 25 May 92 14:37:38 GMT, i...@syacus.acus.oz.au (Ian Joyner) said:
Ian> Well, actually it has generated much response in my personal mail. I have
Ian> replied to over 400 mails, many of them with positive comments, so there
Ian> are many people who find this relevant.
Did you receive any useful critique of your critique?
>What you do is basically to examine how useful the various C++
>features are for solving some never explicitly stated problems, and
>how close they are to a never explicitly stated strategy for solving
>these problems.
>It quickly become clear that the problems you want to solve are not
>identical to the problems C++ is designed to solve, and the strategy
>used in C++ is different from the strategy you prefer. Given this, the
>detailed critique becomes uninteresting.
Ian> Still, if you don't find my critique convincing that there are
Ian> problems with C++, you can always go and read the ARM.
I know there are problems with C++. I just don't think you are
addressing them very well.
Ian> It shows you how imprecisely, and unsafely you can design a
Ian> language.
It shows how many tradeoffs you have to make when you design a
language. (If you want to believe that tradeoffs are always either
obvious or unnecessary, read anything by Bertrand Meyer.)
I was hoping that your critique would address these tradeoffs, and
argue why they should have been different. That could have served as
a base for a useful discussion.
Thant Tessman
> C++ is rather like democracy. It is terribly flawed and there are
> many theoretically better things. The only thing it has going for it
> is that it seems to work better in the real world than anything else
> that's around.
No, it shows that people are so desparate for standards that they are
even willing to adopt very bad ones. (But then again, I'm an
anarcho-capitalist.)
thant
Joachim Schrod
> In article <1992May24.0...@tfs.com> er...@tfs.com (Eric Smith) writes:
> >In article <1992May21.1...@syacus.acus.oz.au> i...@syacus.acus.oz.au (Ian Joyner) writes:
> >>It is time to assess how much further it is worth taking the C
> >>experiment. The technology it made compromises for is now well over 20
> >>years old. It is now not really applicable anymore, or at least in five
> >
> >I'm glad to find someone on the net finally who cares about language
> >elegance, and is willing to do whatever is necessary to get rid of bad
> >languages. I hope I can persuade you to join my crusade to get rid of
> >English.
>
> I believe Ian hoped C++ was not yet the international
> standard language, in which case your argument holds no water.
I would like to point out politely, that English is neither `the
international standard language.' Even if you're a native Australian
speaker (which I don't know and don't care). There are still some
other languages around spoken by some people... you know? French,
Spanish, Chinese, Arabic, Russian, just to name a few... Just like
Fortran, Cobol, Pascal, C, Lisp, Prolog, CLU, Scheme, ...
You didn't score against Eric's satiric comments. He pointed out
very good a core problem: That you must communicate with people if
you're doing software development. Software is peopleware. For me
(and obviously for him) this is more important than being able to
write down terms coming from group theory[*]. I want to solve
problems _together_with_other_peoples_, not spending my energy in
language development or in the introduction of new languages. (The
latter is to be made if one work is done better then -- but between
introduction and development of a new development environment is a
large gap.)
> Unfortunately perhaps, I think Ian is wrong, it is too late,
> C++ IS the international standard language right now.
Oops, then it's time that we get an IS, isn't it? It would be even
nice if we, as Non-US citicens, would get more influence in this IS
-- in the moment it looks like ANSI dominates this play... (Not that
it matters to me, I will switch the programming language as I need
it.)
--
Joachim
[*] Please note that I know that group theory may be applied. I'm
working in an Institute for Theoretical Informatics. But I also
know the difference between a math `term' and an Algol-like
function. One is just not able to map it bijectively. Something
our students always learn when they start with algebraic
specifications. ;-)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod Email: sch...@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany