Microsoft endorses JavaScript (except when they need to get work done)

This post from the JavaScript team at Microsoft endorses JavaScript evolution as the basis of the future web, and criticizes the “clean break” of Dart. It also reveals Script#, Microsoft’s equivalent to GWT, used to write “hundreds of thousands” of lines of code in their Office Web Applications. This is hypocrisy. They endorse JavaScript while finding it unusable for their own mission critical work. Many of the touted benefits of Script# are based on static typing, and will not be possible in future JavaScript till they add type guards (currently slotted for ES7 == JS.next.next). The ES committee is doing a valiant job of evolving the language (and has some really good ideas worth stealing), but it is going to take time. That fact and the unfortunate history of political dysfunction over JavaScript means we need to seriously consider alternative approaches like Dart.

Real world visual programming

I saw an interesting demo at SPLASH of an end-user visual programming language: Cloud Extend. There were two main interesting points. First, it is used to build plugins for Salesforce. Major web applications like Salesforce, and especially Facebook, are becoming software platforms unto themselves. This is a great target domain for end-user programming tools.

The second interesting thing was how radical they are in conceptually simplifying the language. For example, they tried eliminating variable binding, essentially using only global variables. That turned out not to work, so they brought back a limited form of binding. I really like that they are going at conceptual simplicity rather than the focus on syntactic simplicity that most end-user work seems stuck in. For example, rather than use standard nested if-then-else blocks like everyone else, they have imposed a global decision-tree structure on the program. Whether or not that works, it is the kind of radical simplification we need to make progress. I also like that they are working with real end users, and adjusting based on what works. This language is a valuable data-point on how simple we can make an end-user programming language, and has some fresh thinking. Worth following.

Devolving Subtext to JavaScript

I have to rewrite Subtext in JavaScript. First, a quick update. I presented my prototype implementation at the working group this summer, to a tepid response. But in the course of preparing for that I thought of a radical simplification to the language. That inspired a whole rampage of brutal simplifications. The code is so much happier now. And when the code is happy, I’m happy.

I have also been spending a lot of time thinking about my “market”. I have an idea for targeting web/mobile apps with a new twist. More anon. In other news, I am going back to calling the language Subtext. The name is apropos to my new direction, and it seems to be my brand. People ask me if I’m the “subtext guy”.

Now I need to run inside the browser. But rewriting my evolving Java implementation in JavaScript fills me with dread. People that do serious large-scale programming in JavaScript are often deeply troubled by it, and resort to tools like Google’s Closure and GWT that treat the language as a bug to be worked around. The fact that Google felt the need to make big investments in these tools is an indictment of the language that can not be easily dismissed. I have come up with the following three-step strategy:

Continue reading “Devolving Subtext to JavaScript”