RIP John McCarthy. Truly one of the greats in our field.
This is Dart:
var x = ‘foo’;
int s = x;
print(‘Shirley, you are joking’);
print(‘Surely this will be executed.’);
Note that I’ve declared s to be of type int and, just to make sure the point is clear, have assigned this int a value foo which, if there were runtime type semantics, would throw an exception (and, if there were mandatory typing, wouldn’t even compile). In Dart, the output of this is:
I should hope so.
This was the afternoon’s first major talk. David Ungar from IBM Research first demonstrated that the tragedy of Romeo & Juliet comes from a race condition (if only he had waited for news from the Friar).
That was excellent, but the real premise of his talk was that there is a fundamental tension between correctness and synchronization in manycore and the scalable solution (he asserts) is to eliminate synchronization. He proposed a few names for this type of programming model : anti-lock or “race and repair.”
This reminds me (and at least one questioner in the audience) of the application- or web-level concept of “eventually consistent.”
The bulk of the talk was a discussion of his experiments with a programming problem (a slightly-more-complicated version of hash table insert) with various techniques that trade off correctness with performance. What he showed (at least in this one experiment) was that he could get better performance from a “race and repair” technique than he could get from compare-and-swap.
He tentatively proposes that probabilistic data structures and algorithms, in which correctness is a spectrum that can be traded with performance, is a new field of study.
Perl users in our study performed notably poorly… no better than a language designed largely by chance.
They mean this literally, having used in their study a language called “Randomo”:
With the exception of braces, the lexical rule for variable names, and a few operators (e.g., addition, subtraction, multiplication, division), many of the keywords and symbols were chosen randomly from the ASCII table.
I think when people saw that Dart was from Gilad Bracha and Lars Bak there was an expectation that Dart was going to be a grand synthesis: a blazingly-fast NewSpeak-with-curly-brackets. It’s very much not such a language. It doesn’t seem, academically, vastly innovative because it doesn’t add much. But, in truth, optional types are a radical design decision in that they take away runtime aspects that a lot of mainstream programmers expect. (Of course, this raises the question of how to define the “mainstream”…)
Pros and Cons of Mandatory Typing In Descending Order of Importance (per Gilad Bracha):
- machine-checkable documentation
- types provide conceptual framework
- early error detection
- performance advantages
- expressiveness curtailed
- imposes workflow
Having said that, I attended a lecture in which someone, perhaps from Adobe, measured the performance impact of optional typing. Their conclusion, although admittedly done on the troublesome-ly small and artificial SunSpider benchmarks, was that the performance penalty of implicit types amounts to 40% (with a very large standard of deviation). That “feels” about right to me — definitely significant but not the overwhelming performance benefit you might get from either parallelization or an algorithmic change.
OOPSLA is attended by academics, who are typically less interested in the surface appearance of a program (they’ve seen just about variation) and more interested in semantic questions whose impact in the real-world might not be felt for many years. So Bracha begins his talk by disavowing the “interesting-ness” of Dart: it’s a language whose constraints are entirely mundane:
- Instantly familiar to mainstream prorgammer
(Personally, I take it as a damnation of the audience that “Of interest to 90% of the programming world” is not of importance, but the gracious interpretation is that these are the trail-blazers who are already deep in hostile territory.)
The gist of Bracha’s talk was on Dart’s “optional types” semantics. The great takeaway from this, I think, is that:
“Dart’s optional types are best thought of as a type assertion mechanism, not a static type system”
which allows for code that can make your blood run cold; what certainly looks like a statement of programmer intention (“this variable is of type Foo”) can be blithely trod over at runtime (“in fact, this variable is of type Bar”) without so much as a by-your-leave.
The type expression is only evaluated at compilation time and, if the developer puts the compiler in “development” mode, you get warnings and errors. But once out of development mode, there are no runtime semantics of the type expressions. They have no behavior, but on the other hand, they have no cost. And, argues Bracha, this seemingly extreme position is important to support a language that remains truly dynamic and does not “put you in a box” wherein the type system becomes a restriction on expressiveness.
One of the seemingly-obscure corners of language design are the semantics of generics (the building blocks of collection classes). Generics in Dart are reified and covariant, which to an academic means “the type system is unsound.” Bracha acknowledges this and says that he’s “given up” on fighting this battle.
Another interesting design element of Dart is its recognition that the “classic” object-oriented constructor is a failed abstraction that only allows for “I want to allocate a new instance…” instead of common scenarios such as “I want to get an object from cache,” “I want an object from a pool of a specific size (often 1),” etc. So you can declare something that looks an awfully lot like a classical constructor, but in fact is “allowed” to return whatever the heck it wants. (I put “allowed” in quotes because, remember, all this type stuff is just epiphenomenal <– mandatory big word every paragraph!)
The lack of mandatory types preclude the creation of type classes or C#-style extension methods. Those are grating, but really of concern to me is that their lack also precludes type-based initialization. This leads to the disturbing design that variables will have the value null until they are assigned to; a “disturbing design” that is standard in the mainstream but hated by all.
…off to lunch, more later…