Programming languages are a perennial topic of debate. If you ask whether X or Y works better, you’ll find a substantial group of people claiming X works better, and another substantial group that says Y. It becomes almost a religious debate, with no well-understood facts.
Can we make this debate more objective? In other words, if someone goes off and designs a language that they claim achieves certain goals, we should all be able to agree as to whether it really achieves those goals. There may be many ways to get there, and different people may choose different ways, but at the end of the day, we should all be able to agree on whether the language as designed achieved its goals.
This is similar to transport planning. If you’re in charge of transport planning for a major city, you have many options available — metros, suburban trains, bus rapid transit, motorways, ferries and so on. Different people might pick a different set of these options, and combine them in different ways, to achieve their goals. That’s fine. But, no matter what specific solution that was chosen, it’s possible to conduct a study to find out whether the system achieved its goals — what’s the average commute time in the city before and after the system? What’s the pollution levels on major streets? What’s the average commute cost? How much money have people saved by not having to buy cars? And so on.
By the same token, different programming language designers may make different decisions to reach their goals. That’s fine. But no matter what particular decisions that were taken, we should be able to examine the result — objectively determine, and agree on, whether the language achieved its goals.
To do that, all language design efforts should start with a crisp set of goals, as a one- or few-page document. These goals should be expressed in terms programmers and end-users care about. For example, you might say that your language makes mobile apps consume 20% less battery than Java or Objective C. Or a server handle 30% more connections with the same latency. Or whatever it is, in terms that affect the bottom line. Not programming language jargon like being statically or dynamically typed. Those are not goals; but means towards (hopefully) certain goals. So talk about the goals, not the way to get there.
And measure your language against these goals. Build a bunch of realistic, rather than toy, apps. For example, a notes app, an email app, and a maps app. And measure the performance of these apps against your metrics, and show that battery life is indeed optimised by, say, 20% as compared to Java and 10% as compared to Objective C. This is a major project by itself, but essential, because otherwise, nobody knows whether the language achieved its goals, and we regress to programming languages as religion. And if you can’t demonstrate a solid improvement (ignoring contrived examples), then you didn’t achieve anything at all.
I think this is a big part of why most new languages are not adopted widely. After all, if you’re working in the trenches, always under pressure to deliver something by a certain time, and someone comes along and says that they have a better option, but can’t prove that it’s better, in any way, would you trust them? No, you have a job to do, and you’d stick with what you and your team know and use. But if you could objectively and scientifically measure the performance of the new language against its goals and against what you use today, then you’d take the newcomer seriously.
So, language designers should start with a clear, numbered list of goals, in a one- or a few- page document. These should all be expressed in terms programmers and users care about (20% less latency, not: dynamically typed), and a suite of real apps should be built to objectively measure whether the language meets those goals.
This will make language decision more of a science, rather than a religious debate. And a language that objectively proves its merits will be adopted quicker, benefiting programmers and users.