« | » Main « | »

Programming with kids: madlibs

Sunday 31 July 2005

I've been looking for a programming project to work on with my 13-year-old son. He's very interested in computer games, 3D graphics, Flash movies, and so on. He wanted to know more about programming (he's done some ActionScript) and I wanted to share my love of writing software with him. But his natural inclination to advanced games was making it difficult to pick a project: he wanted to make 3D adventure games, or fast-moving arcade games. Those are do-able, but take a lot of time and planning. There's a long ramp-up time where the output is not linear with the input: you're writing many lines of code, and it doesn't do anything.

At the other end of the spectrum are the kinds of boring toy programs that don't excite kids: number addition quiz games, for example. They're simple to write, but when you're done, you've made the computer do something you don't care to have done.

But even those quiz games are appealing to kids that really want to learn about programming. My son and I were talking this weekend about finding and dusting off one that he had written a year or so ago. Together we came up with a better idea: write a Madlibs program. This struck us both as really appealing: he liked it because it seemed like a fun program to have when the work was done, and I liked it because I could see it would involve a little bit of work, and would provide some interesting challenges. Also, it was easy to see a bunch of different directions it could be taken, each creating new teaching opportunities. And it didn't require complex libraries or esoteric output modes: just console input and output.

So he and I set to work on it, and it lived up to its promise as a good program to work on. Read about the results in Programming Madlibs.

Booleans suck

Sunday 31 July 2005

When designing a data format that has to last a long time and be extensible, for goodness sake, think twice (or even three times) before using booleans. Too often, I've represented what seemed like a simple yes or no choice as a boolean, only to see it eventually fracturing into a range of choices. The simple and optimistically chosen boolean ends up being deprecated in favor of a multi-faceted enumeration, but the old code is stuck in its simplistic this-or-that view of the world.

This applies to all sorts of interfaces: protocols, APIs, file formats, and so on. Any time you have data shared by two pieces of code, and you can't change both chunks of code any time you want to, you have to worry about backward compatibility. If one of those pieces of data is a boolean, you will eventually need to change it, take my word for it.

Actually, even choosing an enumeration in the first place doesn't save you from the difficulty of upgrading. For example, suppose you have two types of Things, regular and special. Queries in the code will look like this:

select * from Things where type = 'regular'
select * from Things where type = 'special'

Then in version 2, you add a third type of Thing, call it "unusual". What happens to the queries? Are they still correct? You'll have to look carefully at what the data is used for, and figure out whether unusual Things should have been included or not. Maybe selecting all the special Things should really have been selecting all the non-regular Things:

select * from Things where type != 'regular'

If you have the luxury of changing the queries, you are in good shape, you only have to change a bunch of code. If you can't change the queries, perhaps because they are fossilized in previous versions of your product that are deployed in the wild, then you have a real problem.

I don't know what the best answer to this conundrum is. Unless you can truly plan your semantics for all future versions at the very beginning, you are going to end up splitting concepts like this. One option is to do ugly tricks like have the "unusual" Things not appear in the Things table at all, and instead put them in a new table altogether. Then old code will still work (the new incomprehensible Things won't appear to them), and new code can be written to find them where they are. But you have an ugly data model now, and all future users of it are burdened with strangenesses like Things and UnusualThings. Ick.

Multi-threading?

Thursday 28 July 2005

Almost two weeks ago, Roushan Ali asked a simple question on the sqlite-users mailing list:

Can we use single sqlite_open handle(global) across threads (if all database operations are serialized by using semaphore)? Please help.

D. Richard Hipp, the author of SQLite (an awesome embedded relational database, by the way) responded:

Actually, this seems like a good opportunity to repeat my oft-ignored advice to not use more than one thread in a single address space. If you need multiple threads, create multiple processes. This has nothing to do with SQLite = it is just good programming advice. I have worked on countless multi- threaded programs over the years, and I have yet to see a single one that didn't contain subtle, hard to reproduce, and very hard to troubleshoot bugs related to threading issues.

And from there, the deluge began. The discussion is going on 40 responses and has turned into a computer science equivalent of a pig-pile smack-down, with competing claims, snotty asides, arrogant put downs, references to papers, snarly analysis of same, Linux vs Windows sniping, and so on.

Sifting through the noise, there's a lot of interesting material about how best to develop software which has to "do many things at once". Someone pointed to The C10K Problem, which looks like an interesting summary of the options for building high-throughput network servers.

I've done lots of multi-threaded coding, and it is difficult. If you can keep the cardinal rules in mind (protect shared data and impose a strong ordering on locks) and be extremely diligent, you can make it work. But when it doesn't, you have to do some very difficult debugging. I've never used the other styles, and the arguments for them sound very compelling.

Sometimes the automation really knows best

Tuesday 26 July 2005

Recently I was working on improving the automated test coverage for Cog, preparing for another release of features. I was approaching 100% coverage. There was only one line left untested. It was very simple undocumented function, cog.msg, which simply printed its argument to stdout. I thought about simply yanking it from the code. But looking at my own use of Cog, I saw that I had used it a few times, and others might want to, so I decided to put in a test for it, for completeness. If it weren't the last untested line in the source, I probably would have skipped the test.

So I put in a simple test, and ran the test suite, and it failed! Turns out I had broken the function a while back during a global search and replace to use an explicit stdout member rather than sys.stdout. Go figure. The test that I had put in "just for completeness" found a genuine bug, and one that I would have encountered in my own environment once I tried deploying the code.

Now Cog has 100% test coverage (w00t!) and I learned my lesson about automated tests: they really work, and often know more than you do.

Extremely Loud and Incredibly Close

Friday 22 July 2005

I just finished reading Extremely Loud and Incredibly Close by Jonathan Safran Foer. It was a very interesting book. It's the story of Oskar, a boy who has lost his father in the Twin Towers on September 11th. Oskar is a very endearing character, and I wanted to read more about his thoughts and feelings about the world. Foer did a great job speaking through Oskar, with a boy's hurt, loss, pain, and incomprehension.

» read more of: Extremely Loud and Incredibly Close... (5 paragraphs)

Foer's over-the-top literary pyrotechnics aside, I really liked this book, and was glad to be able to follow Oskar as he tried to make sense of his tragedy.

Extremely Loud and Incredibly Close

Very small objects

Thursday 21 July 2005

I can't tell if this is science or art (or maybe both, or maybe a joke). Brian Collier has devised the Collier Classification System for Very Small Objects. He's invented a scheme for creating "names" for very small objects encountered in the world. For example, a resistor is dubbed Nelifrag Buildielectro tanecylismothbuglik, because it is a fragment that was never alive, found in a building, used in electronics, tan, cylindrical, smooth, and generally bug-shaped. Like I said, is it science, art, or an elaborate joke?

Google maps pedometer

Thursday 21 July 2005

These days, you can't swing a dead cat without hitting another nifty web site based on the Google Maps API. I've been overwhelmed with them lately. But Gmaps Pedometer actually helped me solve a real question I had: how long a walk was it the other day to my car mechanic? (1.75 miles) Or an historical one: how far did I walk in the third grade when I decided to walk home from school rather than simply ask a teacher for a token to get on the subway? 5.26 miles.

Flipbook

Wednesday 20 July 2005

Flipbook is an online flip-book maker, you know, where you make a series of drawings and flip through them to see the animation. My kids say "It's awesome, like Flash, but free". I made Bounce Bounce Bang, trying to incorporate squash and stretch lessons I learned from reading animation books in my youth. Most of the efforts are pretty sketchy and jerky, but Toonami was quite accomplished, considering the tools.

More lattice stuff

Tuesday 19 July 2005

First, the source code for Platitude now supports the Mac. No real installer yet, but at least it runs.

Second, an email correspondent (Dethe Elza) sent along a few Celtic knot pages:

Django

Saturday 16 July 2005

Last week I mentioned the problem of over-proliferation of frameworks, toolkits, and so on, in the Python world. Although I've never developed a web site with a live Python back-end, I understand that the tools to perform this feat are among the most over-proliferated.

Nevertheless, I am excited by the release of Django, a new framework for developing web sites with Python. I'm excited for a number of reasons:

  1. It was developed by the guys at Lawrence Journal-World to build their web site, which is a good site.
  2. The guys who developed it have very good reputations and seem to Get It (Adrian and Simon, for example).
  3. The introductory tutorial Django at a Glance is very smooth and makes a good case.
  4. The Django web site itself is really nice, and the tag line ("The web framework for perfectionists with deadlines") kills.

Perhaps you think a few of these things are cosmetic and shouldn't matter. I say they all add up to having what it takes to do a kick-ass job as a web framework.

Platitude

Saturday 16 July 2005

A few weeks ago I wrote about Lattice drawings. I mentioned that I had used a Python program to produce the figures there, and of course, was asked in the comments to publish the program. I didn't, because the program was an unpresentable piece of crap. I had to edit text files, and then the program would draw the result. Yuk.

So last week while I was on vacation, I wrote a new program, called Platitude. This is a GUI application that lets you manipulate the lattice with the mouse. It still is very bare bones, but I wanted to get it out the door. I consider it a presentable piece of crap.

A changed 5 by 3 lattice

Try it and see what you think. It's available as a Windows executable, and Python source. If someone could help me understand why I get bitmap errors on the Mac, that would be fabulous!

First Segway

Thursday 14 July 2005

I had my first Segway ride the other day. I got the hang of it pretty quickly. I've ridden unicycles before, and a Segway has nearly twice as many wheels. But right after I got off, I had this odd sensation of normal walking being incredibly clumsy, kind of like the way scuba flippers make you feel, where you have to take exaggerated steps, and think about lifting each foot and putting it down again.

Abecedarium

Wednesday 13 July 2005

Kristen McQuillin has a few examples of abecedaria: poems with 26 words, each beginning with the next letter of the alphabet:

Mysteries

Angels bring confusion.
Don’t ever forget god’s hand
Is juggling knives like man’s nature.
Occultists properly question reality.
Saints travel unbroken vigils
without x-ing yesterday’s zodiac.

PySWT

Monday 11 July 2005

PySWT is a Python binding to the critically-accliaimed SWT GUI library from Eclipse. I'm torn about this. On the one hand, I like high-quality tools made available for us all to use. On the other hand, why do we need another? How does this do a better job than wxPython?

Part of the Zen of Python is "There should be one —and preferably only one— obvious way to do it." While this needs to be taken with a grain of salt (the URL is Humor.html, after all), the libraries available for Python have strayed far from this ideal. Everywhere I look I see too many choices.

I've whined about this before, to what end, I don't know. I can't imagine the Python community will somehow consolidate to have a single GUI framework, a single web app framework, and so on. Part of the fun is the ease of getting a project off the ground, then finding a large enough audience to keep it going.

Peak oil

Sunday 10 July 2005

The phrase "peak oil" refers to the moment when oil availability is at its maximum, a moment after which the world gets squeezed between ever-increasing demand and ever-shrinking reserves. Martin Sereno has an information-packed presentation on the topic. It includes many graphs, charts and maps, and many dire predictions (for example, "slow collapse of global industrial civilization begins 2030"). I fear that he is all too right, and we are too comfortable in our oil habits to adapt without a great deal of pain.

« | » Main « | »