Algo-rhythm

While surfing around last night, thinking about interactive applications that would be good for kids and good for the kids who designed the apps, I came across this article. I like the explanations in it, the way they are presented in straightforward English, and the way they describe what I think a lot of people who want kids to get some exposure to computer science would explain the long term benefit from taking such a course.

In my day (early to mid 1970s) we learned Fortran with IF statements, DO loops, and DIMENSION Arrays. The first time I was exposed to Fortran, as a 12th grader taking a Saturday course at NYU, the type of algorithms we played with were intellectual but totally frivolous. I recall that my friend Michael wrote a program to verify Euclid's prime postulate. EUCPP says that for any odd number one can find two primes that bound exactly that number of composites. 17 and 19 bound 18, one composite. 13 and 17 bound 14, 15, and 16, three composites. 23 and 29 bound 24, 25, 26, 27, and 28, five composites, etc. This is great fun for nerds and having written a program already to imitate the Sieve of Aristophanes, it is the next step in prime number theory. But in terms of practical decision making.....nada.

I did take a college course that covered Fortran and in 1977 did some real programming for Econometrics whle at Northwestern. My recollection is that an Econometrics Prof hired me to do something called error components estimation, Maddala was the econometrician who developed the technique, which kept the simplicity of ordinary least squares while managing to address both cross section and time series issues. I originally wrote a program in TSP, but exceeded the capacity of the compiler, and then had to redo in Fortran. That was my entire career as a programmer. After that I was a theorist.

Nowadays, learning a particular programming language may have some value, but the real power is to be able to think algorithmically. It's the 21st century equivalent of fixing old cars in the garage. There is a lot of learning in the tinkering.

For any algorithm that is even modestly complex it is hard to check its correctness purely via logic and introspection. Instead one tries it out in a variety of scenarios. There is intelligence in the choice of scenarios to test. If a test fails one has to modify the algorithm. In that sense, the failure is actually a success. It helps to harden the approach and make it robust.

Designing algorithms that do functional things that are useful to others is really a great way to learn. If we think of courseware, especially highly interactive courseware, as algorithmic in conception this is a really good reason for students to do the designing. My view is that we need this, really good courseware with a lot of interactivity and students being the primary creators of this content.