Re: Advantages of Delphi.NET

From: Sinan Karaca [MimarSinan] (sinankdeletethis_at_mimarsinan.com)
Date: 08/19/04 

Date: Thu, 19 Aug 2004 14:41:31 +0300

> > 1) Using Delphi.NET, I was able to start coding for the .NET platform
> > immediately. Without learning a single new thing about .NET. I used
> > VCL.NET,
> > of course.
>
> This is a huge selling point for Delphi for .NET . However many of the
> developers I've spoken to opted for WinForms for a true .NET experience.
I
> guess they would rather be closer to the .NET workings this way and if
> they're going to adopt the framework, why not learn something new in the
> process.

I disagree that WinForms is a true .NET experience and VCL.NET is a fake
one. The simplest way to illustrate this: WinForms runs only on Windows.
Why, because it has P/Invoke calls to the Win32 API. How else could M$ offer
a sophisticated UI for the FX in such short time? Of course, keep in mind
that the entire .NET FX itself is implemented on Windows - meaning,
ultimately, that it is not "pure". While I have come across many purists,
especially in the Linux world (they rejected Kylix because it wasn't
"pure"), and I have respect for the religious/fanatic kind of purism, my
priority is on getting the job done in as little time as possible with as
high quality as possible. The quality has very little to do, if at all, with
the purity factor.

> > 2) As the need arose, I started working with .NET classes and learning
> > them - the rest was handled by VCL and the other FX that Delphi
provides.
> > This made the learning curve very, very smooth.
>
> I must agree, the learning curve is quite steep, espcecially if you also
> have to throw yourself into C# rather than Delphi, so any help to ease the
> learning process helps.

More than a steep learning curve, I am upset that everything I know gets
thrown out of the window, just because M$ marketing decides they're going to
call COM+ 2.0 an entirely new "platform", a new "framework", even a
competitor to Java. The point is perhaps - I know .NET doesn't really make
anything easier. Its not worth my time to learn and switch over to. I've
always been using Delphi - which was always a visual, yet low-level, real
language (pure, if you will). Maybe all those M$ people out there are
excited they can finally do what we've been doing with Delphi since 1995,
but I don't really find any of this new. I've had this flexibility and ease
of use for a long time.

> > 4) Maybe this is the best part - I was able to back-port the same
> > application to Win32 in a week or so. AND I have single source compiles
> > for
> > Win32/.NET now. True, there are quite a few IFDEFs here and there, but
> > that
> > is all it cost.
>
> If you have half your clients on Win32 and the other half moving to .NET
> then I guess having a single source is good. Its probably achievable if
> you have non-visual classes such as straight forward business classes.
> However, for the scenario of Win32 projects that use a hybrid of 3rd party
> visual components, you're forced to find alternative components in .NET
that
> do the same thing. Never mind 3rd party components, what about native
> Delphi 7 components (ADO) and frameworks (WebSnap) that aren't supported
in
> Delphi 8? Also many of the components out there for .NET come with source
> (mostly C#) . I'm not eveb sure if you can incorporate C# projects into
> Delphi 8?? The point is that you have no choice but to keep a Win32
stream
> and a .NET stream.

I imagine most "dropped" components will make a comeback in the next Delphi
update. Both those provided by Borland in the package, and also those
provided by third party vendors. The VCL itself is the best example for
this - that you can have components which run identically on Win32/.NET and
are called the same way in your code too. For example, the new menu/toolbar
components introduced by Delphi 7 (Office XP style) disappeared in Delphi 8.
But we see the D8 IDE, which is .NET, uses them. So the functionality is
clearly there - there just wasn't enough time to get it all tested and ready
to ship as reusable .NET components.

About the source issue, virtually all Delphi components have source, but in
the transition to .NET, because pointers etc. are missing, it is a better
idea to let the vendor migrate them for you. I have the source for all my
Win32 components here but I am not so sure I personally want to take the
time to migrate them. What is amazing is that once the migration is
completed, thanks to the wonders of OOP, although "under-the-hood" its
totally different stuff going on, everything works the same under Win32 and
.NET. This to me is real computer science in action - not just marketing
fluff.

> So what's the point? Unless your target platform is entirely .NET there's
> not point in trying to make your app straddle the Win32 and .NET platform.
> You're going to only create a code maintanance nightmare by littering your
> code with countless IFDEFs and compromise your apps functionality.
> My point is that I think it should be all .NET or don't bother. Also,
if
> you're app is bulletproof on Win32 and your clients are happy, why bother
> migrating to .NET for the sake of saying that my code now compiles in
Delphi
> 7 and 8.

I am clearly not maintaining a .NET and Win32 version just because I can, or
because I have too much time on my hands. I am doing it because it serves my
needs. The point is that I have found a vehicle which serves my needs, and
no other vehicle at this time provides this. M$ doesn't even let you move to
.NET without rewriting all your software - save having single source
compiles!

> > We all know the famous example - open the Delphi 1 fishfacts app, and it
> > compiles under D8. Now you have a single source app, compiling on Win16,
> > Win32, and .NET. This definitely says something!
>
> Sure it says something about Borlands commitment to the past 20 years.
But
> what's the point? Move on. How many Windows 3.1 OS's have you seen
> lately? If it wasn't for the BDE's migration to Delphi 8 (yes, weren't
we
> all surprised that the BDE made it but ADO didn't) , it wouldn't have been
> possible for the fishfact demo to run. In fact, it might be the only
reason
> why the BDE was migrated. Furthermore, if you intersect the components
> that are compatible on all three platforms, you're left with a handfull of
> standard components, and the BDE. You're app is forced to stick with the
> most basic of user interfaces and database components. Imagine if car
> manufacturers still used spoked solid rubber wheels purely because thats
> what was used in the first motor vehicles?

The point here is that VCL, and the FX that ships with Delphi in general,
has been ported to more platforms and operating systems than any other FX to
date. AND, that by all indications, it will continue to be the most widely
tested, widely deployed FX available for a long time to come. AND, that
because it has been through so many transitions and changes (even across
real platform boundaries - Windows and Linux), it is technically very sound
at this point, otherwise it would not have survived all the transitions.
This ties in with my point below.

> > I consider my knowledge of VCL an investment, one that will last well
into
> > the future - Borland gives us reason to believe that even when M$ drops
> > the
> > Win32 API, we will still be leveraging our VCL knowledge - and natively,
> > at
> > that. While I have occasionally fallen in to the "oh what if Delphi gets
> > discontinued" panic, which seemed to be a real threat back in the Del
> > Yocam
> > days - I think time has proven the choices I made.
>
> You've learnt nothing new about the framework because the VCL does it all
> for you. My worry is that the VCL will now more than ever be one step
> behind the underlying framework. It was the case with Win32 and even more
> so with the .NET framework.

One step behind? This is a valid charge. However, can you give me specific
examples of how this has prevented you, in the real world, from achieving
your needs? Whenever this constrained me in Delphi/Win32, I just popped the
hood and made the necessary changes. Because Delphi is pure, it lets me do
that. I am isolated from the underlying mechanics but I am not prevented
from going there when I need to. This is what M$ does not do. They isolate
and bar you - they isolate you for their own sake. Borland isolates me for
my own sake - to save me time and effort involved in reinventing the wheel.
But I am not barred from going low level if I want to.

> I made the brave move from my 9 year Delphi comfort zone to .NET and
deiced
> to take on a new language (C#) in the process. Also because Delphi job
> boom is over in this country and the tiny pool of jobs that are available
> don't pay well or they're for maintaining legacy Delphi apps while the
rest
> of the developers move onto MS .NET.

Unfortunately, this is true (it is the only statement you have made that I
agree with). If the job market does not demand Delphi developers, there is
nothing you can do.

Even if managers may never understand it, their vision clouded by M$'s
billion dollar marketing budget, I think at least the developers should know
the truth - Delphi jobs have been shrinking because of M$'s misinformation
propaganda, not because Delphi has suddenly become useless/irrelevant. The
last thing M$ does is serve computer science - if you are looking for purity
in that sense, ironically, Delphi is the purest you'll ever get.

Relevant Pages

  • Re: Captain Jakes Top Ten List of what Id like to see in thenextversionofDelphi
    ... MFC and WinForms do not. ... For the Delphi developer, there is less of an argument. ... How many VCL Win32 customers have been asking their vendors to support ... Delphi developers, moving their existing Win32 application to .NET ...
    (borland.public.delphi.non-technical)
  • Re: Stop the negativism!
    ... of Delphi added features that wrapped the latest out of MS. ... But this strategy (and it upgrade income stream it generated) became more ... these coming platform evolutions when many developers ... The bottom line is that the core technology that Delphi rides on (the win32 ...
    (borland.public.delphi.non-technical)
  • ANN: Migrating to Delphi 8 for .NET Masterclass - London (UK) - Tuesday April 27th
    ... Announcing The Developers Group Migrating to Delphi 8 for .NET Masterclass ... to Win16, and then from Win16 programming to Win32, developers will need to ...
    (borland.public.delphi.thirdpartytools.general)
  • ANN: Migrating to Delphi 8 for .NET Masterclass with Brian Long - London UK - Tuesday April 27th
    ... The Developers Group presents Migrating to Delphi 8 for .NET Masterclass ... that it is the heir apparent to the Win32 API. ...
    (borland.public.delphi.thirdpartytools.general)
  • Re: The New Roadmap
    ... Delphi Product Manager - CodeGear ... it may be that Win32 is a focus and Codegear ... Delphi revenue and sustainability the roadmap may be prioritized correctly. ... that's going to be very good at changing developers' perceptions. ...
    (borland.public.delphi.non-technical)