Re: [Edu-sig] A case against GUIs in intro CS :-)
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 structure 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
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 <jeff@elkner.net> Open Book Project <http://ibiblio.org/obp>
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
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 - nico@tekNico.net 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
On 6/3/05 2:50 PM, "Nicola Larosa" <nico@tekNico.net> 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
On 6/3/05 11:00 AM, "Chuck Allison" <chuck@freshsources.com> 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
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
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 Scott.Daniels@Acm.Org
Hello Toby, Saturday, June 4, 2005, 1:50:30 AM, you wrote: TD> On 6/3/05 11:00 AM, "Chuck Allison" <chuck@freshsources.com> 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
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 - nico@tekNico.net 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
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
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
-----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
-----Original Message----- From: edu-sig-bounces@python.org [mailto:edu-sig-bounces@python.org] 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: edu-sig-bounces@python.org [mailto:edu-sig-bounces@python.org] 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
Behalf Of Arthur So I don't think they are likely to ever uncover the truths here, where
-----Original Message----- From: Arthur [mailto:ajsiegel@optonline.net] To: 'Arthur'; 'Kirby Urner'; 'Edu-sig' 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 (hmmmm... foregoing some nice tax benefits), and concentrate for the time being on the athletic training meme. See how far I get. Art
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 (hmmmm... 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
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
participants (7)
-
Arthur -
Chuck Allison -
Jeffrey Elkner -
Kirby Urner -
Nicola Larosa -
Scott David Daniels -
Toby Donaldson