From: David Abrahams (dave_at_[hidden])
Date: 2004-03-02 10:49:10
"Gennadiy Rozental" <gennadiy.rozental_at_[hidden]> writes:
>> > 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
>> > far as possible. After all usage of FP techniques it's primary reason
>> > compilation more and more taking ridiculously long time nowadays.
>> How much expressiveness are you willing to trade away in order to get
>> short compile times? I would choose a Spirit parser over a
>> hand-written one any day, simply because the Spirit parser is more
>> maintainable and more directly expresses the intent of the programmer,
>> and does so at the same level of abstraction at which the programmer
>> is thinking.
> Actually the point of my remark is that would we be able to write meta
> programs in imperative style instead of FP style compilation would be much
The slowness of metaprogram compilation has almost *nothing* to do
with the FP style of metaprogramming, and almost everything to do with
the accidental nature of the metaprogram evaluation engine (using
template instantiation). In fact, you *can* write metaprograms in an
imperative style, given an appropriate framework designed to interpret
them correctly. It'll be much slower than what we use today.
> And Spirit framework would benefit from it the most.
I doubt that. Parsing in particular has little to gain from the use
of mutable data.
>> > IOW from where I stand now I wouldn't want my fellow coworkers to
>> > start using FP in our design. If you(anybody) know an example where
>> > FP actually does bring any advantages, please step out.
>> Consider me stepped. Even using as simple an algorithm as for_each
>> with an appropriate function object has some advantages over a
>> hand-written loop.
> I never question usefulness of function object (any-morphic). What I
> do seek is an example of lazy list application.
Then you should say so. "FP has no advantages" is a far cry from
"Lazy lists have no advantages".
-- Dave Abrahams Boost Consulting www.boost-consulting.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk