|Tools Doth A Language Make|
|Written by Mike James|
|Thursday, 13 December 2018|
Page 2 of 2
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.
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.
It is even possible to think up a safety-fying of C using a suitable IDE. NetBeans for example will point out when you are using an unsafe function and even suggest that you might like to use a safer function. We could take this much, much further with default bounds checking that could only be defeated by a conscious act on the part of the programmer.
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 language 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. To augment a well known motto:
language = syntax + semantics + IDE
or email your comment to: firstname.lastname@example.org
|Last Updated ( Thursday, 13 December 2018 )|