TITLE: Buried Treasures AUTHOR: Eugene Wallingford DATE: June 29, 2006 11:47 AM DESC: ----- BODY: I finally got around to reading Glenn Vanderburg's Buried Treasure. The theme of his article is "our present is our past, and there's more past in our future". Among his conclusions, Glenn offers some wisdom about programming languages and software education that we all should keep in mind:
What I've concluded is that you can't keep a weak team out of trouble by limiting the power of their tools. The way forward is not figuring out how to achieve acceptable results with weak teams; rather, it's understanding how to build strong teams and how to train programmers to be part of such teams.
Let's stop telling ourselves that potential software developers can't learn to use powerful tools and instead work to figure out how to help them learn. Besides, there is a lot more fun in using powerful tools. Glenn closes his article with a nascent thought of his, an example of how knowing the breadth of our discipline and its history might help a programmer solve a thorny problem. His current thorny problem involves database migration in Rails, and how that interacts with version control. We usually think of version control as tracking static snapshots of a system, but a database migration subsystem is itself a tracking of snapshots of an evolving database schema -- so your version control system ends up tracking snapshots of what is in effect a little version control system! Glenn figures that maybe he can learn something about solving this problem from Smalltalkers, who deal with this sort of this thing all the time -- because their programs are themselves persistent objects in an evolving image. If he didn't know anything about Smalltalk or the history of programming languages, he might have missed a useful connection. Speaking of Smalltalk, veteran Smalltalker Blaine Buxton wrote recently on a theme you've seen here: better examples. All I can say is what Blaine himself might say, Rock on, Blaine! I think I've found a textbook for my CS 1 course this fall that will help my students see lots of more interesting examples than "Hello, world!" and Fibonacci numbers. That said, my Inner Geek thoroughly enjoyed a little Scheme programming episode motivated by one of the comments on this article, which taught me about a cool feature of Fibonacci numbers:
Fib(2k) = Fib(k) * (Fib(k+1) + Fib(k-1))
This property lends itself to computing Fib very efficiently using binary decomposition and memoizing (caching perviously computed values). Great fun to watch an interminably slow function become a brisk sprinter! As the commenter writes, simple problems often hide gems of this sort. The example is still artificial, but it gives us a cool way to learn some neat ideas. When used tactically and sparingly, toy examples open interesting doors. -----