Re: Python's simplicity philosophy
From: Jay O'Connor (joconnor_at_cybermesa.com)
Date: 11/27/03
- Next message: Rene Pijlman: "Re: [OT] Spambays question"
- Previous message: Bengt Richter: "Re: Simple instructions on how to programmatically download an image from a web page?"
- In reply to: Douglas Alan: "Re: Python's simplicity philosophy"
- Next in thread: BW Glitch: "Re: Python's simplicity philosophy"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 27 Nov 2003 10:28:19 -0700
Jumping into this a bit late...
Douglas Alan wrote:
>Alex Martelli <aleax@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
- Next message: Rene Pijlman: "Re: [OT] Spambays question"
- Previous message: Bengt Richter: "Re: Simple instructions on how to programmatically download an image from a web page?"
- In reply to: Douglas Alan: "Re: Python's simplicity philosophy"
- Next in thread: BW Glitch: "Re: Python's simplicity philosophy"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
