Saturday, August 30, 2008

Syntactic Noise sample in C#

Martin Fowler wrote an interesting post on syntactic noise in internal DSLs.

I thought it would be interesting to compare the Java versions (there are two in his post) with a concise C# version. Here is the result, the most concise C# version that I could come up with:
static Event
    DoorClosed = "D1CL",
    DrawOpened = "D2OP",
    LightOn = "L1ON";

static Command
    LockPanel = "PNLK",
    UnlockDoor = "D1UL";

static State
    Idle = new State
    {

        UnlockDoor,
        LockPanel,
        DoorClosed.TransitionTo(Active)
    },
    Active = new State
    {
        DrawOpened.TransitionTo(WaitingForLight),
        LightOn.TransitionTo(WaitingForDraw)
    };


It's reasonably concise (slightly more so that the fluent Java one I think), however it did require me to make everything static - which kind of counts as cheating ;-) [Update 9 Sept:] So here is a more realistic version:

public Event
    
DoorClosed = "D1CL",
    
DrawOpened = "D2OP",
    
LightOn = "L1ON";

public Command
    
LockPanel = "PNLK",
    
UnlockDoor = "D1UL";

public State
    Idle,
    
Active;

protected void Setup()
{

    Idle = new State
    {

        UnlockDoor,
        LockPanel,
        DoorClosed.TransitionTo(Active)
    };
    
Active = new State
    {

        DrawOpened.TransitionTo(WaitingForLight),
        LightOn.TransitionTo(WaitingForDraw)
    
};
}



The key differences from the Java version are that it uses implicit conversions to convert strings directly to Events and Commands, and that it uses collection initializers to set up the contents of the States. (Note that a collection initializer need not contain things that are all of the same type. Instead, it will accept all types for which the target collection has an Add method. In our case, that is Commands and Transitions (created by TransitionTo)).

Full source code is attached.

PS as I've noted before, I think that C# offers more options for in-language DSL syntax than Java.

Tuesday, August 26, 2008

A Practical Step in the Stored Proc Debate

I've taken a practical step in the long-running debate for and against stored procs.

I've logged a formal suggestion with Microsoft asking them to correct their erroneous advice on the subject. :-)

This Patterns and Practices page says:
Stored procedures generally result in improved performance because the database can optimize the data access plan used by the procedure and cache it for subsequent reuse.

That's been factually incorrect for the last decade! In terms of query plan caching, Parameterized SQL and Stored Procs are handled in the same way - and they have been since SQL Server 7.

So, if you too are disappointed by the level of erroneous information in this long running debate, head over to the feedback page and support my request to fix the P&P page. You can support it via commenting on the page or by using the Validation link at the top.

Let's hope we can get the page corrected, and achieve a small step for rationality in an often irrational debate :-)

(Apologies to Microsoft if my tone sounds hash. I know you've already got the correct information up on other parts of your site.)

Update Oct 08: the P&P guidance is being updated, so one presumes this will be fixed as part of that work.