Late last week, the boss sat me down with a new task that boils down to reusing part of a previous solution which I wrote in Perl. Both utilities rely on library support for reading in DBF files. Perl’s XBase library is watertight, which is more than I can say about other free libraries for more “serious” languages.
Given that XBase just lets me get the job dome, there’s been no real desire here to revisit the Perl decision, despite the fact that the previous build exposed a drawback Perl has in dealing with large data sets in-memory. Specifically, dynamically allocated arrays grow exponentially in pre-allocated memory whenever the array gets close to filled. Doesn’t matter for small data sets, but I’m occasionally into data sets sometimes climbing into the gigabyte range. That’s a huge amount of potentially wasted memory and unnecessary page swapping to disk.
Anyway, the reuse potential with the new job involves extracting a common library for exporting data to a 3rd-party tool. Now, the first time I just whipped the Perl solution up in VIM, and deemed it good enough. This time, as I’m essentially doing the same thing over for file exports, the extraction of a shared library could be made easier with a rich IDE environment.
I took a brief look around, and found EPIC, touting itself as a Perl development plugin for Eclipse (which, given its lack of any financial cost, and ability to run cross-platform, keeps ending up as a favoured IDE).
EPIC didn’t take too long to download and install. Configuration boiled down to be little more than simply telling EPIC where the perl.exe file resides. From the screenshot below, you should be able to see a few of the more obvious features such as syntax hi-lighting (which is about where VIM stops), outlines of methods & variables, easy navigation of the project space, etc.
The EPIC development environment is a lot more powerful than VIM, so in that sense, I’ve had a win. However, there’s some buyer’s remorse happening here. There are two big-ticket items that are really baking my noodle.
First, syntax checking seems to only really work properly once a file has been saved. Things get odd between saves, with phantom problems being reported which are in are fact syntactically correct. What this means is that I’ve developed a subtle instinctive distrust for the issues being reported to me unless I’ve just saved a change. I’m finding the issues reported between saves an unwanted distraction, because I can’t trust them to actually be issues.
Second, and also my greatest disappointment, lies in the near non-existent support for automated refactoring. EPIC supports a grand total of a only a single refactoring technique (extract subroutine, to be precise). Not even renaming of methods and variables is available, which tend to be bread-and butter techniques for me when I’m engaged in refactorings like extracting a generalised library.
And that leads me to an important insight (one I’ve had before but forgotten). A killer-app feature of IDEs that sees me enthusiastically embrace an IDE over the more scary-end text editors like VIM , is support for automated refactoring.
It really gets to me that a task that is completely automatable isn’t made so for a programmer, where our very jobs are all about automation. As a consequence, I’m pretty bloody harsh about it missing from modern IDEs.
It’s entirely possible that there’s just not the scope for achieving a rich set of refactorings given whatever limited chatter EPIC might be getting back from the Perl compiler. I get that, and find myself already cutting EPIC some slack if we’re dealing with a black-box compiler making things difficult to get anything back but a cursory guess at code structure.
Deeper down, I’m getting constant violations of the rule of least surprise, and no matter how thoroughly I reason it out, I’m not pleased.