A critic of Guido's blog on Python's lambda

[Anton Vredegoor]

olsongt at verizon.net wrote:

> When you consider that there was just a big flamewar on comp.lang.lisp
> about the lack of standard mechanisms for both threading and sockets in
> Common Lisp (with the lispers arguing that it wasn't needed) I find it
> "curious" that someone can say Common Lisp scales well.

In comp.lang.python there are often discussions about which is the best 
web framework or what is the best gui. There seems to be some common 
meme in these kinds of discussions and the lambda controversy. I'm even 
ready to expand the concept even more and include documentation problems 
and polymorphic typing.

So what is the big advantage of using parens then that is making people 
give up documenting their code by naming functions? (See, I'm getting 
into the right kind of lingo for discussing these kind of questions)

Well, there seems to be some advantage to conceptually decoupling a 
function from what it is doing *now* (which can be easily named) and 
what it is doing in some other situation. Naming things is only a 
ballast and makes the mental model not "fit the brain" (introducing 
pythonic terminology here for the lispers).

This is a lot like polymorphic functions. For example an adding function 
   sometimes adds integers and sometimes floats or complex variables and 
it can be defined just once without specifying which type of parameters 
it is going to get. I assume this to be a piece of cake for most lispers 
and pythoneers, but possibly this could still confuse some static typers.

An anonymous function is like a polymorphic function in that it is 
possible to make the "mental model" about it polymorphic, instead of 
just its parameters. This enables the lispers to just "take what it does 
and paste it where that needs to be done" (inventing crypto speak here).

This is a very effective way of handling operations and it would 
surprise me if not 99 percent of the Python coders do things mentally 
this way too and only add names and documentation at the last possible 
moment (mental compile time documentation procedure).

So here we're integrating mental models concerning polymorphism into the 
way we talk and think about code, and naming things explicitly always 
seems to be a burden.

But now we let the other side of our brain speak for a moment, it was 
always the side that translated everything we wanted to say to each 
other here into mental Unicode so that we can hear what the others are 
saying (further diving into the linguistic pit I am digging here).

Yes, communication is what suffers from *not* naming things, and right 
after it documentation and standardization. How else are we going to 
communicate our findings verbally to the non coders and the trans coders?

Also naming functions and variables can help us create appropriate 
mental models that 'fix' certain things in place and keep them in the 
same state, because now they are 'documented'. This promotes people 
being able to work together and also it enables measuring progress, very 
important aspects for old world companies who won't understand the way 
things are evolving (even if they seem to have roaring success at the 
moment).

Not to say that I invented something new, it was always a theme, but now 
it's a meme,(he, he), the conflict between the scripture and the 
mysticism. It's such a pity that everyone understands some way or 
another that mysticism is the way things work but that none wants to 
acknowledge it.

What am I doing here coding Python one might ask, well, the knowledge 
has to be transfered to my brain first *somehow*, and until someone 
finds a better way to do that or until there is so much procedural 
information in my head that I can start autocoding (oh no) that seems to 
be the better option.

Anton