I’m always coming up with metaphors to explain to non-technical people what I do. The point of this one was to explain to people why I prefer Python:
Programming in C is like building a four-story mansion out of 1×2 Lego bricks.
Programming in Python is like building a house out of Lego Technic parts.
Programming in Perl is like building a house with duct tape, a flat of cinder-blocks, some left-over lumber, pipe cleaners, crazy glue, fishing line, and chicken wire. You also get a bunch of re-bar that you can bend into whatever shape you want, and truck full of spray-on concrete.
Programming in PHP is like building a house with just chicken wire, coat hangers, and aluminum foil. Luckily, if you use enough aluminum foil, it will shield your brain from the alien transmissions from outer space, so you don’t have to wear your aluminum foil hat while you’re at home.
Programming in Java is like buying a one-piece, hyper-modern, injection-molded plastic house unit, and then having your lawyer write a letter to the house manufacturer asking for permission to cut a one-meter by two-meter hole in the living room wall into which you’ll install the front door, since the house doesn’t come with one. Your lawyer promises in the letter not to sue the house manufacturer for problems with the door.
Programming in Ruby1 is like building a house out of two different brands of cheap knock-off Legos, made of flimsy, low-quality plastic, which don’t fit together quite snugly enough. You also get a handful of puke-green pipe-cleaners left over from Perl.
Programming in JavaScript is like building a house out of Jell-O that has to stand up on three different lots, one flat, one downhill, and one uphill. Just when you’re finished building the house, Bill Cosby rides up on a stallion, ready to start filming a Jell-O commercial.
Programming in XSLT is like hiring an architect who speaks only Icelandic, an engineer who speaks only Bantu, and a bunch of Nepalese sherpas as the construction team. The architect thinks you’re building a supermarket, and the engineer thinks you’re inventing a new kind of refrigerator, and the sherpas think you’re doing performance art. The engineer builds a catapult to fling 2×4s into the air while the sherpas fire high-powered nail-guns at them, and when it’s all done you’ve got an ordinary two bedroom suburban house that’s completely upside-down.
That’s all! Happy April Fools!
I’ll be posting a larger article about my recent experiences learning Ruby in a few days. Subscribe here if you want to read it when it’s posted.↩
Turns out SuperCache does a less than super job with non-ASCII characters, failing to encode them to HTML entities, and instead writing them out as multi-byte UTF-8 sequences:
I got this email Tuesday from Joel Holdsworth, announcing that he had ported my Alphabet Soup pseudo-letter-generator from a bitmap to a vector model, and turned it into an Inkscape plug-in. He tells me that the extension will likely be included with Inkscape v0.47.
I cannot begin to express how phenomenally awesome this is. This is the kind of news that keeps me writing, and releasing, little free softwareprojects. Six years ago I wrote Alphabet Soup as a little art project; it was fun. I released it under an open source license, and then never got around to improving it to output a vector format. Then somebody I’ve never met comes along, and not only improves it, but integrates it into a bigger free software project and it will soon be available to thousands of users in a greatly improved form.
You can pull the extension out of Inkscape’s SVN here. You’ll need these files:
There are two quite different reasons for implementing HTML generation on a website. The first reason is to insert dynamic content, content that comes from a database or is algorithmically generated, into pages. The second reason is templating; to ensure that standard, site-wide parts of the HTML, such as headers and footers, are pulled from a single source. The goal of the first is to have a dynamic, database-driven site. The goal of the second is to avoid having to edit tens, or hundreds, of HTML files when the site design changes, and to avoid copy-and-paste coding.
This all-Flash interface (screenshot) is a complete reimplementation of the WordPress blog interface; One single Flash widget fills the entire browser page, and implements not only the home page, but categories, comments (including posting), and article pages. It sounds like the author intends to use it to replace the HTML interface to his blog entirely. It’s a great example of why you should never build an entire website purely in Flash.
In Java, many of the the standard library’s objects have configurable settings, like timeout settings, boolean behavior flags, and so on. Sun’s documentation never says what these are set to by default. Does the timeout default to infinity? Zero? Thirty seconds? One hour? Is a new connection set to accept input, or output, by default? What’s the default buffer size of this object? Am I expected to write a little test program to figure out what the defaults are? Am I expected to grep through the Java standard library source code to find out?
On top of this, lots of the configuration values have getters, setters, and a method to set the default value for all future instances of that class for the lifetime of your application. This must have taken some time to implement. But did Sun bother to put the factory defaults in the documentation? No.
This is a classic example of over-engineering; Instead of focusing on choosing a reasonable default and writing complete, useful documentation to make the user’s (coder’s) life better, they focused on a level of configurability that is only rarely (if ever) necessary.
Rethinking the Progress Bar doesn’t really rethink it so much as prove what should have been obvious; people prefer progress bars that speed up as they reach the end, rather than progress bars that slow down towards the end. Execute your unpredictable-duration activities, like network transfers, at the beginning of your code, and your predictable-duration activities at the end.
I wonder why we’ve never seen progress boxes or regions, that express two simultaneous processes by growing in two (or more) dimensions simultaneously, at different rates. Seems like you could map one dimension to radius and the other to angle, and have a progress region that progresses from a single center point, to a wedge, and finally to a filled circle. Probably too complicated, but I’d love to find a use for that.
Spydentify is a new experiment/side project of mine. It fills a niche that I first identified over at the Typophile Type ID Board: people love looking a pictures and trying to figure out what’s in them. The site’s interface is designed to be as addictive as possible, with a neverending, rapid flow of interesting images, big, shiny buttons to click, and instant feedback on your actions. I’m going to add more ego-stroking, viral-spreading and moderation features soon.
The interface also follows the MVC pattern I laid out in this article. It uses one static HTML file, all dynamic data is loaded through XMLHTTPRequest (AJAX, for those of you who speak Web 2.0), and all HTML generation is done via JavaScript manipulation of the DOM. The backend uses Pylons, which gave me a chance to learn Pylons, Paste, Routes, SQLAlchemy, FormEncode, and Mako. And comments are rendered with my own PottyMouth.
