Tools Doth A Language Make
Written by Mike James   
Friday, 03 May 2013
Article Index
Tools Doth A Language Make
Importance of an IDE

Languages are not islands that can be considered in isolation. They have to be part of a development environment and it is time that this was fully recognized. A language isn't just syntax and semantics. A language is syntax, semantics and an IDE. 


When the merits of a language are considered it is very often the case that it is the bare unsupported language. Language is pitted against language but it is often the case that a language is used with a set of tools that enhances its behavior in all sort of ways. This is bad enough but languages are often "improved" to include cumbersome or restrictive features that would be much better provided by a suitable tool. The message is that we need to consider the entire ecosystem that surrounds a language before we evaluate it or "improve" it.

Okay, so English spelling is terrible. Really, really terrible. So what is to be done? We could reinvent the spelling system so that every word had a perfectly logical spelling that was next to impossible to get wrong. This is an approach that fits in with the "hard line" mind set. The problem is that changing the spelling would mean we couldn't access all the years of literature that had built up unless we went in for a huge conversion project. No - changing the spelling rules is not a good idea. What is a good idea is inventing the spell checker and corrector. In practice this brings the level of correctness up to something beyond what you might expect with a logical spelling system but no spell checker. 



More cartoon fun at xkcd a webcomic of romance,sarcasm, math, and language


The point is that the language has a weakness, a flaw even, but instead of changing the language we create a tool that enables  the language to be used more accurately and efficiently. 

As it is with natural languages so it is with computer languages but we tend to forget this because computer languages are perceived to be more changeable. If there is a perceived problem with the language we can fix it in version x.y+1 and in version x+1.0 we can more or less rip the language up and start again. 

This isn't always a good move and it is fairly often the case that the same result can be obtained in a more efficient and powerful way by not modifying the language but by augmenting it with tools.

This is not a very common view point because for a complicated set of reasons there are lots, perhaps even the majority of programmers who just don't believe that tools exist or should exist or could exist. 

How often have you heard or said "I program using just Notepad, Emacs, Notepad++, vi or that utility I created while waiting for a compile to complete. 

There is both a macho culture about building programs with as little visible support as possible and a very read psychological dependence on the first set of editing keystrokes you learn. As long as you use the editor often enough and for long enough just about anything can seem productive to the point of excluding an alternative. 

When you change to a new programming environment it all seems strange and clunky and you immediately think that your original way was better. And of course the macho payoff in saying "we don't need no stinking IDEs" and returning to a text editor and flying by the seat of the pants is huge. 

Partly to blame is the way that popular language distributions are just that - language distributions. I tried to "get into" Ruby recently and after downloading the language implementation was dismayed to find that all I had to get started was an interactive REPL. If you download Python at least you get IDLE which calls it self a Python GUI. This is not a GUI this is a minimal code editor with a run button - better than nothing but it could be so much more. 



IDLE is better than nothing but as an IDE it is just a start - and it needs to get more ambition


There are so many languages that you have to ask the community how best do I work with this?

What is really surprising is that you will usually not get a single clear answer. 

I'm not picking on any particular language here - they all suffer from "the language is enough" syndrome. JavaScript, Java, Lisp, Lua, R, Go, C++, and so on all come as they are and expect you to find or work out a suitable development environment to use them in. If you think that any of these do come with a development environment then either you have low expectations of a development environment or you have provided your own.

The one big exception to this picture is the Microsoft languages C, C++, C#, Visual Basic, F# and so on have all been delivered with a full IDE in the form of Visual Studio and if you learned programming via this route you will perhaps not fully understand my concern when it comes to other languages. Move away from the Microsoft environment and you will be hard pressed to find and IDE as good as Visual Studio - Eclipse and its derivatives sometimes get close and NetBeans tries but they still lack so many of the features that you take for granted in Visual Studio - even compared to the free Express editions.

This is something Microsoft has got right for some time. It has packaged its languages complete with an IDE and seen the system very much as a whole. 

Yes I guess that there are a few people who swear by using C# with the command line compiler but the majority know better. 

The problem is that even Visual Studio is just a step on the road to the sort of help that IDEs and other tools could provide the programmer. We have hardly got started in crafting the tools we need and you tell that this is not a wide spread opinion by the way language communities simply don't bother to provide IDEs to wrap their languages in. Ruby is just Ruby not Ruby plus an IDE.

Last Updated ( Friday, 03 May 2013 )