Wednesday, June 29, 2005

Hooray for Atlas!

Whe I first started using ASP.NET I was intrigued by the concept of server controls. I thought, wow, we can lose all that client-side script that is so tricky to write and debug. It quickly became clear the model was flawed. You really, really can't abandon client-side technologies when you're creating web pages. The user experience is just too disjointed and sluggish. Sure, MS intriduced Smart Navigation, to try to reduce some of the issues intriduced by postbacks, but it was always just a sticking plaster over a deeper problem. To write a decent site, you had to pretty much abandon server controls, viewstate, and so on, and pull out your DHTML and JavaScript reference.

I was always really annoyed that MS completely ignored client-side scripting - there's just no real tool support.

I've already commented on AJAX on this blog. I'm really pleased to see that MS are planning a new suite of tools & techs - codenamed Atlas - built on ASP.NET 2.0, to support client-side web development. You can read about it on Scott Guthrie's blog.

Thursday, June 16, 2005

The Future of VB

I recently mentioned the outcry of VB.old devs at the prospect of moving to VB.net now that the mainstream product support for VB.old has expired. My basic point was that VB.net is better than vb.old, and I was finding it hard to understand why anyone would want to cling to a dying language and toolset.

Then I got to thinking a little more deeply about the issue...

VB was always meant to be a RAD language / toolset. The idea was that you could have folks with rudimentary IT skills create simple programs and automate tasks. For this reason, VB became extremely popular - it was trivial to create GUIs, compare with C++; you could do so much more in a fraction of the time. Gradually more and more people adopted VB, including seasoned developers. As a result, developers demanded more and more from the toolset, the most common cry was for OO, which was kind of delivered in VB5 (arguments raged over whether VB was an object oriented language or not - but let's face it, it wasn't).

So, VB had to serve two masters - the experts who liked the ease of use but wanted a "proper" programming language, and the less sophisticated developers, who just wanted to get the job done. Two kinds of applications were developed as a result - enterprise level apps, that frequently hit the limitations of VB, and small-scale apps that were frequently hard to maintain and extend.

With VB.net 1.x, a lot of the RAD was lost; suddenly there was a yawning gulf between what VB.old developers knew, and where they had to go in order to upgrade their skills. The language now supported OO, and this in itself was a tricky learning curve for those VB devs unused to the discipline. The .net Framework is vast, and there's a lot to learn. VB.net became a grown-up language, and so pleased half of the VB devs (although a lot of these migrated to C#) but left the other half of the user base cold.

So where does VB go from here?

A major problem preventing migration of VB.old to .net are all those VB legacy apps; the conversion wizard in .net 1.x wasn't good enough for most devs, in that it only converted some of your code, leaving large parts untouched for devs to code themselves. When you're new to the framework, this is a daunting proposition; for this reason, the usual recommendation is to re-write your apps in .net, rather than migrate. Perhaps the wizard is improved in version 2?

It seems MS are making concerted efforts to return RAD to the language with version 2, what with "Edit & Continue" restored, and the My classes wrapping up and simplifying large chunks of the .net framework; My seems to be attempting to make .net accessible to the less sophisticated programmers,& .net novices, and reduce the amount of code that needs to be written. This prevents VB devs having to learn the framework, and will shield them from complexity, but it will become a crutch - if you're using the My wrapper, then you won't learn how to code the underlying framework equivalents. Meanwhile, C# gets refactoring support, while VB.net doesn't...

There is a certainly a movement in the 2.0 release towards more hand-holding for VB, and access to more advanced tools for C# developers. I believe this is part of a trend that will continue with the next release. MS will continue to simplify VB.net, and so it will eventually return it to its state of being a novice's language; I'm not trying to denigrate VB or VB developers (I used to be one myself, back in the COM days), but I think eventually the language will dumb itself down to the point where most serious developers will move to C#. The target audience for VB.net will be beginners, students, and end users looking to automate work-flows.

Again, I've no wish to denigrate VB - when I used to develop with VB.old & VB.net, I was always exasperated by the "C++ / C# is better" argument, and thought it unfair that C# got features that VB.net didn't (operator overloading, which VB gets in 2.0, an allegedly more efficient MSIL compiler, etc). However, the point I am trying to make is that BASIC was originally designed as a beginner's language back in the 60s & VB followed this trend by bringing development to novices; the productivity VB brought was a mix of syntax and productivity tools in the IDE, which are now accessible to C# and C++ devs (the great debugger, the forms designer, etc). VB can't serve both pro and novice developers, and so something's got to give...

Tuesday, June 07, 2005

Visual Studio 2005, SQL Server 2005, BizTalk Server 2006 RTM: November 7 2005

More in the press release here.