Re: Captain Jake's Top Ten List of what I'd like to see in thenextversionof Delphi


"Randy Magruder" <randy.magruder@xxxxxxxxx> wrote in message
news:44a568b9$1@xxxxxxxxxxxxxxxxxxxxxxxxx
Dennis Landi wrote:


Why use .NET Forms at all when you've got a native Delphi solution
that performs better? Where is the advantage to the Delphi
developer. And if you are not a Delphi developer, why would you
consider VCL.NET at all?

Garbage collection, no more refcounting for interfaces, with the nasty
self-referencing workarounds you have to do. Better interop with
things NOT written in Delphi (C# assemblies), and whatever is cutting
edge .net stuff that's coming out right out of the box.

One might also ask why .NET at all PERIOD. Those MFC apps performed
better than WinForms, so what's the advantage in moving to .NET AT ALL?


That's disingenious since the proposition isn't moving from MFC apps to .NET
but from Delphi Apps to .NET. And the Delphi developers en masse, have
indicated that natively compiled Delphi is good enough for them; and they
feel no pressure to move at all. This particular discussion has been well
vetted in this ng.

Although VCL.NET looks good on the drawing board (especially before
.NET was officially released) I don't see how it can still look good.
In fact its looked bad for the passed two years, IMO.

That's Borland's fault. They did not do what they needed to do to get
the Delphi Win32 development on board the VCL.NET train, and that shows
in the relatively low #s of ported apps and components. DevCo has
catching up to do here to carry the Delphi Win32 successfully into
VCL.NET. They have work to do. It's not an intrinsic problem with the
framework.


As has been discussed here before ad infinitum. Its a product in search of
a market (in *delphi* community). Instead, I'd rather see DevCo focus on
what the customers are asking for instead of trying to devise ways to move
away from a platform they don't want to leave...

The only value VCL.NET is as an ancillary feature for Delphi
Developers who wish to embrace a multi-platform strategy.

Insert the necessary "In your opinion" here. It's both useful for
multi-platform and interop and the ability to continue to re-use legacy
code without re-writing it in a new environment.


Use of "Interop" here is fuzzy. IMO, the average Delphi developer sees no
need to leave natively compiled Delphi to do .NET WinForms development. So
the need for "interop" is putting the cart before the horse; since you can't
of course be talking about CLI type of scheme which we just don't have with
BDS, at all.


But the pressure to use the "right tool for the job" is definitely
not driving .NET Developers to BDS for a number of reasons already
expressed in this thread.

What your legacy code is written in can influence 'the right tool for
the right job'.

So, IMO, VCL.NET is sucking resources away from more vital areas that
would positively impact the existing customer base, better; or,attract
new users from other toolsets (such as ECO).

I would hate to see DevCo take your advise and wave the white flag on
VCL.NET. It is a better solution than WinForms, and should be built

I would hate to see ECO continue that exact same failed strategies
implemented by Borland

upon as the better alternative to rich client .NET development. What
failings it has up to this point are solveable, both technically and
from a marketing/devrel perspective. Having ECO use it as well will
help (and its inability to be a VCL.NET solution has been a problem
both for ECO and for VCL.NET).


A very telling problem, in that the same barriers to use that the ECO team
finds are the same barriers to use all .NET developers will find.... Make
VCL.NET a seamless technology that can be utilized by all .NET developers
and I'll change my mind. If you can't (make it seamless), I just don't see
it gaining traction. MS owns the platform you can't compete at that level
of granularity and expect to win. Times have changed. However, that
doesn't mean the the dream of a better RAD is dead. ECO may well be a key
to success here.

Am I a fan of ECO? No, I am just identifying it as the one existing
differentiator in DevCo's .NET arsenal. Will I be a fan of ECO? I
hope to be after I've done some more research.

I'm a fan of ECO in theory. In practice, the issues with its
integration into the IDE (Together modeling, for instance) and
databinding with 3rd party controls have really caused a lot of hair
pulling for me.

But here is the real promise I see in ECO: It is, perhaps, the next
RAD platform. It
wraps .NET at the moment. But as an MDA artifact; it could
conceivably "wrap" any concievable platform. This is exciting; and
if it works well enough and offers the correct points of interface to
professional software engineers who have their own code and agendas,
it could well be a killer platform...

Yeah so why drag it down by making it a SlowForms only technology? It
should absolutely be part and parcel of the VCL.NET strategy moving
forward. DevCo's slogan could and should be: "Making .net Development
Better"

As far as your 'wrapping MS technology' statement. No amount of
wrapping is going to make WinForms anything other than the piece o junk
I think it is.


I could care less about WinForms and I sure don't need to waste time
figuring out how to compete against a technology that is irrellevant.
-d





.

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: Captain Jakes Top Ten List of what Id like to see in thenextversionofDelphi
    ... is vastly smaller than the Winforms component market. ... VCL.NET developers = less market for VCL.NET components. ... Borland has put Delphi at a disadvantage. ... code directly to the Win32 API. ...
    (borland.public.delphi.non-technical)
  • Re: first impression and uneasy feeling... (long)
    ... I read in one blog that VCL.Net is way faster than Winforms as Winforms is ... based on the GDI+ (which is a performance disaster) and VCL.Net is not. ... > - IDE is very familiar to Delphi users ... > I think a very large percentage of developers using Delphi to do GUI ...
    (borland.public.delphi.non-technical)
  • Re: How can you drop Winforms support?
    ... Being able to use that shiny VCL Office 2007 Ribbon Bar from ... The support for WinForms in Delphi ... Get 3rd paty developers on board with a partner VCL.NET program with the idea of a coordinated release of the VCL.NET IDE and VCL.NET 3rd party ports to get an initial influx of the biggest 3rd party names. ...
    (borland.public.delphi.non-technical)
  • Re: How can you drop Winforms support?
    ... I'm not certain you've provided any reason for those third party vendors ... that VCL simply cannot. ... The product was not in great shape (Delphi 8) ... meant no developers, which meant no components, and so on. ...
    (borland.public.delphi.non-technical)