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

[Alex Martelli]

Tomasz Zielonka <tomasz.zielonka at gmail.com> wrote:

> Alex Martelli wrote:
> > Having to give functions a name places no "ceiling on expressiveness",
> > any more than, say, having to give _macros_ a name.
> 
> And what about having to give numbers a name?

Excellent style, in most cases; I believe most sensible coding guides
recommend it for most numbers -- cfr
<http://en.wikipedia.org/wiki/Magic_number_(programming)> , section
"magic numbers in code".

> > Yes, we are, because the debate about why it's better for Python (as a
> > language used in real-world production systems, *SCALABLE* to extremely
> > large-scale ones) to *NOT* be insanely extensible and mutable is a
> > separate one -- Python's uniformity of style allows SCALABILITY of
> > teams, and teams-of-teams
> 
> I think this kind of language scalability is most important for Google,
> see below.

It's definitely very important for Google, just as for most organization
doing software development on a large scale.


> > if your need SCALE, well then, PYTHON IS SCALABLE, and will remain a
> > *SIMPLE, CLEAN, LITTLE AND POWERFUL LANGUAGE* (letting nobody do
> > anything INSANE to it;-) while scaling up to whatever size of project(s)
> > you need (including systems so large...
> 
> But honestly, isn't this scalability a result of the data processing
> model you use, which is language independent? My point is that when you
> have such a well scaling data processing model, most languages scale
> well on the "data" and "load" axes, so you pick your language based on
> how well it scales on the "teams" and "features" axes.

There's one more axis, the "size of software project" one (in some unit
of measure such as function points).  That is partly related to
"language level", but it's not _just_ about that -- e.g., Ruby's
language level is basically the same as Python, but (in my modest
experience) it doesn't scale up quite as well to very large software
projects, as it's more prone to subtle coupling between modules (as it
makes it easy for one module to affect others indirectly, by making
modifications to fundamental globals such as "Object" and other built-in
types).


> You seem to claim that there is something in Python that lets it scale
> well on "data" and "load", and is not related to "teams" and "features",
> and also not related to Google's data processing model. Can you tell
> me what it is?

I don't think that (apart from whatever infrastructure Google may have
developed, and partly published in various whitepapers while partly
deciding to not discuss it publically) Python's scaling on "data" and
"load", to use your terminology, should be intrinsically different
(i.e., due to language differences) from that of other languages with
similar characteristics, such as, say, Ruby or Smalltalk.


Alex