Home Original page

Python's simplicity philosophy

Jay O'Connor joconnor at cybermesa.com
Thu Nov 27 12:28:19 EST 2003 
Jumping into this a bit late...

Douglas Alan wrote:

>Alex Martelli <aleax at aleax.it> writes:
>
>  
>
>>>That would have a larger big O time growth value -- most likely
>>>O(n * log n) vs. O(n), for reasonable implemenations.  And while I
>>>      
>>>
>
>  
>
>>If the sequence is carefully randomized, yes.  If the sequence has
>>any semblance of pre-existing order, the timsort is amazingly good
>>at exploiting it, so that in many real-world cases it DOES run as
>>O(N).
>>    
>>
>
>C'mon -- to make robust programs you have to assume the worst-case
>scenario for your data, not the best case.  I certainly don't want to
>write a program that runs quickly most of the time and then for opaque
>reasons slows to a crawl occasionally.  I want it to either run
>quickly all of the time or run really slowly all of the time (so that
>I can then figure out what is wrong and fix it).
>
>  
>

I think that's a bit naive.  You really need to understand what the 
usage pattern of your data is going to be like.  If upstream data is 
being validity checked by the UI, for exampe, then you can generally 
assume that most of the data is valid and you code assuming that most of 
the data will be good.  If a pathological case happens that slows the 
system down but that case is likely to happen only once a month, it may 
be worth it.   However, if 50% of your data is likely to be bad than 
that would be unaccetable.

>>Me too!  That's why I'd like to make SURE that some benighted soul
>>cannot code:
>>    
>>
>
>  
>
>>    onebigstring = reduce(str.__add__, lotsofstrings)
>>    
>>
>
>The idea of aiming a language at trying to prevent people from doing
>stupid things is just innane, if you ask me.  It's not just inane,
>it's offensive to my concept of human ability and creativity.  Let
>people make their mistakes, and then let them learn from them.  Make a
>programming language to be a fluid and natural medium for expressing
>their concepts, not a straight-jacket for citing canon in the
>orthodox manner.
>  
>
I agree completely.  One reason I like Smalltalk and Python is that they 
keep track of the mundane book-keeping, but then get out of my way and 
don't try to limit me too much.

>And Python suits me fine.  But if it continues to be bloated with a
>large number special-purpose features, rather than a small number of
>general and expressive features, there may come a time when Python
>will no longer suit me.
>  
>

This is something I'm watching as well.  I use Python where Smalltalk in 
inappropriate.  One thing I like about Smalltalk is that it has a small 
number of powerful general principles that it follows extensively. This 
means there are not a  lot of suprises and not a lot of 'language rules' 
to keep in mind when writing my code or looking at others. What first 
attracted me to Python was a lot of the same thing; simple syntax and 
some simple concepts used throughout. To me there is a difference 
between adding to a language and extending a language along it's own 
principles.  As Python grows and matures, if it solidifies and extends 
along it's natural principles, I will be happy.  If it just adds new 
stuff on, I won't be as happy.  I think list comprehensions, where the 
first thing I saw that made me nervous as to how the language was going 
to grow.

>  
>
>>If you consider Python to be preferable, then there must be some
>>point on which you disagree with him.  In my case, I would put
>>"simplicity vs generality" issues as the crux of my own
>>disagreements with Dr. Graham.
>>    
>>
>
>Bloating the language with lots of special-purpose features does not
>match my idea of simplicity.  To the extent that I have succeeded in
>this world, it has always been by understanding how to simplify things
>by moving to a more general model, meaning that I have to memorize and
>understand less.  Memorizing lots of detail is not something I am
>particurly good at, and is one of the reasons why I dislike Perl so
>much.  Who can remember all that stuff in Perl?  Certainly not I.  I
>suppose some people can, but this is why *I* prefer Python -- there is
>much less to remember.
>  
>

Ditto
More information about the Python-list mailing list