[EMAIL PROTECTED] (Alex Martelli) writes: > Ken Tilton <[EMAIL PROTECTED]> wrote: > ... >> 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. > > In my opinion (and that of several others), the best way for Python to > grow in this regard would be to _lose_ lambda altogether, since named > functions are preferable (and it's an acknowledged Python design > principle that there should ideally be just one obvious way to perform a > task); GvR used to hold the same opinion, but changed his mind recently, > alas, so we'll keep the wart. > > But, quite apart from the whole issue of whether it's desirable to > languages to change massively ("add new power and capability" meaning > new enriched features in the language itself), your whole argument is > bogus: it's obvious that _any_ fundamental design choice in an artefact > will influence the feasibility and desirability of future design choices > in future releases of that same, identical artefact. 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. Considering > this to mean that Lisp "cannot scale" is just as ridiculous as > considering that Python "cannot scale" by not having an elegant way to > make lambdas heavier and richer -- totally laughable and idiotic. ``An > unneeded feature "cannot" be added (elegantly) in future releases of the > language'' is just as trivial and acceptable for the unneded feature > ``allow ( as an ordinary single-character identifier'' as for the > unneded feature ``allow unnamed functions with all the flexibility of > named ones''.
Not so infeasible: (let ((|bizarrely(named()symbol| 3)) (+ |bizarrely(named()symbol| 4)) ;; => 7 And in any case, enforced indentation is a policy with vastly more serious consequences than the naming of identifiers. >> By contrast, in On Lisp we see Graham toss off Prolog in Chapter 22 and > > Oh, is that the same Graham who writes: > > """ > 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. That may seem a frivolous reason to > choose one language over another. But it is not so frivolous as it > sounds: when you program, you spend more time reading code than writing > it. You push blobs of source code around the way a sculptor does blobs > of clay. So a language that makes source code ugly is maddening to an > exacting programmer, as clay full of lumps would be to a sculptor. > """ > ...? [[ I suspect that friend is in fact a common friend of mine and > Graham's, the guy you also mention later in your post, and who > introduced Graham and me when G recently came talk at Google (we had > "brushed" before, speaking in the same sessions at conferences and the > like, but had never "met", as in, got introduced and _talked_...;-). ]] > > But, no matter, let's get back to Graham's point: significant > indentation is a large part of what gives Python its own special beauty, > uncluttered by unneeded punctuation. And while you, I, Graham, and that > common friend of ours, might likely agree that Lisp, while entirely > different, has its own eerie beauty, most people's aesthetics are poles > apart from that (why else would major pure-FP languages such as *ML and > Haskell entirely reject Lisp's surface syntax, willingly dropping the > ease of macros, to introduce infix operator syntax etc...? obviously, > their designers' aesthetics weigh parenthesized prefixsyntax negatively, > despite said designers' undeniable depth, skill and excellence). > > > Alex -- This is a song that took me ten years to live and two years to write. - Bob Dylan -- http://mail.python.org/mailman/listinfo/python-list