Having been a developer for 20+ years, I occasionally look back and wonder about the great advances that the industry has made in this time. These, of course, are:-
1) Syntax highlighting
2) Test Driven Development
Ok, maybe, a bit facecious, but sadly, not much. It seems to me that the technology that we use today is not much changed from when I started writing RTL-2 on PDP-11s back in the 80’s and when I try to think of things that have had a real impact on my day-to-day work, these are the two that spring to mind ;^)
In particular, I am constantly surprised by the fact that (for the most part) we still represent code in text files. I understand, that developers have a deep-rooted fear of losing control of their beloved text, but this particular phobia has a number of consequences, in particular in the tools that we use to create code.
Text editors have no notion of the intent (or even the structure) of the code and hence, all they actually do is help you type a bit faster… Whoopee do ;^)
IDE’s try to go a step further (err, sideways) but tend to fall into the same trap of thinking that what we need is to be able to write code faster and hence become little more than glorified text editors. What we actually need is to be able to read and determine the intent of code faster.
As an example take the popular Eclipse IDE (I’m not picking on Eclipse – substitute pretty much any IDE here). When editing code the main focus of the developer’s attention is directed at the “editor area” which shows the textual representation of the code in one or more files. The task of editing is (optionally) supported by an “outline view” that shows the actual structure of the currently selected file (what class(es), attributes, methods etc). In a text-based world-view that makes perfect sense, but what I would like is to flip that around and have multiple “outline views” (as the focus of my work), supported by a single editor view that shows me the textual representation of the currently selected outline. To understand the intent of the code it is the structure and relationships expressed in the code that I need to discover – so why not have the tool help me do it!
As another example, take the ever-present “formatting wars”. Developers like to layout their code in a myriad of ways and all of them are right! The problem is that reading code written in a myriad of ways is neither a) efficient nor b) pleasant, and so many teams introduce coding standards to produce an acceptable team ‘style’ (often after lengthy and tedious debates about where a curly-brace should go, and occasionaly after a code “Tzar” stuffs in a code formatter onto the front of the code repository – mentioning no names, Duncan ;^) When code is parsed an Abstract Syntax Tree (AST) is produced – why not use that as the storage format and allow each developer to specify how the code is textually formatted for them so that they can read it unhindered by somebody elses weird and wonderful layout.
And these issues are just the tip of the very cold thing. Tools for testing, refactoring, metrics etc – could all benefit from a more integrated approach – at least that is my hunch…