David Findley's Blog

Here's a quote that sums up my feelings on the C# vs. VB.NET wars.

Looks like a new DNUG is opening up in Plano.

http://weblogs.asp.net/SHenderson/archive/2004/02/26/80863.aspx

I need to keep my eye on this and start attending.

X Omega (a.k.a X# or XEN) will be made available this year!

Looks like MS is moving forward with the new .NET language XEN err... X Omega as they are now going to call it. The details I've read about X Omega thus far look very promising. I can't wait to get my hands on it to play with it for real. Here's some links to more info:

http://www.microsoft-watch.com/article2/0,4248,1529588,00.asp

Programming with Circles, Triangles and Rectangles

Unifying Tables, Objects and Documents

Erik Meijer's Blog

Top ten web application security holes for 2004

Some details about XEN

There may be other places on the net that have some of the XEN details but the folowing article is the first place I've ran into thus far that gives some examples of what the syntax may look like.

Some interesting hilights:

foreach (OrdersRow row in (select * from orders where Total > threshold))
{
    …
}

and

int position = 0;
foreach (Item c in ledger.child::*) { 
   if (c is Deposit || c is OpeningBalance) {
     balance += c.amount;
   } else {
     balance -= c.amount;
   }
   yield {balance};
}

notice the embeded xpath like syntax. Very interesting stuff.

http://www.osnews.com/story.php?news_id=6042

P.S. I just found this after googling for XEN.

A peek into the future of data binding...

I found this article on data binding in Longhorn while surfing around the MSDN site today.

 “You can bind a property of a user interface element to a property of any common language runtime (CLR) object, or to an attribute of an XML node.”

One word: cool! :)

Automating builds.

There is a really good article up on MSDN about automating your build process:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/tdlg_ch4.asp

It's not as fancy as MSBuild but it should work well until Whidbey ships.

Designer vs. Code Window a.k.a. VB.NET vs. C#

With Whidbey looming on the horizon, Microsoft keeps telling us about how VB.NET is advancing from the RAD/designer enhancements and C# is enhancing the code window. As more time goes by the more I’m convinced that this is not a good direction for MS tools.

I work in a shop that consists of both VB and C# developers. Those of us that came from a C++/Java/Javascript background have found C# more comfortable, while those with mainly VB experience prefer VB.NET. Quite honestly there is still quite a debate about which language is better. I tend to believe that the language syntax is irrelevant, especially when compared to many of the other development challenges that we face.

More and more I see VB.NET developers writing a lot of code in the code window that is much easier managed by an existing designer. This ranges from management of connection strings via the web.config/app.config, to the setup and configuration of SqlCommand objects. I find myself repeatedly espousing the virtues of the VS.NET designers. The thing that seems odd to me is that I do most of my coding in C# and I’m the designer evangelist. The VB guys keep telling me: “Oh I prefer to write the code myself”. This seems exactly backwards to the message I keep getting from MS. Whidbey is being marketed as further defining these language “personalities”. VB is an iterative RAD/visual experience where as C# is a code window experience. I find this to be false in practice.

In some cases I think it is purely a lack of understanding about what the designers can do for you. I don’t mean to give the impression that the designers solve 100% of your problems. I just truly believe they are very underutilized. I have honestly seen code that dynamically creates rows in an ASP.NET data grid with no calls to DataBind(). I’ve seen code that builds up html by concatenating strings, not with a string builder btw, and then updates the Text property of a label control.

I can’t say enough good things about the data binding architecture in ASP.NET. I find that by carefully organizing the code with data binding in mind, I can easily wire up an aspx/ascx with little more than a few calls to DataBind. However, I see a lot of VB.NET code that overloads OnDataBinding rather than a lot of <%# %> blocks in the ASPX page. Another data binding rarity is the use of a data binding  expression to define the data source such as: <asp:DataGrid datasource=’<%# dsCustomers %>’ runat=”server” />.

There have also been a few attempts at applying OO principles to ASPX pages by deriving new “basepage” types from Page. The code behind class for all the pages in the site then inherit from this base page. This technique works well for encapsulating some of the common functionality of the site but in some cases the developers have broken the designers. So far I seem alone in my attempts to ditch development paths that outright break the design time environment. This isn’t to say that you should never derive a new Page class. Rather, if you do create a new page class and the code you’re putting in it breaks the designer, you’re probably doing too much in the base page. This also leads other junior developers to believe that the designers are flawed and sacrifice your OO principles. I’ve dubbed this “Fighting the designers”.

Maybe I’m just a data binding/designer bigot. That being said I am completely jazzed about the idea of “code window” designers. C# and Whidbey seem to be moving towards the idea that you can have the IDE help you input and change the code faster. From the code window perspective the IDE should help me visualize, document and implement patterns much more rapidly than notepad. I think this makes sense for the development of the business logic component tier and that the visual designers make sense for the UI/Web Server tier.