Carpet-Bombing Marketing

Unless you spent the last 6 months deep in a cave, you must have heard buzz about the Microsoft Solver Foundation. It is much less likely however that you've heard about OptimJ. That's a major difference between being Microsoft or being Ateji.

In the pure Microsoft tradition, this vaporware has already generated far more downloads and excitation than OptimJ, an existing and proven product acclaimed by our users. Everybody in the OR community is pretending that they're not concerned or worried by the MSF announcement, but have anyway downloaded a large .msi archive "just in case". And the blogosphere is buzzing with wild guesses about what's really inside (do you know how to open an .msi archive ? most of them don't know either, but who cares).

Effects of carpet-bombing marketing are also visible in everything related to the forthcoming ICS'09 conference. I have yet to see any conference-related announcement without the "M" word. And almost all sponsorship opportunities are already bought and reserved by this single company. Maybe the Ateji team will end up on the side-walk distributing flyers from a makeshift cardboard tent (it may be cold in January, we'll exchange marketing material for warm soup).

So what's Ateji to do in this context ? We cannot afford a carpet-bombing marketing strategy, and vaporware announcements are not an option. Clients expect us to deliver first.

What we can do, however, is to leverage all this buzz-making to spread the word about what we've been promoting for long. The vaporware strategy is typically an attempt at delaying competitor's sales. Hairy-pointed bosses will prefer to wait until Microsoft actually delivers anything usable, and we'll lose those sales. But many others will have a chance to look at our product and download right now a fully functional version, so all in all we expect a big boost for Ateji. Time will tell.

But the best bit is about self-satisfaction. The fact that Microsoft is following a similar embedded-language approach applied to optimization reassures me that we choose the right approach when we founded Ateji three years ago.

Common Idioms 2

Associative arrays are one of the driving force behind the adoption of so-called scripting languages such as JavaScript or Ruby. Strangely enough, they're absent from the mainstream generalist languages of the C++/C#/Java family.

Associative arrays are like standard arrays but can be indexed with any given collection of values (whereas Java arrays can only be indexed with 0-based integers). Alternatively, associative arrays can be thought of as maps with built-in language support and a fixed an immutable set of keys (refering to a non-existent key raises an ArrayIndexOutOfBoundsException). Here is the OptimJ version of the canonical example from Wikipedia :

  String[String] phoneBook = {
    "Sally Smart" -> "555-9999",
    "John Doe" -> "555-1212",
    "J. Random Hacker" -> "553-1337"
  };

  // iterate over the values
  for(String number : phoneBook) {
    System.out.println(number);
  }

  // iterate over the keys
  for(String name : phoneBook.keys) {
    System.out.println(name + " -> " + phoneBook[name]);
  }

Notice the type String[String] that denotes an array of strings indexed by strings.

To see how associative arrays differ from Java arrays, consider the two definitions :

  String[] a1 = { "a", "b", "c" };
  String[int] a2 = { 12 -> "a", 3 -> "b", 7 -> "c" };

Here a1 is indexed by 0, 1, 2 and a2 is indexed by 3, 7, 12. Note how their types are different.

Java and associative array dimensions can be mixed freely:

  int[String][][double] a;

a is a 3-dimensional array. The first dimension is associative, indexed by doubles. The second dimension is a Java array dimension, indexed by 0-based integers. The third dimension is associative, indexed by strings.

As usual in Java, an array index expression is written with indices in the opposite order of the types:

  a[3.1416][10]["abc"]

Associative arrays are common in algebraic modeling languages such as AMPL, GAMS, OPL, etc., where they allow for a concise and mathematical-like expression of optimization problems.

Common Idioms 1

Most mainstream programming languages are pretty bad at initializating and populating structured data. Let's say you want a Java list containing "a" and "b".

First attempt :

List<String> a = new ArrayList<String>();
a.add("1");
a.add("2");

Pretty bad signal-to-noise ratio.

Second attempt :

List<String> a = Arrays.asList(new String[]{ "a", "b" });

Slightly more readable, but allocates a useless intermediate array.


Third attempt :

List<String> a = Arrays.asList("a", "b");

Much more readable, but doesn't work if you want a set rather than a list : there's no Arrays.asSet().

Here's the OptimJ version :

ArrayList<String> a = { "a", "b" };
HashSet<String> s = { "a", "b" };

But nausea quickly kicks in when you try to instanciate imbricated collection. A cooking recipe may be seen as a list (ordered) of sets of tasks (unordered because they can be done in parallel).

First attempt :

  List<Hashset<String>> irishStew = new ArrayList<Hashset <String>>();
  HashSet<String> set1 = new HashSet<String>();
  set1.add("Mince the meet");
  set1.add("Mash the potatoes");
  irishStew.add(set1);
  HashSet<String> set2 = new HashSet<String>();
  set2.add("Cook in oven");
  irishStew.add(set2);

Wow! This is called write-only code. Think about having to maintain pages of similar code written by an summer intern two years ago.

Second attempt :

... ?

The asList doesn't work because it requires expressions, and the code that builds our sets is a sequence of statements, not an expression.

Here's the OptimJ version :

  ArrayList<HashSet<String>> irishStew = {
    { "Mince the meet", "Mash the potatoes" },
    { "Cook in oven"}
  };

Do you feel more confident now taking this code maintenance assignment ?

Ateji supports the Roadef challenge

Every two years, the French Operational Research and Decision Support Society (ROADEF) organizes an OR challenge dedicated to industrial applications, in collaboration with an industrial partner. This year, the challenge is proposed by Amadeus and deals with disruption management for commercial aviation. It is open to everyone and provides a fantastic opportunity to match theory and practice: do not miss this chance to demonstrate your talent.

Ateji provides OptimJ licences for the duration of the challenge to all participants (contact us if you need one), and will offer a commercial full-featured OptimJ licence to the winner.

This year's topic is challenging in both data modeling and optimization modeling. Since OptimJ seamlessly integrates both aspects, it can save you a large amount of boring coding time that you'll be able to spend instead on creative thinking. Good luck!

Top 10 reasons to invest in a french technology venture

1. Whenever you feel like spending a romantic week-end in Paris, pretend to have an urgent board meeting.
2. Paris is home to a large number of brilliant universities and grandes ecoles, with no shortage of talented people coming from all over Europe.
3. French VCs are a following trend, they'll courteously let you pick the nicest jewels first.
4. The french still learn engineering at school.
5. Public policy is strongly favoring entrepreneurship and foreign investment (see www.invest-in-france.org)
6. You will find here truly original projects with a sound industrial vision, not just the 10,001th copycat startup.
7. It wouldn't hurt to have a few assets in euros in your portfolio.
8. We're too far away ? Have you ever used Skype ?
9. Despite rumours to the contrary, the term "entrepreneur" is a loanword from French (en.wikipedia.org/wiki/Entrepreneur)
10. There is life outside the Valley. Have a look.

So what's a closure exactly ?

Should I follow the blogosphere more closely, I would have noticed that Neal Gafter had just been developing this idea in the context of closures for Java.

The precautionary principle

Designing language extensions is not just black art, we are trying to follow a certain number of principles. One of them could be called 'the precautionary principle", or as Guy Steele put it "planning for growth". In short, do not add features if they may hamper future developments. When in doubt, stay on the safe side. When facing a choice, if no argument stands out clearly in favor of one side or the other, devise restrictions in order to avoid making a choice rather than take the risk of having to carry the consequences of a wrong choice all over the language life time.

One specific example comes to mind : the design of "closures" for Java, which is currently a heavily debated topic. If you haven't been brainwashed by programming teachers, "closures" are a very natural thing: wrap some piece of code so that you can carry it away exactly like you would do for data. "Closures" are also the basic building block of lambda-calculus, widely recognized as the theoretical basis of computation, and available for decades in functional programming languages.

With "closures", you can define methods or functions that take as parameters not only data, such as integers or strings, but also things to do, in other words pieces of code that will be executed when you evaluate the parameter. If you're familiar to C, this is similar to a pointer to a function (often used as callbacks), with the difference that you do not have to provide a name, and that the type system makes sure that you're not breaking things. Outside the Java world, "closures" are commonplace in functional languages such as Caml and scripting languages such as JavaScript. "closures" have also recently been added to C#. As the story goes, "closures" where even on the feature list of the first version of the Java language, and were dropped because of time-to-market considerations.


The most widely publicized proposal for "closures for Java" today is named BGGA by its authors' initials, and I strongly feel that this proposal is breaking the precautionary principle mentioned above. Let us try to remove the quotes around the word "closure". Theoreticians and functional programming languages talk about "functions" and "functional languages". A closure in this context is an instance of a function that remembers part of the context where it has been defined, for instance the value of some local variables. In some sense, this object is "closed", hence the name:  it has its own copy of the context it needs, and can be carried away as a black box.

The problem is when you try to add functions to an imperative language such as Java. Variables in functional languages have one and only one value, while variables in imperative languages have values that can change in time; they refer to a memory location rather than to a mathematical value ("final" variables in Java are somewhat close to functional variables). Should a closure remember values or memory locations ? Said otherwise, if some value is changed within the closure, should the change be propagated to the original context ?

The BGGA answer is yes. I can see two reasons for this choice. One is about the list of features that a magazine would use for a comparative review : because most scripting languages today do that, if Java would appear as lacking a feature. The other reason is that closures in the BGGA proposal are in effect suggested as an answer for two really different things : macros (designing your own control structures) and functions (carrying away pieces of code). The meaning of what is a context, where should "return" return to, and so on, are totally different for macros and functions. Not surprisingly, macros and functions are compiled in very different ways.

My answer is no. This is not about some subjective notion of language aesthetics, this is about the precautionary principle. Closures are not only about writing more concise code. Intuition and theory tell us for instance that closures are the basic building blocks of parallel programming (google for "pi-calculus"). You want to be able to express distributed computation as closures that are dispatched among different processors or computers. But this is just plain impossible if closures are able to modify arbitrary locations in their originating context.

To put it shortly, the BGGA proposal for closures will go in the way of future language extension for parallel programming, which is the next "big thing" (most PCs sold today have 2 or 4 cores, and PCs with 100's of cores are not far away). The trade-off is between making a nice marketing announcement today and growing a language that will be able to handle multicore processing tomorrow.

One reason for this misunderstanding is the ambiguous meaning of the word "closure", hence the quotes. As you have guessed, I strongly recommend to drop this term and use instead "function" and "macro".


See also my first comment on this topic on Neil Gafter's blog and a few references about closures in general.