What is different with Python ?

[Steven D'Aprano]

Re: What is different with Python ?

On Sun, 12 Jun 2005 20:22:28 -0400, Roy Smith wrote:
[color=blue]
> 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 suspect you would
> agree that's true, even if we don't agree just where the line should be
> drawn. You seem to feel that the level of abstraction exposed by a
> language like C is the right level. I'm not convinced you need to go that
> far down. I'm certainly not convinced you need to start there.[/color]

The important question is, what are the consequences of that faith when it
is mistaken?

As a Python developer, I probably won't write better code if I understand
how NAND gates work or the quantum mechanics of electrons in solid
crystals. But I will write better code if I understand how Python
implements string concatenation, implicit conversion from ints to longs,
floating point issues, etc.

It seems that hardly a day goes by without some newbie writing to the
newsgroup complaining that "Python has a bug" because they have discovered
that the floating point representation of 0.1 in decimal is actually more
like 0.1000000000000 0001. And let's not forget the number of bugs out
there because developers thought that they didn't need to concern
themselves with the implementation details of memory management.

It makes a difference whether your algorithm runs in constant time,
linear, quadratic, logarithmic or exponential time -- or something even
slower. The implementation details of the language can hide quadratic or
exponential algorithms in something that looks like a linear or constant
algorithm. Premature optimization is a sin... but so is unusably slow
code.



--
Steven.

[George Sakkis]

Re: What is different with Python ?

"Andrea Griffini" wrote:
[color=blue]
> 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.[/color]

There's a crucial distinction between these two scenarios though: the
first one has to do with today's hardware and software limitations
while the second one expresses fundamental, independent of technology,
algorithmic properties. In the not-too-far-future, the difference
between RAM and hard disks may be less important than today; hard disks
may be fast enough for most purposes, or the storage policy may be
mainly decided by the OS, the compiler, the runtime system or a library
instead of the programmer (similarly to memory management being
increasingly based on garbage collection). As programmers today don't
have to know or care much about register allocation, future programmers
may not have to care about whether something is stored in memory or in
disk. OTOH, an algorithm or problem with exponential complexity will
always be intractable for sufficiently large input, no matter how fast
processors become. The bottom line is that there is both fundamental
and contemporary knowledge, and although one needs to be good at both
at any given time, it's useful to distinguish between them.

George

[Mike Meyer]

Re: What is different with Python ?

Andrea Griffini <agriff@tin.i t> writes:[color=blue][color=green]
>>In short, you're going to start in the middle.[/color]
>
> I've got "bad" news for you. You're always in the
> middle :-D.[/color]

That's what I just said.
[color=blue][color=green]
>>Is it really justified to confuse them all
>>by introducing what are really extraneous details early on?[/color]
>
> I simply say that you will not able to avoid
> introducing them. If they're going to write software
> those are not "details" that you'll be able to hide
> behind a nice and perfect virtual world (this is much
> less true about bus cycles... at least for many
> programmers).[/color]

I disagree. If you're going to make competent programmers of them,
they need to know the *cost* of those details, but not necessarily the
actual details themselves. It's enough to know that malloc may lead to
a context switch; you don't need to know how malloc actually works.
[color=blue]
> But if you need to introduce them, then IMO is
> way better doing it *first*, because that is the
> way that our brain works.[/color]

That's the way *your* brain works. I'd not agree that mine works that
way. Then again, proving either statement is an interesting
proposition.

[color=blue][color=green]
>>You've stated your opinion. Personally, I agree with Abelson, Sussman
>>and Sussman, whose text "The Structure and Interpretation of Computer
>>Programs" was the standard text at one of the premiere engineering
>>schools in the world, and is widely regarded as a classic in the
>>field: they decided to start with the abstract, and deal with concrete
>>issues - like assignment(!) later.[/color]
>
> Sure. I know that many think that starting from
> higher levels is better. However no explanation is
> given about *why* this should work better, and I
> didn't even see objective studies about how this
> approach pays off. This is of course not a field
> that I've investigated a lot.[/color]

The explanation has been stated a number of times: because you're
letting them worry about learning how to program, before they worry
about learning how to evaluate the cost of a particular
construct. Especially since the latter depends on implementation
details, which are liable to have to be relearned for every different
platform.
[color=blue]
> What I know is that every single competent programmer
> I know (not many... just *EVERY SINGLE ONE*) started
> by placing firmly concrete concepts first, and then
> moved on higher abstractions (for example like
> structured programming, OOP, functional languages ...).[/color]

I don't normally ask how people learned to program, but I will observe
that most of the CS courses I've been involved with put aside concrete
issues - like memory management - until later in the course, when it
was taught as part of an OS internals course. The exception would be
those who were learning programming as part of an engineering (but not
software engineering) curriculum. The least readable code examples
almost uniformly came from the latter group.

<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Andreas Kostyrka]

Re: What is different with Python ?

On Mon, Jun 13, 2005 at 06:13:13AM +0000, Andrea Griffini wrote:[color=blue][color=green]
> >Andrea Griffini <agriff@tin.i t> writes:
> >So you're arguing that a CS major should start by learning electronics
> >fundamentals , how gates work, and how to design hardware(*)? Because
> >that's what the concrete level *really* is. Start anywhere above that,
> >and you wind up needing to look both ways.[/color][/color]
Yep. Probably. Without a basic understanding of hardware design, one cannot
many of todays artifacts: Like longer pipelines and what does this
mean to the relative performance of different solutions.

Or how does one explain that a "stupid and slow" algorithm can be in
effect faster than a "clever and fast" algorithm, without explaining
how a cache works. And what kinds of caches there are. (I've seen
documented cases where a stupid search was faster because all hot data
fit into the L1 cache of the CPU, while more clever algorithms where
slower).

So yes, one needs a basic understanding of hardware, so that one can
understand the design of "assembly". And without knowledge of these
you get C programmers that do not really understand what their
programs do. (Be it related to calling sequences, portability of their
code, etc.) Again you can sometimes see developers that pose questions
that suggest that they do not know about the lowlevel. (Example from a
current project: Storing booleans in a struct-bit-field so that it's
faster. Obviously such a person never seen the code needed to
manipulate bit fields on most architectures.)

A good C programmer needs to know about assembly, libc (stuff like
malloc and friends and the kernel API).

Now a good python programmer needs to know at least a bit about the
implementation of python. (Be it CPython or Jython).

So yes, one needs to know the underlying layers, if not by heart, than
at least on a "I-know-which-book-to-consult" level.

Or you get perfect abstract designs, that are horrible when
implemented.
[color=blue]
> Not really. Long ago I've drawn a line that starts at
> software. I think you can be a reasonable programmer
> even without the knowledge about how to design hardware.[/color]
Well, IMHO one needs to know at least a bit. But one doesn't need to
know it well enough to be able to design hardware by himself. ;)
[color=blue]
> I do not think you can be a reasonable programmer if
> you never saw assembler.
>[color=green]
> >Admittedly, at some level the details simply stop mattering. But where
> >that level is depends on what level you're working on. Writing Python,
> >I really don't need to understand the behavior of hardware[/color][/color]

Yes. But for example to understand the memory behaviour of Python
understanding C + malloc + OS APIs involved is helpful.
[color=blue][color=green]
> >gates. Writing horizontal microcode, I'm totally f*cked if I don't
> >understand the behavior of hardware gates.[/color]
>
> But you better understand how, more or less, your
> computer or language works, otherwise your code will
> be needless thousand times slower and will require
> thousand times more memory than is necessary.
> Look a recent thread where someone was asking why
> python was so slow (and the code contained stuff
> like "if x in range(low, high):" in an inner loop
> that was itself pointless).[/color]

Andreas

[Peter Maas]

Re: What is different with Python ?

Andrea Griffini schrieb:[color=blue]
> On Sat, 11 Jun 2005 21:52:57 -0400, Peter Hansen <peter@engcorp. com>
> wrote:
>
>[color=green]
>>I think new CS students have more than enough to learn with their
>>*first* language without having to discover the trials and tribulations
>>of memory management (or those other things that Python hides so well).[/color]
>
>
> I'm not sure that postponing learning what memory
> is, what a pointer is and others "bare metal"
> problems is a good idea.[/color]

I think Peter is right. Proceeding top-down is the natural way of
learning (first learn about plants, then proceed to cells, molecules,
atoms and elementary particles). If you learn a computer language
you have to know about variables, of course. You have to know that
they are stored in memory. It is even useful to know about variable
address and variable contents but this doesn't mean that you have
to know about memory management. MM is a low level problem that has
to do with the internals of a computer system and shouldn't be part
of a first *language* course.

The concepts of memory, data and addresses can easily be demonstrated
in high level languages including python e.g. by using a large string
as a memory model. Proceeding to bare metal will follow driven by
curiosity.

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Tel +49-241-93878-0
E-mail 'cGV0ZXIubWFhc0 BtcGx1c3IuZGU=\ n'.decode('base 64')
-------------------------------------------------------------------

[Tom Anderson]

Re: What is different with Python ?

On Sun, 12 Jun 2005, Roy Smith wrote:
[color=blue]
> Andrea Griffini <agriff@tin.i t> wrote:
>[color=green]
>> I think that for a programmer skipping the understanding of the
>> implementation is just impossible: if you don't understand how a
>> computer works you're going to write pretty silly programs. Note that
>> I'm not saying that one should understand every possible implementation
>> down to the bit (that's of course nonsense), but there should be no
>> room for "magic" in a computer for a professional programmer.[/color]
>
> How far down do you have to go? What makes bytes of memory, data busses,
> and CPUs the right level of abstraction?
>
> Why shouldn't first-year CS students study "how a computer works" at the
> level of individual logic gates? After all, if you don't know how gates
> work, things like address bus decoders, ALUs, register files, and the like
> are all just magic (which you claim there is no room for).
>
> Digging down a little deeper, a NAND gate is magic if you don't know how a
> transistor works or can't do basic circuit analysis. And transistors are
> magic until you dig down to the truly magical stuff that's going on with
> charge carriers and electric fields inside a semiconductor junction.
> That's about where my brain starts to hurt, but it's also where the quantum
> mechanics are just getting warmed up.[/color]

It's all true - i wouldn't be the shit-hot programmer i am today if i
hadn't done that A-level physics project on semiconductors.

tom

--
Think logical, act incremental

[Tom Anderson]

Re: What is different with Python ?

On Sun, 12 Jun 2005, Peter Hansen wrote:
[color=blue]
> Andrea Griffini wrote:[color=green]
>> On Sat, 11 Jun 2005 21:52:57 -0400, Peter Hansen <peter@engcorp. com>
>> wrote:
>>[color=darkred]
>>> I think new CS students have more than enough to learn with their
>>> *first* language without having to discover the trials and
>>> tribulations of memory management (or those other things that Python
>>> hides so well).[/color]
>>
>> I'm not sure that postponing learning what memory is, what a pointer is
>> and others "bare metal" problems is a good idea. ... I think that for a
>> programmer skipping the understanding of the implementation is just
>> impossible: if you don't understand how a computer works you're going
>> to write pretty silly programs.[/color]
>
> I won't say that I'm certain about any of this, but I have a very strong
> suspicion that the *best* first step in learning programming is a program
> very much like the following, which I'm pretty sure was mine:
>
> 10 FOR A=1 TO 10: PRINT"Peter is great!": END[/color]

10 PRINT "TOM IS ACE"
20 GOTO 10

The first line varies, but i suspect the line "20 GOTO 10" figures
prominently in the early history of a great many programmers.
[color=blue]
> More importantly by far, *I made the computer do something*.[/color]

Bingo. When you realise you can make the computer do things, it
fundamentally changes your relationship with it, and that's the beginning
of thinking like a programmer.

tom

--
Think logical, act incremental

[Tom Anderson]

Re: What is different with Python ?

On Mon, 13 Jun 2005, Andrea Griffini wrote:
[color=blue]
> On Sun, 12 Jun 2005 20:22:28 -0400, Roy Smith <roy@panix.co m> wrote:
>[color=green][color=darkred]
>>> 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.[/color]
>>
>> 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".[/color]
>
> 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.[/color]

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

--
Think logical, act incremental

[Roy Smith]

Re: What is different with Python ?

Andrea Griffini <agriff@tin.i t> wrote:[color=blue]
> 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.[/color]

People were thinking about algorithmic complexity before there was random
access memory. Back in the unit record equipment (i.e. punch card) days,
people were working out the best ways to sort and merge decks of punch
cards with the fewest trips through the sorting machine. Likewise for data
stored on magnetic tape.

I can certainly demonstrate algorithmic complexity without ever going
deeper than the level of abstraction exposed by Python. You can learn
enough Python in an afternoon to write a bubble sort and start learning
about O(2) behavior without even knowing what a memory address is.

Somebody mentioned that string addition in Python leads to O(2) behavior.
Yes it does, but that's more an artifact of how Guido decided he wanted
strings to work than anything fundamental about memory allocation. He
could have taken a different design path and made Python strings more like
STL vectors, in which case string addition would be O(n). Teaching that
"string addition is O(2)" is not only needlessly confusing for somebody
just starting out, it's also wrong (or at best, a specific case valid for
one particular implementation) .

And, BTW, I started out programming on a big HP desktop calculator
(http://www.hpmuseum.org/hp9810.htm). Next came BASIC. Then Fortan and
assembler on a pdp-10. Then C, a couple of years later. After that, I've
lost track. Some of the languages that taught me the most were ones that
got very far away from the hardware. NewtonScript was my first
introduction to OOPL, and PostScript showed me that stack languages aren't
just for calculators. Lisp, of course, expanded my mind in ways that only
Lisp can (the same could be said for many things I tried back in those
days). Even quirky HyperCard showed me a different way to think about
programming.

I think it's probably just as important for a CS major to play with those
mind-altering languages as it is to worry about bytes and pointers and
memory locations. But you can't start everywhere, and if you've got to
start someplace, Python let's you concentrate on the real universal
fundamentals of data structures, algorithms, and control flow without
getting bogged down in details.

[F. Petitjean]

Re: What is different with Python ?

Le Mon, 13 Jun 2005 07:53:03 -0400, Roy Smith a écrit :[color=blue]
> Python let's you concentrate on the real universal
> fundamentals of data structures, algorithms, and control flow without
> getting bogged down in details.[/color]

+1 QOTW

[Tom Anderson]

Re: What is different with Python ?

On Mon, 13 Jun 2005, Roy Smith wrote:
[color=blue]
> O(2) behavior[/color]

Um ...
[color=blue]
> Lisp, of course, expanded my mind in ways that only Lisp can (the same
> could be said for many things I tried back in those days).[/color]

Surely you're not saying you experimented with ... APL?
[color=blue]
> I think it's probably just as important for a CS major to play with
> those mind-altering languages as it is to worry about bytes and pointers
> and memory locations. But you can't start everywhere, and if you've got
> to start someplace, Python let's you concentrate on the real universal
> fundamentals of data structures, algorithms, and control flow without
> getting bogged down in details.[/color]

Ah, so you've cleaned yourself up with Guido's Twelve-Step Plan. Amen to
that, brother!

tom

--
Why do we do it? - Exactly!

[Terry Hancock]

Re: What is different with Python ?

On Monday 13 June 2005 12:55 am, Andrea Griffini wrote:[color=blue]
> On Sun, 12 Jun 2005 20:22:28 -0400, Roy Smith <roy@panix.co m> wrote:
>[color=green]
> >How far down do you have to go? What makes bytes of memory, data busses,
> >and CPUs the right level of abstraction?[/color]
>
> They're things that can be IMO genuinely accept
> as "obvious".[/color]

Hah!

Try explaining them to my non-programmer mother or
my 9-year-old son. On the other hand, telling them that
Python attaches a label (or name) to an object (which can
be "anything") was a cinch. Both want to program, but
are currently still struggling with basic concepts.

Interestingly, my son had no problem at all with the "name"
versus "variable" distinction -- that seems to be a case where
my C experience caused me problems, but it's a non-issue
coming from a tabula rasa perspective.

--
Terry Hancock ( hancock at anansispacework s.com )
Anansi Spaceworks http://www.anansispaceworks.com

[Mike]

Re: What is different with Python ?

[color=blue]
>there should be no room for "magic" in a computer
>for a professional programmer.
>[/color]
well put. sounds like the makings of a good signature...

[Philippe C. Martin]

Re: What is different with Python ?

> So you're arguing that a CS major should start by learning electronics[color=blue]
> fundamentals, how gates work, and how to design hardware(*)? Because
> that's what the concrete level *really* is. Start anywhere above that,
> and you wind up needing to look both ways.[/color]

Some very good schools still believe that


Mike Meyer wrote:
[color=blue]
> Andrea Griffini <agriff@tin.i t> writes:[color=green]
>> On Sat, 11 Jun 2005 21:52:57 -0400, Peter Hansen <peter@engcorp. 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.[/color]
>
> So you're arguing that a CS major should start by learning electronics
> fundamentals, how gates work, and how to design hardware(*)? Because
> that's what the concrete level *really* is. Start anywhere above that,
> and you wind up needing to look both ways.
>
> Admittedly, at some level the details simply stop mattering. But where
> that level is depends on what level you're working on. Writing Python,
> I really don't need to understand the behavior of hardware
> gates. Writing horizontal microcode, I'm totally f*cked if I don't
> understand the behavior of hardware gates.
>
> In short, you're going to start in the middle. You can avoid looking
> down if you avoid certain classes of problems - but not everyone will
> be able to do that. Since you can only protect some of the students
> from this extra confusion, is it really justified to confuse them all
> by introducing what are really extraneous details early on?
>
> You've stated your opinion. Personally, I agree with Abelson, Sussman
> and Sussman, whose text "The Structure and Interpretation of Computer
> Programs" was the standard text at one of the premiere engineering
> schools in the world, and is widely regarded as a classic in the
> field: they decided to start with the abstract, and deal with concrete
> issues - like assignment(!) later.
>
> <mike
>
> *) "My favorite programming langauge is solder." - Bob Pease
>[/color]

[Philippe C. Martin]

Re: What is different with Python ?

> I don't buy that. I think there's a world of difference between knowing[color=blue]
> 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.[/color]


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:
[color=blue]
> On Mon, 13 Jun 2005, Andrea Griffini wrote:
>[color=green]
>> On Sun, 12 Jun 2005 20:22:28 -0400, Roy Smith <roy@panix.co m> wrote:
>>[color=darkred]
>>>> 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".[/color]
>>
>> 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.[/color]
>
> 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
>[/color]