On Saturday 09 September 2006 12:35 pm, you wrote: <snip> > But mostly I'm advocating going to the other extreme: drop GUI as a > topic and just code up a namespace, reach into the grab bag for > functions, like f(x) or cos(x). We pretend kids don't have the > background, but if they did *any* work with a TI calculator or an > algebra course, they know about functions, at least tacitly. > > My prerequisite for my Saturday Academy class is algebra only, and > typing above 30 a minute really helps (a lot of 'em are getting that > from chat rooms these days, buy a typing drill for home). >
As I said below, I'm all for this kind of interaction, and when input and raw_input go away, I'll probably do more of it. > > While I accept the power of twiddling in the shell particularly as an > > educational tool (again, I come from a Lisp/Prolog tradition), this > > statement is just silly. How can you define "state of the art" for any > > "self" but your own. When I write a script to automate some routine task, > > I virtually always > > I can define it for my gnu math teachers, the people I work with in > South Africa for example. This, of course, misses my whole point that you can't define "state of the art" in "programming for self" for others (me, for example). > > use interactive text input. Why? Because the whole point is to make > > something routine and automatic. Why would I write a program that forces > > me to: Start Python > > Import a module > > Recall what I'm suppose to invoke and what information it needs. > > Sounds like your "program" is one of these top-to-bottom > glued-together script thingys. We don't teach that way. Modules are > grab bags, perhaps containing rich data structures (lat/long > dictionary say). Modules define namespaces, like boxes of chocolates > (Forest Gump understands). First up, I was not talking about the way I teach, but the way I program to automate my environment. To use your terms: defining state of the art in programming for myself. Your model is less convenient for these tasks than the one I describe. Further, I highly doubt that the script I'm writing for those purposes are any less modular than they should be to get the job done. Namespaces are a wonderful tool (which I use liberally), but don't confuse being modular with being good. There's plenty of bad modularity too. > This need to glue it all together with some main() -- why? We compete > with that idea of "programming." We're not a part of *that* > particular conspiracy. Umm, the point of my program is to automate something. That's why I glue it together. If I don't do that, I haven't solved the problem I set out to solve. I'm only 'conspiring' to solve the problems I have at hand. > Last week, we were working on phi and the fibonaccis. Let's get back > to that now. Pull out a file drawer (import) and behold: all our > favorite specimens (even the bugs are back). Great. Fantastic. It has nothing to do with what I was describing. I have plenty of these experimental evnrionments as well. > > > Instead I can write an incredibly simply script that I just click on, and > > when it needs information it prompts me for it. That's _my_ state of the > > art in programming for myself. And it's something I can teach students to > > do for themselves in very short order. > > Yeah, we don't like that style. OK for you, works for your students, > I think you're probably a dynamite teacher. But... we still don't > like that style. Again, I'm talking about writing a useful tool to automate some mundane task. What's "not to like about that style"? Should I make automating that task harder so as to fit your pedagogical style? My arguments had nothing to do with how you or I go about teaching math. > Later on maybe, if/when they're committed to CS. But this is just > basic numeracy here, and they already know about functions from > calculators. > > import math > math.cos( 90 * math.degrees) > > -- that's what a first class might include. If what stops 'em isn't > the Python syntax, but the trig, then we go over the trig. Basic > numeracy. All as a bundle. Not your grandfathers math class (but > some hoped it'd be for their kids -- remember when the future was, > well, futuristic?). Again, this sounds great. I like it, and I'm glad you're doing it. And you don't need raw_input (or input). But having input available in no way impedes this, and for the tasks I'm describing, lack of the same is a hindrance. > > Whether I'm writing for myself or whether I want my students to be able > > to write the simplest possible useful programs for themselves and others, > > that involves textual input. I'll say it one more time: IO is fundamental > > to programming; the simplest universal form of IO deserves to be in the > > core language so that it is easily accessible and available everywhere > > the language runs. Pascal got that right and Python (pre 3000) has it > > right. > > And I'm saying using the shell to trigger namespace events is (a) > closer to what a GUI is doing and (b) is fully usable I/O. Use doc > strings to remind about inputs. raw_input prompts are the new goto > (to be avoided if possible). But it's less convenient and therefore less useful for producing real tools that automate tasks. You are talking about a different form of programming and pedagogy. Docstrings do not solve the problem I describe, because they are passive. I have to go look at them again to remind myself how to use the tool. If I write a program, the program itself knows what it needs and when. > > > As teachers, we shouldn't be propagating the hidden assumptions that > > > go with raw_input, i.e. that there's this class if people out there > > > "too dumb" to know anything about namespaces or functions. > > > > Translate this to any other discipline. Running with my physics example: > > "As teachers, we shouldn't be propogating the hidden assumptions that go > > with Newtonian mechanics, i.e. that there's this class of people out > > there 'too dumb' to know anything about quantum physics or general > > relativity." Does > Right, but I see that as a self-serving analogy. You're *defending* > the status quo. Notice how CP4E goes for like "riding a bicycle" and > "driving a car". Anyone can do it, no big deal. Well far be it for me to suggest an anology that supports what I'm defending :-). Is it true that anyone can write a working GUI program? I don't know if that's any more true than that anyone can comprehend quantum mechanics. But let's use your example: does the fact that we expect everyone to be able to drive a car mean that we _shouldn't_ teach them to ride a bicycle? And shouldn't we even go a step further and take bicycles away because they might learn this useful mode of transportation which is _not_ car driving? Because it sounds to me like this is exactly the argument you are making w.r.t. input. > I think CS has a reflex to fight "debasement" of programming into a > "what your grandmother knows" skill. But that's what I *want* to have > happen, and expect grandmothers *will* have those skills in the not > too distant future. > I hope what you want comes to pass. I can assure you that CS academics have nothing whatsoever against programming as a universal skill, since we profess to believe that CS is much more than programming and say so at every opportunity. I, for one, can't wait to add a bunch more upper-level courses to the major when programming is taken for granted. I'm just not holding my breath... > Latin moms in Rio will tell The Monkey to block those Evil Toons > (point and click yes, but they custom-skinned the GUI, know how it > works from hours study. What, working class folk with the free time to > study what they used have to pay for, plus hold down a job? What a > concept! OK, now I just have no idea what you're talking about. Probably that's because I'm stuck in my dino-world. > > > that really make sense? The fact that there is more advanced stuff that > > they will surely learn in due course is in no way a justification for not > > teaching simpler, useful concepts first. > > Nothing much simpler than import math, using the names. Raw_input is > difficult by contrast. For Gnu-math maybe, but not for the types of useful artifacts I suggested above. And Input is no more difficult than typing expressions (as I've explained) which I assume is the starting point for your Gnu-math. > Why don't calculators have raw_input? They can't do I/O? How about > dashboards? Cockpit of an airplane. You are confusing what's easy for the user with what's easy for the programmer. Underneath, of couse, a modern calculator _does_ have the equivalent of raw_input. It grabs the string constructed in the display, parses and evaluates it. The user interface is all extra baggage built on top of that. From the programmer's standpoint, that extra baggage is more effort. If I already have a console, I can get the useful tool without the extra effort. > We use control surfaces all day long. That's what a namespace is, an > API. You don't need to tie it all together with some main(). This > isn't a script. It's a place to do work. Namespaces are like > studios. Event driven. More GUI, less "programming" (in the 1960s > sense). > Right on. But what I'm talking about _is_ a script. > > > I'm saying this'll all be common knowledge soon. > > > > Define "soon." I see the same demographic as Brad Miller. My students are > > freshman in college who have never programmed. And frankly, I'm OK with > > that. > > And frankly, I'm not. High school too wasteful. If it's really about > sports, which is OK with me, lets do more sports camps. But for kids > who want academic rigor (another kind of sport), it's just not OK to > not even *offer* OO by the end of high school. What if they're not interested in it? I know in your world the schools are hopelessly outdated because they don't teach Gnu math and OO. I'm happy if they teach our children to read and write well and to do some mathematics. I don't even care much what math they do, just as I don't care much what they read and write about. Throw in a basic understanding of science, and a healthy dose of getting along with others, and you've got a curriculum. Of course, one can argue schools are not doing this now, but I don't see how teaching them to program frees up more time for what I consider fundamental skills. If your Gnu-math is better at teaching them some mathematics, that's great; I'm all for it. But I don't care if it teaches them OO. One of the reasons for the conservatism of the educational establishment is that it can be devilishly hard to determine what the core skills are that all educated people should have (unlike other countries, our K-12 system attempts to be universal). You specifically mention OO and Python, but education (currently in the US) is a 13 year program. Will OO still be the dominant paradigm in a dozen years? I have a hunch not. OO institutionalizes side-effects (state change), and side-effects are a bane to managing concurrency. With multi-core, multi-processing machines seeming the most obvious routes to increased computing power, it could be that OO looks as old-fashioned as gotos in a dozen years. Is OO some fundamental/essential skill? I don't think you can measure the value of an education in terms of what specific technologies are learned (and OO is just a technology). Fundamental education is not about what technologies we teach or what technologies we teach with; it's about what kind of citizens we raise. Give my children a good teacher that can really communicate and get the kids excited about _learning_, and what in particular they learn doesn't matter so much. They have their whole lives ahead of them to become great at whatever is meaningful to them. > If USA voters want to keep that status quo, fine, but don't think the > rest of the world will think twice about thrashing us in the job > market if so. Or were we planning to use the Pentagon to keep the > rest of the world stone aged, while we went on being mental couch > potatoes. If so, think again. > Praise the Lord we have television. If the schools have decided to > rust in irrelevance, letting it be OK that globalization passes us by, > then we can do what we did in Sesame Street, except at a much higher > level (still using puppets though -- some of them CGI). This is an interesting juxtaposition of paragraphs. Many studies suggest that TV is the number one contributor to mental couch potatoism. I'd much rather have my kids spending time in our current (backwards, dino-era) schools (at least the ones we have here in Iowa) than watching television, no matter what show is on. Real interactions with live caring people in a social setting is what children need most. No truckloads of DVDs, screencasts, or electronic curriculum of the foreseeable future will change that truth. Until we have truly intelligent machines, there is no substitute authentic interpersonal interaction in terms of communication bandwidth. Education is at its core just communication. > Our Snake with __rib__ syntax makes fun cartoons on TV. It slithers > around like Kaa, eating stuff (eat method). Hah hah, the 3rd graders > laugh. Gnu math is just better. > I have no idea what that paragraph is about. Anyway, this is really, really my last post on this thread. --John ps. And I mean it. -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA [EMAIL PROTECTED] (319) 352-8360 _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
