I am aware of Boost, and I even mentioned an associated project
previously on this thread. On 1 Nov I said: "Spirit is part of a
library project on the STL level. My view, perhaps controversial, is
that templates are for writing libraries that will see massive re-use.
Day-to-day programming will use such libraries, but day-to-day
programming should not involve writing templates."
I don't see why not. Perhaps they are too complex? Most applications
of templates are rather simple and well defined. No doubt C++ meta
programming requires great care (mostly because of poor compiler
support), but if you want/need compile time resolution, I see few
other options in the programming world.
The same applies to Boost. Writing STL-level libraries IS a niche
software project. [Frankly, I think it attracts more people than its
usefulness deserves - it attracts people who program for programming's
sake, who believe algorithms are everything, who produce over-complex
'clever' solutions to problems that people have long learned to bypass.
A tiny fraction of Boost, including perhaps the graph library, may get
in STL eventually, and some of it will even see serious use thereafter.
But even if it sees as much general use as the important parts of STL
such as sorting and collections, it will still be niche software.]
I don't care who is attracted to a library. I judge it on it's
usefulness, ease, and efficiency.
In short, if you think I'm saying generic programming is not useful for
making STL extensions, you are misreading me. What I'm saying is that
there are no paradigms that are "[compared to OO] equally useful and
valid general-purpose approaches to the programming and design of non-
niche software".
I am beginning to see what you think is niche software. I disagree.
"Software is written in a university" does not imply "this software will
cure AIDS". As for your 100X, we will discuss that another time if you
like - let me note only that the only overhead necessary for a graph
library written without generic programming is the overhead of copying
your graph into the appropriate format for the library to use - and it
might well be MORE optimised once that is done. In software, there's
always more than one way to skin a cat.
That 100 x is compared to dynamic runtime methods, and if you think
that converting 500 gigs or more of data to an appropriate format is
easy buisiness, then you are mistaken. Remember that you may be forced
to convert data for each library that you use. There can be huge
performance losses if you want to make use of one algorithm and have
to convert all your data there and back.
I have not even mentioned the development time saved by using a
library such as BGL (as opposed to writing a custom library or
retrofitting your data to one).
Your attitude as expressed in the first part of that sentence is exactly
what I am disagreeing with, despite the fact that the last clause is
perfectly correct. There are cases when other approaches are better,
but that does not mean the other approaches should be considered as
having equal status in general.
I am not sure what you mean by "equal status". In general most
problems will be solved well with OO principles. But by skewing your
perspective to automatically assume that OO is the best design
a-priori, then you miss out on many other opportunities. If two or
more design methodologies seem equaly applicable to a design problem,
I would choose OO because it is well understood, and well supported.
But often design methedologies are not equaly applicable, and I have
the sense to recognize when OO would be an inferior (or superior)
design option.
If you are saying that OO is the dominant and best understood design
methedology today, you are correct. If you mean that trying to
retrofit clever designs onto problems that would best be solved with
simple, well defined OO design is stupid, then there is no
disagreement. But where we diverge is that you beleive that OO design
suits all non-niche projects. Since niche has not really been defined,
we will have to agree to disagree. I personally see scientific
computing as very mainstream, and deserves more attention to design
issues than games or web browsers.
I don't think you are wrong Gerry, I just think you are 'blinded by
the light' and take your OO advocacy so far that you fail to see there
are other ways to write successful (non-niche) software.
Jeremy J
