Highlights of the Lang.NET Symposium Day Two

---

No snow last night, which means we avoid a repeat of the Redmond-wide shutdown of
all facilities due to a half-inch of snow, and thus we avoid once again the scorn
of cities all across the US for our wimpiness in the face of fluffy cold white stuff.

Erik Meijer: It's obvious why Erik is doing his talk at 9AM, because
the man has far more energy than any human being has a right to have at this hour
of the morning. Think of your hyperactive five-year-old nephew. On Christmas morning.
And he's getting a G.I. Joe Super Bazooka With Real Bayonet Action(TM). Then you amp
him up on caffeine and sugar. And speed.

Start with Erik's natural energy, throw in his excitement about Volta, compound in
the fact that he's got the mic cranked up to 11 and I'm sitting in the front row and...
well, this talk would wake the dead.

Volta, for those who haven't seen it before,
is a MSIL->JavaScript transformation engine, among other things. In essence, he
wants to let .NET developers write code in their traditional control-eventhandler
model, then transform it automatically into a tier-split model when developers want
to deploy it to the Web. (Erik posted a description of it to LtU,
as well.) He's said a couple of times now that "Volta stretches the .NET platform
to cover the Cloud", and from one perspective this is true--Volta automatically "splits"
the code (in a manner I don't quite understand yet) to run Javascript in the browser
and some amount of server-side code that remains in .NET.

A couple of thoughts came to mind when I first saw this, and they still haven't gone
away:

• How do I control the round trips? If Volta is splitting the code, do I have control
  over what runs locally (on the server) and what runs remotely (in the browser)? The
  fact that Volta will help break things out from synchronous calls is nice, but I get
  much better perf and scale from avoiding the remote call entirely. [Erik answers this
  later, sort of: use of the RunAtOrigin attribute on a class defines that class to
  run on the server. He also addresses this again later in the section marked "End-to-End
  Profiling". Apparently you use a tool called "Rotunda" to profile where the tier split
  would be most effective.]

• How do I avoid the least-common denominator problem? Any time a library or language
  has tried to "cover up" the differences between the various UI models, it's left a
  bad taste in my mouth. Volta doesn't try to hide the markup, per se, but
  it's not hard to imagine a model where somebody says, "Well, if I write a control
  that I want to use in both WPF and HTML...."

• Is JavaScript really fast enough to handle the whole .NET library translated into
  JS? This is a general concern for both GWT and Volta--if I'm putting that much weight
  on top of the JS engine, will it collapse under several megs of JS code and who-knows-how-much
  data/objects inside of it?

Still, the idea of transforming MSIL into some other interesting useful form is a
cool idea, and one I hope gets more play in other ways, too.

Gilad Bracha: Gilad discusses Newspeak, a Smalltalk- and Self-influenced
language that, as John Rose puts it, "is one of the world's smallest languages while
still remaining powerful". It bases on message send and receive, a la Smalltalk, but
there's some immutability and some other ideas in there as well, on top of a pretty
small syntactic core (a la Lisp, I think). Most of the discussion is around Newspeak's
influences (Smalltalk, Self, Beta, and a little Scala, plus some Scheme and E), with
code examples drawn from a compiler framework. Most notably, Gilad shows how because
the language is based on message-sends, it becomes pretty trivial to build a parser
combinator that combines both scanning and actions by breaking lexing/scanning into
a base class and the actions into a derived class. Elegant.

Unfortunately, no implementation is available, though Gilad strongly suggests that
anybody who wants to see it should send him a letter on company letterhead so he can
show it to the corporate heads back at the office in order to get it out to the world
at large. I'm sufficiently intrigued that I'm going to send him one, personally.

Giles Thomas: Giles talks about Resolver One, his company's spreadsheet
product, which is built in IronPython and exposes it as the scripting language within
the spreadsheet, a la Excel's formula language and VBA combined. It's an interesting
talk from sveeral perspectives:

1. he's got 110,000 lines of code written in IronPython and hasn't found the need to
   go to C# yet (implying that, yes, dynamic languages can scale(1))

2. he's taking the position that spreadsheets are essentially programs, and therefore
   should be accessible in a variety of ways outside of the spreadsheet itself--as a
   back-end to a web service or website, for example

3. he's attended a conference in the UK on spreadsheets. Think about that for a moment:
   a conference... on spreadsheets. That sounds about as exciting as
   attending the IRS' Annual Tax Code Conference and Social.

4. he's effectively demonstrating
   the power of scripting languages exposed inside an application engine, in this
   case, the scripting language runs throughout the product/application. Frankly I personally
   think he'd be better off writing the UI core in C# or VB and using the IronPython
   as the calculation engine, but give credit where credit is due: it runs pretty damn
   fast, there was no crash ever, and it's fascinating watching him put regular .NET
   objects (like IronPython generators or lambdas) into the spreadsheet grid and use
   them from other cells. Nifty.

This is a really elegant design. I'm impressed. JVMers (thanks to JSR 233), CLRers
(thanks to DLR), take note: this is the way to build applications/systems with emergent
behavior.

Seo Sanghyeon: Seo had a few problems with his entirely gratuitous
demo for his context-free talk (although I could've sworn he said "content-free" talk,
but it was probably just a combination of his accent and my wax-filled ears). In essence,
he wants to produce new backends for the DLR, in order to reuse the existing DLR front-
and middle-ends and make lots of money (his words). I can get behind that. In fact,
he uses a quote from my yesterday's blog (the "DLR should produce assemblies out the
back end" one), which is both flattering and a little scary. ("Wait, that means people
are actually reading this thing?!?")

Jim Hugunin had an interesting theme threaded through his talk yesterday that I didn't
explicitly mention, and that was a mistake, because it's recurring over and over again
this week: "Sharing is good, but homogeneity is bad". I can completely agree
with this; sharing implies the free exchange of resources (such as assemblies and
type systems, in this case) and ideas (at the very least), but homogeneity--in this
case, the idea that there exists somewhere in space and time the One Language God
Intended--is something that just constrains our ability to get stuff done. Imagine
trying to access data out of a relational database using C++, for example.

Paul Vick: Paul's from the VB team [cue bad one-liner disparaging
VB here], and he's talking on "Bringing Scripting (Back) to Visual Basic", something
that I can definitely agree with.

Editor's Note: I don't know what Visual Basic did to anger the Gods of Computer
Science, but think about it for a second: they were a dynamic language that ran on
a bytecode-based platform, used dynamic typing and late name-based binding by default,
provided a "scripting glue" to existing applications (Office being the big one), focused
primarily on productivity, and followed a component model from almost the first release.
Then, after languishing for years as the skinny guy on the beach as the C++ developers
kicked sand on their blanket, they get the static-typing and early-binding religion,
just in time to be the skinny guy on the beach as the Ruby developers kick sand on
their blanket.

Oh, and to add insult to injury, the original code name for Visual Basic before
it got a marketing name? Ruby.

Whatever you did, VB, your punishment couldn't have fit the crime. Hopefully
your highly-publicized personal hell is almost over.

Paul points out that most VBers come to the language not by purchasing the VB tool
chain, but through VBA in Office, and demos VB inside of Excel to prove the point.
The cool thing is (and I don't know how he did this), he has a Scripting Window inside
of Excel 2007 and demos both VB and IronPython in an interactive mode, flipping
from one to the other. A couple of people have done this so far, and I'd love to know
if that's a core part of the DLR or something they just built themselves. (Note
to self: pick apart DLR code base in my copious spare time.) He does an architectural
overview of the VB compilation toolchain, which is nice if you're interested in how
to architect a modern IDE environment. The VB guys split things into Core services
(what you'd expect from a compiler), Project services (for managing assembly references
and such), and IDE services (Intellisense and so on). Note that the Project services
implementation is different (and simpler) for the command-line compiler, and obviously
the command-line compiler has no IDE services. Their goal for Visual Basic v.Next,
is to provide the complete range of Core/compiler, Project and even IDE services for
people who want to use VB as a scripting engine, and he demos a simple WinForms app
that hosts a single control that exposes the VB editor inside of it. Cool beans.

Serge Baranovsky: (Serge goes first because Karl Prosser has problems
hooking his laptop up to the projector.) Serge is a VB MVP and works for a tools company,
and he talks about doing some code analysis works. He runs a short demo that has an
error in it (he tries to serialize a VB class that has a public event, which as Rocky
Lhotka has pointed out prior to now, is a problem). The tool seems somewhat nice,
but I wish he'd talked more about the implementation of it rather than the various
patterns it spots. (The talk kinda feels like it was intended for a very different
audience than this one.) Probably the most interesting thing is that he runs the tool
over newTelligence's dasBlog codebase, and finds close to 4000 violations of Microsoft's
coding practices. While I won't hold that up as a general indictment of dasBlog, I
will say that I like static analysis tools precisely because they can find errors
or practice violations in an automated form, without requiring human intervention.
Compilers need to tap into this more, but until they do, these kinds of standalone
tools can hook into your build process and provide that kind of "always on" effect.

Karl Prosser: Karl's talking about PowerShell, but I'm worried as
he gets going that he's talking from a deck that's intended for an entirely difference
audience than this one. Hopefully I'm just being paranoid. As the talk progresses,
he's right down the middle: he's showing off some interesting aspects of PowerShell-the-language,
and has some interesting ideas about scripting languages in general (which obviously
includes the PowerShell language) in the console vs. in a GUI, but he also spends
too much time talking about the advantages of PowerShell-the-tool (and a little bit
about his product, which I don't mind--he's got a kick-ass PowerShell console window).
He also talks about some of the advantages of offering a console view instead of a
GUI view, which I already agree with, and how to create apps to be scripted, which
I also already agree with, so maybe I'm just grumpy at not hearing some more about
experiences with PowerShell-the-language and how it could be better or lessons learned
for other languages. He talks about the value of the REPL loop, which I think is probably
already a given with this crowd (even though it most definitely wouldn't be at just
about any other conference on the planet, with possible exception of OOPSLA).

One thing he says that I find worth contemplating more is that "Software is a 2-way
conversation, which is why I dislike waterfall so much." I think he's mixing metaphors
here--developing software may very well be a 2-way conversation which is why agile
methodologies have become so important, and using software may very well also be a
2-way conversation, but that has nothing to do with how the software was built. User
interaction with software is one of those areas that developers--agile or otherwise--commonly
don't think about much beyond "Does the user like it or not?" (and sometimes not even
that much, sadly). What makes this so much worse is that half the time, what the user
thinks they want is nowhere close to what they actually want, and the worst part about
it is you won't know it until they see the result and then weigh in with
the, "Oh, man, that's just not what I thought it would look like."

Which raises the question: how do you handle this? I would tend to say, "I really
don't think you'll like this when it's done", but then again I've been known to be
high-handed and arrogant at times, so maybe that's not the best tack to take. Thoughts?

Wez Furlong: Wez is talking about PHP, which he should know about,
because apparently he's a "Core Developer" (his quotes) of PHP. This promises to be
interesting, because PHP is one of those language-slash-web-frameworks that I've spent
near-zero time with. (If PHP were accessible outside of the web world, I'd be a lot
more interested in it; frankly, I don't know why it couldn't be used outside of the
web world, and maybe it already can, but I haven't spent any time studying it to know
for sure one way or another.) His question: "Wouldn't it be great if the web devs
could transfer their language knowledge to the client side--Silverlight?" Honestly,
I'm kind of tired of all these dynamic language discussions being framed in the context
of Silverlight, because it seems to pigeonhole the whole dynamic language thing as
"just a Silverlight thing". (Note to John Lam: do everything you can to get the
DLR out of Silverlight as a ship vehicle, because that only reinforces that notion,
IMHO.) Direct quote, and I love it: (slide) "PHP was designed to solve the specific
problem of making it easy for Rasmus to make his home page; Not a good example of
neat language design." (Wez) "It's a kind of mishmash of HTML, script, code, all thrown
together into a stinking pile of a language." He's going over the basics of PHP-the-language,
which (since I don't know anything about PHP) is quite interesting. PHP has a "resource"
type, which is a "magical handle for an arbitrary C structure type", for external
integration stuff.

He's been talking to Jim (Hugunin, I presume) about generics in PHP. Dude... generics...
in PHP? In a language with no type information and no first-class support
for classes and interfaces? That just seems like such a wrong path to consider....

Interesting--another tidbit I didn't know: PHP uses a JIT-compilation scheme to compile
into its own opcode and runs it in the Zend (sp?) engine. Yet another VM hiding in
plain sight. I have to admit, I am astounded at how many VMs and execution engines
I keep running into in various places.

Another direct quote, which I also love: (slide) "PHP 4: Confirmed as a drunken hack."
(Wez) "There's this rumor that one night in a bar, somebody said, Wouldn't it be cool
if there were objects in PHP, and the next day there was a patch..." If Wez is any
indication of the rest of the PHP community, I could learn to like this language,
if only for its self-deprecating sense of humor about itself.

He then mentions Phalanger, a CLR implementation of PHP, and hands the floor over
to Thomas for his Phalanger talk. Nice very high-level intro of PHP, and probably
entirely worthless if you already knew something about PHP... which I didn't, so I
liked it. :-)

Thomas Petricek; Peli de Halleux and Nikolai
Tillman; Jeffrey Sax:

(I left the room to get a soda, got roped into doing a quick Channel 9 video about
why the next five years will be about languages, then ran into Wez and we talked for
a bit about PHP's bytecode engine, then ran into with Jeffrey Snover, PM from the
PowerShell team, and we talked for a bit about PSH, hosting PSH, and some other things.
Since I don't have a lot of call for numeric computing, I didn't catch most of Jeffrey's
talk. I wish I'd caught the Phalanger talk, though. I'll have to collar Thomas in
the hallway tomorrow.)

(Just as a final postscript to this talk--John Rose of Sun is sitting next to
me during Jeff's talk, and he has more notes on this one talk than any other I've
seen. Combined with the cluster of CLR guys that swarmed Jeff as soon as he was done,
and I'll go out on a really short limb here and say that this was definitely one of
the ones you want to catch when the videos go online "in about a week", according
to one of the organizers.)

Stefan Wenig and Fabian Schmied: Oh, this was a fun talk.
Very humorous opening, particularly the (real) town's sign they show in the first
five or so slides. But their point is good, that enterprise software for various different
customers is not easy. They write all their code in C#, so they have to handle this.
They cite Jacobsen's "Aspect-Oriented Software Development with Use Cases" as an exemplar
of the problem, and go through a few scenarios that don't work to solve it: lots of
configuration or scripting, multiple inheritance, inheriting one from another, and
so on. (slide) "Inheritance is not enough." (To those of you not here--this is
a great slide deck and very well delivered. Even if you don't care about
C# or mixins, watch this talk if you give presentations.) Stefan sets up the
problem, and Fabian discusses their mixin implementation. (slide) "Mixin programming
is the McFlurry programming model." *grin* Mixins in their implementation can be configured
"either way": either the mixins can declare what classes they apply to, or the target
class can declare which mixins it implements. They create a derived class of your
class which implements the mixin interface and mixes in the mixin implementation,
then you create the generated derived class via a factory method.

I asked if this was a compile-time, or run-time solution; it's run-time, and they
generate code using Reflection.Emit once you call through their static factory (which
kicks the process off).

Their mixin implementation is available here.

---

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