Strategy, or workaround? Seems more like a workaround than a strategy.

Here are my current thoughts on the gradual migration to .NET development tools at Fog Creek.

The status quo: Most of CityDesk is written in Visual Basic 6.0, with parts written in Visual C++ 6.0. Most of FogBUGZ is written in VBScript for ASP, with parts written in C++. Almost all of our internal tools and our web presense (Fog Shop, Discussions, etc) are written in VBScript for ASP.

Why bother moving to .NET at all? Simply put, it's because .NET appears so far to be one of the most brilliant and productive development environments ever created. ASP.NET really makes it incredibly easy to create useful web applications; over the last couple of days I've been creating some applications we use internally at incredible speed. All the grungy stuff that takes 75% of the time creating web applications with ASP (such as form validation and error reporting) becomes trivial. ASP.NET is as big a jump in productivity over ASP as Java is to C. Wow.

Hmm.. I also found this when using Pascal CGI programs in place of PHP scripts. PHP reads like C, and feels like a step backwards. Maybe the same with ASP? ASP feels like a step backwards from .Net?

C# has most of the good stuff from Java, with a few small improvements like automatic boxing. Although we have always done what we can to create reasonably object oriented code in ASP and VB6 in the past, switching to C# will be nice.

Most of the stuff from Pascal/Delphi/ObjectPascal and Java?

Finally, the class libraries that ship with .NET are great. The fact that everything, from data access to web development to GUI development, was redesigned means that

The components for Delphi are wonderful too, and the libraries and units for freepascal and lazarus too. People have been designing components and libraries for delphi and freepascal for years now.

there is incredible consistency from top to bottom. When you look at the old Win32 API's, it is simply amazing how many different ways there are to get a string back from a function call, for example. Every two years they changed their mind about what a good way is to do this. .NET has cleaned that all up. I love the fact that you can use an ASP.NET calendar widget, which generates HTML that selects a date on a monthly calendar, and be confident that the "date" class you get back from that thing

Nice wrappers.. more wrappers need to be written.. but the windows API is still being used everywhere, .Net can't live without it. So the question is: why couldn't wrappers have been written for VB to do that? Is VB not capable? What makes .Net have anything to do with it?

(System.DateTime, I believe) will be the exact same date class that the SQL Server classes expect. In the past you would not believe how much time we wasted doing things like reformatting dates for SQL statements, or converting COleDateTimes to someOtherKindOfDateTime. And finally -- a string data type that works everywhere! Just last week I was writing ATL code and messing around with BSTRs and OLECHARs and char*s and LPSTRs and what a mess that was. Good riddance.

OK, I admit it -- .NET violated the Never Rewrite From Scratch rule. Microsoft got away with it because they had two things. First, they had the world's best language designer, the man who was responsible for 90% of the productivity gains in software development in the last 20 years: Anders Hejlsberg, who gave us Turbo Pascal (thank you!), Delphi (thank you!), WFC (nice try!) and now .NET (smacked the ball outta the park).

I don't think he smacked the ball outta the park with .Net . I think that he smacked the ball outta the park with Delphi, but he wasn't working at microsoft at the time. .Net is reinventing many of the ideas of Delphi, which is nice for microsoft. It's nice for microsoft. That's all. I think he has made some big mistakes with .Net that he should have plenty of experience with all his Delphi years. Maybe he lost some touch.

Second, they put about a zillion engineers on it for about three years, during a period where much of their competition was more-or-less stalled. Remember, just because Microsoft can do something, doesn't mean you can. Microsoft makes their own gravity. Normal rules don't apply to them.

A few dozen people will now proceed to compose angry emails praising some other development environment, or asking why we don't just use Java and get Write Once Run Anywhere (giggle), or Delphi (the talent has left the building. .NET is Delphi 7.0,

The one person left the building, but all the source code out there and components for Delphi, and the freepascal project make delphi and pascal still strong as before. There are still plenty of applications written in Pascal being used moreso than ones in net, and there will continue to be (take for example TotalCommander)

and 8.0, and 9.0), or Lisp, or whatever. I am getting locked in the Microsoft Trunk! they will say. Regrettably, I don't have time to get into religious discussions right now and I usually find them quite boring. I don't care if Japanese is a better language than English. It just doesn't matter. Let me finish describing our strategy.

First problem: we don't know enough about .NET to write good code. As usual in any

But that is one of the problems with switching languages! You say you don't like Japanese. Here's a pointer: .Net is Japanese@! You are learning now a new language. Why do so? Shouldn't you stick to your ethics adn use the language you know? Or is the language just not good enough, and you do need to learn Japanese? Or is someone forcing you to use Japanese and you have no choice? (MS).

In delphi, it's been very much the same every since Delphi 1. Why do you have to "port" your code with .Net, isn't it still Visual Basic? Why is it so complicated? Does VB now become just obsolete and useless? Not the case with Delphi or Freepascal code. development environment there are many ways to do any given thing, and we haven't quite learned the first way, let alone the second way. So the quality of .NET code

Why are so many things different? because VB wasnt' designed properly in the first place and now all of a sudden .Net is correct.. but has to change everything and make all your code non-working?

that we can write is not good enough to ship. Until Bill Vaughn's first ADO book came out, we didn't even know the optimal ways to do basic SQL queries. So our first priority is education, which we will accomplish by doing all future in-house and web-based development in .NET -- basically, all the software that nobody is paying money for. We can migrate parts of the Fog Shop to .NET and certainly use .NET for all kinds of internal stuff. (Today I wrote a FogShop Coupon Generator in ASP.NET. It's kind of messy but it works!)

Second problem: the obese 20 MB CLR (runtime). It's bad enough that about 6 MB of the

Why would you use a 20MB run time and still claim that people shouldn't bring up other devel tools? If Anders is so smart, couldn't he have made that 20MB run time only a 1MB smart linked one? Is it possible Anders is reinventing the wheel and Delphi did all what .Net does back in Delphi2 days?

8 MB CityDesk download comes from runtimes and data access libraries; we just can't expect every home CityDesk Starter Edition user to download another 20 MB. The hope is that in a year or two or three lots of people will have the CLR from somewhere else (too bad it didn't make it into Windows XP). We'll keep an eye on that; it used

Hmm.. sounds kind of wishy washy. Hoping and making by based on "what everyone else will do". I think the real problem here is that you invested all your time into VB, and you don't want to switch environments, and you can't see usign any other tool than Microsoft.. because they rule the market. So you just have to JUSTIFY VB and look and pick the little positive points about it (without seeing the huge negative points about it).

to change your user agent; I hope it still does, so we can get statistics.

The bottom line is that neither CityDesk nor FogBUGZ can be ported to .NET today. We

That's sad.

will port some future version of CityDesk when the CLR has about 75% penetration. The plan is to: port existing code and forms using Microsoft's conversion tools fix problems by brute force until it's working again create new forms and classes using C#

Shouldn't you use VB? You say VB is a good language, now all of a sudden it's ditched?

gradually port old forms and classes to C# whenever they need major work, anyway many old forms and classes will remain in VB.NET forever (using the ugly backwards compatibility string functions, etc.) as long as they work properly.

FogBUGZ also needs to wait for greater CLR penetration on server computers; we need to survey our customers and find out how bad it would be if FogBUGZ required the CLR.

We have another product in the works which we haven't talked about publically; this one will share a large portion of its code base with FogBUGZ (a subset we are going to name "Dispatcho") so it will remain VBScript/ASP at heart until we port FogBUGZ.

For FogBUGZ/Dispatcho/SecretNewProduct, the plan is: wait until it's OK to require CLR, port existing "business logic" classes to C#, keep current web forms in ASP, and create new web forms in ASP.NET.