Re: [OT] Re: D gets it right
From: MSCHAEF.COM (mschaef_at_io.com)
Date: 02/14/04
- Next message: MSCHAEF.COM: "Re: D gets it right"
- Previous message: David Turner: "Re: [OT] Re: D gets it right"
- In reply to: David Turner: "Re: [OT] Re: D gets it right"
- Next in thread: David Turner: "Re: [OT] Re: D gets it right"
- Reply: David Turner: "Re: [OT] Re: D gets it right"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sat, 14 Feb 2004 12:56:57 -0600
In article <592f3326.0402140838.24d4863c@posting.google.com>,
David Turner <david@firepro.co.za> wrote:
...
>> (define (remove pred lis)
>> (filter (lambda (x) (not (pred x))) lis))
>
>Dear me and tsk tsk. What was wrong with the following?
I was kind of hoping that someone would post a nice example with
templates. I'm behind the curve enough on C++ that it doesn't suprise
me at all that STL has better support that what I posted. (I think it's
worth pointing out that I think that my C++ code is closer to a "state
of the art" idiom for languages like C# and Java, at least until C# gets
its own anonymous function support.)
>remove_if(list.begin(), list.end(),
> not1(
> bind1st(
> mem_fun(&IObjectPredicate::satisfies),
> predicateObject
> )
> )
>);
>If anything, I think the C++ version is easier to comprehend than the
>Lisp version ;-).
I think that's a matter of perspective. Coming from more Lispy background,
I'd make the opposite statement. Without direct experience with the idiom
you've posted, there are several issues that more specificaly concern me:
* With not1 and bind1st, you're limited to referencing arguments, by
ordinal, aren't you? I'd consider that a disadvantage compared to the
by name references available in Lisp/Scheme.
* You still have this explicit "IObjectPredicate" concept, which seems
very heavyweight compared to an anonymous function and its lexical
bindings. Even if you can pass in a non-member function and bypass the
whole idea of a predicate object, you're still reduced to defining your
predicate functions out of line compared to where they're used. I guess
you can use boost lambdas, but again you're limited to referring to
parameters by ordinal, which has never, as far as I can remember, been
considered best (or even good) practice in higher level language
design.
* A lot of this logic is done using templates and I question how easy
templates are to debug. At least in Visual C++ 7, the diagnostics
offered by the compiler on a template error seem fairly limited.
(This is also a problem I have with template metaprogramming. I've
seen some pretty amazing things done with templates, but compared
to Lisp languages where you get to use the whole native language
while metaprogramming, C++ limits you to a radically limited language
with limited support for debugging.)
>To be fair, though, there is a larger body of knowledge to master.
I agree that C++ has a larger body of knowledge. Maybe the way I'd phrase
it is, "C++ has more fundamental rules to learn than Lisp". I just don't
think that the added complexity has much of a payoff in terms of power
or safety.
The other thing that's worth pointing out is that my style has always
tended towards skipping straight from C to higher level language like
Scheme and Lisp (and long ago, Tcl). I've never fully bought into C++'s
value propositon, and it's always biased my opinions on these issues in
"non-mainstream" ways.
-Mike
-- http://www.mschaef.com
- Next message: MSCHAEF.COM: "Re: D gets it right"
- Previous message: David Turner: "Re: [OT] Re: D gets it right"
- In reply to: David Turner: "Re: [OT] Re: D gets it right"
- Next in thread: David Turner: "Re: [OT] Re: D gets it right"
- Reply: David Turner: "Re: [OT] Re: D gets it right"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
