basic rules of design (was Re: Comments on Python Redesign)

Alex Martelli aleax at aleax.it
Mon Sep 8 07:28:49 EDT 2003


Fernando Perez wrote:
   ...
> A basic rule of design should always be:  a default (www.python.org) value
> should satisfy the _majority_ of usage cases (not those with the most
> money/corporate power/whatever).  Since the majority of visitors to the
> site can arguably be thought to be developers, _that_ is the audience the

As a general principle of design, this is wrong, because it does not
take into account the _COST_ of occurrences of "not satisfying".

Consider dictionary addressing: what DOES one want to occur when the
key is not in the dict in an operation such as thedict[thekey]?  It is
arguable that in a majority of cases one wants to use a default value
while the need to get an error is somewhat rarer.  HOWEVER, this does
not mean Python's design is wrong, because this simple count regarding
"majority of use cases" is not considering the *COSTS*.  If absent keys
implicitly supplied a default value, then using the default when an
error should be instead raised for key absence would produce weird and
hard-to-debug error situations down the line; as is, using the default
when in fact one wants to supply a default value immediately produces
an exception that shows one must use .get (or whatever) instead.  So,
the current design may well be optimal even though it might appear to
conflict with the "basic rule of design" as Fernando mistakenly states it.

Of course, if one DOES consider costs appropriately, then the thesis that
Fernando wants to promote doesn't necessarily follow any more.  It may
well be argued that developers are more web-savvy than managers and other
corporate decision-makers, easily able to follow a link and/or set a
bookmark as appropriate -- so that failing to serve developers by the
default homepage has low cost, while failing to serve managers by it
(even though it were true that *EVEN IN THE FUTURE* most visitors will
be developers) may well have higher costs.

This doesn't necessarily have to do with "money" or "corporate power",
but rather with ability of the two sub-audiences to negotiate different
levels of difficulty -- what's trivial to a developer may well not be
to an executive.  Analogy: say that due to space constraints (adapting
to public use an existing Renaissance building, a frequent case around
here) I have to choose EITHER a few steps or stairs OR a ramp as the
building's main public access way.  Maybe for 95% of the visitors the
stairs are marginally more convenient than the ramp.  If one were to
apply Fernando's mistakenly-stated principle, one would choose stairs.
But actually the inconvenience of ramps vs stairs to those 95% of users
is minor, call it 0.01 in some arbitrary unit of utility -- while for
the 5% of visitors who are wheelchair-bound, the stairs are *WAY* more
problematic than the ramp, say by 10.0 in the same unit of measure.

So if one were to follow Fernando's principle of serving the majority
of use cases, overall loss of utility for 100 visitors would be 50.0
units (10.0 each for the 5 wheelchair-bound visitors); by following the
RIGHT principle of maximizing overall utility (WEIGHING the frequency
by the cost, a TRUE key principle of design!), the overall loss of
utility would be 0.95 (0.01 each for the 95 non-wheelchair-bound
visitors).  Thus, the application of Fernando's mistaken principle
would be a minor tragedy in term of design failure in this hypothetical
case.  It's not an issue of anybody being a "second class citizen",
as Fernando emotionally puts it: it IS an issue of the ables and
strongest, even if in a majority, making a (to them) minor sacrifice
to help less-able and weaker ones, even if in a minority, avoid what
(to them) might more likely be a serious problem.

If designers will consider this issue more generally when making their
key architectural decisions, then this whole weird thread may have
repaid itself by this single observation;-).


Alex





More information about the Python-list mailing list