Interesting thing 1: The Scala tutorial!
After reading Scalable Component Abstractions, by the Scala people, I got a little bit worried.
It seemed to me that Scala, the language I thought had everything I wanted, was in fact way too complicated. Well it may be too complicated, but after the Scala Tutorial that I attended last Monday, I have a new respect for the power of Scala, and believe that it is a great programming language right now. The absolute highlight of the Tutorial was seeing the guys program a Excel-style spreadsheet with real formulas and cell dependencies in 200 lines of code right there in the room! The ease of programming seemed to be due to a few things, but one was the fact that parsers can be programmed right there into the language using something called parser combinators. Neat. Also, they built a simple layer upon the Swing library which allowed them to program in a reactive style (similar to Erlang maybe) when responding to GUI events. It was dope. I also met and got to hang out with two members of the Scala team, Sean and Gilles. They both were really nice and seem to know what they're doing. Awesome, right?
Interesting thing 2: Alex Buckley, Lord of the Java Spec. I also met and spent a fair amount of time with Alex Buckley, the man who is now officially in charge of the Java specification.
We spent a fair amount of time talking about what he does (mainly answer question from the Eclipse people and other compiler writers clarifying the specification as well as handling the JSR process) and talking about potential extensions for Java (such as a quasi-ML-sort-of-like module system called "super packages." No functors though...). Even though he just finished his PhD, he was quite knowledgeable, especially on the theoretical stuff. I was left with the feeling that Java is in sane hands.
Interesting thing 3: Dan Grossman, and his work on transactional memory. I got to talk with him a bit, and he was extremely interesting. This is worth saying outside of any cut; if you have even a passing interest in transactional memory, you really ought to read Dan's essay, The Transactional Memory / Garbage Collection Analogy. Do it for me.
Interesting things: Other papers on my, to-read list:
Transactions with Isolation and Cooperation - If anything, this paper caused me to realize something about the semantics of the 'retry' statement that I never understood before. Normally using the 'atomic' statement allows us to use purely local reasoning. Unfortunately this isn't always the case, in particular with retry. Suppose you are trying to create a barrier, a point that all threads must reach before any can proceed. You might use code that looks like the following:
foo() {
atomic{ x++ };
atomic{ if( x < 10) retry; else ... }
}
Unfortunately, if a function that calls this function is already inside an atomic block, this code will no longer work, thus getting rid of our nice local reasoning. Boo.
Lost in Translation: Formalizing Extensions to C# - A nice, straightforward paper about using type theory (of all things!) to formalize the new features of C# 3.0, translating them to C# 2.0 where appropriate, and formalizing the old features where necessary.
foo() {
atomic{ x++ };
atomic{ if( x < 10) retry; else ... }
}
Unfortunately, if a function that calls this function is already inside an atomic block, this code will no longer work, thus getting rid of our nice local reasoning. Boo.
Lost in Translation: Formalizing Extensions to C# - A nice, straightforward paper about using type theory (of all things!) to formalize the new features of C# 3.0, translating them to C# 2.0 where appropriate, and formalizing the old features where necessary.
Okay, that's all. It was an interesting trip!
