This post originated from an RSS feed registered with Python Buzz
by Ben Last.
Original Post: Ready To Hand
Feed Title: The Law Of Unintended Consequences
Feed URL: http://benlast.livejournal.com/data/rss
Feed Description: The Law Of Unintended Consequences
Heidegger wrote, interminably and in German, of the difference between objects that are ready-to-hand and present-at-hand. The difference he saw (and I make no apologies for drastically simplifying the philosophy to let me make my point) is that the latter is whatever it is we're thinking about, and the former are the things we use without thinking about them. For example, right now, I'm thinking about how to construct an absurdly overwordy sentence to make a simple point and therefore sound clever (present-at-hand) but I'm not thinking about the keys on the laptop, or the various decorations around the Semagic window in which I'm typing. Sure, they're there if I need them, but they're not the focus of my attention. They're ready to hand.
Good IDEs follow certain consequences of this principle, either through design or heuristics. For example, Microsoft IDEs all now use tooltips to popup little bits of information as you code or debug. It's surprising how often the information displayed follows one's line of though. I type the open-bracket for a method call and lo! a list of arguments pops up just as I start to try and remember the exact order of them. What I'm focused on changes as I work my way through code; from high-level design through the construction of the actual logic to the contracts for calling library objects.
Of late I've been spending way too much time in Eclipse - and here I have to pause and say that it's caused me to reconsider a whole bunch of opinions I had about large Java programs. In a good way. Last time I tried out Java-based Java IDEs, they were vast and cumbersome beasts that took hours of CPU time, megabytes of RAM and whole swathes of swapfile to even get to the point of starting up. And when they did run, they looked awful and had interfaces designed by the Marquis De Sade. It was a relief to run screaming back to the simple comforts of vi (and that's not a phrase that you hear too often) and the command line. Eclipse is different. Yes, it probably does take up many system resources and it's just that the machine I use is a damn sight more powerful. But in both form and function, it's a very well-designed environment.
Something I like about it (and it's not a unique feature) is the way that different elements can be linked together. Change the file you're viewing, and other windows all quietly update to reflect that new focus. Shift thread in the debugger and there's that same ripple of change as everything around shows you information related to it. Lovely. Yet it only works on so many levels, and there's one level that's missed. Google.
I was speaking earlier this week to a developer who'd been struggling with an obscure problem (in Python, as it happened). Eventually, I asked him if he'd Googled to see what experiences others had had. His reply was interesting - "I don't really do that, I prefer the manuals". I find that an odd position to take. Nowadays, when I'm looking at a new area of some language or development, one of the first things I'll do is fire a few queries at Google to see what others have to say. Take, for example, the creation and use of Images in J2ME/MIDP 1. It took around three minutes to find severaldiscussions of what could and could not be done (and a few rants about how brain-dead the design had been, but you got to work with what you have). Sure, I could have inferred it from reading the API docs, but what I wanted was real humans writing about what they'd found, in language that makes sense to me. Coder speaking unto coder.
So that's what I want an IDE to have, as well as the type hierarchies, the file lists, the error messages and the stacks of cryptic toolbars. A Google window that, quietly and without taking too much of my CPU or bandwidth, looks up comments from, say, comp.lang.java (or comp.lang.python, depending on file type) that relate to whatever-the-hell I'm working on. Sure, it's a whole different class of problem from automagically doing content-sensitive help, but the team who can solve it would be rich in kudos owed by developers all over the world. The actual coding is left as an exercise for the student, naturally...
Previous Topic
