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
