from rup to rupp

Wed, Jan 14, 2009

Often the software development wheel turns full circle. For example, from COM to web services and the original Mac OS to Windows but going by the new JISC Developer Happiness Day, the spokes have fallen out and the wheel has flattened into a two dimensional landscape. Every now and then you have to take a look around you, see what’s happening in the field. In academia, Java has never been big. It’s too complicated for most hackers who are short of time and long on tasks. Scripting string and duct tape are the norm. People like Sakai have noticed this and are positioning Sakai 3 to allow non Java developers to contribute [PDF].

The Happiness Days are concentrated not on Java or C++ but on Ruby, Perl and Python and are aimed at, among others, “script kitties”. The mind boggles. Where we once had the heavyweight Rational Unified Process, RUP, we’re now back to basics with RuPP (Ruby Perl Python). Would I build a provisioning infrastructure with Ruby? I don’t know to be honest. I wouldn’t touch Perl with a bargepole and I’m not a great fan of a language that relies on the preservation of indentation to work (Python). PHP is superb IMO due to its C syntax and ease of use but I’m coming from a C background. What if you’re a script kitty, with no experience? You’d prolly want to use Ruby or Python in that case as you’re prolly more influenced by the community than the suitability of the technology for the task in hand.

Is Web 2.0 affecting academic software development? C++ is still the most used language on the planet but there are virtually no C++ programmers in academia. C and Java come next, again with next to no academic proponents. Developers in academia are exposed to much more social software than those in business I suspect and therefore tend to cluster into communities, where the latest language is seen as cool, awesome and the rest. Whether it’ll get the job done seems to be irrelevant these days. It’s the cool factor that counts.

Often a language has a high barrier to entry, such as Java and even more so, C++ but once you’re there, you find that you’re far more productive than if you were slogging away with a scripting language. Take XML for example. The explosion in cheap computing and memory makes it more productive to use Java with XML, using XML Schema as native objects and never having to deal with raw XML and namesapces. You can’t do that in Ruby, Perl or Python. You’re still stuck with raw text and namespace handling can be dodgy at the best of times. But for other tasks, scripting is the better option, such as shuffling text files around, transforming text and creating text reports. Move up a notch to integration and you start to get bogged down in the autovivification of these languages and bugs get harder and harder to find, not to mention lack of support for native technologies such as COM. Whereas SOAP and REST are taking over the unix world, COM is still big in Windows and some applications only have a COM interface.

So what am I going to do? Well, I’ve already started on the Ruby learning curve with Flikbak and I’ve been doing reporting scripts for the account creation system, which is written in Java and C++. I could port the Java to Ruby but that would mean moving to RPC for creating Novell home directories as Ruby does not support NDS. I can’t port the C++ as Ruby doesn’t support COM. But should I use Ruby in the big provisionong framework I’m designing? Perhaps. We’ll see.

comments powered by Disqus