So Bob Pasker has a typically thoughtful response to my post regarding the changes I’ve made to the infrastructure of the Prime Mover simulation framework. The regaling of my adventures reminds him of his conclusion that Java is a lousy language for building infrastructure.
It’s something that I never really thought about, personally. It’s not that I haven’t cursed Java for some reason or another on a continual basis since I started programming in it. But that’s always the way it is when you’re pushing the limits of what a language is capable of and what a system is designed to do. You love to hate it and the very fact that it fights against you as you bend, fold and mutilate it, in the process of violating the warranty is just our way of saying that we really love it – really, we do. Sure, it’s not a healthy relationship, but then again, specializing in these kinds of things has never really been healthy.
Now, I must say that, in defense of proposition that Java as a fantastic language for building infrastructure, that the “pain and suffering” I experienced (not really, but I know it looks that way from the outside) in the refactoring of the guts of the Prime Mover infrastructure really didn’t have anything to do with the shortcomings of Java as an infrastructure programming language per se. Indeed, the primary library that I’ve made use of in this project, the ASM byte code engineering framework, has proven to be a superlative tool for doing precisely the kind of stuff that Bob reminisces about WRT the days of the wild, wild west – back when we had to wrangle byte codes with our bare hands and force them to our will using nothing more than our teeth and a screwdriver.
Rather, all the issues I documented wrt Prime Mover have been problems of my own making – in the end, I’m always the worst enemy I have. Far outstripping any puny terror and punishment that Guy Steel or the hordes of Orc programmers over at JavaSoft can dish out.
Regardless of how it sounded, the problems I had really didn’t have anything to do with the lack of sophisticated and useful tooling or frameworks. As I’ve mentioned, the ASM framework is quite sophisticated and provided a stunning environment which allowed me to produce the system. Looking back ten years and thinking about the tools we used back then to do stuff that isn’t nearly as complicated… well, there’s simply no comparison.
The mechanics of transforming the byte codes and bending them to my nefarious plans never was the issue. Instead, the problem was what I was actually trying to do. ASM, rather than getting in my way and limiting what I was able to do, provided me with not only a simply amazing transformation framework, but also supplied the analysis tools that gave me the mechanisms to figure out what needed to be done, where and so forth. The tooling and frameworks weren’t the issue.
At the heart of the problems I imposed on myself was the rather large mistake of trying to be too clever by half and remove the proxies from the picture. Doing this vastly complicated the issue and actually forced me to solve a far, far harder problem – i.e. discovering precise type information in the data flow of the code I wanted to transform. If it was easy to solve this problem, then we wouldn’t need HotSpot or any other advanced VM technology – we’d already have the fine grained type information needed to do all the optimization compiler technology would allow us to do.
Once I had eliminated that blind spot caused by my poor initial architectural choices, the code become dramatically less complicated and simultaneously more robust in the process. The capabilities of the system also grew, solving some nasty dangly bits that I hadn’t realized were hanging there, waiting for the cat to start swinging at them when I wasn’t looking.
Now, this isn’t to say that things couldn’t be better. Things can always get better. But when I look around at the alternatives, I can’t help but consider myself to be extremely lucky. We’re far from perfection, to be sure. But I’m doing things that are literally impossible in other languages and/or face insurmountable difficulties because of either the lack of maturity wrt Java or the dearth of tooling for them.
I mean, I don’t even want to think about what dark pacts I’d have to enter into to implement Prime Mover in any other language. Certainly, it’s not really possible to implement the same architecture because of the lack of a virtual machine and byte codes in languages such as C++ where systems infrastructure is traditionally done. But even in languages like C#, where there is the prerequisite VM, the paucity of tooling and lack of support for building infrastructure is far behind the amazing array of tools we have in Java.
Geebus, I’d better quit while I’m ahead – I don’t want to sound like even more of a Java fan boy than I already do.
But still. Working at the systems infrastructure level in Java has never been better and given what we have available today, it’s a quite sophisticated and truly amazing place to work. Quite unlike the wild untamed days when we were first doing this stuff…