Status-Q

David Brin laments the fact that modern computers are no good for kids wanting to learn to program, and explains why he bought his son Ben a $25 Commodore 64 from eBay.

Warning: Geeky stuff ahead!

The Parallels Workstation virtual machine software for the Intel Macs has a BIOS which doesn't support network booting.

I wanted to simulate an LTSP workstation, which would boot over the network from our Linux server. Here's how I did it:

On the ThinStation project site, I found a link to a Universal Network Boot package - a zip file containing disk images for floppy, CD and HD.

From this I grabbed the ISO CD-ROM image eb-net.iso and set up my virtual machine to use this as the CD instead of the physical CD drive. I also configured it to boot from CD first, and, for my purposes, I removed the hard disk from the config as well.

Sure enough, it boots up just fine and I have an LTSP terminal in a window. Much easier for experimentation than rebooting my embedded device all the time.

Mike Zornek has produced a very nice screencast which introduces you to version control in general, and the Subversion system in particular.

TextMate is a fabulous text editor for the Mac. The best way to get a feel for its capabilities and see what all the fuss is about is to look at some of the screencasts. Here's one about writing screenplays. Here's another about Python programming.

And there's an excellent new one about how to customise it which is well-worth watching, especially if a bit of shell-scripting doesn't disturb you.

Highly recommended.

Benji Smith wrote a nice piece on Why I Hate Frameworks. Recommended reading for any coders out there, if only for amusement.

He has a follow-up amongst the comments, too, so it's worth scrolling down a bit.

The problem with his argument, I think, is that programming always tends to move towards higher-level constructs. Assembly-language programming with macros was a great framework for those who had previously had to flick switches on the front of their PDP-8. And C offered greater productivity again, but is now considered pretty low-level. The scripting languages of yesterday become the programming languages of tomorrow.

But he draws a distinction between libraries and frameworks.

A library is something *contained* in my code. A framework is a *container* for my application.

And it's true to say that many frameworks have come and gone which try to exert too much control over the code. (Anyone remember CASE tools?) Many frameworks put the programmer in a box and say, "Here's where you can put your little bit of contribution to my mighty machine". And programmers don't like that. They like to know what's happening when and feel that they're in control of it. This is the nice thing about software libraries: they're servants which do your bidding and then return power to you. Frameworks are like big companies in which you must first find your office, and then work out what you are allowed to do in it. Both have their role. But I suspect that today's libraries will become tomorrow's programming languages. Thanks to Frazer for the link. Oh, and P.S. Apple has a tendency to package up its libraries nicely and call them frameworks, but they're still libraries in the sense of this article.

I wrote about TextMate a couple of days ago. Giles Turnbull is also a new convert.

There are some very good text editors for the Mac.

SubEthaEdit is nothing short of wonderful for its collaboration features - if you haven't tried this, you should find a friend with a Mac and do so - and it's not at all bad as a general-purpose editor. TextWrangler has a somewhat nostalgic Mac-classic feel to it, but has a wonderfully useful feature of being able to browse, open and save files on a remote machine via SFTP/FTP. You simply pres shift-cmd-O and shift-cmd-S instead of cmd-O and cmd-S. If, like me, you spend a lot of time editing config files and web pages on remote servers, this is very nice.

But the one I've recently converted to is TextMate. I'd seen people starting to rave about this app, but hadn't quite worked out why. The more time I spent with it, though, the more I liked it, to the extent that I forked out the 39 EU to buy a license within a few days, not something I'd often do for a program that didn't even have documentation. The Bundle system, which groups together the functionality associated with particular types of file, is very nice, and I find I'm starting to miss the various shortcuts, completion mechanisms and auto-expansions when I'm entering text into anything else.

It doesn't have TextWrangler's convenient access to remote files, but I've long been a fan of the Transmit FTP utility, and if you specify TextMate as the editor then everything's pretty seamless.

And then this week, not only did documentation arrive, but people are starting to produce screencasts, showing how to get the most out of it. More info here.

No conference which discusses the Web can consider itself cutting-edge these days unless at least a couple of the speakers make reference to Ruby on Rails. For those who haven't come across it, Ruby is a very dynamic programming language which has been around for a long time, but because it originated in Japan, it's taken a while to gain popularity in non-Japanese-speaking parts of the world. Rails is a framework which takes advantage of the dynamic nature of the language to map SQL databases neatly onto Ruby objects. It has scripts which create a lot of standard stub code for you, and so in general it makes it very easy to create web applications based around a SQL database back-end, which an awful lot of web apps are, nowadays.

I wrote briefly about Ruby on Rails three months ago, and since then I've been sipping at the kool-aid - watched the intro videos, bought a Ruby book, and played a bit with the software - but I never quite got a taste for it. Ruby is so named because it was meant to be a better PERL, and it certainly is that, but I think there's a few too many Perl-isms still lingering in the background. Ruby enthusiasts claim that it's a 'pure' object-oriented language, more like Smalltalk than most of its competitors, because everything is an object, so you can do things like calling a method on an integer:

5.upto(10) { |i| print i }

but somehow this just doesn't feel very natural to me. You can do some lovely things in Ruby, but I don't think a language can lay much claim to purity when it still has things like the global $_ variable from PERL.

And so I've been very pleased to discover Django, which is a very similar framework that slightly pre-dates Ruby on Rails, and which is based on Python rather than Ruby. Python has been one of my favourite languages for a long time - I first used it in 1991 - and to my mind it's rather nicer than Ruby for most things. It's much more widely known, and all the benchmarks I've seen also show Python as rather faster than Ruby, and Django as higher-performance than Rails.

Django works the opposite way to Rails; you create particular kinds of objects in Python and run a script which produces the SQL tables which store them for you. In practice this doesn't make a huge difference. The Rails approach can be more flexible, but with Django's you get all your canonical source code in the same language. They both have their merits. But the default framework that Django produces is much more useful than anything you get for free with Rails; it provides quite a nice 'admin' interface which you can start using immediately for entering data without grimacing too much about the user interface.

My wife Rose needed to store some data in several related tables and access them from home and from the University. In one day I was able to take her data, which was mostly in tables in Word documents and get it via Excel, text files, and some Python scripts into a MySQL database. Django provided the web front end and by the end of the day she was entering her data via her browser into a set of inter-related tables with various conditions attached. I was working in the next room and from time to time I'd come in and say - "Look - there's a search box now!".

Remember that this was my first attempt at using the platform. Now, of course, I'll be tinkering with it for ages, but the ability to get something up and running and useful so quickly is a great tribute to Django's design. I also have a feeling, though I haven't tested this yet, that much of Django might be more useful than Rails for any web apps which are not based on a SQL database.

Anyway - highly recommended.

Thanks to Martin for pointing me at these amazing computer-generated pictures by Jared Tarbell.

As well as being beautiful, most of them come in Java applet form, so you can watch them being generated on your own machine, and they're also accompanied by source code.

I'm reading a book edited by Joel Spolsky and came across this nice footnote:

This reminds me of my rule: if you can't understand the spec for a new technology, don't worry; nobody else will understand it either, and the technology won't be important.