Re: Thinking Clearly

Bob Dawson wrote:
Sure--why else take the time? <g> The infrastructure type of stuff I do
benefits greatly from generics and the FCL.

Ok, just wanted to make that clear that in some cases the *best*
solution is to rewrite existing code. In this case, is it fair to say
that it is best because of the things that the .NET framework itself
provides?

Other options always exist--I'm just saying the reality of the situation is
that DevCo has a VCL framework that it /can/ bring forward, and doing so may
be relatively cheap, compared to trying to go to CF with WinForms without
any MS cooperation.

Ok, but this is a bit like comparing apples to oranges. The CF issue is
a case where MS is sticking it to DevCo. Also, CF development is
significantly different because compact devices themselves are very
different from PC's. I would be surprised if they didn't have to expend
significant resources on VCL.NET for CF regardless of their past investment.

If Borland had built VCL.NET with the intent of supporting CF
development with it, I could buy your argument a bit more than I do.

In the case of Winforms, Borland didn't have to invest in VCL.NET if all
they wanted was a framework and designers for building .NET GUIs on the
PC. IOW, it was an active choice based on a strategy.

Regardless, at this point in time VCL.NET does exist and if it minimizes
that amount of resource usage to get CF support in BDS, then I agree
with you that's a good thing. The question I have is if it will support
C# well. And how much compatibility with VCL/VCL.NET will it really
share?

IOW, even if they can leverage VCL.NET for CF support easily, will it be
the best/most flexible option for .NET CF development or merely the best
for Delphi for .NET developers.

It may also be considerably safer, since VCL.NET depends
only on the win32 interopt layer continuing to function, whereas extending
WinForms makes them dependent on the Visual Studio team not changing the
interface requirements of WinForms designers and debuggers.

WinForms designers are in the framework itself, not VS; CF designers are
in VS. Enhancing the Winforms designers, or aspects of them, that are
in the framework itself seems very doable to me.

That's not .NET
code, and DevCo has no guarantee that anything it writes there isn't built
on sand. In contrast, interop and the core win32 API are bedrock.

Was Win32 "bedrock" when Delphi 2 was released? MS could have changed
Win32 on a whim as well.

It's important to consider all the versioning technology that .NET
includes to mitigate these problems. From that perspective it can be
argued that .NET is actually less risky to build off of.

But during that time, the most important thing for DevCo to do is hold on to
their existing base and convince it to upgrade en masse.

I agree.

For that specific
audience, VCL.NET is crucial.

I disagree.

The Delphi users you are still using D7(-) are
never going to upgrade to Highlander or beyond if DevCo doesn't have a
convincing forward path for them. "Just start over, WinForms aren't that
bad" isn't good enough.

Nonsense. IMO, more Delphi users would upgrade if the Win32 language
were to be enhanced with generics. More would upgrade if BDS' C#
support was better than VS.NET's.

The second crucial thing needed, IMHO, is a convincing reason to buy
Delphi.Next /for Win32 enhancements alone/. Otherwise people are going to
stand pat on D6 or 7, and start playing with .NET in a VS express edition.

I think this is infinitely more critical than the former.

Perfectly possible. I'm not claiming it's free. Only that I'm reasonably
sure that DevCo has to be re-evaluating the cost-benefits pretty
continuously.

In regards to VCL.NET I think a realistic re-evalution will demonstrate
a poor ROI.

Several years back, Danny made a statement in his blog (about
the advantages of .NET) that Borland should never indulge in writing
infrastructure code that it didn't have to: it should alway prefer to use
what MS provides, and ride on top. I don't think that that general opinion
has changed since he left.

I agree, and I hope that DevCo has the courage to not only talk the
talk, but walk the walk even if they have to step on some toes.

As a metacomment, I might characterize your postion as being that DevCo
should be about value-add in the .NET arena, not writing parallels or
alternatives. Fundamentally, I suspect that DevCo already holds that view,
with only a slight qualification: "/As much as possible,/ DevCo should be
about value-add in the .NET arena, not writing parallels or alternatives."

If they want to build an alternative, they wouldn't support .NET at all.
They'd create their own runtime/cross-platform managed environment; but
I suspect they don't have the resources to do so.

I suspect that VCL.NET isn't something that DevCo desparately wants to do,
but rather something it knows it has to do: IOW, it currently passes that
test. And I suspect it strongly because they tried for several years to get
to CF some other way.

I disagree. Look at the reasons here:

http://bdn2.borland.com/article/31983

Be sure to read Danny's CF rant.

If you want to look at the current state of affairs, I agree that they
should just dump VCL.NET just yet; but I think they should seriously
consider it after highlander.

The CF designers and debugging support belong to VS, not the .NET team. And
I also suspect that the the WPF equivilents will also, and similarly
unavailable to DevCo--not included in its .NET technology license. But I
don't know that for sure either.

Right...so that means even more work to support WPF without having to
build VCL.NET for WPF.

Borland, on its last BDS tour, has said themselves that the majority
of Delphi developers are still on Win32.

I tend to belive that as well.

But let me ask you this: Do you honestly believe that the adoption rate
of Delphi for .NET is high? I'd be surprised if 30% of the Delphi
community as a whole are actively/professionally using Delphi for .NET.

No, hence my comments about win32 enhancements.

So why play to your weakness rather than your strengths? If Delphi's
strength is Win32, then focus on Delphi Win32. If you want to compete
in the .NET space, start with making C# in BDS on par with VS.NET.

If you want to bring Delphi into the .NET world, then offer something
better, not more comfortable. Add a mixed-mode Delphi compiler which
offers a more natural and powerful migration path to .NET. IMO, VCL.NET
is a waste.

Why are you adding it to your toolkit?

Because I'm increasing needing to interact with enterprise packages that
assume VS as their customization/extension environment. Don't know how
common a problem that is with the independent and SMB developer market, or
what DevCo can do about it.

Yeah, that's a tough one, but their current .NET strategy doesn't even
come close.

--
Brian Moelk
Brain Endeavor LLC
bmoelk@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
.

Relevant Pages

  • Re: Thinking Clearly
    ... keep D7 for win32 and go VS for .Net. ... way for Borland to get more money from me (not me personally, ... option than to remain with Delphi; possibly adding VS if I had new ... They still support DOS ...
    (borland.public.delphi.non-technical)
  • Re: Are we kidding ourselves?
    ... this because we have over 30 other Delphi Win32 applications to support and therefore thought we could leverage our strong Delphi knowledge and make headway with .NET at the same time. ... We use BDS2006 for all ASP.NET development, but still use D6 to maintain our Win32 apps, partly because we got trapped by some third-party components, but also because we have not been able to see major productivity benefits in updating our Win32 tools. ... BDS2006 is based on the 1.1 iteration. ...
    (borland.public.delphi.non-technical)
  • Re: Are we kidding ourselves?
    ... therefore thought we could leverage our strong Delphi knowledge and make ... Win32 apps, partly because we got trapped by some third-party components ... .NET V2 support, let alone support for AJAX functionality, yet it doesn't ... BDS2006 is based on the 1.1 iteration. ...
    (borland.public.delphi.non-technical)
  • Re: Thinking Clearly
    ... time to rewrite it, then I'll rewrite it. ... that DevCo has a VCL framework that it /can/ bring forward, ... interop and the core win32 API are bedrock. ... The Delphi users you are still using D7are ...
    (borland.public.delphi.non-technical)
  • Re: Thinking Clearly
    ... and how many are using Delphi for .NET development? ... think DevCo should focus on making .NET better, ... years to get CF designers and debugging support and hasn't been able to, ...
    (borland.public.delphi.non-technical)