[Tutor] Learning programming

[John Kleinjans]

At 06:54 PM 4/3/99 +0100, you wrote:
>On 3 Apr 99, Ce'Nedra took her magical amulet and heard John Kleinjans say:
>
>>figured this out:
>>
>>1) get a windowing environment running
>
>Why? That's not necessary... Python for Windows is pretty good, but there
are 
>other versions around working in "console-mode".
>

I'd like to know what other versions and where I can get them, with the
constraint
that they have to run on my DOS/W311/W95 machines (yes, I actually have a 386
in my teaching lab, and a bunch of 486s with 4 Mb RAM; and 3 Pentiums with
W95).

>>2) get Python running in one window
>>3) get a text editor running in another window
>>4) with the text editor, write your program (call me "prog")
>>5) save your program to disk 
>>    a) in the Python directory
>>    b) with a ".py" extension
>>6) switch to the Python window and
>>>>> import prog
>
>In my opinion, the best way to start a Python program is still from the 
>command line, possibly specifying options and arguments for your program. So
>
>python myprog.py
>
>should do, too.
>

On my machines, Python takes 20 or 30 seconds to load, so I'm looking for an
alternative protocol. The elapsed time from Python -> editor -> Python
leads to
major attention- and memory-lapses. There has to be something faster for DOS. 
I'm thinking about running a TSR editor...

>It seems that you are used to a DOS environment. 

Actually, I'm used to DOS and Windows (and Mac, but that was long ago and
far away). In my teaching, I have to take account of what's available
(sounds like
real life again); hardware, software, OSs. licenses, curriculum guides,
state DOE
regulations, etc--and then make good things happen. DOS is OK--a lot of people
did a lot of good work with DOS for several years. And until it's dead,
it's still
alive. And it doesn't hurt for kids to learn some command-line stuff...

...but I'm getting off-track. Sorry. 

>If this is the case, then I 
>would suggest installing 4DOS which makes starting a program easier. I start 
>my program by just typing the program name, like
>
>myprog
>
>like it was an executable. Also, an editor with some macro capabilities is 
>also useful. I use vim 5.x myself, but there are lots of editors around (I 
>don't recommend vi for newbies :^). With 4DOS and the editor combined, I
edit 
>my program, save it by pressing F2, and run it by pressing F9 (or Shift-F9
if 
>I want to specify arguments first). Instant IDE for DOS or Win95 console 
>mode.

I might try that. Thanks. 

>And this is just one way to do it. Python 1.5.2 comes with a development 
>environment called IDLE, to name something. There's PythonWin...
>
>>7) at his point,
>>    a) your program might actually run
>>    b) you'll probably get some error messages
>>8) switch back to the editor window
>>9) edit the program. Try to fix it.
>>10) SAVE IT TO DISK AGAIN
>>11) switch back to Python and type
>>>>> reload(prog)
>>
>>-----
>>
>>At this point, 7 through 11 keep repeating. 
>>
>>Beginning programmers would take a very long time to figure this out.
>>They'd probably quit first. 
>
>I see your point. Although some of the points you mention (like the saving 
>and editing thing) is considered common knowledge unless you're an absolute 
>beginner, also when it comes to computers. Even my mom who just started with 
>Word knows that she should save regularly. :^)
>

My point here is that beginners frequently think "it's in the computer" and
are often
fuzzy on exactly _where_ in the computer 'it' is. In the above-mentioned
mode, _we_ 
know that Python can't just "get" the code from the editor--but newbies
don't. As we
teach, we help them build a correct model of the parts and processes. Your
mother 
(and mine, too) save frequently for a different reason, and the difference
matters. 

>>Please tell me; am I doing this the hard way? Or is this the way? 
>
>There are easier ways...
>
>>We should probably provide more detailed instructions for users of DOS,
>>Macs, even Windows. Realistically, that's what's running on most boxes out
>>there... there's a lot of kids with W95 (or even W311, or DOS) boxes who
>>would like to learn how to program. 
>
>I don't disagree, although this is a mix of 'how to start programming' and 
>'how to start with computers'. If someone doesn't know about editing and 
>saving yet and about the operating system in general, I don't know if it's 
>such a good idea to start programming already. ;^)
>

Not necessarily "how to start with computers". With C, there's a sequence
(cycle) of 
	- write source code 
	- compile
	- link
	- run & test
	- repeat
that is above and beyond 'start with computers' level. And (I'm sure)
Python has its 
processes and procedures also. That is... a programmer interacts with a
programming
environment in a different manner than a student writing a term paper
interacts with
a word processor. And we can help that student, who might be capable in the
one 
area, become capable in another, different area. 

>>I teach high school--that'll probably (assuredly) affect what I see and
>>say. That's not so bad. And I teach programming (and some other things). 
>>
>>Well, I'd like to see if this effort gets from here to there (and back
>>again) before I put more into it. 
>
>I can understand that. Python is not something that comes in a box with 
>disks/CDs and a coupla manuals to get you started. Still, working with it 
>isn't too hard, it's just a bit different from commercial environments like 
>Delphi, VB or (some years ago) Turbo Pascal. (I must admit that when I 
>started with Python, this bit me too. Heck, I even hacked the Turbo Pascal 
>editor so it accepted .py files and started them upon pressing F9...)
>
>Regardz,
>
>+  Hans Nowak  (Zephyr Falcon)

Thanks. 

John.