Chris Hills wrote:
> In article <1125404095.109890.161740@z14g2000cwz.googlegroups.com>,
> kanze@gabi-soft.fr writes

> >If someone pretends

> You mean "says" it is their opinion just as the following is
> yours.  Neither are fact or fiction yet.

Just to clarify, I think I made a mistake in English here.  I
was using the verb "to pretend" as I would use "pretendre" in
French, and in checking, I find that it doesn't have the that
meaning in English.  The correct verb for what I meant to say
would be allege, argue, assert, claim, or contend.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Tue, 30 Aug 2005 09:10:44 CST, kanze@gabi-soft.fr wrote:
<snip>
> And of course, there are a number of important languages which
> have never been subject to ISO standardization: Perl and Java
> come immediatly to mind, and of course, there is the Unix shell,
> along with its sublanguages like awk and sed.  None of those
> seem likely to die anytime soon, despite never having been
> "standardized" (except for the Unix shell, by Posix).
>
At least since SUS2 (and now 3=POSIX=9945) awk, sed, and bc, as well
as sh, are standardized. But I wouldn't call sed and bc 'important'.

- David.Thompson1 at worldnet.att.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"John Nagle" <nagle@animats.com> wrote in message
news:9gHPe.799$5k1.691@newssvr27.news.prodigy.net...

> The Linux community is staying with C.  (That, incidentally,
> needs to be thoroughly studied by those working on the C++
> standard.  It's worth understanding why a sizable community
> has looked at and firmly rejected C++.)  Application-level

How can one reject something one does not understand
nor care to understand?

best regards

-Thorsten



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Thorsten Ottosen wrote:
<snip>
>> The Linux community is staying with C.=A0=A0(That,
>> incidentally, needs to be thoroughly studied by those
>> working on the C++ standard.=A0=A0It's=A0worth=A0understanding
>> why=A0a=A0sizable=A0community has looked at and firmly
>> rejected C++.)=A0=A0Application-level
>=20
> How can one reject something one does not understand
> nor care to understand?
<snip>

Thorsten, as a member of said community that happens to be
in one of the few camps (KDE) that uses almost only C++
as it's programming language I feel strongly insulted by
your comment.

John, I agree with you that the C++ community should think
about why the majority of Free Software developers refuse
to use C++. Complexity is the prime argument I hear[1].
My personal feeling (which might be completely off) is
that this complexity is for threefold reasons, two of
which involve the language's class library, and the last
one the core language efford.

First, all levels of 'core' C++ libraries (boost, tr1, the
'old' standard library and to a lesser extend the C
library) present themselves as a conglomerate of
independantly designed components that are thrown into a
pot without stirring. It seems to me that large,
extensive, 'single-source' class libraries like .net, the
Java class library, and - if I may add this - Qt provide
_a lot_ more uniform APIs and also have the ability to
dump dead ends over board, something that C++ refuses or
is unable to do. API consistency is very important for
the ease-of-use of a language, and C++ fares very badly
in this regard.

Second, the C++ standardized (even when including boost
here) libraries are way too low-level. We don't even have
a standardized xml parser library, although both SAX and
DOM could be trivially adapted and standardized almost
as-is. We don't have classes for common network
protocols, or even socket programming in general. And I
won't even start thinking about GUIs. I know this is
mostly due to the way the standardisation process works.
No-one gets paid for working on the standard, and I guess
that's the major drawback of C++.

Third, the reluctance to change the core langauge. Sure,
C++ compilers are complex beasts, and further
complexification of the core language might reduce the
number available high-quality C++ compilers, but other
langauges demonstrate that langauge support for e.g.
properties, delegates/signals-slots/callbacks (whatever
you want to call them) are welcome in the developer
community.

Considering that the C++ community itself only came to
terms in the last few years with the 'monster' it created
back in the nineties (TMP, exception-safety guidelines,
export), it shouldn't be of any wonder if people not on
the C++ research bleeding egde have trouble groking all
the little details of C++. In the same vein, as the
communitiy learns what C++ is all about, it might be a
good idea to revise the standard to accomodate what we
have learned. After all, all software rots and needs to
be kept up-to-date with the growing knowledge about the
problem domain and implementation techniques, and why
should the standard class library be any different. The
STL written in the boost era would look vastly different.
But due to backwards compatibility and lack-of-manpower,
local fixes (bind, function) need to ba added instead of
a putting up a coordinated efford to design an STLv2 that
looked like this:
  std::vector<int> v =3D ...;
  std::vector<int> r =3D ...;
  std::transform( v, r, std::bind( plus(), _1, 42 ) );
Another example: Everyone seems to agree that exception
specifications are a failure. Why not re-create them to
do what most people new to C++ expect them to do: To make
the compiler enforce the specifications at compile time.
Make void foo() throw() { throw 5; } ill-formed:
error: function 'foo()' is not allowed to throw 'int'.
Or language support for lamba functors:
  std::for_each( v, x->{ x +=3D 42; } ); //whatever syntax
  std::transform( v1, v2, (x,y)->{ x+y; } );
It's amazing that you can add lambda functions without
explicit language support and I consider the authors or
such libraries ingenious scientists that further the
understanding of a language that is showing a most
curious manifestation of emergent behaviour (TMP). But
apart from very simple cases, the syntax is not exactly
readable. Or maybe the need for a lambda library just
shows that C++ badly lacks a foreach keyword.

Let me stress that I'm awestruck at the power of modern
C++ template libraries like Spirit or Boost.Lambda and
that I fully understand that to shoulder large redesigns
of the standard library, the committee simply lacks the
man power, but we must ask why the industry lets this
happen. Maybe the turn-around times for the ISO process
is too long for companies to submit their stuff and get
involved.

Just my 2 cents. Sorry for the long post. You probably
know all of the above already.

Marc

[1] Personally, I think that younger languages like
Python, C# or Java will also become more complex as they
add features C++ has had for the last decade already.
These features are needed to write robust code and I'm
looking forward to see new lean language effords like
python was when it was invented pop up with a
functionality set to rival C++ and but with a leaner,
more consistent, less-dark-corner design.


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Marc Mutz" <marc@klaralvdalens-datakonsult.se> wrote in message
news:deobtp$fl9$00$1@news.t-online.com...
Thorsten Ottosen wrote:
<snip>
>> The Linux community is staying with C. (That,
>> incidentally, needs to be thoroughly studied by those
>> working on the C++ standard. It's worth understanding
>> why a sizable community has looked at and firmly
>> rejected C++.) Application-level
>
> How can one reject something one does not understand
> nor care to understand?
<snip>

Thorsten, as a member of said community that happens to be
in one of the few camps (KDE) that uses almost only C++
as it's programming language I feel strongly insulted by
your comment.
>>>>>>>>>>>

You shouldn't. Obviously you don't fall into that camp I'm talking about.

I've meat some really important FreeBSD guys...really smart people
working on OS cores. But they don't understand the power of C++
and how it might help them. One of them said, he had given up
on C++ a long time ago. He's relunctant to change, even if it
could help him enourmously.



John, I agree with you that the C++ community should think
about why the majority of Free Software developers refuse
to use C++. Complexity is the prime argument I hear[1].
>>>>>>>>>>

right, an that is often because they don't know how modern C++
works.



pot without stirring. It seems to me that large,
extensive, 'single-source' class libraries like .net, the
Java class library, and
>>>>>>>>>>

The quality of the .Net class linbraries is not exactly
great. For example, I've never seen a weak container library before.
The remoting API is way to complex compare to what it should be



Second, the C++ standardized (even when including boost
here) libraries are way too low-level. We don't even have
a standardized xml parser library, although both SAX and
DOM could be trivially adapted and standardized almost
as-is. We don't have classes for common network
protocols, or even socket programming in general. And I
won't even start thinking about GUIs. I know this is
mostly due to the way the standardisation process works.
No-one gets paid for working on the standard, and I guess
that's the major drawback of C++.
>>>>>>>>>>>>>>>

right. we can't standardize everything. but C++ needs a
more of these libraries...and I'm pretty sure that they will
appear in boost within two years.



Third, the reluctance to change the core langauge.
>>>>>>>>>>>>>>>

what reluctance?



Sure,
C++ compilers are complex beasts, and further
complexification of the core language might reduce the
number available high-quality C++ compilers, but other
langauges demonstrate that langauge support for e.g.
properties, delegates/signals-slots/callbacks (whatever
you want to call them) are welcome in the developer
community.
>>>>>>>>>>>>>>>>

properties are not really useful, except maybe for embedded domain
specific languages. signals/slots will be added as a library,
there is no need to make a core change for that.



Considering that the C++ community itself only came to
terms in the last few years with the 'monster' it created
back in the nineties (TMP, exception-safety guidelines,
export), it shouldn't be of any wonder if people not on
the C++ research bleeding egde have trouble groking all
the little details of C++.
>>>>>>>

right, they shoul have to. And C++0x will be much easier
to use. count on it.


should the standard class library be any different. The
STL written in the boost era would look vastly different.
But due to backwards compatibility and lack-of-manpower,
local fixes (bind, function) need to ba added instead of
a putting up a coordinated efford to design an STLv2 that
looked like this:
  std::vector<int> v = ...;
  std::vector<int> r = ...;
  std::transform( v, r, std::bind( plus(), _1, 42 ) );
>>>>>>>>>>>>>

I have a proposal about this for C++0x in the next mailing.
(available in a week)



Another example: Everyone seems to agree that exception
specifications are a failure. Why not re-create them to
do what most people new to C++ expect them to do: To make
the compiler enforce the specifications at compile time.
>>>>>>>>>>>>>

Alisdair M. is working in this area. I think what everybody
don't expect is that it can terminate the program. whether we need
to detect it a compile time is another issue. I don't think
exception-specs are that useful, though.


readable. Or maybe the need for a lambda library just
shows that C++ badly lacks a foreach keyword.
>>>>>>>>>>>>>>>>

Also described in one of my new papers. You may find the old version
here (it contains a few errors, though)

http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2005/n1796.html


happen. Maybe the turn-around times for the ISO process
is too long for companies to submit their stuff and get
involved.
>>>>>>>>>>>>

hear, hear.


Anyway, be sure that C+0x is going to be much easier to
use and and  much more pleasant ride for everyone.

best regards

Thorsten


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Marc Mutz wrote:

> First, (...) API consistency is very important for the ease-of-use of a
> language, and C++ fares very badly in this regard.

In any case, the standard C library is much worse. I also don't think
popular scripting languages like Python and perl are exemplary in this
regard.

> Second, the C++ standardized (even when including boost
> here) libraries are way too low-level.

I agree, but on the oter hand, ISO C also has a weak standard library,
but there you have external standards (POSIX/SUSv3) which build on it,
and a lot of widely available libraries.

IMHO, C++ is missing those external bindings. Even if I just want to use
C++ simply as a better C and not bother with templates and classes, e.g.
by just using 'string', namespaces and function overloading, I run into
issues, since a lot of interfaces are designed for pure C.

Many people wouldn't care that the C++ Standard doesn't have sockets or
threads if there were an external standard "POSIX/C++" or whatever.

> Third, the reluctance to change the core langauge. (...)
> Or maybe the need for a lambda library just
> shows that C++ badly lacks a foreach keyword.

Personally, I'd rather see C++ adding support for nested functions (or
closures, or whatever you want to call them) since this is a more
general solution, and easy to learn. Lambda abstractions and "foreach"
serve pretty specialised needs.

But I doubt just changing or adding to the language like this would
convince people to 'ditch' C in favor of C++.

And actually; *Has* the free software community 'firmly rejected' C++?
Aren't there lots and lots of Qt apps and isn't KDE the default desktop
environment in most Linux distributions?

~Marc.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <gDpnOxSDAxCDFwzP@robinton.demon.co.uk>, Francis Glassborow
<francis@robinton.demon.co.uk> writes
>In article <X5fOe.178$dw4.134@newssvr29.news.prodigy.net>, John Nagle
><nagle@animats.com> writes
>>The first ISO standard for Pascal was issued in 1983.  The Pascal
>>working group was wound up on April 30, 1995, and there has been
>>no new work since then.  So that standards activity had a life of
>>12 years, a surprisingly short period for what was once a major
>>language.
>>
>>ALGOL was first described in 1960, and standards activity began
>>in 1962, under the auspices of IFIP.  The ALGOL Bulletin ceased
>>publication in 1976, so that standards effort had a life of 14 years.
>>
>>The Common LISP standards effort began in 1983, and appears to have
>>ceased operations in 1994.  So that effort had a lifetime of
>>11 years.
>>
>>FORTRAN and COBOL still have ongoing standards efforts, 40 years on.
>>(COBOL is adding a "<>" operator, support for ISO 8601:2000 dates
>>(a bit late for Y2K), and, surprisingly, method overloading.)
>>But the rate of change is very low.
>>
>>The first ISO standard for ANSI C was issued in 1990, and continues,
>>so that effort is at year 14.
>>
>>So, with the exception of FORTRAN and COBOL, the earliest of major
>>languages, the active lifespan of a language standards effort seems to
>>be in the range of 11 to 15 years.
>>
>>The first ISO standard for C++ was issued in 1997, so we are now at
>>year 8 with C++.  This gives us a sense of where we are in the
>>life cycle.  There's probably one more major revision cycle
>>left in the lifespan.
>
>You are being inconsistent in the way you count. In some cases you
>measure from the start of Standards activity and in others from the
>first Standard release. C is in about year 23 from the start of
>standardisation, C++ in year 16. And where is Ada in your list?

I think it might be work re-doing the list in a more consistent from and
with some more of the languages to see if there is any correlation. Some
of it will depend on dates as well as time as I am sure modern working
with the Internet (ie web, ftp and email) has and a dramatic change of
the work flow etc in producing standards documents


>I think all your data demonstrates is that some languages become so
>important to some communities that they are willing to fund ongoing
>work.

However that work is not always in the ISO standards area. Sometimes the
ISO standards meander off in a direction that differs from industry. C
and Basic are two I can think of.


> If I were a betting man, I would lay good odds that C++ will still
>be around and under continued development in 2020.

Not looking for an argument here I am just curious as to what grounds
you base that on and see if they apply to other languages. Ie is this
just a gut feeling or something that can be applied to other languages?

There must be some rules or equation that will cover the life of a
language. Perhaps redoing the list as you suggest in a more consistent
manner might yield some answers?



--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <1124962740.444680.27940@g47g2000cwa.googlegroups.com>,
kanze@gabi-soft.fr writes
>
>The case of C is an interesting one.  There, too, I don't think
>that there can be any doubt that the critical volume was
>reached.  If C dies, it will basically be because C++ has been
>able to subsume it -- the C compatibility of C++ means that much
>C code is almost C++ code, migrating it to C++ (and thus
>reducing the effective volume) is affordable.  So C could
>conceivably be an exception to the above.


C is interesting as it has a life of it's own, like (visual) Basic
outside the ISO standardisation.   There is a lot of work going on with
it but mainly based around C90.

In the embedded world they use C for the vast a majority (assembler
comes next I think) and it is no way a sub set of C++. Actually it is
usually "almost" C90 + some extensions. As for migrating it to C++. this
is not possible as the most common platforms do not have C++ compilers
or debug tools.

C is not likely to die and is more likely to outlive C++. C based
languages are used in ASICS and FPGA's as well.  IT is the lowest level
of high level language and thus makes sense for embedded work.
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Marc Mutz wrote:
> Thorsten Ottosen wrote:
>> "John Nagle" <nagle@animats.com> wrote in message
>>>The Linux community is staying with C.  (That,
>>>incidentally, needs to be thoroughly studied by those
>>>working on the C++ standard.  It's worth understanding
>>>why a sizable community has looked at and firmly
>>>rejected C++.)  Application-level
>>
>>How can one reject something one does not understand
>>nor care to understand?
>
> Thorsten, as a member of said community that happens to be
> in one of the few camps (KDE) that uses almost only C++
> as it's programming language I feel strongly insulted by
> your comment.

I believe that John was speaking about rejecting the use
of C++ in the Linux _Kernel_ only. AFAICT, this rejection
is to be explained by history, ignorance and "human inertia"
rather than by _technical_ obstacles preventing from use of
C++ in kernel mode (Yes there are some specific constraints
in kernel that you need to be aware of - no matter if you
develop in C++ or C) - see for example the discussions in
<http://kerneltrap.org/node/2067>.

Falk

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Chris Hills wrote:
> In article <1124962740.444680.27940@g47g2000cwa.googlegroups.com>,
> kanze@gabi-soft.fr writes

> >The case of C is an interesting one.  There, too, I don't
> >think that there can be any doubt that the critical volume
> >was reached.  If C dies, it will basically be because C++ has
> >been able to subsume it -- the C compatibility of C++ means
> >that much C code is almost C++ code, migrating it to C++ (and
> >thus reducing the effective volume) is affordable.  So C
> >could conceivably be an exception to the above.

> C is interesting as it has a life of it's own, like (visual)
> Basic outside the ISO standardisation.

This is an aspect I didn't address.  Both Basic and Pascal have
ISO standards.  Both standards have largely been ignored, from
the start.  But both languages are very much alive, in the form
of Visual Basic and Delphi.

And of course, there are a number of important languages which
have never been subject to ISO standardization: Perl and Java
come immediatly to mind, and of course, there is the Unix shell,
along with its sublanguages like awk and sed.  None of those
seem likely to die anytime soon, despite never having been
"standardized" (except for the Unix shell, by Posix).

    [...]

> C is not likely to die and is more likely to outlive C++.

Independantly of a standard, my point was that any language
which reaches a critical mass lives forever.  In my mind, there
is no doubt that both C and C++ have reached that critical mass.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:
> Tony Delroy wrote:
> >>There's probably one more major revision cycle left in [C++]
> >>the lifespan.

> > COBOL and FORTRAN stand out as having been core parts of
> > corporate and governmental financial and engineering
> > systems, while in my experience Pascal is typically employed
> > in Universities and PCs.

>      Pascal was the first major language in microcomputing.
> The personal computer revolution was powered by Pascal.

I'm sorry, but this is just wrong.  The personal computer
revolution was powered by application software: VisiCalc, then
Lotus 1-2-3 and WordStar, mostly.  And almost all of the PC
application software was written in assembler.

On early personal computers, if a programming language was
present, 9 times out of 10, it was a dialect of Basic.

> The DOS machines used Borland's Turbo Pascal (which,
> significantly, was nothing like the ISO standard), and
> Lisa/Macintosh machines used several varieties of Pascal, some
> with object-oriented extensions.

Turbo Pascal didn't appear until long after the PC had
established itself.  Microsoft and at least one other company
had Pascal offerings before that, but they weren't widely used.

>      The standards community was never able to get together on
> a usable version of Pascal for systems programming.  Wirth was
> off doing Modula and Oberon, the ISO standarized version was
> too restrictive (it couldn't even handle an I/O error), and no
> organization took on the standards effort.

The real problem was that the standardization committee for
Pascal was unable to build a consensus on how to handle separate
compilation.  By the time standardization was in progress, there
were a number of implementations, all of which supported some
form of separate compilation, but none compatible.

>      And that killed the language.  It wasn't a technical problem.

The lack of a portable dialect certainly played a role in
killing the language as such.  Although in another sense, it
isn't dead; it has just changed its name.  Both Pascal and Basic
live on in the hands of a single supplier (Borland and
Microsoft).  A fact which, of course, eliminates the dialect
problem, and makes standardization irrelevant, but has another
set of disadvantages.

>      To some extent, this is happening to C++.  Microsoft is
> going off in their own direction (extra keywords, "managed
> C++", ".NET", and now "C#").

Yes and no.  They seem to be actively interested in standard C++
as well.

> AT&T is no longer a factor in computing.  The Linux community
> is staying with C.

The Linux kernel is staying with C.  A number of important Linux
applications (Firefox, for example, or Gnome) are written in
C++.

If someone pretends that C++ will disappear, my first question
is: what will replace it?  Java tried and failed.  Microsoft
seems to have admitted very early on that there is a role for
both C# and C++.

> (That, incidentally, needs to be thoroughly studied by those
> working on the C++ standard.  It's worth understanding why a
> sizable community has looked at and firmly rejected C++.)
> Application-level programming is transitioning to other,
> safer, languages.

For example?  There are more than a few things that I don't like
about C++, but I don't see any other language (except maybe Ada
95) which is capable of supporting modern, large scale program
development.

>      Issues like this need more attention in the standards
> process.  This is more important than adding cool features to
> templates that very few people will ever use.

It's certain that there are some core issues which need
attention.  The language could be simpler and easier to use (to
put it mildly).  But until a working alternative comes along,
such problems aren't going to kill it.  (Also, I think that
there are people in the standards committee who are concerned by
these problems.  Not everyone there is working on cool new
template features.)

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <1125404095.109890.161740@z14g2000cwz.googlegroups.com>,
kanze@gabi-soft.fr writes
>
>If someone pretends

You mean "says" it is their opinion just as the following is yours.
Neither are fact or fiction yet.

>that C++ will disappear, my first question
>is: what will replace it?  Java tried and failed.  Microsoft
>seems to have admitted very early on that there is a role for
>both C# and C++.

I must say I have to agree. I was one who in the recent past said C++
would demise due to Java and C#  but I am not so sure now.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I just came across this note from the Pascal ISO standards committee:

Annual Report for J9, Pascal
June 2003 through June 2004
1. Executive Summary
For the 5-year maintenance review for the U.S. Extended Pascal Standard,
INCITS/ISO/IEC 10206 :1991 [1999], Information Technology - Programming
languages - Extended Pascal, the committee voted unanimously (4-0-0)
that the standard should be reaffirmed for another 5-year period.
The status of the Pascal committee is in    Maintenance   . This corresponds
with the Pascal and Extended Pascal standards projects, which are in
maintenance mode. No meetings were held in 2003 and to date in 2004. All
committee business is conducted via e-mail, telephone calls, and post.
The last committee meeting was in April of 1995.
Membership remains stable, as it has been for years, at four principal
members. The positions of Vice Chairman, International Representative,
and Vocabulary Representative remain vacant.
No new work is anticipated at this time.
===

The first ISO standard for Pascal was issued in 1983.  The Pascal
working group was wound up on April 30, 1995, and there has been
no new work since then.  So that standards activity had a life of
12 years, a surprisingly short period for what was once a major
language.

ALGOL was first described in 1960, and standards activity began
in 1962, under the auspices of IFIP.  The ALGOL Bulletin ceased
publication in 1976, so that standards effort had a life of 14 years.

The Common LISP standards effort began in 1983, and appears to have
ceased operations in 1994.  So that effort had a lifetime of
11 years.

FORTRAN and COBOL still have ongoing standards efforts, 40 years on.
(COBOL is adding a "<>" operator, support for ISO 8601:2000 dates
(a bit late for Y2K), and, surprisingly, method overloading.)
But the rate of change is very low.

The first ISO standard for ANSI C was issued in 1990, and continues,
so that effort is at year 14.

So, with the exception of FORTRAN and COBOL, the earliest of major
languages, the active lifespan of a language standards effort seems to
be in the range of 11 to 15 years.

The first ISO standard for C++ was issued in 1997, so we are now at
year 8 with C++.  This gives us a sense of where we are in the
life cycle.  There's probably one more major revision cycle
left in the lifespan.

    John Nagle
    Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"John Nagle" <nagle@animats.com> wrote in message
news:X5fOe.178$dw4.134@newssvr29.news.prodigy.net...

> The first ISO standard for Pascal was issued in 1983.  The Pascal
> working group was wound up on April 30, 1995, and there has been
> no new work since then.  So that standards activity had a life of
> 12 years, a surprisingly short period for what was once a major
> language.
>
> ALGOL was first described in 1960, and standards activity began
> in 1962, under the auspices of IFIP.  The ALGOL Bulletin ceased
> publication in 1976, so that standards effort had a life of 14 years.
>
> The Common LISP standards effort began in 1983, and appears to have
> ceased operations in 1994.  So that effort had a lifetime of
> 11 years.
>
> FORTRAN and COBOL still have ongoing standards efforts, 40 years on.
> (COBOL is adding a "<>" operator, support for ISO 8601:2000 dates
> (a bit late for Y2K), and, surprisingly, method overloading.)
> But the rate of change is very low.
>
> The first ISO standard for ANSI C was issued in 1990, and continues,
> so that effort is at year 14.
>
> So, with the exception of FORTRAN and COBOL, the earliest of major
> languages, the active lifespan of a language standards effort seems to
> be in the range of 11 to 15 years.
>
> The first ISO standard for C++ was issued in 1997, so we are now at
> year 8 with C++.  This gives us a sense of where we are in the
> life cycle.  There's probably one more major revision cycle
> left in the lifespan.

Averages don't mean much when you have a lumpy distribution. What
this data reaffirms to me is that about half of all programming
language standards are failures -- they are ignored in the
marketplace. Since few failures slink away quietly, they appear as
documents that nobody feels the need to change. (And yes, I know
that the C committee recently voted to reaffirm C99 unchanged.)

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Why would no work on the standard mean an end of life cycle ? Pascal and C
are still in active use and therefore their standard is. I'd rather say that
these languages are apparently mature.

Jaap

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In article <X5fOe.178$dw4.134@newssvr29.news.prodigy.net>, John Nagle
<nagle@animats.com> writes
>The first ISO standard for Pascal was issued in 1983.  The Pascal
>working group was wound up on April 30, 1995, and there has been
>no new work since then.  So that standards activity had a life of
>12 years, a surprisingly short period for what was once a major
>language.
>
>ALGOL was first described in 1960, and standards activity began
>in 1962, under the auspices of IFIP.  The ALGOL Bulletin ceased
>publication in 1976, so that standards effort had a life of 14 years.
>
>The Common LISP standards effort began in 1983, and appears to have
>ceased operations in 1994.  So that effort had a lifetime of
>11 years.
>
>FORTRAN and COBOL still have ongoing standards efforts, 40 years on.
>(COBOL is adding a "<>" operator, support for ISO 8601:2000 dates
>(a bit late for Y2K), and, surprisingly, method overloading.)
>But the rate of change is very low.
>
>The first ISO standard for ANSI C was issued in 1990, and continues,
>so that effort is at year 14.
>
>So, with the exception of FORTRAN and COBOL, the earliest of major
>languages, the active lifespan of a language standards effort seems to
>be in the range of 11 to 15 years.
>
>The first ISO standard for C++ was issued in 1997, so we are now at
>year 8 with C++.  This gives us a sense of where we are in the
>life cycle.  There's probably one more major revision cycle
>left in the lifespan.

You are being inconsistent in the way you count. In some cases you
measure from the start of Standards activity and in others from the
first Standard release. C is in about year 23 from the start of
standardisation, C++ in year 16. And where is Ada in your list?

I think all your data demonstrates is that some languages become so
important to some communities that they are willing to fund ongoing
work. If I were a betting man, I would lay good odds that C++ will still
be around and under continued development in 2020.


--
Francis Glassborow      ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Jaap Versteegh wrote:
> Why would no work on the standard mean an end of life cycle ?

Because the programming environment changes enough, quickly enough,
that almost anything that doesn't adapt quickly becomes obsolete.
Granted, some areas change more quickly than others, but even Fortran
(arguably in the most stable area there is) has changed substantially
over the years.

> Pascal and C are still in active use and therefore their standard is.

As standardized, Pascal has never really been actively used -- I'm only
aware of one Pascal compiler that ever really even tried to implement a
standard, and TTBOMK, it never saw much use. A conforming
implementation of Pascal would be required to reject nearly everything
most people currently write as Pascal.

> I'd rather say that these languages are apparently mature.

While C has certainly matured, it's also stagnated to an extent -- or
at least the area in which it's the language of choice has narrowed
considerably over time.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle schreef:

>
> The first ISO standard for Pascal was issued in 1983.  The Pascal
> working group was wound up on April 30, 1995, and there has been
> no new work since then.  So that standards activity had a life of
> 12 years, a surprisingly short period for what was once a major
> language.
>
> ALGOL was first described in 1960, and standards activity began
> in 1962, under the auspices of IFIP.  The ALGOL Bulletin ceased
> publication in 1976, so that standards effort had a life of 14 years.
>
> The Common LISP standards effort began in 1983, and appears to have
> ceased operations in 1994.  So that effort had a lifetime of
> 11 years.
>
> FORTRAN and COBOL still have ongoing standards efforts, 40 years on.
> (COBOL is adding a "<>" operator, support for ISO 8601:2000 dates
> (a bit late for Y2K), and, surprisingly, method overloading.)
> But the rate of change is very low.
>
> The first ISO standard for ANSI C was issued in 1990, and continues,
> so that effort is at year 14.
>
> So, with the exception of FORTRAN and COBOL, the earliest of major
> languages, the active lifespan of a language standards effort seems to
> be in the range of 11 to 15 years.
>
> The first ISO standard for C++ was issued in 1997, so we are now at
> year 8 with C++.  This gives us a sense of where we are in the
> life cycle.  There's probably one more major revision cycle
> left in the lifespan.

At least. However, I'd like to suggest an explanation. The number of
revisions is probably strongly related to both the number of LOCs
in production use, and the rate of change. Certainly, FORTRAN and
COBOL score high in the 'LOCs in production' category. Pascal most
certainly doesn't. If I'd have to estimate the lifespan of C++ based
on this, I'd give it at least 25 years (i.e. we'll see C++1x and C++2x
too, although I do suspect these will be even more library-oriented.)

Regards,
Michiel Salters

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Francis Glassborow wrote:
> In article <X5fOe.178$dw4.134@newssvr29.news.prodigy.net>,
> John Nagle <nagle@animats.com> writes

    [...]
> I think all your data demonstrates is that some languages
> become so important to some communities that they are willing
> to fund ongoing work. If I were a betting man, I would lay
> good odds that C++ will still be around and under continued
> development in 2020.

I think that Plauger hit the nail on the head when he pointed
out that averages don't mean much when there is a strong
variance.  Note that in some African countries, the "average"
lifespan is something like 45; the difference, when compared to
North America or Europe, isn't that a lot of people die in their
fourties; the difference is that there are a lot more infant
deaths -- if half of the population dies in their first year,
and the other half lives to 90, that makes an average of 45.

I suspect that there is a similar phenomenon in programming
languages.  Some languages fail to attain a critical volume of
code, and for all intents and purposes die.  Once the critical
volume is reached (e.g. the case of Fortran or Cobol), however,
the language effectively lives forever.  (At least in name --
modern Fortran has very little resemblance to Fortran IV.)  In
the case of C++, I don't think that there is any doubt that the
critical volume has been reached.

The case of C is an interesting one.  There, too, I don't think
that there can be any doubt that the critical volume was
reached.  If C dies, it will basically be because C++ has been
able to subsume it -- the C compatibility of C++ means that much
C code is almost C++ code, migrating it to C++ (and thus
reducing the effective volume) is affordable.  So C could
conceivably be an exception to the above.

--
James Kanze                                           GABI Software
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
9 place S   mard, 78210 St.-Cyr-l'   cole, France, +33 (0)1 30 23 00 34


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

> There's probably one more major revision cycle left in [C++] the lifespan.

COBOL and FORTRAN stand out as having been core parts of corporate and
governmental financial and engineering systems, while in my experience
Pascal is typically employed in Universities and PCs.  Bigger systems
take more effort to displace, and the dependency makes organisations
place huge pressure on standards bodies form a bridge between companies
desparately trying to continue to use critical systems and vendors
who'd be reluctant to enhance an old language if only one customer was
demanding the change.

This mirrors hardware, where VAX computers are still available and
support promised despite several changes to the ownership of
OpenVMS/VAX/Alpha technology.  There are enough telcos, defense
projects etc with no practical way off the technologies that pressure
and entice the vendors.

As for C++... I think John's probably onto something.  It's inevitable
that in the next couple years someone will release a C++ system with
full compile-time introspection, and what we now call C++ will be to
that "C++ with introspection" what C is to C++.  I've written such a
system for a previous client, and plan to do something similar again
for public release.  From a programming perspective, it's actually
relatively simple, and existing systems like OpenC++ illustrate the
larger techniques, without yet hitting on the necessary blend of
flexibilitiy, practicality, usability, and productivity.

Cheers,

Tony

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Tony Delroy wrote:
>>There's probably one more major revision cycle left in [C++] the lifespan.
>
>
> COBOL and FORTRAN stand out as having been core parts of corporate and
> governmental financial and engineering systems, while in my experience
> Pascal is typically employed in Universities and PCs.

     Pascal was the first major language in microcomputing.  The
personal computer revolution was powered by Pascal.  The DOS
machines used Borland's Turbo Pascal (which, significantly,
was nothing like the ISO standard), and Lisa/Macintosh machines
used several varieties of Pascal, some with object-oriented
extensions.

     The standards community was never able to get together on
a usable version of Pascal for systems programming.  Wirth
was off doing Modula and Oberon, the ISO standarized version
was too restrictive (it couldn't even handle an I/O error),
and no organization took on the standards effort.

     And that killed the language.  It wasn't a technical problem.

     To some extent, this is happening to C++.  Microsoft is
going off in their own direction (extra keywords, "managed C++",
".NET", and now "C#").  AT&T is no longer a factor in computing.
The Linux community is staying with C.  (That, incidentally,
needs to be thoroughly studied by those working on the C++
standard.  It's worth understanding why a sizable community
has looked at and firmly rejected C++.)  Application-level
programming is transitioning to other, safer, languages.

     Issues like this need more attention in the standards
process.  This is more important than adding cool features
to templates that very few people will ever use.

    John Nagle
    Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]