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

[Arthur]

> From: Rodrigo Dias Arruda Senra [mailto:[EMAIL PROTECTED]
> Sent: Saturday, June 11, 2005 12:49 PM
> To: Arthur
> Cc: edu-sig@python.org
> Subject: Re: [Edu-sig] A case against GUIs in intro CS :-)
> 
>  Moreover, a good communicator may be capable to convey multiple-
> perspectives
>  competently. Perhaps that makes more sense in other domains than in math,
>  and maybe that is why we have this different perspectives about it
> .

Maybe, maybe not.

Turns out that I got a little flummoxed trying to make it through "Practical
Common Lisp" cover to cover.

Backing off, and digesting a few chapters of another Lisp introduction,

"""
Successful Lisp:
How to Understand and Use Common Lisp
"""

http://psg.com/~dlamkins/sl/

helps immensely.

Yes, it could get expensive.  Thankfully "Successful Lisp" is available
complete online (not my first choice - I'd rather own it, and may
eventually.)

More generally, the whole idea of approaching Lisp is to get another
perspective on programming. Obviously there is no good way to effectively
communicate the Lisp perspective from, say, a book on Python. One of the few
points of consensus on edu-sig seems to be the usefulness of learning
multiple languages as a means to gaining (what I call) dimension, as a
programmer.

I have read great books on analytic geometry, and great books on synthetic
geometry - but no great books giving each approach equal weighting.  Its up
to me to synergize.

In the end, I have yet to understand there to be a great difference with
tackling programming and math.  Of course I took the approach of in fact
learning them together, as one undertaking - adding some cross-dimension to
each undertaking.

I am leaning toward an unprovable "not" on the thesis that learning and
teaching math and programming are truly distinct domains 

Kirby seems to have an idea or two along these lines. ;) 

But he and I seemed to have started here with that perspective, seem to
maintained it, and seem to be quite unconvincing to many others.

But I shouldn't speak for Kirby - noticing him to be fairly capable of
speaking for himself ;)


Art


___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Rodrigo Dias Arruda Senra]

 [ Arthur <[EMAIL PROTECTED]> ]
 ---
 | 
 | 
 | > -Original Message-
 | > From: [EMAIL PROTECTED] [mailto:edu-sig-
 | > [EMAIL PROTECTED] On Behalf Of Rodrigo Dias
 | > Arruda Senra
 | >  "Avoiding repetition == respect" is an oversimplification to me.
 | 
 | I don't disagree, really - except that it is near impossible to say anything
 | that is not an oversimplification.

 Well, the term 'oversimplification' itself is not an oversimplification. ;o)
 Just kidding.

 | And it is maybe because I tend to take that approach, that I tend to
 | appreciate an author giving his best shot at communicating *a* perspective.

 I respect that, but that can be quite expensive as well, from book costs POV.

 Moreover, a good communicator may be capable to convey multiple-perspectives
 competently. Perhaps that makes more sense in other domains than in math,
 and maybe that is why we have this different perspectives about it .

 cheers,
 Senra

-- 
   ,_   
   | )  Rodrigo Senra 
   |(__ ---
 _((|__|]   GPr Sistemas  http://www.gpr.com.br   
_ |(|___|]  Blog  http://rodsenra.blogspot.com
___(|__|]   IC - Unicamp  http://www.ic.unicamp.br/~921234  
   L___(|_|]---
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Arthur]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:edu-sig-
> [EMAIL PROTECTED] On Behalf Of Rodrigo Dias
> Arruda Senra
> Sent: Saturday, June 11, 2005 11:32 AM
> To: edu-sig@python.org
> Subject: Re: [Edu-sig] A case against GUIs in intro CS :-)


>  "Avoiding repetition == respect" is an oversimplification to me.

I don't disagree, really - except that it is near impossible to say anything
that is not an oversimplification.

It is true that I do find that I tend to need more than one perspective on
the same subject in order to flesh it out in a way that gives it dimension.
And generally accomplish it by reading more than one book/tutorial/whatever,
often almost side-by-side, when trying to digest a subject.  

I think this is one of the reasons I could not adjust well to traditional
schooling, especially when it came to introductory material for technical
subjects.  We are generally expected follow patiently a single text. I
learned that I need multiple sources to effectively learn.  It is in this
sense that the appearance of the Internet was such a catalyst for new
learning opportunities in my own case.  Multiple sources, on most any
subject, at my fingertips. 

And it is maybe because I tend to take that approach, that I tend to
appreciate an author giving his best shot at communicating *a* perspective.
Not many.  I *will* need another perspective, to be sure - but I will get
that from another source, who hopefully is giving it their best shot at
communicating their perspective - which if substantive enough will almost
always be shaded in its own way, and therefore not simply redundant as to my
other source/sources.

I am thinking more about how I tend to study math and geometry than
programming, directly.  But I have this crazy theory that the pursuits
follow similar cognitive paths.

Art   




___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Rodrigo Dias Arruda Senra]

 Arthur wrote:
 | > The author communicates respect for his audience.  He says things once.
 | > Even hard things...Him repeating himself is not going to help 
 | > because he has already said it the best way he could
 | > find to say it.  Saying it a second time, he could only be saying it a
 | > second best way.

 I see your point, and I beg to differ.

 In terms of human communication, there is hardly one best way to convey
 any message. Therefore, 'the second best way' might be a matter of 
 reader perspective (not writer).

 The argument """there is nothing stopping me from reading it five
 or six times if I need to""" can be counter-argumented by
 '''I can skip text as much I'm confident'''.

 Moreover, there is no learning without some degree of repetion. Therefore,
 'say things once' might turn from 'good-there-is-no-repetion' into
 'blast-I-have-to-read-it-back-again'.

 Communicating well: clearly, enjoyably, effectively takes time, 
 hard struggles for balance, and tough decisions. 

 "Avoiding repetition == respect" is an oversimplification to me.

 best regards,
 Senra

-- 
   ,_   
   | )  Rodrigo Senra 
   |(__ ---
 _((|__|]   GPr Sistemas  http://www.gpr.com.br   
_ |(|___|]  Blog  http://rodsenra.blogspot.com
___(|__|]   IC - Unicamp  http://www.ic.unicamp.br/~921234  
   L___(|_|]---
___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Laura Creighton]

I have often wondered if we didn't lose something when the first programming 
people learn
to do is no longer batch processing -- the sort I learned to do with cards.  At 
any rate,
I keep meeting people who have severe problems understanding how to write 
programs that
do not interact with a user at all.  They keep wanting to have 'conversations' 
with an
assumed 'program operator' ...  It is a fundamental conceptual problem, for 
some of them.
The notion that somebody could want to 'get data from here' without clicking on 
a mouse
for a filename at all stops some people cold, even though they have already had 
1 or 2
introductory progamming courses.  For them, the _GUI_ is the computer, and the 
computer is
relentlessly interactive...

Laura

___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Kirby Urner]

> > 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.
> 
> Yikes. Any "gimp" who has had to work with a programmer "educated" in this
> sort user-hostile rhetoric knows that it leaves a lot to be desired. I
> can't understand why anyone would want to actively promote it, except as a
> joke about the foolishness of some programmers. A wiser approach is to
> encourage students to use the best tool for the job.
> 
> Toby

The use of 'gimp' was a play on Gimp, the source of GTK, a premier X-Windows
library.

It's not supposed to come across as hostile, but simply as reassurance to a
resolute core group, that command-line savvy is not in vain.  We're
contenders.  We matter.  That sort of thing.  Cheer leading.  And then
there's an edge to it, because you don't want to envy the competition so
much that your concentration fails.  So we bad-mouth the GUI people a
little, but only to keep our spirits up, as we're secretly in love with
GNOME, KDE, and the rest of them.  In fact, we're all on the same team.  I
code GUIs, and I like command-line straightforwardness.  I'm representative
of a huge group of coders.

Kirby


___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Arthur]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Toby Donaldson
> A wiser approach is to
> encourage students to use the best tool for the job.

Were it only that easy.

Perhaps it is easy, except when its important.

For example, what is the best tool for the job of teaching introductory
computer science?  

The best tool for the job is apparently not apparent.

Or is the definition of the job that is not?

Art 




___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Toby Donaldson]

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

While I don't think a completely command-lined based approach would work well 
for a large mixed-audience CS0/1 class, I think it is an important and useful 
tool that developers should know about. 

Unfortunately, most students are not excited by system administration. Indeed, 
many programmers dislike it too. Similarly, most university instructors would 
be turned off by the idea; "system administration" is a a dirty word in 
"proper" CS education. 

As a case-study in programming, system administration is a good example of how 
to get simple programs to do useful things for you.

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

A side-effect of relying IDEs for programming is that most students only know 
how to run a program through the IDE. I think in a first course showing 
students how to launch programs from the command-line is good idea. I would 
allow but not require students to use the command-line for program 
*development*.

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

Yikes. Any "gimp" who has had to work with a programmer "educated" in this sort 
user-hostile rhetoric knows that it leaves a lot to be desired. I can't 
understand why anyone would want to actively promote it, except as a joke about 
the foolishness of some programmers. A wiser approach is to encourage students 
to use the best tool for the job.

Toby

___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Arthur]

> -Original Message-
> From: Kirby Urner [mailto:[EMAIL PROTECTED]
> Sent: Sunday, June 05, 2005 12:08 PM
> To: 'Arthur'; 'Edu-sig'
> Subject: RE: [Edu-sig] A case against GUIs in intro CS :-)
> 
> > The only realms that I can think of in which the notion of the voluntary
> > adoption of and adaptation to discomfort has been successfully
> introduced
> > is
> >
> > Religion
> > Athletic training
> >
> > I have decided to (at this time) forego the incorporation of the Church
> of
> > the Awkward Interface (h... foregoing some nice tax benefits), and
> > concentrate for the time being on the athletic training meme.
> >
> > See how far I get.
> >
> > Art
> 
> I think the athletic training metaphor is a fine one to milk. 

Less far-out when I recall that my 10th grade math teacher and my junior
varsity wrestling coach were one-in-the-same.  And I promise that training
for collegiate style wrestling is all about adaptation to discomfort.
Perhaps explains how I can get through 8 chapters on Lisp syntax ;) 

> I'm drawn
> to
> the bicycle world in particular, where there's the actual activity of
> riding, which may be very strenuous (distance racing is one of the most
> punishing of all competitive sports), but also the job of maintaining the
> bike.  

The real point, I think, is that it is not the most efficient way to get
from here to there.  But its workings are transparent, and there is no
ambiguity as to whom is supplying the power.


Art


___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Kirby Urner]

> The only realms that I can think of in which the notion of the voluntary
> adoption of and adaptation to discomfort has been successfully introduced
> is
> 
> Religion
> Athletic training
> 
> I have decided to (at this time) forego the incorporation of the Church of
> the Awkward Interface (h... foregoing some nice tax benefits), and
> concentrate for the time being on the athletic training meme.
> 
> See how far I get.
> 
> Art

I think the athletic training metaphor is a fine one to milk.  I'm drawn to
the bicycle world in particular, where there's the actual activity of
riding, which may be very strenuous (distance racing is one of the most
punishing of all competitive sports), but also the job of maintaining the
bike.  Race car people do the maintenance too, including deep rebuilding of
engine components, but the bicycle is more transparent, lighter weight, so
I'll stick with them.  Horses would have been another option, but our urban
kids wouldn't get it.

To me, the *nix OS as approached through the command line feels like a
bicycle repair shop.  Lots of little tools, all of which do something useful
and specialized.  Used in concert, you can do wonders with your bicycle,
which on this analogy might be some project or application you're developing
(maybe for someone else -- bicycle shops aren't confined to working on the
owner's bike, especially given ssh).  

The *nix OS, unlike Windows, is all about giving the developer a lot of
developer tools.  Microsoft sees those as extra (e.g. Visual Studio), and as
intensively GUI-based.  That's because DOS was written for the end user, the
stereotypical consumer of apps.  Early Windows was merely a GUI-based
wrapper for DOS (at least at first) and preserved the "developers do it
elsewhere (i.e. on our more expensive platforms)" aesthetic.

Also, although bicycle technology has changed over the years, it's still
very inter-generational.  Likewise the command line.  Some may consider it
antiquated, superseded by the GUI, the desktop.  That's not really a correct
assumption.  People still need to build and fix bicycles, and the command
line tools still make sense.  Some are more obscure than others, but it's
not a waste of time to get fluent with at least a subset of them.

The link to math and Python is that math notations aim to be self-contained
i.e. to take my course, you don't need to take any other mathematician's
course, because like she or he, I'm trained to build everything from axioms
right in front of you, such that my towering theorems are seen to rest on my
secure foundations, and you're suitably impressed -- like, math is
impressive.  

So if we're playing around with shells, doing math, we'll at least need to
at least be able to ssh, ls, cd and such.  We don't tell you to go down the
hall for that; just stay in your seat and all will become clear, and if
you've heard it before, listen again, because this is the math department
now, and math is different.

Kirby


___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Arthur]

> -Original Message-
> From: Arthur [mailto:[EMAIL PROTECTED]
> To: 'Arthur'; 'Kirby Urner'; 'Edu-sig'
> > Behalf Of Arthur
> So I don't think they are likely to ever uncover the truths here, where
> the
> results are not the point, and a certain level of discomfort (avoiding
> glibness) is for the better.

The only realms that I can think of in which the notion of the voluntary
adoption of and adaptation to discomfort has been successfully introduced is

Religion
Athletic training

I have decided to (at this time) forego the incorporation of the Church of
the Awkward Interface (h... foregoing some nice tax benefits), and
concentrate for the time being on the athletic training meme.  

See how far I get.

Art


___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Arthur]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Arthur
> Sent: Saturday, June 04, 2005 9:52 PM
> To: 'Kirby Urner'; 'Edu-sig'
> Subject: Re: [Edu-sig] A case against GUIs in intro CS :-)
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> > Behalf Of Kirby Urner
> 
> 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.

Which is the point that leads me to be
resistance/suspicions/paranoias/concerns in respect to the introduction of
technology into the classroom, more generally.

Kirby's efforts as well as my own do not attempt to entice based on their
technical sophistication.

Raw simple unadorned transparent is what makes sense in a serious effort to
make cognitive connections.  But such an approach - once it is introduced on
a computer - cannot be taken seriously, because it is raw simple transparent
and unadorned, and that's not how we use computers, these days.

HCI studies are generally designed to measure results, comfort levels, etc.
So I don't think they are likely to ever uncover the truths here, where the
results are not the point, and a certain level of discomfort (avoiding
glibness) is for the better. 

Art


> 
> Art


___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Arthur]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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


___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Nicola Larosa]

> There are actually subtle dangers in event-driven design itself. I
> heartily suggest everyone read Miro Samek's "Who Moved My State",
> C/C++ Users Journal, April 2003. He says it much better than I can,
> and he's one who Really Knows.

After a little Googling, here it is:
http://www.quantum-leaps.com/writings/samek0304.pdf

It looks interesting, at a first glance. I'll read it soon.

-- 
Nicola Larosa - [EMAIL PROTECTED]

Forget everything you ever learned about wxPython/Twisted integration.
It is no longer relevant. Forget that any of the ugly wxPython+Twisted
Python Cookbook entries, lame wiki examples, twisted.internet.wxreactor,
etc. even exist. -- Bob Ippolito, April 2005


___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

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

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

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

[Chuck Allison]

Hello Arthur,

Saturday, June 4, 2005, 6:06:34 AM, you wrote:

A> Question.

A> I don't remember SQL and database ever coming up here.

A> It is the only the combination of skills I developed in learning Python and
A> in learning SQL and database design that has allowed me to become useful in
A> the real world - in the making $ sense of the word.

A> Luckily I find database stuff interesting enough, and SQL powerful enough in
A> the context of database, that I have been able to throw myself into the
A> effort to get my arms around these technologies.

A> And they seem to be very core skills for making one's way in the world as a
A> developer.

A> Where does it fit into the CS curriculum?

A> Art 

We teach it in a few places. First, we have a required Database class
at the junior level. Then, several classes thereafter use DB in the
assignments. And of course it usually makes its way into the capstone
project for those majoring in software engineering.



-- 
Best regards,
 Chuck

___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Chuck Allison]

Hello Toby,

Saturday, June 4, 2005, 1:50:30 AM, you wrote:

TD> On 6/3/05 11:00 AM, "Chuck Allison" <[EMAIL PROTECTED]> wrote:

>> I think VB is the absolute
>> worst way to introduce programming,

TD> Worse than COBOL? Or the C pre-processor? :-)

Well, worse than what is being used today. These aren't on the plate.

>> and emphasizing GUI in a first exposure to computing is a mistake.

TD> My feeling is that it was not so much GUI-first as design-first that made
TD> the VB course I taught so interesting. By drawing a GUI first, you are doing
TD> some design, and even making decisions about certain variables and data
TD> structures. Your goal is clear: you want to write a program that implements
TD> the GUI. And it's not just the visuals that students would work out before
TD> writing code, but they also thought about the interaction, and how the
TD> interface should behave. It makes programming very goal-oriented.

Teaching design early is a good thing. What I object to
over-emphasizing GUIs is that newbies feel that 1) Event-driven
programming is the only way to go, and 2) if there isn't a GUI, you're
not programming. I am reacting to a strong contingent that has been in
my face a lot. Thee are many who really believe this. GUI has it's
place, though, as I have suggested.

There are actually subtle dangers in event-driven design itself. I
heartily suggest everyone read Miro Samek's "Who Moved My State",
C/C++ Users Journal, April 2003. He says it much better than I can,
and he's one who Really Knows.

TD> I more commonly hear students complain that CS doesn't do a good job of
TD> preparing them for a career in software engineering. That it is too focused
TD> on esoteric theory, and that too many (university) faculty hold their noses
TD> when writing programs.

I have heard this too, but my college is not one of those. We cater to
industry, while not skimping on theory.

-- 
Best regards,
 Chuck

___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Scott David Daniels]

Arthur wrote:
> I don't remember SQL and database ever coming up here
> Where does it fit into the CS curriculum?

It is typically its own course (it takes a completely different
attitude than "another programming language").  Most programmers
"pick it up" after school.  Usually they "don't want to understand,"
but "just have to get this coded."  There are too many texts that
cater to that attitude, to the detriment of the consumer.  This
attitude leads to bad (inefficient), product-specific SQL.  The
best texts I've found for DB for the programmer are Joe Celko's
books; he has a good blend of practical and enough theory to steer
it.  He is also one of the few practical programming authors to
write about how to write in SQL without picking a single vendor and
teaching you how to use their product.

--Scott David Daniels
[EMAIL PROTECTED]

___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Arthur]

> Behalf Of Toby Donaldson
> To: Chuck Allison; Jeffrey Elkner
> I more commonly hear students complain that CS doesn't do a good job of
> preparing them for a career in software engineering. That it is too
> focused
> on esoteric theory, and that too many (university) faculty hold their
> noses
> when writing programs.

Question.

I don't remember SQL and database ever coming up here.

It is the only the combination of skills I developed in learning Python and
in learning SQL and database design that has allowed me to become useful in
the real world - in the making $ sense of the word.

Luckily I find database stuff interesting enough, and SQL powerful enough in
the context of database, that I have been able to throw myself into the
effort to get my arms around these technologies.

And they seem to be very core skills for making one's way in the world as a
developer.

Where does it fit into the CS curriculum?

Art 


___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Toby Donaldson]

On 6/3/05 2:50 PM, "Nicola Larosa" <[EMAIL PROTECTED]> wrote:

>> Event-driven programming is a narrow, over-emphasized slice of the
>> software experience,
> 
> No, this is going too far. Event-driven, asynchronous programming is not
> limited to GUIs: it is instead a powerful, if a little invasive ;-) ,
> concurrency model. Anyone who "got" Twisted ( http://twistedmatrix.com/ )
> will never program the same way again. Drop those threads for good!

Another nice example of event-driven programming is parsing. Some (simple)
parsing problems can be nicely implemented in an object-oriented,
event-driven way. 

Toby
-- 
Dr. Toby Donaldson
School of Computing Science
Simon Fraser University


___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Toby Donaldson]

On 6/3/05 11:00 AM, "Chuck Allison" <[EMAIL PROTECTED]> wrote:

> I think VB is the absolute
> worst way to introduce programming,

Worse than COBOL? Or the C pre-processor? :-)

> and emphasizing GUI in a first exposure to computing is a mistake.

My feeling is that it was not so much GUI-first as design-first that made
the VB course I taught so interesting. By drawing a GUI first, you are doing
some design, and even making decisions about certain variables and data
structures. Your goal is clear: you want to write a program that implements
the GUI. And it's not just the visuals that students would work out before
writing code, but they also thought about the interaction, and how the
interface should behave. It makes programming very goal-oriented.

> Event-driven programming is a
> narrow, over-emphasized slice of the software experience, and is
> particular damaging to start a CS major off that way. I think there is
> more than just a little deception in luring people into CS with a
> visual approach, just to have them fail later on because they didn't
> know what CS was really about.

I more commonly hear students complain that CS doesn't do a good job of
preparing them for a career in software engineering. That it is too focused
on esoteric theory, and that too many (university) faculty hold their noses
when writing programs.

> If you want to do that with IS majors, go ahead, but not CS majors. It's just
> plain evil.

I think many CS students would benefit from treating programming as a
goal-oriented design activity.

In any event, I don't think my school teaches VB any more --- and it was
never a course for majors.
 
> I think Python can fix a lot of this. I've actually been "concerned"
> that if we switch to Python, they'll learn CS concepts too quickly,
> and we'll run out of things to do in four years :-).

Toby
-- 
Dr. Toby Donaldson
School of Computing Science
Simon Fraser University


___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Nicola Larosa]

> Event-driven programming is a narrow, over-emphasized slice of the
> software experience,

No, this is going too far. Event-driven, asynchronous programming is not
limited to GUIs: it is instead a powerful, if a little invasive ;-) ,
concurrency model. Anyone who "got" Twisted ( http://twistedmatrix.com/ )
will never program the same way again. Drop those threads for good!


> and is particular damaging to start a CS major off that way.

Concurrency is hard. What is damaging is the current preponderance of the
broken threading model, so frequent in the Windows and Java worlds. A
balanced presentation of the pro and cons of the different concurrency
models - process-based, thread based and event-based - should be included
in every intermediate level programming course.

Not introductory stuff, for sure, but education nonetheless. :-)


-- 
Nicola Larosa - [EMAIL PROTECTED]

The computer, especially connected to the Internet, is the paradigm power
tool of our age. The sin would be to bring up a generation of passive
consumers who complain and whine because "it won't do what I want."
The mark of a successful civilization is it gives its people power over
its most powerful tools, and not vice versa. -- Kirby Urner, April 2005

___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Toby Donaldson]

Jeffrey Elkner wrote:

>On Fri, 2005-06-03 at 01:59 -0700, Toby Donaldson wrote:
>  
>
>>When I taught VB (Visual BASIC), however, the GUIs were great, and
>>students almost universally said the course was more interesting and
>>enjoyable because of them. In part, they liked the fact that their
>>programs looked like real programs, and that there was some room for
>>creativity in how they organized their interfaces. Student were often
>>driven to do extra programming by a desire to add or fix features they
>>had seen in programs. I liked the fact that there was a very clear
>>design phase where you had to sketch out the interface. Talking about
>>the interfaces was a good way to talk about the program without
>>talking about the source code. This helped students organize their
>>source code, and to see first-hand the benefits of modularity, i.e.
>>they were always writing the code for widgets in specially-named
>>functions. Also, GUI widgets roughly correspond to programming
>>concepts, when deciding if you want to use a text book or a list
>>(say), you are indirectly deciding which data s!
>> tructure you want to use. Some students said they thought that
>>learning VB first made it easier to understand Java-like OO GUI
>>models.
>>
>>
>
>Toby, check out pythoncard (http://pythoncard.sourceforge.net/).  I have
>a student this year, Daniel Caughran, who used it for his science fair
>project, and he compares the experience favorably to using VB (with
>which he is familiar).  He was able to put together a very useful GUI
>program with a minimum of effort.  Version 1.0 will be out soon.  It
>looks like teachers using Python can now offer their students the
>advantages of VB without the disadvantages.
>  
>
Thanks, will do.

>  
>
>>As much as I like Python and dislike the BASIC part of VB, I do have
>>to admit that my experiences with VB were probably the best I ever had
>>teaching introductory programming (although it wasn't quite a CS1
>>course, just a humble introduction to "event-driven" programming).
>>
>>
>
>I "taught" VB for a year, and was amazed to find out that I made it
>through the entire year without either myself or my students (naturally)
>learning much of anything about programming.  To be fair, that is not
>the fault of the tool itself (though the tool did contribute to the
>problem), but rather the fault of the approach used to teaching it (it
>was my fault, in other words, but let me explain ;-).
>
>We used a Shelly Cashman book as the textbook for the course (I had
>nothing to do with choosing it).  These books seem to be popular with
>some folks inside the school system because they keep students busy (and
>thus, the reasoning goes, out of trouble).  They also teach students
>almost nothing.  Long, complex procedures are illustrated step-by-step,
>with screen shots showing exactly what the screen should look like at
>each stage.  Students are able to follow the instructions step-by-step
>to achieve the desired result (thus they are kept busy), but the focus
>is almost exclusively on the environment and the procedures are way to
>complex for students to be able to extrapolate much of use from the
>experience.
>  
>
This is a good point ... I recall that many of the VB textbooks I looked 
at step-by-step procedures (with screenshots for every step) that guided 
the students through the creation of a program. It seems like a 
reasonable way to teach programming to beginners, although, as you say, 
if it is just about the mechanics of coding then it's nothing more than 
a VB package training course. Which is fine if you never use anything 
but VB, and never need to do anything too advanced.

I recall that the VB text I was using had a very elegant and 
sophisticated implementation of mergesort --- more elegant than the 
implementation given in the data structures and algorithms textbook I 
was using at the same time for a CS2 course. I suppose that's because CS 
courses are not really about programming, but about the underlying ideas 
and concepts. Implementation is sometimes treated as a necessary evil. I 
am surprised how frequently I hear CS people talk about their dislike of 
programming.

>It is my hope that the grass roots nature of the Python community will
>prevent this same kind of thing from happening with our teaching
>materials, particularly as more and more people are using Python.  The
>eclectic, cross platform, multi-environment nature of Python programming
>will make it difficult for a Shelly Cashman type book to be written.  Or
>at least we can hope...
>
Toby

___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Scott David Daniels]

Arthur wrote:
> The author communicates respect for his audience.  He says things once.
> Even hard things.  It doesn't mean he expects me to get it on reading it
> once, but we understand each other I think - there is nothing stopping me
> from reading it five or six times if I need to.  Him repeating himself is
> not going to help - because he has already said it the best way he could
> find to say it.  Saying it a second time, he could only be saying it a
> second best way.

Some day when you are feeling ambitious, take a gander at Knuth's "The
Art of Computer Programming."  Reading Knuth is hard; he writes well but
succinctly.  A twenty-page assignment is a huge chunk of text.  But none
of is wrong, or hand-holding, or repetitious.  The one thing you might
not expect is that the answers to exercises sections includes ideas only
mentioned in that section.  I think of reading TAOCP as reading poetry;
you read a bit, reflect a lot, and then read a bit more.

--Scott David Daniels
[EMAIL PROTECTED]

___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Chuck Allison]

Hello Jeffrey,

Friday, June 3, 2005, 7:08:29 AM, you wrote:

JE> I "taught" VB for a year, and was amazed to find out that I made it
JE> through the entire year without either myself or my students (naturally)
JE> learning much of anything about programming.  To be fair, that is not
JE> the fault of the tool itself (though the tool did contribute to the
JE> problem), but rather the fault of the approach used to teaching it (it
JE> was my fault, in other words, but let me explain ;-).

This is a major issue in software development. Much has been said
about "90-day wonders" during the dot-com boom, who learned a little
VB, enough to drag-and-drop their way into a "job". The ranks of these
people have a lot to do with the sad state of software quality (there
is a lot of research on this actually - it's called "The Battle of the
Exponents" - the number of VB coders exceeds our ability to train them
properly, and we're losing this battle). I think VB is the absolute
worst way to introduce programming, and emphasizing GUI in a first
exposure to computing is a mistake. Event-driven programming is a
narrow, over-emphasized slice of the software experience, and is
particular damaging to start a CS major off that way. I think there is
more than just a little deception in luring people into CS with a
visual approach, just to have them fail later on because they didn't
know what CS was really about. If you want to do that with IS majors,
go ahead, but not CS majors. It's just plain evil.

I think Python can fix a lot of this. I've actually been "concerned"
that if we switch to Python, they'll learn CS concepts too quickly,
and we'll run out of things to do in four years :-).

-- 
Best regards,
 Chuck

___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Arthur]

> Behalf Of Radenski, Atanas
> > Behalf Of Bob Noonan
> 


> GUI programming is relatively complex. To understand it, one needs to
> understand event handling. I have hard time explaining event handling to
> beginners and see that beginners have hard time understanding it. While
> GUI programming is complex from beginner's perspective, it does not
> offer many interesting algorithmic problems.

Right.  After hearing people discussing closures and not closures for some
time, and not needing to understand the concept, and therefore not
understanding the concept, I ran into a concrete GUI problem (in tkinter as
it happens) and a little googling helped me find some information posted up
by Scott David Daniels that addressed my concrete problem and did so via an
implementation and explanation of the closure concept.
 
> I believe that we humans are really good at linear communication. Most
> animals see and understand pictures. We humans have the exclusive
> capability of speaking and hearing *linear sequences* of sounds, while
> animals are not particularly good at that. We are also good in reading
> and writing sequences of characters while no known animals can do that.

A bit OT perhaps but I do wish pedagogical approaches had more respect and
insight into our non-linear nature, especially when it comes to the learning
process.  I just don't remember any coursework where we said, "now having
gotten through Chapter 8, we are going to circle back around to Chapter 3
and 4 again and redo it, and we will get things from it - with Chapters 5-8
under our belt - that we undoubtedly missed the first time around.  Left to
my own resources, this is exactly how I approach and successfully learn
subjects like math and programming - absolutely consistently.

Kirby mentions the Guido tutorial in a recent post.

Its not like I worked it once and left it behind.  I did a once over
lightly, and then probably iterated over at least portions of it 7 or 8
different times, at different points of my early process, each time getting
different things from it. I'm sure if I did it today, I would still learn
something new from it.

The Internet, with Google and the like, is a great non-linear resource. The
beauty of it being that nobody really designed it as such.  It sort of
happened.

Left untouched it is a great learning environment. When we intercede to
create a more ordered learning environment, it seems to me that we are
always tending to linearize it somehow, and therefore reducing it from what
it already is.

What we need to do to turn the Internet into a learning environment is
pretty much nothing.  Activists (and business folk) seemed to have a problem
with that approach.

I am only a modified Luddite.

Art




___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Jeffrey Elkner]

On Fri, 2005-06-03 at 01:59 -0700, Toby Donaldson wrote:
> When I taught VB (Visual BASIC), however, the GUIs were great, and
> students almost universally said the course was more interesting and
> enjoyable because of them. In part, they liked the fact that their
> programs looked like real programs, and that there was some room for
> creativity in how they organized their interfaces. Student were often
> driven to do extra programming by a desire to add or fix features they
> had seen in programs. I liked the fact that there was a very clear
> design phase where you had to sketch out the interface. Talking about
> the interfaces was a good way to talk about the program without
> talking about the source code. This helped students organize their
> source code, and to see first-hand the benefits of modularity, i.e.
> they were always writing the code for widgets in specially-named
> functions. Also, GUI widgets roughly correspond to programming
> concepts, when deciding if you want to use a text book or a list
> (say), you are indirectly deciding which data s!
>  tructure you want to use. Some students said they thought that
> learning VB first made it easier to understand Java-like OO GUI
> models.

Toby, check out pythoncard (http://pythoncard.sourceforge.net/).  I have
a student this year, Daniel Caughran, who used it for his science fair
project, and he compares the experience favorably to using VB (with
which he is familiar).  He was able to put together a very useful GUI
program with a minimum of effort.  Version 1.0 will be out soon.  It
looks like teachers using Python can now offer their students the
advantages of VB without the disadvantages.

> As much as I like Python and dislike the BASIC part of VB, I do have
> to admit that my experiences with VB were probably the best I ever had
> teaching introductory programming (although it wasn't quite a CS1
> course, just a humble introduction to "event-driven" programming).

I "taught" VB for a year, and was amazed to find out that I made it
through the entire year without either myself or my students (naturally)
learning much of anything about programming.  To be fair, that is not
the fault of the tool itself (though the tool did contribute to the
problem), but rather the fault of the approach used to teaching it (it
was my fault, in other words, but let me explain ;-).

We used a Shelly Cashman book as the textbook for the course (I had
nothing to do with choosing it).  These books seem to be popular with
some folks inside the school system because they keep students busy (and
thus, the reasoning goes, out of trouble).  They also teach students
almost nothing.  Long, complex procedures are illustrated step-by-step,
with screen shots showing exactly what the screen should look like at
each stage.  Students are able to follow the instructions step-by-step
to achieve the desired result (thus they are kept busy), but the focus
is almost exclusively on the environment and the procedures are way to
complex for students to be able to extrapolate much of use from the
experience.

It is my hope that the grass roots nature of the Python community will
prevent this same kind of thing from happening with our teaching
materials, particularly as more and more people are using Python.  The
eclectic, cross platform, multi-environment nature of Python programming
will make it difficult for a Shelly Cashman type book to be written.  Or
at least we can hope...

-- 
Jeffrey Elkner <[EMAIL PROTECTED]>
Open Book Project 

___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Toby Donaldson]

> The problem is that GUI programming is given significant coverage in 
> most mainstream introductory CS textbooks. Open an arbitrary Java-based 
> textbook and you are likely to face GUIs from almost the beginning. 
> Sample programs and exercises often come with GUI shells that obscure 
> their essential non-GUI parts. I find the dominance of GUIs in java-based 
> introductory books troublesome. 

I agree that the overhead of writing hand-made Swing GUIs can be overwhelming, 
and that beginners should instead focus on clear and simple expression of 
algorithms and ideas. I too have struggled with Java and Swing, and have pretty 
much just given up on it and told students the bare minimum of what they need 
to know to get things going, with the promise that the underyling details of 
how it all works will be revealed in later CS courses. I have not yet decided 
if this encourages or discourages students from taking more CS courses. :-)

When I taught VB (Visual BASIC), however, the GUIs were great, and students 
almost universally said the course was more interesting and enjoyable because 
of them. In part, they liked the fact that their programs looked like real 
programs, and that there was some room for creativity in how they organized 
their interfaces. Student were often driven to do extra programming by a desire 
to add or fix features they had seen in programs. I liked the fact that there 
was a very clear design phase where you had to sketch out the interface. 
Talking about the interfaces was a good way to talk about the program without 
talking about the source code. This helped students organize their source code, 
and to see first-hand the benefits of modularity, i.e. they were always writing 
the code for widgets in specially-named functions. Also, GUI widgets roughly 
correspond to programming concepts, when deciding if you want to use a text 
book or a list (say), you are indirectly deciding which data s!
 tructure you want to use. Some students said they thought that learning VB 
first made it easier to understand Java-like OO GUI models.

So far, in our Python courses, we haven't gotten around to any GUI programming, 
although its on the books to be included.

Of course, VB is an integrated tool for GUI development, so you can't fairly 
compare it to the process of making hand-made Swing GUIs. 

As much as I like Python and dislike the BASIC part of VB, I do have to admit 
that my experiences with VB were probably the best I ever had teaching 
introductory programming (although it wasn't quite a CS1 course, just a humble 
introduction to "event-driven" programming).

Toby


___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Chuck Allison]

Hello Atanas,

I agree with this post 100%. GUIs require a fairly good understanding
of event loops and OOP. They confuse beginners who have to look at the
code as well as the pictures. They are, however, a good example of
quality OO design, once the students have a little experience.

Thursday, June 2, 2005, 7:42:34 PM, you wrote:


>> -Original Message-
>> Behalf Of Bob Noonan

>> The one place where Python is clearly deficient IMHO is in GUI
RA> programming.

RA> While this might be true, I do not feel it is a problem. The problem is
RA> that GUI programming is given significant coverage in most mainstream
RA> introductory CS textbooks. Open an arbitrary Java-based textbook and you
RA> are likely to face GUIs from almost the beginning. Sample programs and
RA> exercises often come with GUI shells that obscure their essential
RA> non-GUI parts. I find the dominance of GUIs in java-based introductory
RA> books troublesome. 

RA> GUI programming is relatively complex. To understand it, one needs to
RA> understand event handling. I have hard time explaining event handling to
RA> beginners and see that beginners have hard time understanding it. While
RA> GUI programming is complex from beginner's perspective, it does not
RA> offer many interesting algorithmic problems. 

RA> I believe that we humans are really good at linear communication. Most
RA> animals see and understand pictures. We humans have the exclusive
RA> capability of speaking and hearing *linear sequences* of sounds, while
RA> animals are not particularly good at that. We are also good in reading
RA> and writing sequences of characters while no known animals can do that.

RA> Some folks say that a picture can easily show what a thousand words
RA> cannot. Well, there is nothing you cannot express with words, but there
RA> are many things that you cannot express, at least not easily, with
RA> pictures. You do not need to try translating Shakespeare into pictures
RA> to see how hard that would be, just try writing technical emails in this
RA> list using pictures.

RA> My point is that GUI should not be overweighed in intro CS courses. GUIs
RA> have some place, but certainly not central place in such courses.
RA> Python's interactive mode, without GUIs, is great way to teach
RA> introductory level programming. Therefore, a possible Python deficiency
RA> in the GUI area should not be considered a problem at all.

RA> I apologize for this non-technical message. I was tempted to write it
RA> because I have struggled way too much teaching too much GUI programming
RA> in intro level CS courses.

RA> Atanas

RA> Atanas Radenski  

RA> mailto:[EMAIL PROTECTED]  http://www.chapman.edu/~radenski/

RA> ___
RA> Edu-sig mailing list
RA> Edu-sig@python.org
RA> http://mail.python.org/mailman/listinfo/edu-sig



-- 
Best regards,
 Chuck

___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Arthur]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Arthur
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> > Behalf Of Radenski, Atanas
> > > -Original Message-
> > > Behalf Of Bob Noonan
> >
> > > The one place where Python is clearly deficient IMHO is in GUI
> > programming.
> >
> > While this might be true, I do not feel it is a problem. The problem is
> > that GUI programming is given significant coverage in most mainstream
> > introductory CS textbooks.
> 
> FWIW, the text I am currently working with/from - "Practical Common Lisp"
> does not as yet (Chapter 8) touch GUI programming, and I am not expecting
> that it will at all.

There is also, BTW, embedded respect for Python within the text.  It does
not mean to be a text introductory to programming.  And sometimes points are
made by comparing Lisp features to similar or analogous one's of other
programming languages, often in footnotes.  And in all cases when doing so,
Python is included among the languages (usually with Java and Perl) that are
being discussed.  I think that's a pretty impressive testimony in itself to
Python's current place in the universe.

Art



> 
> I think, BTW, it is an excellent effort, with an excellent pedagogical
> approach.
> 
> Chapter 1 is purely introductory salesmanship "Why Lisp", within the
> expectations of what might find in a book devoted to that subject.
> 
> Chapter 2 is the "Hello World" stuff from the interactive prompt.
> 
> And I am afraid I am embarking on the typical linear "building-block"
> approach, which will force me (being who I am) to be skipping ahead
> chapters
> to see where we are going, in order to make an assessment as to whether we
> are going to an interesting enough place for me to hang with the building
> of
> the blocks.
> 
> But Chapter 3 is unexpected - it takes us through creating a simple but
> functional database, with persistency, "select" and "update" and "delete"
> calls with fairly standard database syntax, and through it we get a taste
> of
> function passing, and macro writing, until it's all refactored down to
> maybe
> 35 lines of code that I actually feel I understand. And I would certainly
> not see a non-Lisp way of writing it as efficiently. So by Chapter 3 the
> author has made good on some of the claims of Chapter 1.
> 
> And I no longer feel I need to skip ahead to anything.  I'm sold on the
> effort, and willing to bear some of the drudgery that necessarily follows
> when we do back up a bit and start filling in some of the details of
> syntax
> and semantics. (some of it quite ugly when one is used to Python)
> 
> The author communicates respect for his audience.  He says things once.
> Even hard things.  It doesn't mean he expects me to get it on reading it
> once, but we understand each other I think - there is nothing stopping me
> from reading it five or six times if I need to.  Him repeating himself is
> not going to help - because he has already said it the best way he could
> find to say it.  Saying it a second time, he could only be saying it a
> second best way.
> 
> Nice job Mr. Seibel.
> 
> Back to the point - I would find GUI issues mostly a distraction, and
> don't
> regret at all that it is not being covered.
> 
> GUI building seems to be dominated by tools.  Couldn't the argument might
> be
> made that GUI building can only really be taught in the context of a
> specific development environment, rather than in the abstract.
> 
> Python has many such environments.
> 
> Lisp has Allegro Lisp which is an almost VB like environment. If GUI
> building in Lisp ever became a practical issue for me (I don't expect it
> will), I would probably cop out by becoming comfortable with the Allegro
> environment.
> 
> Art
> 
> 
> 
> 
> ___
> Edu-sig mailing list
> Edu-sig@python.org
> http://mail.python.org/mailman/listinfo/edu-sig


___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig

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

[Arthur]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Radenski, Atanas
> Sent: Thursday, June 02, 2005 9:43 PM
> To: Bob Noonan; edu-sig@python.org
> Subject: [Edu-sig] A case against GUIs in intro CS :-)
> 
> 
> > -Original Message-
> > Behalf Of Bob Noonan
> 
> > The one place where Python is clearly deficient IMHO is in GUI
> programming.
> 
> While this might be true, I do not feel it is a problem. The problem is
> that GUI programming is given significant coverage in most mainstream
> introductory CS textbooks. 

FWIW, the text I am currently working with/from - "Practical Common Lisp" -
does not as yet (Chapter 8) touch GUI programming, and I am not expecting
that it will at all.

I think, BTW, it is an excellent effort, with an excellent pedagogical
approach.

Chapter 1 is purely introductory salesmanship "Why Lisp", within the
expectations of what might find in a book devoted to that subject.

Chapter 2 is the "Hello World" stuff from the interactive prompt.

And I am afraid I am embarking on the typical linear "building-block"
approach, which will force me (being who I am) to be skipping ahead chapters
to see where we are going, in order to make an assessment as to whether we
are going to an interesting enough place for me to hang with the building of
the blocks. 

But Chapter 3 is unexpected - it takes us through creating a simple but
functional database, with persistency, "select" and "update" and "delete"
calls with fairly standard database syntax, and through it we get a taste of
function passing, and macro writing, until it's all refactored down to maybe
35 lines of code that I actually feel I understand. And I would certainly
not see a non-Lisp way of writing it as efficiently. So by Chapter 3 the
author has made good on some of the claims of Chapter 1.  

And I no longer feel I need to skip ahead to anything.  I'm sold on the
effort, and willing to bear some of the drudgery that necessarily follows
when we do back up a bit and start filling in some of the details of syntax
and semantics. (some of it quite ugly when one is used to Python)

The author communicates respect for his audience.  He says things once.
Even hard things.  It doesn't mean he expects me to get it on reading it
once, but we understand each other I think - there is nothing stopping me
from reading it five or six times if I need to.  Him repeating himself is
not going to help - because he has already said it the best way he could
find to say it.  Saying it a second time, he could only be saying it a
second best way.

Nice job Mr. Seibel.

Back to the point - I would find GUI issues mostly a distraction, and don't
regret at all that it is not being covered.

GUI building seems to be dominated by tools.  Couldn't the argument might be
made that GUI building can only really be taught in the context of a
specific development environment, rather than in the abstract.  

Python has many such environments.  

Lisp has Allegro Lisp which is an almost VB like environment. If GUI
building in Lisp ever became a practical issue for me (I don't expect it
will), I would probably cop out by becoming comfortable with the Allegro
environment.

Art




___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig