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

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?

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.

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.

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
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).

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.

Randy
.

Relevant Pages

  • Re: I really hate .NET especially inside Delphi
    ... Because its not a reason for Visual ... Delphi and expanded. ... With ECO a whole new way of creating software can be pioneered with DevCo ... "enhancements" you posted awhile back and I'm not impressed. ...
    (borland.public.delphi.non-technical)
  • Re: Vote for it: ECO Visual Studio plugin
    ... I won't get any further down into this part with you, because we are both agreed that if evaluated in terms of existing ECO users, there's a logic behind continued C# support. ... But if you expect to invest most of your $$ into building and growing developer tools such as Delphi, you have to have product differentiators that are available exclusively in your developer tool. ... And when you tell me that Delphi "can't compete on .net, it's just that simple" how can you deny you're flying the white flag? ...
    (borland.public.delphi.non-technical)
  • Re: Captain Jakes Top Ten List of what Id like to see in thenextversionof Delphi
    ... Where is the advantage to the Delphi ... better than WinForms, so what's the advantage in moving to .NET AT ALL? ... And the Delphi developers en masse, ... I would hate to see ECO continue that exact same failed strategies ...
    (borland.public.delphi.non-technical)
  • Re: Roadmap Review - My Questions
    ... ECO is somewhat expensive and I have reservations about not having ... Chrome offers additional value above and beyond Delphi for .NET. ... "Again it can be a productivity issue - one already knows the VCL, ... Delphi for .Net, for those preferring C#, ECO is just as much an advantage ...
    (borland.public.delphi.non-technical)
  • Re: My rant about the "throw out delphi and re-write it in C#" crowd.
    ... for .NET development over Delphi .NET? ... No ECO Support for VCL.NET ... their WinForms stuff, ... As far as the Delphi "language" goes, vs. C#, I'm agnostic. ...
    (borland.public.delphi.non-technical)