Tools, languages or frameworks — which will have the biggest impact on developer productivity? I previously said that I thought languages could do better than frameworks in this regard. Now I’ll talk about at least one class of tools.
A good deal of focus around developer productivity is on visual editing tools. I think these efforts are misguided and unlikely to produce major benefits to developers. Clearly tools are useful. Humans are natural tool makers and users. Written language is arguably the most important tool invented by humans. Programming languages are tools.
So what do I mean by visual editing tools? My definition may be a little fuzzy but here it is: I’m talking about tools for creating software that don’t have an underlying text based language or completely hide it. They usually involve working with pictures, diagrams, or forms. Some examples:
- Business Process Workflow editors
- Property editors
- Visual UI layout editors
These are some of the general problems I have found with visual editors. Not all of them have all these problems and I’m not signaling out a specific tool.
- Scale — Sometimes the visual editors don’t take scale into consideration. They work well for small programs but break down when used on larger programs. The breakdown may be due to implementation details or a more fundamental limit in ability to comprehend the visualization at large scales.
- lock in — This is when a tool requires you to use a particular platform, IDE, tool set, library or framework. The same lock in is possible with languages but it tends not to be; at least not for the more popular languages. Perhaps that is what makes them popular. As a developer I’m very skittish when it comes to lock in. It is much easier to share (and reach agreement on) a language specification than it is a GUI specification.
- Poor source control integration — Being able to track changes to software source over time is very important. Some tools make arbitrary text changes that confound source control systems. The worst example I have seen is a visual work flow editor that changed all ids in its XML format source file every time you saved it. Binary formats are a definite no-no.
- Lack of flexibility — When writing software in a text based language you are free to write in whatever order your thoughts come to you. Tools that force you to translate your thoughts into specification in a fixed way will end up frustrating users.
- Inefficient — I tend to find that visual editors get in the way after a while (if not right away). They tend to require a lot of mousing around. Once I know what I’m doing typing is much faster.
Good editing tools assist you while working with a text based language. The most basic editing such as random access to the text, insert, delete, cut, copy, paste etc. is sufficient to get the job done and has the benefit of working equally well for all text languages. Advanced features such as syntax coloring, unobtrusive flagging of errors and warnings, context sensitive completion, access to language and API help, type based searching and navigation, refactoring, template insertion/completion, bracket pair matching, indenting etc. are very useful and don’t replace or get in the way of the text.
Diagrams can help visualize aspects of programs but programs are too complex and multidimensional to be fully represented in any picture or diagram so it is a mistake to think that the visualization is the program and can be edited directly. Being able to draw (or even edit) diagrams is a nice add on for a language but the language must come first and stand on its own.
Some tools claim to have an editable underlying text format when in fact it is just the tool’s internal model serialized as XML. This doesn’t count. Not because its XML but because it tends to favor ease of serialization and the needs of the tool over the ease with which humans can read and write it. XSLT is a good example of a language that uses XML syntax. It was clearly designed to be edited directly by humans. The fact that it can’t be fully described with XML schema is probably a good indication of this. I like XSLT but I also agree with Terence Parr when he says “I implore everyone to please stop using XML as a human interface!” (see his excellent book “The Definitive ANTLR Reference”) .
The best development productivity tools help the user write in a given language not replace language.