Re: Thinking Clearly

Nick Hodges (Borland/DevCo) wrote:
Agreed -- VCL.NET is merely one part of a large and complicated
product. How this single technology is suddenly shouldering the entire
burden of bringing new users to the product is something I don't
understand.

I don't think that's a fair characterization of the discussion as a
whole. I don't think anyone believes that VCL.NET is solely responsible
or even the primary thing that's going to bring new users to the product.

But if it's not VCL.NET alone shouldering the burden, then I would like
to understand what other things are shouldering the burden. AFAICS,
there are some other things in the .NET space that have that potential:
ECO, BDP.NET and Delphi for .NET itself.

It seems clear to me, that DevCo views VCL.NET as a strategic
competitive advantage. If its main strategic advantage is the code
migration one, that's fine. I personally recognize that it is indeed an
advantage for code migration.

But I believe that this means that it is not an advantage that will
enlarge the customer base in any significant way unless there are some
other benefits to VCL.NET. So I'd like to take a step back and ask
honestly: What are the other benefits in choosing VCL.NET over Winforms?

In addition, I don't agree that VCL.NET is not worth the
effort merely because it might not be some "newbie magnet" that some
are setting up as.

I agree, but this really depends on how much of your customer base is or
will be using Delphi for .NET development.

If it truly is the problem as Randy describes of the community actually
not knowing that BDS supports .NET development at all, then I would
agree that it is a marketing/evangelism problem.

But I, like I.P., am quite skeptical of that situation. As a Delphi
developer, I think you'd have to be living in a cave not to know that
Delphi supports .NET development.

This is, BTW, a textbook case of a strawman argument -- setting up an
argument purely to knock it down.

It's only a strawman if the intention is that VCL.NET has *no* value if
it doesn't bring new users to the product. I don't think anyone is
saying that at all.

If the primary value is code migration, then it's fine to just say that
VCL.NET is more of a customer retention technology rather than one that
will bring new developers into the fold.

Certainly there are some that will appreciate the two-way code migration
capabilities of Delphi for .NET and VCL.NET and that might bring a few
guys on board. But FMPOV, that looks like a very narrow segment.

--
Brian Moelk
Brain Endeavor LLC
bmoelk@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
.

Relevant Pages

  • Re: Function Inlining (and other compiler enhancements)
    ... There are quite a few people who happily use D8 for .NET development. ... I'd not be willing to call D8 a 'disaster' ... ... > 64-bit compilation. ... I'm a fan of Delphi, ...
    (borland.public.delphi.non-technical)
  • Re: Why arent you upgrading?
    ... with BDS for .NET development. ... doing a "me too" .NET development tool is worthless. ... Not to mention the Delphi myopia that drives DevCo only to see how to ... Ruby or Python since they have their own culture and philosophy. ...
    (borland.public.delphi.non-technical)
  • Re: .NET 3.0 created by the stroke of a pen
    ... I don't know anyone doing .Net development of any type at our users group. ... So yes a lot of them are doing native with Delphi and web with ASP.Net and VS. ... I am assuming that is true for all 20 of our regulars to our Programmers Users Group. ... BSS Enterprise Accounting FrameWork ...
    (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)