Re: Thinking Clearly

Nick Hodges (Borland/DevCo) wrote:
First, there is more than one way to lure new users into the Delphi
camp.

Certainly.

Second, ECO for VCL.NET is of high interest to a number of customers,
and I personally believe that it /is/ a compelling reason to check out
..Net.

ECO itself sure; ECO supporting VCL.NET not so much.

Note there is no ECO "migration path" as there is for Delphi Win32 ->
Delphi for .NET and I think it's appealing enough for many Delphi
developers to take a look at .NET itself.

If you are a VCL developer, you can more easily give ECO a look
-- something that people, including if I am not mistake, you, Brian --
have been arguing for.

It's completely braindead to have VCL.NET and ECO, but not have ECO
support VCL.NET...so yes, I'm a strong advocate of that simply because
BDS is not cohesive in its current state. OTOH, if there were no VCL.NET...

It's my view that we must do both .Net and Win32 to be sucessful.

I agree.

VCL.NET is more than just an alternative to Winforms. It's also a path
to CF and perhaps even WPF.

It may be, but unfortunately, I believe this will require forging a new
path as well as supporting the bulldozed one running parallel to it.
Hence, more work for DevCo.

Granted, CF designers are a problem that require work beyond what MS has
provided in the framework but this just illustrates how tough the task
is. Is it less effort to bring VCL.NET to CF or less effort to create
their own designers for CF with 100% compatibility with VS.NET's? I
don't know.

The VCL, in it's various incarnations, is
the preferred framework of a very large number of Delphi developers.
We aren't about to forget that or fail to leverage that fact for the
benefit of our customers.

VCL Win32 absolutely; VCL.NET OTOH has a ways to go for it to be
leveraged with true benefit IMO, FMPOV.

--
Brian Moelk
Brain Endeavor LLC
bmoelk@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
.

Relevant Pages

  • Re: genral question
    ... In fact I personally would choose BDS for large company apps because of ECO. ... recurring time lag. ... and Pascal compiler stuff are brought up to speed - well over ... in supporting the latest batch of .NEXT acronyms... ...
    (borland.public.delphi.non-technical)
  • Re: Delphi roadmap from the .NET perspective...
    ... ECO isn't comparable to Linq or WPF. ... Supporting vs.net doesn't really matter and I wasn't thinking of wpf. ...
    (borland.public.delphi.non-technical)
  • Re: Delphi roadmap from the .NET perspective...
    ... all that is water under the bridge because ECO is supporting VS.NET. ... Brian Moelk ...
    (borland.public.delphi.non-technical)
  • 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)