There has been much ado about Apple's decision to yank Scratch from the app store. The timing has led many to believe that this was precipitated by the much-maligned iPhone OS 4.0 SDK developer agreement change that forbids alternative development languages/environments. However, things like interpreters, executable plugins, and virtual machines have been explicitly forbidden by the developer agreement at least as far back as March 2008.
I am forced to wonder: Were the guys that developed the iPhone port of Scratch unaware of these rules, or were they simply hoping that -- given that Apple was founded on the ingenuity of two young guys in their garage -- maybe, just maybe someone there would think making creative software development tools for kids was worth making some kind of exception for. One of the guys behind the project posited that "Basically, Apple hates us." No, man, what you experienced was not hate. It was the blind scythe of consistency. It was -- in ye olde D&D parlance -- Lawful Evil.
But, the noise about this has reminded me of a bit of a conundrum I have over this whole rule. What the hell is "code," anyway? That may sound like a silly question for a programmer to be asking, but it is an important question. Most technical definitions I can find suggest that it is some kind of symbolic set of instructions or rules intended to tell a computer what the heck to do. In other words, the only thing that makes a recipe for chocolate chip cookies not code is that it is intended to be interpreted and executed by a human, rather than a computer.
We do use a considerable amount of data that contains instructions intended for computers, however. Most document formats (aside from raw text) include some kind of markup that informs a viewer or editor application of the intended presentation logic for that document. Isn't that code? What about the formulas in a spreadsheet? That's code, isn't it? Isn't MIDI a set of instructions for playing music?
Where is the line, here? If I make a game with monster AI that is driven by a state machine whose nodes and state changes are specified in an XML document, am I not running a program on a virtual machine?
Data influences how many non-trivial programs function. A great deal of data is code. Code is everywhere.
Monday, April 19, 2010
Roger Ebert has once again attempted to tackle the whole question of videogames-as-art. I have a huge amount of respect for Ebert as a human being, and as a film critic. He is a giant of a man. However, let's be honest: He doesn't play enough videogames to judge whether they are or can be art. His analysis of games based on Kellee Santiago's talk is comparable to a non-classical-music-listener critiquing Dvorak's New World symphony, simply based on someone else's description of it.
Certainly, it is a critic's job to describe things in such a way that a reader (or listener) knows whether something is worth experiencing, first-hand. However, the audience needs an appropriate frame-of-reference to get any value from the critic's review. I don't expect people who don't play videogames to have the frame-of-reference they need to appreciate, from a critic's review, the artistic merit of a given game.
What I am about to write may be controversial with some of my friends in the open source community, but it needs to be said.
For the most part, I won't make substantial contributions to any GPL projects anymore, as a matter of principle. I think that the license is, in many cases, self-defeating, and only delivers the highest-quality code for certain types of projects, under certain ideal circumstances.
Why is this?
To put it simply, the people you probably most want contributing to your project are developers who really understand the domain, and are going to give you professional-quality code contributions.
Many companies do not use GPL code, because they do not feel that they have the luxury of GPLing their own code. This is a practical truth, whether you agree with their reasons or not. Many of your would-be expert contributors work for such companies, and are bound by non-compete agreements that would prohibit them from contributing to your project in their spare time. If their employers aren't using your code, then they can't contribute to it.
In short, if you GPL your code, you may be missing out on some of your best contributors.
If I wanted to work on a piece of game-related code, and it was under the GPL -- in practical terms -- almost nobody will use it and no professional game developers will contribute to it, no matter how good or useful it is. I mean, really, it sounds like a horrendous waste of time to me.
One great success story of open source game development technology is the Ogre3D engine. This is an open source 3D graphics engine which is arguably as good as some of the expensive commercial ones I have used. It was originally released under the GPL, many years ago, and has gradually become more permissive over time (GPL -> LGPL -> MIT). Upon the transition to the MIT license, the project maintainer, Steve Streeting, notably observed the following:
While not requiring modified source to be released might initially seem like giving up an important motivator to contribute code back to the community, we’ve noticed something in recent years: 99% of useful code contributions come from people who are motivated to participate in the project regardless of what the license tells them they have to do. It’s our experience that a certain percentage of the user community will always participate and contribute back, and therefore encouraging adoption via simpler licensing is likely to result in more contributions overall than coersion via complex and restrictive licensing does. In addition, people who are internally motivated to participate tend to provide much higher quality and more usable contributions than those who only do it because they are forced to.This is very consistent with my own observations of open source projects. I am curious whether others have seen the same.
Now, mind you, everything I just said can depend a lot on the domain of a given project, and also whether something is an API or standalone, and a number of other factors. Linux, for example, seems to be a perfect-storm of GPL-working-as-intended. However, there aren't a lot of professional operating systems developers in the world, and many of them work for companies that sell competing products, so one can make a fair argument that Linux probably gets the best contributors they are going to get, regardless of how permissive their license is.
Thursday, April 08, 2010
I used to spend a lot of money on tech books.
As a programmer who is always expanding my horizons and trying out various technologies (and generally trying to keep my skills fresh), I spent exorbitant amounts of money buying fat tomes full of wisdom that would be obsolete, oh, about 15 minutes after I brought them home. Sometimes, they would already be obsolete, by the time the publisher managed to shove them out the door.
The web changed things... up to a point. I no longer need hefty API references, since most API references are published online, and it is considerably faster to search them electronically. If I have some obscure question about how to accomplish something or solve a problem, there is usually a forum or article somewhere that will address my concern. Still, there is usually at least one good "bible" on any given topic that was worth having. What C programmer doesn't have a yellowing copy of K&R on her shelf? What Perl programmer doesn't have the camel book? What webpage will replace our Stroustrup? Our Knuth?
When I was living in Australia, I couldn't take all my books with me from the States. That was when I discovered O'Reilly's Safari. In the beginning, it was most of the O'Reilly library, online, and you could keep a bookshelf, with a few books on it at a time that you could read on the web. Today, the library has expanded to many publishers, and you can buy a yearly subscription that gives you access to the entire library. The subscription is a bit pricey, but if I truly admit to myself how much I was spending on technical books per year before, the price is not unreasonable. It is access to a giant library of the most recent version of nearly every computer book you could ever want. How do you even put a price on that?
However, like all websites containing technical information, Safari presented an interesting usage-pattern problem for me. I can use a physical technical book without taking up any of my precious screen real estate. An electronic technical book, however, uses your computer screen. If I have a second screen up, I am usually already using it for some kind of work. There is a decent mobile version of the Safari site, but I usually only use it when I'm curious about something on-the-go, because my phone screen is just too small to be a practical display for a tech book. So, if I need to refer to something, I often end up with a laptop to my left or right, displaying a book. This is ultimately a waste of space and energy.
A few weeks ago, I won an iPad in a drawing (Thank you, PayPal!). It arrived yesterday. I thought it was pretty cool, but I wasn't sure yet what on earth I was going to use it for. Before the day was out, I was already browsing a tech book on my iPad, while I coded on the desktop. Well, now, there's a perfectly good practical use for my new gadget -- technical book viewer. I wonder what else it will turn out to be good for?