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

[Alex Martelli]

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?

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?

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.

> > 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).

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).


> 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