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

[Ken Tilton]

Alex Martelli wrote:
> Ken Tilton <kentilton at gmail.com> wrote:
> 
> 
>>Martin P. Hellwig wrote:
>>
>>>Bill Atkins wrote:
>>><cut>
>>>
>>>>How do you define scalability?
>>>>
>>>
>>>http://www.google.com/search?hl=en&q=define%3Ascalability&btnG=Google+Search
>>>
>>
>>Damn! Google can do that?! Omigod!!! Not joking, I never knew that,a 
> 
> 
> You're welcome; we do have several little useful tricks like that.
> 
> 
>>lways used dictionary.com. Thx! I meant:
>>
>>
>>>The ability to add power and capability to an existing system without
>>>significant expense or overhead. www.yipes.com/care/cc_glossary.shtml
> 
> 
> Excellent -- just the definition of "scalability" that Google and its
> competitor live and die by ((OK, OK, I'm _not_ implying that such issues
> as usability &c don't matter, by no means -- but, I live mostly in the
> world of infrastructure, where scalability and reliability reign)).
> 
> 
> 
>>The number of definitions explains why most respondents should save 
>>their breath. Natural language is naturally ambiguous. Meanwhile Usenet
>>is the perfect place to grab one meaning out of a dozen and argue over
>>the implications of that one meaning which of course is never the one
>>originally intended, as any reasonable, good faith reader would admit.
> 
> 
> However, you and I are/were discussing exactly the same nuance of
> meaning, either by a funny quirk of fate or because it's the one that
> really matters in large-scale programming (and more generally,
> large-scale systems).  E.g., if your existing system can gracefully
> handle your current traffic of, say, a billion queries of complexity X,
> you want to be able to rapidly add a feature that will increase the
> average query's complexity to (X+dX) and attract 20% more users, so
> you'll need to handle 1.2 billion queries just as gracefully: i.e., you
> need to be able to add power and capability to your existing system,
> rapidly and reliably, just as that definition says.
> 
> When this is the challenge, your choice of programming language is not
> the first order of business, of course ...

Looks like dictionaries are no match for the ambiguity of natural 
language. :) Let me try again: it is Python itself that cannot scale, as 
in gain "new power and capability", and at least in the case of lambda 
it seems to be because of indentation-sensitivity.

Is that not what GvR said?

By contrast, in On Lisp we see Graham toss off Prolog in Chapter 22 and 
an object system from scratch in Chapter 25. Lite versions, to be sure, 
but you get the idea.

My sig has a link to a hack I developed after doing Lisp for less than a 
month, and without lambda (and to a lesser degree macros) it would be 
half the tool it is. It adds a declarative paradigm to the CL object 
system, and is built on nothing but ansi standard Lisp. Yet it provides 
new power and capability. And that by an application programmer just 
working on a nasty problem, never mind the language developer.

I just find it interesting that sexpr notation (which McCarthy still 
wants to toss!) is such a huge win, and that indentation seems to be so 
limiting.


-- your hardware and network
> architecture loom large, and so does the structuring of your
> applications and infrastructure software across machines and networks.
> Still, language does matter, at a "tertiary" level if you will. Among
> the potential advantages of Lisp is the fact that you could use Lisp
> across almost all semantic levels ("almost" because I don't think "Lisp
> machines" are a realistic option nowadays, so lower levels of the stack
> would remain in C and machine language -- but those levels may probably
> be best handled by a specialized squad of kernel-level and device-driver
> programmers, anyway); among the potential advantages of Python, the fact
> that (while not as suited as Lisp to lower-level coding, partly because
> of a lack of good solid compilers to make machine language out of it),
> it brings a powerful drive to uniformity, rather than a drive towards a
> host of "domain-specific" Little Languages as is encouraged by Lisp's
> admirably-powerful macro system.
> 
> One key axis of scalability here is, how rapidly can you grow the teams
> of people that develop and maintain your software base?

I am with Brooks on the Man-Month myth, so I am more interested in /not/ 
growing my team. If Lisp is <pick a number, any numer> times more 
expressive than Python, you need exponentially fewer people.

In some parallel universe Norvig had the cojones to dictate Lisp to 
Google and they listened, and in that universe... I don't know, maybe 
GMail lets me click on the sender column to sort my mail? :)

>  To meet all the
> challenges and grasp all the opportunities of an exploding market,
> Google has had to almost-double its size, in terms of number of
> engineers, every year for the last few years -- I believe that doing so
> while keeping stellar quality and productivity is an unprecedented feat,
> and while (again!) the choice of language(s) is not a primary factor
> (most kudos must go to our management and its approaches and methods, of
> course, and in particular to the strong corporate identity and culture
> they managed to develop and maintain), it still does matter.  The
> uniformity of coding style and practices in our codebase is strong.

Well, you said it for me. Google hires the best and pays a lot. Hey, I 
wrote great code in Cobol. So as much as you want to brag on yourself 
and Google <g>, your success does not address:

     Indentation-sensitivity: Is it holding Python back?

> 
> We don't demand Python knowledge from all the engineers we hire: for any
> "engineering superstar" worth the adjective, Python is really easy and
> fast to pick up and start using productively -- I've seen it happen
> thousands of times, both in Google and in my previous career, and not
> just for engineers with a strong software background, but also for those
> whose specialties are hardware design, network operations, etc, etc. The
> language's simplicity and versatility allow this. Python "fits people's
> brains" to an unsurpassed extent -- in a way that, alas, languages
> requiring major "paradigm shifts" (such as pure FP languages, or Common
> Lisp, or even, say, Smalltalk, or Prolog...) just don't -- they really
> require a certain kind of mathematical mindset or predisposition which
> just isn't as widespread as you might hope.

Talk about Lisp myths. The better the language, the easier the language. 
And the best programmers on a team get to develop tools and macrology 
that empower the lesser lights, so (a) they have fun work that keeps 
them entertained while (b) the drones who just want to get through the 
day are insanely productive, too.

Another myth (or is this the same?) is this "pure FP" thing. Newbies can 
and usually do code as imperatively as they wanna be. Until someone else 
sees their code, tidies it up, and the light bulb goes on. But CL does 
not force a sharp transition on anyone.


>  Myself, I do have more or
> less that kind of mindset, please note: while my Lisp and scheme are
> nowadays very rusty, proficiency with them was part of what landed me my
> first job, over a quarter century ago (microchip designers with a good
> grasp of lisp-ish languages being pretty rare, and TI being rather
> hungry for them at the time) -- but I must acknowlegde I'm an exception.
> 
> Of course, the choice of Python does mean that, when we really truly
> need a "domain specific little language", we have to implement it as a
> language in its own right, rather than piggybacking it on top of a
> general-purpose language as Lisp would no doubt afford; see
> <http://labs.google.com/papers/sawzall.html> for such a DSLL developed
> at Google. 

No lambdas? Static typing?! eewwwewww. :) Loved the movie, tho.

Come on, try just one meaty Common Lisp project at Google. Have someone 
port Cells to Python. I got halfway done but decided I would rather be 
doing Lisp. uh-oh. Does Python have anything like special variables? :)

Kenny

-- 
Cells: http://common-lisp.net/project/cells/

"Have you ever been in a relationship?"
    Attorney for Mary Winkler, confessed killer of her
    minister husband, when asked if the couple had
    marital problems.