CodeStock is a community-organized software conference running in Knoxville TN, on June 26-27 2009. Registration is only $25 and includes lunch, t-shirt, and what looks to be a great session lineup. An interesting aspect is that registered attendees can vote for sessions they’d like to see… I’ve submitted a session abstract on the DLR (“The Dynamic Language Runtime: Why You Should Care”, under the Ruby/Python category) so if you’re planning to attend and have any interest in hearing more about a cornerstone of .NET 4, vote for me! All your wildest dreams will come true.  Really looking forward to CodeStock… see you there!
I gave a fun talk on integrating Oslo's MGrammar and the Dynamic Language Runtime to build your own high-performance, .NET-targeted DSL. Unfortunately in my time slot I was up against "ASP.NET MVC and World Domination" or something like that, so it was an intimate gathering for my talk... but what we lacked in sheer numbers we made up for in enthusiasm.  I'll elaborate further on some of the details in a future blog post... for now, here are the slides and code samples. slides code
Task.ContinueWith() [Parallel Extensions June 2008 CTP] ActivityExecutionStatus.Executing + WorkflowQueue.QueueItemAvailable [Windows Workflow] (Almost) the same thing. That is all.
My side project TextFlow is coming along nicely... I've still got a lot of work to do there, but it's surprisingly functional for something I've only been tinkering around with for a few weeks. TextFlow is (among other things) a language compiler that generates Windows Workflow programs from a text-based language syntax. Those familiar with WF will know that ordinarily you create WF programs from code, or using XAML. I like the idea of using a language syntax as yet another means to define workflows... some potential workflow authors will be comfortable neither with code or XAML; the graphical WF designer can help here, but even that requires either Visual Studio, SharePoint Designer (which has a crippled graphical workflow designer, and is SharePoint-specific to boot), or you need to host the WF designer in your own app. WF is a somewhat under-utilized and misunderstood technology, IMO. There are several reasons for this... confusion with Biztalk, lack of prescriptive guidance on implementing systems using WF, the fact that once you get beyond the graphical designer the sexiness factor goes way down (but that's precisely when a technology like WF starts to shine). It's plumbing, and plumbing isn't very sexy. Another difficulty with WF adoption is audience. WF is plumbing, and is ideally used to provide higher-order abstractions through which business users can express intent. But those business users can't express their intent without the abstractions in place; waiting for programmers to recognize this deficiency on their own and do something about it is mostly a non-starter. You get what we have today... most higher-order workflow logic is expressed as low-level control flow in languages like C# or Java. Enter TextFlow. TextFlow is (hopefully) one example of these higher-order abstractions. It's intended to be more approachable and business-user-friendly than writing .NET code (certainly) or interacting with the workflow designer (hopefully). It's also intended to be more powerful and general-purpose than the SharePoint Designer. As I've said, the key characteristic of TextFlow is that it compiles down to a WF program, instead of a "raw" CLR assembly. What this means is that, when a TextFlow program is compiled, the output is an in-memory .NET object graph that represents the logical sequence of actions described by the original syntax. This in-memory graph can be executed, serialized into XAML, or even displayed in the WF designer. So one obvious question is "why would you compile to WF, instead of the CLR itself?" Great question! Advantages of compiling to WF - WF allows you to work at a higher level of abstraction when writing your compiler. For example, control flow is built into WF via a set of pre-canned atomic elements (activities); if your language syntax has looping or branching constructs (as most will), its trivial to use WhileActivity or IfElseActivity (among others) to realize these. To do the same in MSIL is entirely possible, but arguably more difficult and tedious (though admittedly well documented). In effect, the WF "opcodes" (activities) more directly translate to procedural language constructs than do IL opcodes.
- The CLR is a huge leap forward for language designers and compiler writers because of the set of built-in services; garbage collection, a unified type system, a ubiquitous security model, etc. Platforms can leverage these services instead of writing them over and over again. The WF infrastructure leverages the basic CLR services, but also provides an array of services above and beyond the CLR that are powerful and easily leveraged from your own WF-targeting language:
- inherent support for transactions and compensation
- inherent support for long-running workflows, where periods of inactivity (waiting for human input, etc.) result in automatic serialization of the workflow to a persistent store
- the ability for workflow execution to load-balance across multiple machines, so that a single workflow instance might hop from machine to machine during its lifetime
- the ability to pause or cancel running workflows
- the ability to modify the inherent logic of a running workflow
- The extensibility model of WF is a big win for compiler writers, too. The atomic unit of execution in WF is an Activity; there are many pre-defined Activities shipped with WF, but it's trivial to create your own, too. In essence, if you're writing a compiler that targets WF, you can extend the set of opcodes that your compiler supports! Try that with MSIL! Another great thing about this is that the built-in activities have no special significance to the WF runtime; they don't leverage any "hidden" APIs that are unavailable to yours, etc.
Disadvantages of compiling to WF - WF doesn't offer much help if you want to expose a user-extensible type system from your language. As I mentioned above, you can certainly create your own custom Activity types and execute them in WF; but definition of your Activities is done via traditional subclassing of the .NET Activity class. WF has no magical CreateNewActivityType() method to help you here. So, WF is most appropriately targeted by procedural languages where the emphasis is on control flow and sequences of actions, as opposed to more pure OO-style languages (for the record, I think targeting WF with an OO language is possible... you've just got more typing ahead of you ).
- I hesitate to mention this, because most obsessing over software performance is misguided and misinformed... but it's true that WF will impose some performance tax on your code, relative to execution of equivalent logic directly against the CLR. I have no numbers to quote you (and wouldn't do it even if I did), but it stands to reason that since WF is in essence a virtual machine running on the CLR, there will be some performance penalty, even if small. That said... if you're launching the space shuttle or doing DirectX 3D graphics, you probably shouldn't be running on WF anyway. For true workflow-style programs that interact with external systems and (gasp!) actual users, whatever performance penalty may exist is totally dwarfed by the benefits provided by the platform. If your workflow program sends an email to a user and waits two weeks for a response before then proceeding with execution, who cares if the email was sent in 50ms or 5 seconds???
- One final thing to note... to truly take advantage of WF by compiling to it from your language, you'll obviously need a firm grasp of the semantics and underpinnings of the WF runtime and ancillary services. And since WF runs atop the CLR, you really need a similar grasp of the basic CLR services, too. So in all fairness, the barrier to entry isn't small; but neither is it insurmountable. In fact, I would venture to say that if you're capable of designing a language and writing a compiler, then grokking WF isn't going to seem like a big deal.
There's more to say, but that's a start. I highly recommend Essential Windows Workflow Foundation by Shukla and Schmidt as the definitive guide to WF and its underpinnings. And if you're intrigued by any of this, I invite you to take a closer look at TextFlow... let me know what you think!
Sad to see that Gary Gygax has died. Man, I gave many Sunday afternoons to D&D during my formative years... Casey, Chris, Zoob, Pete, Kessel, and me had some fun times. Then Pete got a girlfriend, and that was the beginning of the end.  I played a few different characters over the course of several campaigns... but my favorite has always been my first, Bandaar the dwarf fighter. Life was pretty simple for Bandaar... ale good, battle axe good, orcs bad. He wasn't much of a talker, and he certainly wasn't the shiniest gem in the pouch (8 for intelligence, around there for wisdom, IIRC)... but we had good times, me and him. Here's to you, Gary. Thanks for the memories.
My little side project is finally ready for others to poke around with: TextFlow - www.codeplex.com/TextFlow The main idea behind TextFlow is to allowing authoring of WF programs (workflows) via a language syntax, as opposed to (or, eventually, in addition to) using the drag-and-drop designer. The designer is great for many users, but there are times when a terse language syntax would be useful too. Here's a (mostly) simple Hello World in TextFlow syntax: SET x = 10 INPARALLEL START IF x > 100 THEN [HelloWorld] ENDIF END START IF x < 100 THEN [GoodbyeWorld] ENDIF END
ENDPARALLEL This is a slightly gratuitous example that executes a WF ParallelActivity with two IfElseActivity children; the square bracket syntax allows execution of configured external activities (in this case, ones that simply display messages of some sort). You get the idea. The actual generated workflow looks like this: 
The project includes an authoring tool that let's you toggle between syntax view and workflow view; workflow view is read-only at this point, but I hope to enable bi-directional updating eventually. The code is a definite work in progress... it's not much more than prototype quality at this point. So don't expect to launch the space shuttle with it anytime soon, but if you have an interest in any of the following, you might find something worth your trouble: - using ANTLR-generated lexers and parsers in C# (if you've only ever used lex and yacc, you need to see ANTLRWorks) - hosting the WF designer in a WinForms app (not sure my code should be reference material for this ) - a real-world use for .NET 3.5 expression trees (very cool stuff) I'll be blogging more on this in the coming weeks, as I continue to work on the code. For further details, visit www.codeplex.com/TextFlow. Feedback is welcome and appreciated!
Several days ago I mentioned that I'm working on an idea that combines ANTLR and Windows Workflow to demonstrate "business process authoring for analysts". In hindsight, that's a pretty bombastic thing to say. So instead, let's just say that the tool I'm working on could be used by semi-technical folk to author executable business processes. There are many other fine tools in this space; mine incorporates a few (IMHO) clever ideas, but I'm not breaking any monumental new ground. I'm getting closer to having something for public consumption... I'm trying to walk that line between making it solid enough for folks to actually use of it, without crossing every T and dotting every I. I'm very eager for feedback and input, but I want a minimal level of utility before it goes out the door. So if I've piqued your interest at all, stay tuned. Oh, and by the way... .NET 3.5 expression trees are FANTASTIC. Except that they don't serialize without writing your own surrogate. Bah.
In the interest of not scaring off employers of both the "current" and "potential future" variety, it's perhaps useful for me to follow up and clarify my comments originally made here. In general, I meant what I said... code reuse is usually more trouble than it's worth. Usually, you're better off not trying too hard to make it work, because you'll probably fail, and waste a lot of time. Even if you're smart, and certainly if you're not. I come by this point of view honestly... I've personally failed more often than not in trying to build "The One Reusable API to Rule Them All". I don't think it's a big secret that most others fail at this, too. I like to think I've gotten better as I've aged... but it's still a tough nut to crack. IMO, the characteristic most often desired in "software that shall be reusable" is FLEXIBILITY. Truly flexible code that is widely applicable across multiple disparate problem domains is a thing of beauty... and extremely rare. The fact that any such code exists isn't the telling point; the fact that it represents an infinitesimally small percentage of all code ever written is. Most "flexible" code I've personally witnessed was anything but. I've concluded that flexibility (and the goal of wide-scale reuse) is wildly overestimated as a desirable (and achievable) code characteristic for most classes of software. So I say all this to say, reusable software is hard. It has instant sex appeal for non-technical manager types (which makes it even more dangerous), which is probably one reason it perpetuates. And certainly, there exist many fine counter-examples in the wild (none of this really applies to SDK vendors, obviously). But I think the world would be a better place if we software types focused on building for today, and not For All Time To Come. Try it, and use your extra free time to read up on refactoring and test-driven development... there's your flexibility, cowboy.
I understand that "sorry it's been awhile since I posted on my blog" posts are considered bad form by the blogging elite... oh well. I started a new job last October, working here. Very interesting company, very interesting work (rules engine technology)... but they were quite eager to throw me immediately into the deep end of the pool, so I haven't had time for much of anything since I started. Just now starting to find some energy for endeavors beyond, like this blog. I've got an interesting new project idea percolating... I'll be posting more on that very soon. I also hope to have a CodePlex project up soon with some prototype code. As a teaser, think ANTLR + Windows Workflow = "business process authoring for analysts".
|