[boost] Re: FC++ formal review

From: David B. Held (dheld_at_[hidden])
Date: 2004-03-03 14:46:25

"Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> wrote in message
news:c21hhr$tfp$1_at_sea.gmane.org...
> [...]
> If I understand you correctly what you are saying is: "let's have it
> just because it's cool example of what could be done with C++,
> good example of GTM in use".

Almost, but not quite.  What I'm saying is: "We need more examples
of working GTM libraries to advance the state of the art."  If everyone
who looked at FC++ said: "Been there, done that", then FC++ would
not bring this benefit.  But because GTM as a programming style is
not as mature as, say, OOP, I think we need more instances of GTM
code to help establish what constitutes good GTM code.

> [...]
> 1. FC++ is freely available on the web. Do you want to rake up all
> the code written under boost hood?

Boost has numerous advantages.  1) It's peer-reviewed, so you know
that at least some knowledgable people have looked at the library
and offered comments.  2) It has higher standards of portability than
your average project.  Also, people who find it useful are more likely
to port it to another platform if it is in Boost than if it is hiding
somehwere with less exposure.  Considering the wide variety of
implementation qualities, I think having another big GTM library that
stresses compilers helps to expose weaknesses and find
workarounds.  3) It fosters competition.  I know that sounds like a bad
thing for Boost libraries, but I don't know why it should be.  Why should
any library enjoy a monopoly by fiat?  The differences between
libraries get debated, and at the least, users get even more rationale
as to why various design choices were made, and more commonly,
have a *choice* when making certain trade-offs.  And I think the
primary benefit of C++ as a language is the huge amount of choice
it gives you as far as implementation qualities go.

> 2. There is nothing cool about class designed and implemented the
> way so it works 320 times slower then similar solution written in
> different style. And I am not talking about minor issues related to
> abstraction overhead and portability workarounds. There should be
> something wrong in the very heart of the design, for this to happened.

No, what was wrong is that you were comparing apples to oranges.
If I write a bubble sort, and you write a quicksort that is 320 times
faster, and say that it's "similar", I'm going to think you're crazy.

> 3. One of the main lessons I brought from numerous examples of
> GTM is actually that we need to stay away from FP in our
> production programming as far as possible. After all usage of FP
> techniques it's primary reason why compilation more and more taking
> ridiculously long time nowadays.

Is it FP techniques, or GTM techniques?  Because those are
logically orthogonal, as far as I can see.

> [...]
> My understanding is that there exist already solution in sandbox to
> implement support for result_of. And example of PP usage are all
> over the place (not mentioning that PP has pretty good docs). If you
> need more examples let's then just have new section dedicated to
> an example of usage and put some staff there.
> [...]

I think you're missing the forest for the trees.  For instance, would
people care about a standardized result_of<>, rather than a custom
one, if it were only used in one library?  I only mentioned that because
I happened to see it mentioned in the thread.  But I'm sure there are
many other mechanisms that are common among FC++, Lambda,
and several other related libraries.  But maybe some of the libraries
only share a mechanism with one other library, and it's not evident
that the mechanism should become idiomatic.  But if more libraries
(like FC++) are considered, then the patterns start to emerge, and
we get a better idea of which code patterns are being reused
across libraries/applications.  Whereas, if we say: "Let's go for the
smallest possible number of libraries", you might miss out on
possibilities for abstraction because many devices might appear
on the surface to only be singularly useful.

In the early days of coding, programmers focused on basic
algorithms.  We now have those algorithms, and they are so
standard that we can write an entire library of them in a very
generic way.  The same is true of data structures.  Now we have
entered a new era in programming where the entities being
explored are Concepts.  Concepts are not nearly so obvious to
formalize as algorithms and data structures, partly because we
need to see several uses of a concept before we determine its
usefulness.  And we cannot establish this baseline of usage
unless we look at a lot of GTM code.  It's a statistical process,
after all.  I wouldn't say that FC++ should be accepted on this
basis alone.  I think there are other reasons to consider the
library.  But I think it is an advantage in having the library as
part of Boost (because Boost is perhaps considered more
authoritative than other library collections).

Dave

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.581 / Virus Database: 368 - Release Date: 2/9/2004