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.