Article on webcams in general, and the coffee pot in particular, in yesterday’s New York Times.
Article on webcams in general, and the coffee pot in particular, in yesterday’s New York Times.
Well, I wrote that ‘Zen’ piece on the 14th without much careful thought, and in particular before I had seen John Naughton’s pointer to Richard P. Gabriel & Ron Goldman’s remarkable essay “Mob Software: The Erotic Life of Code“, of which it is not worthy to be a minor sub-paragraph. And while a skeptic might say that the word ‘erotic’ is in that title more to attract attention than because it’s a major theme of the essay, the attention is certainly deserved. Recommended.
Recommended, at least, if you have the time to read over twelve and a half thousand words. There’s an assumption, built into most types of writing, that what you are saying is worth the time and effort of the person reading it. The longer the piece, the better it needs to be, either in terms of the enjoyment of reading, or of the knowledge gained by doing so.
Weblog entries tend to be brief. Quick to write, quick to read. While in general I dislike the trend towards a sound-bite culture, I would argue that weblogs are important chiefly because of their brevity, and this is not just because of the ease with which they can be jotted down and the speed with which they can be skimmed. It is because many of us are not sufficiently confident in the value either of our ideas or of our writing skills to feel comfortable imposing large quantities of text on our fellow man. By publishing just a couple of paragraphs we can try out an idea and see if others find it worthwhile, without imposing too great a burden on them if it isn’t. The timid publisher has had very few such opportunities in the past. Publishing pamphlets was too expensive, writing to the newspapers was too subject to editorial rejection, and creating websites required too many specialist skills. This, I think, is part of why weblogs are a genuinely interesting new medium.
Zen and the art of Bug Removal
We often think of programming as architecture or as engineering – the construction of complex working machines out of many small parts. Build it properly, and it doesn’t fall apart. Here’s a different view, which probably has limited validity and no useful purpose, but which I thought was interesting.
Computers can do things without any human intervention. If you power up your microprocessor and point it at a large chunk of memory containing random bytes, exciting things may happen. Your disk may whirr. Your screen may display colourful rubbish. If you’re lucky some lights on your computer might flash on and off. Or it may just stop dead. Whatever happens will probably be chaotic, unpredictable and, above all, not very useful.
Programming, then, is the art of taming this wild behaviour. Of imposing order on a system that would otherwise run wild. Of reducing the almost infinite number of possible actions to the relatively small number that are useful. Of producing order from chaos.
To pick an analogy suitable for this part of the world, you might compare it to digging irrigation channels so that you could reclaim agricultural land from a flooded plain. Programming languages provide the component parts – the ducting, the pumps, the weirs and sluice-gates – which make this process easier than simply digging with a spade. If you use higher-level programming languages, you might get complete viaducts and locks ready-made. But the natural state of the water is one of chaos. If you misuse the components or forget anything, you get bugs. One day, a high tide, combined with a westerly wind and an unfortunate usage of sluice gates, will allow the water in one channel to leak out and cause another flood.
The perfect irrigation system would use the minimum number of channels in the perfect locations with exactly enough sluices and dams to control the possible flooding situations, but no more.
The most aesthetically pleasing programs are those that provide the most complete and elegant order out of the chaos with the minimum amount of intervention from the programmer.
Enough for now – I have to go and tidy my desk…
Strength through diversity: I like Dave Wilson’s “Windows, Windows Everywhere“.
Ahh, nostalgia! You can find some very elderly versions of Netscape still available for download on
Netscape’s FTP server. Still have a Windows 3.1 machine? No problem! Just grab a copy of Netscape 2 or 3.
Today’s Sunday Telegraph has an interview with Gore Vidal. Does he think there’s immortality in books?
“I would doubt it now. Do you see anybody reading anything in the near future? The book is almost irrelevant. Poetry has the best chance. Fiction, I’m not so sure. I see the essay as probably the last necessary form of prose. I can imagine Montaigne outlasting Shakespeare, who will have become too difficult.”
Weblog entries must be amongst the most transient of writings.
The auction of the Trojan Room Coffee Pot has closed on eBay with a bid of over £3000, which will apparently go towards purchasing a new coffee machine in the new Computer Lab. The coffee should be a bit better now.
I’ve just come back from a fabulous holiday in Austria, where I was woken each morning by cowbells, as the cows from the farm where we were staying meandered down the road to their green and pleasant pastures. Hiking in the mountains, we would sometimes come across large numbers munching away, and it would sound like a wind-chime factory.
It’s a wonderful thing that nobody has yet replaced these bells with electronic beepers, or even silent radio beacons. This is a fabulously appropriate technology, a location system which uses no electricity, is rugged and weatherproof, and actually enhances the environment in which it is installed.
So here’s a challenge to mobile phone manufacturers: Can you produce a phone which, as well as being small, light etc, has a ringtone which does its job of alerting the user, while actually being pleasant to listen to? By ‘pleasant’ I mean actually pleasing, rather than ‘not annoying’. You could use that built-in microphone to choose an appropriate volume level, too. Oh, and I’d like mine to play extracts from The Sound of Music, please.
Seditious thought for the day: Is the phrase ‘Strike while the iron is hot’ really a call for industrial action amongst housewives?
Tom Bradford’s ‘The Future of XML‘ is a timely warning. Perhaps the motto for the W3C should be one of my favourite quotes, taken from Antoine de Saint-Exupery:
You know you have reached perfection in design, not when there is nothing more to add, but when there is nothing more to be taken away.
There is a quote from Byte at the top of the XML-RPC home page:
“Does distributed computing have to be any harder than this? I don’t think so.”
No, it doesn’t have to be, in many cases. I’ve just been making my first real use of XML-RPC, and it was perfectly adequate for my needs, trivial to install (at least for Python) and to debug. It’s also very easy to learn, especially if you understand XML; the entire spec is just a couple of pages, written in a very laid-back Dave Winer-ish ‘this bit isn’t defined, it’s application/implementation-dependent’ style which would probably make writers of most other technical specifications begrudge it the name.
The big question, then, is what the other systems like SOAP, Java RMI, and more particularly CORBA, give you that make them worth the steeper learning curve, the installation hassles, and the devotion of large areas of bookshelf to ‘real’ specifications.
Well, you get performance, for one thing. It would be hard to define a less efficient method of sending certain types of data around than encoding them as a structured text document and using a general purpose parser to decode them at the other end. But unless speed is an absolute requirement for you, other factors are likely to be more important. Ever written a shell script, a Perl program, a Java application when you could have used C? Precisely. Developer time is more expensive than processing power.
But with many of these other systems you also get a raft of services that XML-RPC doesn’t try to provide. Callback mechanisms, interface discovery, security, naming services, to mention a few. You also get a more thoroughly-defined agreement between server and client as to what the nature of the interaction is going to be. All these things add complexity, which is what makes other RPC systems more difficult to learn, but it’s complexity you may have to implement yourself if you’re building substantial mission-critical systems based on XML-RPC.
So the XML-RPC premise is that most distributed systems aren’t like that. That the required interactions are typically simple things and don’t need the complexity that something like CORBA can bring to your development. That the relatively slow speed of the internet or of user interaction makes the speed of the RPC system irrelevant. For the sort of stuff I’m doing, this is usually true, which is good because it means I can spend less time worrying about the plumbing.
So, should you use XML-RPC? I guess the answer is ‘application/implementation-dependent’…
My trusty old Palm V died recently, and I’m trying to switch to a Compaq iPAQ as an experiment. You can read about my experiences in “How I survived the move from Palm to Windows CE“!
© Copyright Quentin Stafford-Fraser
Recent Comments