Oct 27, 2017 - DLS 2017 Most Notable Paper Award for 2007


Each year the Dynamic Languages Symposium awards the DLS Most Notable Paper award to a paper published 10 years earlier in the symposium proceedings.

This year, our 2007 paper “Mirages: Behavioral Intercession in a Mirror-based Architecture” (link to paper) won the Most Notable Paper award.

The paper explored a new mechanism to virtualize objects in object-oriented programming languages (in particular, in the AmbientTalk programming language which I co-developed with my co-author Stijn Mostinckx as part of my PhD work). This work laid the foundation for my later work on the JavaScript Proxy API together with Mark S. Miller, which was standardized as part of ECMAScript 2015 and is now available in all major browsers.

The award citation reads:

The 2007 DLS paper “Mirages: Behavioral Intercession in a Mirror-based Architecture” combined the ideas of explicit mirrors for reflective introspection and modification with implicit mirrors for behavioral intercession. The work in this paper influenced and inspired the design of proxies in the JavaScript language, where it now has applications in areas such as security, testing, and virtualization of the DOM.

I’m honored to have received this award from the DLS community, which is one of the premier forums to discuss advances in dynamic languages.

Jun 26, 2017 - DEBS 2017 Best Demo Award


Our demonstrator “Building Connected Car Applications on top of the World-Wide Streams Platform” received the Best Demo Award at DEBS 2017, the ACM conference on distributed and event-based systems.

The demo showcases the capabilities of World-wide Streams, a wide-area distributed stream processing platform that I helped build at Nokia Bell Labs. The demo is a fleet management application for connected cars, processing the telemetry data and dashcam video streams emitted by cars in real-time.

WWS Demo

An extended abstract of the demo is available from the ACM digital library.

Dec 16, 2016 - 43 years of actors: a taxonomy of actor models


As part of his PhD thesis, my former PhD student Joeri De Koster has been deeply involved in actor languages and systems. Recently Joeri took the effort of transforming one of the chapters of his PhD thesis into a stand-alone paper that surveys different eminent actor systems and places them into a coherent taxonomy. He presented this work last month at the AGERE workshop at SPLASH, and to my surprise it actually got picked up by others quicky, for instance, by Tony Garnock-Jones, who wrote an excellent blog post on the history of actors, and by Phil Wadler in a recent paper.

The four big actor families mentioned in our paper:

  • Classic Actors: actors are seen as an identity tied to a single piece of state and a set of message handlers. A functional base language can act upon received messages and transform the actor’s entire state and message handlers. The Akka framework follows this model.
  • Processes: actors are seen as isolated threads of control that may explicitly suspend execution to receive a matching message. Erlang and Scala actors follow this model.
  • Active Objects: actors are seen as OOP objects with their own thread of control, by contrast with “passive” objects that are shared by-copy between actors. ASP, Salsa and Orleans follow this model.
  • Communicating Event Loops: actors are seen as heaps of regular objects, and objects in one actor can directly reference specific objects in other actors, even though asynchronous communication between those objects is enforced. E and my own AmbientTalk language follow this model.

The paper is officially published in the ACM digital library, but here’s a direct link to the author’s copy.

Nov 14, 2016 - Serving on OOPSLA 2017 PC


I was invited to serve on the OOPSLA 2017 PC. OOPSLA seeks outstanding contributions on all aspects of programming languages and software engineering. The deadline for this year’s research papers is April 17th, 2017.

Jan 4, 2016 - My ES6 development setup


I recently switched from TextMate to Atom, a lightweight cross-platform text editor and thought it would be useful to write down how to configure the editor and various related tools to be productive with ECMAScript 6. It also shows how to set up tooling for TypeScript, a typed dialect of JavaScript, which aligns well with ECMAScript 6 and gives you optional static type checking and type inference. IMHO, if you’re going to invest in new tooling for ECMAScript 6, going the extra mile to switch to TypeScript is worth it.

Getting started

Install Node.js v5 or higher (which comes with many ES6 features enabled by default).

Install the Atom text editor. Atom is a lightweight, easy-to-extend text editor with a large repository of plug-ins.

Atom has basic editor support for JavaScript out of the box (such as syntax highlighting).

Configure a JS linting tool

When you program in JavaScript, using a linter is a must. It will catch errors like undefined variables, unused variables, duplicate parameter names, forgotten semicolons, features of the language you would rather avoid, etc.

JSHint is my favorite linting tool for JavaScript. Other good options include JSLint and ESLint.

JSHint is highly configurable (look here for the list of configurable options). The easiest way to configure it is to set up a .jshintrc file in the root directory of your project. Here’s a good starting point for tweaking your .jshintrc file (comments in the config file are okay). To ensure JSHint doesn’t choke on new ES6 features, set the option “esnext” to true (or in the next major release, set “esversion” to 6). I would also recommend to set the option “node” to true, so that JSHint understands your code will run in node.js and functions such as require will be available.

There is a jshint atom package that will check your JavaScript files as you type, providing visible error highlighting like so:


To install the plug-in, in Atom, go to your Atom preferences > Packages > Install > search for “jshint”.

Enforcing strict mode

I always configure my JSHint file to require my JavaScript to be in “strict mode”. This is a safer subset of JavaScript with better-behaved scoping rules and less “silent errors” (e.g. operations that would silently fail without error will throw an error in strict mode). To enter strict mode, it suffices to add the literal string “use strict” as the first line in your JavaScript file (as shown on the screenshot above). In JSHint, I set the “strict” option to “global” (enforcing a single global “use strict” directive at the top of the file).

Configure typescript (optional)

TypeScript is a typed dialect of JavaScript. It allows you to add optional static type annotations on functions and variables. In addition, it has a good type inferencer that will catch type errors even when your code is mostly unannotated. Finally, it implements most ES6 features and even some ES7 features. For a good intro to TypeScript, see this book.

Configure typescript plug-in for Atom

Good editor support for TypeScript usually requires a commercial IDE like Visual Studio or WebStorm. Atom is one of the few open-source editors with very good TypeScript support, via the atom-typescript package. Install this just like you installed jshint above.


Configure typescript compiler

The atom-typescript package comes pre-bundled with a bleeding-edge TypeScript compiler. The compiler is configured using a configuration file called tsconfig.json which usually lives in the root of your project. An example file can be found here. If you don’t yet have a tsconfig file, the atom-typescript plug-in usually detects that the file does not exist and will offer to create it for you with default settings.

Two important properties in tsconfig.json to check are:

  1. set target to ‘es6’. This will let the TypeScript compiler generate ECMAScript 6 code, which is almost line-for-line the same as TypeScript code. This will only work if you run the subsequent compiled code on a recent version of node. If you develop for the browser, leave this set to ‘es5’. Keep in mind that some ES6 features are not yet enabled by default in node. So if you use them in your TypeScript, you must ensure to start node with the appropriate flags. For instance, I tend to use ‘destructuring’ a lot (allowing you to write things like let [a, b] = f(x)), which at the time of writing requires starting node with node --harmony_destructuring.
  2. set module to ‘commonjs’ so your TypeScript modules work just like node’s modules and npm packages. If you develop for the browser, it’s probably better to set it to ‘amd’ (for use with libraries like require.js).

Configure typescript linter

Just like JSHint lints your JavaScript, you can use TSLint to lint your TypeScript. Install the linter-tslint Atom package for built-in support.

Tslint reads its configuration from tslint.json. An example file can be found here. Details about the rules can be found here.

Set up type definitions for external libraries

Chances are that your JavaScript project is making use of existing JavaScript APIs, either in node.js or from external libraries. Many libraries are not written in TypeScript. Fortunately, TypeScript allows you to describe the types of an untyped API separately in a type definition file (*.d.ts). tsd is a tool to install and manage such type definition files.

To install:

npm install tsd -g

You will probably immediately want to install the type definitions for the node.js standard library. To do so:

tsd install node --save

This will do two things:

  1. download the node.d.ts type definition file to a directory called typings.
  2. create a file tsd.json remembering what version of the type definition file was installed.

(note: the command is tsd install <name> --save and not tsd install --save <name>, the latter will fail silently)

Using the tsd.json file it becomes easier to re-install the type definition files later. tsd.json acts similar to package.json and the typings directory is similar to the node_modules directory.

Normally your atom-typescript package will pick up the type declarations in the typings directory automatically, and any errors about e.g. the type of the node.js require function should go away.

Configure source maps

TypeScript code is compiled down to JavaScript code. When compiling to ES6, the source code and the compiled code will map almost one-to-one in many cases, but often the TypeScript compiler will insert some extra code. This causes the line numbers of the original code to diverge from the source code. This can become a problem when debugging: the stack traces and debugger will use JavaScript source lines, not TypeScript source lines.

Luckily there exists a translation format called “source maps” that allows JavaScript debuggers to work with external source code compiled down to JavaScript.

First, tell the TypeScript compiler to generate source maps. In your tsconfig.json file, add the following option:

{ "compilerOptions" : { ..., "sourceMap": true } }

Now, when you recompile a *.ts file (e.g. by editing and saving it), a *.js.map file will have been created as well.

When debugging code in the browser (e.g. using chrome developer tools), the presence of a source map file is enough for the debugger to use the correct line numbers. In node.js, you need to install a little utility library called source-map-support that will transform node.js stack traces so that source maps are taken into account:

npm install --save-dev source-map-support

To enable this library, start node (or a test runner like mocha) with the following command-line flag:

node --require source-map-support/register

Even better would be to edit your package.json to use a start script, so you can start your program using a simple npm start. Here is an excerpt from my package.json file:

"scripts": {
  "start": "node --harmony_destructuring --require source-map-support/register index.js",

Happy hacking.