Sometime ago I posted an entry about some comments Michael Swindell had made about how Delphi was a better choice for enterprises because of it's speed. Marco followed-up to that post with another one yesterday about how really .NET vs Win32 speed is not relevant, but what is relevant is being able to upgrade your application to the latest compiler, that same application written in Delphi 2.

I was going to comment on his blog, but since it turned out long, I've made it a blog post. Now here's the thing. My original blog post wasn't about Delphi vs Visual Studio/C#/VB or CodeGear vs Microsoft. My point was that it's not all about performance. It might matter for intensive calculations and processing, but in general, it is not the case for the vast majority of Enterprise (or non-Enterprise for that matter) applications, specially when the real bottleneck is the database back-end and/or network.

Now Marco's post has somehow hooked into stability and reliability. These are broad terms which can be applied to many different aspects of an application and it's lifecycle. More than the actual scalability and up-time of the system, I think Marco's post is mostly referring to backwards compatibility.

One of the other points he brings up is how certain technologies have been dropped or are not backwards compatible. As for things being dropped, I think it's fair to say all companies do it. Even CodeGear has done it. Should I forget all the investment my company made in Internet Express? What about those poor people that invested in WebSnap? Not to mention Kylix or the recent VCL.NET.  In the case of Linq To Sql, it was pretty clear that this was a mid-term solution until they had something shippable with Entity Framework, and just like everything, if you took the necessary protection, it wouldn't hit you so hard. 

In regard to backwards compatibility, I couldn't agree more. You need to try and sustain compatibility as much as possible. However, there are times when it's near to impossible and you have to cut some ropes for the "greater good". Sometimes it's not viable to allow for new functionality and/or features without making sacrifices. We had this many times on Indy.

He also mentions how continuously new technology comes out from Microsoft. Well here's the deal. Microsoft is a company. Just like most of us they are here to make money . They push out new technology because among other things, it generates revenue and obviously there seems to be a demand for it. It's the same as us, as developers. When working on a product we tend to continuously innovate and create new features for our end customer. Why? To try and improve their experience, to try and make it easier for them, but ultimately to also generate revenue.

At the end of the day, if you're on the bleeding edge, don't be surprised if sometimes you cut yourself. That's where you need to apply judgement and valuate the risks involved, both for yourself and your business. Nobody forces anything down your throat. You're free to continue using what you were using 5 years ago. ADO.NET still works today. All new technology is still built on top of it. You just won't get the added-value if you don't "upgrade".

Here's an update on the roadmap for Linq2Sql. The post is pretty much confirming that they're killing off the project.

A project we started recently, we had to make a choice of which ORM to use. Since Entity Framework wasn't still up to par (and in certain aspects probably still isn't), and the team had experience with Linq2Sql, we decided to use that. However, from day one, we made a conscientious choice of not leaking anything of L2S into our domain objects.

This meant that we didn't use the L2S objects, but in turn used our own POCO classes. Therefore the sole purpose of L2S was to map data from the DB, what the job of an ORM is. Recently, and before the announcement, we found a lot of shortcomings when working with L2S and aggregate roots (I won't get into the details since Steve is planning a series of posts on the subject and how to handle aggregate roots with the different existing ORM's). We've therefore decided to switch ORMs. The beauty of it is that because of the clear abstraction of L2S, it's going to be very easy to swap out L2S for another ORM.

Now that we have confirmation that L2S isn't going anywhere, if you have issues with the current version and were hoping to get them resolved in a future release, I guess you're out of luck. So the time comes to move on. If you've abstracted well, it shouldn't hurt that much.

Obviously if you don't have issues with L2S and no projections on needing new features, then stick to what you have. "If it ain't broken, don't fix it". But don't start any new projects with it. Even Microsoft don't recommend it anymore.

Well Marco's probably been the first one to blog about it. My only comments are:

a) Change the name. PRISM is already a pretty well-known project in the Microsoft camp, also known as Composite Application Library for WPF/Silverlight

b) Two years ago I said at a session at TechEd that going down the VCL.NET route is a mistake because of the lack of roadmap and support from third-parties. I received a lot of feedback (i.e. read hate mail). Ironic...

On Steve Martin's blog

I was just reading on a blog a reference to an article Michael Swindell published about native application development. It's fair to say that you don't always have to agree with everything someone writes, but I think in this particular case, there is misleading information.

The story of the .NET framework lagging behind native performance just doesn't cut it anymore. Wake up and smell the coffee. We are three versions into the .NET framework and Microsoft is already talking about 4.0. While we are seeing new things that will make applications and architectures more flexible and easier to maintain (such as dynamic binding), Delphi developers are still complaining about the garbage collector.

This might come as a shock to you, but in a business application, your end customer is not going to know how long it took him to destroy that order object, or to create it for that matter. He cares about his application. He cares about interoperability. He cares about his ROI. With all that the .NET Framework (or Java for that matter) has to offer in terms of productivity to the programmer, with all the frameworks that exists to make application development easier to maintain, the native vs interpreted performance argument doesn't stand anymore.

I'm not saying that native is bad, far from it. Right now, and for the foreseeable future, there is a place for native code, just as the article points out, something needs to be under that virtual machine or the RIA. Until all computer systems (excluding my mother, she's already on .NET 3.5) have the .NET framework installed, there will be room for small utilities to run natively. But enterprise level or businesses do not have an issue with making use of applications that use the .NET framework. They don't have an issue with deployment. You can still automate and accomplish easy deployment with .NET (and I'm not even talking about ClickOnce).

Every day we have faster processors coming out, we have cheaper memory and yet 6 years after the release of .NET we are still clinging on how native out-performs managed. They say you shouldn't dismiss something without having really tried it. Unfortunately that's something I see a lot in the Delphi community.

Halfway through the install, I get prompted with the following

I checked, only one instance of the setup (/installer) running. Tough call!