Re: Announcing Xrtti - Extended Runtime Type Information for C++
On May 7, 3:59 am, Zeljko Vrba <zvrba.nos...@gampen.ifi.uio.no> wrote:
I asked myself that very question before I posted the example. The thing
is, I don't know. I'm not a mechanical engineer :) I know that I wouldn't
rely on testing; rather I would rely on a sane design. There are well-
known principles for constructing static structures like bridges.
IMO, this is the very crux of the issue.
There has been an uncountable number of times where I have seen too
much effort being diverted from the fundamental issue:
There would be meetings, ad-hoc discussions, books, Perrier, yellow
note pads, code reviews, discussions about language principles in
general, QA documents, test cases, more meetings...with all the
activity, you would think the business at hand was open-heart surgery
on the Pope, only to discover that is is one executable and a few
libraries that are multi-threaded.
The fundamental issue is the design itself. If I may be critical of
those who feel they are being criticized by what I am about to say,
there are some people who simply prefer not to spend too much time on
good design. Some people are simply not good at it, so they spend
more time on ancillary activities.
This can be a huge impediment to good software engineering. If you
take a group of "software architects", and challenge them with a
difficult grand design of software, each required to work in
isolation, with a time limit, say 1 year, and they would be judge by
the virtue of their designs, inevitably, there will be a certain crop
of problems, that all of them will encounter, and each will solve the
problem in a different way.
However, IMO, an extremely important observation is that a small
percentage of these designers will structure their system in such a
way that certain problems never become an issue. The other designers
will not do this, and so spend time trying to find solutions to the
problem.
The critical question then becomes:
Where is the mental effort best spent? In finding solutions to
problems, or structuring the system in such a way that such problems
never exist.
I think polymorphism best illustrates this in the context of C++.
There are a whole class of "problems" that arise when a designer
abuses polymorphism: need for garbage collection, in ability to copy,
broken serialization, ownership, etc...the list is very long, but
polymorphism is often the first thing that a designer reaches for when
making a new system.
So, there is the constant struggle between good designers and bad
designers, and because the jury is still out on what constitutes good
design and what constitutes bad design, there there is much waste on
superfluous tools and methods in software engineering.
I think the best way to resolve this issue is to have each designer
design and create a *massive* system, alone. Then it will become very
clear what constitutes good design and what constitutes bad the
design. The good design will be the one that works and provides a
sense of order and integrity. The bad design will be the one that
gives you that uneasy feeling that the whole thing is going to either
lock up or come crashing down at any moment.
-Le Chaud Lapin-
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]