Re: Compile Time String processing
On Mar 8, 9:32 am, Walter Bright <wal...@digitalmars-nospamm.com>
wrote:
James Kanze wrote:
On Mar 4, 8:30 am, Walter Bright <wal...@digitalmars-nospamm.com>
wrote:
James Kanze wrote:
There's a old saying: if it ain't broke, don't fix it.
That's what Douglas thought about designing jetliners - turboprops work
great, and are proven technology. Boeing blew right by them when the
airliners discovered that jetliners had half the operating costs, and
Douglas was reduced to a shadow.
What does this have to do with anything we're discussing (or
with C++)?
It's the disruptive innovation thing. By focusing on step-wise
refinement of existing technology, you can fail to recognize fundamental
problems as even being problems.
That can be a risk. You do have to take a large view when
considering problems. On the other hand, if you're a commercial
organization whose main product is not data processing, you
pretty much want to avoid untried technology. Let you're
competitors suffer the problems of version 1.0:-).
So, with C++, by focusing merely on fixing "broken" things, a big risk
is run by missing the boat in recognizing seismic shifts in programming
technology.
In the case of C++, I'm not too worried about that. Given the
wide range of users, I rather suspect that a lack of support for
a seismic shift in programming technology will be felt to be a
problem too soon, rather than too late. (I'm also a little bit
sceptical of seismic shifts. I find today that programming is a
fairly mature discipline.)
(Aside from being false---I think you're thinking of
Lockheed, not Douglas, who was for a long time the second
biggest constructor of jetliners.)
No, I have it right. Douglas was the big cheese of airliner builders
before jets, closely followed by Lockheed, with Boeing way, way behind.
Lockheed bet on the Electra, a turboprop, and missed the boat, not
producing a jetliner until the L1011 in 1970. Douglas failed as a
company in 1966.
Well, I'm not going to argue about it (this isn't the place).
The information is readily available on the network, for those
interested.
Also, of course, turboprops were actually more experimental than
jet engines at the time; jets were widely used in military
aircraft.
Turboprop engines were (mistakenly) seen as less risky by
Douglas, Lockheed, Convair, because they seemed a natural
evolutionary step. I suspect exported templates were added to
C++ rather than modules because export was seen as a less
risky evolutionary step.
Boeing didn't innovate in producing the 707.
That's dead, dead wrong.
That's relevant to my point, and I'm right. The de Havilland
Comet was the innovation; the first jetliner. Boeing wasn't
first, by a long shot. (And Boeing had extensive experience in
large jet aircraft already, e.g. the B-52.)
Which is exactly my point: the de Havilland Comet was a typical
"first version", and it's users came to regret it.
But we don't have to go so far afield. Who had the first
implementation of templates for C++? And where are they now?
Whereas the two most widely used implementations of C++ (VC++
and g++) were probably the last two to implement templates.
There's an old saying about learning from your mistakes, but
it's even better to learn from the mistakes of others.
(If you want to make money, of course. Obviously, some one has
to innovate. I just prefer that it be the other fellow, so that
I can learn from his mistakes, rather than from mine.)
There
were earlier, experimental, jetliners, such as the Sud Aviation
Caravelle
Which rolled out (1955) one year AFTER the 707 (1954).
or the de Havilland Comet which didn't catch on.
For two very good reasons:
1) it cost more to operate than a prop airliner, whereas the 707 cost
ONE HALF
2) it had a fundamentally unsound design, killing lots of people
Typical of a technological innovation, no. That's exactly my
point.
The
de Havilland Comet is, in fact, a good example as to why you
don't want to much state of the art in production tools:
The Comet didn't go far enough,
Taken literally, one can't argue the point. (On a flight from
London to Johannesburg, it only got to the Mediteranean. Which
definitly wasn't far enough. And sorry for the bad joke.)
it was too timid.
Whatever. It was the first jetliner (and the first jet aircraft
at all of that size?), and Boeing didn't appear until
considerably later.
Of course, in both this example and mine with C++, there are a
lot of other factors: Boeing had a lot of Defense Department
moneys for development, which de Havilland didn't, and I don't
think that VC++ won it's position just because it was in some
way stabler than CFront (although instabilities with CFront
definitly hurt arguments for its template instantiation
technology).
it
generated a lot of excitement when it first appeared (as the
first jet airliner); regretfully, it turned out to have one
small defect---it tended to loose its wings in flight.
No, that was the Electra. The Comet's problem was fatigue failure of the
fuselage, not the wings.
It was
Boeing's experience with large jet aircraft like the B-52 which
put it in the driver's seat with regards to commercial
jetliners.
No, it was Boeing's willingness to go whole hog with jetliners and do it
right with a long range, high capacity machine that had half the
operating costs of props. The Comet's timid, short range, small capacity
design doomed it to a costly, irrelevant niche. Airliners bought 707's
by the bucketful because it:
1) worked
2) made big fat wads of cash for the airliners
And the reason it worked: because Boeing had learned from de
Havilland's mistakes.
For C++, the magic is productivity. More productive use of
programmer time == better. Improvements to C++ should not
exclusively focus on problems, but on increasing productivity.
Where I work, we consider the amount of time it takes to produce
reliable, working code a real problem.
My point is simply that without concrete experience, you'll
probably get it wrong first time around. (Where was it that I
read: "Plan to throw one out. You'll have to anyway.") And
that we can't afford to get it wrong in the standard, so we
can't afford to standardize untested technology.
To get back to C++ (sort of): no one is saying that there should
be no research into new technologies, nor that what isn't broken
today might be considered so in the future, as a result of new
technologies.
"If it ain't broke, don't fix it" sure sounds like that.
It's a saying. It doesn't really mean much, except as a
starting point to further explinations.
(When I look at the C++ I wrote 15 years ago, I
would consider it broken by my standards today. But back then,
I was proud of it.) The r?le of C++ amongst the many languages
available isn't to invent new features; it's to leverage off
inventions that have proved themselves in other languages.
Probably C++'s biggest productivity improvement, templates with STL, was
new, not proven in another language. C++ took a big risk with it, and it
paid off handsomely.
Templates were already in wide use in Ada, Eiffel and possibly
other languages. Even before that, much generic programming was
being done by the Lisp community. The addition of templates to
C++ was a catch-up move, if you like. It was, at any rate,
fully in keeping with the philosophy of adopting existing good
ideas, rather than inventing things from scratch. It was also a
response to something that anyone who'd used it felt broken, and
needing fixing, mainly <generic.h>.
As for the STL, I'd agree that it was adopted too quickly, and
now we're stuck with its mistakes.
And
when it does play an innovative r?le, as is the case with
template meta-programming, it's more or less serendipity;
templates weren't designed with meta-programming in mind, and it
was only after the fact that one or two geniuses realized all
that could be done with them. (And of course, even today, most
serious companies don't allow programmers to define templates at
the application level---templates are restricted to standard
components which don't change, because of the source code
coupling issues.)
Template STL was designed, not discovered, and for a truly innovative
feature it does it tolerably well.
Templates were originally introduced into C++ before STL (which
if I'm not mistaken, was originally started in Ada). The needs
of the STL did influence the early evolution of templates, but
again, we're talking about features that were added to solve a
particular problem in the library.
Template metaprogramming, I agree, was discovered.
A bit serendiptiy, even, I believe.
As a consequence, C++ templates are rather bad at
metaprogramming simply because they aren't designed for it. It's like
discovering a belt buckle can drive screws. Now that we know that
driving screws is a useful activity, we can purposefully design a
screwdriver, and go back to using the belt buckle to hold up our pants,
which it does a fine job of <g>.
I think we agree there.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
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
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]