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".