John Dvorak on the official new name for Longhorn.
The buzzphrase of the moment is AJAX. If you’re a programmer, and you don’t know about this, you will soon. It stands for Asynchronous Javascript And XML, which is an increasingly common technique for updating parts of a web page from a server without having to update the whole thing.
It’s being heavily used by Google in Gmail and Google Maps, for example. And I think it my duty to keep Status-Q readers up to date with such terms so that you can casually drop them into conversations around the water cooler. “Oh no, it isn’t using Flash. It’s based on AJAX…”
Ruby is a language that’s getting a lot of attention as a slightly cleaner and nicer alternative to Python and Perl. If you have some basic programming experience and want to learn Ruby, there’s a very good tutorial here.
It’s mostly used, it seems, in the Ruby on Rails framework for writing web apps.
Another goody from IT Conversations: Paul Graham on “Great Hackers”. Here’s a quote:
When you decide what infrastructure to use for a project, you’re not just making a technical decision. You’re also making a social decision, and this could be the more important of the two.
For example, if your company wants to write some software, it might seem a prudent decision to write it in Java. But if you write your program in Java, you won’t be able to hire such smart people to work on it as if you wrote it in Python. And the quality of your hackers probably matters more to the success of your project than the language you choose. Though, frankly, the fact that good hackers prefer Python to Java should tell you something about the relative merits of those languages….
Business types prefer the most popular languages because they view languages as standards; they don’t want to bet the company on Betamax. The thing about languages, though, is that they’re not just standards. If you want to move bits over a network, by all means use TCP/IP.
But a language isn’t just a format; programming languages are mediums of expression…
Now, I’ll take issue with him here a little bit. The assumption behind his argument is that the programming task is best compared to painting or creating a piece of music.
Increasingly, however, it’s more like engineering & can even be rather mechanical. Good engineers don’t get to choose whether they work in metric or imperial units and often don’t have much choice about the materials and many of the dimensions. Their skill is in creating something robust and reliable given the constraints. Ideally something that will be maintainable after they have gone. The world is certainly in a better place with Java as the dominant language for such tasks than it was when COBOL or Visual Basic had that honour, and, much as I love Python, it’s probably not as good as Java for this role.
Artists, on the other hand, are usually loners who can throw off the constraints because they need to accomplish a particular single task. It makes sense for them to use whatever medium they like best, even if, God forbid, that should be Perl. Paul’s book is called ‘Hackers and Painters, so it’s natural that he should concentrate on this aspect. Python is a better language for exploration and invention.
I’ve programmed in dozens of different languages, BTW, and in general Python is my language of choice, because it comes somewhere between the two extremes. But the best artist is one who can choose the optimal medium for his expression. And the best engineer is often one who can create the optimal expression for his medium.
The real danger is that we will only train people to create nice Java boxes that fit together very neatly. This is great for building things that don’t fall down. But we also need people who can think outside the boxes.
One aspect of my new situation is that I’m writing some code again, having been doing mostly managementy things for the last couple of years. It’s fun to catch up.
I’ve been particularly impressed by Eclipse, a development environment that came from IBM originally, and has a large and growing community behind it. The recent eclipseCon conference had some influential keynote speakers, for example.
In my youth, serious programmers used the Emacs editor, which, if you could program in Lisp, could be made to do much more than just editing. There are Emacs games, mail readers, news readers and every variation of editing under the sun, all available from a few obscure keystrokes. The saying was that Emacs was “not so much an editor, more a way of life”. I know people who still use it for reading news and mail.
“Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.” – Zawinski’s Law. Nowadays he would probably say “until it becomes a web browser”.
Well, I think Eclipse is the new Emacs. Strictly, it’s an environment for building development tools, and there are many many projects out there creating applications based around it. In more down-to-earth terms, the basic download gives you a really nice environment for Java development, and an easy system of plugins so you can get tools for other work as well – C/C++ coding, Quality Testing, GUI design, Nokia phone development, Web site creation, even COBOL programming. Eclipse is now apparently “the most popular Java IDE in North America“. And it’s not just because it’s completely free. Having used it for the last two days, I’m very impressed.
There’s an introduction to Eclipse on Apple’s site, though being written in Java, it will run on most platforms. IBM even offer Eclipse Innovation Grants for people doing interesting things with it.
Groovy is a scripting language for Java, and it looks as if it’s appropriately named. A good introduction here. It has a lot of the best features of Python and Ruby, but integrates really well into the Java environment – Java code can be called from Groovy and vice versa very easily, the syntax is similar, with the Java rules relaxed a bit to suit the typically more informal nature of scripting, and Groovy code can be compiled into .class files and executed with the standard ‘java’ command. It has a neat syntax for XML/HTML generation and can be used for creating Ant scripts which are rather more readable than the standard XML.
Must find time to play with this.
[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…
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’…
© Copyright Quentin Stafford-Fraser
RSS feed
Recent Comments