I was hoping to blog my thoughts on Lang.NET as the event went along. Obviously, that didn’t happen, though I was pretty good about dumping links into my del.icio.us feed. The talks were all recorded, and should be up on the website in a week or two. Rather than provide a detailed summary of everything that happened, here are my highlights:

• The coolest thing about conferences like this is what John Rose called “N3″ aka “Nerd-to-Nerd Networking”. It was great to meet in person, drink with and geek out with folks who’s blogs I read like Tomas Petricek, Wesner Moise and Larry O’Brien. Plus, I got to meet a bunch of other cool folks like Gilad Bracha, Stefan Wenig and Wez Furlong. That’s worth the price of admission (which was admittedly nothing) right there.
• Coolest MSFT talk: Martin Maly “Targeting DLR”. I was wholly unaware that the DLR includes an entire compiler back end. Martin summarized the idea of DLR trees on his blog, but the short version is “you parse the language, DLR generates the code”. That’s pretty cool, and should dramatically lower the bar for language development. Of course, I want to write my parser in F#, so I’m going to port the DLR ToyScript sample to F#.
• Runner-up, Coolest MSFT talk: Erik Meijer “Democratizing the Cloud with Volta”. Erik is a great speaker and he really set the tone of his session with the comment “Division by zero is the goal, not an error”. He was referring to an idea from The Change Function that user’s measure of success is a function of perceived crisis divided by perceived pain of adoption. Erik wants to drive that adoption pain to zero. It’s a laudable goal, but I remain unconvinced on Volta.
• Coolest Non-MSFT talk: Gilad Bracha “Newspeak”. Newspeak is a new language from one of the co-authors of Java. It’s heavily smalltalk influenced, and runs on Squeak. He showed developing PEGs in Newspeak, and they were very compact and easy to read, easier even than F#. He calls them Executable grammar, and you can read his research paper or review his slides on the topic. Unfortunately, Newspeak isn’t generally available at this time.
• Runner-up, Coolest Non-MSFT talk: Miguel de Icaza “Moonlight and Mono”. The talk was kinda all-over-the-place, but It’s great to see how far Mono has come. Second Life just started beta testing a Mono-based script runner for their LSL language (apparently, Mono breaks many LSL scripts because it runs them so fast). He also showed off Unity, a 3D game development tool, also running on Mono.
• Resolver One is a product that bridges the gap between spreadsheets and applications, entirely written in IronPython (around 30,000 lines of app code and 110,000 lines of test code, all in IPy). Creating a spread-sheet based app development environment is one of those ideas that seems obvious in retrospect, at least to me. If you do any kind of complicated spreadsheet based analysis, you should check out their product.
• If you’re a PowerShell user, you should check out PowerShell+. It’s a free console environment designed for PowerShell and a damn sight better than CMD.exe. If you’re not a PowerShell user, what the heck is wrong with you?
• Other projects to take a deeper look at: C# Mixins and Cobra Language.
• I thought my talk went pretty well. It’s was a 15 minute version of my Practical Parsing in F# series. Several folks were surprised I’ve been coding F# for less than a year.

To prep for my Lang.NET talk, I went back and reviewed my PEG parser. One thing I was not happy with was that all the recursion was handled in a one-off manner. When I needed to match multiple characters in the comment rule, I wrote a special one-off function to recursively process the comment until it reached an EOL. When I needed to parse a series of ranges, characters or definitions, I wrote special one-off functions to handle that recursion. Obviously, that’s not the best approach. So, I wrote the following active pattern functions to handle recursion.

//ZOM == Zero Or More
let rec (|ZOM|) f input =
    match f input with
    | Some(i,input) ->
        let j,input = (|ZOM|) f input
        (i :: j, input)
    | None -> [], input

//OOM == One Or More
let (|OOM|_|) f input =
    match (|ZOM|) f input with
    | [], input -> None
    | v, input -> Some(v,input)

//ZOO == Zero Or One
let (|ZOO|) f input =
    match f input with
    | Some(i,input) -> Some(i), input
    | None -> None,input

With these functions at the ready, I can stop writing one-off recursion functions. Instead, I write a function that matches a single item, which I pass as an argument to one of the three functions above. For example, here is the original and new version of the top level Grammar function.

//Original version
let (|Grammar|_|) input =
    let rec ParseDefinitions dl input =
        match input with
        | Definition (d, input) -> ParseDefinitions (dl @ [d]) input
        | _ -> Some(dl, input)
    let (|OneOrMoreDefintions|_|) input =
        match input with
        | Definition (d, input) -> ParseDefinitions [d] input
        | _ -> None
    match input with
    | Spacing (OneOrMoreDefintions (dl, EndOfFile)) ->
          Some(List.to_array dl)
    | _ -> None

//New Version
let (|Grammar|_|) = function
    | Spacing (OOM (|Definition|_|) (dl, EndOfFile)) ->
          Some(List.to_array dl)
    | _ -> None

The new version is much shorter, because there’s already a function to match a single definition, which we can pass into OneOrMore (aka OOM). Note, when I pass an active pattern function as a parameter, I have to use it’s real name (with the pipes and parameters). Having to use the real name is pretty ugly, but F# need to be able to differentiate between using a function as an active pattern vs using it as a function parameter. If you could just call OOM Definition (dl, EndOfFile), would F# realize Definition is a parameter?

I also defined syntactic predicate functions. If you’ll recall, these syntactic predicates will try to match but automatically backtrack, returning success or failure depending on which function you called.

//FP == Failure Predicate
let (|FP|_|) f input =
    match f input with
    | Some(_) -> None
    | None -> Some(input)

//SP == Success Predicate
let (|SP|_|) f input =
    match f input with
    | Some(_) -> Some(input)
    | None -> None

To see this in action, here’s the original and updated Primary function. Only the first rule is relevant, so I’ve omitted the others.

//Original version
let (|Primary|_|) input =
    let (|NotLEFTARROW|_|) input =
        match input with
        | LEFTARROW (_) -> None
        | _ -> Some(input)
    match input with
    | Identifier (id, NotLEFTARROW (input)) ->
        Some(Primary.Identifier(id), input)
    //rest of function omitted for clarity

//new version
let (|Primary|_|) = function
    | Identifier (id, FP (|LEFTARROW|_|) (input)) ->
          Some(Primary.Identifier(id), input)
    //rest of function omitted for clarity

Instead of writing a special function to match “not left arrow”, I just pass the left arrow function as a parameter to Failure Predicate (aka FP). With these recursion and syntactic predicate functions, I was able to remove all the one-off recursion functions from my parser. (Note, I posted an updated version of PegParser on my SkyDrive so you can see this in action.)

These five functions significantly reduced the complexity of the code. Unfortunately, I’m not sure it’s much easier to read. The conciseness is offset IMO by the ugliness of using the active pattern’s true names. Also, I would have liked to use custom operators for these five functions, but operators aren’t allowed to be active pattern functions. Hopefully, that will change at some point in the future, though if we’re going to dream of better syntax, can we do something about all the parens? Personally, I’d love to be able to write the following:

//This doesn't work, but I can dream, can't I?
let (|Primary|_|) = function
    | Identifier (id) !!LEFTARROW (input) ->
        Some(Primary.Identifier(id), input)
    //rest of function omitted for clarity

let (|Grammar|_|) = function
    | Spacing ++Definition (dl) EndOfFile ->
        Some(List.to_array dl)
    | _ -> None

Note to self, talk to F# team members who come to LangNET about this…

• I only posted one Morning Coffee post last week. It wasn’t a lack of content, it was a lack of drive on my part. I had 20-30 items flagged in my news reader, but for some reason I couldn’t work up the interest in posting them. So some of these are a bit old.
• I’m at the Language.NET Symposium this week, so look for lots of language blogging. I’ve already chatted with Tomáš Petříček and John Lam. If someone kicks Ted Neward’s ass because he hates Perl, I’ll try and liveblog it.
• Speaking of Ted Neward, he discusses the question “Can Dynamic Languages Scale?” without devolving into a flame-fest. I agree 100% with his point about the difference between performance scaling and complexity scaling. Personally, I tend to err on the side of better complexity scaling, since buying hardware is easier than hiring developers.
• Nick Malik responds to me calling his shared global integration vision flawed. He points to NGOSS/eTOM as an example of a shared iterative model that works. I know squat about that shared model, so I’ll refrain from commenting until I do a little homework on the telco industry.
• Speaking of shared interop models, Microsoft is joining DataPortability.org. Dare Obasanjo and Marc Canter are skeptical that so far this effort is all hype and no substance. Reminds me a bit of AttentionTrust.org. But if DataPortability.org can get off the ground, maybe there’s hope for Nick’s vision (or vis-versa).
• Don Syme lists what’s new in the latest F# release. As I said, this release is pretty light on features. Hopefully, I’ll get some details
• Tomas Restrepo shows how to change your home folder in PowerShell. I need to do this.

Of all the things you might say about Nick Malik, “thinks small” is not one of them. He takes on a significant percentage of the .NET developer community over the definition of Mort. He wants to get IT out of the applications business. He invents his own architecture TLA: SDA (aka Solution Domain Architecture). He’s a man on a mission, no doubt. And for the most part, I’m with him 110% on his ideas.

However, when he starts going on about a shared global integration model, I start to wonder if he has both hands on the steering wheel, as it were.

Nick’s been talking about this for over a year. As he points out, SaaS integration layer is the new vendor lock-in. One of the attractions of SaaS is that you could – theoretically, anyway – switch SaaS application providers easily which would drive said SaaS companies to constantly innovate. However, if the integration layers aren’t compatible, the cost to switch goes up dramatically, leaving the customer locked-in to whatever SaaS company they initially bet on – even if that bet turns out to be bad.

OK, I’m with him so far. Not exactly breaking news here – we’ve seen the same integration issues inside the enterprise for decades. SaaS adds new wrinkles – if your ERP vendor goes belly-up, they can’t take your data with them or worse sell it to your competition – but otherwise it sounds like the same old story to me.

However, where Nick loses me is when he recommends this solution:

“To overcome this conflict, it is imperative that we begin, now, to embark on a new approach. We need a single canonical mechanism for all enterprise app modules to integrate with each other. If done correctly, each enterprise will be able to pick and choose modules from different vendors and the integration will be smooth and relatively painless.”

Yeah, and if a frog had wings, it wouldn’t bump its ass when it hopped.¹ There are so many things wrong with this approach, I’m not sure I can get them all into a single web post.

First off, it won’t, in fact, be done correctly – at least, not the first time. I realize everyone knocks MSFT for never getting an application right before version 3.0, but I believe it’s actually systemic to the industry. Whatever you think you know about the problem to be solved, it’s at best woefully incomplete and at worst wrong on all counts. So getting it right the first time is simply not possible. Getting it right the second time is very unlikely. It isn’t until the third time that you really start to get a handle on the problem you’re really trying to solve. Getting an effort like this off the ground in the first place would be a Herculean task. Keeping it together thru a couple of bad spec revisions would be impossible.

Meanwhile, the vendors aren’t going to be waiting around twiddling their thumbs waiting for the specs to be done. We’ve seen efforts to unify multiple completing vendors around a single interoperable specification. By and large, those efforts (UNIX, CORBA, Java) have been failures. The technologies themselves haven’t been failures, but the idea that there was going to be “relatively painless” portability or interoperability among different vendors never really materialized. If it didn’t work for UNIX, CORBA or Java, what makes Nick think it will work for the significantly more complex concept of a shared global integration model? Not only more complex in terms of spec density, but the mind-boggling number of vendors in this space.

Nick is worried that either “we do this as a community or one vendor will do it and force it on the rest of us.” But if you look at how specifications evolve, retroactive realization of defacto standards is the way the best standards get created. For example, I could argue that TCP was forced on us by the US Military, but I don’t hear anyone complaining. I realize there’s a big difference between having a vendor force a spec down our throat vs. a single big customer, but either way it’s not designed by committee. Besides, if we do see get an enterprise integration standard forced on us, I don’t believe it will be the vendors doing the forcing. If I were a betting man, I’d bet on Wal-Mart. Business leverage trumps IT leverage and Wal-Mart has more business leverage than anyone in this space these days.

BTW, would design-by-committee be an extreme example of BDUF? Do we really want to develop a this critical integration model using the same process that produced the XSD spec?

Finally, Nick thinks that this model will improve innovation, where I think it will have the exact opposite effect. Once you lay a standard in place, the way you innovate is to build proprietary extensions on top of that standard. However, by definition, these extensions aren’t going to be interoperable. If someone has a good idea, others will copy it and eventually it will become a defacto standard.

A recent example of the process of defacto standardization is XMLHttpRequest. Microsoft created it in 1999 for IE 5, Mozilla copied it for their browser a couple of years later, followed by the other major browser vendors. Google innovated with it, Jesse James Garrett coined the term AJAX, everyone else started doing it and then finally – nearly a decade later and still counting – a standards body is getting around to putting their stamp of approval on it.

However, if you’re worried about painless integration and not having something forced on you by some vendor, then you’re not going to embrace these innovations – which means, you won’t embrace any innovation. Well, there may be some innovation in the systems themselves that doesn’t affect the interface, but once that interface is cast in stone, the amount of innovation will go way down. How do vendors differentiate themselves? There’s only two ways: price and innovation. Take away innovation with standardization, and you’re left with a race to the rock bottom price with no incentive to actually improve the products.

I get where Nick is going with this. He looks around our enterprise and sees duplication of effort and massive resources being spent on hooking shit together. It sure would be nice to spend those resources on something more useful to the bottom line. But standardizing – or worse legislating – the problem out of existence isn’t going to work. What will? IMO, applying Nick’s ideas of Free Code to interop code. If we’re going to get IT out of the app business, can’t we get out of the integration business at the same time?

NHL.com Game Summary NHL.com Game Recap

It wasn’t a pretty win, but I’ll take the two points just all the same. Especially given the long history Washington has of losing to the Penguins – they had lost the past six meetings before tonight. Japers’ roundup mirrors my own thoughts, though On Frozen Blog’s roundup was funnier – they made a drinking game out of the number of times the on-air announcers referenced Sid the Kid. Certainly, there’s no love lost for Crosby among Caps fans, but the amount of on-air time spent discussing an injured player bordered on ridiculous – Sid the Kid was mentioned 27 times by OFB’s count + five in the post game. Worst was probably Malkin’s first goal – he hadn’t even stopped celebrating and the announcer was already talking about Crosby.

Caps were pretty dreadful on special teams tonight. Pens had three goals on eight penalties while the Caps had only went one for six. However, the penalty kill came thru in overtime overtime with the Caps down 5-3 for 1:07. The Caps won both defensive zone face offs and blocked four shots – Quintin Laing had three of those blocks – and kept the Pens from registering a shot on goal for the entire power play. That was money. If they gave out game stars to unsung heroes, Laing would have gotten one.

For all the great young talent on the Caps, there’s got to be real concern about goaltending. I love Olie the Goalie, but he didn’t get it done tonight. The Penguins had a grand total of 15 shots (14 if you don’t count the one from beyond the blue line with one second left in overtime). 5 goals on 15 shots == a pretty crappy save percentage. Malkin’s first goal was very impressive skating, but he didn’t so much shoot as throw the puck at the net. And letting Talbot’s  open the scoring by stuffing the puck in at the post was weak sauce as it were. I’m not so much worried about it for this season, but with Kolzig talking retirement as his struggles, I’m not sure who the Caps have in the pipeline between the pipes.

It sure was fun getting to watch an entire Caps game in its entirety with my family. Patrick and Riley watched most of it. Patrick wanted to know who the bad guys were – he figured it out after I pointed out the Penguins were wearing black…like Darth Vader. 😄 Julie wanted to know how I’d handle it if Patrick grew up to be a professional hockey player, but was drafted by Pittsburgh. My love for Paddy Boy far exceeds my hatred for the Penguins, though that’s the only scenario I could imagine rooting for the Penguins. My boy Patrick, however, protested and said he wanted be a Capital and play with Alex the Great. Patrick will be 18 by the time Ovechkin’s contract is over. It could happen. Guess I gotta teach him to skate!