What is different with Python ?

[Roy Smith]

Re: What is different with Python ?

John Machin <sjmachin@lexic on.net> wrote:
[color=blue][color=green]
> > I know I'm going out on a limb by asking this, but why do you think future
> > software engineers should know about memory management?[/color]
>
> Perhaps we have a terminology problem here i.e. different meanings of
> "software engineer". Philippe started talking about "CS" courses,
> whereas you may be referring to people who have done an "IT" course or
> achieved a certification in the use of app development tool X.[/color]

No, you've missed the point entirely.

No, the problem is that I'm out on the limb, and you're still comfortably
standing on the ground leaning up against the trunk. Climb up and come out
on the limb with me. Now, stop hugging the trunk and take a few steps out
here with me. Don't worry about how it's swaying, and whatever you do,
don't look down.

The point I was trying to make was that as computer science progresses,
stuff that was really important to know a lot about becomes more and more
taken for granted. This is how we make progress.

I used to worry about memory busses at the milivolt and microsecond level.
I knew about termination impedances and wired-OR logic, and power budgets
and all that good stuff. Today all I know about memory is you go to
www.crucial.com, type in your Visa card number, and the nice UPS guy shows
up with some SIMMs in a few days.

I expect that's all most current CS students know as well. Is that bad?
Is their education somehow lacking because they don't understand why
"memory bus" and "transmissi on line" belong in the same sentence? Not at
all. All that's happened is that very important stuff has become so
standardized that they don't have to worry about it any more and can spend
their time and energy thinking about other problems that need to be solved
today.

There are lots of really important, hard, theoretical problems that today's
CS majors need to be solving. User interfaces for the most part still
suck. Self-configuring and self-healing high speed networks on a global
scale. AI hasn't really progressed in 30 years. Computer vision and
speech. Robotics. Cryptography and security. And what about flying cars?

Just like you can't even begin to think about building today's GUI-driven
desktop applications if you're still worrying about individual logic gates,
you can't begin to think about solving some of these really hard problems
(and others we haven't even imagined) if you're still worrying about memory
buffer reference counting and garbage collection. Yesterday's research
projects are today's utilities and tomorrow's historical footnotes.

[Tom Anderson]

Re: What is different with Python ?

On Sun, 12 Jun 2005, Mike Meyer wrote:
[color=blue]
> For instance, one problem was "You have two files that have lists of 1
> billion names in them. Print out a list of the names that only occur
> in one of the files."
>
> That's a one-line shell script: "comm -12 <(sort file_one) <(sort file_two)"[/color]

Incidentally, how long does sorting two billion lines of text take?

The complementary question, of course, is "how long does it take to come
up with an algorithm for solving this problem that doesn't involve sorting
the files?"!

the best thing i can come up with off the top of my head is making a pass
over one file to build a Bloom filter [1] describing its contents, then
going over the second file, checking if each name is in the filter, and if
it is, putting it in a hashtable, then making a second pass over the first
file, checking if each name is in the hashtable. this would work without
the filter, but would require storing a billion names in the hashtable;
the idea is that using the filter allows you to cut this down to a
tractable level. that said, i'm not sure if it would work in practice - if
you have a billion names, even if you have a filter a gigabyte in size,
you still have a 2% false positive rate [2], which is 20 million names.

tom

[1] http://en.wikipedia.org/wiki/Bloom_filter
[2] http://www.cc.gatech.edu/fac/Pete.Ma...alculator.html

--
Think logical, act incremental

[Steven D'Aprano]

Re: What is different with Python ?

On Sun, 12 Jun 2005 08:11:47 -0400, Roy Smith wrote:
[color=blue]
> The point I was trying to make was that as computer science progresses,
> stuff that was really important to know a lot about becomes more and more
> taken for granted. This is how we make progress.
>
> I used to worry about memory busses at the milivolt and microsecond level.
> I knew about termination impedances and wired-OR logic, and power budgets
> and all that good stuff. Today all I know about memory is you go to
> www.crucial.com, type in your Visa card number, and the nice UPS guy shows
> up with some SIMMs in a few days.[/color]

Yes. But (to a first approximation) memory either works or it doesn't. And
we never need to worry about it scaling, because you don't get to assemble
your own SIMMs -- you buy them pre-made. Software is nothing like that.

[snip][color=blue]
> Just like you can't even begin to think about building today's
> GUI-driven desktop applications if you're still worrying about
> individual logic gates, you can't begin to think about solving some of
> these really hard problems (and others we haven't even imagined) if
> you're still worrying about memory buffer reference counting and garbage
> collection. Yesterday's research projects are today's utilities and
> tomorrow's historical footnotes.[/color]

Nice in theory, but frequently breaks down in practice. Let's take a nice,
real, Python example:

I write an text-handling application in Python. I've taken your advice,
and don't worry about messy details about the language implementation,
and concentrated on the application logic. Consequently, I've used the
idiom:

new_text = ""
for word in text:
new_text = new_text + process(word)

I test it against text containing a few thousand words, and performance is
good. Then my customers use my application in the real world, using texts
of a few hundreds of millions of words, and performance slows to a painful
crawl.

Python does a good job of insulating the developer from the implementation
details, but even in Python those details can sometimes turn around and
bite you on the behind. And your users will discover those bum-biting
situations long before your testing will.

Joel of "Joel On Software" discusses this issue here:

http://www.joelonsoftware.com/articles/fog0000000319.html

Of course, we should not prematurely optimise. But we should also be aware
of the characteristics of the libraries we call, so we can choose the
right library.

Fortunately, a high-level language like Python makes it comparatively easy
to refactor a bunch of slow string concatenations into the list-append
plus string-join idiom.


--
Steven.

[Philippe C. Martin]

Re: What is different with Python ?

Taking stuff for granted in unrelated to progress.

I agree that the "trade" of software engineering evolves and that, thanks to
hardware advances, we _usually_ can now "object orient" our software, add
billions of abstraction layers, and consume memory without a second
thought. But the trade evolves in the sense "sub"-trades are created, one
person becomes a database experts while another will html all of his/her
life (I personally find that sad). I'm being redundant here: The reason we
can use Python and take many issues for granted is because some very
skilled people handle the issues we find cumbersome.



Roy Smith wrote:
[color=blue]
> The point I was trying to make was that as computer science progresses,
> stuff that was really important to know a lot about becomes more and more
> taken for granted. This is how we make progress.[/color]

[Peter Dembinski]

Re: What is different with Python ?

Steven D'Aprano <steve@REMOVETH IScyber.com.au> writes:

[snap]
[color=blue]
> new_text = ""
> for word in text:
> new_text = new_text + process(word)[/color]

new_text = "".join(map(pro cess, text))

(I couldn't resist)

[Andrea Griffini]

Re: What is different with Python ?

On Sat, 11 Jun 2005 21:52:57 -0400, Peter Hansen <peter@engcorp. com>
wrote:
[color=blue]
>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. Those concept are not
"more complex" at all, they're just more *concrete*
than the abstract concept of "variable".
Human mind work best moving from the concrete to
the abstract, we first learn counting, and only
later we learn rings (or even set theory).
Unless you think a programmer may live happy
without understanding concrete issues then IMO
the best is to learn concrete facts first, and
only later abstractions.
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.

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.

Andrea

[Roy Smith]

Re: What is different with Python ?

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

[Mike Meyer]

Re: What is different with Python ?

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

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

[Peter Hansen]

Re: What is different with Python ?

Mike Meyer wrote:[color=blue]
> Andrea Griffini <agriff@tin.i t> writes:[color=green]
>>Also concrete->abstract shows a clear path; starting
>>in the middle and looking both up (to higher
>>abstraction s) 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(*)?[/color]

No, Andrea means you need to learn physics, starting perhaps with basic
quantum mechanics and perhaps with some chemistry thrown in (since you
can't really understand semiconductors without understanding how they're
built, right?). Oh, and manufacturing. And a fundamental understanding
of scanning electron microscopes (for inspection) would be helpful as
well. I think probably a Ph.D. level training in mathematics might be a
good start also, since after all this is the foundation of much of
computing. A while later comes the electronics, and then memory management.

Things like while loops and if statements, and *how to actually write a
program* are, of course, only the eventual outcome of all that good
grounding in "the basics" that you need first.

<big wink>

-Peter

[Peter Hansen]

Re: What is different with Python ?

Andrea Griffini wrote:[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. ...
> 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'm curious how you learned to program. What path worked for you, and
do you think it was a wrong approach, or the right one?

In my case, I started with BASIC. Good old BASIC, with no memory
management to worry about, no pointers, no "concrete" details, just FOR
loops and variables and lots of PRINT statements.

A while (some months) later I stumbled across some assembly language and
-- typing it into the computer like a monkey, with no idea what I was
dealing with -- began learning about some of the more concrete aspects
of computers.

This worked very well in my case, and I strongly doubt I would have
stayed interested in an approach that started with talk of memory
addressing, bits and bytes, registers and opcodes and such.

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

And no, I don't recall enough BASIC syntax to be sure that's even
correct, but I'm sure you get my point. In one line I learned
(implicitly at first) about variables, control structures and iteration,
output, and probably a few other things.

More importantly by far, *I made the computer do something*. This
should be everyone's first step in a programming course, and it doesn't
take the slightest understanding of what you call "concrete" things...
(though I'd call these things very concrete, and memory management
"esoteric" or something).

If I had been stuck in a course that made me learn about memory
management before I could write a program, I'm pretty sure I'd be doing
something fascinating like selling jeans in a Levis store...

-Peter

[George Sakkis]

Re: What is different with Python ?

"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.[/color]

This may sound as a rhetorical question, but in fact as an Informatics
undergrad I had to take courses in electronics, logic design, signals
and systems and other obscure courses as far CS is concerned
(http://www2.di.uoa.gr/en/lessons.php). Although these are certainly
useful if one is interested in hardware, architecture, realtime and
embedded systems, etc., I hardly find them relevant (or even more,
necessary) for most CS/IT careers. Separation of concerns works pretty
well for most practical purposes.

George

[Andrea Griffini]

Re: What is different with Python ?

On Sun, 12 Jun 2005 20:22:28 -0400, Roy Smith <roy@panix.co m> wrote:
[color=blue]
>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". Even "counting" is not the lowest
level in mathematic... there is the mathematic
philosohy direction. From "counting" you can go
"up" in the construction direction (rationals,
reals, functions, continuity and the whole
analysis area) building on the counting concept
or you can go "down" asking yourself what it
does really mean counting, what do you mean
with a "proof", what really is a "set".
However the "counting" is naturally considered
obvious for our minds and you can build the
whole life without the need to look at lower
levels and without getting bitten too badly for
that simplification.

Also lower than memory and data bus there is
of course more stuff (in our universe looks
like there is *always* more stuff no mattere
where you look :-) ), but I would say it's
more about electronic than computer science.
[color=blue]
>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).[/color]

It's magic if I'm curious but you can't answer
my questions. It's magic if I've to memorize
because I'm not *allowed* to understand.
It's not magic if I can (and naturally do) just
ignore it because I can accept it. It's not
magic if I don't have questions because it's
for me "obvious" enough.
[color=blue][color=green]
>> 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". 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]

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.

If you don't understand *why* "C" needs malloc
then you'll forget about allocating objects.

Andrea

[Andrea Griffini]

Re: What is different with Python ?

On Sun, 12 Jun 2005 19:53:29 -0500, Mike Meyer <mwm@mired.or g> 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.[/color]

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.
I do not think you can be a reasonable programmer if
you never saw assembler.
[color=blue]
>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.[/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=blue]
>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. Apparently it looks like this is a
constant in our universe. Even counting (i.e.
1, 2, 3, ...) is not the "start" of math (you
can go at "lower" levels).
Actually I think this is a "nice" property of our
universe, but discussing this would bring the
discussion a bit OT.
[color=blue]
>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).

But if you need to introduce them, then IMO is
way better doing it *first*, because that is the
way that our brain works.

You cannot build on loosely placed bricks.
[color=blue]
>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.

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

Andrea

[Claudio Grondi]

Re: What is different with Python ?

> They're things that can be IMO genuinely accept[color=blue]
> as "obvious". Even "counting" is not the lowest
> level in mathematic... there is the mathematic
> philosohy direction.[/color]
I am personally highly interested in become
aware of the very bottom, the fundaments
all our knownledge is build on.
Trying to answer questions like:
What are the most basic ideas all other
are derived from in mathematics and
programming?
keeps me busy for hours, days, years ...

Any insights you can share with
me(and/or this group)?

Claudio



"Andrea Griffini" <agriff@tin.i t> schrieb im Newsbeitrag
news:5q5qa1lotp 0fbjru7i4492llo ec251664v@4ax.c om...[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". Even "counting" is not the lowest
> level in mathematic... there is the mathematic
> philosohy direction. From "counting" you can go
> "up" in the construction direction (rationals,
> reals, functions, continuity and the whole
> analysis area) building on the counting concept
> or you can go "down" asking yourself what it
> does really mean counting, what do you mean
> with a "proof", what really is a "set".
> However the "counting" is naturally considered
> obvious for our minds and you can build the
> whole life without the need to look at lower
> levels and without getting bitten too badly for
> that simplification.
>
> Also lower than memory and data bus there is
> of course more stuff (in our universe looks
> like there is *always* more stuff no mattere
> where you look :-) ), but I would say it's
> more about electronic than computer science.
>[color=green]
> >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[/color][/color]
like[color=blue][color=green]
> >are all just magic (which you claim there is no room for).[/color]
>
> It's magic if I'm curious but you can't answer
> my questions. It's magic if I've to memorize
> because I'm not *allowed* to understand.
> It's not magic if I can (and naturally do) just
> ignore it because I can accept it. It's not
> magic if I don't have questions because it's
> for me "obvious" enough.
>[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". I suspect you[/color][/color]
would[color=blue][color=green]
> >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[/color][/color]
that[color=blue][color=green]
> >far down. I'm certainly not convinced you need to start there.[/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.
>
> If you don't understand *why* "C" needs malloc
> then you'll forget about allocating objects.
>
> Andrea[/color]

[Andrea Griffini]

Re: What is different with Python ?

On Sun, 12 Jun 2005 21:52:12 -0400, Peter Hansen <peter@engcorp. com>
wrote:
[color=blue]
>I'm curious how you learned to program.[/color]

An HP RPN calculator, later TI-57. Later Apple ][.
With Apple ][ after about one afternoon spent typing
in a basic program from a magazine I gave up with
basic and started with 6502 assembler ("call -151"
was always how I started my computer sessions).
[color=blue]
>What path worked for you, and do you think it was
>a wrong approach, or the right one?[/color]

I was a fourteen with no instructor, when home
computers in my city could be counted on the fingers
of one hand. Having an instructor I suppose would
have made me going incredibly faster. Knowing better
the english language at that time would have made
my life also a lot easier.
I think that anyway it was the right approach in
terms of "path", not the (minimal energy) approach
in terms of method. Surely a lower energy one in
the long run comparing to those that started with
basic and never looked at lower levels.
[color=blue]
>In my case, I started with BASIC. Good old BASIC, with no memory
>management to worry about, no pointers, no "concrete" details, just FOR
>loops and variables and lots of PRINT statements.[/color]

That's good as an appetizer.
[color=blue]
>A while (some months) later I stumbled across some assembly language and
>-- typing it into the computer like a monkey, with no idea what I was
>dealing with -- began learning about some of the more concrete aspects
>of computers.[/color]

That is IMO a very good starting point. Basically it
was the same I used.
[color=blue]
>This worked very well in my case, and I strongly doubt I would have
>stayed interested in an approach that started with talk of memory
>addressing, bits and bytes, registers and opcodes and such.[/color]

I think that getting interested in *programming* is
important... it's like building with LEGOs, but at a
logical level. However that is just to get interest...
and a few months with basic is IMO probably too much.
But after you've a target (making computers do what
you want) then you've to start placing solid bricks,
and that is IMO assembler. Note that I think that any
simple assembler is OK... even if you'll end up using
a different processor when working in C it will be
roughly ok. But I see a difference between those that
never (really) saw assembler and those that did.
[color=blue]
>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]

Just as a motivation. After that *FORGETTING* that
(for and the "next" you missed) is IMO perfectly ok.
[color=blue]
>More importantly by far, *I made the computer do something*.[/color]

Yes, I agree. But starting from basic and never looking
lower is quit a different idea.

Andrea