Highlights of the Lang.NET Symposium, Day Three (from memory)

---

My Mac froze when I tried to hook it up to the projector in the afternoon to do
a 15-minute chat on Scala, thus losing the running blog entry in its entirety. Crap.
This is my attempt to piece this overview together from memory--accordingly, details
may suffer. Check the videos for verification when they come out. Of course, details
were never my long suit anyway, so you probably want to do that for all of these posts,
come to think of it...

I got to the conference about a half-hour late, owing to some personal errands
in the morning; as I got there, Wayne Kelly was talking about his work on the Ruby.NET
compiler.

Wayne Kelly: Parsing Ruby is made much harder by the fact that there
is no Ruby specification to work from, which means the parser can't easily be generated
from a parser generator. He tried, but couldn't get it to work cleanly and finally
gave up in favor of getting to the "fun stuff" of code generation. Fortunately, the
work he spent on the parser was generalized into the Gardens Point Parser Generator
tools, which are also used in other environments and are included (?) as part of the
Visual Studio SDK download. Good stuff. Ruby.NET uses a "wrapper" class around the
.NET type that contains a hash of all the symbols for that type, which permits them
to avoid even constructing (or even knowing!) the actual .NET type behind the scenes,
except in certain scenarios where they have to know ahead of time. Interesting trick--probably
could be used to great effect in a JSR-223 engine. (I know Rhino makes use of something
similar, though I don't think they defer construction of the Java object behind the
Rhino object.)

In general, I'm hearing this meme that "Ruby's lack of a specification is making X so
much harder". I hate to draw the parallel, but it's highly reminiscent of the state
of Perl until Perl 6, when Larry decided it was finally time to write a language specification
(and the language has languished ever since), but maybe it's time for Matz or another
Ruby digerati to sit down and write a formal specification for the Ruby language.
Or even just its grammar.

Luke Hoban: Luke is the PM on the F# team, which is a language that
I've recently been spending some quality time with, so I'm looking forward to this
talk and how he presents the language. (Note to self: steal slides... I mean leverage slides...
for my own future presentations on F#.) Not surprisingly, he makes pretty heavy
use of the F# Interactive window in Visual Studio, using a trick I hadn't known before
this: swipe some text in the editor, then press Alt-Enter, and it sends it to the
Interactive window for execution. Nifty.

Then he starts showing off F#'s fidelity to the underlying CLR, and just for effect
creates a DirectX surface and starts graphing functions on it. Then he starts playing
with the functions, while the graph is still up, which has the neat effect of changing
the function's graph in the DirectX surface without any explicit additional coding.
Then he tightens up the mesh of the graph, and adds animation. (Mind you, these are
all one-to-four lines of F# at a time he's pasting into the Interactive window.) What
gets even more fun is when he pastes in a page and a half more of F# code that introduces
balls rolling on the graphed surface. Very nifty. Makes Excel's graphing capabilities
just look silly by comparison, in terms of "approachability" by programmers.

I will say, though, that I think that the decision to use significant whitespace in
F# the same way Python does is a mistake. We don't have to go back to the semicolon
everywhere, but surely there has to be A Better Way than significant whitespace.

Harry Pierson: Harry works in MS IT, so he doesn't play with languages
on a regular basis, but he likes to explore, and recently has been exploring Parser
Expression Grammars, which purport to be an easier way to write parsers based on an
existing grammar. He shows off some code he wrote in F# by hand to do this (a port
of the original Haskell code from the PEG paper), then shows the version that Don
(Syme) sent back, which made use of active patterns in F#. (Check out Don's Expert
F# for details.)

Harry predicated this talk with his experience talking with the creators of Glassbox
(a C#-based tool that wanted to do something similar to what the C# mixins guys were
doing from yesterday), and when he heard how much pain they were going through taking
the Mono C# compiler and hacking it to introduce their extensions, he realized that
compilers needed to be more modular. I had an interesting thought on this today, which
I'll talk about below.

Magnus ???: Again, this was a lightning talk, a quick-hit lecture
on the tool that his company is building, and I can't tell if the name of the tool
was Intentional Software, or the name of the company was Intentional Software, or
both. It's a derivative of what Charles Simonyi was working on at Microsoft (Intentional
Programming), and basically they're creating programming language source trees in
various ways while preserving the contents of the tree. So, for example, he takes
some sample code (looked like C#, I don't think he said exactly what it was--assume
some random C-family language), and presto, the curly braces are now in K&R style
instead of where they belong (on new lines). Yawn. Then he presses another button,
and suddenly the mathematical expressions are using traditional math "one over x"
(with the horizontal line, a la MathML-described output) instead of "one slash x".
That got a few peoples' attention. As did the next button-press, which essentially
transformed whole equations in code into their mathematical equivalents. Then, he
promptly button-presses again, and now the if/else constructs that are part of the
equation are displayed inside the equation as "when"/"otherwise" clauses. Another
button press, and suddenly we have a Lisp-like expression tree of the same function.
Another button press, and we have a circuit diagram of the same function.

Wow. I'm floored. With this, completely non-programmer types can write/edit/test code,
with full fidelity back to the original textual source. And, in fact, he promptly
demonstrates that, with a table-driven representation of some business rules for a
Dutch bank. It's a frickin' spreadsheet we're looking at, yet underneath (as he shows
us once or twice), it's live and it's really code.

Combine this with some unit tests, and you have a real user-friendly programming
environment, one that makes Rails look amateurish by comparison.

Now, if this stuff actually ships.... but this talk leads me to some deeper insight
in conjunction with Harry's comments, which I'll go into below.

Wesner Moise: Wesner presents his product, NStatic, which is a static
analysis tool that scans .NET assemblies for violations and bugs, much in the same
way that FindBugs does in the Java space. It operates on binary assemblies (I think),
rather than on source files the way FxCop does (I think), and it has a very spiffy
GUI to help present the results. It also offers a sort of "live" view of your code,
but I can't be certain of how it works because despite the fact that he takes the
time to fire it up, he doesn't actually walk us through using it. (Wesner, if
you read this, this is a HUGE mistake. Your slides should be wrapped around a demo,
not the other way around. In fact, I'd suggest strongly ditching the slides altogether
and just bring up an assembly and display the results.)

As readers of this blog (column?) will know, I'm a big fan of static analysis tools
because I think they have the advantageous properties of being "always on" and, generally,
"extensible to include new checks". Compilers fall into the first category, but not
the second, in addition to being pretty weak in terms of the checks they do perform--given
the exposure we're getting to functional languages and type inferencing, this should
change pretty dramatically in the next five years. But in the meantime, I'm curious
to start experimenting with the AbsIL toolkit (from MS Research) and F# or a rules
engine (either a Prolog variant or something similar) to do some of my own tests against
assemblies.

Unfortunately, it's a commercial product, so I don't think source will be available
(in case you were wondering).

Chuck ...: Chuck stands up and does a quick-hit lecture on his programming
language, CORBA... er, sorry about that, flashback from a bad acid trip. I mean of
course, the language Cobra, which according
to his blog he was working on at the Lang.NET 2006 Symposium. It's a Python derivative
(ugh, more significant whitespace) with some interesting features, including a combination
of static and dynamic typing, contracts, a "squeaky-clean" syntax, first-class support
for unit tests (directly in the method definition!), and uses source-to-source "compilation",
in this case from Cobra to C#, rather than compilation directly to IL.

It's a fascinating little piece of work, and I'm planning on playing with it some.

Miguel de Icaza: Miguel is another one of those who has more energy
than any human being should have right to, and he spends the entire talk in fast-forward
mode, speaking at a rapid-fire pace. He talks first of all about some experiences
with Mono and the toolchain, then gets around to the history of Moonlight ("Can you
give us a demo in 3 weeks?") and their (Mono's/Novell's) plans to get Moonlight out
the door. They're already an impressive amount of the way there, but they have to
make use of a "no-release" codecs library that also (potentially) contains some copywrit
stuff, so they're instead going to incorporate Microsoft codecs, which they have rights
to thanks to the Microsoft/Novell agreement of n months ago.

The thought of all these Linux devs running Microsoft code in their browser as
they work with Moonlight just tickles my demented funny bone to no end.

He then switches tacks, and moves into gaming, because apparently a number of game
companies are approaching Novell about using Mono for their gaming scripting engine.
(Apparently it is being adopted by SecondLife, but the demo tanks because the SecondLife
servers aren't up, apparently. That, or the Microsoft firewall is doing its job.)
He jumps into some discussion about UnityScript, a {ECMA/Java}Script-like language
for a game engine (called Unity, I think) that Rodrigo (creator of Boo) was able to
build a parser for (in Boo) in 20 hours.

He then demonstrates the power of game engines and game editors by giving a short
demo of the level editor for the game. He modifies the Robot bad guys to shoot each
other instead of the player. If you're a game modder, this is old hat. If you're a
business programmer, this is wildly interesting, probably because now you have visions
of pasting your boss' face on the robots as you blast them.

Aaron Marten and Carl Brochu: I think his co-presenter's
name was Carl something, but memory fails me, sorry. These two are from the Visual
Studio Ecosystem team (which I think gets the prize for strangest product team
name, ever), and they're here to give an overview of the Visual Studio integration
API and tooling, with some sample code around how to plug into VS. This is good, because
not an hour or two before, during Chuck's Cobra talk, he was talking about wanting
to integrate into VS as a formal "next steps" for his language. Frankly, the whole
area of IDE integration Dark Art to most folks (ranking behind custom languages, but
still high up there), and the more the VSX team can do to dispel that myth, the more
we'll start to see interesting and useful plugins for VS a la what we see in the Eclipse
space. (Actually, let's hope the plugins we see for VS work more than a quarter of
the time--Eclipse has become the dumping ground for every programmer who had an idea
for a plugin, created a space on Sourceforge, wrote twenty lines of code, then got
stuck and went away, leaving a nifty idea statement and a plugin that crashes Eclipse
when you fire it up, not that I'm bitter or anything.)

The code demo they show off is a RegEx language colorization sample, nothing too terribly
useful but still a nice small example of how to do it in VS. As VS starts to put more
and more of a managed layer into place inside of VS, this sort of thing should become
easier and easier, and thus a lot more approachable to the Average Mortal.

Me: I did a 15-minute presentation on Scala, since the name had come
up a few times during the week, and promptly watched in horror as hooking my Mac up
to the overhead projector locked the Mac completely. Ugh. Hard reboot. Ugh. Shuffle
and dance about the history of Scala while waiting for the Mac to reboot and the VMWare
image in which I have Scala installed to reboot. Ugh. I have no prepared slides, so
I open up a random Scala example and start talking briefly about the syntax of a language
whose list of features alone is so long it would take all fifteen minutes just to
read aloud, much less try to explain. Cap it off with a leading question from Don
Box ("Is this Sun's attempt to catch up to the C# compiler, given that Java is 'done'
like the Patriots or the Dolphins?") that I try to answer as honestly and truthfully
as possible, and a second question from Don (again) that forcefully reminds me that
I'm out of time despite the "5 min" and "1 min" signs being held up by the guy next
to him ("What would you say, in the two minutes you have left to you, is the main
reason people should look at Scala?"), and I can safely say that I was thoroughly
disgusted with myself at presenting what had to be the crappiest talk a the conference.
*sigh*

That's it, no more presentations on technical topics, ever.

OK, not really, but a man can dream....

Don Box and Chris Andersen: I had to leave about
ten minutes into their talk, so I still have no idea what Don and he are working on
deep inside their incubating little cells in Microsoft. Something to do with "modeling
and languages", and something that seeks to bring data to the forefront instead of
code. *shrug* Not sure what to make of it, but I'm sure the video will make it more
clear.

Meanwhile...

Overall: Here are some thoughts I think I think:

• A blog is not a part of your presentation, and your presentation is not part of
  your blog. I find it frustrating when speakers say, in their presentation, "Oh,
  you can find Y on my blog" and don't go into any more detail about it. I
  don't want to have to go look up your blog after the talk, when the context of the
  question or situation is swapped out of memory, and I don't want to have to go look
  it up during your presentation and miss whatever follows in your talk. If you blogged
  it, you should be able to give me a 30-second summary about the blog entry or what
  not, enough to tell me whether or not I want the deeper details of what's on your
  blog. Exception: files that contain examples of a concept you're discussing or sample
  code or whatnot.

• Don't hook your Mac up to the projector when you have a VMWare session on an external
  USB disk running. This happened to me at Seattle Code Camp, too, with the same
  result: Mac lockup. Dunno what the deal is, but from now on, the rule is, connect
  thy Mac, then fire up thy suspended VMWare VM.

• Language design and implementation is a lot more approachable now than it was
  even five years ago. Don't assume, for even a second, that the only way to go
  building a "DSL" or "little language" is by way of Rake and Rails--it's still a fair
  amount of work to build a non-trivial language, but between parser combinators and
  toolkits like the DLR and Phoenix, I'd go head-to-head against a Ruby-based DSL development
  process any day of the week.

• Don't go in front of Don Box at a conference. Dude may like to go long on
  his own talks, but man, he watches the clock like a hawk when it's time for him to
  start. (I may sound like I'm angry at Don--I'm not--but I'm not going to resist a
  chance to poke at him, either. *grin*)

• Modular tool chains are the future. Actually, this is a longish idea, so
  I will defer that for a future post.

• This conference rocks. It's not the largest conference, you get zero swag,
  and the room is a touch crowded at times, but man, this little get-together has one
  of the highest signal-to-noise ratio of any get-together I've been to, and without
  a doubt, within the realm of languages and language design, this is where the Cool
  Kids like to hang out.

Bye for now, and thanks for listening....

---

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services.
1-day or multi-day workshops available. Contact
me for details.