From bruce@eckelobjects.com  Wed Mar  1 14:59:02 2000
From: bruce@eckelobjects.com (Bruce Eckel)
Date: Wed, 01 Mar 2000 06:59:02 -0800
Subject: [Edu-sig] C++ As a First Language
In-Reply-To: <000801bf8285$3d0a2700$732d153f@tim>
References: <000801bf8285$3d0a2700$732d153f@tim>
Message-ID: <200003010659020520.0192155A@smtp.a001.sprintmail.com>

This is actually correct ISO C++; there is a special case
for main() that allows you to leave out the return
statement and it defaults to return 0. If it doesn't
compile, it means your compiler is broken.

Not defending C++ over Python in any way, however. One of
my python programs is a rewrite of the equivalent C++
version (a code extraction program for the Java book), and
it runs faster (because C++ iostreams turn out to be badly
implemented, but universally so -- Dan Saks has written a
series of articles on this in the C/C++ Users Journal). Of
course, the python version took 1/10th of the time to
develop, is 1/10th the size, does more, and is WAY easier
to modify because I don't get scared when I look at it (I
worked hard to make the C++ program nicely OOPed etc., but
it's still scary).

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D
Bruce Eckel    http://www.BruceEckel.com
Contains free electronic books: "Thinking in Java" &
"Thinking in C++ 2e"
Please subscribe to my free newsletter -- just send any
email to:
join-eckel-oo-programming@earth.lyris.net
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=3D=3D=3D=3D=3D


*********** REPLY SEPARATOR  ***********

On 2/29/00 at 2:18 AM Tim Peters wrote:

>[Jason L. Asbahr]
>> Most readers have probably seen this already, but there
is a
>> fascinating interview with Stroustrup on Slashdot, in
which
>> Bjarne asserts that, yes, indeed, C++ *is* a great first
language.
>> :-)
>>
>>
http://slashdot.org/article.pl?sid=3D00/02/25/1034222&mode
=3Dthread
>
>His paper is at:
>
>    http://www.research.att.com/~bs/new_learning.pdf
>
>It's interesting reading, but is overwhelmingly concerned
with why C++ can
>be easier to teach than C, and C is really the only other
language
>considered.  Here's his first example:
>
>int main()
>{
>    using namespace std; // gain access to standard
library
>
>    cout << "Please enter your first name:\n";
>    string name;
>    cin >> name;
>    cout << "Hello " << name << =B4\n=B4;
>}
>
>While equivalent C is truly a mess (mostly because you
can't know in advance
>how much space to allocate for "name"), it's prophetic
that this first C++
>example doesn't compile:  main is declared to return int
but lacks a return
>stmt.  My Python version compiled the first time <wink>:
>
>name =3D input("Please enter your first name:")
>print "Hello", name
>
>although-at-this-level-you-may-as-well-teach-basic-ly y'rs
 - tim
>
>
>
>_______________________________________________
>Edu-sig mailing list
>Edu-sig@python.org
>http://www.python.org/mailman/listinfo/edu-sig





From gherman@darwin.in-berlin.de  Wed Mar  1 18:48:08 2000
From: gherman@darwin.in-berlin.de (Dinu C. Gherman)
Date: Wed, 01 Mar 2000 19:48:08 +0100
Subject: [Edu-sig] Math book recommendation, creating addendums
References: <Pine.LNX.4.10.10002141703320.21126-100000@vortex.tjhsst.ed u>
 <3.0.3.32.20000214081101.00748e14@pop.teleport.com> <3.0.3.32.20000215011122.0074dc4c@pop.teleport.com>
Message-ID: <38BD65E8.D17919D2@darwin.in-berlin.de>

I've much enjoyed the math Python tutorials developed by 
Kirby Urner which made me revisit the corner of "books 
to be read when I'll finally have some time" on my own
book shelf at home where I found a truely well-illustra-
ted and heavy work of Conway and Guy:

  The Book of Numbers 
  John H. Conway, Richard K. Guy
  ISBN: 0-387-97993-X
  Publisher: Springer-Verlag New York, Inc.
 
http://shop.barnesandnoble.com/booksearch/isbnInquiry.asp?isbn=038797993X

It is reminding me much of the spirit of Kirby's Python 
tutorials, somewhere located between fun, play, explora-
tion and learning, with the only disadvantage being the 
missing Python code...

This leads me to ask how much sense you think there would 
be in asking authors of such books for whatever type of 
"cooperation" in order to create something like online 
and/or interactive "addendums" to their works? 

Jeffrey Elkner has been a pioneer in that field "conver-
ting" Allen B. Downey's book "How to Think Like a Computer 
Scientist".

Regards,

Dinu

-- 
Dinu C. Gherman
................................................................
Say no to Amazon: http://www.noamazon.com


From infonuovo@email.com  Wed Mar  1 20:20:35 2000
From: infonuovo@email.com (Dennis E. Hamilton)
Date: Wed, 1 Mar 2000 12:20:35 -0800
Subject: [Edu-sig] Python for non-programmers
Message-ID: <NDBBKEGCHLLCCFMJKMIHMELPDAAA.infonuovo@email.com>

I posted this to python-list and I was kindly requested to post it here too.
I am very interested in the objectives of CP4E.

-- Dennis

-----Original Message-----
From: python-list-admin@python.org
[mailto:python-list-admin@python.org]On Behalf Of Dennis E. Hamilton
Sent: Wednesday, March 01, 2000 08:07
To: Donn Cave; python-list@python.org
Subject: RE: Python for non-programmers


I am teaching my 35-year-old son about programming using Python.  He is a
musician and has learned to do impressive things with the DVD + CD-RW + SB
Live! on the Windows system that I set up for him.  He does his own web
pages, surfs a lot, and can get around pretty well.  He wanted to know how
to do more and learn how people do multi-media, game animation, and so on.
I figured this was a good occasion to get involved with Python for some
projects I have and as a learning laboratory for him, rather than getting
into C Language, GUI object manipulation, etc.

Yesterday, I sat next to him as he used Python and started to go through the
tutorial, me making notes on my desktop machine and him trying to figure out
things on my laptop next to it.

I learned a lot.  One thing is that the tutorial is full of things (I called
it toolcraft in a different conversation here) that are meaningless for
someone in Doug's shoes but leave him thinking that he is supposed to know
what is being discussed.  This was discouraging for him.  It was an
eye-opener for me.  I have a list of all the terms (from shell to
object-oriented) that have no context for non-programmers.  I just skip past
that stuff when I run into it.  It is in the noise for me.  He doesn't know
that.  I told him to treat it all as yack-yack-yack and just look for things
that provided examples or gave him some things to do.  That helped him get
through to section 2.1 but things got tough around section 2.1.1 where there
was no way to get through what was being talked about without more
grounding.  ("Argument," for Pete's sake!)

So, I talked him through a "hello world" exercise, after organizing a
Python/Projects folder enough so that he can see what corresponds to Python
libraries and modules.  This is without getting too technical about it.  I
want him to have enough about library organization just so he can get by for
now, with deepening after as he gets some confidence with basic operations.
He knows to make __init__.py files but not why.  I wanted him to have a
basic setup where he could begin self-guided activity and see useful results
that can also be grown to bigger projects and organized work.

He can see how to get in and out of the interpreter.  I showed him the DOS
editor and we built a "hello.py".  We ran it from the python command line
and by importing it in the "interactive mode."

I set him up with 4DOS just because it is a little easier to know where you
are and explore inside a command shell.  (I figure learning about console
mode would be an easier way to have useful work in python before dealing
with the GUI and the fledgling IDEs available for Python).

But mostly we learned things that one could also do using the MS-DOS
command.com shell.  He doesn't know what either of those are, but he knows
how to start a shell and start working with files and the python processor.
If we practice more today and tomorrow, while he is visiting me from
Portland, I figure he will be able to sustain himself when he is back home
next week, especially with me as a telephone and Instant-Messenger and
NetMeeting consultant.

He saw me use Python like a calculator, and he saw me assign strings and
calculation results to variables an reuse them.  He was fading fast (I need
to make the first steps smaller yet leave him in accomplishment), but he was
intrigued and I need to walk him through it again.

That was more than enough for a first time out.  If there were any good toy
applications that did useful things around, I could have him doing engaging
things at the console shell and python level that he could learn to analyze
and replicate later.  (I don't care if it is simply playing Hangman, or
tic-tac-toe or How Many Petals Around the Rose, something that is a complete
thing which can be used without having anything to do with building
software.)

He was tired and I was overwhelmed by how much we geeks operate on assumed
understanding and an incredible amount of unexplainable lore.  I saw that
his Windows knowledge is spotty -- there are things that he has missed so
far, such as the right-click menus and ability to make new documents and
folders.  He didn't know about the wheel on the wheel mouse to help with
scrolling.  Just the same, he has picked up ways to get around in Windows
applications and can get by (that's part of Windows usability).  He hasn't a
very coherent model and doesn't have a confident way to learn more.  Yet
Doug is the kind of guy who *does* read manuals and he does work through
tutorials, but he has, after 8 months with his own computer, mostly
developed a personal craft based on things that were discovered to work for
him.  He watches me and others with more experience and he picks up more
craft all of the time.

This has really brought me up short about what it takes to introduce
something like Python to a non-programmer (or even a programmer with a whole
different paradigm of computer use, operation, and programming).  I have to
shed all of my intuitions, developed over 40 years around these fascinating
mechanisms, and learn to see through his eyes.  That is daunting!

Doug has called the two of us the cybersmiths.  He was remarking on how, in
the past the blacksmith's kids would learn smithing from their dad by
hanging out and watching and developing a trade, absorbing the smithie's
toolcraft.   He sees himself as an apprentice cybersmith.  I like that.  Now
I am looking at what would make his experience more successful and
effective.

-- Dennis

-----Original Message-----
From: python-list-admin@python.org
[mailto:python-list-admin@python.org]On Behalf Of Donn Cave
Sent: Tuesday, February 29, 2000 21:53
To: python-list@python.org
Subject: RE: any non programmers out there?


Quoth "Cristian Echeverria" <echeverria@interactiva.cl>:
| I think a very good and basic introduction is the Python tutorial:
|
| http://www.python.org/doc/current/tut/tut.html

I started with that document and liked it a lot, too, but it's
probably a little hairy for someone who really has no background
in this area.  I mean this not as criticism of the document,
which is perfect for its normal audience, but in case someone
out there is thinking ``Man, I must be retarded, that was Greek
to me!''

	Donn Cave, donn@oz.net
--
http://www.python.org/mailman/listinfo/python-list


--
http://www.python.org/mailman/listinfo/python-list



From fstajano@uk.research.att.com  Wed Mar  1 20:37:18 2000
From: fstajano@uk.research.att.com (Frank Stajano)
Date: Wed, 01 Mar 2000 20:37:18 +0000
Subject: [Edu-sig] Python for non-programmers
In-Reply-To: <NDBBKEGCHLLCCFMJKMIHMELPDAAA.infonuovo@email.com>
Message-ID: <4.2.2.20000301203500.00bf1f00@localhost>

At 2000-03-01 12:20 -0800, Dennis E. Hamilton wrote:
>I posted this to python-list and I was kindly requested to post it here too.
>I am very interested in the objectives of CP4E.

This message was f***ing brilliant. Dennis, thanks for sharing this with 
us. That's the sort of thing that CP4E needs -- trying things out on real 
human beings (as opposed to programmers and geeks). No matter how much we 
think we know what "they" need, and no matter how helpful we are determined 
to be, we can't overcome our own biases unless someone innocently points 
them out to us.

  Frank (http://i.am/filologo.disneyano/)  http://www.uk.research.att.com/~fms/



From siegel@eico.com  Wed Mar  1 21:29:02 2000
From: siegel@eico.com (Arthur Siegel)
Date: Wed, 1 Mar 2000 16:29:02 -0500
Subject: [Edu-sig] Python for non-programmers
Message-ID: <NDBBIAEANKEFIFOFMJHPIEPPCAAA.siegel@eico.com>

Dennis E. Hamilton, wrote -
> If there were any good toy
> applications that did useful things around, I could have him doing
engaging
> things at the console shell and python level that he could learn to
analyze
> and replicate later.  (I don't care if it is simply playing Hangman, or
> tic-tac-toe or How Many Petals Around the Rose, something that is a
complete
> thing which can be used without having anything to do with building
> software.)


I like to think the PyGeo app I wrote
http://starship.python.net/crew/kernr/PyGeo/ fits well into this category.
You're writing actual Python code and getting immediate feedback as 3D
graphics.

So far I am a chorus of one who sees it as on point to what EDU-SIG is
about.

But as the guy who spent a good number of hours getting it to the point
where I thought it
was presentable, its hard to be objective.

I'll take any feedback at this point - good, bad, or indifferent.




From pdx4d@teleport.com  Thu Mar  2 01:13:45 2000
From: pdx4d@teleport.com (Kirby Urner)
Date: Wed, 01 Mar 2000 17:13:45 -0800
Subject: [Edu-sig] Python for non-programmers
In-Reply-To: <NDBBIAEANKEFIFOFMJHPIEPPCAAA.siegel@eico.com>
Message-ID: <3.0.3.32.20000301171345.03979dc8@pop.teleport.com>

>I like to think the PyGeo app I wrote
>http://starship.python.net/crew/kernr/PyGeo/ fits well into this category.
>You're writing actual Python code and getting immediate feedback as 3D
>graphics.

Hi Arthur --

I'd say "yes and no" regarding "is actual Python code".

Here's an excerpt from one of your modules, which you shared
as illustrative of what a student is supposed to write:

  A=FreePosition(-24.0,-12.,1.0,name='A',color=RED)
  C=FreePosition(31,-7.0,-12.0,name='C',color=RED)
  AC=Line(A,C,name='AC',color=RED)
  B=LineSlider(AC,(-7.,-14.0,-6.0),name='B',color=ORANGE)
  Cp=FreePosition(11.0,7.0,7.0,name="C'",color=RED)
  Ap=FreePosition(-16.5,-3.5,16.,name="A'",color=RED)
  ApCp=Line(Ap,Cp,name="A'C'",color=RED)
  Bp=LineSlider(ApCp,(30.0,13.0,2.0),name="B'",color=ORANGE)
  pmap=PointMap(AC,ApCp,B,Bp,density=60,color=ORANGE,name='pmap')
  p1=FreePosition(-30.0,-25.,-17,name='p1',color=GREEN)
  p2=FreePosition(31,-17.0,9.0,name='p2',color=GREEN)
  p3=FreePosition(17,-11.0,-14.0,name='p3',color=GREEN)
  ccirc=CircumCircle(p1,p2,p3,style=FILL,precision=100)
  tri=Triangle(A,C,Ap)

Certainly this is executable directly in Python, but there's
a layer between the Python language and getting results on
the screen, which is this vocabulary of geometric functions
and their properties which you've devised.

I'm not saying this is bad and/or avoidable, or that I've 
got a better way, merely that we should not bleep over the 
truth about the learning curve and make it sound like just 
knowing Python is all it would take to operate your program, 
or, conversely, that learning your program is 100% synonymous 
with the process of learning Python.  

I know Python, and yet when I look at the lines above, I 
feel someone overwhelmed, intimidated, because I have
no idea how big this vocabulary is, how much memorization
of new functions and their parameters I'm likely to 
face.  Where can I go to find out?

I think what your program needs most is on-line documentation
(on the web).  Plus a tutorial.  That's a lot of work of 
course.  But "getting something to work" is not the same
as "getting something others find usable".

I'm certainly curious about your project, as I've communicated
by private emails as well.  For example, re the above lines,
I'm wondering if:

  tri=Triangle(A,C,Ap)

refers to a class named Triangle, i.e. is tri an instantiation
of the Triangle class, with A,C and Ap passed to some __init__
constructor "behind the scenes".  It'd be cool to go to some
website and find all these "secrets" discussed -- the deeper
you get into it, the more I feel like your goal is to teach 
my Python (and I look up to you as something of a Python guru,
working at a level beyond the one I've managed to attain).

>So far I am a chorus of one who sees it as on point to what EDU-SIG is
>about.

I think your work is very much relevant to what this EDU-SIG is
about.  However, for the purposes of discussion, I think we need
to draw a distinction between:

   (a) applications written in Python that are useful to 
       students in various subject areas

   (b) applications written in Python that have "teaching
       Python" as a primary goal

   (c) non-applications (e.g. modules that run in IDLE but
       do not provide a custom GUI) that are useful to 
       students in various subject areas

   (d) non-applications that have "teaching Python" as a 
       primary goal

I realize that many projects fall somewhere in between vis-a-vis
the above categories.  Do you think it fair to say yours falls 
between (a) and (b)?  I think my approach falls between (c) 
and (d).

All chatter about your extremely interesting application aside,
I think the difference between "using Python to do X" and "doing
X to teach Python" really needs to remain front and center in
this SIG.  

It's easy to confuse the two approaches, and think that just 
because one has written this dynamite application, useful in 
schools, and done 100% in Python, that it's therefore a good 
tool for advancing the goals of CP4E.  

Maybe yes, maybe no, is what I'd say -- there's no necessary
correlation here.  

Getting back to your application, I'm thinking probably yes -- 
I think students could probably learn a great deal about 
Python by dissecting what you've done -- maybe even more 
than they'd learn about geometry.

>I'll take any feedback at this point - good, bad, or indifferent.
>

My two cents.

Kirby



From pdx4d@teleport.com  Thu Mar  2 01:26:22 2000
From: pdx4d@teleport.com (Kirby Urner)
Date: Wed, 01 Mar 2000 17:26:22 -0800
Subject: [Edu-sig] Python for non-programmers
In-Reply-To: <NDBBKEGCHLLCCFMJKMIHMELPDAAA.infonuovo@email.com>
Message-ID: <3.0.3.32.20000301172622.0397f410@pop.teleport.com>

>I am teaching my 35-year-old son about programming using Python.  He is a
>musician and has learned to do impressive things with the DVD + CD-RW + SB
>Live! on the Windows system that I set up for him.  He does his own web

<<SNIP>>

Question:  when you talk about the tutorial, I presume you mean
the one that's included with Python.  I would highly recommend 
investing in 'Learning Python' in addition.  That's really a very
good book, and it _doesn't_ get into technical stuff too fast or
too quickly.

>He knows to make __init__.py files but not why.  I wanted him to have a

Yeah, really, why start here?  You don't need __init__.py files
to learn Python.

<<SNIP>>

>I set him up with 4DOS just because it is a little easier to know where you
>are and explore inside a command shell.  (I figure learning about console
>mode would be an easier way to have useful work in python before dealing
>with the GUI and the fledgling IDEs available for Python).

This seems completely and totally ass-backwards to me.  Why on
earth would you boot an X-Term window (aka DOS or 4DOS) and learn
Python in that clunky, unfriendly environment.  Especially when
your student is already Windows user, accustomed to that interface,
and does DVD + CD-RW.  Must seem like a real big step back into
the dark ages.

I'd say an IDE that color codes program key words as you type 
them is a _minimum requirement_ for any student getting into
programming, in ANY language.  IDLE 0.5 is not all that 
"fledgling" either.  Compared to a DOS prompt, it's lightyears 
ahead and beyond, in terms of ease of use. 

Your attitude seems to be:  "before we use Word to learn word-
processing, let me show you how we type on this manual typewriter 
from the late 1940s (remember, you have to hit the keys _real hard_ 
-- and the ribbon might jam from time to time)."

>But mostly we learned things that one could also do using the MS-DOS
>command.com shell.  He doesn't know what either of those are, but he knows

Ugh!  Who cares???

<<SNIP>>

>He was tired and I was overwhelmed by how much we geeks operate on assumed
>understanding and an incredible amount of unexplainable lore.  I saw that

Yeah, really.

>his Windows knowledge is spotty -- there are things that he has missed so
>far, such as the right-click menus and ability to make new documents and
>folders.  He didn't know about the wheel on the wheel mouse to help with
>scrolling.  Just the same, he has picked up ways to get around in Windows

No big deal.  I threw away my wheel mouse when it proved too glitchy
(yeah, a cheapo).  Back to the track ball for now.

>This has really brought me up short about what it takes to introduce
>something like Python to a non-programmer (or even a programmer with a whole
>different paradigm of computer use, operation, and programming).  I have to
>shed all of my intuitions, developed over 40 years around these fascinating
>mechanisms, and learn to see through his eyes.  That is daunting!

Shed the intuition that you need to go to a DOS window, is my 
advice.

>I am looking at what would make his experience more successful and
>effective.

IDLE.  GUI.  No DOS (or 4DOS, or CP/M either).

Kirby




From jelkner@umd5.umd.edu  Thu Mar  2 02:13:53 2000
From: jelkner@umd5.umd.edu (Jeffrey Elkner)
Date: Wed, 1 Mar 2000 21:13:53 -0500
Subject: [Edu-sig] Python for non-programmers
In-Reply-To: <3.0.3.32.20000301172622.0397f410@pop.teleport.com>
References: <3.0.3.32.20000301172622.0397f410@pop.teleport.com>
Message-ID: <00030121242105.00703@robeson.elkner.net>

I don't mean to be contrary, Kirby, but I was actually disappointed with
"Learning Python" in the sense that it still does make a lot of assumptions
about the background of its readers.  There are frequent references to other
programming languages throughout (offered as comparison with Python) and I
found the text to still be very intimidating for beginners in much the same way
that Dennis talks about the on-line docs.  There really is no good beginners
book using Python yet, but of the existing books the one I like best is "The
Quick Python Book" by Kenneth McDonald and Daryl Harms.  While it is certainly
not perfect, I found this to be the clearest and easiest to read of the
books that are out there.

jeff elkner

On Wed, 01 Mar 2000, Kirby wrote (in reply to Dennis ;-):
> >I am teaching my 35-year-old son about programming using Python.  He is a
> >musician and has learned to do impressive things with the DVD + CD-RW + SB
> >Live! on the Windows system that I set up for him.  He does his own web
> 
> <<SNIP>>
> 
> Question:  when you talk about the tutorial, I presume you mean
> the one that's included with Python.  I would highly recommend 
> investing in 'Learning Python' in addition.  That's really a very
> good book, and it _doesn't_ get into technical stuff too fast or
> too quickly.


From ajs@ix.netcom.com  Thu Mar  2 02:30:51 2000
From: ajs@ix.netcom.com (Arthur Siegel)
Date: Wed, 1 Mar 2000 21:30:51 -0500
Subject: [Edu-sig] Python for non-programmers
References: <3.0.3.32.20000301171345.03979dc8@pop.teleport.com>
Message-ID: <001b01bf83ef$55657c80$6fe36dd1@eiconyc>

Kirby writes  -

> Certainly this is executable directly in Python, but there's
> a layer between the Python language and getting results on
> the screen, which is this vocabulary of geometric functions
> and their properties which you've devised.

But isn't this only a matter of degree -  and is true any time
one works with an imported module.  I am being a little cute in PyGeo
by hiding the module import behind the IDE.

So, yes there is imported code adding to the functionality of the top level
script. But I would argue
this is orthodox Python.

The script itself is being parsed directly by Python and any syntactical
error
will generate a standard Python error message.

> I think what your program needs most is on-line documentation
> (on the web).  Plus a tutorial.  That's a lot of work of
> course.  But "getting something to work" is not the same
> as "getting something others find usable".

There is a good deal of html documentation done and in the download. Some of
it
gets a little beyond basic geometry - because I actual do use the
application
as a tool to help myself visualize geometric concepts. But for younger
students
you could limit yourself to a few basic elements and go a long way.

But yes it is work to document, which is probably one of  the main reasons
I'm pushing a bit to get a gauge of interest.

>   tri=Triangle(A,C,Ap)
>
> refers to a class named Triangle, i.e. is tri an instantiation
> of the Triangle class, with A,C and Ap passed to some __init__
> constructor "behind the scenes".

 That's all thats going on . And OpenGL draws it. Nothing up the sleeve.

> I realize that many projects fall somewhere in between vis-a-vis
> the above categories.  Do you think it fair to say yours falls
> between (a) and (b)?  I think my approach falls between (c)
> and (d).
>

Yes. On the other hand, I see a lot of similarities in our approach to
things.

The truth is that I went as far as I did in developing an application
because I got mesmerized
with what I could get done with Python.

I am an old dog learning new tricks.

I don't participate in the discussions about whether Python is the best
language with which to
teach OOP, because I take that as a given. And I base that on my own
experience. Whatever I understand
about OOP I learned from Python - and that after a few false starts with
other approaches.

And yes, I can now apply that understanding in a general way.

>It's easy to confuse the two approaches, and think that just
>because one has written this dynamite application, useful in
>schools, and done 100% in Python, that it's therefore a good
>tool for advancing the goals of CP4E.

> Maybe yes, maybe no, is what I'd say -- there's no necessary
> correlation here.

Agreed.

Nonetheless, I could say a lot to defend PyGeo as relevant to CP4E -  but
will spare
the EDU-SIG, at least for now.

> My two cents.
> Kirby

For which I thank you.

> _______________________________________________
> Edu-sig mailing list
> Edu-sig@python.org
> http://www.python.org/mailman/listinfo/edu-sig



From pdx4d@teleport.com  Thu Mar  2 04:14:14 2000
From: pdx4d@teleport.com (Kirby Urner)
Date: Wed, 01 Mar 2000 20:14:14 -0800
Subject: [Edu-sig] Python for non-programmers
In-Reply-To: <00030121242105.00703@robeson.elkner.net>
References: <3.0.3.32.20000301172622.0397f410@pop.teleport.com>
 <3.0.3.32.20000301172622.0397f410@pop.teleport.com>
Message-ID: <3.0.3.32.20000301201414.006ef1d8@pop.teleport.com>

At 09:13 PM 03/01/2000 -0500, you wrote:
>I don't mean to be contrary, Kirby, but I was actually disappointed with
>"Learning Python" in the sense that it still does make a lot of assumptions
>about the background of its readers. 

jeff --

I don't dispute your point.  I think the market is still 
wide open for really good Python tutorials -- in many
shapes and forms.  But I think 'Learning Python' is a
step in the right direction -- from the tutorial which
comes with Python (more geared towards programmers new
to Python, but not programming).  I would still recommend 
it, given it's available, and not over-priced.

Kirby




From infonuovo@email.com  Thu Mar  2 04:28:58 2000
From: infonuovo@email.com (Dennis E. Hamilton)
Date: Wed, 1 Mar 2000 20:28:58 -0800
Subject: [Edu-sig] Python for non-programmers
In-Reply-To: <3.0.3.32.20000301172622.0397f410@pop.teleport.com>
Message-ID: <NDBBKEGCHLLCCFMJKMIHGENADAAA.infonuovo@email.com>

1. Yes, I did mean the tutorial that comes with Python.

2. I bought "Learning Python" for both of us.  He started looking in it last
night and he didn't find it much more helpful at this point.  Today I was
referred to Magnus Lie Hetland's "Instant Hacking" and "Instant Python"
articles and they look like much more what I am looking for, and Doug finds
them accessible too.

3. I said why I wanted him to know to put __init__.py in directories from
the beginning, as a start towards developing libraries of modules as he
begins to organize the work that he does.  Knowing the environment of Python
for a platform seems important in achieving usability.  I am giving him a
minimum that he should be able to grow from without getting into paths,
environment variables, and such so soon.  That's why.  We'll see how well it
works out.

4. My assessment with Idle and PythonWin so far is that they are both too
easy to crash and there is too much that is inscrutable.  (I haven't
installed Idle 0.5 yet.)  More than that, I want Doug to have some short
path of connection between what he sees in the material he creates and what
happens operationally.  I agree that having an IDE environment is an
improvement, once you have a sound model of the fundamental process that is
not obscured by the tool.

5.   I don't expect this will hurt him any, and it will teach him
command-line use of the python processor, something that gets talked about
in all of the books.  He can move to an IDE when he has the basic
operational process under his belt.  I think he will adjust his own
practices to suit himself once he has enough sense of what is happening.  I
have no charge on whether he continues to run under 4DOS or do something
else.  I think he'll keep his wheel mouse though.

-- Dennis

-----Original Message-----
From: edu-sig-admin@python.org [mailto:edu-sig-admin@python.org]On
Behalf Of Kirby Urner
Sent: Wednesday, March 01, 2000 17:26
To: edu-sig@python.org; edu-sig@python.org
Subject: Re: [Edu-sig] Python for non-programmers

<<1-3>

Question:  when you talk about the tutorial, I presume you mean
the one that's included with Python.  I would highly recommend
investing in 'Learning Python' in addition.  That's really a very
good book, and it _doesn't_ get into technical stuff too fast or
too quickly.

>He knows to make __init__.py files but not why.  I wanted him to have a

Yeah, really, why start here?  You don't need __init__.py files
to learn Python.

</1-3>>

  [ ... ]

<<4>

>I set him up with 4DOS just because it is a little easier to know where you
>are and explore inside a command shell.  (I figure learning about console
>mode would be an easier way to have useful work in python before dealing
>with the GUI and the fledgling IDEs available for Python).

This seems completely and totally ass-backwards to me.  Why on
earth would you boot an X-Term window (aka DOS or 4DOS) and learn
Python in that clunky, unfriendly environment.  Especially when
your student is already Windows user, accustomed to that interface,
and does DVD + CD-RW.  Must seem like a real big step back into
the dark ages.

I'd say an IDE that color codes program key words as you type
them is a _minimum requirement_ for any student getting into
programming, in ANY language.  IDLE 0.5 is not all that
"fledgling" either.  Compared to a DOS prompt, it's lightyears
ahead and beyond, in terms of ease of use.

</4>>

 [ ... ]

<<5>

Shed the intuition that you need to go to a DOS window, is my
advice.

>I am looking at what would make his experience more successful and
>effective.

IDLE.  GUI.  No DOS (or 4DOS, or CP/M either).

</5>>

Kirby





From infonuovo@email.com  Thu Mar  2 04:29:21 2000
From: infonuovo@email.com (Dennis E. Hamilton)
Date: Wed, 1 Mar 2000 20:29:21 -0800
Subject: [Edu-sig] Python for non-programmers
In-Reply-To: <NDBBIAEANKEFIFOFMJHPIEPPCAAA.siegel@eico.com>
Message-ID: <NDBBKEGCHLLCCFMJKMIHKENADAAA.infonuovo@email.com>

I found this interesting in terms of what might be possible for a graphic
manipulation system.

It is a big reach from what I meant by toy applications, because of the need
to understand a lot of analytical geometry to express things.  Also, I
wouldn't want to modify the IDE.  I'm concerned that could get in the way.

Learning how pyGeo works and is built by taking it apart seems like a big
thing too.

I downloaded the thin distribution to see if I could get a better sense of
it from your code.  I haven't looked at it yet.

I think geometry work might be very interesting at some point.  Have you
considered introducing it along with objects for geometric representation,
sort of how it showed up in the early Smalltalk work?  Something like

	p1 = mkPoint(0.0, 7.3)
	p2 = mkPoint(-3.7, 1.5)
	p3 = mkPoint(2.4, -12.7)
	s1 = mkPlain(p1, p2, p3)
	s2 = ...
	linex = mkIntersection(s1, s2)
	linex.draw(parameters)

like that?  Or little turtle stuff?

Thanks for showing me this.  It is something to think about.

-- Dennis

-----Original Message-----
From: Arthur Siegel [mailto:siegel@eico.com]
Sent: Wednesday, March 01, 2000 13:29
To: infonuovo@email.com; CP4E Edu-Sig
Subject: Re: [Edu-sig] Python for non-programmers


Dennis E. Hamilton, wrote -
> If there were any good toy
> applications that did useful things around, I could have him doing
engaging
> things at the console shell and python level that he could learn to
analyze
> and replicate later.  (I don't care if it is simply playing Hangman, or
> tic-tac-toe or How Many Petals Around the Rose, something that is a
complete
> thing which can be used without having anything to do with building
> software.)


I like to think the PyGeo app I wrote
http://starship.python.net/crew/kernr/PyGeo/ fits well into this category.
You're writing actual Python code and getting immediate feedback as 3D
graphics.

So far I am a chorus of one who sees it as on point to what EDU-SIG is
about.

But as the guy who spent a good number of hours getting it to the point
where I thought it
was presentable, its hard to be objective.

I'll take any feedback at this point - good, bad, or indifferent.





From pdx4d@teleport.com  Thu Mar  2 04:50:44 2000
From: pdx4d@teleport.com (Kirby Urner)
Date: Wed, 01 Mar 2000 20:50:44 -0800
Subject: [Edu-sig] Python for non-programmers
In-Reply-To: <001b01bf83ef$55657c80$6fe36dd1@eiconyc>
References: <3.0.3.32.20000301171345.03979dc8@pop.teleport.com>
Message-ID: <3.0.3.32.20000301205044.006ecf8c@pop.teleport.com>

>The script itself is being parsed directly by Python and 
>any syntactical error will generate a standard Python 
>error message.

As soon as you say "parsed directly by Python" it sounds like 
you're writing in another language.  

I mean, we _could_ say that Python is a clever way of squeezing 
a lot of utility out of ANSI C, given that's what it's written 
in (not C++, as I mistakenly claimed in an earlier post).
But then C is a clever way of sqeezing utility out of 
assembler or machine language.  Ultimately, we're all in the
business of controlling chips (which control us back -- a 
feedback loop, via what I call the "cell-silicon" interface 
(keyboards, monitors and like that)).

Seriously though, your scripting language doesn't look all 
that Python-like to my eyes.  Every statement is an assignment 
(in the example given anyway).  No indents, no key words
I recognize as Python's, right off the bat.

>There is a good deal of html documentation done and in the download. 

OK, that's encouraging.  My habit is to read documentation
first, to get a flavor of what's involved, _before_ I do
any installation of a runtime setup.  I want to know what
I'm getting in to.  Given my habits, I of course find it 
most convenient if the documentation isn't bundled with all
the rest of it.

Like, before I got around to downloading the Java SDK for
the first time, I poked around at the Sun website and looked
at the tutorials and examples.  I decided Java looked learnable
on that basis.  But other websites I've poked around in have
prompted a different response:  learning curve too steep, 
too much to learn right now, no gradual on-ramp available
(or no affordable price tag -- not Python's problem).

I think a lot of us go through a similar assessment process:
we try to figure out if this is something we can master 
_in principle_, based on what learning materials we see 
are already out there.  Given all the hard work going into 
making Java intelligible, even to beginners, I was encouraged 
to start learning it.  Same with Python.

Actually, I'm pretty sure it was positive remarks by 
Bruce Eckel (recent poster), in one of his newsletters,
that finally prompted me to take a serious look at 
Python.  I'd read Bruce's 'Thinking in Java' and found 
it to be an exceedingly clear presentation (as have many 
others).  "If Bruce likes thinking in Python, I bet I 
would too," is what I was probably thinking (before 
that, I had only the haziest of ideas about Python -- 
sounded way more arcane than it is).

> That's all thats going on . And OpenGL draws it. Nothing up the sleeve.
>

That's interesting.  As a student myself, what I'd be looking
for is a tutorial on how to make Python talk to OpenGL.  I know
you have an add-on module for that.  I'm not clear what resources 
are already out there.  Probably you had to learn this stuff 
from the work of others.  So if you had a website with a lot 
of on-line documentation, you'd have a pointer to the OpenGL 
piece and say "for more background on this topic, click here" 
or something like that.

That's what I love about the web:  you can send your readers
to where they need to go in order to continue with your thread
(after some detours, however long), if that's their true intent
(some follow your tangents and never return -- such is life).  
So much more convenient than sitting in a library, where such 
"see such-and-such" directives mean getting out of my seat, 
taking the elevator, checking the card catalog, taking the 
elevator again -- and finding the book missing from the shelf.
I used to dream we'd have hypertext someday.  Now we do.  Yay.

I guess what's confusing me about your syntax, right off the
bat, is every statement seems to be an assignment.  You're
returning objects and then using these objects as parameters
fed to other objects.  I find myself thinking:  "What if 
I just want to define an object but not have it draw anywhere?"  
Like, I'm not used to having "assignment" (tri = Triangle(a,b,...)) 
so directly associated with the verb "to draw".  In other 
words, what seems alien about your syntax is I don't see 
things like:

 tri = Triange(a,b,..) # returning object, initialize w/ params
 tri.color = "Blue"    # setting a property (needn't be a param)
 tri.draw()            # invoking a method

To have an "=" statement actually "do" something (other than
assign an object's handle to a variable) seems kinda quirky
to me -- as a general proposition, nothing to do with Python
per se.  Is 'learning to think in PyGeo' going to help me
learn to think in Python?  Is the style the same?  I don't
know yet.  Just curious.

>
>Yes. On the other hand, I see a lot of similarities in our approach to
>things.

Indeed.  The focus on geometry for starters.

>I am an old dog learning new tricks.
>

Ditto.  We old dogs aren't so stupid as the old saying suggests.

>I don't participate in the discussions about whether Python is the 
>best language with which to teach OOP, because I take that as a 
>given. And I base that on my own experience. Whatever I understand
>about OOP I learned from Python - and that after a few false 
>starts with other approaches.

I agree that this is something of a premise from the standpoint
of this SIG.  We're here because we're committed to seeing 
Python used as a teaching language (not to the exclusion of
all others, but used nevertheless).  The debates rage on, but 
"which language?" is not really a relevant thread in this
context.

>Nonetheless, I could say a lot to defend PyGeo as relevant 
>to CP4E -  but will spare the EDU-SIG, at least for now.
>

I don't think you need to defend the relevance of your program 
-- at least in my eyes it's highly relevant.  I take that 
as a given.

Kirby



From pdx4d@teleport.com  Thu Mar  2 05:11:26 2000
From: pdx4d@teleport.com (Kirby Urner)
Date: Wed, 01 Mar 2000 21:11:26 -0800
Subject: [Edu-sig] Python for non-programmers
In-Reply-To: <NDBBKEGCHLLCCFMJKMIHGENADAAA.infonuovo@email.com>
References: <3.0.3.32.20000301172622.0397f410@pop.teleport.com>
Message-ID: <3.0.3.32.20000301211126.006f6ef4@pop.teleport.com>

>3. I said why I wanted him to know to put __init__.py in directories from
>the beginning, as a start towards developing libraries of modules as he

OK, but it's easy to just save your .py modules in the Python 
directory and move them later, adding to the search path then.  

You can do modules first, __init__.py later.  That would 
probably be my approach -- to avoid getting bogged down in
environmental nitty gritties.

>4. My assessment with Idle and PythonWin so far is that they are both too
>easy to crash and there is too much that is inscrutable.  (I haven't
>installed Idle 0.5 yet.)  More than that, I want Doug to have some short
>path of connection between what he sees in the material he creates and what
>happens operationally.  I agree that having an IDE environment is an
>improvement, once you have a sound model of the fundamental process that is
>not obscured by the tool.

This is where we disagree I guess.  I haven't found IDLE especially
crash-prone in Windows (I've used PythonWin too, but have decided 
to just use IDLE 0.5 for now).  

Sometimes, rarely, I have to ctrl-alt-delete terminate (just the 
thread, not a reboot) because I've got an infinite loop going (or, 
more likely, I'm stuck trying to compute primes up to some godawfully 
humongous number -- what I got into with Pascal's Pyramid the 
other day).

IDLE is not an IDE in the sense of "edit code, then compile/link, 
then execute" like Visual Cafe for Java or something.  It's a true 
REPL loop, a command line interpreter, exactly like what you get 
in DOS, except color coded, friendly, in a window.  The computer 
replies in blue.

>5.   I don't expect this will hurt him any, and it will teach him
>command-line use of the python processor, something that gets talked about
>in all of the books.  He can move to an IDE when he has the basic

Yes, but IDLE _is_ in interactive command line environment.  

I agree that an interactive command line should be front and 
center in the learning process.  All my prime teaching language 
candidates, Logo, Python, DrScheme, Xbase... -- have interactive 
command lines, where you can type 2+2 and get 4, or 3*"CAT" and 
get "CATCATCAT".

But the command lines I'm talking about are in the context of a
GUI.  I find that an improvement over opening a DOS or X-term
window in Windows or Linux/Unix.

>operational process under his belt.  I think he will adjust his own
>practices to suit himself once he has enough sense of what is happening.  I
>have no charge on whether he continues to run under 4DOS or do something
>else.  I think he'll keep his wheel mouse though.

You probably have a good sense of the situation in your particular 
case.  I just want to avoid the paradigm where we think "computer 
programming for everybody" means indoctrinating everyone into 
the arcana of some hopelessly geekish world.  On the contrary,
software engineers have worked very hard to transcend that world,
by devising interfaces that seem more humane.  I see no reason to
turn back the clock.

It's an ancient pitfall in the teaching process that some previous 
generation is more interested in having downliners (future 
generations) appreciate "what it was like for us in our time" 
than recognizing and responding to what's ahead:  a future that's 
alien to all of us, but is ours to own and anticipate nevertheless.

Kirby




From tim_one@email.msn.com  Thu Mar  2 05:09:35 2000
From: tim_one@email.msn.com (Tim Peters)
Date: Thu, 2 Mar 2000 00:09:35 -0500
Subject: [Edu-sig] C++ As a First Language
In-Reply-To: <200003010659020520.0192155A@smtp.a001.sprintmail.com>
Message-ID: <001101bf8405$80b7df20$732d153f@tim>

[Bruce Eckel, commenting on Stroustrup's "int main() { ... }" without
 a return, that blew up under Tim's compiler for that reason]

> This is actually correct ISO C++; there is a special case
> for main() that allows you to leave out the return
> statement and it defaults to return 0. If it doesn't
> compile, it means your compiler is broken.

Yet another killer argument in favor of C++ as a first language.  Or,
really, two:  compilers implement different languages, and a function named
"main" follows different rules because ... umm ... well ... because its name
is "main" <wink>.

> Not defending C++ over Python in any way, however.

I use both languages daily, and have for years -- there's *plenty* to be
said in favor of C++.  As a first language, though -- brrrrrr.

gotta-say-though-that-stroustrup-convinced-me-it-*can*-be-a-
    better-first-language-than-c-ly y'rs  - tim




From DavidA@ActiveState.com  Thu Mar  2 05:21:24 2000
From: DavidA@ActiveState.com (David Ascher)
Date: Wed, 1 Mar 2000 21:21:24 -0800
Subject: [Edu-sig] RE: Learning Python
In-Reply-To: <20000302042403.0F52D1CED4@dinsdale.python.org>
Message-ID: <NDBBJPNCJLKKIOBLDOMJMECHCBAA.DavidA@ActiveState.com>

> From: Jeffrey Elkner <jelkner@umd5.umd.edu>
>
> I don't mean to be contrary, Kirby, but I was actually disappointed with
> "Learning Python" in the sense that it still does make a lot of
> assumptions about the background of its readers.  There are frequent
> references to other  programming languages throughout (offered as
comparison with
> Python) and I found the text to still be very intimidating for beginners
in
> much the same way that Dennis talks about the on-line docs.

Indeed.  I think we mention that in the introduction.  _Learning Python_ was
not intended to be a book used to teach programming, but one intended to
teach programming in Python, assuming that some general programming concepts
are known.  While I do hear occasional reports from some motivated and
bright readers who claim to be learning how to program from LP, it's not its
intent.

I would love to do a true introduction to programming with Python, but I
refuse to do so until I spend a few semesters teaching it to true novices.
I've been programming since I was 13 or 14, and I'm just too far removed
from the experience to be a good teacher at that level.

I was lucky enough to be a student of Andy van Dam, who, besides his
reputation as being a founder of computer graphics, was the most dedicated,
thoughtful and intent teacher of computer science I ever had the pleasure to
listen to and work for.  Andy truly puts tremendous effort into perfecting
his courses.  Now I wish I'd taken notes on his pedagogical technique, not
linked lists!

Cheers,

--david ascher




From gerrit@nl.linux.org  Thu Mar  2 07:17:16 2000
From: gerrit@nl.linux.org (Gerrit Holl)
Date: Thu, 2 Mar 2000 08:17:16 +0100
Subject: [Edu-sig] RE: Learning Python
In-Reply-To: <NDBBJPNCJLKKIOBLDOMJMECHCBAA.DavidA@ActiveState.com>; from DavidA@ActiveState.com on Wed, Mar 01, 2000 at 09:21:24PM -0800
References: <20000302042403.0F52D1CED4@dinsdale.python.org> <NDBBJPNCJLKKIOBLDOMJMECHCBAA.DavidA@ActiveState.com>
Message-ID: <20000302081716.A7088@nl.linux.org>

<quote name="David Ascher" date="951942084" email="DavidA@ActiveState.com">
>
> Indeed.  I think we mention that in the introduction.  _Learning Python_ was
> not intended to be a book used to teach programming, but one intended to
> teach programming in Python, assuming that some general programming concepts
> are known.  While I do hear occasional reports from some motivated and
> bright readers who claim to be learning how to program from LP, it's not its
> intent.
> 
> I would love to do a true introduction to programming with Python, but I
> refuse to do so until I spend a few semesters teaching it to true novices.
> I've been programming since I was 13 or 14, and I'm just too far removed
> from the experience to be a good teacher at that level.

</quote>

Maybe it helps if I tell how I learned programming (I'm 14).

Some years ago, when I was 9 or 10, I got a book as christmas present,
called "Programmeren voor kinderen met Superlogo voor Windows" (programming
for kids with Superlogo for Windows). This book, written by Addo Stuur,
tried to teach the programming basics, but I think it fails. It was not
too hard, no certainly not! Telling how to click on an icon and how to
change 'voruit' to 'vooruit, it seemed to not even assume a basic computer
knowledge. It started with instructions on how to move the turtle, which
already was during half the book! It explained something on procedures
afterwards. But the main problem with that book was that it doesn't
teach programming - it teaches an extremely basic language where all
programs need to be run from the IDE and without any libary/packaging
system. This stopped me from wanting to learn programming - actually,
I didn't even realize I _was_ programming!

We must certainly not copy Addo's fault.

A few years later, I discovered Linux, the shell, started using Perl
but couldn't understand a single bit, started reading "Programming Python"
(my father, an experienced programming and Unix guru, bought it),
(Learning Python wasn't there yet) but found it very difficult too;
after half a year, I did understand Programming Python but did not
understand OO yet; I bought Learning Python and got the concept of classes.

regards,
Gerrit.

-- 
Plis korekt eni ingglisj joe encounter in mai imeel meeasj!
-----BEGIN GEEK CODE BLOCK----- http://www.geekcode.com
Version: 3.12
GCS dpu s-:-- a14 C++++>$ UL++ P--- L+++ E--- W++ N o? K? w--- !O !M !V PS+ PE?
Y? PGP-- t- 5? X? R- tv- b+(++) DI D+ G++ !e !r !y
-----END GEEK CODE BLOCK-----


From bob@cs.usyd.edu.au  Thu Mar  2 08:03:09 2000
From: bob@cs.usyd.edu.au (Bob Kummerfeld)
Date: Thu, 02 Mar 2000 19:03:09 +1100
Subject: [Edu-sig] Re: Edu-sig digest, Vol 1 #35 - 4 msgs
In-Reply-To: Your message of "Tue, 29 Feb 2000 12:02:05 CDT."
 <20000229170205.76D171CDC8@dinsdale.python.org>
Message-ID: <200003020803.TAA15752@bega.cs.su.oz.au>

> =

> From: "Tim Peters" <tim_one@email.msn.com>
> Subject: RE: [Edu-sig] C++ As a First Language

> My Python version compiled the first time <wink>:
> =

> name =3D input("Please enter your first name:")
> print "Hello", name
> =



=2E.. but did it run? Did you mean to use "raw_input"?

Bob Kummerfeld.




From ulf.engstrom@b2b-link.com  Thu Mar  2 08:26:50 2000
From: ulf.engstrom@b2b-link.com (=?iso-8859-1?Q?Ulf_Engstr=F6m?=)
Date: Thu, 2 Mar 2000 09:26:50 +0100
Subject: [Edu-sig] C++ As a First Language
Message-ID: <002501bf8421$0eabf1c0$d300a8c0@Alexis>

This is a multi-part message in MIME format.

------=_NextPart_000_0022_01BF8429.70365E00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Tim Peters:
>> name =3D input("Please enter your first name:")
>> print "Hello", name

Bob Kummerfeld:
>...but did it run? Did you mean to use "raw_input"?

It runs, the difference between input and raw_input in matter of use is =
just that when you use just plain input you'll have to add ' or " to =
your reply if it's made up of chars.

>>> name =3D input("Please enter your first name:")
Please enter your first name:Ulf
Traceback (innermost last):
  File "<pyshell#0>", line 1, in ?
    name =3D input("Please enter your first name:")
  File "<string>", line 0, in ?
NameError: Ulf

>>> name =3D input("Please enter your first name:")
Please enter your first name:'Ulf'
>>> name
'Ulf'

>>> num =3D input("Please enter a number:")
Please enter a number:5
>>> num
5

>>> name =3D raw_input("Please enter your first name:")
Please enter your first name:Ulf
>>> name
'Ulf'

Conclusion: Unless you're dealing with numbers-only, use raw_input. =
Still it's a lot easier than starting with C++, which was one of my =
first languages. ;)
Regards
Ulf Engstr=F6m

------=_NextPart_000_0022_01BF8429.70365E00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2919.5500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Tim Peters:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&gt;&gt; name =3D input("Please enter =
your first=20
name:")</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&gt;&gt; print "Hello", =
name</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Bob Kummerfeld:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&gt;...but did it run? Did you mean to =
use=20
"raw_input"?</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>It runs, the difference between input =
and raw_input=20
in matter of use is just that when you use just plain input you'll have =
to add '=20
or " to your reply if it's made up of chars.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&gt;&gt;&gt; name =3D input("Please =
enter your first=20
name:")<BR>Please enter your first name:Ulf<BR>Traceback (innermost=20
last):<BR>&nbsp; File "&lt;pyshell#0&gt;", line 1, in =
?<BR>&nbsp;&nbsp;&nbsp;=20
name =3D input("Please enter your first name:")<BR>&nbsp; File =
"&lt;string&gt;",=20
line 0, in ?<BR>NameError: Ulf<BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&gt;&gt;&gt; name =3D input("Please =
enter your first=20
name:")<BR>Please enter your first name:'Ulf'<BR>&gt;&gt;&gt;=20
name<BR>'Ulf'<BR></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>&gt;&gt;&gt; num =3D input("Please =
enter a=20
number:")<BR>Please enter a number:5<BR>&gt;&gt;&gt; =
num<BR>5</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>&gt;&gt;&gt; name =3D raw_input("Please =
enter your=20
first name:")<BR>Please enter your first name:Ulf<BR>&gt;&gt;&gt;=20
name<BR>'Ulf'</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Conclusion: Unless you're dealing with=20
numbers-only, use raw_input. Still it's a lot easier than starting with =
C++,=20
which was one of my first languages. ;)</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Regards</FONT></DIV>
<DIV><FONT face=3DArial size=3D2>Ulf =
Engstr=F6m</FONT></DIV></BODY></HTML>

------=_NextPart_000_0022_01BF8429.70365E00--




From gerrit@nl.linux.org  Thu Mar  2 09:36:53 2000
From: gerrit@nl.linux.org (Gerrit Holl)
Date: Thu, 2 Mar 2000 10:36:53 +0100
Subject: [Edu-sig] C++ As a First Language
In-Reply-To: <002501bf8421$0eabf1c0$d300a8c0@Alexis>; from ulf.engstrom@b2b-link.com on Thu, Mar 02, 2000 at 09:26:50AM +0100
References: <002501bf8421$0eabf1c0$d300a8c0@Alexis>
Message-ID: <20000302103652.A11250@nl.linux.org>

<quote name="Ulf Engström" date="951985610" email="ulf.engstrom@b2b-link.com">
> Conclusion: Unless you're dealing with numbers-only, use raw_input. Still it's a lot easier than starting with C++, which was one of my first languages. ;)

I disagree.

>>> age = input("How old are you? ")
How old are you? __import__('os').system('/bin/sh')
sh-2.03$

Not safe.
</quote>

regards,
Gerrit.

-- 
Plis korekt eni ingglisj joe encounter in mai imeel meeasj!
-----BEGIN GEEK CODE BLOCK----- http://www.geekcode.com
Version: 3.12
GCS dpu s-:-- a14 C++++>$ UL++ P--- L+++ E--- W++ N o? K? w--- !O !M !V PS+ PE?
Y? PGP-- t- 5? X? R- tv- b+(++) DI D+ G++ !e !r !y
-----END GEEK CODE BLOCK-----


From smorris@nexen.com  Thu Mar  2 15:19:51 2000
From: smorris@nexen.com (Steve Morris)
Date: Thu, 2 Mar 2000 10:19:51 -0500 (EST)
Subject: [Edu-sig] Python for non-programmers
In-Reply-To: <3.0.3.32.20000301171345.03979dc8@pop.teleport.com>
References: <NDBBIAEANKEFIFOFMJHPIEPPCAAA.siegel@eico.com>
 <3.0.3.32.20000301171345.03979dc8@pop.teleport.com>
Message-ID: <200003021519.KAA13184@brocade.nexen.com>

Kirby Urner writes:
 > I think your work is very much relevant to what this EDU-SIG is
 > about.  However, for the purposes of discussion, I think we need
 > to draw a distinction between:
 > 
 >    (a) applications written in Python that are useful to 
 >        students in various subject areas
 > 
 >    (b) applications written in Python that have "teaching
 >        Python" as a primary goal
 > 
 >    (c) non-applications (e.g. modules that run in IDLE but
 >        do not provide a custom GUI) that are useful to 
 >        students in various subject areas
 > 
 >    (d) non-applications that have "teaching Python" as a 
 >        primary goal

This is an interesting slicing of the problem space and probably
represents the traditional pedagogical split but I don't think that is
the best way to look at it for CP4E. As a physicist I feel like you
have just told me we need to separate the observer from the system
being observed, something a physicist knows is impossible. I think
CP4E needs to instead emphasize the interaction, i.e. you teach
programming by allowing the student to explore a subject area with a
programming language. You guide them through both in parallel. The
difference is one of emphasis.

It is different in a classroom where you have students already primed
to learn a specific language. However it is my understanding that CP4E
is trying to reach a different audience and has a different
point. CP4E is trying to teach the purpose and use of "programability"
to people of diverse backgrounds and skills.

To me the language/subject dichotomy is a noun/verb, object/action
kind of thing. Python is the verb that acts on the subject being
explored (the noun.) You need to start with simple nouns and verbs and
work up to complex ones. The complexity of both need to go in
parallel, especially when you are tring to draw in the student in a
single course or at a single point of contact.

My late father-in-law was an impressive self tought linguist. He
started with German, Latin and Greek in school and then tought himself
to be fluent in French, Spanish, Russion and Romanian and then to be
able to read technical work and poetry (!) in many other languages. He
usually learned a new language because there was something he wanted
to read in that language and he didn't trust the translators.

He was obviously gifted (his rote memory was phenominal) but his
methodology was interesting. He said that instead of finding a
language tutorial/course etc.  and learning to say simple but useless
things he started by trying to read a subject that he knew well, the
more complex the better as long as he already understood the
complexities of the subject. He said that his understanding of the
subject gave him clues that help him learn the language as it is used.

The same distinction shows up in trying to teach English writing
skills. It is much easier to teach students to write about something
when they have something to say.


From siegel@eico.com  Thu Mar  2 15:27:49 2000
From: siegel@eico.com (Arthur Siegel)
Date: Thu, 2 Mar 2000 10:27:49 -0500
Subject: [Edu-sig] PyOpenGL
Message-ID: <NDBBIAEANKEFIFOFMJHPEEACCBAA.siegel@eico.com>

Kirby writes-

>As a student myself, what I'd be looking
>for is a tutorial on how to make Python talk to OpenGL.  I know
>you have an add-on module for that.  I'm not clear what resources
>are already out there.

Check out David Ascher's site
http://starship.python.net:9673/crew/da/Code/PyOpenGL.

You can download a self-executing Windows install of PyOpenGL, which comes
with a set of
simple demos.

OpenGL is its own learning curve, but there are a lot of resources out there
for it - and
it does become intuitive fairly quickly.


ART




From fig@oreilly.com  Thu Mar  2 15:39:04 2000
From: fig@oreilly.com (Stephen R. Figgins)
Date: Thu, 02 Mar 2000 07:39:04 -0800
Subject: [Edu-sig] RE: Learning Python
In-Reply-To: Your message of "Thu, 02 Mar 2000 08:17:16 +0100."
 <20000302081716.A7088@nl.linux.org>
References: <20000302042403.0F52D1CED4@dinsdale.python.org> <NDBBJPNCJLKKIOBLDOMJMECHCBAA.DavidA@ActiveState.com>              <20000302081716.A7088@nl.linux.org>
Message-ID: <200003021539.HAA03675@rock.west.ora.com>

Gerrit writes:

>A few years later, I discovered Linux, the shell, started using Perl
>but couldn't understand a single bit, started reading "Programming Python"
>(my father, an experienced programming and Unix guru, bought it),
>(Learning Python wasn't there yet) but found it very difficult too;
>after half a year, I did understand Programming Python but did not
>understand OO yet; I bought Learning Python and got the concept of classes.

So mostly you learned through continued exposure and not giving up?

I actually think that is how a lot of hackers learn to program.  Mix
them together with the right elements, shake vigorously, and
eventually they get it.  Though a lot of people don't last, never get
it, never become hackers.  It seems a really like an inefficient way
to go about it.

Stephen


From siegel@eico.com  Thu Mar  2 16:22:18 2000
From: siegel@eico.com (Arthur Siegel)
Date: Thu, 2 Mar 2000 11:22:18 -0500
Subject: [Edu-sig] PyOpenGL  - another comment
Message-ID: <NDBBIAEANKEFIFOFMJHPIEADCBAA.siegel@eico.com>

Dennis writes -

> I think geometry work might be very interesting at some point.  Have you
> considered introducing it along with objects for geometric representation,
> sort of how it showed up in the early Smalltalk work?  Something like
>
> p1 = mkPoint(0.0, 7.3)
> p2 = mkPoint(-3.7, 1.5)
> p3 = mkPoint(2.4, -12.7)
> s1 = mkPlain(p1, p2, p3)
> s2 = ...
> linex = mkIntersection(s1, s2)
> linex.draw(parameters)

I may have reinvented the wheel.  This looks like PyGeo to me.
I don't know what kind of graphics one got from SmallTalk.  Python, via
PyOpenGL,
has the power of OpenGL behind it, so that one can achieve real nice 3D
effects -
lighting, textures, the whole thing.

There is nothing new under the sun. The sun here probably at least got
prettier.

ART



From gherman@darwin.in-berlin.de  Thu Mar  2 17:03:06 2000
From: gherman@darwin.in-berlin.de (Dinu C. Gherman)
Date: Thu, 02 Mar 2000 18:03:06 +0100
Subject: [Edu-sig] Too much money in schools considered harmful
Message-ID: <38BE9ECA.4EA5F7B3@darwin.in-berlin.de>

Hi all,

yesterday night I had an amusing two-hour phone conversa-
tion with a former high school teacher of mine and he was 
keen about telling me the latest developments in that school 
concerning computer science teaching. This is a story about 
how too much money combined with a high dosis of incompe-
tence can make things worse than they were before.

This teacher of mine works now for about 20 years as a bio-
logy and computer science teacher for all age groups from 
10-19 years in Heidelberg, Germany. I'm long out of that 
environment, but I'd say he did an excellent job in getting
people motivated about CS and programming, resulting in va-
rious off-curriculum working groups producing stuff like a 
very interesting simulation software for Plate Tectonics!

For some time now I'm trying to drag him into using Python,
which turns out to be somewhat difficult because I'm rarely
physically present to give a demo or so. It's also a bit 
hairy, because he belongs to those who've grown up with a
warm feeling for Assembler and don't think there's so much 
bad about C++. He went that far to say that he was using 
C++ sucessfully for years in low grades, teaching it with 
some sort of Logo-like graphics simulation environment, that 
actually *produced* C++ code which was then studied and mo-
dified to to slightly different things. Now he's using more 
Java, I think.

As I was rather insisting he finally started to give Python
a try and has some people now participating in what I would 
call an (off-school) evaluation phase, getting himself more 
familiar with Python, and doing simple things for the only 
reason of seeing how it can be done in Python.

This is the end of the good news! On the phone he was almost
depressed when we came to speak about resources and support
by the local or regional/federal authorities. Ironically, he
said last year was a very good one in terms of financial 
support and that's exactly the basis of ongoing trouble.

What happened? The school got lots of money for improving
computer resources and internet access. Previous teaching
rooms were turned into computer teaching and practicing 
pools. Many Wintel PCs were bought. Everything was wired in
a Novel network on top of which there was implemented some
magic "zero-administration" software, that is actually try-
ing to centralize all software installation and maintenance
issues giving control to a single individual, declared to
be the "administrator". Unfortunately, this person has to 
be a high-ranking school administration officer. In that 
case this is the one who has chosen this particular admini-
stration software. I leave it as an excersize to imagine 
how much this person understands about computers or even 
teaching...

Now on this network all new software has to be somehow "ex-
amined" and "adapted" for security reasons by the admini-
stration software's vendor who then has to come by and phy-
sically manipulate the system to do the update (which is 
likely forming a huge part of their revenues). The PCs can-
not simply be disconnected from the network because the
next time they are reconnected their hard drives will be 
nicely reformatted to conform with the system as conceived
by the tool vendor.

So the kids can now use Netscape, some office suite, a C++
compiler (only to edit and compile, not to execute code!)
and some rather useless other programs. The software that
was developped previously will not be running anymore with-
out great headaches resulting from convincing the "admini-
strator" to get it installed. The old PCs will vansish. 
The tool vendor will not care to prepare other software in
their system without the majority of their clients crying
for it.

This is where one realizes that "zero administration" means
"zero flexibility" which is a marriage in heaven for high
school administration officers, responsible for the network.

And it is a lesson to all those who believe that great so-
lutions are to be expected once the sacks of money arrive.
It is not the money alone, it is also full control over how
it is to be spent, that will teach kids something new and
useful that they can hopefully benefit from for the rest of 
their lives. Sadly, this is not by definition what you should
expect nowadays from all teachers and school officials.

This seems to be principal problem that has no easy solution,
has it? Isn't it that always when large amounts of money are
assembled there will be immediatly individuals popping-up and 
trying to appear very concerned and responsible in using it 
to the best of their knowledge and the benefit of those the 
bucks are actually meant for? To me at least it seems that 
too often these individuals are simply enjoying the pleasures
of having power over spending money and controlling things 
that others are affected by and that they rarely understand
themselves.

Well, all that said, we tried to figure out ways to by-pass
the system, which I'm going to outline in a follow-up message 
as this one has already become way too long... 

Still-wondering-if-this-is-a-good-example-of-
the-(other)-Peter-Principle'ly,

Dinu

-- 
Dinu C. Gherman
................................................................
"The thing about Linux or open software in general is that 
it actually tries to move software from being witchcraft to 
being a science," [...] "A lot of the programs you see today 
are actually put together by shamans, and you just take it and 
if the computer crashes you walk around it three times... and 
maybe it's OK." (Linus Thorvalds, LinuxWorld 2000, NYC)


From pdx4d@teleport.com  Thu Mar  2 17:21:59 2000
From: pdx4d@teleport.com (Kirby Urner)
Date: Thu, 02 Mar 2000 09:21:59 -0800
Subject: [Edu-sig] Python for non-programmers
In-Reply-To: <200003021519.KAA13184@brocade.nexen.com>
References: <3.0.3.32.20000301171345.03979dc8@pop.teleport.com>
 <NDBBIAEANKEFIFOFMJHPIEPPCAAA.siegel@eico.com>
 <3.0.3.32.20000301171345.03979dc8@pop.teleport.com>
Message-ID: <3.0.3.32.20000302092159.00772244@pop.teleport.com>

>The same distinction shows up in trying to teach English writing
>skills. It is much easier to teach students to write about something
>when they have something to say.
>

That's interesting feedback to my post Steve.

I actually use this approach, of using Python in the context
of another subject area, where it means something, has a 
clear purpose, already familiar to the student, in my 
'Computer Literacy + Numeracy' series, linked from my
http://www.inetarena.com/~pdx4d/ocn/cp4e.html  

Here I'm going over familiar ground, math topics, using 
Python notation as an alternative way to express math 
concepts (in executable form -- a big plus).  This is 
why I characterized my approach as 'between (c) and (d)'.

I think if you look at my categories again, you might 
see that there's nothing here that would discourage your
approach, which is to tackle the domain of physics using
Python as one more tool.

I have two observers in my picture:  the student and 
the teacher.  The teacher already presumably knows quite
a bit of Python, plus a lot about some subject area 
(e.g. physics).  The student is perhaps learning both
Python and the subject, or just Python, or just the 
subject (already knows Python).  From the standpoint 
of CP4E, I think we're most interested in cases where
Python is still being learned, although it's also 
interesting to think about how to add clarity to a
subject (e.g. physics) with "already knows Python" 
taken as a given -- even on the part of the students.

Kirby



From pdx4d@teleport.com  Thu Mar  2 17:25:16 2000
From: pdx4d@teleport.com (Kirby Urner)
Date: Thu, 02 Mar 2000 09:25:16 -0800
Subject: [Edu-sig] PyOpenGL  - another comment
In-Reply-To: <NDBBIAEANKEFIFOFMJHPIEADCBAA.siegel@eico.com>
Message-ID: <3.0.3.32.20000302092516.00776978@pop.teleport.com>

At 11:22 AM 03/02/2000 -0500, Arthur Siegel wrote:
>Dennis writes -
>
>> I think geometry work might be very interesting at some point.  Have you
>> considered introducing it along with objects for geometric representation,
>> sort of how it showed up in the early Smalltalk work?  Something like
>>
>> p1 = mkPoint(0.0, 7.3)
>> p2 = mkPoint(-3.7, 1.5)
>> p3 = mkPoint(2.4, -12.7)
>> s1 = mkPlain(p1, p2, p3)
>> s2 = ...
>> linex = mkIntersection(s1, s2)
>> linex.draw(parameters)
>
>I may have reinvented the wheel.  This looks like PyGeo to me.

That's encouraging.  So you have object.draw() syntax in PyGeo?  
From the earlier example and your comments about it, it looked 
like you were using assignment statements to cause draw events 
behind the scenes -- confusing.

Thanks for the OpenGL link.  I will follow it.

Kirby




From siegel@eico.com  Thu Mar  2 18:06:18 2000
From: siegel@eico.com (Arthur Siegel)
Date: Thu, 2 Mar 2000 13:06:18 -0500
Subject: [Edu-sig] PyGeo
Message-ID: <NDBBIAEANKEFIFOFMJHPEEAECBAA.siegel@eico.com>

Kirby writes -

> That's encouraging.  So you have object.draw() syntax in PyGeo?
> From the earlier example and your comments about it, it looked
> like you were using assignment statements to cause draw events
> behind the scenes -- confusing.

As presently configured the draw method is called by default. To change the
toggle so it off by
default, and require an explicit call from the script should be no issue.

Which leads to a broader issue of PyGeo in the context of EDU-SIG. The
following is an excerpt of
an off list exchange with Steve Morris. Steve was crticizing me
(constructively I thought) on a few
scores and chose to do it in private.

Steve writes -
...

>In otherwords your web page probably scares away the very people you
>want to attract.

>I suggest that you recreate this page with much simpler examples and
>describe them in more detail. Give at least a one liner that describes
>every function that you use as well as any data types that are
>returned.

Art responds--

>Points well taken, and I appreciate the feedback.

>I do maintain that if I can get PyGeo some sympathetic attention, it could
>be found -  in concept if not in execution - to be very much on point as a
tool
>for helping young folk get some handle on OOP via Python, and at the most
elementary levels.

>A sphere is an object. sphere=Sphere(p1,p2).  sphere.drawcolor=GREEN. And
it is there in front of you.
>And it is green.

>The truth is PyGeo is a lot simpler than the impression people apparently
get from the site.
>
>As to particular design decisions I made with PyGeo, I am certainly open to
ideas, suggestions,
>criticisms.  To the extent you may conclude that I may have gone off-track
in designing PyGeo (as relevant to the goals
>of EDU-SIG), please jump in. I would ideally like to see PyGeo as raw
material to play with for those interested
>in the goals of EDU-SIG.


ART



From pdx4d@teleport.com  Thu Mar  2 18:53:29 2000
From: pdx4d@teleport.com (Kirby Urner)
Date: Thu, 02 Mar 2000 10:53:29 -0800
Subject: [Edu-sig] PyGeo
In-Reply-To: <NDBBIAEANKEFIFOFMJHPEEAECBAA.siegel@eico.com>
Message-ID: <3.0.3.32.20000302105329.00df11e4@pop.teleport.com>

>As to particular design decisions I made with PyGeo, I am certainly 
>open to ideas, suggestions, criticisms.  To the extent you may 
>conclude that I may have gone off-track in designing PyGeo (as 
>relevant to the goals of EDU-SIG), please jump in. I would ideally 
>like to see PyGeo as raw material to play with for those interested
>in the goals of EDU-SIG.
>
>ART

Art, as you say, there's much that's similar between our
respective approaches.  You back end into OpenGL, which
gives students direct and immediate feedback on the 
screen, whereas I back end into Povray.  

You can keep Povray open at the same time as Python, a 
re-render immediately upon re-running a script (even 
outputting to the very same .pov file -- Povray notifies 
you the underlying text file has been changed) but 
your method is still more immediate (as is the method
of drawing diretly to Tk's (flat) canvas, as demoed 
by Python's native /Lib/turtle.py module).

I don't think it has to be either/or.  There are 
advantages and disadvantages to either approach.  For
example, Povray is a free-standing application with
a whole lot of features worth exploring independently
of Python.  OpenGL is likewise a vast topic area unto
itself (more as an API, not as a specific application).  

Some students are heading into the world of ray-tracing, 
and Povray will be a good experience for them, others 
may be heading into a career that requires familiarity 
with OpenGL or other such standard.  Others will benefit
from exposure to both, while some will have occasion 
to use neither. Different walks for different talks.

Although I talked about:

  tri = Triange(p1,p2)
  tri.draw() 

as syntax I'm comfortable with, really my approach has 
been to pass geometric objects to file writer objects.  
That means my vector or shapes classes (which pack in
all the geometry) remain innocent of Povray (and all
the special case syntax that goes with it) -- a good 
design.  

So in practice I'm more likely to write something like:

tri = Triangle(p1,p2)        # create triangle object
outfile = Povray("test.pov") # open file writer w/ filename
outfile(tri)                 # feed tri to the file writer               
outfile.close()              # close the file

[then render test.pov in Povray, to see the triangle]

Using this same framework, I'd probably define an OpenGL 
class along similar lines, and just go:

tri = Triangle(p1,p2)        # create triangle object
outwindow = OpenGL(params)   # open draw window
outwindow(tri)               # draw triangle to window
outwindow.close()            # close the window

... something like that anyway.

In the 'Numeracy + Computer Literacy' series, my Povray 
object (defined in povray.py) contains point(v1), shaft(v1), 
edge(v1,v2) and face([v1,v2,...vn]) methods, all of which 
expect one or more vectors as input.  The vector class is
defined in coords.py and, as I've mentioned, is wholly 
ignorant of Povray.

In my Chapter 7 of "Using Polyhedra to Teach OOP and Coordinate 
Geometry Concepts", I have methods to write out entire 
polyhedra: vertices, edges and faces (all of which have 
their own parameters, including simply "on" and "off").  

Again, the polyhedra, all subclasses of the Poly class, 
are ignorant of Povray (or VRML), although they do have 
color attributes (but physical shapes have color 
independently of their applications -- even if math/philo 
texts regard these as strictly "secondary characteristics").

In this latter approach (passing whole polys as objects), 
the POVwriter class is a subclass of a more generic 
Datawriter class, of which VRMLwriter is another, parallel 
subclass (I never finished RWXwriter, which was supposed 
to output in ActiveWorlds format).  I've implemented this 
same design in Java and, to a lesser extent, in Xbase.

When whole shapes get passed to POVwriter (which accepts
any Poly, i.e. Tetrahedron or Octahedron objects get
upcast to their baseclass Poly for passing) you get 
interactive Python sessions that look more like this:

>>> oTet    = polys.Tetra()     # 'o' in oTet means 'object'
>>> oTet2   = polys.Invtetra()  # oTet2 is inverted tetrahedron
>>> oCube   = polys.Cube()      # other polys follow
>>> oOcta   = polys.Octa()
>>> oDodeca = polys.Rhdodeca()
>>> oCubocta= polys.Cubocta()
>>> oFile   = writers.VRMLwriter('cosmic.wrl') # open VRML file
>>> oFile.writeshape(oTet)      # write all these shapes
>>> oFile.writeshape(oTet2)
>>> oFile.writeshape(oCube)
>>> oFile.writeshape(oOcta)
>>> oFile.writeshape(oDodeca)
>>> oFile.writeshape(oCubocta)
>>> oFile.closefile()           # close file

[ view cosmic.wrl in VRML viewer -- so far I've only 
implemented in VRML 1.0, not VRML 2.0 ]

Kirby



From djmitche@cs.uchicago.edu  Fri Mar  3 00:49:19 2000
From: djmitche@cs.uchicago.edu (Dustin James Mitchell)
Date: Thu, 2 Mar 2000 18:49:19 -0600 (CST)
Subject: [Edu-sig] Python for non-programmers
In-Reply-To: <00030121242105.00703@robeson.elkner.net>
Message-ID: <Pine.LNX.4.10.10003021847340.20723-100000@trigeminal.cs.uchicago.edu>

On Wed, 1 Mar 2000, Jeffrey Elkner wrote:

> I don't mean to be contrary, Kirby, but I was actually disappointed
> with "Learning Python" in the sense that it still does make a lot of
> assumptions about the background of its readers.  There are frequent
> references to other programming languages throughout (offered as
> comparison with Python) and I found the text to still be very
> intimidating for beginners in much the same way that Dennis talks
> about the on-line docs.  There really is no good beginners book using
> Python yet, but of the existing books the one I like best is "The
> Quick Python Book" by Kenneth McDonald and Daryl Harms.  While it is
> certainly not perfect, I found this to be the clearest and easiest to
> read of the books that are out there.

I have to agree.  I found "Learning Python" to be very inconsistent in its
assumptions of its reader.  As an expert programmer who had not used
Python before, I found the book alternately condescending and baffling.
There are sections which are at the right level for a programming novice,
but they appear on the same pages as sections for seasoned Python
programmers, even in the beginning of the book.

Dustin

---------------------------------------------------------------------
|                         Dustin Mitchell                )O(        |
---------------------------------------------------------------------



From djmitche@cs.uchicago.edu  Fri Mar  3 00:57:02 2000
From: djmitche@cs.uchicago.edu (Dustin James Mitchell)
Date: Thu, 2 Mar 2000 18:57:02 -0600 (CST)
Subject: [Edu-sig] More math-teaching
In-Reply-To: <3.0.3.32.20000215140856.0072d1fc@pop.teleport.com>
Message-ID: <Pine.LNX.4.10.10003021849440.20723-100000@trigeminal.cs.uchicago.edu>

On Tue, 15 Feb 2000, Kirby Urner wrote:

> To: Ivars Peterson
>     Science Writer
>     MAA columnist
> 
> Fr: Kirby Urner
>     Curriculum writer
>     Oregon Curriculum Network

I know this was a long long time ago, but some other posts reminded me.
I read and reread Mr. Peterson's books during middle- and high-school,
because they were fascinating explorations of mathematics written at an
accessible but not belittling level.

Kirby, did you hear anything back from Mr. Peterson?

Perhaps we could consider following the course of Mr. Peterson's books?
Perhaps he's interested in working with us?  It seems that his works would
provide a wonderful textbook to which we could attach a series of support
programs...  That is, give modules to do the display of some fractals, and
set students free with The Mathematical Tourist.  Or perhaps write code to
support some randomness experiments to accompany The Jungles of Randomness
(anyone read this?)

I'd like to see this forum create something solid, or at least the designs
of something solid.  Kirby's done that on his own, and I think his work
serves as an excellent model for work we should continue.

Dustin

---------------------------------------------------------------------
|                         Dustin Mitchell                )O(        |
---------------------------------------------------------------------




From djmitche@cs.uchicago.edu  Fri Mar  3 01:01:42 2000
From: djmitche@cs.uchicago.edu (Dustin James Mitchell)
Date: Thu, 2 Mar 2000 19:01:42 -0600 (CST)
Subject: [Edu-sig] Python for non-programmers
In-Reply-To: <001b01bf83ef$55657c80$6fe36dd1@eiconyc>
Message-ID: <Pine.LNX.4.10.10003021900500.20723-100000@trigeminal.cs.uchicago.edu>

On Wed, 1 Mar 2000, Arthur Siegel wrote:

> Nonetheless, I could say a lot to defend PyGeo as relevant to CP4E -
> but will spare the EDU-SIG, at least for now.

I agree completely.  I think that any criticism from the SIG should be
taken, by all of us, as criticism of the nascent ideas floating around in
all of our heads.  Thank you for posting that here.

Dustin

---------------------------------------------------------------------
|                         Dustin Mitchell                )O(        |
---------------------------------------------------------------------



From djmitche@cs.uchicago.edu  Fri Mar  3 01:21:11 2000
From: djmitche@cs.uchicago.edu (Dustin James Mitchell)
Date: Thu, 2 Mar 2000 19:21:11 -0600 (CST)
Subject: [Edu-sig] PyGeo
In-Reply-To: <3.0.3.32.20000302105329.00df11e4@pop.teleport.com>
Message-ID: <Pine.LNX.4.10.10003021918120.20723-100000@trigeminal.cs.uchicago.edu>

>As to particular design decisions I made with PyGeo, I am certainly >open
to ideas, suggestions, criticisms.  To the extent you may >conclude that I
may have gone off-track in designing PyGeo (as >relevant to the goals of
EDU-SIG), please jump in. I would ideally >like to see PyGeo as raw
material to play with for those interested >in the goals of EDU-SIG. >
>ART

Art, as you say, there's much that's similar between our respective
approaches.  You back end into OpenGL, which gives students direct and
immediate feedback on the screen, whereas I back end into Povray.

Suddenly I see where ART's use of immediate redraws instead of explicit
'ob.draw()' calls pays off: the user gets a 'snapshot' of the current
status of their world of objects.  If they write a for loop to turn every
object green, they will see each object turn green in sequence.

I think this is the kind of advantage you can get from interfacing Python
directly with the rendering system, rather than using a separate
application -- immediate feedback.    And to students trying to grasp
difficult OO concepts, immediate feedback is both helpful and engaging.

Dustin

---------------------------------------------------------------------
|                         Dustin Mitchell                )O(        |
---------------------------------------------------------------------




From jasbahr@austin.rr.com  Fri Mar  3 07:23:03 2000
From: jasbahr@austin.rr.com (Jason L. Asbahr)
Date: Fri, 03 Mar 2000 01:23:03 -0600
Subject: [Edu-sig] PyGeo
Message-ID: <3.0.32.20000303012004.00831190@mail112.pair.com>

At 07:21 PM 3/2/00 -0600, Dustin James Mitchell wrote:
>I think this is the kind of advantage you can get from interfacing Python
>directly with the rendering system, rather than using a separate
>application -- immediate feedback.    And to students trying to grasp
>difficult OO concepts, immediate feedback is both helpful and engaging.

Absolutely!  Or to put it another way, it's the kind of advantage you
can get from interfacing Python directly with the *simulation* system.
The model is Python as a microworld toolkit -- with realtime 3D rendering 
as one of many possible outputs of the simulation state.

Cheers,

Jason Asbahr
Origin Systems, Inc.
jasbahr@origin.ea.com




From pdx4d@teleport.com  Fri Mar  3 14:44:53 2000
From: pdx4d@teleport.com (Kirby Urner)
Date: Fri, 03 Mar 2000 06:44:53 -0800
Subject: [Edu-sig] More math-teaching
In-Reply-To: <Pine.LNX.4.10.10003021849440.20723-100000@trigeminal.cs.uc
 hicago.edu>
References: <3.0.3.32.20000215140856.0072d1fc@pop.teleport.com>
Message-ID: <3.0.3.32.20000303064453.0075691c@pop.teleport.com>

>Kirby, did you hear anything back from Mr. Peterson?

Yeah, he and I have some correspondance going back a 
ways.  He knows I'm into Bucky Fuller, which is 
somewhat controversial in that Dr. J.H. Conway at
Princeton thinks Fuller's stuff is a waste of time
(as per recent posts to the Math Forum).

But I was a philosophy major (at Princeton too it
so happens) and interpret 'Synergetics' in light 
of my background in Wittgenstein.  I get quite a
bit of value out if it, including stuff I can use
at the K-12 level, as a curriculum writer (a fact
Conway has said he finds distressing).

I go into this because Ivars (Mr. Peterson) has 
made some links to Fuller's synergetic geometry 
in his books (e.g. in 'Jungles of Randomness') and 
plans to do so again in the upcoming Math Trek 2 
(part of what he's written to me about).  Rather 
courageous of him I'd say, given all the prejudice 
against doing that.  More details at my website
(e.g. see http://www.teleport.com/~pdx4d/bio.html
-- including 'For Further Reading').

Kirby




From pdx4d@teleport.com  Fri Mar  3 15:02:58 2000
From: pdx4d@teleport.com (Kirby Urner)
Date: Fri, 03 Mar 2000 07:02:58 -0800
Subject: [Edu-sig] PyGeo
In-Reply-To: <Pine.LNX.4.10.10003021918120.20723-100000@trigeminal.cs.uc
 hicago.edu>
References: <3.0.3.32.20000302105329.00df11e4@pop.teleport.com>
Message-ID: <3.0.3.32.20000303070258.006c5ffc@pop.teleport.com>

This was me (no quote marks in your reply):
>>Art, as you say, there's much that's similar between our respective
>>approaches.  You back end into OpenGL, which gives students direct and
>>immediate feedback on the screen, whereas I back end into Povray.
>
>Suddenly I see where ART's use of immediate redraws instead of explicit
>'ob.draw()' calls pays off: the user gets a 'snapshot' of the current
>status of their world of objects.  If they write a for loop to turn every
>object green, they will see each object turn green in sequence.

You could get these snap shots either way, e.g.

for i in range(5):  
   tri.center = (0,0,i)
   tri.draw()

>I think this is the kind of advantage you can get from interfacing Python
>directly with the rendering system, rather than using a separate
>application -- immediate feedback.    And to students trying to grasp
>difficult OO concepts, immediate feedback is both helpful and engaging.
>
>Dustin

But we shouldn't exaggerate the difficulty of using a separate
application.  

If I have Povray and Python open at the same time, I can render 
a file generated by Python within a few seconds. 

Plus Povray gives me a "post production" editing phase, where
I can tweek camera distance and angle, background color, textures,
other stuff, without rerunning the script.  

Plus -- and I don't know how this works with PyGeo -- since I'm 
rendering to a .bmp file (by default), I've got a permanent 
copy of my work if I want it, without doing a screen capture.
That's how I get all those .gifs at my website.

Finally, by back ending into Povray, I'm able to keep the 
Python code very simple.  I can just use XYZ coordinates to 
position my objects and don't have to worry about messy issues 
around perspective (foreshortening, cylinders appearing 
thinner with distance etc.).  

Like, here's my function for drawing an edge between two 
points:

    def edge(self,v1,v2):
        # write cylinder from v1.coords to v2.coords
        pointA = v1.coords
        pointB = v2.coords
        self.file.write(("cylinder{<%s, %s, %s>" % pointA
                 + ",<%s, %s, %s>," % pointB
                 + " %s pigment {color %s} no_shadow}\n" 
                 % (self.cylradius, self.cylcolor)))

That's it!  Very short.  Mostly it's just about substituting
numbers into a phrase of text, using the %s syntax -- easy
to explain.  

v1 and v2 (the parameters) are vector objects, already 
familiar, code explained, and usable interactively at 
the Python command line.

Povray handles shading, shadows (if I want them) -- all 
the stuff that ray tracer stuff which, if done in Python, 
would make this _not_ a transparent, beginner's intro 
to the language at all, but a full-fledged application 
with lots and lots of code.

And _that_ is what would get in the way of my students 
appreciating the simplicity of OO.  I'm very willing to 
accept these trade-offs and, as I've said, it's not 
either/or.

Kirby




From siegel@eico.com  Fri Mar  3 16:25:39 2000
From: siegel@eico.com (Arthur Siegel)
Date: Fri, 3 Mar 2000 11:25:39 -0500
Subject: [Edu-sig] PyGeo
Message-ID: <NDBBIAEANKEFIFOFMJHPEEAICBAA.siegel@eico.com>

Kirby -

As I mentioned to you at one point, it was POV-RAY that initially generated
my interest in 3D graphics directly, which indirectly led to a path that has
turned me into a (mostly)gray-haired guy who can code Python and OpenGL.

So as a cross-section of one, I am a good argument to support your position
that POV-RAY can be an inspiration in generating the kind of interest and
enthusiasm that is fundamental to the goals of EDU-SIG.

And it remains true that the quality of graphical output provided by POV-RAY
is beyond anything that OpenGL can do, at least anything I am capable of
making OpenGL do.

I have a graphic I did in POV-RAY a few years ago hanging proudly in my
study.

And with the advent of decent $150 color printers, the opportunity for
students to see their work in hard copy is there, I think extremely
important, and better handled through POV-RAY than PyGeo - though you can
output .ppm
images from PyGeo.

So that I certainly do not want support a Python to POV-RAY, versus PyGeo
argument.

BUT - (you knew one was coming)

What hasn't been emphasized in the discussion so far is the PyGeo is fully
interactive. The top-level script just defines a starting position of
objects in 3D space.
You go from there. I think the interactivity has a high fun quotient, which
will generate a "help me
understand how that happens" factor and  a good "you got my attention now"
factor.  And, yes, it can work wonderfully I believe to build an intuitive
understanding of geometric concepts, which to me is not as off topic as may
appear.

Based on the approach you have achieved with Python and POV-RAY, there is of
course the potential of building a write-to-POV function into PyGeo. Many
modellers
much more sophisticated than PyGeo have it.  Manipulate the construction
interactively until
you are happy with what you see. Write to POV-RAY and get a new level of
graphic resolution.
Write to a targ or a jpg. Print it out. Hang it up

Killer app, in my opinion.

Any interest in pursuing???



From smorris@nexen.com  Fri Mar  3 16:53:20 2000
From: smorris@nexen.com (Steve Morris)
Date: Fri, 3 Mar 2000 11:53:20 -0500 (EST)
Subject: [Edu-sig] PyGeo vs PovRay
Message-ID: <200003031653.LAA27822@brocade.nexen.com>

Arthur Siegel writes:
--- clip ---

 > So that I certainly do not want support a Python to POV-RAY, versus PyGeo
 > argument.
 > 
 > BUT - (you knew one was coming)
 > 
 > What hasn't been emphasized in the discussion so far is the PyGeo is fully
 > interactive.

--- clip ---

Leaving the issues of implementation behind for the moment, in a
perfect world we want the interactivity of PyGeo/OpenGl with the
quality of PovRay.

Since that is impossible (at least with our resources) the next best
thing is to be able to debug with lower (graphical) quality higher
speed interactive tools and then do hardcopy with PovRay.

In this better but less than perfect world we would have a higher
level abstraction that could map into eithor output method at the
users discretion.

The concept of a common abstraction with drivers hiding the details of
the implementation is not rocket science. On the other hand adding a
level of abstraction also adds to the complexity (cost) of a
project. Today we have two people generating useful work. If we wait
for the development of a spec and the implementation of an abstraction
layer everything would stop for a while.

Another disadvantage of such an approach is that it is a lowest common
denominator kind of thing. Adding features gets harder because they
have to be implemented and debugged in both backends.


From pdx4d@teleport.com  Fri Mar  3 17:20:32 2000
From: pdx4d@teleport.com (Kirby Urner)
Date: Fri, 03 Mar 2000 09:20:32 -0800
Subject: [Edu-sig] Re: PyGeo
In-Reply-To: <NDBBIAEANKEFIFOFMJHPEEAICBAA.siegel@eico.com>
Message-ID: <3.0.3.32.20000303092032.0078fe3c@pop.teleport.com>

>And with the advent of decent $150 color printers, the opportunity for
>students to see their work in hard copy is there, I think extremely

And to make T-shirts of their own work.  Office Depot sells
some product making this easy (haven't yet tested myself).

>What hasn't been emphasized in the discussion so far is the PyGeo is fully
>interactive. The top-level script just defines a starting position of
>objects in 3D space.

Yes, this is an important difference.  The ability to grab
something on screen with a mouse and move it is what makes
your app a different animal.  Like any good zoo, or jungle,
a classroom/course should have lots of animals, some exotic.

>You go from there. I think the interactivity has a high fun quotient

Agreed.  This is what we've found with STRUCK (interactive 
Java application -- outputs to Povray, VRML _and_ ActiveWorlds).

STRUCK also makes stuff happen on screen even if the user 
just sits back and doesn't do anything, because the shapes 
are defined using "springs" with tension/compression 
characteristics.  

Lots of times, the network has a hard time "getting comfortable" 
and blobs all over the place. Capturing this dynamism (which
power users learn to control) in successive frames has been 
the basis for a number of interesting AVI and QuickTime 
animations.  Very high fun quotient.

>will generate a "help me
>understand how that happens" factor and  a good "you got my attention now"
>factor.  And, yes, it can work wonderfully I believe to build an intuitive
>understanding of geometric concepts, which to me is not as off topic as may
>appear.

Agreed.

>Manipulate the construction interactively until you are happy with 
>what you see. Write to POV-RAY and get a new level of graphic 
>resolution. Write to a targ or a jpg. Print it out. Hang it up
>
>Killer app, in my opinion.
>
>Any interest in pursuing???

STRUCK is open source (in Java).  Given I'm more familiar with 
this package, I'm wondering about learning more from your work
in order to help me convert pieces of STRUCK into Python and/or
JPython.  

The idea would be for students to learn Python, see how Python 
can implement STRUCK-style concepts (this might include some
OpenGL stuff -- not clear yet), and then make the transition 
to full-fledged Java (which will seem far more readable and 
comprehensible given the strong background in Python).

Were I to undertake the above (sounds like a real challenge), 
I think you and I would find ourselves overlapping quite a bit.
Colleagues in the fluidiom.com circle might jump in as well
(Gerald, STRUCK's principal designer/coder, has been using
Python to show the ropes to his son Mitch -- about the same
age as my 5 year old).

Kirby




From rlatimer@mirage.tjhsst.edu  Fri Mar  3 22:47:05 2000
From: rlatimer@mirage.tjhsst.edu (Randy Latimer)
Date: Fri, 3 Mar 2000 17:47:05 -0500 (EST)
Subject: [Edu-sig] PyGeo
In-Reply-To: <3.0.3.32.20000303070258.006c5ffc@pop.teleport.com>
Message-ID: <Pine.LNX.4.10.10003031743270.16929-100000@vortex.tjhsst.edu>

This is a note from a high school CS teacher.  After the APCS exam in May,
some CS teachers are more open to trying some new ideas, such as teaching
a short unit on Python.  I'm teaching at a science and technology magnet
school, and we have several APCS classes as well as the introductory year
course.  I'd be happy to try and "sell" a unit on Python as an end of year
exploratory unit for interested CS students.
   1. Is this worth undertaking
   2.  If yes, is there some suggested materials that would be good to
use?
  Randy Latimer




From siegel@eico.com  Fri Mar  3 18:29:32 2000
From: siegel@eico.com (Arthur Siegel)
Date: Fri, 3 Mar 2000 13:29:32 -0500
Subject: [Edu-sig] re: PyGeo
Message-ID: <NDBBIAEANKEFIFOFMJHPOEAICBAA.siegel@eico.com>

Kirby -

I think we get down to brass tacks a bit.

You write:

> The idea would be for students to learn Python, see how Python
> can implement STRUCK-style concepts (this might include some
> OpenGL stuff -- not clear yet), and then make the transition
> to full-fledged Java (which will seem far more readable and
> comprehensible given the strong background in Python).

My sense of where you and I part company in a fundamental way has nothing to
do with programming, education in general, PyGeo, POV-RAY, or Python.

It has to do with geometry.

You seem intrigued by and devoted to "alternative" geometric concepts.  I
am essentially a Euclid fundamentalist. When I run the world, we probably
throw
away all the Geoemetry texts and go back to Heath's Euclid. I'm only pissed
we have to settle for a translation. Maybe we make ancient Greek a
pre-requisite.

ART



From dscherer@cmu.edu  Fri Mar  3 18:48:12 2000
From: dscherer@cmu.edu (David Scherer)
Date: Fri, 3 Mar 2000 13:48:12 -0500
Subject: [Edu-sig] PyGeo vs PovRay
In-Reply-To: <200003031653.LAA27822@brocade.nexen.com>
Message-ID: <NDBBJMMNCLAJIPDNOJNEOENHCAAA.dscherer@cmu.edu>

> Leaving the issues of implementation behind for the moment, in a
> perfect world we want the interactivity of PyGeo/OpenGl with the
> quality of PovRay.

In support of our effort to integrate Python with the physics curriculum
here, I am working on a Python visualization library which aims to provide
both high rendering quality and "automatic" interactivity to Python
programs.  The interface aims at allowing the user to write "zero graphics
code" by making the graphics primitives useful data structures.  For
example,

from visual import *

ball = sphere()
ball.momentum = vector(10,0,0)
ball.mass = 3.0
dt = 0.1

while 1:
  ball.position = ball.position + ball.momentum/ball.mass*dt

'momentum' and 'mass' are attribute names invented by the user - any names
could be used.  Python's __getattr__ and __setattr__ mechanism allows me to
make changing the ball's built-in 'position' attribute actually move the
ball on the screen in real-time.

At present, I am working with a prototype implementation which, like PyGeo,
uses PyOpenGL for rendering.  Once we are satisfied with the interface, I
plan to re-implement the library with a custom graphics engine in C++, which
will probably use OpenGL directly to render polygons (if it's good enough
for Quake 3... :).  Although it obviously won't be a raytracer, the presence
of an engine written by knowledgable graphics coders in a fast
implementation language makes all kinds of powerful rendering techniques
available.  For example, the engine could transparently do stereo rendering
with anaglyph or shutter glasses, replace lines with shaded cylinders or
alpha 'trails', interpolate curves for added detail, or reduce unnecessary
detail in order to maintain a high frame rate.  It could also support
advanced primitives like height and even volume fields at interactive frame
rates.

The internals of the graphics engine aren't intended to be exposed to the
beginning coder, any more than the internals of the Python interpreter or
the OpenGL library itself are.  I don't see that as a problem - you have to
draw the line at *some* level of abstraction.

> Since that is impossible (at least with our resources) the next best
> thing is to be able to debug with lower (graphical) quality higher
> speed interactive tools and then do hardcopy with PovRay.

For our purposes, animation and even interactivity are very important, so we
haven't seriously considered a non-real-time back end implementation, but
the level of abstraction of the interface is already adequate to make this
possible.

> Another disadvantage of such an approach is that it is a lowest common
> denominator kind of thing. Adding features gets harder because they
> have to be implemented and debugged in both backends.

Indeed.  In fact, even releasing a prototype makes it harder to make changes
because you instantly have a group of users who are used to the "old way."

I think it's a good idea to "let a thousand flowers bloom" at the moment.
There are all kinds of ways that separate efforts could be integrated
later - for example, PyGeo is an interactive 'application' that could easily
run on top of my library instead of PyOpenGL and enjoy both simpler code and
better rendering quality.  A "dump screenshot to povray" feature could then
be added to my library, and you would have the best of all worlds.

Dave



From pdx4d@teleport.com  Fri Mar  3 20:47:13 2000
From: pdx4d@teleport.com (Kirby Urner)
Date: Fri, 03 Mar 2000 12:47:13 -0800
Subject: [Edu-sig] re: PyGeo
In-Reply-To: <NDBBIAEANKEFIFOFMJHPOEAICBAA.siegel@eico.com>
Message-ID: <3.0.3.32.20000303124713.0076f2f4@pop.teleport.com>

> = Art 
  = Kirby

>My sense of where you and I part company in a fundamental way has nothing to
>do with programming, education in general, PyGeo, POV-RAY, or Python.
>
>It has to do with geometry.
>
>You seem intrigued by and devoted to "alternative" geometric concepts.  I
>am essentially a Euclid fundamentalist. When I run the world, we probably
>throw away all the Geoemetry texts and go back to Heath's Euclid. I'm 
>only pissed we have to settle for a translation. Maybe we make ancient 
>Greek a pre-requisite.
>
>ART

You could be right Art.  Although I could write a lot about
this, I'm reluctant to do so on Edu-Sig, as we're no longer
talking about Python per se, nor even CP4E exactly.

I will say that I don't know for sure that anything I'm 
doing contradicts the original Greek implementation.  As 
formalized by later generations, perhaps the discrepancies
build up, but all those Euclidean demos remain relevant 
to my work (at least a couple web sites have implemented 
at least some of his Elements in the form of animated 
step-by-step presentations).

What I will say here (because I think it's relevant) is that
I consider it wasteful to always be sticking to a flat plane
when doing geometry.  In the old days, going spatial was 
more difficult and tedious, and people considered it an
elaboration of the planar constructs -- not necessary to
get into from the point of view of teaching a Euclidean 
mindset.

But my view is that computers and our new graphical tools
free us from the plane, get us into space.  Kids deserve 
a much better, easier on-ramp into spatial geometry than
ever before.  And the Oregon Curriculum Network is about 
supplying such an on-ramp (one of many possible).  

But I wouldn't say that in going from a planar to a spatial
focus that my approach is "anti-Euclidean" in any way. 
Plus I notice PyGeo is thoroughly volumetric in its 
approach.  So our differences (as you seem to detect 
them) must lie elsewhere.  Perhaps that's a thread we 
could pick up on someday on another listserv -- might be 
interesting to teachers with a more specialized interest 
in geometry and the pedagogical debates surrounding that 
subject.

Kirby




From jason@crash.org  Fri Mar  3 21:26:54 2000
From: jason@crash.org (Jason L. Asbahr)
Date: Fri, 03 Mar 2000 15:26:54 -0600
Subject: [Edu-sig] PyGeo vs PovRay
Message-ID: <3.0.32.20000303152314.009d8940@mail112.pair.com>

At 01:48 PM 3/3/00 -0500, David Scherer wrote:
>At present, I am working with a prototype implementation which, like PyGeo,
>uses PyOpenGL for rendering.  Once we are satisfied with the interface, I
>plan to re-implement the library with a custom graphics engine in C++, which
>will probably use OpenGL directly to render polygons (if it's good enough
>for Quake 3... :).  Although it obviously won't be a raytracer, the presence
>of an engine written by knowledgable graphics coders in a fast
>implementation language makes all kinds of powerful rendering techniques
>available.  For example, the engine could transparently do stereo rendering
>with anaglyph or shutter glasses, replace lines with shaded cylinders or
>alpha 'trails', interpolate curves for added detail, or reduce unnecessary
>detail in order to maintain a high frame rate.  It could also support
>advanced primitives like height and even volume fields at interactive frame
>rates.
>
>The internals of the graphics engine aren't intended to be exposed to the
>beginning coder, any more than the internals of the Python interpreter or
>the OpenGL library itself are.  I don't see that as a problem - you have to
>draw the line at *some* level of abstraction.

This is a good way to go -- also, check out the OpenRM Scene Graph
on SourceForge.  Gizmo3D is also an interesting open source scene
graph effort.  There may be some possibilities for merging.

Cheers,

Jason Asbahr
Origin Systems, Inc.
jasbahr@origin.ea.com



From Fredrik Lundh" <effbot@telia.com  Fri Mar  3 19:52:40 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Fri, 3 Mar 2000 20:52:40 +0100
Subject: [Edu-sig] PyGeo vs PovRay
References: <200003031653.LAA27822@brocade.nexen.com>
Message-ID: <009801bf854a$09d9b540$34aab5d4@hagrid>

Steve Morris wrote:
> Leaving the issues of implementation behind for the moment, in a
> perfect world we want the interactivity of PyGeo/OpenGl with the
> quality of PovRay.
>=20
> Since that is impossible (at least with our resources) the next best
> thing is to be able to debug with lower (graphical) quality higher
> speed interactive tools and then do hardcopy with PovRay.

fwiw, you just described caligari's trueSpace 4

(fast interactive rendering via DirectX or OpenGL, high-quality
raytracing for output, and a built-in Python interpreter...  but
not exactly free, of course...)

</F>



From pdx4d@teleport.com  Fri Mar  3 23:24:54 2000
From: pdx4d@teleport.com (Kirby Urner)
Date: Fri, 03 Mar 2000 15:24:54 -0800
Subject: [Edu-sig] Re: "Killer Apps" vs. CP4E
In-Reply-To: <009801bf854a$09d9b540$34aab5d4@hagrid>
References: <200003031653.LAA27822@brocade.nexen.com>
Message-ID: <3.0.3.32.20000303152454.03251a5c@pop.teleport.com>

>(fast interactive rendering via DirectX or OpenGL, high-quality
>raytracing for output, and a built-in Python interpreter...  but
>not exactly free, of course...)
>
></F>

<SOAP BOX>

Re news of some of the latest projects --

We already know that Python is a powerful and capable
language.  So is C++, so is Java -- a host of others
(e.g. the LISP varieties -- some claim Scheme is no 
longer a LISP (an irrelevant aside, I know)).

So I have no doubt that many talented and accomplished
programmers are going to use Python and JPython to 
create whiz bang gee whiz applications that help 
students learn a variety of subjects.

But this is nothing new.  We already have an embarrassment
of useful software, a lot of which is having a hard time
finding its way into the standard curriculum -- simulations, 
dynamic geometry programs and so on, all with their advantages 
and disadvantages.

The question in my mind is how to open up the world of
programming to more people.  I'm especially interested
in doing this in a non-CS context (my students haven't
necessarily committed to following any CS curriculum).

To this end, even the best application/simulation/killer 
app ever conceived, for teaching geometry or physics or 
whatever, might be completely irrelevant from the standpoint 
of opening up the world of programming to a wider audience 
-- because the code is hard, difficult to comprehend
(doesn't mean inelegant, just means "done by a pro" (or 
by a hacker -- sometimes it's a very fine line...)).

In sum, when it comes to "proving Python can drive 
sophisticated apps with GUIs, real time graphical feedback", 
I have no doubts.  I know that's true.  But my initial 
reaction is "so what?".  What does this have to do with 
CP4E?  Just being a devil's advocate (a role I'm probably 
all too accustomed to playing).

My mentioning of Struck in this context (earlier post) 
was in line with the goal of giving students deeper insights 
into coded namespaces.  Gerald de Jong, founder of 
beautifulcode.nl, specifically wrote Struck in a way he 
hoped demonstrated elegant _simple_ Java code (he trains
people in Java for a living, has flown to Tokyo and places
to show how it's done -- not unlike Bruce Eckel in this 
regard).  

The amazing thing about Struck isn't how much goes on "under
the hood", but how LITTLE.  And yet you get a lot of screen 
activity, the ability to do animations -- from a very _tiny_ 
reiterative vector processor.

I, for one, am not in on this listserv because I'm trolling 
for potential collaborators on some "killer app". That might 
happen, inadventently, but my focus is finding ways to open 
up the world of programming to more students.

To this end, I think Python is already adequate as is (as 
I've been saying from the beginning), and no additional apps 
are essential to furthering these goals.  I'm sure the next 
IDLE will be even better, and eagerly await its debut, but 
0.5 is certainly usable as is.  No need to sit around 
twiddling my thumbs waiting for Guido to provide: he's 
already made a tremendous contribution, is not himself a 
bottle neck of any kind.

Seems to me that most of the relevant barriers to CP4E are 
political and administrative.  The technology is not the 
problem.  The problem is a creaky, obsolete, boring, 
unimaginative curricula.  

What I'm doing is setting some new standards (yes, using 
Python as a part of the mix), so that I can go out to world 
and say "look, any of you other curriculum writers _could_ 
be doing stuff more like this -- don't you think this 
makes a lot of sense, compared to what's run-of-the mill 
today?".

</SOAP BOX>

Kirby



From siegel@eico.com  Sat Mar  4 00:06:37 2000
From: siegel@eico.com (Arthur Siegel)
Date: Fri, 3 Mar 2000 19:06:37 -0500
Subject: [Edu-sig] Re: "Killer Apps" vs. CP4E
Message-ID: <NDBBIAEANKEFIFOFMJHPMEAJCBAA.siegel@eico.com>

Kirby - 


> I, for one, am not in on this listserv because I'm trolling 
> for potential collaborators on some "killer app". That might 
> happen, inadventently, but my focus is finding ways to open 
> up the world of programming to more students.

Since I am the one whose used the term killer app, and did implicitly
invite you to think about collaborating on some code and concepts, I take
the above a little personally.

And highly resent it.

If this isn't fun, its nothing - from my perspective.  And remarks
like that - whoever you may have been thinking of  -  kill it for me.

I'll leave it at that.
 
ART


From dscherer@evergames.kssacct.com  Sat Mar  4 00:20:41 2000
From: dscherer@evergames.kssacct.com (David Scherer)
Date: Fri, 03 Mar 2000 19:20:41 -0500
Subject: [Edu-sig] Stop the insanity: no more meta-discussion (was: "Killer Apps" vs. CP4E)
Message-ID: <2923468654.952111241@ZAPHOD>

Kirby,

> To this end, even the best application/simulation/killer 
> app ever conceived, for teaching geometry or physics or 
> whatever, might be completely irrelevant from the standpoint 
> of opening up the world of programming to a wider audience 
> -- because the code is hard, difficult to comprehend
> (doesn't mean inelegant, just means "done by a pro" (or 
> by a hacker -- sometimes it's a very fine line...)).

You are focusing on a particular method of teaching: a kind of "top down"
self-motivated analysis approach, in which students originally work with the
top level of a system, but as they grow can "open up the hood" one layer at
a time to look at the implementation.

This is a powerful idea.  However, there's always some point at which things
become opaque.  An example is the Python language itself.  The
implementation of Python and its libraries is many tens of thousands of
lines of C code "done by a pro", and probably doesn't have much pedagogical
value to the novice.  However, the interface of that code (Python) is very
relevant to CP4E.  The POVRAY application you are using is another example -
it's interface defines the minimum level of abstraction your students are
able to see.  In fact, no matter how expert a programmer you are, you are
almost certainly using some tools that you don't know very much about the
implementation of (Did you write your own optimizing C++ compiler?  Virtual
memory system?  Video card firmware?)

I think that all of the projects which are being discussed on this SIG are
relevant, because they are all designed to provide pedagogically useful
programming *interfaces*.  They don't have to be useful example code to
contribute to CP4E; they just need to provide some service relevant to
teaching programming and other subjects using Python.

Also, keep in mind that Guido created the edu-sig to discuss all kinds of
applications of Python in education, not *only* CP4E.  It says so quite
clearly on the SIG homepage.

> To this end, I think Python is already adequate as is (as 
> I've been saying from the beginning), and no additional apps 
> are essential to furthering these goals.  

If the presently available tools are adequate for *your* needs, that's
great!  No one has complained about you using this forum to discuss your
work.  However, other people might have different needs.  It's not clear to
me why they shouldn't use this forum to discuss them.

> Seems to me that most of the relevant barriers to CP4E are 
> political and administrative.  The technology is not the 
> problem.  The problem is a creaky, obsolete, boring, 
> unimaginative curricula.  

As it happens, I agree.  However, I have neither skill nor leverage to
attack that aspect of the problem.  If you do, why not respond to Randy
Latimer's post, instead of complaining about progress in other directions?

Dave


From pdx4d@teleport.com  Sat Mar  4 00:55:37 2000
From: pdx4d@teleport.com (Kirby Urner)
Date: Fri, 03 Mar 2000 16:55:37 -0800
Subject: [Edu-sig] Re: "Killer Apps" vs. CP4E
In-Reply-To: <NDBBIAEANKEFIFOFMJHPMEAJCBAA.siegel@eico.com>
Message-ID: <3.0.3.32.20000303165537.03268cc8@pop.teleport.com>

>Since I am the one whose used the term killer app, and did implicitly
>invite you to think about collaborating on some code and concepts, I take
>the above a little personally.

Sorry you chose to take it personally.  "Killer app" is a common
term of art, and we've seen more than one post to this list 
suggesting we might all want to get together and collaborate 
on some large project, of one kind or another.

I want to make clear what my own motivations are.  Others have 
other motivations.

My <SOAP BOX> tags were meant to indicate that I was meaning to be 
polemical, state my case strongly, but I hoped constructively.

>And highly resent it.
>
>If this isn't fun, its nothing - from my perspective.  And remarks
>like that - whoever you may have been thinking of  -  kill it for me.

On the other hand, you have indicated that you and I have some
fundamental difference in our respective approaches to geometry, 
and you claimed Euclid for your camp, while dismissing mine as
"alternative".

This seemed a prejudicial and distancing remark.  I responded 
without a lot of rancor or resentment at what I might have 
taken personally, as a slap in the face.

Kirby

PS:  I don't give you Euclid by the way.  As far as I'm concerned, 
he's as much in my camp as in yours.




From pdx4d@teleport.com  Sat Mar  4 01:26:15 2000
From: pdx4d@teleport.com (Kirby Urner)
Date: Fri, 03 Mar 2000 17:26:15 -0800
Subject: [Edu-sig] Stop the insanity: no more meta-discussion (was:
 "Killer Apps" vs. CP4E)
In-Reply-To: <2923468654.952111241@ZAPHOD>
Message-ID: <3.0.3.32.20000303172615.0327320c@pop.teleport.com>

Dave --

First off, I don't quite understand why "more meta-discussions" 
fit your criteria of "insanity".  Most lists I've been on lapse
into "meta mode" from time to time as people take stock and map 
out future directions.  Seems this thread is a lot more valuable 
than debating about whether Python should remain case sensitive 
or not -- but that's just me talking.

>implementation of (Did you write your own optimizing C++ compiler?  Virtual
>memory system?  Video card firmware?)

No, nor did I design the neural network behind my eyes, nor
the eyeballs I use to stare at my screen.  I agree with you:
if you start going deeper into it, you get to layers you 
won't find all that transparent -- or even if you eventually
understand them, they're still not your own work.  Point 
granted.  Absolutely.

>I think that all of the projects which are being discussed on this SIG are
>relevant, because they are all designed to provide pedagogically useful
>programming *interfaces*.  They don't have to be useful example code to
>contribute to CP4E; they just need to provide some service relevant to
>teaching programming and other subjects using Python.

When you say teaching programming "and" other subjects, does that 
also imply "or" -- meaning we can drop the "teaching programming" 
part?  That's what I was getting at with my little soap box speech.  

It seems to me that if you have a brilliant interface (for example 
Lotus 1-2-3, from VisiCalc, which set the standard for a whole 
breed of application) you don't necessarily have anything helpful 
vis-a-vis the goals of CP4E.

As it happens, Lotus 1-2-3 implemented "key stroke macros" and a 
lot of bizapp users really _did_ start to grok basic concepts of 
programming by using this feature -- Microsoft gradually weaned 
these people from a keystroke menu context over to various 
flavors of Visual Basic.  

So yes, Lotus 1-2-3 did have some merit from a CP4E standpoint. But 
a lot of high end apps do not (even if they're killers), because 
they're immediately opaque (to use your terminology) the moment 
you try to do anything like "program" with them, and/or understand
how they work (in general, I consider the open source movement
to be highly consistent with the goals of CP4E).

>Also, keep in mind that Guido created the edu-sig to discuss all kinds of
>applications of Python in education, not *only* CP4E.  It says so quite
>clearly on the SIG homepage.

Yes, that's true.  But I don't think that should mean individual
subscribers should keep silent about their own desires, needs,
motivations.  I've found it helpful when others have announced
their intentions and focus -- sometimes quite different from 
mine.  

I think such statements help keep the discussion from drifting 
too aimlessly.  Because if we're really going to just chat about 
all the wonderful stuff that Python is doing or might do in 
various educational contexts, then we're sort of slicing at 
a weird angle IMO.  Like, why is it so important what language 
got used, if it's just another "black box" with a groovy interface?  

Why get all pumped and excited because such and such an app is 
written in Python and go ho hum because something else is 
written in C++ or Pascal -- even if they're both killer apps?  

That seems little more than "language bigotry", and I see no 
reason to indulge in it myself.  That's like cheerleading 
on behalf of English or French.  Great works can/have/will 
be written in either language.  Yeah, so?

>> To this end, I think Python is already adequate as is (as 
>> I've been saying from the beginning), and no additional apps 
>> are essential to furthering these goals.  
>
>If the presently available tools are adequate for *your* needs, that's
>great!  No one has complained about you using this forum to discuss your
>work.  However, other people might have different needs.  It's not clear to
>me why they shouldn't use this forum to discuss them.

I've said from the beginning that when I make statements about 
what I see as useful and important, I'm not meaning to play
moderator.  I don't moderate this group.  Anyone can post 
anything they like.  I just provide feedback, my two cents.
I encourage others to do the same -- that's healthy.

>> Seems to me that most of the relevant barriers to CP4E are 
>> political and administrative.  The technology is not the 
>> problem.  The problem is a creaky, obsolete, boring, 
>> unimaginative curricula.  
>
>As it happens, I agree.  However, I have neither skill nor leverage to
>attack that aspect of the problem.  If you do, why not respond to Randy
>Latimer's post, instead of complaining about progress in other directions?
>

I don't think I'm "complaining about progress in other directions".
My whole point is we're already there.  No more progress is needed 
(again, from my point of view), when it comes to having a highly 
teachable, fun, intelligent language that we can immediately 
press into service to advance the goals of CP4E. That's all good 
news.

From my point of view, all we have to do is keep pumping out 
useful curriculum that makes transparent use of computer language,
and we'll quickly erode the authority of "has been" curricula
which no longer suit.  We have a winning hand.  Nothing can 
stop us.  Just a matter of time.  If administrators don't see
it, I know parents will, and most of them have an investment
in seeing their children get a relevant education.

Kirby



From ajs@ix.netcom.com  Sat Mar  4 01:39:24 2000
From: ajs@ix.netcom.com (Arthur Siegel)
Date: Fri, 3 Mar 2000 20:39:24 -0500
Subject: [Edu-sig] Re: "Killer Apps" vs. CP4E
References: <3.0.3.32.20000303165537.03268cc8@pop.teleport.com>
Message-ID: <000501bf857a$7eb10d20$f2e16dd1@oemcomputer>

> Kirby
>
> PS:  I don't give you Euclid by the way.  As far as I'm concerned,
> he's as much in my camp as in yours.

I'm not sure how we got into camps. So be it.

And yes I fear I'm contruibuting to sending things off track here somehow.

But I need to get a few more words out before I troll away for a bit.

What I tried to make clear from the beginning of my involvement here is that
I
don't consider myseld a serious developer, nor am I an educator.

What I am, and why I thought myself relevant, is someone who has  learned
a decent amount about programming, and exclusively through Python .

What's a decent amount. Enough to pull off PyGeo, no more no less.

When the the Guido's, Lundh's and Ascher's and others who are
participating -
guys who make their living and reputations writing code and building a
community of others who do the same - post up I am happy to move aside and
listen.

Ironically though, Python is probably too young to have been a first
language for
anyone doing serious development today - and that includes the leaders
of the Python community.

So I have a perspective about learning programming with Python that it is
hopefully authentic because thats exactly what I did.

And it is in this regard in which I hope to be taken "seriously" as a
participant in the discussions of EDU-SIG.









From pdx4d@teleport.com  Sat Mar  4 02:01:27 2000
From: pdx4d@teleport.com (Kirby Urner)
Date: Fri, 03 Mar 2000 18:01:27 -0800
Subject: [Edu-sig] Re: "Killer Apps" vs. CP4E
In-Reply-To: <000501bf857a$7eb10d20$f2e16dd1@oemcomputer>
References: <3.0.3.32.20000303165537.03268cc8@pop.teleport.com>
Message-ID: <3.0.3.32.20000303180127.0326f98c@pop.teleport.com>

> = Art
  = Kirby

> I'm not sure how we got into camps. So be it.

Here's how:  "My sense of where you and I part company 
in a fundamental way..."

> And it is in this regard in which I hope to be taken "seriously" 
> as a participant in the discussions of EDU-SIG.

As far as I'm concerned, you're a Python guru.  I've already
stated I look up to you as a teacher of the language and I
expect to learn a lot from digging around in your code, 
and/or following your lead/direction with regard to 
promising new synergies (i.e. Python + OpenGL, Python + ?).

If you read back in the archives, I was the guy always 
saying I was most interested in reading stuff from posters
who were actually working on projects, not sitting back
in their arm chairs and throwing out a lot of "bright
ideas" in hopes that others would then do all the work.

Then you showed up, a role model and prime example of 
someone who walks the talk.  Exactly the kind of participant
I was hoping to hear from.

Kirby

PS:  I code for a living a lot of the time, pay bills by 
writing programs -- but in Xbase, not Python.  For years
I had a GUI running in the open heart surgery theaters
(8 workstations, multi-user).  Even today, my programs
suck data from cath labs via a wide area network.  I am
a pro.  But not at Python.






From pdx4d@teleport.com  Sat Mar  4 17:53:13 2000
From: pdx4d@teleport.com (Kirby Urner)
Date: Sat, 04 Mar 2000 09:53:13 -0800
Subject: [Edu-sig] N + CL = CP4E
In-Reply-To: <3.0.3.32.20000303180127.0326f98c@pop.teleport.com>
References: <000501bf857a$7eb10d20$f2e16dd1@oemcomputer>
 <3.0.3.32.20000303165537.03268cc8@pop.teleport.com>
Message-ID: <3.0.3.32.20000304095313.00723f00@pop.teleport.com>

I've posted a first version of Part 4 of my 
'Numeracy and Computer Literacy' series, 
linked from:

  http://www.inetarena.com/~pdx4d/ocn/cp4e.html

I'll be enhancing it from here, especially with
more graphics.

I realize I now have all the "ammo" I need to 
push my curriculum reform agenda.  Yay!

I'm going to unsubscribe from this list and go 
back to the math teacher lists from whence I came.  

Certain faculty members I know are going to go 
gaga for this stuff.  Python rules!

G'night ya'll and pleasant dreams.  I'll be checking 
posts through the archives from time to time.

Thanks especially to Tim Peters for technical support,
and to Guido for the exchange of links.

Kirby Urner
Curriculum writer
Oregon Curriculum Network
http://www.inetarena.com/~pdx4d/ocn/




From Fredrik Lundh" <effbot@telia.com  Sat Mar  4 18:07:41 2000
From: Fredrik Lundh" <effbot@telia.com (Fredrik Lundh)
Date: Sat, 4 Mar 2000 19:07:41 +0100
Subject: [Edu-sig] Re: "Killer Apps" vs. CP4E
References: <200003031653.LAA27822@brocade.nexen.com> <3.0.3.32.20000303152454.03251a5c@pop.teleport.com>
Message-ID: <00c001bf8604$893b0180$34aab5d4@hagrid>

> >(fast interactive rendering via DirectX or OpenGL, high-quality
> >raytracing for output, and a built-in Python interpreter...  but
> >not exactly free, of course...)
> >
> ></F>
>=20
> <SOAP BOX>

since I don't understand why my pointer to Caligari's 3D
application resulted in this kind of response, I hereby pro-
mise to remain silent in the future.

apologizing for the inconvenience, etc /F



From siegel@eico.com  Sat Mar  4 18:32:40 2000
From: siegel@eico.com (Arthur Siegel)
Date: Sat, 4 Mar 2000 13:32:40 -0500
Subject: [Edu-sig] Caligari's 3D
Message-ID: <NDBBIAEANKEFIFOFMJHPIEAKCBAA.siegel@eico.com>

I looked at Caligari in an early release  - and either before
it had Python scripting or before I knoew anything of Python.

But what I have found generally of the high end 3D modellers is that you can
define objects willy-nilly, but not relationships that stick, and certainly
not if you have any interest in working with planar concepts.

Could I define with Caligari and its Python scripting a plane determined by
three points, a sphere, and the circle that is determined if and when the
sphere and plane
intersect?

Or that kind off thing.

And yes the post was right on point.

And yes it was good to know you are taking an interest in the
sometimes mad proceedings.




From siegel@eico.com  Sat Mar  4 18:59:51 2000
From: siegel@eico.com (Arthur Siegel)
Date: Sat, 4 Mar 2000 13:59:51 -0500
Subject: [Edu-sig] 3D rendering
Message-ID: <NDBBIAEANKEFIFOFMJHPMEAKCBAA.siegel@eico.com>


Sorry for the successive posts -

But of high relevance to the issue of high quality 3D rendering, with Python
scripting built-in from the ground-up, and with GPL licensing is the work
being done on the Pretty Poly Editor.


http://prettypoly.sourceforge.net


ART



From smorris@nexen.com  Mon Mar  6 15:57:54 2000
From: smorris@nexen.com (Steve Morris)
Date: Mon, 6 Mar 2000 10:57:54 -0500 (EST)
Subject: [Edu-sig] Re: "Killer Apps" vs. CP4E
In-Reply-To: <00c001bf8604$893b0180$34aab5d4@hagrid>
References: <200003031653.LAA27822@brocade.nexen.com>
 <3.0.3.32.20000303152454.03251a5c@pop.teleport.com>
 <00c001bf8604$893b0180$34aab5d4@hagrid>
Message-ID: <200003061557.KAA00745@brocade.nexen.com>

I wish there was less taking of offense on this list. Different people
want to get different things. Kirby in particular is an "on the
ground" type of contributor adding what he things is important. (I
love his numericy pages, check them out.) This means he has well
focused ideas he would like to see come out of this list and CP4E. He
is apparently afraid that the grandious ideas will dilute the effort
resulting in little accomplishment.  On the other hand he is just one
of many. For example I think he sets the goals too low and we have
room to explore many approaches.

However I fail to see why he shouldn't be allowed to present his
opinion and try to convince the rest of us without everyone taking
offense apparently merely because he disagrees with them. He and I
have had occasion to disagree on several things so far. I don't have
less respect for him because of it and I don't believe he has less
respect for me or anyone else that disagrees with him. So what's the
problem?

This is a subject that is bound to have plenty of disagreement among
intelligent people of good will. Lets please assume that each of us is
one of these intelligent people of good will having these inevitable
disagreements and chill out a little.

Just a suggestion ;-)


From frank@oreilly.com  Wed Mar  8 06:09:40 2000
From: frank@oreilly.com (Frank Willison)
Date: Tue, 07 Mar 2000 22:09:40 -0800
Subject: [Edu-sig] Interview with Jeffrey Elkner and students
In-Reply-To: <00020514413601.02613@tpaine.yorktown.arlington.k12.va.us>
References: <NDBBKPLDKLMJNNGNFMGFCEGICIAA.hank@prosysplus.com>
 <NDBBKPLDKLMJNNGNFMGFCEGICIAA.hank@prosysplus.com>
Message-ID: <4.2.0.58.20000307220546.0095af00@ruby.ora.com>

The interview with Jeff Elkner of Yorktown High School and two of his 
Python-learnin' students (Lex Berezhny and Virginia Hafer) is up on the 
O'Reilly web site (www.oreilly.com/frank/).

Thanks to Allen Noren and his O'Reilly web team for turning this project 
around in less than a day.l

Frank


From Alessandro.Bottoni@think3.com  Fri Mar 10 09:08:52 2000
From: Alessandro.Bottoni@think3.com (Alessandro Bottoni)
Date: Fri, 10 Mar 2000 10:08:52 +0100
Subject: [Edu-sig] Python as an educational language (Long)
Message-ID: <6D8A17398E28D3119F860090274DD7DB498550@pces.cadlab.it>

[Re-sending here, on suggestion, after a first post to the main python
mail-list]

I would like to hear the opinions of the Pythonist about the use of Python
as "educational language".

I was asked to give a basic course on computer programming to a small group
of windows users. The aim of the course is to give some programming
capabilities to these "power users", allowing them to create their own tools
and perform some batch processing. There is no intention of teaching
unrequired programming philosophy but it would be appreciated if I was able
to give the participants a good "programming habit", that could be useful
later for learning C++ and Java programming. Given this
pragmatic/evolutionary approach, I have the possibility to choose the
language that best fit the task at hand. Of course, I would like to use
Python (guess why?). 

I think it is a good opportunity to see how Python can be used as an
"educational programming language", a type of application that Guido is
quite fond of. 

This course will last for around 75 hours (maybe less) and will be scheduled
in around 25 lessons of 3 hours each. 
Each lesson will be split in two parts: around one hour devoted to the
lecture and two hours devoted to practice.
I think to structure the course in this way:

Introduction:
Lesson 1) What I'm doing here? #  A first example of computer programming
and a few programming concepts

First Part: Programming Concepts and Tools
Lesson 2) Data Types and basic operators
Lesson 3) Flow control
Lesson 4) Accessing the File System # We need something REAL to work on...
Lesson 5) Text Files and String processing
Lesson 6) Regular Expressions
Lesson 7) Functions
Lesson 8) More functions: structured programming
Lesson 9) Modules
Lesson 10) Classes
Lesson 11) More Classes: OOP
Lesson 12) Exceptions
Lesson 13) More Exception handling: writing sound applications

Second Part: Common Programming Tasks
Lesson 14) Tips: Log files, Temporary files, Diagnostics functions,
Configuration files, CL Parameters, etc...
Lesson 15) Accessing a DataBase
Lesson 16) Handling Programs # IPC
Lesson 17) Debugging methods and tools

Third Part: Workshop
Lesson 18) Workshop Day 1: A real-world, sample application # Most likely,
an internet-related app
Lesson 19) Workshop Day 2: A real-world, sample application # Continued
Lesson 20) Building a GUI with TkInter
Lesson 21) Workshop Day 3: A real world, sample application with TKinter #
Most likely, a small e-mail client
Lesson 22) Workshop Day 4: A real world, sample application with TKinter #
Continued
Lesson 23) Using COM to access Windows applications
Lesson 24) Workshop Day 5: A real world, sample COM application # Most
likely a document-building app for Word

Conclusion: Where from here
Lesson 25) Compiled programs and the C++ language

How about this program? Too brief? Too long? Badly designed?
Any suggestion, in particular regarding the workshop exercises? 
Any comment about Python as an educational language?
Any criticism regarding this choice?

TIA
--------------------------------
Alessandro Bottoni
(Alessandro.Bottoni@Think3.com)
(alessandro.bottoni@libero.it)
Web Programmer
Think3 inc.
(www.think3.com)



From siegel@eico.com  Tue Mar 14 23:17:41 2000
From: siegel@eico.com (Arthur Siegel)
Date: Tue, 14 Mar 2000 18:17:41 -0500
Subject: [Edu-sig] New game in town
Message-ID: <NDBBIAEANKEFIFOFMJHPIEBMCBAA.siegel@eico.com>

>During my time at Waikato University I developed POVTalk (Using Python and
PyOpenGL). POVTalk is a Natural Language driven >>3D scene generator.
Basically you type commands like "create a large pink ball called bob",
"make bob bigger" and "make bob >blue", and a 3D scene is generated. A few
demo scripts are included.

>If you are interested in taking a look go to
http://homepages.ihug.co.nz/~synopsis/computing/ to donwload it.

>You may notice that the OpenGL window doesn't re-display when windows are
dragged over it. This is because the program is >waiting for input on the
command line. I want to put it into a better gui, with a better cli but
don't know where to start.

>I welcome any comments or suggests.

>Stacey Verner

Stacey posted the above today on the PyOpenGL list. Played a bit with it.
Great fun.
With Stacey's permission I pass it along here.



From fig@oreilly.com  Tue Mar 14 23:48:25 2000
From: fig@oreilly.com (Stephen R. Figgins)
Date: Tue, 14 Mar 2000 15:48:25 -0800
Subject: [Edu-sig] New game in town
In-Reply-To: Your message of "Tue, 14 Mar 2000 18:17:41 EST."
 <NDBBIAEANKEFIFOFMJHPIEBMCBAA.siegel@eico.com>
References: <NDBBIAEANKEFIFOFMJHPIEBMCBAA.siegel@eico.com>
Message-ID: <200003142348.PAA02377@rock.west.ora.com>

>>During my time at Waikato University I developed POVTalk (Using Python and
>PyOpenGL). POVTalk is a Natural Language driven >>3D scene generator.
>Basically you type commands like "create a large pink ball called bob",
>"make bob bigger" and "make bob >blue", and a 3D scene is generated. A few
>demo scripts are included.
>
>>If you are interested in taking a look go to
>http://homepages.ihug.co.nz/~synopsis/computing/ to donwload it.

This just gave me an idea.  How about a database of programming tools
and programs divided into categories and rated by complexity.

This way learners could find code that matched their interests and
capabilities.  They could tear it apart, study it, put it back
together, play with it, maybe even contribute to it.

One thing about tribal cultures that I have learned is that when a
young member of the tribe wants to go hunting, they don't give them a
toy bow and arrow, they give them fully functioning bows and arrows
suited to their size and send them out to hunt.  

In this same way, it might also be possible to have a database of open
source projects appropriate to newcomers, or perhaps even tasks in a
larger project appropriate to newcomers.  The projects would be
appropriate sized bows and arrows, but the hunting would be for real.
Welcome to the hacker tribes. 

Stephen R. Figgins
fig@oreilly.com



From siegel@eico.com  Wed Mar 15 15:48:41 2000
From: siegel@eico.com (Arthur Siegel)
Date: Wed, 15 Mar 2000 10:48:41 -0500
Subject: [Edu-sig] re: New game in town
Message-ID: <NDBBIAEANKEFIFOFMJHPKEBNCBAA.siegel@eico.com>

Stephen R. Figgins writes:

>This just gave me an idea.  How about a database of programming tools
>and programs divided into categories and rated by complexity.

>This way learners could find code that matched their interests and
>capabilities.  They could tear it apart, study it, put it back
>together, play with it, maybe even contribute to it.

Sort of a Python Gamelan. Ambitious, would be great - but I don't
think the Python communioty is up to it.

As an interested and relatively long-time observer of the scene, frankly I'm
totalling confused at what's happening.

The announcement list, I thought a key life-blood of the Python world - who
is doing
what and willing to share it - has been essentially dead for some time and
nobody seems to notice
or care.

Nothing put forward on this list has been given any serious attention by the
folks who matter.

I have a personal bone to pick with my PyGeo - whether it good or bad
software.  I maintain
strongly that it is a much more serious effort at a piece of educational
software than Alice,
which is bloated, complex from a code point of view and has no redeeming
educational value from
a functional point of view.  If the EDU-SIG moderators want to stay out of
the software "wars"
I would understand it. But if Alice is going to be put forward as a
"certified" and high-profile piece of Python
educational software I would like to better understand the criteria for
inclusion.

PovTalk, which I had nothing to do it, I think is another great starting
point for some
real, fun, concise and innvoative stuff, but it also has no credentials
behind it and will probably be ignored.

Flame, rank whatever yuo might want to call it.



From fig@oreilly.com  Wed Mar 15 17:15:48 2000
From: fig@oreilly.com (Stephen R. Figgins)
Date: Wed, 15 Mar 2000 09:15:48 -0800
Subject: [Edu-sig] re: New game in town
In-Reply-To: Your message of "Wed, 15 Mar 2000 10:48:41 EST."
 <NDBBIAEANKEFIFOFMJHPKEBNCBAA.siegel@eico.com>
References: <NDBBIAEANKEFIFOFMJHPKEBNCBAA.siegel@eico.com>
Message-ID: <200003151715.JAA06279@rock.west.ora.com>

Arthur writes: 

>Sort of a Python Gamelan. Ambitious, would be great - but I don't
>think the Python communioty is up to it.

Perhaps not.  It probably isn't a way that we are used to thinking.  A
Python Gamelan with complexity ratings would be interesting.  But more
important is probably the shift in thinking.

Something I have had to learn as a parent is how to include my
children in more of what I do.  This often means finding work
appropriate to their ability and leaving it for them to do.  That
slows me down a bit, but it helps my children discover new things and
helps along their self esteem.  They want to feel included.

While our relationship to those who wish to learn Python is not really
the same as parent's, it can be seen as a sort of mentoring thing.  It
is a challenge to think about how those new to the language, or
intermediate to the language can be included in the work.  One of the
more advanced project members could probably get it done quicker, it
may be trivial for them, leaving it may slow things down some, but in
the end, you would end up with more competent hackers.

The database idea I had would be one way of getting new people into
appropriate projects.  

>Nothing put forward on this list has been given any serious attention by the
>folks who matter.

I don't know.  I think that we are the folks who matter.  I think some
of the suggestions here have been great.  While they may not all be
something that Guido can work into CP4E, we don't have to let them
fade off into the abyss either.  

I am working with O'Reilly Network to put together a Python
Developer's Center.  I am thinking about putting together a
database for that developer's center.  Anyone out there interested in
giving me a hand with that?  I think I will start with a list of
interesting tools and projects divided into categories and rated on
what level of programmer they might be appropriate for. 

I could use your suggestions.  What code should we include?  What
kinds of ratings (besides complexity) would be useful?  An educational
value?  Openness of a project to those new to programming?  

Stephen R. Figgins
fig@oreilly.com





From faassen@vet.uu.nl  Wed Mar 15 19:32:57 2000
From: faassen@vet.uu.nl (Martijn Faassen)
Date: Wed, 15 Mar 2000 20:32:57 +0100
Subject: [Edu-sig] re: New game in town
In-Reply-To: <NDBBIAEANKEFIFOFMJHPKEBNCBAA.siegel@eico.com>
References: <NDBBIAEANKEFIFOFMJHPKEBNCBAA.siegel@eico.com>
Message-ID: <20000315203257.A28384@vet.uu.nl>

Arthur Siegel wrote:
> Stephen R. Figgins writes:
> 
> >This just gave me an idea.  How about a database of programming tools
> >and programs divided into categories and rated by complexity.
> 
> >This way learners could find code that matched their interests and
> >capabilities.  They could tear it apart, study it, put it back
> >together, play with it, maybe even contribute to it.
> 
> Sort of a Python Gamelan. Ambitious, would be great - but I don't
> think the Python communioty is up to it.
> 
> As an interested and relatively long-time observer of the scene, frankly I'm
> totalling confused at what's happening.
> 
> The announcement list, I thought a key life-blood of the Python world - who
> is doing
> what and willing to share it - has been essentially dead for some time and
> nobody seems to notice
> or care.

I think there are some technical problems with comp.lang.python.announce,
I'm not sure. It just seems to randomly show up and go away again
for people. I've never been able to find it when I looked for it.

But, we have something else you may not be aware of: the Vaults of
Parnassus. http://www.vex.net/parnassus

Click 'latest' for at least a nice list of recent Python software 
(and also info) announcements. It's a great resource.

Perhaps this could also be extended to list 'hackability' value; 
how easy it is considered to change it, how much such activities are
supported and invited by the original creators, etc. We could talk to
Tim Middleton (the guy who does the Vaults) if anyone has good ideas 
about this.

> Nothing put forward on this list has been given any serious attention by the
> folks who matter.

Perhaps the expectations are too high? Who are the folks who matter?
What could these people do to help?

I myself am currently teaching almost all my coworkers Python (and then on
to Zope); it's about 8 people. I'm creating at least a little bit of course
material for that, which anyone is welcome to. I've just started, though!
 
[snip] 
> But if Alice is going to be put forward as a
> "certified" and high-profile piece of Python
> educational software I would like to better understand the criteria for
> inclusion.

I didn't think Alice was being held forward as anything like a cool
piece of Python software with a GUI that's aimed at beginners. But I thought
Alice's aim wasn't CP4E, it was letting people play with 3d environments. 

I think the main thrust of CP4E development is currently IDLE -- the idea
is that there should be a tool that's easy enough for beginners to
use (but yet also powerful) to write Python code. You need that kind of
infrastructure in place if you want people to learn to work with programming
Python applications, I think.

I suppose I may be confused; this forum is about teaching Python and
programming in general to people, isn't it? Or is it about educational
software written in Python? I am not sure if the latter belongs on the
list, except that the process of understanding and extending such
software may help people understand programming concepts. So I'm not
entirely sure what you're talking about. I haven't looked at these
packages yet. 

Perhaps the Edu-SIG needs refocussing though -- currently it's unclear
in which direction we're moving, I think. There are various directions:

* create non-software course materials

* make it easier to program in Python (IDLE, some simple libraries, perhaps?)

* make software that's fun to extend and hack on, so students learn to
program by doing it.

The IDLE track is covered by idle-dev, though it could probably use more
feedback from educational people. As far as software goes we could then
look at libraries and hackable programs. Perhaps we can decide on
developing a few, though usually in the open source world it's just
that there is one steady developer (or a core group) that goes on
developing no matter what, and then eventually a larger group of
users/developers coalesces around that when what's developed becomes
more usable.

And there it'd be nice if there was more discussion on course materials,
and the best ways to approach teaching Python. I'll post more about my
experiences some other day.

Regards,

Martijn



From siegel@eico.com  Wed Mar 15 20:42:20 2000
From: siegel@eico.com (Arthur Siegel)
Date: Wed, 15 Mar 2000 15:42:20 -0500
Subject: [Edu-sig] re: New game in town
In-Reply-To: <06053C71C50D1CF2852568A3006A989E.006A98C8852568A3@eico.com>
Message-ID: <NDBBIAEANKEFIFOFMJHPAEBPCBAA.siegel@eico.com>

Martijn Faassen writes:

>But, we have something else you may not be aware of: the Vaults of
>Parnassus. http://www.vex.net/parnassus

>Click 'latest' for at least a nice list of recent Python software
>(and also info) announcements. It's a great resource.

Good advice. Things change. The focus of python.org does appear to be
shifting.
The Vaults are a resource I and perhaps others need to pay more attention
to.
And hopefully there will be other alternatives, like the one Stephen is
discussing.

Martijn Faassen writes:

>I didn't think Alice was being held forward as anything like a cool
>piece of Python software with a GUI that's aimed at beginners. But I
>thought Alice's aim wasn't CP4E, it was letting people play with 3d
environments.

I'm not sure what Alice's aim is. The fact is one of only a few software
efforts
on the EDU-SIG page and is described page as follows:

"Alice
A 3d virtual reality system that teaches 19-year olds without
prior programming experience to write Python scripts to control interactive
3d experiences."

Alice is a monster which I don't get - and Python and 3D is sort of my
thing. What is educational about
it in any possible sense of the word? Unless you bill it more honestly as
something that provided an educational
experience for the folks who built it. Having 19-year olds (did they say
19-year olds?) play with scripting it is serious dumbing down.
An opinion.

I seem to have a lot of them.

And I honestly hope that my stating them bluntly is not an annoyance to the
list or distructive of
the progress of EDU-SIG.

Martijn Faassen writes:

>And there it'd be nice if there was more discussion on course materials,
>and the best ways to approach teaching Python.

Hopefully. An alternative to me yakkking would be welcome by all, including
me.



From wesc@alpha.ece.ucsb.edu  Wed Mar 15 21:48:15 2000
From: wesc@alpha.ece.ucsb.edu (Wesley J. Chun)
Date: Wed, 15 Mar 2000 13:48:15 -0800 (PST)
Subject: [Edu-sig] *2* SF Bay Area Python education events
Message-ID: <200003152148.NAA06309@alpha.ece.ucsb.edu>

1. BayPIGgies (San Francisco Bay Area and Silicon Valley
    Python Interest Group) monthly meeting... if you're in
    the Northern California area tonite, you can come to
    Mountain View, CA to hear Guido give his talk on CP4E
    as well as Python Futures and Q&A:

    When:   (today) Wednesday, March 15, 2000, 8pm

    Where:  Mountain View, CA

    Who:    special guest speaker, Guido van Rossum,
	    creator of Python!

    What:   Guido will discuss the following topics: 

	    1. Computer Programming For Everybody 
	    2. Python Futures (1.6, etc.)
	    3. Python Q&A 

    Info:   for more, see the BayPIGgies website:
	    http://www.baypiggies.org/

	    public transit directions and map can be
	    found at: http://linuxmafia.com/bale/


2.  another UC Santa Cruz Extension Python course in Silicon
    Valley, Spring quarter 2000:  speaking of teaching/learning
    Python...

    for those of you interested Python training and are able
    to make it to Northern California, due to the popularity
    of its first Python course, UC Santa Cruz has decided to
    offer this course again in Silicon Valley, so if you know
    anyone who wishes to get up-to-speed quickly on Python or
    those self-taught who perhaps would like to fill-in any
    missing gaps, this would be a good opportunity.

    the maximum enrollment is set at 50, and their rate ($400)
    is pretty reasonable, being a public institution and all.
    (shameless plug:  i am also available to contract for
    corporate training services too if there too many people
    from your company or if you're too far away!)

    the website below is not 100% accurate but close enough!


    When:   Tuesdays, April 4 - May 30, 2000, 6:30pm-9:30pm

    Where:  Sunnyvale, CA

    Who:    Wesley Chun

    What:   intro to Python, data types, statements, errors
	    and exception handling, functions and modules,
	    OOP and classes, execution environment, regular
	    expressions, network/Internet progamming, inter-
	    facing to your operating system, creating GUIs
	    with Tkinter, intro to JPython, and Extending
	    Python

    Info:   for more info, see the UCSC Extension
	    website for the next Python course:
	    http://www.ucsc-extension.edu/knowledge_is_timeless/qd/softlist.taf?function=detail&X_Number=X444.3


From zev@mail.ru  Fri Mar 17 21:59:17 2000
From: zev@mail.ru (zev@mail.ru)
Date: Fri, 17 Mar 2000 21:59:17 +0000
Subject: [Edu-sig] (no subject)
Message-ID: <1916.000317@mail.ru>

Hello edu-sig,

  i have large practice in solving one problem...

  python dosn't support cyclic import/// i mean you can't write
  something like this:

#p1.py
import p2
def pp1():
  print 'yep'
p2.pp2()

#p2.py
import p1
def pp2():
   p1.pp1()



so .. even now i cant understand why it doesn't work
on the one hand PC commands admitted cyclic import/including
on the other hand why dont use this commands in Python??

actually i solve this problem ... but i spend 3 weaks solving it...

please comment me
-- 
Best regards,
 zev                          mailto:zev@mail.ru




From siegel@eico.com  Sun Mar 19 17:37:22 2000
From: siegel@eico.com (Arthur Siegel)
Date: Sun, 19 Mar 2000 12:37:22 -0500
Subject: [Edu-sig] CIGS
Message-ID: <NDBBIAEANKEFIFOFMJHPCECICBAA.siegel@eico.com>

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01BF919F.DFCF5E00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Attached is some information I sent to

http://forum.swarthmore.edu/dynamic/

informing them of my own activities and that of CP4E.

The general efforts at forum.swathmore.edu are making its (good) influence
felt.
My 9 year-old nephew is actively involved with one of their programs . I'm
not
sure how he found it.

ART

------=_NextPart_000_0000_01BF919F.DFCF5E00
Content-Type: text/plain;
	name="PyGeo.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="PyGeo.txt"

I have a contribution-in-progress, I hope, to the world of dynamic =
geometry software. =20

It is written in Python  http://www.python.org/ and rendered by OpenGL.  =


I built it primarily to support my own efforts to visualize and =
understand=20
on a more intuitive level Projective Geometry concepts, but have come to =
see=20
it as having broader potential.

I believe in concept, design at least - it brings the possibilities of =
dynamic
geometry software in education a notch forward.

The potentially most innovative thing about PyGeo is the use of Python - =

a full featured OOP language, but with a simplified syntax.  The main =
developer=20
behind Python is currently devoting his energies to focus Python's =
potential as=20
a first programming language - a project called CP4E (Computer =
Programming for Everybody).=20
The project (see at http://www.python.org/sigs/edu-sig/ )might be of =
general interest to the=20
Math Forum and I encourage you to check it out.

Using Python in creating dynamic geometry software allows for a better =
integration of=20
synthetic and analytic concepts - the analytics in the algorithms =
driving the software
are readily exposed, given a basic grasp of OOP. In fact a presentation =
of the basics of OOP=20
could (and should) be part of a curriculum that used PyGeo. =20

All this assumes, by the way, that the potential for performance =
optimization is purposefully=20
sacrificed in the interest of coding transparency.

I think it alls ties together wonderfully and can't help but be excited =
about it.

I don't see why in its simplest form it could not be useful at the =
elementary school level.=20
On the other hand I am exploring college level concepts with it.

My own background is liberal arts.=20

I know from my own education that traditional geometry and symbolic math =
were never really tied=20
together for me. From my liberal arts perspective, I believe that the =
importance of developing this=20
integration transcends the subject matter of math (as narrowly defined). =
Which is probably why the=20
entire field of dynamic geometry is so exciting to me - and why I am =
excited about the possibility of
 contributing to it.

At this point PyGeo is all my own effort (derived and inspired, without =
question, from the efforts of
others), and there are certainly limitations in the design and =
execution.=20

But it is fully OpenSource. I am hoping to interest folks in getting =
into it and improving it.

You can check out a page I did about it at =
http://courses.soe.umich.edu/pygeo/

I hope to redo the page and put the distribution in better shape before =
I try to give it much exposure. =20
At this point I mostly wanted to give a heads up and see if you might =
have any preliminary comments, ideas.



------=_NextPart_000_0000_01BF919F.DFCF5E00--



From gherman@darwin.in-berlin.de  Tue Mar 21 18:48:13 2000
From: gherman@darwin.in-berlin.de (Dinu C. Gherman)
Date: Tue, 21 Mar 2000 19:48:13 +0100
Subject: [Edu-sig] SEI's Guidelines for Software Eng. Education
Message-ID: <38D7C3ED.6AA37F52@darwin.in-berlin.de>

Hello,

I found this two days ago while surfing the SEI web site
and think it might be of interest to some people in this
group. Although definitely aiming at higher academic edu-
cation the SEI (Software Engineering Institute at CMU)
addresses many concerns in the introduction below (as well
as in other parts of the document) that match very  well 
with the motivation behind CP4E as I understand it.

Recognizing this I wonder if there would be any reason to 
get in touch with SEI, or maybe not, given the fact (well,
rather my own estimate) that they are better known for a 
solid, systematic, academic, engineering-like approach to 
software development than for one more based on soft qua-
lities like playing, exploration, self-discovery?

In fact, I wouldn't be surprised if SEI would discourage
people from using script languages for 'serious program-
ming'. Anybody having experience/evidence backing this 
opinion, or the contrary of it?

Regards,

Dinu

-- 
Dinu C. Gherman
................................................................
"The thing about Linux or open software in general is that 
it actually tries to move software from being witchcraft to 
being a science," [...] "A lot of the programs you see today 
are actually put together by shamans, and you just take it and 
if the computer crashes you walk around it three times... and 
maybe it's OK." (Linus Thorvalds, LinuxWorld 2000, NYC)



Guidelines for Software Engineering Education Version 1.0

http://www.sei.cmu.edu/publications/documents/99.reports/99tr032/99tr032abstract.html


Introduction

Into the foreseeable future, software will play an in-
creasingly important and central role in all aspects 
of daily life. The number, size, complexity, and app-
lication domains of programs being developed will grow 
dramatically. Unfortunately, there are serious problems 
in the cost, timeliness, and quality of development of 
many software products. The code in consumer products 
is doubling every two years; it is almost the norm for 
software projects to overrun their planned cost and 
schedule. Many large-scale development projects are 
never completed, and many of those completed do not 
meet the user requirements and are of poor quality [...]. 
These issues have placed an increasing demand for soft-
ware developers who are equipped not only to deal with 
the scientific and technical aspects of computing, but
for those who have professional education and prepara-
tion for the practice of software engineering [...]. 
This includes practice related to use of software pro-
cesses, measurement and analysis, front-end development 
methods, quality engineering, software maintenance, 
testing, and working as part of a team. Unfortunately,
too few academic programs offer curricula that focus on 
this type of education. The solution to this problem 
depends heavily on the ability of faculty to redesign 
and implement curricula that not only emphasize computer 
science, information science, and technology, but also
focus on the "practice" of software engineering (SE) and 
include the equally critical people and process issues. 
The main purpose of these Guidelines is to provide 
assistance to faculty in the design and development of 
programs in software engineering and related curricula.


From gward@cnri.reston.va.us  Tue Mar 21 19:04:22 2000
From: gward@cnri.reston.va.us (Greg Ward)
Date: Tue, 21 Mar 2000 14:04:22 -0500
Subject: [Edu-sig] Software Engineering for everyone?
Message-ID: <20000321140422.C1326@cnri.reston.va.us>

[oops, sent this to Dinu personally -- meant to send it to the list,
 here 'tis]

On 21 March 2000, Dinu C. Gherman said:
> I found this two days ago while surfing the SEI web site
> and think it might be of interest to some people in this
> group. Although definitely aiming at higher academic edu-
> cation the SEI (Software Engineering Institute at CMU)
> addresses many concerns in the introduction below (as well
> as in other parts of the document) that match very  well 
> with the motivation behind CP4E as I understand it.

Remember, the "E" stands for "everyone", and full-bore,
industrial-strength "software engineering" is most definitely not for
everyone.

(Yes, it *is* something that needs to be taught to prospective
professional programmers as part of their undergraduate degree: the
ability to write solid, maintainable code is at least as essential as
the ability to understand quicksort.  Good coding practices are
certainly the first step on the road to full-scale "software
engineering", and good coding practices are something that CP4E should
emphasise.  But there's no need to go all the way -- after C++, the best
way to discourage people from programming is probably forcing them to do
requirements analysis or write test suites.  *yaawn*)

        Greg
-- 
Greg Ward - software developer                    gward@cnri.reston.va.us
Corporation for National Research Initiatives    
1895 Preston White Drive                           voice: +1-703-620-8990
Reston, Virginia, USA  20191-5434                    fax: +1-703-620-0913


From gherman@darwin.in-berlin.de  Thu Mar 23 11:05:23 2000
From: gherman@darwin.in-berlin.de (Dinu C. Gherman)
Date: Thu, 23 Mar 2000 12:05:23 +0100
Subject: [Edu-sig] Software Engineering for everyone?
References: <20000321140422.C1326@cnri.reston.va.us>
Message-ID: <38D9FA73.DAC8FDFF@darwin.in-berlin.de>

Greg Ward wrote:
> 
> (Yes, it *is* something that needs to be taught to prospective
> professional programmers as part of their undergraduate degree: the
> ability to write solid, maintainable code is at least as essential as
> the ability to understand quicksort.  Good coding practices are
> certainly the first step on the road to full-scale "software
> engineering", and good coding practices are something that CP4E should
> emphasise.  But there's no need to go all the way -- after C++, the best
> way to discourage people from programming is probably forcing them to do
> requirements analysis or write test suites.  *yaawn*)

I would consider this an interesting interpretation of the
concept of "extreme programming" ;-), but this is certainly 
not what you mean, programming without testing, without know-
ing what you're trying to accomplish, is it? 

The difference is a matter of scale and formalism, it is not
one of not doing something on one level (say, your homework 
at school), but on another (say, a phone billing system).
Moreover, drawing the borderline might not be always easy to 
do.

> Remember, the "E" stands for "everyone", and full-bore,
> industrial-strength "software engineering" is most definitely 
> not for everyone.

I never forgot that. I just noticed that there are papers 
being written at SEI that replicate some of the motivation
behind CP4E as you can read in my original posting.

> Dinu Gherman wrote:
> 
> > Recognizing this I wonder if there would be any reason to 
> > get in touch with SEI, or maybe not, given the fact (well,
> > rather my own estimate) that they are better known for a 
> > solid, systematic, academic, engineering-like approach to 
> > software development than for one more based on soft qua-
> > lities like playing, exploration, self-discovery?

The paragraph above which you have not cited, simply asks if 
it would be reasonable to approach SEI? Then, I added some 
concerns originated in SEI's "industrial professionalism" 
image. I asked if there was anybody having contacts already.

Now I'm adding that SEI is most likely sitting on a huge pile
of money and might be willing to know how to spend it more
effectively. The question is, do we have something to offer?
I would firmly say: yes, we do! CP4E tries to raise the bar
for "everybody" (whatever that will mean in practice) to be-
come more literate in expressing some of his or her problems
in terms of programs/scripts/algorithms -- "in software", so 
to say.

There's no reason to believe this will do any harm to SEI's
goals of getting companies and individuals to produce better
software systems, but there is *every* reason to believe that
CP4E will actually help them achieve their goals more quickly!

In this light I find it hard to believe there haven't been
contacts already. This is all I wanted to say.

Kind regards,

Dinu

-- 
Dinu C. Gherman
................................................................
"The thing about Linux or open software in general is that 
it actually tries to move software from being witchcraft to 
being a science," [...] "A lot of the programs you see today 
are actually put together by shamans, and you just take it and 
if the computer crashes you walk around it three times... and 
maybe it's OK." (Linus Thorvalds, LinuxWorld 2000, NYC)


From fig@oreilly.com  Thu Mar 23 18:04:04 2000
From: fig@oreilly.com (Stephen R. Figgins)
Date: Thu, 23 Mar 2000 10:04:04 -0800
Subject: [Edu-sig] Learning and Doing
Message-ID: <200003231804.KAA22524@rock.west.ora.com>

I ran into this quote this morning:

  A common and mistaken idea hidden in the word "learning" is that
  learning and doing are different kinds of acts.  Thus, not many
  years ago I began to play the cello.  I love the instrument, spend
  many hours a day playing it, work hard at it, and mean someday to
  play it well.  Most people would say that what I am doing is
  "learning to play the cello."  Our language gives us no other words
  to say it.  But these words carry into our minds the strange idea
  that there exist two wvery different processes: (1) learning to play
  the chello; and (2) playing the cello.  They imply that I will do
  the first until I have completed it, at which point I will stop the
  first process and begin the second; in short, that I will go on
  "Learning to paly" until I "have learned to play," and that then I
  will begin to "to play."

  Of course, this is nonsense.  There are not two processes, but one.
  We learn to do something by doing it.  There is no other way.  When
  we first do something, we probably will not do it well.  But if we
  keep on doing it, have good models to follow and helpful advice if
  and when we feel we need it, and always do it as well as we can, we
  will do it better.  In time, we may do it very well.  This process
  never ends.

  John Holt
  Instead of Education 

While not specifically about CP4E, it reminded me of my own direction
in education and python which is providing new programmers
opportunities to do programmming, find good models, and people to
provide helpful advice when needed.  I want to weave together
something like the pattern "Network of Learning" as described by
Christopher Alexander in A Pattern Language.

  Instead of the lock-step of compulsory schooling in a fixed place,
  work in piecemeal ways to decentralize the process of learning and
  enrich it through contact with many places and people all over the
  city: workshops, teachers at home or walking through the city,
  professionals willing to take on the young as helpers, older
  children teaching younger children, museoums, youth groups
  travelling, scholarly seminars, industrial workshops, old people,
  and so on.  Conceive of all these situations as forming the backbone
  of the learning process; survey all these situations, describe them,
  and publish them as the city's "curriculum"; then let students,
  children, their families and neighborhoods weave together for
  themselves the situations that comprise their "school" paying as
  they go with standard vouchers, raised by community tax.  Build new
  educational facilities in a way which extends and enriches this
  network.

To this end, I am sketching out some ideas for a database of
information on opportunities to program, good models, and people to
provide helpful advice or act as masters to apprentices.  I hope to
have enough things together to launch the database in mid April.

For the opportunities to program, I am thinking of something like
classifieds, people looking for assistance and willing to act as the
master on a certain project.  

For good models I am thinking of something like Amazon's review of
books, but applied to code, tools, libraries, tutorials, etc.. 

I will post some more specifics next week.  I still need to flesh it
out a bit more. 

Stephen









From smorris@nexen.com  Thu Mar 23 18:36:32 2000
From: smorris@nexen.com (Steve Morris)
Date: Thu, 23 Mar 2000 13:36:32 -0500 (EST)
Subject: [Edu-sig] Learning and Doing
In-Reply-To: <200003231804.KAA22524@rock.west.ora.com>
References: <200003231804.KAA22524@rock.west.ora.com>
Message-ID: <200003231836.NAA15587@brocade.nexen.com>

Stephen R. Figgins quotes:
 > 
 >   Of course, this is nonsense.  There are not two processes, but one.
 >   We learn to do something by doing it.  There is no other way.  When
 >   we first do something, we probably will not do it well.  But if we
 >   keep on doing it, have good models to follow and helpful advice if
 >   and when we feel we need it, and always do it as well as we can, we
 >   will do it better.  In time, we may do it very well.  This process
 >   never ends.
 > 
 >   John Holt
 >   Instead of Education 

In this case (as usual) I find John Holt just a little cutsy. What he
says is true in a sense but a little misleading. In our complex world
the distinction between learning and doing is useful but largely
distinguished by intent. John makes a philosophical point which is
less useful in practice. By definition any action we take is "doing"
something. Reading a text book is "doing" something. This is a
spurious and not useful definition of "doing."

Here are some contrary examples.

When I learned valences in highschool I was learning chemistry but not
doing it.

I learned realivity by reading a physics book and then solving
problems. I learned both by reading AND by doing. However I could
never have solved problems in relativity without first "learning" by
reading.

When I do something seldom I technically learn something each time I
do it but frequently this is just refreshing something I forgot. It is
not clear that there is net learning in this case.

I learned about the evils of genocide by reading history and current
events. I have never felt the need to "do" it to learn it.

I could teach someone to play a perfect game of tic tac toe by getting
them to memorize a set of rules but never letting them play a single
game. If there memorization skills are good enough they would never be
beaten when they did start playing.

There are many (most?) subjects that are so complex that there must be
an initial phase where you are only learning. When you first learn how
to hold a cello, how to hold the bow, how to sit, how to finger, how
to stroke; at this initial phase you could hardly be considered to be
playing the cello.

There are (at least) two kinds of learning, transferring knowledge and
acquiring skill. John's real point is that "doing" is often the most
valuable way of learning skills. When he says that there is no
difference between the process of learning and the process of doing I
contend he is playing with semantics.


From infonuovo@email.com  Fri Mar 24 21:32:27 2000
From: infonuovo@email.com (Dennis E. Hamilton)
Date: Fri, 24 Mar 2000 13:32:27 -0800
Subject: [Edu-sig] CyberSmiths Progress II - On to QBasic?
In-Reply-To: <NDBBKEGCHLLCCFMJKMIHGENADAAA.infonuovo@email.com>
Message-ID: <NDBBKEGCNONMNKGDINPFOECCDEAA.infonuovo@email.com>

I had so much fun relating my 35-year-old son Doug's initial experiences
with Python and me as a tutor, that I owe you a follow-up.

There are four things I want to add by way of progress report and memoir:

A.	What happened in our subsequent attempts at Python.

B.	What Doug has since done on his own.

C.	What I have to say about that.

D.	What I Care About

A.	CYBERSMITHS AT THE BRINK

[The CyberSmiths are what my son Doug has called the two of us, appealing to
the notion of a blacksmith's son apprenticing to his father.  I am touched
by that and not about to quibble with the appropriateness of the term.]

	As the result of my previous report on our experiences, I received some
great leads to tutorials for beginners.  I downloaded and printed a couple
of the on-line versions and made them available to Doug.  He also stumbled
in "Learning Python," but he started to get some benefit out of
"Introduction to Hacking" and more practice.

	I got him to try an edit-run process using the MS-DOS edit utility that
comes with Win98, and python as a console application under 4DOS.

	We tried some more extensive examples and the following occurred:

	1.	He began to see more possibilities with interactive applications (e.g.,
ask questions, do things based on the answers, etc.)
		He noticed what was convenient and inconvenient, and appeared ready to
discover how to make little programs more useful, by having them repeat
rather than have to be rerun each time..

	2.	He had a big insight about the difference between writing and filing a
program and running/interpreting the program.  That is, he began to see the
separation between description or creation and then active use.  I could
tell this was a pretty tenuous thing, but it is of course pretty fundamental
to what will come later.

	3.	Before he tired in our final session he was stopped at an interesting
place.  It was the use of f(), the notation we are now all so accustomed to
that we don't see anything weird about it.  Doug has been working himself
through college algebra using computer-based training courses of one kind an
another -- it is one of the things he has found valuable about computers and
about the Internet.  But he wasn't ready for f and f().
	He stopped at that point.  I was excited to think that we might, in a
session or two when we next got together, take the difference between
mention and use (and the different ways that comes up in using computers) to
a level where he would get why this kind of unfamiliar notation and
preoccupation is so important in how computers operate.

B.	ENTER THE SERPENT

Well, yesterday I had an on-line messaging session with Doug and learned
that he'd obtained a book that introduces programming via QBasic and then
branches out from there.  You got it, QBasic.  I actually have a copy of
that software lying around, but not one that is designed for Win32 long file
names and Fat32 drives.

	Talk about a shattering experience!

	Well, I get to take my own advice about being tolerant and patient.

	So I checked around on where I might find QBasic and gave him some tips on
using it.  Actually, it and the MS-DOS text editor are both CUA applications
that have pretty nice Help and other information.  A nice thing about QBasic
is that there is a separate immediate-mode window, at the bottom of the
screen, and then an edit window in most of the remaining screen.  I mention
that only because it may help Doug to distinguishing something about
edit-run-save-load approaches versus do-it-and-forget-it mode.  I don't know
what QBasic does if you launch it with a filename in the command line -- I
suspect it does not do what the Python processor does under the same
conditions.  These are more things for me to observe around how Doug is
teaching himself about computing and programming.

	I even sent him a Zipped package of the program that I had been saving just
in case I might ever want to install it again.

	I think the most telling aspect of this journey is best expressed in Doug's
own words, from an E-mail I received this morning:

	"Thanks for the email on QBASIC.  I found it kind of complicated so I
looked in the book I have to see where they thought QBASIC is in Windows and
it happens that there is a version on the Windows 98 setup disc so I
installed it using there instructions.  The book I have is written in a very
simple way which I prefer cause I'm so new to this and I don't want to give
up on programming.  In fact I'm getting really excited about it thanks to
this book."  [Doug and I have the same habit of interchanging words like
their and there, two and too and to.]

	So I will go look at my Windows 98 install disks and see if the QBasic
there is more Windows and Fat32-friendly than the version 1.1 I have been
holding onto.

	From this I see I mentioned things in my E-mail that were deeper than his
understanding, so he found another way to satisfy his itch.  The gratifying
part is that he isn't giving up.  I actually recommend the old books on
basic (how to do tiny interactive games, other little tasks that are
self-contained and easily understandable outside of the context of computer
programming and software) for people who want something to practice with.  I
can't wait to see what Doug produces in QBasic.  There may then be an
opportunity to then learn more about Python by comparative example.

	It is difficult for me to realize that I speak at a level that requires an
understanding the people I am speaking to don't have.  For what I have to
offer to be accessible to someone else, it is going to take a great more
discipline to put myself in the other's shoes and to accept their experience
of the matter.  So I am going to have to be more generous and patient in
having my son train me in what I have long forgotten -- what it was like to
not know anything about computers and from there develop mastery of software
and computer science.

C.	THANK YOU LUDWIG

I am not distressed about Doug using QBasic, or any other form of Basic,
though I think ones closer to the original Dartmouth Basic are the most
ideal for this kind of teething.  I don't think it will be valuable for him
to start using Peek and Poke and In and Out commands for direct
input-output, but I think this can be an useful way to deal with some
fundamentals.  And then it will become time to learn something else.  I
think learning more than one computer language is an important part of
learning what programming languages are about, so I am not fearful that this
is an invalid experience for Doug.  (I recommend that people develop a
mastery level of at least three noticeably-different computer languages. I
support and argue for the continued use of a fictitious machine in the Art
of Computer Programming because it assures that people will be exposed to at
least two computer languages that way.)

	From time to time I run into a translation of a famous statement.  It goes
like this:

		6.54 My propositions are elucidatory in this way: he who understands me
		finally recognizes them as senseless, when he has climbed out
		through them, on them, over them.  (He must so to speak throw away
		the ladder, after he has climbed up on it.)

I am reminded of Kirkegaard who spoke on how we get to a particular level in
our lives using particular means, but those are not the means that will take
us to the next level.  I watch 10-year-old grand-nephew Jake struggle with
mastery of arithmetic and wonder if he will be practiced enough when he is
asked to suspend his approach to it and take a fresh look via algebra and
trigonometry.  Yet I counted on my fingers under the desk just as he does,
and there did come a time when I did that no longer.  I still write my
carry-amounts at the top of addition columns though.  And then what happens
when knowledge expressed in algebraic terms is suspended and recreated using
the calculus?  And then shall we suspend that and learn about real functions
and ultimately about computational/constructive objects and their
limitations?  And rediscover arithmetic through the eyes of Peano, Frege,
and Russell?  A journey up many ladders as part of a promising and perhaps
unending developmental progression.  It is hard to remember what it was like
when I didn't have my latest ladder.  It is even more difficult to
anticipate what ascending the next ladder will require me to give up, even
if only for a time!

	In his Nobel lecture, Richard Feynman pays homage to a notation that he
once developed and that gave him purchase on an important area in physics.
But he had since retired that particular notation because it did not support
the models he needed to explore for the areas that opened up afterwards.
Einstein was also a master of notations for bringing tractability to
difficult problems.

	As a self-taught student of symbolic logic, I could work through early
chapters of Principia Mathematica and other books, but I was completely
stopped on modus ponens, the fundamental principle of inference.
[Basically, modus ponens is the principle that given that *a*, and given
that *a implies b*, one can infer that *b*.]  It was clear to me, from
writings of Quine and others, that there was some difficulty with modus
ponens, but I couldn't even tell what modus ponens was, or how it worked,
let alone appreciate the difficulty.  I had that definition and other
versions of it in front of me, and I couldn't get it.  It am amazed how much
of symbolic logic I could get some grasp of without grokking modus ponens.
This went on for about 5 years, from when I was 19 to around 24.  I also had
a copy of a treatise on "Elementary Formal Systems" and I could do all right
in the first (introductory) chapter, but I got stopped around modus ponens
pretty early.    It so happened that a coworker of mine, a concert pianist
by training, knew the author of the book.  So I meet Raymond Smullyan at his
home on Manhattan, and my friend introduces me as a coworker who is very
bright and knowledgable and has Smullyan's book.  I am embarassed and not
feeling so bright and knowledgable, knowing that I haven't mastered modus
ponens or gotten past the bare introduction of "Elementary Formal Systems."
The conversation is awkward, and Raymond shows me his study and that he
corresponds with people I am familiar with by name who are working in the
foundations of computer science.  I finally get over my dumbfoundedness
enough to tell professor Smullyan about my difficulty with modus ponens.  He
goes to the chalkboard in his study and draws the truth table for the
implication proposition of logic.  He carefully and simply takes me through
the principle.  And I see it.  It is perfectly, beautifully clear in that
moment and forever after.  I have never forgotten it.  And that was a
*really* big ladder to have climbed.  It took maybe 5 minutes.  Probably the
biggest part was being unwilling to continue in ignorance and asking for
help when this marvelous opportunity became available.   It was right up
there with having the nerve to ask my wife out, though it took me much
longer to have that much mastery of myself.

	One of the most profound moments in my early career as a young software
developer came in the Summer of 1961 when I happened across issues of the
Communications of the ACM in the stacks of the Seattle Public Library.  I
opened the Report on the Algorithmic Language ALGOL 60 and was enthralled to
see a programming language in what seemed to be perfect description in 14
pages of typeset text and examples.  (I could completely get it even though
I hadn't mastered modus ponens yet, too.)  We now know it wasn't all that
perfect, or complete, but the effort to produce it and exploit it was the
launchpad for an amazing explosion and development of a discipline that we
dared to call computer science.  Treatment of formal languages is perhaps
not so singularly central these days, but it was an invaluable ladder.

	The Algol 60 report was prefaced with the following statement (in the
original German):

	What we cannot speak about we must pass over in silence.

		-- Ludwig Witgenstein: Tractatus Logico-Philosophicus

I have no idea what the authors of the Algol 60 report had in mind that led
them to choose this quotation.  It was many years later (and long after I
had a copy of the full text, unread) before I noticed that this often-quoted
final line of Witgenstein's "Tractatus" was preceded by the paragraph 6.54
quoted above.


D.	WHAT I CARE ABOUT

I have worked with computers almost my entire life.   And now my cellular
phone has more computing power than the first computer I actively
programmed, and my desktop system has more computing power than existed in
the entire world shortly before I started.  I have been fascinated by the
elusive qualities of computers that has them be so powerful while so
obviously limited.  That started when high-school classmates and I struggled
with ancient issues of Scientific American that proposed how we could build
a tiny machine of our own, called Simple Simon, that exhibited everything
there is about computing.  It was all an enchanting mystery and, at first,
completely impenetrable.

	I love exploring computation and the power of computing (and even more, the
magnificent limitations) for its own sake.  But I don't think I could have
sustained a 40+ year career around software development if that was all
there was to it.  There is also something elusively fascinating about our
relationship to computers and how difficult it is to comprehend them and
have the software we provide for them be genuinely useful to people.  I
think most of us think there is something valuable here, and we want to
convey that value to others, contributing something useful and lasting.

	Yet so many computer software projects fail, so many successful ones (that
ship) are found to have been misguided in some way.  It pains me, not only
in my own experience but in watching young developers, as obsessive as I
was, be frustrated by their contributions ultimately not being fruitful.

	I have recently been exploring the proposition that "software sucks."  And
looking for ways to make software and computers even more useful and
supportive in what people are up to.  I can think of no better perspective
on learning about programming than this recent statement on software in
general:

	"Learning to use software should be as easy as learning
	the way around a new office.  A little benign exploration,
	a couple of interesting side trips, a fortuitous meeting
	in the hallway, this is how we get oriented in real life.
	We should expect nothing less from our software.  The
	user should be reassured at every step and generously
	rewarded for his curiosity.  In today's information age,
	creativity, excitement, and a sense of adventure are more
	important, ultimately, than correctness.  There are no
	mistakes, only opportunities to learn."

		Alan Cooper.  1995 "About Face: The Essentials of
			User Interface Design." p.481

This is my personal manifesto for CP4E.  I want learning about software and
programming to be that kind of experience for my son Doug, my grand-nephew
Jake, and anyone else who chooses to obtain some mastery of these
marvelously simple artifacts on which we are willing to depend for so much.

-- Dennis



From siegel@eico.com  Fri Mar 24 23:37:57 2000
From: siegel@eico.com (Arthur Siegel)
Date: Fri, 24 Mar 2000 18:37:57 -0500
Subject: [Edu-sig] The passion of EDU-SIG
Message-ID: <NDBBIAEANKEFIFOFMJHPIEDMCBAA.siegel@eico.com>


Inspired by some recent posts, I have gone back over some of the EDU-SIG
archives, particularly the archives from before my involvement.

I was struck my the degree of passion of a good deal of the discussion.
Since I have been truly surprised
at the degree to which discussions on this list have stirred my own
passions, it helped give me
some perspective.

Early on in the list Guido had posted up a letter of resignation to the list
from Terry Gabriel which said,
among other things:

"I think Python is what is going to be instrumental in saving democracy."

I probably couldn't be further from Mr. Gabriel's general political bent. He
talks of fighting  "the corporate interests who want to dumb the society
down". I consider the $1,200 piece of unfathomable genius and energy from
which I write
(a Gateway, as it happens)  - as proof that the demonization of "corporate
interests" are not on target. But I am
in agreement with his general point of what's at stake here. His point was -
a lot. And it is about demystification,
and putting people in a position to be at home in the world, the real world,
circa 2000.

I also relate to to Stephen Figgins analogy to wilderness tracking.  When I
explain to friends - and my wife -
the passion I developed for learning programming, I always use the term
'orienteering'. It seems to be coming from
a deep place - a survival instinct. Circa 2000 I need to understand the
algorithm to help me understand where I am, in effect.

We recognize what's at stake, and have different ideas.

I would hope we can let the passions stir here, rather than feel embarrassed
by them.




From gward@cnri.reston.va.us  Mon Mar 27 14:12:08 2000
From: gward@cnri.reston.va.us (Greg Ward)
Date: Mon, 27 Mar 2000 09:12:08 -0500
Subject: [Edu-sig] Software Engineering for everyone?
In-Reply-To: <38D9FA73.DAC8FDFF@darwin.in-berlin.de>; from gherman@darwin.in-berlin.de on Thu, Mar 23, 2000 at 12:05:23PM +0100
References: <20000321140422.C1326@cnri.reston.va.us> <38D9FA73.DAC8FDFF@darwin.in-berlin.de>
Message-ID: <20000327091208.B409@cnri.reston.va.us>

On 23 March 2000, Dinu C. Gherman said:
> Greg Ward wrote:
> > 
> > (Yes, it *is* something that needs to be taught to prospective
> > professional programmers as part of their undergraduate degree: the
> > ability to write solid, maintainable code is at least as essential as
> > the ability to understand quicksort.  Good coding practices are
> > certainly the first step on the road to full-scale "software
> > engineering", and good coding practices are something that CP4E should
> > emphasise.  But there's no need to go all the way -- after C++, the best
> > way to discourage people from programming is probably forcing them to do
> > requirements analysis or write test suites.  *yaawn*)
> 
> I would consider this an interesting interpretation of the
> concept of "extreme programming" ;-), but this is certainly 
> not what you mean, programming without testing, without know-
> ing what you're trying to accomplish, is it? 

I think you misunderstood, or I misspoke.  I'm *not* speaking out
against testing software (or debugging, or thinking about what you're
going to do before doing it, or other good practices); I think that
should be taught from the beginning.

And I'm not speaking out against "anal-retentive software-engineering"
practices, like rigorous, full-coverage testing, formal design and code
reviews, etc. etc.  IMHO "extreme programming" falls into this camp,
although it seems to me rather less anal retentive than most other
software methodologies.  It's still a methodology, though, and Kent Beck
(I'm in the middle of his book on XP now) says so.

I *am* speaking out against trying to teach full-blown software
engineering techniques to high-school students who are just getting
their first taste of writing code.  Yes, teach them to understand the
code before (and while) they write it, and teach them not to trust it
until they've tested it, and teach them how to fix it when it doesn't
work.  But don't go pulling in all the industrial-strength machinery
that the SEI espouses, because it just isn't necessary for writing Excel
macros or throwaway Python scripts -- which is what an awful lot of
people who come out of CP4E will probably end up doing.

> The difference is a matter of scale and formalism, it is not
> one of not doing something on one level (say, your homework 
> at school), but on another (say, a phone billing system).
> Moreover, drawing the borderline might not be always easy to 
> do.

True.  The further you get from a throwaway script to do your homework
to implementing a phone-billing system, the more SEI-style bureaucracy
you need.  However, that sort of software engineering bureaucracy
probably belongs in the undergraduate CS curriculum, not at the high
school level.

        Greg


From infonuovo@email.com  Mon Mar 27 19:18:14 2000
From: infonuovo@email.com (Dennis E. Hamilton)
Date: Mon, 27 Mar 2000 11:18:14 -0800
Subject: [Edu-sig] Software Engineering for everyone? -- In a way
In-Reply-To: <20000327091208.B409@cnri.reston.va.us>
Message-ID: <NDBBKEGCNONMNKGDINPFEEHCDEAA.infonuovo@email.com>

I support what you have to say here.  I do think there is something
important to provide in a high-school curriculum about what engineering
involves, but it doesn't have to be very heavyweight.  I am thinking of
three things: accountability, collegiality, and predictability.

1.	ACCOUNTABILITY
	I worked as an engineering aide right out of high school.  (Well, I had two
quarters of college, and the calculus plus high-school drafting classes got
me the job.)  The engineer I was working for wrote everything down.  I spent
all of my time, until I got to write some programs (we were self-teaching
ourselves FORTRAN), creating graphs and charts for the data we were
producing off of an IBM 701 computer system.  Everything was signed and
bound and filed.  I never forgot that.  I hated the tediousness of the work,
and I never forgot it.  And I was never afraid to ride a Boeing 720 when
they were later produced.

	In "Introduction to the Personal Software Process," the Watts Humphrey
book, the first thing that students are asked to do is record their time and
keep a log book.  As many years on-and-off that I have seen and used
engineering log books, I started all over again when I picked up the
Introduction to PSP about two years ago as a way to sharpen my individual
practices.  I am in log book #19 right now.  It takes me one-to-two months
per notebook.  Just in recording adjustments to my own computer
configuration and wanting to be able to recover or recreate an installation
on another machine, the log books have been a lifesaver.  I also find that
it doesn't work to keep notebooks on-line.  It is something I use on the
side even when my computer system is hosed and there are other things taking
up my screen real-estate.

	My point is that there is something around accountability, keeping track of
what was done and what happened, and also getting present to how ones
energies are invested in activities, that are valuable and that can be
introduced when young people are interested in what the activities of
software development and software engineering are.

	I would look for a way to provide this in the context of young people
learning their own ability to accomplish something by exploration and doing.
Providing accounts for what was done and what was involved is an important
aspect of getting a sense of the responsibility with which software
engineering is undertaken.  I would not tie it particularly to software.  It
applies in science and engineering generally, and I would want young people
left with a sense of that, even if they never pursue a technical career
themselves.

	I also notice that an important aspect of open-source projects is that
there is an opportunity to provide a high level of accountability simply in
keeping it all together and having a structure by which what is available
and what is being worked on can be inspected.  This may be the right level.

	For me this was an unnatural act, and I resisted it mightily.  I recognized
it as an important aspect of producing useful results, so I kept practicing.
Now it is second-nature for me.

2.	COLLEGIALITY
	I have been looking for a better word than this.  I am giving up that
search.

	I say that most human activities of any scale are cooperative activities.
I notice as a software developer that I easily maintain the illusion that it
is all about me and my own innate creativity, and if those other jerks would
get out of my face it would all be perfect.  I know that is hogwash, yet I
constantly see how I organize my life as if it were true that I exist
independently from everyone else, a pack of intruders.  (Even typing this
note has as much or more self-gratification in it than any sense of being
part of something bigger than myself and participating in a community.)

	In my first serious programming job (as a "Clerk Typist A" student
programmer -- they hadn't invented programming positions yet) after the
engineering aide experience, the faculty member I worked for was creating a
handbook of software by collecting what was available and republishing it
with documentation.  We were also cleaning up the disparate sources so that
the programs and routines could be used together as part of a coherent body
of work.  I loved it and hated it all at the same time.

	In my first "hacking" project we actually forked, as had many others, a
piece of open-source software.  It was the SOAP II Assembler for the IBM
Model 650 Computer System.  Hudson, High, and Hamilton produced the SOAP H
version by taking advantage of the fact that the source code and
documentation for the assembler were printed in the back of the manual.  We
did the usual thing: inspected the code and figured out ways to tighten it
up enough so that we had some free memory in our ~10k machine to add the
goodies we wanted.  My contribution was to build a linking loader for the
assembled programs, based on what I had seen of the FORTRAN II BSS Loader.
I recall not being very good about teamwork in this project, and I was
always holding up the parade by being off doing stuff on my own, and slowly.

	One of the things I noticed is that programming skill is often learned by
working from existing code.  It becomes important to have good examples.  At
some point, one has developed a practice of refinement and adaptation that
begins to show up as craftsmanship.  This is not a solitary activity, no
matter how much we go through it individually.  And for it to work, we must
be willing to submit our work to the adaptation and refinement of others.
Sooner rather than later.  When I first met Donald Knuth, he talked about
some of the most beautifully-crafted programs he had ever read. One program
was one that I had used, the Bell Labs Interpreter for computational work on
the IBM 650.

	Ever since "The Psychology of Computer Programming" and the introduction of
inspection, I have been more and more inclined to submit my work to the
inspection of others, as early as possible.  I have always been gratified
when a colleague came to me and requested doing a code walkthrough of
something being worked on.  This where code walkthroughs were not (yet) a
formal part of the team's work process.  I also notice that when I go dark
(I love that expression), I have completely closed up and gone inward where
there is no community support at all.  These days I can catch myself by
noticing that the date on the last completed page of my notebook is not
recent.  Today (03-27) the last entry is 03-25, and the previous was 03-23
and that was the last one of any substance.

	I haven't gotten rid of the fear of rejection, of being humiliated by doing
something stupid in public, or any of that.  What I have learned is that I
don't have to stop because of that, and I persist more all of the time.
Every time I write one of these long notes, I am apprehensive about how it
will be received.  It's as if the newbie hesitations (which I don't recall
having that strongly as a newbie) and the desire to look good never leave.
I am just playing a bigger game where that stuff all comes up, and I play
anyhow.

	So I want to point out a key aspect of collegiality.  It is not just that
we are always always always building on the work that comes before us, and
that such work was made available for us to work on.  That's no small thing.
I want to emphasize that software development is actually more of an
empirical and, yes, social process than those of us with as much
introverted, intellectualized viewpoint as myself can easily or willingly
recognize.  I notice, for example, that as much as I follow principles of
the PSP and bring myself to be accountable, my work is not nearly as
effective as when I have collaborators who hold me to account.  When I go
dark, I am in the dark.  Someone else can interrupt me (and I will resist),
and that can happen more quickly and usefully than waiting for myself to
snap out of it.  I also notice that I always get something out of
discussions of ideas and projects, if I am willing to be vulnerable enough
to talk about my half-baked ideas and be authentic about what concerns me.
It helps immeasurably to have a community in which to do that.  I also know
a wonderful secret: there is nothing better for mastery of a subject than
teaching it to others -- because they will teach it to you.  I think the
great athletic coaches know this, along with their profound commitment to
and respect for their players.

	In the context of CP4E, I think the simple practice of sharing ones work,
learning to inspect the work of others, and having our own work checked is a
big deal.  The open-source philosophy is also applicable here, as well as a
source of great worked examples (though not all open source code is that
great.)  And having that be all right and a desirable, let alone
permissible, way to produce an effective result is an important thing to be
exposed to when young.  And be accountable for what is original and what
isn't and acknowledge the support that occurs in teamwork.  These are
practices that I think are very important to demonstrate in a practical,
simple way.  There are many exercises for demonstrating the diversity and
insights that are available with cooperative approaches.  I don't know what
would instill an appreciation for how interdependent we actually are.  I
would look at that, though.

	I grew up on a steady diet of science fiction.  I like to say that Robert
Heinlein taught me to read.  In all of that reading, I thought of being on
the moon or going to Mars as something that would be a personal, individual
act.  The reality of space flight and the magnitude of the enterprise that
it took to have human beings walk on the moon and return just wasn't the way
I dreamt it would be.  Today I can be moved to tears about the magnificence
of that undertaking and the contributions that so many people made in so
many ways that brought space flight to reality.  I say there is not anyone
who participated in that effort whose contribution did not matter.  That's
new thinking for me.  (And not original, either.)  I want to see some sense
of the possibility of collegiality in the way CP4E is introduced in schools.

3.	PREDICTABILITY
	It is something to get to the point where one can actually specify
something and design it without having ever built it first.  It takes
practice and experimentation and some sort of conceptual shift where one can
do that reliably.  It's a big leap from not knowing what line of code to
write first in ones early teething.  Then building it first becomes a
seductive habit that is very hard to shake.  It's very interesting to get to
the point where one can specify something and trust that it can be built
without having any idea how!

	For me, predictability in software development is more than this.  It has
to do with a lot of quantitative methods and metrics.  It has to do with
refinement of requirements through design and construction.  It is certainly
tied to accountability and collegiality.  And being able to predict effort
and the time it will take to have a completed result.

	I don't want to emphasize predictability too much, but I think it is also
something valuable to instill an early appreciation for.

	It may be that the simplest first principle here is divide-and-conquer.
Creating interface agreements and sharing modules in a larger project of a
team might be enough.  That does lead to critical predictability of a kind.
And it can be useful to see what happens over time and in the face of
change.

	I found a very cool book on project management once (I think it is the
50-minute book on Project Management from Crisp Publications).  It is very
simple and very straightforward.  There is a video that goes with it that
demonstrates project thinking using a small company's move to new quarters
as an example.  It is really great.  It is also easy to forget and revert to
other ways of doing things.  It is also, in my experience, very difficult to
project manage a one-man-band.  It helps to have more players.

	I don't know if I would promote estimation very heavily, but maybe it would
be valuable for kids to try predicting the size of programs and learn how to
refine that as the work proceeds.

	I would look for examples in "real life," like getting homework or papers
done on time, though, and working from outlines first, something that I
remember as a challenge when I was a high-school student.  Or managing ones
training for a sporting event or team activity.  Or producing a
community-service or performing arts activity.

	The outline for this note is the first paragraph.  I wrote that.  Then I
let the note "write itself."  Not very predictable.  It helped though, in
that I did occasionally use that three-point list to ask myself what was the
point of each part and when was I going to make it.   Satisfying, but low in
predictability.  Unless I notice and use that data in further work.  I've
just put it in my notebook.

Love,

- Dennis

------------------
Dennis E. Hamilton
InfoNuovo
mailto:infonuovo@email.com
tel. +1-206-779-9430 (gsm)
fax. +1-425-793-0283
http://www.infonuovo.com


-----Original Message-----
From: edu-sig-admin@python.org [mailto:edu-sig-admin@python.org]On
Behalf Of Greg Ward
Sent: Monday, March 27, 2000 06:12
To: edu-sig@python.org; edu-sig@python.org; edu-sig@python.org
Subject: Re: [Edu-sig] Software Engineering for everyone?

[ ... ]

I'm *not* speaking out
against testing software (or debugging, or thinking about what you're
going to do before doing it, or other good practices); I think that
should be taught from the beginning.

And I'm not speaking out against "anal-retentive software-engineering"
practices, like rigorous, full-coverage testing, formal design and code
reviews, etc. etc.  IMHO "extreme programming" falls into this camp,
although it seems to me rather less anal retentive than most other
software methodologies.  It's still a methodology, though, and Kent Beck
(I'm in the middle of his book on XP now) says so.

I *am* speaking out against trying to teach full-blown software
engineering techniques to high-school students who are just getting
their first taste of writing code.  Yes, teach them to understand the
code before (and while) they write it, and teach them not to trust it
until they've tested it, and teach them how to fix it when it doesn't
work.  But don't go pulling in all the industrial-strength machinery
that the SEI espouses, because it just isn't necessary for writing Excel
macros or throwaway Python scripts -- which is what an awful lot of
people who come out of CP4E will probably end up doing.

[ ... ]

True.  The further you get from a throwaway script to do your homework
to implementing a phone-billing system, the more SEI-style bureaucracy
you need.  However, that sort of software engineering bureaucracy
probably belongs in the undergraduate CS curriculum, not at the high
school level.

        Greg

_______________________________________________
Edu-sig mailing list
Edu-sig@python.org
http://www.python.org/mailman/listinfo/edu-sig



From fig@oreilly.com  Mon Mar 27 19:47:26 2000
From: fig@oreilly.com (Stephen R. Figgins)
Date: Mon, 27 Mar 2000 11:47:26 -0800
Subject: [Edu-sig] Software Engineering for everyone? -- In a way
In-Reply-To: Your message of "Mon, 27 Mar 2000 11:18:14 PST."
 <NDBBKEGCNONMNKGDINPFEEHCDEAA.infonuovo@email.com>
References: <NDBBKEGCNONMNKGDINPFEEHCDEAA.infonuovo@email.com>
Message-ID: <200003271947.LAA19471@rock.west.ora.com>

Wow, that reminds me of one of the most important things about being a
naturalist, or a scientist in general, journaling.  I hadn't thought
of this in connection to computer programming.  Though I have kept a
SysAdmin journal sporadically for some time.  Whenever I get lazy and
don't write something down I generally end up cursing myself later.

Something that has helped my own progress as a naturalist has been
seeing the journals of others.  What sorts of things do you log on a
regular basis?  Do you have some really nice journal pages you would
be willing to share?  I wonder what other Programmer's out there are
journalers?  What could we learn from seeing their journals?

Stephen



From aschneiderman@njdc.com  Tue Mar 28 20:36:20 2000
From: aschneiderman@njdc.com (anders schneiderman)
Date: Tue, 28 Mar 2000 15:36:20 -0500
Subject: [Edu-sig] Software Engineering for everyone?
Message-ID: <3.0.6.32.20000328153620.007e1640@njdc.com>

On 23 March 2000, Greg Ward wrote:

>I *am* speaking out against trying to teach full-blown software
>engineering techniques to high-school students who are just getting
>their first taste of writing code.  Yes, teach them to understand the
>code before (and while) they write it, and teach them not to trust it
>until they've tested it, and teach them how to fix it when it doesn't
>work.  But don't go pulling in all the industrial-strength machinery
>that the SEI espouses, because it just isn't necessary for writing Excel
>macros or throwaway Python scripts -- which is what an awful lot of
>people who come out of CP4E will probably end up doing.

In fact, given the success of the open source movement, it's not clear that
anyone should be forced to learn SEI.  Last year, Software magazine had
several wonderful exchanges between several Open Source practitioners and
followers of more formal methodologies.  The OS folks said, we do follow a
methodology--a very particular, stylized way of doing things--we just don't
talk about it much and we don't focus on the same things you do (e.g., we
do less spec writing and more iterations or "microspirals", as one person
put it).  I'm sure SEI is useful in some circumstances--there are very
smart programmers who swear by it--but there are just as many very smart
programmers who use a very different approach.  

So, rather than saying to poor high school kids, here's _the_ methodology
that all righteous computer people follow (i.e., lying to them), I'd go for
the following approach.  

First, let's step back and ask, what are we trying to accomplish with CP4E?
 IMHO, the list looks something like this:

1) Give everyone enough skill so they can write the equivalent of an Excel
macro so they automate a bit of their work and make their computer work for
them rather than against them.  Odds are most people won't end up using
this skill very much (unless, of course, the world of computers becomes a
lot more user-friendly than it is now), but at least school can lay the
groundwork so it isn't so intimidating or mystifying.

2) Since at some point in their lives many people will end up being
involved with a computer project (usually as hapless users), it's useful
for them to know how the sausage gets ground.

3) Create enough basic computer literacy so people can act as informed
citizens when computer-related issues are discussed.


Given these goals, I'd say your average Jane needs to learn the following
about Software Engineering in high school:

* If you're writing a program for someone else, how do you figure out what
the program needs to do?  How do you help users decide which tradeoffs
they're willing to live with? How do you deal with the fact that it's hard
for most users to know in advance what they really want?  

* How do you handle changes in the requirements for a program?  How do you
allow for the reality that people will change their minds & unforseen
events will force you to change the direction of a program without having
the process spiral out of control?

* How do you work in groups without killing each other?  How do you resolve
conflicts between different users, developers, etc.?  How do you run
meetings that are short, focused, and that get things done (of all the
skills we could teach, this one could have the biggest impact on society,
the GDP, etc.)?

* How do you figure out roughly how much progress you've made & how close
you are to finishing?  In other words, how do you do very rough estimates &
revise them as you go,  how do you use testing to make sure your program
doesn't become "90% done" forever, and how in general do you manage risks?

* As your problems get more complicated, how do you scale up without either
losing control or getting swamped by a process that's too bureaucratic?

Most of these skills are important for Goal #1, and all of them are
important for Goals #2 and #3.  In teaching these skills, the focus
wouldn't be to say here's the one right way to do this but rather teach
kids how to figure out what seems to them the best way to answer these
questions.

You might think this is way too complicated for kids, but given a slightly
different approach to teaching, I think it's doable (based on my experience
teaching computer-illiterate adults how to write macros, scripts, programs,
etc.). For instance, most computer classes teach people how to write short,
individual scripts from scratch.  You can't learn software engineering this
way; at this size, you won't get bit on the ass when you make software
engineering mistakes and so you won't really learn.  Here are some examples
of how to get around that problem:

1) For the first few projects, kids would build small, simple databases
from scratch.  Once they got their feet wet, they'd break into groups to
modify a larger database that already existed, using other students in the
classroom as their users/clients.  The databases could be something that
was really used or they could just be fun, such as a  database for cat
lovers, car lovers, the fashion police, etc. (my first database written 20
years ago, for hiring assassins to kill teachers, would probably be a no-no
in the post-Columbine world).  

Say one group was extending the Fashion Police database so that in addition
to having Fashion Crimes it would also have punishments for each crime.
They would have to negotiate with their "client" to figure how much they
thought they could realistically do in 3-4 weeks, prioritize what features
mattered most, then report back twice a week on their progress, getting
feedback and talking as a class about the problems people had encountered
and how to move forward.  For ex, in the first week you'd expect that the
kids would have gotten a bit too ambitious in their goals and got bogged
down as soon as they started forward.  By the end of the week, with enough
help from the teacher and the rest of the class, they'd have scaled back
what their goals were and set a target of the end of the next week to see
how they were doing.

2) If you were using something like the 3D graphics world of Alice,
students would start by writing a bunch of little scripts over several
weeks.  Working in groups, each kid would be responsible for animating a
different set of characters (e.g, one kid might animate the cow and the dog
for the Farm group).  After several weeks of work, they'd have a decent
number of scripts.  Now the challenge would be to start combining them to
build more and more complex scenarios.  At some point, the amount of
scripting would get clumsy enough that the kids would have to "scale" their
approach or they'd get overwhelmed.  With the right curriculum and a few
practice runs, a teacher could probably get her students right to that "oh
my God what the hell do we do next" point where the students would need the
tools of software engineering, redesign, etc. to keep afloat (quite similar
to what happens to lay programmers when they've got one too many Excel macro).

3) Every few assignments, instead of having students write a new script,
have them test and debug a simple existing script.  After a few weeks, give
each group of students a program that's really cool (however they define
"cool") but really buggy and poorly documented.  Have them tear it apart
and figure out how to make it work _and_ what all of its parts are supposed
to do.  As they go, have them keep a journal of all the things they wish
the stupid programmer who wrote the program had done differently.

Most of my experience is with teaching adults, so I don't know how well
this would work with, say, teenagers.  But I think an approach similar to
this one could probably fit the bill:  start out going easy on software
engineering and then gradually add more as students learn the hard way why
they need it.  In the end, students would not only learn a lot more about
programming, but they'd also learn valuable lessons about how computer
projects do & don't work, lessons which would really save their butts in
the real world when they confront computers as users.

Anders Schneiderman
National Journal Daily Briefings Group