What is different with Python ?

[Philippe C. Martin]

> I don't buy that. I think there's a world of difference between knowing
> what something does and how it does it; a black-box view of the memory
> system (allocation + GC) is perfectly sufficient as a basis for
> programming using it. That black-box view should include some idea of how
> long the various operations take, but it's not necessary to understand how
> it works, or even how pointers work, to have this.


Maybe you should say programming at the application level. Also if you will
notice from this newsgroup that people are sometimes trying to figure out
how to optimize the speed of their application; you will also notice that
the answers they get usually involve how Python is implemeted in their
specific environment.


I like analogies: twice in my career in and two different companies in two
different industries, it was decided that the application should be
prototyped on workstations and then ported to the embedded environment.
Both times, the speed/size of the "ported" code was so bad that it was
virtually unsusable. It was then decided to spend some time (it took years)
optimizing the system(s) to make it feasible.

I am conviced that if some of the target constraints had been taken into
consideration from the beginning:
1) much less time would have been spent in the optimization process.
2) the architecture of the final piece of code would have been cleaner.

Assuming I am correct, this implies that the folks working on the initial
prototypes should fully understand the constraints of a realtime embedded
environment (and that includes memory management)

Regards,

Philippe






Tom Anderson wrote:

> On Mon, 13 Jun 2005, Andrea Griffini wrote:
> 
>> On Sun, 12 Jun 2005 20:22:28 -0400, Roy Smith <roy at panix.com> wrote:
>>
>>>> Also concrete->abstract shows a clear path; starting in the middle and
>>>> looking both up (to higher abstractions) and down (to the
>>>> implementation details) is IMO much more confusing.
>>>
>>> At some point, you need to draw a line in the sand (so to speak) and
>>> say, "I understand everything down to *here* and can do cool stuff with
>>> that knowledge.  Below that, I'm willing to take on faith".
>>
>> I think that if you don't understand memory, addresses and allocation
>> and deallocation, or (roughly) how an hard disk works and what's the
>> difference between hard disks and RAM then you're going to be a horrible
>> programmer.
>>
>> There's no way you will remember what is O(n), what O(1) and what is
>> O(log(n)) among containers unless you roughly understand how it works.
>> If those are magic formulas you'll just forget them and you'll end up
>> writing code that is thousands times slower than necessary.
> 
> I don't buy that. I think there's a world of difference between knowing
> what something does and how it does it; a black-box view of the memory
> system (allocation + GC) is perfectly sufficient as a basis for
> programming using it. That black-box view should include some idea of how
> long the various operations take, but it's not necessary to understand how
> it works, or even how pointers work, to have this.
> 
> tom
>