Lambda the Ultimate

TileStack is an attempt to resurrect HyperCard and bring it to the web.

Running online there are going to be limitations about which stacks can be ported, which may reduce the usefulness and impact of this project, but maybe a standalone version will come later.

The system compiles Speak (the TileStack version of HyperTalk) to Javascript. If the result is not obfuscated, something I haven't verified, it may be possible to augment the output from TileStack with additional capabilities not supported or not yet implemented.

From the compatibility angle it is interesting to note that they renamed the language and seem to imply they are going to extend it beyond HyperTalk, without giving any specific guarantee about future compatibility. I'd suggest releasing the compiler that's as close to full HyperTalk compatibility as a separate product (or even, if they can bring themselves to do it, releasing it as open source).

John Resig (of jQuery fame) has ported the Processing visualization language to JavaScript.

The examples are remarkable, check them out (but check the browser issues John discusses).

John has a little confession:

The first portion of the project was writing a parser to dynamically convert code written in the Processing language, to JavaScript. This involves a lot of gnarly regular expressions chewing up the code, spitting it out in a format that the browser understands.

It works "fairly well" (in that it's able to handle anything that the processing.org web site throws at it) but I'm sure its total scope is limited (until a proper parser is involved). I felt bad about tackling this using regular expressions until I found out that the original Processing code base did it in the same manner (they now use a real parser, naturally).

Actually that's quite cool in itself (even if angels weep at this parsing code, I think we on LtU shouldn't cast the first stone). DSLs should be easily built and played with. Cleaning up the implementation comes later, if at all.

Purists may not only object to the regular expression parsing, but also to the central line of code which ties things together, namely: eval(parse(code, p)). But then, DSL lovers are not the sort of people to object to eval...

In the old days of LtU we regularly posted links to cool small interpreters that people could play with. Some of the more amusing ones were javascript based, and the page contained a REPL form (Luke, I am talking to you!). It is a shame we don't post more stuff like this, in between the more highbrow discussions...

Evolutionary Programming and Gradual Typing in ECMAScript 4, by Lars T Hansen, Adobe Systems, is an 18 page tutorial detailing features of ECMAScript 4, and how they can be applied to existing ECMAScript code to improve it.

This tutorial uses a simple library as a running example to illustrate the evolution of a program from the ES3 "script" stage, via various levels of typing and rigor, to an ES4 package with greater guarantees of integrity and better performance potential than the original code. We then look at how union types, generic functions, and reflection can be used to work with a library whose code we can't modify.

The video and slides of David Pollak's BayFP presentation on lift are available online.

While the thrust of the talk is on lift as a web framework, you get a very nice intro to Scala along the way, and David even mentions a quick way to get a PLT PhD, for those interested in that sort of thing...

Ben Laurie:

I’ve been running a team at Google for a while now, implementing capabilities in Javascript....a Caja program will run without modification on a standard Javascript interpreter - though it won’t be secure, of course! When it is compiled then, like CaPerl, the result is standard Javascript that enforces capability security. What does this mean? It means that Web apps can embed untrusted third party code without concern that it might compromise either the application’s or the user’s security...I’m very excited about this project and the involvement of some world class capability experts, including Mark Miller (of E fame) who is a full-time member of the Caja development team.

This could possibly be a very important development. I haven't delved into Caja, but I know some members know all there is to know, so perhaps they can enlighten us about the details...

There's a new document on the incompatibilities between ECMAScript Edition 3 and the proposed Edition 4. Given the recent controversy in the blogosphere and the degree of interest in last week's discussion of the proposed ES4, this document may be of interest to LtUers.

It's also interesting to think of conservative extension not as an all-or-nothing property, but to judge incompatibilities in terms of their impact. This document attempts to enumerate and classify the different ways the proposed ES4 spec conflicts with the specification of ES3.

(One last note: there's a new pre-release of the reference implementation available, with binaries for all major platforms. Check it out!)

Phil Windley Technometria podcast is dedicated to the Google Web Toolkit. The guest on the show is Bruce Johnson a Tech Lead of GWT.

The show is very good, and more technical than usual. Many themes that are near and dear to LtU are discussed. Here are some pointers:

Bruce talks at length about the advantages of compiling from Java to JS, many of which arise from Java's static typing. He mainly talks about optimizations, but also about how static typing helps with tools in general (IDEs etc.). This was a subject of long and stormy debates here in the past.

The advantages, from a software engineering standpoint, of building in Java vs. JS are discussed. This is directly related to the ongoing discusison here on the new programming-in-the-large features added to JS2. I wonder if someone will write a compiler from Java/GWT to JS2 at some point, which will enable projects to move to JS2 and jump ship on Java all together.

Bruce mentions that since JS isn't class-based, and thus doesn't directly support the OO style many people are used to, there are many ways of translating common OO idioms into JS. This is, of course, the same type of dilemma the Scheme community has about many high level features. Cast as a question on OOP support the questions becomes is it better to provide language constructs that allow various libraries to add OO support in different ways, or to provide language support for a specific style. The same can be asked about a variety of features and programming styles, of course.

Finally, Bruce mentions that as far as he knows no one thought about something like GWT before they did. Well, I for one, and I don't think I was the only one, talked many times (probably on LtU) about Javascript as a VM/assembly language of the browser, clearly thinking about JS as a target language. I admint I wasn't thinking aobut compiling Java... But then, I am not into writing Java, so why would I think about Java as the source language...

An overview paper describing ECMAScript 4 has been added to the ECMAScript site. It was recently announced on the mailing list:

I'm pleased to present you with an overview paper describing ES4 as the language currently stands. TG1 is no longer accepting proposals, we're working on the ES4 reference implementation, and we're expecting the standard to be finished in October 2008.
...
This paper is not a spec, it is *just* a detailed overview. Some features may be cut, others may be changed, and numerous details remain to be worked out, but by and large this is what TG1 expects the language to look like. Your comments on the paper are very much welcome. Please send bug reports directly to me, everything else to the list.

Code Splitting for Network Bound Web 2.0 Applications. Benjamin Livshits, Chen Ding. August 2007.

Modern Web 2.0 applications such as Gmail, Live Maps, MySpace, Flickr and many others have become a common part of everyday life. These applications are network bound, meaning that their performance can and does vary a great deal based on network conditions. However, there has not been much systematic research on trying to optimize network usage of these applications to make them more responsive for end-user interactions. Interestingly enough, code itself, usually in the form of JavaScript that runs within the client browser, constitutes a significant fraction of what needs to be transferred to the client for the application to run. Therefore, one way to significantly improve the perceived client-side performance for a range ofWeb 2.0 applications is to perform judicious decomposition — or splitting — of code and only transfer the code that is necessary just before it is needed. In this paper we propose several code splitting algorithms and explore their effectiveness at improving the responsiveness of large sophisticated Web 2.0 sites.

Once upon a time there was a lot of research on mobile code. It seemed like it was going nowhere. Then came Javascript, AJAX and Web 2.0, and in a worse-is-better fashion Javascript became the mobile code platform of choice. Maybe now is a good time to resume research on the subject...

The first pre-release of the reference implementation of ECMAScript Edition 4 (a.k.a. JavaScript 2) is now available. We've created a new web site for information about the ECMAScript specification and reference implementation. You can download source and binary forms of the reference implementation.

As we've discussed before here on LtU, the reference implementation of ECMAScript is being written in Standard ML. This choice should have many benefits, including:

• to make the specification more precise than previous pseudocode conventions
• to give implementors an executable framework to test against
• to provide an opportunity to find bugs in the spec early
• to spark interest and spur feedback from the research and user communities
• to provide fodder for interesting program analyses to prove properties of the language (like various notions of type soundness)
• to use as a test-bed for interesting extensions to the language

This pre-release is just our first milestone, i.e., the first of many "early and often" releases. Neither the specification nor the reference implementation is complete, and this early implementation has plenty of bugs. We encourage anyone interested to browse the bug database and report additional bugs.

We're happy to hear your feedback, whether it's bug reports or comments here on LtU or on the es4-discuss mailing list.