Re: Delphi for .Net 3?

Brian Moelk wrote:
John Furlong wrote:
Perhaps that's because they have bought into the Microsoft "vision", due
to a lack of critical thinking on their own part.

I'm not sure. Even though I think most managers, and even many
programmers, underestimate the value of existing code, I think there
might be some substance to the idea of reevaluating systems every 5
years or so.

Perhaps so. but surely there is a difference between doing the re-evaluation for sound business reasons as opposed to being forced to do this arbitrarily (e.g. because a particular tool or API has been unceremoniously dumped by the vendor).


It's a tough thing because it's not only pure technology changes, but
architectural changes. For example, client/server architecture fell out
of favor for n-tiered architecture over time.

Despite any tool's technical ability to support these different
architectures there are fundamentally different approaches to developing
applications with these different architectures. Therefore, even if
Delphi supported SQLinks, then MIDAS/dbExpress, it doesn't make the
transition significantly easier since IMO, in order to move to the
n-tiered approach more fundamental things need to be changed.

This is certainly true when considering how to implement new applications. However, for an existing application, providing it is still working to the users' satisfaction, why should it be re-implemented just because it doesn't use the currently in-vogue architecture? After all, at any given point in time, you have to put your stake in the ground and say this is how we are going to design our application, and hope that it will serve you for a reasonable amount of time. Once it has been done, and you are in maintenance mode, you shouldn't to have to incur the cost of a significant rewrite or conversion because my tool vendor has abandoned the tool / API I initially chose. (Of course, an app. might eventually be too old and mouldy to keep maintaining, but the choice to re-implement it should not be arbitrarily forced on you due to something like VB6 is no longer supported. And even when you do re-implement, being able to reuse existing business libs (See Dan Barclays recent posts) is certainly valuable.)


Yes, and I agree that MS doesn't have a good track record with Win32.
But the fact is that .NET is very different from Win32, so in this case
I believe that it is worth looking at rewriting or integrating code for
certain things.

I find it interesting however, that while .NET and Win32 are quite different, the Delphi team manged to find a way to let you migrate / share a great deal of code between VCL and VCL.NET applications, if Microsoft had done the same for VB users, there wouldn't have been the uproar over VB.NET.


I think that DevCo has a really good story to tell in terms of Delphi's
track record of ongoing compatibility. I have worked with Delphi from
D1, and there have not been any major roadblocks to moving code forward
(Now on BDS2006) for me. Some minor code tweaks have been required in
some cases, but nothing on the scale of a rewrite.

Agreed, but .NET is very different.

Although Win16 -> Win32 was also different, I just believe that it
wasn't such a noticeable transition because everyone moved as quickly as
possible to Win32 and never looked back. ;)

Ironically, using Delphi has been a less risky, and more cost effective
way of building and maintaining applications (for me at least) than
following the crowd and using Microsoft tools. i say "ironically",
because the justification for not using Delphi is often the "its too
risky, Microsoft is safer, Microsoft is cheaper" argument. Which, when
you look at it in hindsight, has patently not been the case.

Agreed. But I believe that .NET changes the game and I think we'll see
that in Delphi for .NET usage.

The .NET issue is certainly more complicated than Win16 vs Win32 where there was a clear and immediate advantage in going to Win32. For some people .NET (especially ASP.NET) seems to be a compelling story. However, for those whose emphasis is desktop apps it seems less so. Over time this is likely to change, but I don't think its a racing certainty. It will be interesting to see how quickly Vista and WinFX apps become widely deployed, and whether users will demand "new-look" apps. I suspect the uptake will be faster in the consumer apps space, but that many enterprise desktop apps will be Win32 for a long time.

By the same token, Borland seems to have dropped the ball in the execution of its NET strategy by delivering late on Net 2.0. It remains to be seen if the can recover.

John.
.

Relevant Pages

  • Re: Delphi for .Net 3?
    ... Even though I think most managers, ... For example, client/server architecture fell out ... Delphi supported SQLinks, then MIDAS/dbExpress, it doesn't make the ... and I agree that MS doesn't have a good track record with Win32. ...
    (borland.public.delphi.non-technical)
  • Re: A time for patience
    ... apps for Vista, XP, and 2000, that apparently Delphi 2007 for Win 32 ... app department, Ruby in Steel, matches Delphi 2007 for Win32. ... for Win32 in web app development. ...
    (borland.public.delphi.non-technical)
  • Re: A time for patience
    ... apps for Vista, XP, and 2000, that apparently Delphi 2007 for Win 32 ... app department, Ruby in Steel, matches Delphi 2007 for Win32. ... for Win32 in web app development. ...
    (borland.public.delphi.non-technical)
  • Re: There is no market for a Delphi for .NET compiler
    ... There is a demand for a Native compiler for Delphi both for Win32, Win64, and Linux64. ... The most likely thing I can think of is that somehow, the use of a native win32 application is deemed as "not safe". ... If win32 apps become subject to some costly "certification" process that doesn't apply to .NET apps, that would likely motivate us to move to .NET. ...
    (borland.public.delphi.non-technical)
  • Re: About speed
    ... It seems to me that too often Delphi developers decide ... apps that used to rely on ... Borland are trying to make the transition from Delphi for Win32 to ... constructor Create(name: string); virtual; ...
    (borland.public.delphi.non-technical)