Mailman 3 April 2014 - Edu-sig

a short essay about programming
by kirby urner 08 Dec '22

08 Dec '22

A common "error" (not too serious) that I see in beginning Python (and no doubt other languages, but Python is the one I'm teaching), is having a while condition that appears to put a lid on things, but then the flow all leaks away through break statements, such that the "front door" condition is never revisited. while guess != secret: guess = int(input("Guess?: ") if guess == secret: print("You guessed it!") break else: print("Nope, try again...") What's messed up about the above code is you never really go back to the top in the case where you'd get to leave. Rather, you exit by the back door, through break. So in that case, wouldn't have been simpler and more elegant, even more "correct" (dare I say it) to have gone: while True: # no ifs ands or buts guess = int(input("Guess?: ") if guess == secret: print("You guessed it!") break else: print("Nope, try again...") I see lots of heads nodding, and that could be the end of the matter, but then a next question arises: wouldn't this also be a more correct solution?: while guess != secret: guess = int(input("Guess?: ") if guess == secret: print("You guessed it!") continue # instead of break else: print("Nope, try again...") We're back to having a variable while condition, not a boolean constant, but this time we actually exit by means of it, thanks to continue or... while guess != secret: guess = int(input("Guess?: ") if guess == secret: print("You guessed it!") else: print("Nope, try again...") ... thanks to no continue. This last one is getting a thumbs up, but then I'd pause here and say "continue" can be easier on the eyes. It's unambiguous where it takes you, in contrast to having to scan on down the gauntlet, looking for possibly other open doors. "What happens next" should not require scanning ahead too far. Help us not to get lost. Be a civic-minded coder. I'm thinking of a programming style that advises two things: (a) if you use a while condition that's variable, that's expected to change, then your goal should be to always exit because of that, i.e. that should be your only exit point. Even if some other criterion suggests exiting, you have the option to flip that "lid" at the top, to crack that front door, and bounce the ball out. (b) which is why 'continue' is your friend. You are showing the user where your 'break' statements are, except you don't use "break" statements, as you've given a non-constant condition, and your aim is to make that your ONLY exit point. In short: never use break to exit a while loop unless your condition is while True. Instead, always flip the condition and exit through the font door. However, as soon as I make that rule I can think of good reasons to break it. The other programmers in the room are shaking their heads. Won't we lose information, needed elsewhere in the program, if we "artificially" force a True condition to False. Aren't we, in effect, lying? That concern could be addressed. Keep all the info true, just treat the "lid condition" (it "keeps a lid on it") as a flag. Go ahead and remember the user's guess. allowed = 5 tries = 1 exit = False while not exit: # no other way out guess = int(input("Guess?: ") if guess == secret: print("You guessed it!") exit = True # instead of break continue print("Nope, try again...") tries += 1 if tries == allowed: print("You've maxed out") exit = True continue I think we all understand the main issue: writing reader-friendly code, and rules for doing so. There's something comforting about approaching a while loop and knowing its not a leaky sieve, riddled with back doors, maybe even an exit( ) time bomb. But in the recursion world we want a minimum of two exits usually: when another round is called for versus when we've "hit bottom". Can we have it both ways? Conclusions: Lets not be too hasty with rules of thumb and: Lets keep the reader in mind when writing code. Just because the interpreter knows to compute the flow unambiguously, doesn't mean all ways of writing it are equally reader-friendly. What may seem a gratuitous gesture, an unnecessary flourish, may actually promote reader comprehension of your code, and that should be a goal as much as satisfying the interpreter. Kirby

8 17

Collaborate on Reeborg's World using Mozzilla TogetherJS
by Andre Roberge 29 Apr '14

29 Apr '14

If you go to http://reeborg.ca/world.html and click on "Start TogetherJS" at the top, you can get a URL to share with others. This hopefully will be found useful by teachers who can help their students remotely. Note that the exact location of the Start TogetherJS button may change in the near future. André

1 0

Talk by Seymour Papert & Robin Jettinghoff
by Daniel Ajoy 25 Apr '14

25 Apr '14

https://www.youtube.com/watch?v=4iIqLc0sjjs (1h 16m) On April 28, 2004, Seymour Papert and Robin Jettinghoff gave a presentation at the University of Maine on some materials that they prepared for helping students understand mathematics. (Published on Jul 1, 2012)

1 0

Course on Beginning Python
by Matt Harrison 24 Apr '14

24 Apr '14

Hi, I have created a multimedia Beginning Python course [0] and am looking for another reviewer or two. Please reply to me off list if you are interested. Cheers, Matt 0 - http://hairysun.com/90py/

1 0

Processing and Python
by Jurgis Pralgauskis 24 Apr '14

24 Apr '14

Hi, I enjoyed Processing for C++/Java teaching, and now I stumbled upon Python alternatives, most of them are mentioned here http://secondcomingforprocessingpy.blogspot.com/ pyprocessing, processing.py, NodeBox, RapydScript RapydScript works in a browser! :) http://rapydscript.pyjeon.com/, http://salvatore.pythonanywhere.com/RapydScript Maybe smb has experience with them or maybe will get interested :) -- Jurgis Pralgauskis tel: 8-616 77613; Don't worry, be happy and make things better ;) http://galvosukykla.lt

2 4

Reeborg's World: quick Python tutorial
by Andre Roberge 20 Apr '14

20 Apr '14

Reeborg's world (http://reeborg.ca/world.html) currently supports Python, Javascript and CoffeeScript as programming language. It is my intention to add more languages if possible - provided I can find a transpiler written in Javascript to convert from language X to Javascript so that everything can run entirely in the browser. I *will* write a slow-pace Python tutorial so that absolute beginners will be able to learn programming using Python in Reeborg's world, like many have done using rur-ple, the desktop version. In the meantime, I have written a super-quick Python tutorial for people that already know how to program but do not know Python. (My intention is to write such quick tutorials for every language supported by Reeborg's world; of course Python had to be first!) I would *really* appreciate if any of you could have a look at http://reeborg.ca/quick_python.html and give me feedback as to what should be added/modified in order to give a good overview of Python to non-Python programmers. Cheers, André

1 0

learn.code.org
by Jurgis Pralgauskis 17 Apr '14

17 Apr '14

Hi, very nice introduction to coding based on Blocky http://learn.code.org/ :) *** And many more tools http://code.org/learn Though could mention more PyTools http://www.codeskulptor.org/ , http://reeborg.ca/, maybe http://pythontutor.com/ :) -- Jurgis Pralgauskis tel: 8-616 77613; Don't worry, be happy and make things better ;) http://galvosukykla.lt

1 0

the idea of "CS-friendly" algebra courses...
by kirby urner 15 Apr '14

15 Apr '14

Re: http://mathforum.org/kb/message.jspa?messageID=9430209 The above-linked thread might garner some forking threads or comment lines here. This branch is mostly dormant on math-teach as of today, but points back to an earlier thread that evoked much discussion (so well may take off again), which discussion I boldly dare to summarize here: http://mathforum.org/kb/message.jspa?messageID=9432446 (long-winded and skipable without losing the plot line) We're in the thick of it, Python-wise, which is why I bring our thread up here on edu-sig. The gist of the math-teach thread is that given changes in some states, it's getting easier to give math credit for high school courses we might call "digital flavored" meaning (in part) a computer language enters in, maybe more than one. Hardly a "new thing" for a lot of us in math teaching, who've used Logo since the 1960s or whatever, but the status quo in secondary schools has been to relegate CS (computer stuff) to elective status and make a 3-year's worth of math credits mandatory, with nothing CS-like counting towards fulfilling that requirement. Algebra, trig, stats and of anything-like-calculus -- that was it for math credit. But nothing like Python. Computer Stuff was elective-only and in a state such as Oregon using property taxes for schools (disbursement formula since changed) only the few best neighborhood public schools had any computers to begin with (which was probably why they set it up that way, to not let CS count). This was before you could get a computer for $45 dollars (Raspberry Pi less the peripherals you also need). This status quo is what has changed in some of the less backward US states, thanks to various lobbies and special /overlapping interests. New laws have been or are in the process of being passed, including in Oregon. The older linked thread on math-teach takes a look at some of the back stories. In many states, the new laws allow Computer Stuff to count more towards the 3-years of math credit these same states require. [ You may still do a lot of calculus stuff in a digital flavored math course, since digital technology is a fine tool for studying calculus concepts... but lots of other stuff too. ] I think many in Europe e.g Austria have never had a problem with a turtle.py in math class, whereas any programming in the US public sphere was automatically painted into the CS corner as AP this or that. Private schools could organize differently. The new emphasis on STEM is changing the dynamics, since it's more of an integral whole, not that friendly to being carved up into this and that. To draw a line in the sand and say it's math-for-credit on this side and CS-not-math-credit on that side was not making sense to a lot of STEM people. Kirby

3 6

OSCON opens, lets look at the Python track...
by kirby urner 14 Apr '14

14 Apr '14

Just topping up at Pycon? Wait, there's more: http://www.oscon.com/oscon2014/public/schedule/topic/1128 However, many more talks than these may mention or use Python as all tracks are partially overlapping in various ways (like a basket of snakes alive!). Sssssss. I was one of the readers of talk proposals but the final cut is up to the program chair. Over 1000 submittals this year! Some potentially great talks didn't make it simply for lack of formal track space. Great to have such a rich space to choose from. Kirby

1 0

Abducted by Decorators (niche market, esoteric TV allusions)
by kirby urner 07 Apr '14

07 Apr '14

""" Learning about Decorators "Just for the fun of it" -- OCN Decorators as Abductors I'm thinking in terms of a specific (aborted) TV series, but the pattern: me = Abduct(me) # @Abduct a callable has generic resonance as a metaphor. Specifically: http://en.wikipedia.org/wiki/Invasion_%28TV_series%29 Storyline (from imdb.com) In the aftermath of a hurricane, a Florida Park Ranger and his family deal with strange occurrences, including luminescent creatures in the water and people that somehow seem to have changed after surviving the night of the disaster out in the open. Written by Anonymous Wikipedia: In Bulgaria, Invasion premiered on February 21, 2007, on Nova Television and in Romania it premiered on March 10, 2009, on Pro Cinema movie channel. OUTPUT: She loves her babies. She loves her babies (not!). """ def Floridian(s): # this all happens in Florida return s # BEFORE: print( Floridian("She loves her babies.")) def Alien(f): # A is for Abduction """luminiscent creature in the water""" def FauxFloridian(s): # a clone return s[:-1] + " (not!)." # a change return FauxFloridian @Alien def Floridian(s): # same function return s # AFTER: # she = Dr. Mariel Underlay print( Floridian("She loves her babies."))

1 0