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 == 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”

The Frontier of Touch

I have been looking at the various touch/tablet platforms. It seems to me that the JavaScript/HTML5 stuff is way out past the frontier of civilization. There is a saying that when armchair warriors meet they talk about strategy and tactics, but when generals meet they talk about logistics. Likewise when someone shows me a new programing language/platform I am not interested in syntax or semantics or architecture. Instead I care most about three things: first the API docs; second the rename refactoring; and third the debugger. The further you get from the civilized regions of programming the less developed these crucial logistics become. This is entirely a matter of personal preference. There are a lot of young gun-slinger programmers who relish operating out where law and civilization haven’t yet reached. I did too back when my Testosterone level was higher. But now I value more highly my time and effort, as they are depleting resources. Continue reading “The Frontier of Touch”

The Genius of Jobs

Steve Jobs’ biographer, Walter Isaacson, writes in the NY Times:

The ability to merge creativity with technology depends on one’s ability to be emotionally attuned to others. Mr. Jobs could be petulant and unkind in dealing with other people, which caused some to think he lacked basic emotional awareness. In fact, it was the opposite. He could size people up, understand their inner thoughts, cajole them, intimidate them, target their deepest vulnerabilities, and delight them at will. He knew, intuitively, how to create products that pleased, interfaces that were friendly, and marketing messages that were enticing.

He seems at first to be praising Jobs’ empathy, but ends up describing a psychopath. Only by not feeling the emotions of others can one learn to ruthlessly manipulate them. Ironically, the lack of empathy is actually a great enabler of creativity. Thinking differently threatens and upsets people. To be creative you need to not give a damn what anyone else thinks or feels.

Onward! 2012 program

I am program chair of Onward! 2012. What do you want to see?

Here is one thing I am thinking about. I understand that in the real sciences, conferences often accept papers based solely on an abstract. That wouldn’t work for Onward, or even most of CS. Perhaps we should instead use the opposite of an abstract: a “concrete”. That is, an example. A common problem with big-idea papers is the lack of examples, making them quite difficult to understand. Perhaps we ought to require authors to submit an example up front in lieu of an abstract. That procedure might be beneficial both for the authors and the reviewers.

A win for design

Programming is not just engineering — it is design. All my hopes and beliefs about programming boil down to that one assertion, which has become my main cause. The misunderstanding of programming as engineering has many pernicious effects, infecting our tools, technologies, and practices. Computer Science embodies this fallacy in its very name. Therefore I have banded together with some other programming language researchers and developers to form the IFIP Working Group 2.16 on Programming Language Design.
Continue reading “A win for design”

Delusions of Programming

It’s great to be coding again, after spending so long lost in thought and theory. This has been my longest break from programming since I started at 13. I now have a working virtual machine that supports the essential semantics of the language. The next step is a compiler. The good thing about having a long break from programming is that it made the experience of starting up again quite vivid. What was most vivid was the many ways I make programming needlessly harder for myself. Continue reading “Delusions of Programming”

What is Ruby&Rails’ secret of success?

The history of programming languages is depressing. Generally worse is better. Socio-economic factors dominate. But there seems to be one giant exception: Ruby & Rails. I haven’t studied them deeply, but they look like really good work that has succeeded on its merits. Ruby is a tastefully designed language with a coherent philosophy of making programming easy and fun. Rails righteously smites the bloated complexity of the Big Java web frameworks. Gotta love it. So how did it win? This undermines my entire cynical world view. Can anyone explain how it went down?

Update: note the obstacles. Ruby had dubious performance. It was developed in Japan, doc translation from Japanese was incomplete and laggy, the dev lists were largely in Japanese. Scripting languages were not considered suitable for large-scale applications. Ruby was not used for a lot of server-side programming. Rails took away many checklist features that people thought they needed. People had already built cool web frameworks in LISP and Smalltalk without anyone much caring. What fortuitous combination of factors allowed Ruby&Rails to succeed? How important was the DHH cult of personality? I’m guessing a lot.

Why numbering should start at one

Should collection/sequence/array indices start with zero or one? Most current languages choose zero. For flux, I am choosing one. This choice is orthogonal, meaning that I can easily change it if it turns out to be wrong. The reason to discuss such a trivial issue is that it is an example of how choices that made sense in the early days of programming need to be reexamined. It also frames some principles of language design: Abstract Datatypes, and Conservatism.
Continue reading “Why numbering should start at one”

Still Alive

Hey, long time. Having a snow day here, which is a good day to catch up. My son got sick this summer, which knocked me out of commission for a while, but I am back to work now. As promised last June, I have defined the formal semantics of a core language that captures the key ideas of side-effects in a tree-structured heap without sequential programming. I have formulated confluence and soundness theorems that seem plausible (though I haven’t tried to prove them). So I don’t think it will collapse under me like Coherence did. One of the next steps is to build a reasonably usable textual syntax that can be compiled into the core language. By reasonably usable, I mean usable for expressing small examples up to a hundred lines of code, which is the minimum I need to communicate the idea to others. The working title of the language is flux.
Continue reading “Still Alive”