Re: Compile Time String processing
{ This article was submitted Sun, 04 Mar 2007. I rejected it for
off-topicality (stronger topicality judgement on airplane industry
history sub-thread), suggesting a move to other forum instead. After
discussion with other moderators I now think tangential discussions
should be accepted as long as there is on-topic C++ content, and I
apologize for the inconvenience; also, consequently, please disregard
earlier mod-comment regarding the tangential discussion. -mod/aps }
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. Another way to look at it is you'll
never evolve a CLI into a GUI by fixing problems with the CLI.
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.
(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.
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.
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
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, it was too timid.
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
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.
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.
(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.
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. Template metaprogramming, I agree,
was discovered. 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>.
To Mr. Moderator: Yes, I like to bring up aviation analogies <g>. I know
a lot about the aviation industry, having worked in it for years, and
having read many books about it. I've learned a lot from it, which has
influenced a lot of my work on compilers and language design. There are
a lot of parallels. Although it may not seem relevant, I think it is,
and I'll try to make the connections more clear in the future.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]