Designer Language: a programming language created to avoid the perceived shortcomings of an existing language, usually by creating a superset of the existing language by modifying syntax or modifying programming constructs.
The designer language usually compiles to its parent language and its compiler is usually written in the new langauge itself. The latter of which apparently adds a wow factor to the whole affair.
But all this is nothing new. The Java language has survived its share of designer languages over the past decade or so.
Designer Languages: The Java Frontier
James Strachan introduced the Java world to Groovy in early 2007. Dynamic and loosely typed, Groovy built upon the strengths of Java but had additional power features inspired by languages like Python, Ruby and Smalltalk.
With the invention of web frameworks like Grails, Groovy continues to influence the J2EE landscape to this day. However, it wouldn’t be long before the J2EE landscape would again be rocked.
Similar to Groovy, but with an increased focus on Functional Programming, Scala is another interesting designer language built on top of Java.
In early 2009, a burgeoning social media company (Twitter) picked up on a little known language called Scala. Famously, a Ruby on Rails shop, Twitter kept Rails for its presentation layer and swapped out its backend with Scala.
Twitter’s move to Scala sent ripples through the Rails community and ushered in another star to the limelight. But this is the nature of designer languages - to ripple, to rumble, to roll.
In a short two years, CoffeeScript managed to influence legions of developers. Simplicity and clean output was the key:
That’s the greatest lesson to be learned from designer languages. That the future isn’t written in stone. That we too can influence its path and shape its fringes.
CoffeeScript went on to influence and spur further designer languages in both the static and dynamic space.
Developers weren’t too happy with that type of result and the push back was strong. Rightfully so…
With a web server or desktop app, who cares what the compiler outputs - regardless, your app will run. But, in the browser, every byte counts. So if the browser has to download tons of needless code, your user loses and you lose too.
Based on TypeScript’s syntax, it’s not too hard to see why:
TypeScript, however, didn’t seem to be an improvement on either concept. In fact, TypeScript’s implementation seemed very Groovy-ish. It seemed history was again repeating itself.
I predict TypeScript adoption will be lack luster at best. Not because the language is tedious like Dart. No…
In fact, TypeScript is much more pleasing to read than Dart. That itself is a success for the TypeScript Team. TypeScript will fail because it doesn’t improve the development experience.
What a funny world we live in…
Listen, I don’t believe you help developers by giving them an illusion of type safety that doesn’t actually exist at runtime. What we do is serious business. No smoke. No mirrors.
Time and time again, the fact remains that an extra layer between you and the browser is simply - No good.
Claims of cross browser compatibility - solved years ago with jQuery.