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

[Bill Atkins]

aleaxit at yahoo.com (Alex Martelli) writes:

> Ken Tilton <kentilton at gmail.com> wrote:
>    ...
>> True but circular, because my very point is that () was a great design
>> choice in that it made macros possible and they made CL almost 
>> infinitely extensible, while indentation-sensitivity was a mistaken 
>> design choice because it makes for very clean code (I agree 
>> wholeheartedly) but placed a ceiling on its expressiveness.
>
> Having to give functions a name places no "ceiling on expressiveness",
> any more than, say, having to give _macros_ a name.
>
>
>> As for:
>> 
>> >  At a syntax-sugar
>> > level, for example, Lisp's choice to use parentheses as delimiter means
>> > it's undesirable, even unfeasible, to use the single character '(' as an
>> > ordinary identifier in a future release of the language.
>> 
>> (defun |(| (aside) (format nil "Parenthetically speaking...~a." aside))
>> => |(|
>> (|(| "your Lisp /is/ rusty.")
>> => "Parenthetically speaking...your Lisp /is/ rusty.."
>> 
>> :) No, seriously, is that all you can come up with?
>
> Interestingly, the SECOND lisper to prove himself unable to read the
> very text he's quoting.  Reread carefully, *USE THE ***SINGLE***
> CHARACTER* ... *AS AN ORDINARY IDENTIFIER*.  What makes you read a
> ``PART OF''  that I had never written?  You've shown how to use the
> characters as *PART* of an identifier [[and I believe it couldn't be the
> very start]], and you appear to believe that this somehow refutes my
> assertion?

Now I see what the problem is here - you just don't know what you're
talking about.  The identifier in Ken's and my samples *is* a single
character identifier.  The vertical bars tell the Lisp reader that
what's between them is exempt from other reading rules.

 (symbol-name '|(| ) => "("

 (length (symbol-name '|(| )) => 1

> Are you ready to admit you were utterly wrong, and (while it is indeed
> true that my Lisp is rusty) there is nothing in this exchange to show
> it, as opposed to showing rustiness in your ability to understand
> English?  Or shall we move from polite although total dissent right on
> to flamewars and namecalling?

Believe it or not, _you_ got it wrong.

> The point is, OF COURSE any design choice places limitations on future
> design choices; but some limitations are even DESIRABLE (a language
> where *every* single isolated character could mean anything whatsoever
> would not be "expressive", but rather totally unreadable) or at least
> utterly trivial (syntax-sugar level issues most typically are). Wilfully
> distorting some such limitation as meaning that one language "can scale"
> (when EVERY language inevitably has SOME such limitations) is not even
> funny, and clearly characterizes a polemist who is intent on proving a
> preconceived thesis, as opposed to an investigator with any real
> interest in ascertaining the truth of the matter.

Having to name a variable "paren" instead of "(" is not a serious
restriction.  I can't think of a single situation where being able to
do so would be useful.

That said, raw, out-of-the-box Common Lisp can accomodate you if you
both a) need variables named "(" and b) are unwilling to use the bar
syntax.  Simply redefine the parenthesis characters in the readtable
(a matter of four function calls) and get this abomination:

 {let {{( 3}}
   {+ ( 5}}

Lisp places no restrictions on you, even when your goal is as silly as
this one.

>> > Oh, is that the same Graham who writes:
>> 
>> So we are going to skip the point I was making about Common Lisp being
>> so insanely extensible? By /application/ programmers? Hell, for all we
>> know CL does have a BDFL, we just do not need their cooperation.
>
> 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, which is as crucial in the real world as
> obviously not understood by you (the law you misquoted was about adding
> personnel to a LATE project making it later -- nothing to do with how
> desirable it can be to add personnel to a large and growing collection
> of projects, scaling and growing in an agile, iterative way to meet
> equally growing needs and market opportunities).

Buh?  The project doesn't have to be late for Brooks's law to hold;
adding programmers, so goes Brooks reasoning, will always increase the
time required to complete the project because of various communication
issues.

> This specific debate grew from your misuse of "scalable" to mean or
> imply "a bazillion feechurz can [[and, implicitly, should]] be added to
> a language, and therefore anything that stands in the way of feechuritis
> is somehow holding the language back".  That's bad enough, even though
> in its contextual misuse of "scalable" it breaks new ground, and I don't
> want to waste even more time re-treading *old* ground as to whether the
> "*insane* extensibility" afforded by macros is a good or a bad thing in
> a language to be used for real-world software production (as opposed to
> prototyping and research).
>
>
>> > """
>> > A friend of mine who knows nearly all the widely used languages uses
>> > Python for most of his projects. He says the main reason is that he
>> > likes the way source code looks. 
>> 
>> No argument. The little Python I wrote while porting Cells to Python was
>> strikingly attractive. But it was a deal with the devil, unless Python
>> is content to be just a scripting language. (And it should be.)
>
> It's hard to attribute feelings to a programming language, but, if you
> really must, I'd say Pyton aspires to be *useful* -- if all you need is
> "just a scripting language", it will be content to be one for you, and
> 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 that they redefine the very concept
> of "large scale" -- believe me, once in a while at a conference I make
> the mistake of going to some talk about "large scale" this or that, and
> invariably stagger out once again with the realization that what's
> "large scale" to the world tends to be a neat toy-sized throwaway little
> experiment to my current employer).

You haven't given much justification for the claim that Python is a
particularly "scalable" language.  Sure, Google uses it, Graham gave
it some props somewhere in the middle of his notoriously pro-Lisp
writings, and even Norvig has said good things about it.

Fair enough. But what does Python offer above any garbage-collected
language that makes it so scalable?

>
>> OK, I propose a duel. We'll co-mentor this:
>> 
>>     http://www.lispnyc.org/wiki.clp?page=PyCells
>> 
>> In the end Python will have a Silver Bullet, and only the syntax will
>> differ, because Python has a weak lambda, statements do not always 
>> return values, it does not have macros, and I do not know if it has 
>> special variables.
>> 
>> Then we can just eyeball the code and see if the difference is 
>> interesting. These abstract discussions do tend to loop.
>
> As a SummerOfCode mentor, I'm spoken for, and can't undertake to mentor
> other projects. I do agree that these discussions can be sterile, and
> I'll be glad to see what comes of your "pycells" project, but until then
> there's little we can do except agree to disagree (save that I'd like
> you to acknowledge my point above, regarding what exactly I had said and
> the fact that your alleged counterexample doesn't address at all what I
> had said -- but, I'll live even without such an acknowledgment).
>
>
> Alex

-- 
This is a song that took me ten years to live and two years to write.
 - Bob Dylan