[Edu-sig] A case against GUIs in intro CS :-)

[Arthur]

> -----Original Message-----
> From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at 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 at python.org
> http://mail.python.org/mailman/listinfo/edu-sig