
Re: Structured Programming
Posted:
Mar 6, 2014 10:53 PM


> And yes, it was me that said ?subroutine? and I did > that to make sure that kirby understood he was > talking about blocks of code that could be invoked > wholly from elsewhere in a program, optionally passed > parameters, and optionally return values. These > parameters and values being either registers, stack > locations or pointers to memory locations. He seems > to be trying to make the case that all of that is the > essence of a mathematical function. Even though we > had an agreement that all of that should come after > algebra and after the student learns the actual > essence of mathematical functions first, before they > try to implement them computationally in subroutines. > We even shook on it. Obviously, he had his fingers > crossed behind his back. > > Bob Hansen
I'm sticking to our agreement: let them take Algebra first and lets just hope and pray their Algebra doesn't just have the dumbed down, diluted "numbers only" view of functions, as if they really were just little machines designed for number crunching and nothing more.[1]
How mindblowingly narrow a view that is, how inappropriate in this day and age, when "number crunching" is just a small fraction of what goes on in STEM and its many computations, which include string operations galore (so can we at least show a couple string ops please? Concatenation maybe?  typical answer: no, if you calculator can't do it, we don't cover it).
My point with def f(x): return x * x looking so much like ordinary algebra was this: we can dispense with calculators in favor of much higher power computers that take the tedium out of repetition in ways those calculators never could. They can read and write files for one thing. We can explicitly write little functions and save our work, come back to them the next day, enhance them, save our own comments next to them and so on. We do this with pencil and paper now, but those implementations, in graphite on wood pulp, don't "run" (as in "execute"). We never get to see the forest for the trees as we get bogged down in the details.
If there's any merit at all to using calculators post Algebra (some say there's not), then computers offer all the same merits, except a big screen is not portable and has to be left behind in the math lab. You have a different screen at home.
You also have the bash shell both in the lab and at home and learn that the pipe character "" is a lot like function composition. Instead of writing f(g(h(q(x)))) you might go > q < x  h  g  f (were q < x means q should read in file x)  an interesting connection to make.[3]
We can show you how to implement q, h, g and f so they work just that way, with a pipe character. Thanks to Algebra, the content of which we continue to review, "composition of functions" is a very familiar concept and you learn to generalize to where you see it in more and more special cases (i.e. you're learning to "think like a mathematician" in having a vocabulary for patterns you see everywhere, once you know where/how to look).
With a computer, I can investigate Euler's number e in a playful manner, feeding a high precision decimal to (1 + 1/n)**n and getting e to 300 decimal places, as crosschecked with a public source.[2] Calculators are just too wimpy to do that. That's just one example of doing something "superhuman" (e to 300 places in a single computation) that is nevertheless mathematically intelligible and conceptually reinforcing. Another example: rotating a colorful polyhedron on screen with a rotation matrix. With pencil and paper, it's tedious and therefore wimpy. On a computer, which you the student programmed, it's 30 frames a second.
I'm talking about giving high school students a lot more raw power. That's probably what sparks a lot of the resistance: little children coding turtles to spell "I love mommy" are sweet, but high schoolers at the bash shell... that sounds like "hackers" in the making and suddenly the adults are afraid and start backing away.
Kirby
[1] http://mathforum.org/kb/message.jspa?messageID=9398575
[2] https://mail.python.org/pipermail/edusig/2014March/010951.html
[3] http://en.wikipedia.org/wiki/Pipeline_%28Unix%29
""" Unix pipeline can be thought of as left associative infix operation whose operands are programs with parameters. Programatically all programs in pipeline run at the same time (in parallel), but, looking at syntax, it can be thought that one runs after another. It is a functional composition. One can be reminded of functional programming, where data is passed from one function to another (as their input or output). """
  "functional composition" is a direct link to the *mathematical* (!) description of what that means.

