Subject: Re: C++ cycle time
From: Erik Naggum <erik@naggum.net>
Date: Sat, 01 Dec 2001 13:12:46 GMT
Newsgroups: comp.lang.lisp
Message-ID: <3216201163137950@naggum.net>
* Kenny Tilton
| I guess big C++ projects spend more time thinking and planning and less
| time tossing code around?
It appears to me that big C++ projects only actually work well if they
"lucked out" with their design early enough to avoid rethinking it. If
not, they die. When you have precise knowledge of the problem domain and
you are able to anticipate your requirements completely, C++ is not a bad
choice of language. This implies that the thinking and planning stage
must have started a long time before anyting actually start thinking and
planning for a particular project -- only if you do _not_ have to make
engineering decisions during the course of development does it make sense
to use C++. This contributes to the need for patterns and "patterns" in
C++ software development, and especially of avoiding questioning the way
things are done, which means good leadership and loyal team members.
But more than software problems, I think C++ produces social problems and
requires harsh solutions to them. I and others have been arguing for a
long time that there is no one unique right solution to a problem without
a context and that there are tradeoffs between all kinds of factors
depending on the context, and that allowing the "rightest" solution to
emerge as sufficient knowledge to make the best tradeoffs emerges, is the
only way to make those tradeoffs. If this is to succeed in a brittle and
frail language as C++, _people_ have to agree, or not be allowed to have
any "ideas" of their own about what is right to do. In my view, C++ is a
good language if you have a benevolent dictator and people who are
willing to accept orders from above down to the very tiniest details. In
other words, C++ is an excellent assembly-line programming language.
I think the kinds of problems that can be solved successfully in C++ are
limited by the mental capacity of the leading designer. Abstraction in
the language is not necessary, as it is cheaper to pay people to do the
menial labor of typing in a lot of code than to design with the right
abstractions, and this seems to account for the low abstracation level in
successful and large C++ projects. This also leads to the development of
other languages and tools to manage all the abstraction that is not to
occur in C++, because it is impossible to think design in C++ due to the
immense cognitive load of the language. If designing software is like
building a mechanical clock, it does nobody any good to have to do it
moleculy by molecule.
The reason I made up my mind never to use C++ again when a project died
on me back in 1994, was primarily that the information required for any
particular decision is not available until a long time after it must be
made. Now, dealing with uncertain information is no big deal by itself,
but the process of discovery of the required certainty is very expensive
in C++, and if you are fully aware of the decisions you make on missing
or insufficient information, the "backtrack log" grows much faster than
your "progress log", and if you are not aware of the decisions you make,
you will go seriously wrong. This is not unlike those people we see come
to comp.lang.lisp who base most of their opinions about (Common) Lisp on
guesswork and who refuse to question the assumptions on which they have
built their current set of conclusions, and who, amazingly, think they
are still as certain in their conclusions as they were with the little
bit of fact that they once acquired. Some people just _have_ to fill in
the blanks between the things they are certain about and are probably not
even aware of this seriously bad mental habit. This does not work well
in programming in general, but C++ is a language that really punishes you
for this kind of mistake, while it makes avoiding it and doing things
right is prohibitively expensive.
My conclusion is that C++ is not a language that _can_ be used by very
intelligent people -- it requires that you _not_ think carefully about
what you do -- but rather suitable for people who can tolerate a lot of
failure. Likes sales people who continue to have a great attitude even
though they get 99% rejections, I imagine that good C++ programmers must
tolerate doing _so_ much manual work, and repeating it several times,
which would tell me that I am doing something seriously wrong and quit
and find something else to do. ... which I did.
///
--
The past is not more important than the future, despite what your culture
has taught you. Your future observations, conclusions, and beliefs are
more important to you than those in your past ever will be. The world is
changing so fast the balance between the past and the future has shifted.