Status-Q

[Original Link] Bruce Eckel on why Python programs, even fairly substantial systems, can work so well despite it being such a weakly-typed language. Python has been my favourite language for about six or seven years now, though when I want a GUI I usually use the web, and hence usually write PHP code because it's so tightly integrated with Apache. PHP, though, is just PERL with some of the more horrific parts taken out. Neither can ever achieve the elegance and readability of Python.

From "Import This: the Tenth International Python Conference":

"Tim [Berners-Lee] became a Python enthusiast when he tried to learn Python on a plane trip. He had already downloaded Python and its documentation on his laptop, and between takeoff and landing he was able to install Python and learn enough to do something with it, "all on one battery." "

(Python is a programming language. Just in case anyone thinks this is an unhealthy obsession with reptiles.)

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...

"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'...