On 9/8/06, Joshua Zucker <[EMAIL PROTECTED]> wrote: > On 9/8/06, kirby urner <[EMAIL PROTECTED]> wrote: > > I think the model today is "a person writing code for him or herself" > > i.e. "self as client" -- at least in an early context. We're not > > guiding the unknowing through a menu tree. We're computer literate, > > fluent. > > > > Why would we ask ourselves for raw_input, when it's much easier to > > just pass arguments to functions? > > As someone who has taught a lot of functional programming (Scheme), I > have a lot of sympathy for this argument. It wouldn't occur to me to > teach raw_input or its equivalent anywhere early in the course, > because designing functions is what it's all about!
I don't think it's an accident that the Scheme community seems more prepared to teach in a functional style, and treat .py namespaces as fish tanks full of mouthy functions and class type initializers -- both callables. Top-to-bottom executable scripting, with maybe forks in the road, as in: dumb_user_says = raw_input("yes or no?: ") and likely no going back if you answer it wrong: confirm = raw_input("are you sure??") Not that we don't like being asked a 2nd time, but there are other ways to build in security. You might have to actually go into the source and uncomment something (standard in POSIX environments: cut and paste a commented example, tweak and uncomment). You might have to tweak a permission. Very likely, a program with consequences will log its activities. A big part of a sysop's job: know where programs leave audit trails ( /var/syslog or whatever). Companies sometimes have manuals of style. Code that's potentially dangerous should be flagged as such. Various conventions. Often there's a "no anonymous users" policy i.e. you can't run this code if you're not willing to have your real name in the log as the user. But of course hackers are always looking for ways to bypass such restrictions (sometimes to hack into their own systems, when they've been a little too clever, and now can't remember the stupid passphrase or whatever it was). Very often, companies resort to physical dongles, swipe cards, other hardware, to prevent unauthorized access. Anyway, the most primitive module or namespace is the current session, a kind of temporary scratch pad, where we cut and paste the "keepers" to a "final draft" version. Smalltalk has less of this sense of "saving out to permanent storage" and keeps the current scratch pad as the image (unless you don't save it). I wonder about that workflow, but realize you can internalize any file structure you like in an image: Smalltalk tends to seek the outer frame, and provide everything internally (the tablet itself was the "smalltalk machine" with "lid closed hibernation" -- since the 1960s at least). > But the Scheme course I taught also came with a lot of teachpacks > (read: modules to import) that did things like provide an interactive > session with your function (prompting, like raw_input but with more > error handling built in, or GUI). Without those, I might have been > tempted to teach those input functions after all. People have different motives for getting into programming, which need to be taken into account. Some want to impress their mom's with "look mom, no hands" GUI programs, others want to sit in a back office fine tuning statistical analysis programs that will never see the light of day, but which make the company tons of money and adds quality of life to its customers as well. I'm not saying any of these ways is "wrong". But I think we should acknowledge each language brings forward a sense of an interface. Python's is most naturally a shell. That's how it was designed. And that goes will with today's "unit testing" and "extreme programming" best practices. Work interactively at a work bench, debugging, reloading, while saving out "keeper quality" work to intelligently designed modules, properly populated with docstrings etc. Kirby _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig