On Tue, Dec 27, 2011 at 8:51 AM, Eelco <hoogendoorn.ee...@gmail.com> wrote: > That proves the original point of contention: that [Steve's demo code] is > suboptimal language design, not because terseness always trumps > verbosity, but because commonly-used constructs (such as parenthesis > or round brackets or whatever you wish to call them) are more > deserving of the limited space in both the ascii table and your > reflexive memory, than uncommonly used ones.
In Magic: The Gathering R&D, they have a term (the article reporting which I can't actually find at the moment) called "spread complexity" or "fan complexity" - the idea being that as you fan out a booster pack, you see a certain amount of complexity in front of you. The designers can afford to put more complex cards in as rares than they can as commons, because you see ten commons for every rare - so a common factors ten times as much as a rare in spread complexity. (Mark Rosewater, my apologies if I'm misremembering here!) The same applies here. When you cast your eye over a program, you're going to see certain syntactic elements a lot. Assignment, arithmetic, blocks of code (ie indent/dedent), and function calls are all extremely common; lambdas, the use of decorators, and exception handling are somewhat uncommon; and metaclasses, the writing of decorators, and reloading of modules are all quite rare. The elements that occur frequently should be: a) Readable and grokkable; b) Easily typed on a regular keyboard - no using ASCII character 126 to mean negation, tyvm! c) Make sense. Rarer elements (and I'm not talking about xenon and plutonium here) are allowed to have long names, obscure syntax, or even be shoved away in odd modules (the way module reloading is in Python 3). If 0.1% of your code is suddenly twice as large as it used to be, will you notice? But if a new syntax adds even 5% to the mindspace requirement of basic assignment, your code will majorly suffer. In summary: Terseness trumps verbosity primarily for common operations, and only when doing so does not violate rules a and c above. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
