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


Importance of an IDE

The IDE is seen as something separate from the language and not part of the language design and implementation problem. This is about as wrong an attitude as it could possibly be. 

It is like a motor car designer working away on an new engine and then expecting the end user to figure out how to make use of it within some bodywork and other extra bits. 

A language design is just a start. What matters is how effectively programs in the language can be created and executed. The effective creation of programs is aided by an IDE and other tools. The effective execution is a matter for the compiler or runtime and this is what language implementers focus on. 

There are many language features that are much better to implement in the IDE rather than the language. If there is a language feature that is causing programmers to make mistakes then you can either change the language or add a feature to the IDE that picks up the mistake and highlights it for the programmer. A static or dynamic code analysis in the IDE and trap potential problems and draw the programmers attention to best practice. 

A poor language becomes a great language when it is coupled with the right IDE. 

For example, if it is undesirable to use the Eval function in JavaScript then we can either remove it from the language, remove it from strict or some other mode or create an IDE that flags it as a dangerous option.

On a bigger issue, type inference can do away with the need for static typing. If you think that this is an exaggeration try out JavaScript as provided by Visual Studio - it is not quite good enough, but it could be. If you still don't think that type inference can replace static strong typing find an example that can be detected by strong typing and not by a sufficiently clever IDE with type inference. 

Yes, an IDE can provide you with a lot of small things that make your work easier and more accurate. Perhaps the best example is code completion which speeds the entry of code and makes sure you don't make stupid errors. I am not so sure about syntax highlighting, but all manner of auto formatting can make an error stand out immediately. The list goes on and what is more the list can be extended even further. The innovative sort of live coding environment suggested by Brett Victor and Microsoft Research is just the next step, not the end point.




You can argue about individual features and facilities and yes you can still argue that a simple text editor is all you need but the point is bigger.

The point is that the development environment should be considered part of a language. A different IDE coupled with a language should be considered a different but compatible dialect of the language. We should talk of NetBeans Java and Eclipse Java and so on. Ruby shouldn't be Ruby on Rails but Ruby on RubyMine or Ruby on Aptana. After all, if you switch from, say, Visual Studio C# to NotePad C# you are as disadvantaged as if you had swapped to a completely different language or dialect. 

But we need to go yet one step further Language designers and implementers should take the view that an IDE should be a standard part of their design and their work should be judged on the whole package provided. Python 4 shouldn't be a new langauge but just Python 3 plus a new and standard PythonIDE that extends the language and defines it as a complete development environment. 

A language is not enough and the job isn't done until its a language with a fully programmer supportive environment. 


language  =  syntax  +  semantics  +  IDE 


Related Articles

A Better Way To Program

RubyMine The Right Way To Do Ruby

Data Typing Is A Relic

Beginning PHP with Eclipse 

NetBeans IDE 7.3 Released






blog comments powered by Disqus 

Last Updated ( Friday, 03 May 2013 )

RSS feed of all content
I Programmer - full contents
Copyright © 2015 All Rights Reserved.