-----Original Message----- From: edu-sig-bounces@python.org [mailto:edu-sig-bounces@python.org] On Behalf Of Kirby Urner
To some extent what's bogus about the GUI vs. no-GUI debate is that you /have/ to have an interface to the user at some point, whether this is accomplished with bells and whistles or not. So both the command line and the windowing environment are meant to accomplish the same purpose: closing the feedback loop between user and CPU.
Python has presented what I think is another alternative. The entry point to PyGeo is purposefully not a GUI. I think that getting what one should get from the process of doing a geometric construction - in order for it to have the cognitive impact that makes it a meaningful activity - rules out a GUI event sequence. I believe this firmly, despite the fact that almost all other dynamic geometry applications of which I am aware take the opposite tack - click here to create a point, click there to create another point, do this to connect the points, etc and etc. I like to think that the attempt of PyGeo is to create an interface that is neither a GUI or an API, but an SUI - a script users interface Much thought and intention has gone into the design of the PyGeo SUI (it is the SUI I want to use to *Do* geometry), but I suspect it comes off to some as if the author just hasn't gotten around to the GUI yet, or is trying to be stubbornly geeky, or something. In my view, the more GUI intensive efforts are the less mature. It sometimes what you don't say that is the more important statement, as it sometimes the GUI that you don't create. If the purpose is to get to the end result, the construction on the screen, maybe the GUI approach makes sense. If the process of getting to the construction is the essence of the activity, which in what I am intending it indeed is, then the more sophisticated GUI approach is clearly less sophisticated. Art
I'd like a CS0/CS1 to take a more resolutely historical approach and clomp through the command line era in grand style, taking very seriously the command line switches, man pages, HTML manuals or whatever. Especially in UNIX, these commands were designed to be chained, switched, piped, redirected. They were tiny toys, power tools, micro apps. The accomplished sysadmin had enough of them down to perform serious kung fu.
So my CS0 is a combination of command line Linux, Python shell, Python shell invoking command line Linux, Python programs run as scripts, from the command line. This would seem very austere to newbies, but we'd perpetuate the ethos that GUIs are for gimps -- you don't need those handicaps to play the game. But it'd be a mock attitude, i.e. we secretly respect GUIs (the good ones) and write them ourselves. But the command line has lost none of its power in the meantime.
However, as I've also reiterated, I'm not designing a CS curriculum. This is a CS/math hybrid, with emphasis on the math. So the Linux/POSIX notation, along with dot-notation, will have a means-to-an-end feel, Python taking us even further, into graphical and tactile output territory for example, e.g. the 1000s-of-frequency Waterman polyhedra (whatever that means right?).
Kirby
_______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig