Re: [Edu-sig] A case against GUIs in intro CS :-)
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 wink. 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 :-)
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 :-)
-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 :-)
-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 :-)
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 :-)
-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
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
-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 :-)
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 :-)
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 :-)
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 :-)
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 :-)
-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 :-)
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 :-)
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 :-)
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 http://ibiblio.org/obp ___ 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 :-)
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 :-)
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 :-)
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 :-)
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 :-)
-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
Re: [Edu-sig] A case against GUIs in intro CS :-)
-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
