Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Comments on Python Redesign

Reply
Thread Tools

Comments on Python Redesign

 
 
Alex Martelli
Guest
Posts: n/a
 
      09-08-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

 
Reply With Quote
 
 
 
 
Gerrit Holl
Guest
Posts: n/a
 
      09-08-2003
Erik Max Francis wrote:
> Tim Parkin wrote:
> > Perhaps the people who have commented on the site should realise it's
> > a proposal and a work in progress.

>
> Could someone remind me what need there is for a redesign in the first
> place? Of all the Python-related efforts that one could put time into,
> this seems like one of the least useful.


What I *do* think, is that it would be useful to put the FAQ more
prominently on the site. Maybe posting the FAQ to c.l.py weekly,
in a separate post, also helps. I don't really mind seeing questions
answered in the FAQ, but it will help because the FAQ is not very
easy to find.

(The FAQ actually _is_ linked from the front page of www.python.org, but
there are exactly 114 links on the front page: not exactly easy to find
the FAQ between them, especially if you're new)

Gerrit.

--
107. If the merchant cheat the agent, in that as the latter has
returned to him all that had been given him, but the merchant denies the
receipt of what had been returned to him, then shall this agent convict
the merchant before God and the judges, and if he still deny receiving
what the agent had given him shall pay six times the sum to the agent.
-- 1780 BC, Hammurabi, Code of Law
--
Asperger Syndroom - een persoonlijke benadering:
http://people.nl.linux.org/~gerrit/
Het zijn tijden om je zelf met politiek te bemoeien:
http://www.sp.nl/

 
Reply With Quote
 
 
 
 
=?ISO-8859-1?Q?Gerhard_H=E4ring?=
Guest
Posts: n/a
 
      09-08-2003
Erik Max Francis wrote:
> Could someone remind me what need there is for a redesign in the first
> place? Of all the Python-related efforts that one could put time into,
> this seems like one of the least useful.


I guess (I may be wrong) that Tim Parkin is not a developer, but
apparently he has experience with web design. For some reason he chose
to volunteer for proposing a redesign of the Python homepage (foolishly
so, he might think by now). There's hardly any point in you telling him
what to spend his time on for free, is there? :-/

Generally, in the open source community there's no point in telling
people what they should do. Of those that are involved with open source
in their spare time, everybody contributes to what are her or his
priorities, according to their skills. Many of these projects might be a
waste of time, but neither of your time nor mine

I dislike the connotation that web design (or writing documentation)
would be less valuable than more technical contributions to Python.

-- Gerhard

 
Reply With Quote
 
Robin Becker
Guest
Posts: n/a
 
      09-08-2003
In article <(E-Mail Removed)>, Tim Parkin
<(E-Mail Removed)> writes
>Bengt Wrote
>>It looks slick, but not really technically slick in a way
>>that would lead me to expectations about Python, just
>>eye-candy/we-spend-more-on-advertising-than-research
>>kind of slick (though for largely irrelevant photos, I
>>prefer pretty things and/or great photography

>
>What has amazed me throughout the pulling of a discussion
>Onto the Python list is the amount of furor that has been
>generated by the use of three photographs. The marketing
>content of the website takes only 7% of the space of the
>main page. The remaining is textual navigation content.

...... I don't actually hate the photos, though they do give me a bit of
that awful corporate entrapment feeling (at a recruitment event someone
asked me why all the people in the slides were young when we wanted
commitment and promised a long term career etc etc).

The problem for me at least is that even with ADSL they slow things to a
crawl for a period and then things pop up. This is after all just eye-
candy and I want the real protein.

There is also the bicycle shed effect. We pretty well understand the
concepts although the colour may be wrong.
--
Robin Becker
 
Reply With Quote
 
Anton Vredegoor
Guest
Posts: n/a
 
      09-08-2003
Alex Martelli <(E-Mail Removed)> 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".


Since no one dares to tackle this, and it has to be dealt with,
reluctantly I'll make a start. There's more to it than costs, also the
*changing of the definition of what gains and costs are* and the
directions one wants to take have to be considered.

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


The general idea seems to be that it's costing very little to give way
to managers while it brings a lot of advantages that cannot be gained
any other way because of the low tolerance of these people for
developer friendly web sites. While this dichotomy is questionable
from the outset there are also other issues that are more important
than static traffic analysis.

For example consider Christopher Columbus setting foot on America for
the first time. This is not just some dry historic fact but it also
marked the exact landing place as a place with higher probability of
future expeditions landing at the same spot. While it is not *sure*
following parties will choose the same spot, it still is likely that
they will follow directions from the first traveler. Also a small base
camp or the remains of it will make it easier for the next ship. Maybe
there where some friendly relations with the local population later
and some primitive exchange of goods (that was before some other
highly ominous occurrence prompted the visitors to wipe out almost the
entire population of the continent, I don't claim to know the exact
details but it's just an image )

For those more given to statistical analysis consider f.e. a 100x100
grid where each point initially has a probability of 1/10000 to be
selected. After a point is selected the point itself and some points
in its neighborhood receive higher probabilities to be selected next
time, (all probabilities can be scaled anew after that, so that they
once again sum nicely up to 1.0) Now repeat the process a few thousand
times and some chaos-like (highly dependent on initial occurrences)
distribution of hits per point will result.

From this thought experiment completely different statistical
evaluations follow than those from f.e. a static analysis of web
traffic, because the *evaluation function* itself changes as a result
of previous hits. This calls for a different kind of view than mere
static statistical evaluation, it calls for more active anticipating
what direction one wants to go because of the importance of initial
conditions. To see an example of what I mean visit f.e. the home of
the Rubik's cube.

http://www.rubiks.com/

There's just business advertisement there, nothing else, it's dead as
a dodo, or should I say parrot?

Anton
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
RE: Comments on Python Redesign Tim Parkin Python 20 09-09-2003 05:30 PM
RE: Comments on Python Redesign Tim Parkin Python 20 09-09-2003 03:45 PM
RE: Comments on Python Redesign Tim Parkin Python 1 09-08-2003 06:20 PM
Re: Comments on Python Redesign James P. Rutledge Python 3 09-07-2003 10:23 PM
Comments on Python Redesign Tim Parkin Python 0 09-07-2003 11:43 AM



Advertisments