Of Tools and Languages

People often discuss tools for languages, often discuss languages, but rarely discuss languages for tools. If you haven't checked the NBL - The Next Big Language - go read it. Until, of course, you don't care about new languages. Here is small quotation:

Most programmers don't realize how often they need to deal with code that processes code. It's an important case that comes up in many, many everyday situations, but we don't have particularly good tools for dealing with it, because the syntax itself prevents it from being easy.

Being tool developer myself, I must say that it is often extremely hard to make desired feature. Not that it is hard to implement the feature, but rather understand how it should work in a particular language and how to "fix" the language. Few examples to illustrate the problem:

Braces in C#
C# block delimiters are braces, symbols "{" and "}", and they are used everywhere, and thus has context-dependent semantics. For a class body they surround methods and properties; for a method they designate start and end of implementation code; inside method they are used for conditional and loop blocks. The problem is that they can easily become unmatched, and thus closing braces change their meaning. The one which was at the method end suddenly becomes closing brace for the loop, method borrows its closing brace from class and all the code looks broken. ReSharper's code analysis goes crazy and highlights the rest of the file in red.

Note, that we don't have such problem in Visual Basic .NET, because we have different "braces" for different constructs and we can detect unmatched "brace" early. However, VB.NET has own problems...

Name suggesting in VB.NET
ReSharper always had name suggesting feature for C# - when you have name of the type in the editor plus space and hit Control+Space you're presented with generated names for local variable or field:



Those names are generated from type name to the left. Note the order - type name first, than declaring symbol name. In VB.NET the order is the opposite. You first give name to the declaring symbol and then specify what type is it.

ReSharper can't help you find the type for the specified name, it would be too slow. We have to invert the order, and we do so by providing "dim" Live Template:



We have similar problem in C# with interface implementation, actually.

So what?
No modern software development process can exist without tools. Continous integration and version control, refactoring and code editing, error detection and code analysis - all these require tools. If the language doesn't support tools, tools cannot support language very well. It requires significant effort to develop tools for unfriendly language and thus less tools appear on the market. At times tool vendors attempt to "fix" language editing expirience with techniques that are not natural to the language itself, because at some moment they need information not typed in yet. In order to get maximum information about developer's intention, we create special features for each intention (like "surround with") instead of understanding what is being typed; just because language forces us to do so.

That said, if you are creating your own language, or even the Next Big Language, be sure to consider tools as a major thing influencing language design.