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 right information up on other parts of your site. Here's hoping to see P&P updated too.)

Software Development Meme

I've been tagged by Andrew, in a software development meme that started way back here.

How old were you when you started programming?

I was exactly 13. My parents bought me my first computer for my 13th birthday. It was a second-hand Ohio Scientific Superboard II.

By the way, the Superboard shipped in 1978 as a single circuit board. It had keys mounted on the front and chips mounted on the back. That’s it. No case, no nothing – just one big circuit board with stuff on it. By the time it reached me a few years later, mine had been fitted into a hand-built wooden case, and its memory had been expanded to 16k. (I still have the machine. If anyone knows how to fix a Superboard II that won’t respond to the Break key after power-up, please contact me :-)

How did you get started in programming?

Before my SuperBoard, I’d only seen two other computers. I guess they must have made a big impression on me. I got Mum and Dad to buy me a book on programming in BASIC, and the purchase of the actual computer followed sometime after. I don’t recall how much nagging was involved ;-)

What was your first language?

The Superboard’s version of BASIC, which was apparently "Microsoft 6502 BASIC version 1.0 revision 3.2". In hindsight, I love the fact that it was simple enough for a 13 year-old to learn the whole language. If I recall correctly, there was IF .. THEN, but no ELSE; and GOTO but no GOSUB. Definitely a minimal language. It made me appreciate "real" languages when I finally got to use them.

What was the first real program you wrote?

It was a clone of the first computer program I’d ever seen – a game where you had to steer a tank through a minefield. My version had the randomly-generated minefield, and the tank that was stuck on full-throttle while you steered your way though, but it lacked the system-generated comments that poked fun at your crashes.

What languages have you used since you started programming?

I’ve done serious development in Pascal, Excel 4.0 Macro language, VBA, Ada, PowerBuilder, PL-SQL, Delphi and C#. I’ve dabbled in various others including C++, JavaScript and even VB.NET (although it makes my eyes hurt when I read it ;-)

What was your first professional programming gig?

I did a few small jobs in BASIC and Excel when I was a student, but my first really serious job was in PowerBuilder for an IT consultancy. PowerBuilder’s (in)famous DataWindow really was a fast way to get things done. It set the bar for productivity, and it's only now in 2008 that I feel like we've replicated that speed in .NET - thanks to a good ORM and our in-house framework. (And we get a proper domain model with layering, which we never had in PB!)

If you knew then what you know now, would you have started programming?

Yes.

If there is one thing you learned along the way that you would tell new developers, what would it be?

I might tell them that it’s not about technology, it’s really about people – but I don’t think they’d believe me.

So instead I’d tell them to read How to be a Programmer.

What’s the most fun you’ve ever had... programming?

I’ve particularly enjoyed my old Superboard; writing (most of) a compiler at university; doing some funky stuff with COM in Delphi; and releasing a couple of open source projects.

But the thing I look back on most fondly is a .NET project at Optimation. The highlight wasn’t the technology, which was interesting but not amazing; the highlight was the project as a whole. We had great collaboration with the customer, very much "one team" with great dialogue and innovation, and together we exceeded expectations instead of merely meeting requirements.

Over to you

Bevan
Eduard
and
Kirill

POCO LINQ Update

Here is my long-promised near-POCO solution for LINQ to SQL.

As planned, it is deliberately not 100% pure POCO, but it does implement these key goals:

1. Entity classes are simple enough to be hand-written (no need to generate them with SQL Metal or VS 2008)


2. Mapping is easy (no need to manually map every property via attributes or external XML)


3. Lazy-loading works


4. Bi-directional relationships work (update one end, and the other is synchronized automatically)

Another reason why architects should write code

Johanna Rothman explains why architects should write code. I completely agree.

Not only does hands-on involvement reduce risks on the project, it also reduces embarassment when talking to your kids ;-) Here's an actual conversation with my daughter:

What did you do today Dad?
I drew some diagrams. Do you know what a diagram is?
No
It's a picture that shows how something works. I drew some diagrams, then I talked with some people about them.
So you didn't do any work then?

Only 4 New Features in C# vNext?

I've always admired the effort that Microsoft put into the design of C#. It's difficult to find the right balance between power and flexibility, and on the whole I think they've done an excellent job.

At the same time, it's been great to see the language grow, particularly with the addition of LINQ. As Jon Skeet has written recently, C# today is noticably more complicated than it was at version 1.0. Personally, I don't think that's a bad thing. The C# community has grown up along with the langauage, learning the new features as they have been released.

I can see this process continuing for some time, with the language continuing to grow. So I was suprised to see this comment from Microsoft's Mads Torgersen, in response to some suggestions that I posted at Microsoft Connect:

"We have to do some harsh prioritization, both because of our implementation and testing resources, but also because we need to keep the number of new langauge features at a manageable level - depending on how you count, we are adding only four language features to C# this time around".

We more-or-less know that one will be some form of dynamic lookup. That just leaves three others. They might be big "killer" features (like generics and lambda expressions in previous versions) but there's still only three of them.

I don't know what to think. Should we be trilled that Microsoft are continuing their excellent track record of keeping the language simple, or should we be dissapointed that there will be so few improvements?

Summary of C# vNext Ideas in this Blog

Here's a summary of the ideas I've suggested in this blog, for future versions of C#:

• Fix the versioning issues with extension methods
• Consider "extension interfaces" to provide mixin-like behaviour
• Also, consider improving the resolving of extension methods
• Retain some means of serializing iterator state (even if the underlying iterator implementation is changed) (See comments here)
• Provide an infoof operator, or similar
• Better handling of @-quoted strings that contain double quotes
• Enhance automatic properties to retain their concise syntax but to offer greater flexibility to use programmer-defined code. Particularly helpful for automatic INotifyPropertyChanged implementation

Enhanced Automatic Properties

Recently there's been a lot of blog posts discussing things people would like to see in the next version of C#. Here's my addition to the wish-list:

"Automatic properties that let me supply a method body." It sounds like a contradiction in terms - but it doesn't have to be. Instead, it would be a compact syntax for defining properties that use standardised method bodies (where you define your own "standard" bodies).

Some places where it would be useful:

1. Cases where many properties follow a standard format.  For instance, all the properties generated by the LINQ designer could be single-line automatic properties.  (Much less verbose than the current approach).
   
2. ORM's and similar products that require properties to be written according to certain conventions.  (E.g. Mindscape LightSpeed)

How would it look?

Right now, we can write automatic properties like this:

public int Foo { get; set; }

My suggestion is that the words "get" and "set" could be replaced by the names of methods. For instance:

public int AdvancedFoo { GetValue; SetValue; }

Where the methods "GetValue" and "SetValue" are generic instance methods with these signatures:

/// <summary>
/// When passed the field, return the property value
/// </summary>
T GetValue<T>(ref T field)
{
    // ... your own code goes here...
}
       
/// <summary>
/// When passed the field, by ref, and the new property value, set the field
// </summary>
void SetValue<T>(ref T field, T value)
{
    //...your own code goes here...
}

Given the above property, "AdvancedFoo", the compiler would compile it as if I had written this:

public int AdvancedFoo
{
    get { return GetValue(ref _advancedFoo); }
    set { SetValue( ref _advancedFoo, value); }
}

private int _advancedFoo; // compiler-generated backing field

Just as in today's automatic properties, the compiler would generate the backing field for me. The difference is that it reads and writes that backing field via methods which I define.

This goes a long way towards giving the best of both worlds: the compact syntax of automatic properties, and the flexibility of my own code (plus standardisation - all me properties that are supposed to work the same way do work the same way, because they all use the same code).

Questions:

Why does the "GetValue" method take the field "by ref"? SetValue needs it by ref, but why GetValue? GetValue takes it by ref simply so that you can use this trick to find out which property is being read - just in case you need to know. This is something you are more likely to need to know when setting, e.g. to raise change notificiations, but maybe some people want to identify the property in GetValue too. Using the ref param makes that possible.

What type should the complier use for the backing field? Simply put, it should use whatever field type is implied by the field parameters of the "GetValue" and "SetValue" methods. E.g. an automatic property for a LINQ EntityRef might look like this:

T GetEntity(ref EntityRef<T> field) where T:class
{}

void SetEntity(ref EntityRef<T> field, T value) where T:class
{}

allowing me to write this:

public Customer Bar{ GetEntity; SetEntity; }

and have the compiler compile it as if I had written this:

public Customer Bar
{
    get { return GetEntity(ref _bar);}
    set { SetEntity(ref _bar, value);}
}
private EntitySet<Customer> _bar;

Note that the compiler is able to infer that the backing field should be EntitySet, not Customer, based on the signatures of Get/SetEntity.

(And how would Get/SetEntity actually work? That's a question for another day ;-) I do have some (working) prototype code...)

What do you think of this idea for enhanced automatic properties?

Update 2 March: posted on MS Connect here (in the comments)

Update 12 March: And here here as an MS Connect item in its own right.

Extension Methods - Feedback to Microsoft

If you've been following the disussions about extension methods in this blog, you might be interested to know that I've submitted the issue to Microsoft's feedback site. Jump over there and vote for it, if you'd like to see something done.