The Coding Game
I found this presentation on using principles of game design when creating ordinary applications via Jeff Atwood. It’s a really fascinating idea and the author has some great points. The idea that really got me thinking was this: what if programming environments were designed this way?
In a way, a programming language is exactly what an “exploratory learning environment” is: you have a goal, you don’t know how to get there, and you’ll be told (more or less) whether you succeed of fail. But programming environments are generally exactly how the author describes “enterprise applications”. You’re presented with a bizarre and complex array of features and an incredibly steep learning curve. What if programming environments unlocked features as your experience increased?
Some of these ideas are present in a few programming environments. Visual Basic had the extensible toolbox metaphor that made putting together GUIs really easy and intuitive. PLT Scheme has the idea of language levels – you can start off on a Scheme flavor that has a very limited feature set, all the way up to a full R5RS implementation, and past that into extensions to R5RS. And every dynamic language has that loop of immediate feedback.
I think one place environments fall down is in setting explicit goals for newbies. I’ve messed around with Squeak and eToys, for example, and while they have tutorials available from the opening screen, I’ve gone through the tutorials and not really felt like I learned how to do anything. After reading this paper, I’m getting a vision for a tutorial that works more like a game: give the user a limited toolset, an explicit goal, and let the user see if they can get there. Rather than show me how to create a car I can drive around on the screen (the eToys tutorial), give me a limited toolset and tell me to make a car, offering hints along the way.
In another way, I think it might be a useful way to look at programming in general. I think about my toolbelt that I use when I’m building something. When I’m doing electrical work, I get my lineman’s pliers, crimper, utility knife, a couple screwdrivers, and wire strippers and put them in my toolbelt. I don’t need my framing hammer, combination square, RJ-45 crimper, cordless drill, or any of a hundred other tools that are very useful for other tasks, but not for electrical work. Would it make a more productive environment? More importantly, would it make for cleaner code? If I didn’t have access to an HTTP request object except in limited situations, then I wouldn’t have so many problems with separation of concerns.
That’s probably not a realistic goal for a programming environment. We programmers like to have the full power of our language available on demand. It’s a useful metaphor at least. Next time you go to add a using statement, think about it: if I’m supposed to be installing electrical outlets, what’s my pneumatic nailgun doing in my toolbelt?
— Gordon Weakliem
Comment
Commenting is closed for this article.
The End of Presidential Elections On Automatic Coding Standards