In my job, more and more I find that we end up building distributed architectures, i.e. multi-server installations where services are routinely spread around 20+ Windows boxes, plus the occasional Unix. These services have specific startup and shutdown sequences and dependencies, so they can't just be set to Automatic startup; we usually provide batch files to manage them, but this is quickly becoming ugly and unreliable as the number of machines go up every year. It's also tricky to test actual service availability -- some are binary-based, some are HTTP based, some are Weblogic services, etc etc etc... So I'm investigating alternatives.
The first, natural choice for me was obviously Python: it does everything I need, it's flexible etc. However, distributing scripts to customers is a bitch; either you compile everything with cx_freeze (crashy) or py2exe (no python 3! no 64bit bundling! party like it was 2004! have fun tracking down which un-redistributable DLL or manifest you need on each release...), or you drop an entire environment and teach the customer what python is -- not ideal.
The traditional "native" approach to these problems in the Windows world is VBScript. It's fairly flexible, doesn't need to be deployed on Windows Win2003+ (yes, we still deal with loads of Win2003 servers), documentation is extensive and there are plenty of resources out there.
The problem with VBScript, apart from the ugly syntax and pseudo-OOP quirkiness, is that it's clearly seen as legacy by Microsoft. Year after year, running scripts becomes more cumbersome, security checks increase and new technologies don't expose the necessary interfaces. Does it make sense, in 2011, to invest time and effort building solutions that are, de-facto, already obsolete?
So we come to PowerShell, Microsoft's "future of scripting", which must be the less intuitive shell I've ever had the pleasure to deal with. I simply can't get my head around the way it deals with input and output; it doesn't seem to have reference assignment, so you have to retrieve an object on every line before you can use it; the syntax seems to combine the worst of Perl and Bash, and it quickly becomes unreadable. Also, deploying it on anything older than Vista has to be done manually and has to be justified to customers.
I honestly can't see a good solution here. I keep looking at IronPython, but its infrastructure baffles me and I wouldn't know where to start redistributing programs (I don't use Visual Studio). It's clearly a second-class citizen in the .Net world, with all that it entails.
Maybe Jython? After all, the products we install will drop JREs absolutely everywhere, so I could leverage that. I'd like to avoid going full-Java if I can, I hate the whole byzantine toolchain and I'm not really up to speed with post-1.4 changes; plus, there's always a degree of customization required in each environment, so I'd like to keep stuff as easily-editable as possible.
Please feel free to drop any suggestions in comments, I could really do with them!
Hi Giacomo,
ReplyDeleteI work for DZone.com and I found your blog today and I wanted to let you know about some opportunities to feature you as an active Python community member. Shoot me an email at mpron [at] dzone [dot] com and I'll tell you more.
The current Jython is still stuck at Python 2.5 compatibility. If you can live with that, then more power to you.
ReplyDeleteI'd be tempted to revamp some very basic and rusty Scala skills or learn Clojure (some kind of Lisp/Scheme dialect or equivalent: I reckon you may be interested and leverage that Lisp book I don't remember the title of that's been sitting on your desk for quite some time now) but in the end I think I'd probably go with JRuby. When I got faintly interested in broadening my knowledge of JVM languages a couple of years ago, I remember to have been under the impression of it being quite solid and up-to-date with language features, and I believe it's still like that.
I've ended up writing some 500 LOC in Jython, because I've found that basically all products ship it, hidden away in a common folder. It is an old version (2.2) but this wasn't much of a challenge: the only thing I'm missing is the logging module (in stdlib since 2.3, and the third-party package that supports 2.2 and earlier seems to rely on a C library, which doesn't work under jython 2.2), and there's an odd message printed to stdout whenever I write to a file, but apart from that, it's ok.
ReplyDeleteNow I'm going to introduce some advanced checks using httplib and sockets, if I find any trouble I'll simply drop the latest jython.jar. Now I'm actually curious to find if I can leverage actual product libs from jython, which would open some interesting perspectives.
Now I'm actually curious to find if I can leverage actual product libs from jython, which would open some interesting perspectives.
ReplyDeleteCommon sense dictates that, if they're written in Java, you should be able to. I don't know how well Jython plays with features such as generics or enumerations, just to mention two newcomers from the Java 5 old days (Java 7 shipped some weeks ago, you know), but maybe you won't even have to worry about it if Jython shields you from the annoyances of the underlying static strong typing world.
I know this is a year and a quarter later, but I did a blog post about IronPython vs. Powershell:
ReplyDeletehttp://gktr.us/DC
Hi Priya, 11.1.2.3 has been released only this morning, so no, I haven't. I know Jython is supposed to replace VBScript for integration scripts. I can't say I'm sad: I've never particularly liked VBS, and I do like Jython.
ReplyDeleteDepending on the environment in which these scripts will run (whether it's sandboxed or not, it's real Jython or just a subset, etc etc), you could end up with a tremendous amount of power (you could use almost any Java library out there, and a lot of pure-Python ones) and very readable scripts.
However, it'll be curious to see how you guys deal with the main quirk of Python/Jython, i.e. significant whitespace. At minimum, you'll have to use good text editors. Also, Jython is always a few versions behind "real Python" (which is why I didn't eventually use it for anything), and even more so when shipped by Oracle; I bet there will be a lot of "I got this code from the internet and it doesn't work" moments.
Jython, like all Python dialects, is very easy to pick up and tends to produce very readable code that often reads just like English ("if someValue is in someList:", "for someVar in someList:", "if myVariable is True:" etc etc), but it's still a programming language.