Lean startup language design

At a recent hackathon, I was noodling around with Dart. I thought it was great that Google made it particularly easy to start playing with their new language by putting an interactive shell — the Dartboard — on its home page. No download, no installation, instant coding. Very nice. On the other hand, they made it unnecessarily hard to find any information about the language on the internet by calling it Dart. Particularly when you search about throwing exceptions…

Trying to implement a small project in this new language I haven’t seen before made me wonder: How effective do language designers use feedback? On Dart’s website, they ask for feedback, which is mostly organized in groups. What they should really do is to bring in some developers and monitor them as they try to solve simple tasks with the language under development. After all, creating a language is just another software project with end users. Or better still, at this stage they should log and analyse compiler errors from the shell on the website. If people keep producing the same compiler error over and over it is probably an indicator that this particular construct of your hip new language just might not be very intuitive.

Let’s assume Google logged and analysed what happened in our session from this week’s hackathon — and they most likely did, they would come to the conclusion that having two different notations for creating a function was confusing for us. Especially, because only one of them caters for certain scenarios. Either that or that there were two idiots in front of the computer who needed 20 minutes to figure it out. You can judge for yourself:

[sourcecode language=”java” wraplines=”false”]
main() {
(function() => print(‘Hello again’))();
}
[/sourcecode]

This works just fine. It creates a function that prints ‘Hello again’ and executes it.

[sourcecode language=”java” wraplines=”false”]
main() {
(function() => throw new Exception())();
}
[/sourcecode]

This, on the other hand, gives you a (not very useful) compile time error that the token ‘throw’ and ‘new’ are not expected. While this is entirely true, it sent us in the wrong direction to check how to throw exceptions. While the actual mistake was that you can only use expressions with the => notation. If you want to use statements, like throwing an exception, you need to omit the arrow and use a block with curly braces instead.

[sourcecode language=”java” wraplines=”false”]
main() {
(function() {throw new Exception();})();
}
[/sourcecode]

I hope other language designers will follow Google’s example and show off their language as early as possible to get feedback on their decisions. Maybe even without the developers being aware of it. I don’t see any reason why lean startup ideas shouldn’t be applied to the creation of a new language. Can you?

Photo by Sergei Zolkin