[Tutor] Are you allowed to shoot camels? [kinda OT]

[Liam Clarke]

>I suppose that one might argue that I *still* just don't really get
>lambdas (and I wouldn't argue with that).  I can see some advantages
>to small inline functions, though I suspect that a more-explicit
>currying mechanism (such as the proposed partial() higher-order
>function) could easily replace such uses.  I'm sorry to say, though,
>that the supposed advantages of anonymity come across as little more
>than handwaving assertions to me, no matter how sincerely they're
>intended.

I'm with Jeff on this one - I've yet to see the light regarding
lambda's. I understand they're used through-out Tkinter GUI stuff, can
anyone put up an example of why a lambda is better? I would like to
'get' the concepts.

Is this one of those conceptual things like OOP?

Or is it a subtlety that a Masters in COSC is necessary to appreciate?


On Thu, 03 Feb 2005 16:06:55 -0800, Jeff Shannon <jeff at ccvcorp.com> wrote:
> Alan Gauld wrote:
> 
> >
> >>However, Python doesn't need lambdas to be able to write in a
> >>functional style.
> >
> > I disagree Jeff. It does need lambdas to do FP properly, and
> > better lambdas than we have currently. What it doesn't need
> > is the lambda keyword and syntax - although pesonally I like
> > lambda since it is descriptive!
> 
> Well, we'll have to continue to disagree on that. ;)  Personally, I
> can't help but think that 'lambda' is descriptive only to people
> who've experienced it elsewhere, and that that does *not* include the
> majority of the programming community, but I could be mistaken. :)
> 
> >>Functions are first-class objects and can be passed
> >>around quite easily,
> >
> > Yes, but lambdas are more than first class functions, they
> > are anonymous functions! In fact really just callable code
> > blocks, not necessarily functions in the strictest sense
> > (except that every callable in FP is a function...! ;-)
> 
> Well, given that in Python a function is just a callable code block
> that's bound to a name... ;)  Personally, I fail to see why having an
> anonymous function is such a huge conceptual advantage, no matter how
> many times this is proclaimed as truth by lambda-users, but again this
> is just my own impression.
> 
> > Having to define every function before using it would
> > be a big hassle and make code less readable IMHO.
> 
> Here, ISTM that you're emphasizing the in-line nature of lambdas as
> being their key usage point...  And personally, I prefer to have a
> glossary of terms rather than having to decipher jargon by context. ;)
> 
> >>only a few differences between lambdas and named functions in
> >> Python:
> >>
> >>   - Anonymous vs named
> >
> > the key feature
> 
> Again, I fail to see why this is such an advantage -- I've seen
> assertions that it is, over and over again, but never any convincing
> evidence....
> 
> >>   - Single expression vs suite of statements
> >
> > A python restriction.
> 
> Well, I *did* specify that I was talking about 'in Python'... ;)
> 
> 
> >>I'd also argue that the inline nature is the *true* differentiating
> >>feature of lambdas -- the fact that they're anonymous is relatively
> >>minor.
> >
> > I agree, if I had an inline mechanism that forced me to
> > provide a name I could just use 'f' over and over and
> > not feel too cheated, but its nicer not to have an artificial
> > name when theres no need.
> 
> Personally, I prefer to have the opportunity to provide a meaningful
> name, and don't see where a generic name is any more restrictive than
> having no name, but again, maybe that's just me.
> 
> >>So, while there are some advantages to having single-use callables
> >>be defined inline
> >
> > The other advantage is the huge conceptial advantage that
> > real lambdas confer. The breakthrough idea of
> >
> > def f(x): return x+x
> >
> > being the same as
> >
> > f = lambda x: x+x
> >
> > is only possible to demonstrate if you have lambda to start with.
> > And yet that concept of a function name being just another variable
> > and the callable code being an object in its own right becomes
> > much more obvious in my opinion. lambda is a learning tool which
> > shows what is really happening whereas def is just syntactic sugar.
> 
> Hm, I understood the idea of functions being just code objects that
> were bound to a name, and could be passed around, stored in
> collections, and effectively renamed, well before I really got a hold
> on lambdas as anything more than some confusing bit of magic.  Of
> course, I started in C, where I was fairly comfortable with the idea
> of function pointers; function objects are a pretty simple step up,
> abstraction-wise, from that.
> 
> I suppose that one might argue that I *still* just don't really get
> lambdas (and I wouldn't argue with that).  I can see some advantages
> to small inline functions, though I suspect that a more-explicit
> currying mechanism (such as the proposed partial() higher-order
> function) could easily replace such uses.  I'm sorry to say, though,
> that the supposed advantages of anonymity come across as little more
> than handwaving assertions to me, no matter how sincerely they're
> intended.  (I've just started to read through SICP, to pick up some
> lisp/scheme, in hopes of understanding the appeal a bit better, so
> maybe there's hope for me yet. ;) )
> 
> Jeff Shannon
> Technician/Programmer
> Credit International
> 
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> http://mail.python.org/mailman/listinfo/tutor
> 


-- 
'There is only one basic human right, and that is to do as you damn well please.
And with it comes the only basic human duty, to take the consequences.