Subject: Re: C++ cycle time
From: Erik Naggum <>
Date: Sat, 01 Dec 2001 13:12:46 GMT
Newsgroups: comp.lang.lisp
Message-ID: <>

* 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.