The future of C++?
Mobilusfut
Folks what is the status of C++ now and what is it's likely future?
I see that most linux uses C more than C++
and applications are written more and more in the highly portable Java.
As for windows(if it survives at all) still mostly it's written in C as well
and as for
MFC and ATL it seems as if these component technologies may have seen their
better days. What major new developements will C++ likely contribute to
and what future enhancements to the language are likely to emerge?
Again if you dont like this question please just ignore it I am asking the
question only for the purpose of gaining some more insight into all this.
Thanks John
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
Robert O'Dowd
>
> Question 3.
> Folks what is the status of C++ now and what is it's likely future?
The status is that a standard exists, compilers and libraries are
gradually catching up with the standard, and people are learning how
to use the language more effectively.
I can't comment on *likely* future, but the future I'd like to see
is
a) Stability. Avoid the temptation to extend C++ to address the
latest fads. Give developers a language they can rely on,
rather than having to scratch their heads working out what
has been deprecated or what latest fad will rear its
head next.
b) Compilers increasingly supporting advanced features of the
language. Languages better optimised to avoid temptation
to use system specific hacks to work around problems (eg
performance issues).
c) Increasing knowledge, based on experience, of strengths and
weaknesses of the language when supported by standard
conformant compilers and libraries. This will help in
at least two ways: more documented idioms to make more
effective use of the language, and also identify pitfalls
that will need to be addressed by changing the language
or library.
> I see that most linux uses C more than C++
> and applications are written more and more in the highly portable Java.
That depends on your application domain, I guess. All languages
have their pros and cons. I'd say Java is being used more visibly
(i.e. there seems to be a lot more media hype about Java) but other
languages such as C++ are being used in serious work that is not
visible (eg in domains where doing the job is more important than
making it visible). Usage of C++ (and usage of a number of other
languages) is increasing, but not with the fanfare that is
accompanying Java.
On the "highly portable Java" ... My experience is that portability
of Java is a bit exaggerated. The phrase "write once, debug everywhere"
comes to mind. I'm not claiming that C++ (or implementations of C++)
is perfect, but Java is not a universal solution to portability issues
either.
> As for windows(if it survives at all) still mostly it's written in C as well
> and as for
> MFC and ATL it seems as if these component technologies may have seen their
> better days. What major new developements will C++ likely contribute to
> and what future enhancements to the language are likely to emerge?
> Again if you dont like this question please just ignore it I am asking the
> question only for the purpose of gaining some more insight into all this.
MFC and ATL have probably seen better days, but they are still a
significant
presence in the Microsoft world. I suspect a lot of developers will
follow
whatever trend Microsoft chooses to set because of their dominance in
the
desktop market.
I hope there will not be too many "big bang" evolutions of C++. Some
enhancements I anticipate (or at least hope for) in the future are
a) Multi-threading support. Probably along the lines of a library
to support behaviour (eg mutexes, launching threads) and some
guarantees in the language associated with threads (eg specifying
constraints on what is allowed and what not).
b) Better support of numerics.
c) Increasing scope of the standard library (eg as above to support
multithreading, parallel processing, some capabilities such as
networking support), but done carefully to avoid the trap of a
"everything but the kitchen sink" approach.
Victor Bazarov
> Question 3.
> Folks what is the status of C++ now and what is it's likely future?
Have you tried reading "Design and Evolution of C++"?
> I see that most linux uses C more than C++
?
> and applications are written more and more in the highly portable Java.
??
> As for windows(if it survives at all) still mostly it's written in C as
well
> and as for
> MFC and ATL it seems as if these component technologies may have seen
their
> better days. What major new developements will C++ likely contribute to
> and what future enhancements to the language are likely to emerge?
Huh? Where are you getting those ideas? Some friend whom you trust
for no apparent reason whispered it in your ear?
<toALL>
I don't know, ALL, every week or so, in one C++ newsgroup or another
there is a posting like that, beginning with "Ahh, C++ is dying, nobody
develops anything in it no more. Why learn it when there are better,
shinier languages like <another language here>? No Internet support,
no nottin', some illusive Standard which nobody follows...".
I know I shouldn't complain. I am happy writing C++ programs (and there
is still so much more to write). I am happy learning C++ (and there is
still a lot to learn). But what is there to tell folks like the OP?
I tend to think that the best answer is "it seems that you don't have
any knowledge of what you're trying to judge, maybe you should choose:
either learn more, or drop the topic." But they are unlikely to follow
the advice. It seems rather futile.
</toALL>
> Again if you dont like this question please just ignore it I am asking the
> question only for the purpose of gaining some more insight into all this.
Yeah, right.
John, you seem to have formed your opinion and are looking for support.
Forgive me, it just seems so, I would really like to be mistaken. And
if I am not mistaken, asking a question like yours won't get you far.
You are starting with a wrong premise. It's like asking "All dogs love
climbing trees. Do you know, why?". How do you answer that?
Victor
--
Please remove capital A's from my address when replying by mail
Francis Glassborow
<mobil...@aol.com> writes
>Question 3.
>Folks what is the status of C++ now and what is it's likely future?
>and as for
>MFC and ATL it seems as if these component technologies may have seen their
>better days. What major new developements will C++ likely contribute to
>and what future enhancements to the language are likely to emerge?
>question only for the purpose of gaining some more insight into all this.
The problem with the question is that you make a whole bundle of
assumptions (even though you make them explicitly)
You begin to sound like those who maintain that C++ replaced C (except
that in your case you claim that Java is replacing C++ and that C is
alive and well, these two languages squeezing out C++)
C is used in Linux for the same reasons that it is in many other OS's as
a low-level tool for tweaking the OS because that is what the OS was
written in.
C is good for this low-level stuff, and C++ is good for the kind of OO
and generic programming where compile time checking is valuable. Java
has its own strengths and weaknesses but here is not the place to study
them.
Do not let your experiences + what you read in the press lead you to
generalise to the World as a whole. C, C++ and Java along with such
languages as Fotran, FORTH and APL are all alive and well and being used
by those that understand what they are good for.
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Tom Payne
> Question 3.
> Folks what is the status of C++ now and what is it's likely future?
> I see that most linux uses C more than C++
C is a subset of C++, and there are good reasons to start using the
non-C features of C++ in OS work.
Tom Payne
Stan Brown
>C is a subset of C++
That was true once upon a time, but has not been true for quite a while.
See <http://www.parashift.com/c++-faq-lite/big-picture.html#[6.10]>.
(That answer was written before the adoption of C99, which introduced
some additional incompatibilities.)
--
Stan Brown, Oak Road Systems, Cleveland, Ohio, USA
http://oakroadsystems.com
C++ FAQ Lite: http://www.parashift.com/c++-faq-lite/
the C++ standard: http://webstore.ansi.org/
illegal identifiers: http://oakroadsystems.com/tech/cppredef.htm
more FAQs: http://oakroadsystems.com/tech/faqget.htm
Sam Lindley
"Tom Payne" <t...@roam-thp2.cs.ucr.edu> wrote in message
news:8io32q$22l$1...@pravda.ucr.edu...
> Mobilusfut <mobil...@aol.com> wrote:
> > Question 3.
> > Folks what is the status of C++ now and what is it's likely future?
> > I see that most linux uses C more than C++
>
> C is a subset of C++, and there are good reasons to start using the
> non-C features of C++ in OS work.
Of course, strictly speaking C isn't a subset of C++; there are a few
minor
incompatibilities. In practice, the differences aren't usually relevant.
C++
is just as appropriate for writing low-level (e.g. OS) code as C. I agree
with you that there are good reasons to use the new features of C++ in OS
work and elsewhere.
The question I am interested in is why so much code is still written in
C.
Off the top of the head I can think of the following reasons why people
still choose to code in C:
1) Familiarity. Many C coders simply don't know C++.
2) Complexity. C++ (in its entirety) is much harder to learn well than C.
3) Efficiency. There is a myth that C++ is inherantly slower and / or
always
produces larger binaries than C.
4) Maturity. ANSI C has been around a lot longer than ANSI C++.
5) Portability. Due to 2) and 4) many of C++s newer features are not
compatible across different platforms.
6) Stability. Again due 2) C++ compilers tend to have more bugs, than C
compilers.
7) Backwards compatibility. The original code was written in C or has to
interact with other C code.
In the majority of cases, I don't think any of these reasons are likely
to
be valid; the main reason being that a lot can be gained even by using
just
the most basic features of C++. Taking each point in turn:
1) Just pick a few features which are easy to learn, but very useful in
themselves. For example, new / delete, C++ comments, variable
declarations
at an arbitrary position within a scope and functions in structs.
2) Same as for 1).
3) C source should produce the same output under a C++ compiler as a C
compiler. Judicious use of C++ features according to efficiency
requirements
allows C++ code to be as well optimised for speed or memory as equivalent
C
code.
4), 5), 6) Many of the core features of C++ are quite mature. These
features
are implemented by most compilers and work reliably. If any of these
factors
is a concern, then just use a restricted subset of C++. The mozilla
project,
for instance, has been very successful with this model.
7) It does make a lot of sense to maintain an existing C codebase rather
than rewriting in C++ from scratch, but in many situations it is
advantageous to gradually migrate to C++. extern "C" can be used to use
the
C calling convention from within C++ for compatibility with third-party
code.
There are situations in which C is a better choice than C++, but I think
that C++ is more appropriate in most cases.
Sam Lindley
Victor Bazarov
> Mobilusfut <mobil...@aol.com> wrote:
> > Question 3.
> > Folks what is the status of C++ now and what is it's likely future?
> > I see that most linux uses C more than C++
>
> C is a subset of C++, and there are good reasons to start using the
> non-C features of C++ in OS work.
C is NOT a subset of C++.
Victor
--
Please remove capital A's from my address when replying by mail
Ron Natalie
Stan Brown wrote:
>
> Said t...@roam-thp2.cs.ucr.edu (Tom Payne) in comp.lang.c++.moderated:
> >C is a subset of C++
>
> That was true once upon a time, but has not been true for quite a
while.
>
Actually if your definition of subset is that a C++ compiler must accept
a
legal C program, it was never true. As soon as C with classes introduced
new reserved words or symbols with other meaning (class, friend, operator
...),
C ceased to be a subset.
ka...@gabi-soft.de
|> The question I am interested in is why so much code is still written
|> in C.
Is that much new code still written in C? Some is, but most of what I
see in C is maintainance of code written at least five years ago.
|> Off the top of the head I can think of the following reasons why people
|> still choose to code in C:
|> 1) Familiarity. Many C coders simply don't know C++.
|> 2) Complexity. C++ (in its entirety) is much harder to learn well than C.
|> 3) Efficiency. There is a myth that C++ is inherantly slower and / or
|> always
|> produces larger binaries than C.
|> 4) Maturity. ANSI C has been around a lot longer than ANSI C++.
More important, all C compilers actually implement the previous C
standard. To date, no known compiler implements the C++ standard. In
some shops (but not many), this can be a killer argument.
|> 5) Portability. Due to 2) and 4) many of C++s newer features are not
|> compatible across different platforms.
|> 6) Stability. Again due 2) C++ compilers tend to have more bugs, than C
|> compilers.
|> 7) Backwards compatibility. The original code was written in C or has to
|> interact with other C code.
As I said above, there is an awful lot of C work which is really
maintainance of existing code.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Pete Becker
>
> Stan Brown wrote:
> >
> > Said t...@roam-thp2.cs.ucr.edu (Tom Payne) in comp.lang.c++.moderated:
> > >C is a subset of C++
> >
> > That was true once upon a time, but has not been true for quite a
> while.
> >
> Actually if your definition of subset is that a C++ compiler must
accept
> a
> legal C program, it was never true. As soon as C with classes
introduced
> new reserved words or symbols with other meaning (class, friend,
operator
> ...),
> C ceased to be a subset.
>
On the other hand, if your definition of subset is that with only
trivial changes a C program can be modified to compile as C++ without
changing its meaning and without making it invalid C (which is what most
people really mean when they say that C++ is a superset of C) then it
has always been true (until C99).
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
Contibuting Editor, C/C++ Users Journal (http://www.cuj.com)
Francis Glassborow
>|> The question I am interested in is why so much code is still written
>|> in C.
>
>Is that much new code still written in C? Some is, but most of what I
>see in C is maintainance of code written at least five years ago.
It depends which industry you work in. More to the point is why so much
C code is written in C++ :-)
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
delr...@my-deja.com
only had a C compiler for the hardware involved. We used cfront
to write the application in C++ and then compile it with C.
Unfortunately, the cfront we used did not initialize static constants
correctly in the embedded environment. (There was no main() in our
application, just an _init()) so we had to use the C preprocessor
a little more than is desirable.
Our engineers are significantly more productive in C++ than in C,
so it was worth the extra effort.
Cheers,
delrayva
>
Sent via Deja.com http://www.deja.com/
Before you buy.
ka...@gabi-soft.de
|> On the other hand, if your definition of subset is that with only
|> trivial changes a C program can be modified to compile as C++
|> without changing its meaning and without making it invalid C (which
|> is what most people really mean when they say that C++ is a superset
|> of C) then it has always been true (until C99).
Not quite. C89 didn't require function prototypes, C++ always did. The
conversion is more or less mechanical, but not necessarily trivial.
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Robert O'Dowd
>
> Mobilusfut <mobil...@aol.com> wrote:
> > Question 3.
> > Folks what is the status of C++ now and what is it's likely future?
> > I see that most linux uses C more than C++
>
> C is a subset of C++, and there are good reasons to start using the
> non-C features of C++ in OS work.
>
C is not a strict subset of C++; there are some minor differences even
in C as standardised in 1989 (I think). The more recent C standard
(C99) introduces some features that are not in C++ (some keywords, and
a native complex type that would conflict with the C++ complex class).
As to your comment about using C++ for operating systems development,
I agree. Of course, the choice about C or C++ depends on what
you want the operating system to provide. Horses 4 courses, etc.
ZHN
the future applications of C++ and all that's come about is a discussion of the
ongoing nature of it's origins.
Hey is it possible you are all looking backward. That wouldn't be good if
it were true.
Steve Clamage
Robert Klemme wrote:
>
>
> i doubt whether they will incorporate this into the standard.
> multi-threading is a serious issue that is quite complex - at least as i
> understand it. and it is quite dependant on the underlying OS. i am
> not sure whether the standards body will take on this herculean (?)
> task. does anybody know any better?
Someone would have to submit a proposal to the C++ committee. "Submit
a proposal" doesn't mean just saying, "You guys should add MT to C++."
It means working out the syntax and semantics and showing how it
integrates with the rest of the language, and especially the effect
on the library. (What guarantees are provided for the various functions
and objects in the library in the presence of MT?) And how do
exceptions interact with MT, if at all? (Can you catch an exception
in a different thread? What happens to the rest of the program if
an exception in a thread results in a call to abort?)
It seems to me that the proposal also would have to specify MT
in a way that could reasonably be implemented on a range of platforms
integrated with native threads on the platform. Otherwise, it would
do more harm than good (IMHO).
Although some person or group outside the commitee might choose to do
this huge amount of work, I think the most likely route to success is
the creation of a new New Project within the C++ committee.
--
Steve Clamage, stephen...@sun.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Francis Glassborow
<nos...@nonexistant.com> writes
>C is not a strict subset of C++; there are some minor differences even
>in C as standardised in 1989 (I think). The more recent C standard
>(C99) introduces some features that are not in C++ (some keywords, and
>a native complex type that would conflict with the C++ complex class).
Only in so far as there would then be two types of complex, but they
have different names so I do not view that as any worse that having
char* and string.
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
bruceattah
language, and many C programmers are either sticking with C, or
learning Java (because they know it is an easier skill to
acquire than C++).
I think it is possible that C++ will die fairly soon (i.e.,
become a minority or maintenance-only language) if a few things
are not done, namely these:
(1) Implementors should make garbage collection available as a
compiler option, and trumpet the fact. It should not be
necessary for C++ users to shop for a third-party solution if
they want GC; rather they should be able to rely on it out of
the box.
(2) Good, portable libraries for common OS, networking, GUI and
database tasks should become widely available. They should
integrate well with STL, and support multithreading. Good
libraries do exist currently, but they are third-party products
that are either not widely known or expensive, so that
individual developers cannot rely on having them to hand each
time they sit down in front of a keyboard. It is this reliable
availability of key libraries, rather than the merits of the
language itself, that make Java such an attractive option to so
many.
(3) Compilers should implement the standard (they're getting
closer, which is good).
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
Ron Natalie
bruceattah wrote:
>
> Many students and beginners are now learning Java as a first
> language, and many C programmers are either sticking with C, or
> learning Java (because they know it is an easier skill to
> acquire than C++).
They are fools, Java has it's use, but it's not a substitute for
C++ and lacks the major advantage for existing C programmers that
C++ is compatible with existing C code, Java will not.
>
> I think it is possible that C++ will die fairly soon (i.e.,
> become a minority or maintenance-only language) if a few things
> are not done, namely these:
Yeah, yeah, people been saying the same thing about COBOL.
It's still the language of choice for performance applications.
> (1) Implementors should make garbage collection available as a
> compiler option, and trumpet the fact. It should not be
> necessary for C++ users to shop for a third-party solution if
> they want GC; rather they should be able to rely on it out of
> the box.
You'd have to define what you mean by garbage collection. It would be
incredibly inefficient to try to hunt down all possible memory leaks in
real time on C++.
>
> (2) Good, portable libraries for common OS, networking, GUI and
> database tasks should become widely available. They should
> integrate well with STL, and support multithreading\
I would like to see these too, but I certainly want them to be compatible
with the STANDARD not the STL crap.
C++ is NOT attempting to be a language that guarantees a pigs eye view
of the world like JAVA to assure portability, it is designed as a flexible
language to allow a variety of system and high level applications to be
written in a well structured way.
>
> (3) Compilers should implement the standard (they're getting
> closer, which is good).
This I have no argument with.
Robert O'Dowd
>
> Many students and beginners are now learning Java as a first
> language, and many C programmers are either sticking with C, or
> learning Java (because they know it is an easier skill to
> acquire than C++).
Hmmm.... students and beginners are learning Java because it
is easier to teach and learn. One reason for that is that
the language is simpler than other languages like C++.
There are also some things that are extremely hard to do in
Java, but relatively straight forward in C++. All that
means is that the two languages service different needs,
not that one is fundamentally better than the other.
>
> I think it is possible that C++ will die fairly soon (i.e.,
> become a minority or maintenance-only language) if a few things
> are not done, namely these:
>
> (1) Implementors should make garbage collection available as a
> compiler option, and trumpet the fact. It should not be
> necessary for C++ users to shop for a third-party solution if
> they want GC; rather they should be able to rely on it out of
> the box.
This is good for those who *need* GC out of the box. GC is
an unnecessary burden for those who don't need it, or have
requirements that specifically exclude the use of GC (eg hard
real time requirements and most GC schemes don't exactly
go together well). In other words those who don't need or
want GC will probably not appreciate a compiler that forces
it on them. Although I don't have statistics to back
the assertion, I suspect most C++ programmers neither need
nor want GC.
Given that there are a number of good garbage collectors
in both comercial and public domains (some with source)
obtaining a collector to plug into C++ is not a big chore.
GC is also not a panacea to resource management. For example,
it provides no means of managing things like sockets,
network connections, semaphores --- all resources that,
like memory, are available in finite supply, can be acquired
by a program and will cause headaches if not released
correctly.
>
> (2) Good, portable libraries for common OS, networking, GUI and
> database tasks should become widely available. They should
> integrate well with STL, and support multithreading. Good
> libraries do exist currently, but they are third-party products
> that are either not widely known or expensive, so that
> individual developers cannot rely on having them to hand each
> time they sit down in front of a keyboard. It is this reliable
> availability of key libraries, rather than the merits of the
> language itself, that make Java such an attractive option to so
> many.
There is some truth as well as some fallacy in this argument.
I suspect you'll find that a lot of C++ programmers would
welcome expanding the library to have wider scope.
However, few will want to see the problems that occur
with the Java libary (eg the quality of some parts is
questionable, the "everything but the kitchen sink"
approach can make it difficult to find an existing tool
to do task X).
ZHN
>integrates with the rest of the language, and especially the effect
>on the library. (What guarantees are provided for the various functions
>and objects in the library in the presence of MT?) And how do
>exceptions interact with MT, if at all? (Can you catch an exception
>in a different thread? What happens to the rest of the program if
>an exception in a thread results in a call to abort?)
>
>It seems to me that the proposal also would have to specify MT
>in a way that could reasonably be implemented on a range of platforms
>integrated with native threads on the platform. Otherwise, it would
>do more harm than good (IMHO).
>
>Although some person or group outside the commitee might choose to do
>this huge amount of work, I think the most likely route to success is
>the creation of a new New Project within the C++ committee.
Well if you add Multi threading why stop there why not also go for Graphics and
portability. Really why not? This would be hardware specific but look isn't
the streambuffer class really an assembley language interface in disguise?
Maybe the time has come for C++ to look deep down inside it's own guts so to
speak. Maybe that's where the real improvements will be found. Maybe the
runtime has to changed and made a more "Universal and adaptable and more
flexible" implementation. Lets face facts boys all languages really deal with
machinery and though the trend has tended towards more abstraction the past few
years in that respect C++ never went far enough. Look at Java I mean really
what is java? Java is not "an object oriented language" it's really a portable
high level graphics system that has as much(or even more similarity to Visual
Basic-especially the JFC) than to what is still a fairly low level C++. The
difficulty with C++ is that the real magic is left to the operating system in
conjuring up wndows and check boxes and toon figures flying through the air.
And ofcourse operating systems rely on good old assembley language guys to
write the drivers. Maybe it's time for C++ to team up with those assembley
language guys and make a truly portable low level language. Cant be done?
Look I really think it can be. In the end it may have to do with portable op
codes more than stionary operating systems. A portable operating system.
Isn't that Java at it's core? I mean java doesn't call any windows functions
does it? Java just hijacks the computer. That is really what C++ has to do.
Or at least have that potentiality should it be desired.
In my opinion C++ is in reality a perfect manager for assembley language.
Pete
Francis Glassborow
<battahN...@datametrics.co.uk.invalid> writes
>Many students and beginners are now learning Java as a first
>language, and many C programmers are either sticking with C, or
>learning Java (because they know it is an easier skill to
>acquire than C++).
Many students (age 0-5) learn English as their first language and stick
with it for the rest of their lives. Perhaps this suggests that Arabic
and Chinese are likely to die out soon:)
Well it seems that competent programmers rather prefer to match
languages to tasks rather than force all tasks into the narrow straight
jacket of a single language. However there is a considerable body of
'programmers' who only ever learn one programming language in their
lives though its name changes with the winds of fashion:)
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
bruceattah
>In article <20bd2c3a...@usw-ex0101-006.remarq.com>,
bruceattah
><battahN...@datametrics.co.uk.invalid> writes
>>Many students and beginners are now learning Java as a first
>>language, and many C programmers are either sticking with C, or
>>learning Java (because they know it is an easier skill to
>>acquire than C++).
>
>Many students (age 0-5) learn English as their first language
and stick
>with it for the rest of their lives. Perhaps this suggests that
Arabic
>and Chinese are likely to die out soon:)
I don't think that analogy works, because children first learn
the language that surrounds them, whereas tyro programmers learn
the language that they or their tutors have chosen through some
rational (or quasi-rational) process. Therefore, a programming
language can be killed off this way much more easily than a
natural language (and even natural languages do die out this
way).
>Well it seems that competent programmers rather prefer to match
>languages to tasks rather than force all tasks into the narrow
straight
>jacket of a single language. However there is a considerable
body of
>'programmers' who only ever learn one programming language in
their
>lives though its name changes with the winds of fashion:)
I don't think we should need to learn different languages for
different programming tasks. That we have to do so is, in my
view, a failure of particular languages or their libraries, not
something that is a necessary feature of all programming
languages. For instance, there is no universal truth about
programming languages that means C++ could not have been given
stronger tools for numerical programming that would match the
power of those tools available in the specialist languages
favoured by scientists. Nor is there anything fundamental about
programming languages that says C++ could not ship with a
relational database library equivalent in power to, and possibly
more elegant than, SQL. Again, there is no law of nature that
says Java could not have provided operator overloading or
templates. C-sharp, the Java-like language just announced
Microsoft offers plain structs (absent in Java) for efficient
memory access, as well as a way to use C pointers in marked
blocks of "unsafe" code - just another example that illustrates
that the tradeoffs we make when choosing a library are often
choices between the arbitrary diktats of language designers.
Similarly, although some languages are traditionally
interpreted, and others traditionally compiled to machine code,
most languages could be treated in either way.
So far as I can see, nearly all the tradeoffs that we make when
choosing a language can be represented WITHIN a single language
(one, however, that doesn't yet exist). My suspicion is that the
only inescapable tradeoff is at the level of superficial syntax,
and that even this can be dealt with by software.
Meanwhile, by adding the right libraries and compiler options to
C++, we can future-proof it for the next decade or more - until
that super-language comes in to being.
-----------------------------------------------------------
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
bruceattah
>bruceattah wrote:
>>
>
>Hmmm.... students and beginners are learning Java because it
>is easier to teach and learn. One reason for that is that
>the language is simpler than other languages like C++.
>There are also some things that are extremely hard to do in
>Java, but relatively straight forward in C++. All that
>means is that the two languages service different needs,
>not that one is fundamentally better than the other.
>
What makes Java easier to teach and learn, in my view, is not
its relative lack of power, but mainly the extra things it has
(GC and application libraries) that enable programmers to get
things done that they wouldn't otherwise be able to do without
considerable expertise. Learning Java is rewarding to the
novice, because you get to the point of doing big things sooner.
The slightly cleaned-up syntax also helps. The extra things
mentioned could be added to C++ without breaking the standard as
it now stands.
>> (1) Implementors should make garbage collection available as a
>> compiler option...
>
>This is good for those who *need* GC out of the box. GC is
>an unnecessary burden for those who don't need it...
I reiterate, GC should be available as an *option*. Sure, lots
of applications (maybe even most), don't need it, but at least
the myth that Java beats C++ because C++ is not garbage-
collected would be scotched.
>Given that there are a number of good garbage collectors
>in both comercial and public domains (some with source)
>obtaining a collector to plug into C++ is not a big chore.
That's by-the-by. It is clear that you can't sell C++ on the
basis that such tools are available from third parties.
Management will be more easily convinced by stuff that's built
in; also some houses resist the incorporation of public domain
or GPLed source in their projects.
>I suspect you'll find that a lot of C++ programmers would
>welcome expanding the library to have wider scope.
>However, few will want to see the problems that occur
>with the Java libary (eg the quality of some parts is
>questionable, the "everything but the kitchen sink"
>approach can make it difficult to find an existing tool
>to do task X).
Javasoft have done it the right way around: first let's have the
library - good enough to make us productive, then let's improve
the quality to the point where it deserves respect. The next
step will (or should) be to make it a formal standard. This is
what happened with C++: first we had C-with-classes, then we had
early C++ (no templates &c), now we have a very powerful
language. Anyway, Java enthusiasts often find it's better to go
hunting for an existing tool in a big, fairly well documented
library than to hunt for the same tool in a raft of expensive
textbooks, or a third-party developers' software catalogue.
Phil McRevis
Ron Natalie <r...@sensor.com> spake the secret code
<39591387...@sensor.com> thusly:
>> (2) Good, portable libraries for common OS, networking, GUI and
>> database tasks should become widely available. They should
>> integrate well with STL, and support multithreading\
>
>I would like to see these too, but I certainly want them to be compatible
>with the STANDARD not the STL crap.
I don't understand your comment about "STL crap" here.
When the GUI library needs a list of child windows, it should implement
its own wacky list variation instead of using std::list<>? What would
be the benefit of that? As users of the GUI library we'd have to go
and learn *another* variation of the basic container just to use the
GUI library instead of re-using the existing work done for STL
template classes. This would be a huge mistake in my opinion.
--
<http://www.xmission.com/~legalize/> Legalize Adulthood!
``Ain't it funny that they all fire the pistol,
at the wrong end of the race?''--PDBT
lega...@xmission.com <http://www.xmission.com/~legalize/who/>
Hyman Rosen
> Well if you add Multi threading why stop there why not also go for
> Graphics and portability.
Because multi-threading affects aspects of the language, while graphics
do not.
Charlton Wilbur
> I don't think we should need to learn different languages for
> different programming tasks. That we have to do so is, in my
> view, a failure of particular languages or their libraries, not
> something that is a necessary feature of all programming
> languages.
I'd rather learn a dozen different programming languages, each tailored to
a different approach to a problem or for different preferences, than have
to deal with every feature shoehorned into the same language just so it
can be ticked off on a list. Indeed, some of the languages I like the
most chose different tradeoffs - C and C++, Perl, Smalltalk, Scheme, and
Sather all have very different approaches to problem solving because of
those tradeoffs. I don't think it is possible to have *both* the
strengths of Scheme and the strengths of C in the same language
(especially since one of the strengths of both languages is their
compactness and elegance), and so when I need the strengths of C I use C,
and when I need the strengths of Scheme I use Scheme.
Charlton
--
Charlton Wilbur | Wer bin ich, waer' ich deine Wille nicht?
University of Massachusetts | -- Bruennhilde
cwwi...@music.umass.edu | 1832 - 1841 - 1976 - 1992 - 2001
Ron Natalie
Phil McRevis wrote:
>
> I don't understand your comment about "STL crap" here.
>
> When the GUI library needs a list of child windows, it should implement
> its own wacky list variation instead of using std::list<>?
std::list is not part of STL
Ken Hagan
>
> I reiterate, GC should be available as an *option*. Sure, lots
> of applications (maybe even most), don't need it, but at least
> the myth that Java beats C++ because C++ is not garbage-
> collected would be scotched.
I haven't heard about the perfect garbage collection algorithm, so
presumably we have to choose between various design trade-offs if
we opt for GC. Building it in would make that harder. ("Great
compiler, shame about the GC.")
Furthermore, I can easily imagine software systems where some of
the memory management had to be non-GC (to ensure deterministic
release of resources at appropriate moments) and other areas would
benefit from GC, and if I knew enough about the subject, I could
probably imagine a single app benefitting from two separate GCs.
Therefore, I *hope* that GC always remains a third-party thing.
llewe...@dbritschdot.dsldot.xmissiondot.com
> Francis Glassborow <fra...@robinton.demon.co.uk> wrote:
[snip]
> >Well it seems that competent programmers rather prefer to match
> >languages to tasks rather than force all tasks into the narrow
> straight
> >jacket of a single language. However there is a considerable
> body of
> >'programmers' who only ever learn one programming language in
> their
> >lives though its name changes with the winds of fashion:)
>
> I don't think we should need to learn different languages for
> different programming tasks.
To me, this seems akin to saying 'I don't think construction workers
should need all those different kinds of vehicles. Just one great
big do-it-all machine with a crane, a cement mixer, a shovel, etc,
all rolled in to one.'
But I *like* learning new languages.
> That we have to do so is, in my
> view, a failure of particular languages or their libraries, not
> something that is a necessary feature of all programming
> languages. For instance, there is no universal truth about
> programming languages that means C++ could not have been given
> stronger tools for numerical programming that would match the
> power of those tools available in the specialist languages
> favored by scientists.
> Nor is there anything fundamental about
> programming languages that says C++ could not ship with a
> relational database library equivalent in power to, and possibly
> more elegant than, SQL. Again, there is no law of nature that
> says Java could not have provided operator overloading or
> templates. C-sharp, the Java-like language just announced
> Microsoft offers plain structs (absent in Java) for efficient
> memory access, as well as a way to use C pointers in marked
> blocks of "unsafe" code - just another example that illustrates
> that the tradeoffs we make when choosing a library are often
> choices between the arbitrary diktats of language designers.
> Similarly, although some languages are traditionally
> interpreted, and others traditionally compiled to machine code,
> most languages could be treated in either way.
>
> So far as I can see, nearly all the tradeoffs that we make when
> choosing a language can be represented WITHIN a single language
It seems to me that you are focusing on features, and assuming that
because all of these different features are implementable in some
language, they can and should all be combined into a single
language. I have a multitude of problems with this:
(0) Some languages are designed to encourage a particular way of
thinking about programming (Smalltalk, Eiffel). Would your
super-language, having all possible features, also encourage all
possible ways of thinking about software? If so, how?
(1) Often, what features a language has is less important than how
well or how poorly they work together.
At one time, NeXT delivered a compiler for a language they called
Objective-C++ . This compiler would compile mixed Objective C
and C++ source. However, C++ class hierarchies and Objective C
hierarchies had to remain separate. Objective C objects and C++
objects had different method lookup semantics. This language had
2 different views of object oriented programming that did not
work together. Was Objective C++ a good thing? What if they had
thrown in some Haskell as well?
(2) Some features tend to work against each other, making it difficult
to design a language that supports them both.
Try reading chapter 13 (overloading) of the ISO C++ standard, and
think about how much simpler it could have been if C++ had
disallowed implicit conversions. (I seem to remember Modula-3
disallowed implicit conversions in part for this reason.)
(3) Some languages are designed to work well in a particular
environment.
Because it is difficult to predict/control when the collector will
run, garbage collection is undesirable in many hard real-time
environments. From this viewpoint, *lack* of garbage collection
can be considered feature, even a *necessary* feature. Yet
programmers of ordinary applications find gc to be very
valuable. How does a language support both?
Pointer arithmetic and casts are both often blasted as vile,
unnecessary features. Clearly they are error-prone, and not often
needed by those who write ordinary applications. But how does
one write a device driver or an operating system without such
things? (And if you think an ordinary application programmer
cannot use the *concept* of pointer arithmetic, take a good look
at the STL, and think again.)
(4) Language designers and implementers have finite resources.
C++ as codified in ISO 14882 represents over 18 years of design
and evolution, by many very talented and hard-working
people. How long would it have taken if all the features of
Eiffel, Dylan, and CLOS had been included? (Assume for the
moment such features could have been made appropriate to C++,
though I suspect some could not be made appropriate for C++.)
It has been over 2 years since the standard was finished, and yet
no c++ environment implements it. I will claim the major reason
is the difficulty involved. (For a better example, read up on
the history of Algol 68; I read somewhere (in a HOPL paper, I
think) that the first conforming implementations of Algol 68
emerged in 1977, 9 years after the standard was completed.)
> (one, however, that doesn't yet exist). My suspicion is that the
> only inescapable tradeoff is at the level of superficial syntax,
> and that even this can be dealt with by software.
>
> Meanwhile, by adding the right libraries and compiler options to
> C++, we can future-proof it for the next decade or more - until
> that super-language comes in to being.
>
I do not know that the super-language you are envisioning is
impossible, but I doubt it will become feasible with the next 10
years.
[snip]
Rudy Velthuis
>std::list is not part of STL
Then what is described in 23.2.2 of the standard?
--
Rudy Velthuis
Dennis Yelle
> bruceattah <battahN...@datametrics.co.uk.invalid> writes:
[...]
> > I don't think we should need to learn different languages for
> > different programming tasks.
>
> To me, this seems akin to saying 'I don't think construction workers
> should need all those different kinds of vehicles. Just one great
> big do-it-all machine with a crane, a cement mixer, a shovel, etc,
> all rolled in to one.'
>
> But I *like* learning new languages.
It seems to me that we have three problems:
1. C++ is already so big that few will ever truly master the entire
language.
2. Some things are still missing from C++.
3. It is often very difficult to write a single program
in 2 or more different languages and then link those
pieces together into one working program.
I don't have the answer to these problems, but I do know that
Bjarne Stroustrup said something like this:
Inside C++ there is a smaller simpler language trying to get out.
Perhaps we should be searching for this smaller simpler language.
But that may be one of those tasks that cannot be completed by
attacking it directly. Maybe we need to go thru the process of
adding everything possible to C++, getting that to work, and then
noticing which parts are truly unnecessary, and tossing out those
parts. Unfortunately, I don't expect to live long enough to see
this task completed.
Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here: http://table.jps.net/~vert
bruceattah
>bruceattah <battahN...@datametrics.co.uk.invalid> writes:
>To me, this seems akin to saying 'I don't think construction
workers
> should need all those different kinds of vehicles. Just one
great
> big do-it-all machine with a crane, a cement mixer, a shovel,
etc,
> all rolled in to one.'
I don't see it that way. I'm not talking Heath Robinson here, or
even Swiss Army knife. I think of a general purpose programming
language less as a big, do-everything machine than as a
laboratory or workshop into which tools and machinery (in the
form of modules, or particular expressive constructs) can be
brought as they are needed.
>But I *like* learning new languages.
I don't mind learning new languages, myself. Partly, it's a
critical activity (what strengths and weaknesses does this
language have compared to others?), and partly a process of
discovery, because often the language developer has found a
novel way of facilitating some particular approach to
programming.
That said, I'd be quite happy learning one well-designed
language quickly, and then spending a great deal of time
learning about the many facilities it made available and the
many programming techniques it supported.
>(0) Some languages are designed to encourage a particular way of
> thinking about programming (Smalltalk, Eiffel). Would your
> super-language, having all possible features, also
encourage all
> possible ways of thinking about software? If so, how?
No, but it would enable most and support many. A single language
could support declarative-functional, procedural, OO and generic
programming without pushing the programmer in any one direction.
>(1) Often, what features a language has is less important than
how
> well or how poorly they work together.
That's true.
> At one time, NeXT delivered a compiler for a language they
called
> Objective-C++ . This compiler would compile mixed
Objective C
> and C++ source...
Two complicated grammars combined into one that is even more
complicated? Two distinct object models coexisting but not
integrated? That's not what I'm looking for. That's not a super-
language, but a super-kluge.
>(2) Some features tend to work against each other, making it
difficult
> to design a language that supports them both.
Everyone loves a challenge.
>(3) Some languages are designed to work well in a particular
> environment.
>
> Because it is difficult to predict/control when the
collector will
> run, garbage collection is undesirable in many hard real-
time
> environments. From this viewpoint, *lack* of garbage
collection
> can be considered feature, even a *necessary* feature. Yet
> programmers of ordinary applications find gc to be very
> valuable. How does a language support both?
One way would be to make GC is a compiler option, just like
certain optimizations typically are.
> Pointer arithmetic and casts are both often blasted as vile,
> unnecessary features.
...so the environment makes pointer arithmetic available, and
gives programmers a simple method to permit or prohibit it on a
project-by-project or module-by-module basis. (By default, it's
prohibited, of course.)
>(4) Language designers and implementers have finite resources.
>
> C++ as codified in ISO 14882 represents over 18 years of
design
> and evolution...
C++'s better successor won't take that long, because it's
designers will be standing on the shoulders of giants (and
because the language will have a simpler underlying structure
than C++, being free from the constraints of C source-code
compatibility).
>I do not know that the super-language you are envisioning is
> impossible, but I doubt it will become feasible with the next
10
> years.
I think it will be here before then.
-----------------------------------------------------------
Got questions? Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
ZHN
>a different approach to a problem or for different preferences, than have
>to deal with every feature shoehorned into the same language just so it
>can be ticked off on a list. Indeed, some of the languages I like the
>most chose different tradeoffs - C and C++, Perl, Smalltalk, Scheme, and
>Sather all have very different approaches to problem solving because of
>those tradeoffs. I don't think it is possible to have *both* the
>strengths of Scheme and the strengths of C in the same language
>(especially since one of the strengths of both languages is their
>compactness and elegance), and so when I need the strengths of C I use C,
>and when I need the strengths of Scheme I use Scheme.
>
failure. Look these languages are complex. Each one has it's ins and outs
no
matter their similarity. It takes a lot of time to learn each and even
after
doing two years on each language you may still be balked at calling
yourself an
"expert" And yet at the same time the demands on the industry are growing
leaps and bounds.
There are some new additions that are needed such as XML and
formerly
java-which is really a good idea at bottom and it will be around for a long
time, but then the idea of having to master five six and seven languages
will
almost certainly begin to strain the programming community to the point of
possible DISSILLUSION. Warning!!! do not underestimate human frustrations.
They can get serious and they can reach a breaking point. There is only so
much
that a human being can do. Learning twelve times Microsoft COM or Xwindows
or
even Java will in a short while lead to burnout and confusion. I am happy
thta
I know C++. I know basic too(vb) and I also know some Java and assembly.
But
let me tell you I am woefully frustrated with having spent so much time and
effort using Borland's VCL only to find it completely worthless(though it's
a
good system.) I do not want my time in MFC wasted in a similar fashion.
And
God forbid I find that C++ is now worthless as well!!! I might seriously
consider moving on to another field.
It takes a long time to learn a language and I dont particularly
enjoy
being told two years later that I wasted my time. Languages should rather
be
extended to new functionality rather than having a new "Major" language pop
up
every two years!!!
So why is this happening? One reason only. Proprieatary interests!!!
MOney!!! No other reason. Of course there are details here that I cannot
afford to go into but most of you understand quite well what I am talking
about. The problem is that we are being bandied about so that some big
corporation or other might keep it's interests fully viable. The time will
come when the goverment will have to step in and force standards for new
languages-again I dont have the time to go into it in detail but understand
that the world economy is now riding on the software industry. At some
point
in time someone is going to realize that building these huge software
structures on foundations like Java , VB, and C#
may in fact be a little too trusting in the competence of these guys to set
up
stable reliable software systems that an entire world is banking on.
Quickly, when a jet rolls out of Boeing assembly line doesn't the
goverment test this plane before people are placed on board? YOU Better
believe it!!!
Only my humble opinion
Pete.
Francis Glassborow
writes
>Perhaps we should be searching for this smaller simpler language.
>But that may be one of those tasks that cannot be completed by
>attacking it directly. Maybe we need to go thru the process of
>adding everything possible to C++, getting that to work, and then
>noticing which parts are truly unnecessary, and tossing out those
>parts. Unfortunately, I don't expect to live long enough to see
>this task completed.
Personally, I think it is fundamentally impossible. The concepts and
grammars of languages such as Lisp, Forth and C++ are incompatible. I
once wrote an article (April '97, I think) reporting the final addition
to C++, a language cast that allowed the compiler to be told which
language you were now expressing your ideas in. Perhaps it should not
have been published that month:)
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Dennis Yelle
>
> In article <395CF901...@jps.net>, Dennis Yelle <denn...@jps.net>
> writes
> >Perhaps we should be searching for this smaller simpler language.
> >But that may be one of those tasks that cannot be completed by
> >attacking it directly. Maybe we need to go thru the process of
> >adding everything possible to C++, getting that to work, and then
> >noticing which parts are truly unnecessary, and tossing out those
> >parts. Unfortunately, I don't expect to live long enough to see
> >this task completed.
>
> Personally, I think it is fundamentally impossible. The concepts and
> grammars of languages such as Lisp, Forth and C++ are incompatible.
I will grant you that the grammars of those 3 languages incompatible,
but I do not think that the concepts are incompatible.
Please give at least one example of a concept from Lisp, Forth, or
other computer programming language that you believe is
fundamentally incompatible with C++.
Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here: http://table.jps.net/~vert
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Thant Tessman
Dennis Yelle wrote:
> [...]
> Please give at least one example of a concept from Lisp, Forth, or
> other computer programming language that you believe is
> fundamentally incompatible with C++.
I guess you missed the thread about adding lambda to C++.
-thant
Francis Glassborow
<z...@aol.com> writes
>It takes a long time to learn a language and I dont particularly
>enjoy
>being told two years later that I wasted my time. Languages should rather
>be
>extended to new functionality rather than having a new "Major" language
pop
>up
>every two years!!!
No need to learn fashionable languages, learn useful ones. I know a fair
number of programmers who comfortably work with half a dozen languages.
OTOH, I do not know a single competent programmer who only knows one
computer language, and very few who only use one.
I like C++ and it is very versatile and exercises my ageing brain,
however It is learning other languages that has broadened my
understanding. Programming is about solving problems, and that requires
versatility of thought.
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Francis Glassborow
writes
>I will grant you that the grammars of those 3 languages incompatible,
>but I do not think that the concepts are incompatible.
>other computer programming language that you believe is
>fundamentally incompatible with C++.
Anything I could describe could be forced into expression in C++.
However, it would be ugly and you would be unlikely to learn to think
that way.
I can remember sitting down to write a race control program for the
Warden (English, not US meaning) of our local sailing centre. This was
in days long gone by when many in the UK used something referred to as a
BBC Machine which used a form of BASIC. When I finished the job, the
client looked at the code and declared that it looked nothing like BASIC
as he knew it. He was dead right. It was pure Forth in concept but
expressed in BASIC. I was thinking in Forth and expressing it in BASIC.
Without the internalised design I could never have delivered the product
in a single day (yes it worked and ran for several years without any
further work, mind you it was only 2000 odd lines)
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Dennis Yelle
>
> Dennis Yelle wrote:
> > [...]
> > Please give at least one example of a concept from Lisp, Forth, or
> > other computer programming language that you believe is
> > fundamentally incompatible with C++.
>
I probably missed part of it, my newsfeed for this group was unreliable
for a while, but I do seem to remember that at least some of the
participants of that thread were discussing how lambda could be added
to C++. So, at least that (sub?)group of people did not believe that
it was fundamentally incompatible with C++.
I think Francis Glassborow was exactly right when he said:
Anything I could describe could be forced into expression in C++.
Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here: http://table.jps.net/~vert
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Charlton Wilbur
I said:
> >I'd rather learn a dozen different programming languages, each tailored to
> >a different approach to a problem or for different preferences, than have
> >to deal with every feature shoehorned into the same language just so it
> >can be ticked off on a list. Indeed, some of the languages I like the
> >most chose different tradeoffs - C and C++, Perl, Smalltalk, Scheme, and
> >Sather all have very different approaches to problem solving because of
> >those tradeoffs. I don't think it is possible to have *both* the
> >strengths of Scheme and the strengths of C in the same language
> >(especially since one of the strengths of both languages is their
> >compactness and elegance), and so when I need the strengths of C I use C,
> >and when I need the strengths of Scheme I use Scheme.
To which Pete replied:
> N0 I'm sorry but that is absolutely wrong and it it in fact a sign of
> sure failure. Look these languages are complex. Each one has it's ins
> and outs no matter their similarity. It takes a lot of time to learn
> each and even after doing two years on each language you may still be
> balked at calling yourself an "expert" And yet at the same time the
> demands on the industry are growing leaps and bounds.
It is much easier to become a master of a small language like Scheme than
it is to master a large language like C++.
> It takes a long time to learn a language and I dont particularly enjoy
> being told two years later that I wasted my time. Languages should
> rather be extended to new functionality rather than having a new
> "Major" language pop up every two years!!!
There are astoundingly few Big New Ideas, and I have found, having worked
with probably twelve to fifteen programming languages ranging from the
esoteric (ML, Oberon) to the wildly popular (C++, Perl) that there is very
little truly new happening in each new language. I picked up Tcl in about
a week - it was an interesting mix of stuff I recognized from LISP, stuff
I recognized from Perl, and stuff I recognized from the shell. After
about three weeks working in it, I wouldn't have called myself an *expert*
Tcl programmer, but I was producing solid, robust code that did what it
was supposed to do.
And I'd say that any programmer without the brainpower to learn a new
computer language every two years ought to give it up and become a
pointy-haired boss. In the four years I was in college, I picked up
nearly a dozen languages; in the five years since, I've probably picked up
a half-dozen more.
> So why is this happening? One reason only. Proprieatary
> interests!!! MOney!!! No other reason. Of course there are details
> here that I cannot afford to go into but most of you understand quite
> well what I am talking about. The problem is that we are being
> bandied about so that some big corporation or other might keep it's
> interests fully viable.
None of the programming languages I mentioned - Smalltalk, Sather, Perl,
Scheme, C, C++ -- is proprietary in the sense that Java, Visual Basic, or
C++ are. It might be argued that a language like Perl is at the mercy of
the implementors/porters, since there's no Perl standard aside from the
implementation. Different languages arise because there is a need for
different languages, because they have different expressive power. In the
case of Microsoft, Netscape, and Sun, it's hardly surprising that they
created such things as Java, Javascript, Visual Basic, and C# in order to
gain competitive advantage; but overall, new languages appear because they
offer a new way of thinking and a new way of solving problems.
When you deal with a *standard* programming language, such as Scheme, C,
or C++, you are dealing with a known quantity. The language *must* behave
in a particular fashion if you give it a particular program, or the
compiler/interpreter is broken. You are free to choose the implementation
and set of libraries that works best for you, your company, and your
project. It's only when you choose a proprietary programming language -
Java, Visual Basic, C# -- or when you commit to a particular library --
MFC, GTK++ -- that you run into problems.
In an earlier part of your message (which I snipped), you mentioned that
you know Java, C++, Visual Basic, and some assembly language. That's a
pretty restricted set - C++ and Java are quite closely related, and Visual
Basic is really best used as a scripting language for COM objects. Why not
try to write some things in Scheme or LISP just to see another approach to
thinking about projects (object-oriented vs. functional)? Or writing some
things in Smalltalk or LISP to see another approach to data types and
binding?
> The time will come when the goverment will have to step in and force
> standards for new languages-again I dont have the time to go into it
> in detail but understand that the world economy is now riding on the
> software industry. At some point in time someone is going to realize
> that building these huge software structures on foundations like Java
> , VB, and C# may in fact be a little too trusting in the competence of
> these guys to set up stable reliable software systems that an entire
> world is banking on.
Mechanical and civil engineers are required to have professional engineer
certifications from a state agency to work as engineers in any U.S. state.
I eagerly await the day that software engineers have to be similarly
certified - and I'm not talking about Microsoft certification, either.
That will solve the problem much more effectively than government-mandated
standards for programming languages (ever heard of Ada?).
And the "new economy" is what used to be known as a "speculative bubble,"
but that's rather off-topic for this newsgroup, so I'll leave it at that.
Charlton
--
Charlton Wilbur | Wer bin ich, waer' ich deine Wille nicht?
University of Massachusetts | -- Bruennhilde
cwwi...@music.umass.edu | 1832 - 1841 - 1976 - 1992 - 2001
Tony Wingo
>Many students and beginners are now learning Java as a first
>language, and many C programmers are either sticking with C, or
>learning Java (because they know it is an easier skill to
>acquire than C++).
Yeah, and 10-15 years ago many students and beginners were learning
BASIC as a first language (because they know it is an easier skill to
acquire than C). Yet BASIC never did replace C in the real world.
>
>I think it is possible that C++ will die fairly soon (i.e.,
>become a minority or maintenance-only language) if a few things
>are not done, namely these:
>
>(1) Implementors should make garbage collection available as a
>compiler option, and trumpet the fact. It should not be
>necessary for C++ users to shop for a third-party solution if
>they want GC; rather they should be able to rely on it out of
>the box.
I wrote my first program (in FORTRAN II) in 1969, so I've been doing
this for some three decades, and in that time I've seen a lot of
languages come and go. And I've heard a lot of predictions about what's
going to come and what's going to go, virtually all of which turned out
to be dead wrong. (Remember when the Japanese were going to take over
the computing world with Prolog? Or all those diatribes by pundits about
how any programmer that didn't learn Ada immediately would be out of
work in a year?)
The comp.* hierarchy is full of heated discussions about what C++ (or C
or Pascal or Lisp or FORTRAN...) needs, or why language A is better than
language B, or why language C is in immanent danger of demise. The
common characteristic of all these discussions is that the arguers are
invariably arguing from the implicit position that the problem domain
that they are used to is the only problem domain of importance.
Yes, C++ is a complex language. But one of the consequences of that
complexity is a generality that allows it to span more problem domains
than any other language I am familiar with. For all of its virtues, you
cannot write realistic I/O drivers in Java. Nor can you do large scale
numeric work (at least until the VM's the a WHOLE lot more efficient).
That being said, there are still some problem domains that C++ doesn't
address well. For instance, I wouldn't wand to try to do the kind of
inference that Prolog in C++. And this fact give the lie to this idea
that there should be one universal language. There are just too many
problem domains, and too many ways of thinking about the solutions for
that to be possible.
-t
John Nagle
>
> Thant Tessman wrote:
> >
> > Dennis Yelle wrote:
> > > [...]
> > > Please give at least one example of a concept from Lisp, Forth, or
> > > other computer programming language that you believe is
> > > fundamentally incompatible with C++.
EVAL. C++ being a hard-compiled language, you can't read
in C++ source code from a running program and execute it.
This is probably a good thing. Even in LISP and Perl,
which have EVAL, it's not used much.
John Nagle
Animats
llewe...@dbritschdot.dsldot.xmissiondot.com
[snip]
> > Pointer arithmetic and casts are both often blasted as vile,
> > unnecessary features.
>
> ...so the environment makes pointer arithmetic available, and
> gives programmers a simple method to permit or prohibit it on a
> project-by-project or module-by-module basis. (By default, it's
> prohibited, of course.)
>
I believe Modula-3 has several features, including pointer arithmetic,
which are labeled 'unsafe' and can only be used in modules
explicitly declared 'unsafe'.
Mike Dimmick
news:395F8188...@jps.net...
> Francis Glassborow wrote:
> >
> > In article <395CF901...@jps.net>, Dennis Yelle <denn...@jps.net>
> > writes
> > >Perhaps we should be searching for this smaller simpler language.
> > >But that may be one of those tasks that cannot be completed by
> > >attacking it directly. Maybe we need to go thru the process of
> > >adding everything possible to C++, getting that to work, and then
> > >noticing which parts are truly unnecessary, and tossing out those
> > >parts. Unfortunately, I don't expect to live long enough to see
> > >this task completed.
> >
> > Personally, I think it is fundamentally impossible. The concepts and
> > grammars of languages such as Lisp, Forth and C++ are incompatible.
>
> but I do not think that the concepts are incompatible.
> other computer programming language that you believe is
> fundamentally incompatible with C++.
I thought I'd have a go at biting this one.
Having recently concluded my level 2 CS degree module entitled "Programming
Language Concepts and Paradigms" (the names these lecturers think up...)
and
having programmed using a somewhat different paradigm for about half the
course, I felt this was a good example.
For the aforementioned portion, we were using the programming language
'Miranda', which is referred to as a functional language. Here's a quick
snippet of Miranda code:
|| I decided to insert error conditions for illegal n
|| n is legal so long as it is positive and an integer
factorial 0 = 1
factorial n
= error "Argument must be integer", if ~(integer n)
= error "Undefined for -ve n", if n < 0
= n * factorial (n - 1), otherwise
That is a complete program, runnable from within the Miranda runtime
system,
obviously, which you do with:
> factorial 12
479001600
Miranda has basically three types, num (any number to any precision), bool
(True and False), and char, and you can define your own enumerations. You
can also do constructed types; I won't go into these here but suffice to
say
that binary trees are certainly possible.
The equivalent C++ would be along the lines of (note I'm doing this without
a reference manual handy, I'm moving house on Saturday and all my manuals
are packed up...):
class undefined: public exception {
char* whatis() {return "Undefined for -ve n";}
};
int factorial (int n)
{
if (n < 0) throw undefined;
if (n == 0) return 1;
return n * factorial (n - 1);
}
That was just a quick sample, now here's a real demo of the power of
Miranda: a function which compares two lists and returns the number of
items which were present in the same position in both lists. Not hard,
I'll
grant you, but in Miranda, extremely short.
> matches [] x = 0
> matches x [] = 0
> matches (a:x) (b:y)
> = 1 + matches x y, if a = b
> = matches x y, otherwise
> matches [3,5,7,9] [1,5,7,4]
2
> matches "cat" "dog"
0
> matches "rat" "hamster"
1
If you've not seen it before, the constructions above do pattern matching.
Where an exact pattern (such as the empty list []) exists on the left-hand
side, that matches first, then any remaining arguments of the matched line
are set to the corresponding parameters. If the first pattern fails, the
next is tried, and so on until the patterns are exhausted.
When a pattern (a:x) is supplied, that tells the compiler/runtime to match
any list with one or more item, with 'a' set to the first item in the list,
and 'x' to the remainder of the list. So supplying [3,5,7,9] will set 'a'
to 3 and 'x' to [5,7,9].
A couple of things of note. The above function is automatically
polymorphic; it will work on lists of any type at all (demos of 'num' and
'char' types above). Secondly, note that the arguments are separated
merely
by a space. This allows a technique known as Currying, where you can say
> cat_matches = matches "cat"
> cat_matches "dog"
0
> cat_matches "rat"
2
Miranda also supports passing functions as parameters (so does C++ but only
through function pointers...); there's a library function 'map' which can
be
used to perform an operation over a list:
> map cat_matches ["rat","dog","car"]
[2,0,2]
> map (matches "dog") ["log","frog","pig"]
[2,0,1]
The ultimate in list comprehension code is the quicksort:
quicksort [] = []
quicksort (a:x) = quicksort [i | i <- x; i < a]
++ [a] ++
quicksort [j | j <- x; j >= a]
The list comprehension [i | i <- x; i < a] means "Make a list of all the
i's, in sequence, where i is taken from x and i < a."
Doing any of the above in C++, /because/ C++ is an imperative language,
means detailing to the compiler exactly what to do in what order. In
Miranda, you let the compiler and runtime work it out. The disadvantage is
of course that you cannot specify how it does it; it may or may not come up
with a timely solution and if it doesn't, there's no way to change it.
Then
too, most DP work is much more easily performed with an imperative
language.
Similarly, Prolog (termed a 'logical language') is very good at the pattern
matching necessary for natural language processing; the disadvantage is
that
it's slow.
My feeling is to use functional and logical languages to express the
problem
and test your algorithm, before working through the slog of how to
represent
that properly in an imperative manner.
Just my, erm, 50 cents.
--
Mike Dimmick
Thant Tessman
Dennis Yelle wrote:
>
> Thant Tessman wrote:
> >
> > Dennis Yelle wrote:
> > > [...]
> > > Please give at least one example of a concept from Lisp, Forth, or
> > > other computer programming language that you believe is
> > > fundamentally incompatible with C++.
> >
> > I guess you missed the thread about adding lambda to C++.
>
> I probably missed part of it, my newsfeed for this group was unreliable
> for a while, but I do seem to remember that at least some of the
> participants of that thread were discussing how lambda could be added
> to C++. So, at least that (sub?)group of people did not believe that
> it was fundamentally incompatible with C++.
Lambda can already be simulated (very poorly) in C++ with a very tricky
use of templates. But to do lambda correctly, you need closures; and to
do closures correctly, you need automatic memory management. Adding
lambda to C++ in any genuine sense would radically change the nature of
the language, and in the process forego what many (most?) C++
programmers consider its strengths.
I would be delighted to see Bjarne Stroustrup and Alexander Stepanov
design their smaller language hidden within C++ -- not because it would
be a chance for them to add all the features on my particular
programming language wish-list, rather because it would be a chance to
design a language with C++'s strengths and without C++'s weaknesses.
Such a language would bear little resembance to Forth or Scheme.
Sadly, as I think even Stroustrup would agree, such a language would not
get the kind of attention C++ has. The sentiments expressed in your post
and others in this thread are yet more proof that the effort that has
gone into extending and 'refining' C++ (and to its creation in the first
place) must be largely attributed to the unwillingness of its advocates
to give up the effort they've already put into learning and using it
(and C before it). Strangely, this is simultaneously despite *and*
because of the fact that C++ is not one of the easier languages to
learn.
In an earlier post, you wrote:
> [...] Maybe we need to go thru the process of
> adding everything possible to C++, getting that to work, and then
> noticing which parts are truly unnecessary, and tossing out those
> parts. Unfortunately, I don't expect to live long enough to see
> this task completed.
Here's a quote from the "Revised^5 Report on the Algorithmic Language
Scheme":
"Programming languages should be designed not by piling feature on top
of feature, but by removing the weaknesses and restrictions that make
additional features appear necessary." I bring up Scheme also because it
contains a construct called "call-with-current-continuation" which is my
favorite example of a programming language abstraction that flat-out
can't be added to C++ (except in the uninteresting sense that C++ can be
used to implement Scheme itself).
-thant
Tony
ZHN <z...@aol.com> wrote in message
news:20000627200305...@ng-cs1.aol.com...
> Well if you add Multi threading why stop there why not also go for
Graphics and
Isn't the purpose of the std _library_ portability?
Thant Tessman
John Nagle wrote:
>
> Dennis Yelle wrote:
> >
> > Thant Tessman wrote:
> > >
> > > Dennis Yelle wrote:
> > > > [...]
> > > > Please give at least one example of a concept from Lisp, Forth, or
> > > > other computer programming language that you believe is
> > > > fundamentally incompatible with C++.
>
> EVAL. C++ being a hard-compiled language, you can't read
> in C++ source code from a running program and execute it.
Being hard-compiled has nothing to do with it. The question is whether
or not you want to carry around a compiler/linker in your executable.
This is entirely practical in a language as relatively easy to implement
as Scheme. And there are "hard-compiled" implementations of Scheme (and
even Lisp I assume) that support eval.
> This is probably a good thing. Even in LISP and Perl,
> which have EVAL, it's not used much.
Eval is good for when you want to interact with a running program using
the language itself. But language implementations that support eval tend
to be interactive already (whether compiled or interpreted). For such
implementations, eval is cheap to add, but doesn't buy you much more
than you already have. That's why eval isn't used much.
In other words, the concept of 'eval' is incredibly valuable. It's just
that people tend to use it implicitly in the form of an interactive
development environment instead of explicitly in a running executable.
What makes eval impractical for C++ is:
- the massiveness of C++ compilers,
- the fact that C++ (and Java) tend to be much
less succinct than Lisp/Scheme, making interactive
development much more awkward,
- the fact that memory-related errors will tend to
bring down your environment along with the program.
-thant
Tony
<llewe...@dbritschdot.dsldot.xmissiondot.com> wrote in message
news:m2wvj7z...@brownie.frogger.foobar.snot...
> bruceattah <battahN...@datametrics.co.uk.invalid> writes:
>
> > Francis Glassborow <fra...@robinton.demon.co.uk> wrote:
> [snip]
> > >Well it seems that competent programmers rather prefer to match
> > >languages to tasks rather than force all tasks into the narrow
> > straight
> > >jacket of a single language. However there is a considerable
> > body of
> > >'programmers' who only ever learn one programming language in
> > their
> > >lives though its name changes with the winds of fashion:)
> >
> > I don't think we should need to learn different languages for
> > different programming tasks.
>
> To me, this seems akin to saying 'I don't think construction workers
> should need all those different kinds of vehicles. Just one great
> big do-it-all machine with a crane, a cement mixer, a shovel, etc,
> all rolled in to one.'
That analogy doesn't work for me. The "tools" are the classes, libraries
etc. that you build from the language. Perhaps the language is better
thought of as elements like hydrogen, and oxygen. Most people don't really
work with hydrogen directly on a daily basis but they sure do admire being
able to drink water (H2O)!
Phil McRevis
Tony Wingo <wi...@spamcop.net> spake the secret code
<wingo-352CEE....@nntp.best.com> thusly:
>That being said, there are still some problem domains that C++ doesn't
>address well. For instance, I wouldn't wand to try to do the kind of
>inference that Prolog in C++.
I've seen this done by hooking in a little prolog engine (written in
C++) to which you submit your queries. It was kinda cool because you
could use prolog-isms for the parts that prolog was well suited for
and use C++-isms for everything else. I think the engine came as a
library that was available as open source from a university. I can
track things down a little more specifically if you have an interest.
--
<http://www.xmission.com/~legalize/> Legalize Adulthood!
``Ain't it funny that they all fire the pistol,
at the wrong end of the race?''--PDBT
lega...@xmission.com <http://www.xmission.com/~legalize/who/>
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
Hyman Rosen
> Lambda can already be simulated (very poorly) in C++ with a very
> tricky use of templates.
It's really not that bad. Try <http://lambda.cs.utu.fi/>. You have
to get used to the embedded language in which you write the lambdas,
but short expression functions are quite simple.
> But to do lambda correctly, you need closures; and to
> do closures correctly, you need automatic memory management.
Not so. The lambda library above lets lambda functions refer to
variables in scope when they are created, and forbids such functions
to be called if the lifetime of those variables has ended. This is a
perfectly natural restriction for C++.
> Adding lambda to C++ in any genuine sense would radically change the
> nature of the language, and in the process forego what many (most?)
> C++ programmers consider its strengths.
Again, I don't think so.
> Sadly, as I think even Stroustrup would agree, such a language would not
> get the kind of attention C++ has. The sentiments expressed in your post
> and others in this thread are yet more proof that the effort that has
> gone into extending and 'refining' C++ (and to its creation in the first
> place) must be largely attributed to the unwillingness of its advocates
> to give up the effort they've already put into learning and using it
> (and C before it). Strangely, this is simultaneously despite *and*
> because of the fact that C++ is not one of the easier languages to
> learn.
The interoperability with C is vital. The syntax is abysmal.
> "Programming languages should be designed not by piling feature on top
> of feature, but by removing the weaknesses and restrictions that make
> additional features appear necessary." I bring up Scheme also because it
> contains a construct called "call-with-current-continuation" which is my
> favorite example of a programming language abstraction that flat-out
> can't be added to C++ (except in the uninteresting sense that C++ can be
> used to implement Scheme itself).
I would argue that C++ already has some of this economy of design in it.
I admit that sometimes it's well-hidden :-) And I agree with you about
call/cc. It's really a remarkable feature, and totally unimplementable
and meaningless in a typical stack-based, non garbage-collected language.
I don't know if you remember or saw, but there was a paper published a
few years ago, I think in TOPLAS, that started off by saying that all
the other papers were writing about concurrent programming, as if to say
that purely sequential progarms were well understood. They then proceeded
to demonstrate what you could do with purely sequential programs given
call/cc:-)
Matthias Meixner
[...]
)
) My feeling is to use functional and logical languages to express the
) problem
) and test your algorithm, before working through the slog of how to
) represent
) that properly in an imperative manner.
This is probably only true for data-processing, that has limited control
flow and is probably not useful at all, when your problem domain is
mainly control-flow or I/O dominated.
- Matthias Meixner
--
Matthias Meixner mei...@rbg.informatik.tu-darmstadt.de
Technische Universität Darmstadt
Rechnerbetriebsgruppe Telefon (+49) 6151 16 6670
Wilhelminenstraße 7, D-64283 Darmstadt, Germany Fax (+49) 6151 16 4701
Tony
Steve Clamage <stephen...@sun.com> wrote in message
news:395242A9...@sun.com...
>
> Robert Klemme wrote:
> >
> >
> > i doubt whether they will incorporate this into the standard.
> > multi-threading is a serious issue that is quite complex - at least as i
> > understand it. and it is quite dependant on the underlying OS. i am
> > not sure whether the standards body will take on this herculean (?)
> > task. does anybody know any better?
>
> Someone would have to submit a proposal to the C++ committee. "Submit
> a proposal" doesn't mean just saying, "You guys should add MT to C++."
> It means working out the syntax and semantics and showing how it
> integrates with the rest of the language, and especially the effect
> on the library.
Gee, I wish I had someone to just hand me stuff that could be taken credit
of and without paying anyone too! Are the standards guys on a high horse or
what?
BTW, C++ doesn't need MORE, it needs LESS.
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Thant Tessman
Hyman Rosen wrote:
> Thant Tessman <th...@acm.org> writes:
> > Lambda can already be simulated (very poorly) in C++ with a very
> > tricky use of templates.
>
> It's really not that bad. Try <http://lambda.cs.utu.fi/>. You have
> to get used to the embedded language in which you write the lambdas,
> but short expression functions are quite simple.
This kind of stuff is amazing testimony to the power of templates--and
occasionally genuinely useful. But it just doesn't measure up to the
real thing. Issues like memory management, awkward syntax, and argument
calling conventions can never really be pushed out of the way.
[...]
-thant
Hyman Rosen
> Issues like memory management, awkward syntax, and argument
> calling conventions can never really be pushed out of the way.
A statement that easily applies to C++ as a whole :-)
llewe...@dbritschdot.dsldot.xmissiondot.com
[snip]
> I would be delighted to see Bjarne Stroustrup and Alexander Stepanov
> design their smaller language hidden within C++ -- not because it would
> be a chance for them to add all the features on my particular
> programming language wish-list, rather because it would be a chance to
> design a language with C++'s strengths and without C++'s weaknesses.
> Such a language would bear little resembance to Forth or Scheme.
I cannot find a url right now, but Ben Wether and Damian Conway (while
at Monash university Austrailia, apparently) wrote a paper on a
language called SPECS (Significaly Prettier and Easier C++ Syntax).
Thant Tessman <th...@acm.org> writes:
>
> Sadly, as I think even Stroustrup would agree, such a language would not
> get the kind of attention C++ has.
[snip]
To the best of my knowledge, SPECS has gotten no attention at all...
Steve Clamage
Tony wrote:
>
> Steve Clamage <stephen...@sun.com> wrote in message
> news:395242A9...@sun.com...
> >
> > Robert Klemme wrote:
> > >
> > >
> > > i doubt whether they will incorporate this into the standard.
> > > multi-threading is a serious issue that is quite complex - at least
as i
> > > understand it. and it is quite dependant on the underlying OS. i am
> > > not sure whether the standards body will take on this herculean (?)
> > > task. does anybody know any better?
> >
> > Someone would have to submit a proposal to the C++ committee. "Submit
> > a proposal" doesn't mean just saying, "You guys should add MT to C++."
> > It means working out the syntax and semantics and showing how it
> > integrates with the rest of the language, and especially the effect
> > on the library.
>
> Gee, I wish I had someone to just hand me stuff that could be taken
credit
> of and without paying anyone too! Are the standards guys on a high horse
or
> what?
I don't know whether that remark is a troll for flames, or an
indication of total unfamiliarity with the process. Refer to the
comp.std.c++ FAQ at http://reality.sgi.com/austern_mti/std-c++/faq.html
for information on how the C++ committee does its work. D&E ("The
Design and Evolution of C++" by Bjarne Stroustrup) also has a
discussion of how features are proposed and evaluted.
The situation has nothing to do with taking credit for the work of
others. Committee members are not identified by name in the ISO
standard. The work is understood to be the joint effort of many:
official members as well as contributors who are not on the committee.
Your remark can be viewed from another perspective: Committee members
are not only unpaid volunteers, we must pay to participate. We set
our agenda based on what we think are important issues, based on our
own analyses, suggestions (or demands) from other standards-
related bodies, and from the general public. Evidence of the latter
can be found in the FAQ mentioned above, regarding public-comment
periods and our procedures on Defect Reports. In addition, anyone
can join the J16 committee; it is not an exclusive club.
So someone comes along and says, "I have a half-baked idea for a
feature that would help me a lot. You unpaid volunteers should do the
work necessary to flesh it out and integrate it into the language, so
that my job will be easier. But of course I won't invest any of my
own effort in the process. Let me know when you are done."
If the suggestion interests one or more committee members, they might
take on the job. In any case, SOMEONE has to do the work. If those
who propose a feature are unwilling to invest time and effort in
defining it, how can they expect anyone else to do so?
--
Steve Clamage, stephen...@sun.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
Hyman Rosen
> > a proposal" doesn't mean just saying, "You guys should add MT to C++."
> > It means working out the syntax and semantics and showing how it
> > integrates with the rest of the language, and especially the effect
> > on the library.
>
> Gee, I wish I had someone to just hand me stuff that could be taken
credit
> of and without paying anyone too! Are the standards guys on a high horse
or
> what?
At the point where you were making such a proposal, especially for
multi-threading, you would be a member of the committee. You aren't
paying them to produce a proposal either; why should they add it
just because you want it?
> BTW, C++ doesn't need MORE, it needs LESS.
C++ desperately needs multi-threading as part of the language. Many
C++ developers are using it for this purpose already, and lack of a
standard makes it difficult to know what will work.
ka...@gabi-soft.de
"Tony" <to...@my.isp> writes:
|> > Someone would have to submit a proposal to the C++
|> > committee. "Submit a proposal" doesn't mean just saying, "You guys
|> > should add MT to C++." It means working out the syntax and
|> > semantics and showing how it integrates with the rest of the
|> > language, and especially the effect on the library.
|> Gee, I wish I had someone to just hand me stuff that could be taken
|> credit of and without paying anyone too! Are the standards guys on a
|> high horse or what?
The "standards guys" are unpaid volonteers, who have full time paid jobs
in addition to the work they do for the standards committee. If the
issue isn't important enough for you to write up a serious proposal, why
should it be important enough for them?
--
James Kanze mailto:ka...@gabi-soft.de
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Francis Glassborow
In article <jd395.8276$oh5.6...@bgtnsc04-news.ops.worldnet.att.net>,
Tony <to...@my.isp> writes
>> Someone would have to submit a proposal to the C++ committee. "Submit
>> a proposal" doesn't mean just saying, "You guys should add MT to C++."
>> It means working out the syntax and semantics and showing how it
>> integrates with the rest of the language, and especially the effect
>> on the library.
>
>Gee, I wish I had someone to just hand me stuff that could be taken credit
>of and without paying anyone too! Are the standards guys on a high horse
or
>what?
Maybe you are referring to such bodies as ISO, I hope so because a
reading of what you wrote seems deeply offensive to those people who
actually do the work of standardising such things as computing
languages. None of them are paid, indeed some even fund themselves (and
that comes out at several thousand dollars a year in actual cash outflow
let alone the hundreds of hours of unpaid work.
>
>BTW, C++ doesn't need MORE, it needs LESS.
And writing short letters is harder work than writing long ones:)
Francis Glassborow Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
James Kuyper
....
> > Someone would have to submit a proposal to the C++ committee. "Submit
> > a proposal" doesn't mean just saying, "You guys should add MT to C++."
> > It means working out the syntax and semantics and showing how it
> > integrates with the rest of the language, and especially the effect
> > on the library.
>
> Gee, I wish I had someone to just hand me stuff that could be taken
credit
> of and without paying anyone too! Are the standards guys on a high horse
or
> what?
The standard is a volunteer operation, and correspondingly way
understaffed. If you want something done, it must either be important
enough to you to justify doing the work yourself, or you must convince
someone else that it's important enough for them to do the work instead.
If it's not important enough to you, you'll have a hard time convincing
them it's important enough for them. You want credit? Join your national
body and volunteer, and you'll be rewarded with all the credit you can
handle (and all the blame as well).
Michael S. Terrazas
Tony <to...@my.isp> wrote in message
news:jd395.8276$oh5.6...@bgtnsc04-news.ops.worldnet.att.net...
> Gee, I wish I had someone to just hand me stuff that could be taken credit
> of and without paying anyone too! Are the standards guys on a high horse
or
> what?
You obviously don't understand how standardization works.
The participants are volunteers. Credit is not a huge issue.
By the time all those volunteers work on it, polishing up areas
that were not fully thought out by the proposer and putting it
into correct standardese, while paying for the privilege to
participate, very few desire to take any individual credit.
TB
Michael S. Terrazas <michael.s...@worldnet.att.net> wrote in message
news:nIv95.253$bR6....@bgtnsc04-news.ops.worldnet.att.net...
>
> Tony <to...@my.isp> wrote in message
> news:jd395.8276$oh5.6...@bgtnsc04-news.ops.worldnet.att.net...
> > Gee, I wish I had someone to just hand me stuff that could be taken
credit
> > of and without paying anyone too! Are the standards guys on a high
horse
> or
> > what?
>
> You obviously don't understand how standardization works.
A little better now though.
TB
<ka...@gabi-soft.de> wrote in message news:86u2e17...@gabi-soft.de...
>
> "Tony" <to...@my.isp> writes:
>
> |> > Someone would have to submit a proposal to the C++
> |> > committee. "Submit a proposal" doesn't mean just saying, "You guys
> |> > should add MT to C++." It means working out the syntax and
> |> > semantics and showing how it integrates with the rest of the
> |> > language, and especially the effect on the library.
>
> |> Gee, I wish I had someone to just hand me stuff that could be taken
> |> credit of and without paying anyone too! Are the standards guys on a
> |> high horse or what?
>
> The "standards guys" are unpaid volonteers, who have full time paid jobs
> in addition to the work they do for the standards committee. If the
> issue isn't important enough for you to write up a serious proposal, why
> should it be important enough for them?
Because they're kind of the gatekeepers?
Tony
TB
Francis Glassborow <fra...@robinton.demon.co.uk> wrote in message
news:jmQ9FLAj...@robinton.demon.co.uk...
>
> In article <jd395.8276$oh5.6...@bgtnsc04-news.ops.worldnet.att.net>,
> Tony <to...@my.isp> writes
> >> Someone would have to submit a proposal to the C++ committee. "Submit
> >> a proposal" doesn't mean just saying, "You guys should add MT to C++."
> >> It means working out the syntax and semantics and showing how it
> >> integrates with the rest of the language, and especially the effect
> >> on the library.
> >
> >Gee, I wish I had someone to just hand me stuff that could be taken
credit
> >of and without paying anyone too! Are the standards guys on a high horse
> or
> >what?
>
> Maybe you are referring to such bodies as ISO, I hope so because a
> reading of what you wrote seems deeply offensive to those people who
> actually do the work of standardising such things as computing
> languages.
Sorry, I get skeptical of institutions occassionally.
> >BTW, C++ doesn't need MORE, it needs LESS.
>
> And writing short letters is harder work than writing long ones:)
So when will it be done? :)
David R Tribble
Hyman Rosen wrote:
> C++ desperately needs multi-threading as part of the language. Many
> C++ developers are using it for this purpose already, and lack of a
> standard makes it difficult to know what will work.
One step in that direction would be adding replacement functions for
the standard library functions that rely on global data between
invocations. (The next step would be to get rid of the original
thread-unsafe functions.)
I've mentioned this before, but I proposed just this thing to the
ISO C committee. See <http://david.tribble.com/text/c9xthr.txt>.
The next step would be defining functions/classes that implement
multithreading primitives (probably along the lines of POSIX
pthreads, or even perhaps borrowing the Thread and Runnable classes
from Java).
--
David R. Tribble, mailto:da...@tribble.com, http://david.tribble.com
Barry Margolin
In article <86u2e17...@gabi-soft.de>, <ka...@gabi-soft.de> wrote:
>The "standards guys" are unpaid volonteers, who have full time paid jobs
>in addition to the work they do for the standards committee.
I think this is a poor characterization of it. In most cases, they work
for companies that rely on the standard (either because they sell
implementations or because they use the language and need portability), and
part of their job responsibility is participating in standardization so
that the language will meet their companies' needs.
If they haven't budgeted the time the spend on standards into their time,
that's a time management problem. But calling them "unpaid volunteers" is
wrong. The only ones for whom that may be appropriate would be private
consultants; in their case, though, they can consider it an investment in
their careers (just as the companies who are footing the bills for their
employee members consider it an investment in their business).
> If the
>issue isn't important enough for you to write up a serious proposal, why
>should it be important enough for them?
By joining the standardization committee they've indicated willingness to
work out the details.
--
Barry Margolin, bar...@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
ZHN
and C++; In fact Multi threading was invented in C ten years ago. It's not
really all that hard to provide a standard lib in C or C++ to have a very good
multithreading capability.
I remember seeing a very good implementaition written in pre standard C++
sometime in 1992 and it was really pretty simple straight and clean. The good
thing about it is that you can write it yourself and really retain great
control over it unlike java and windows where you dont have a clue as to how
the resources are being used(speaking of which I find that most threads on a
system are usually threads that must be written using that systems particular
implementation anyway. That is to say the MT is already there and does not need
to be re-impemented from scratch)
My opinion only and if you think I am wrong
(and I am always wrong to some degree or other)tell me please -that's the only
way I learn anything.
Pete
Steve Clamage
Barry Margolin wrote:
>
>
> > If the
> >issue isn't important enough for you to write up a serious proposal, why
> >should it be important enough for them?
>
> By joining the standardization committee they've indicated willingness to
> work out the details.
By joining the standardization committee, they've indicated a
willingness to participate in the process; not a commitment
to work on anything that happens to be tossed over the fence.
The committee members are all volunteers with limited resources
for committee work. There is no way to force any member to work
on any project; and you wouldn't want the result of forced labor
anyway.
The point at issue is that person Z, who chooses not to work on the
committee, nevertheless wants the committee to do something that will
benefit Z. If Z provides a reasonable specification, the committee can
analyze and vote on it, possibly with modifications.
Absent a specification, some committee members would have to decide
it was worthwhile to produce one. There is certainly no guarantee that
every half-formed idea will find an advocate on the committee.
--
Steve Clamage, stephen...@sun.com
[ Send an empty e-mail to c++-...@netlab.cs.rpi.edu for info ]
[ about comp.lang.c++.moderated. First time posters: do this! ]
[ comp.std.c++ is moderated. To submit articles, try just posting with ]