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, Per