Re: Delphi Product Manager questioned

Andrea Raimondi wrote:
I disagree on a very simple concept: even when MS did APIs,
Delphi was able to do "more" than MS in many areas, namely the widest
used ones. I beleive this can happen again with dotNET, after all
there's a track record here.

There is some historical precedent for your position, although I think
it ignores the more recent historical events of BDS' current .NET support.

I recognize that things can and will change with DevCo, but the core
problem still remains: MS resources will continue to dwarf DevCo's. MS,
IMO, is also doing a better job with .NET than they have done in the past.

So although I agree with learning the lessons of history and applying
them to today, things do indeed change and we can't only look back when
we look to the future.

Disagree here again: Delphi.NET is an *asset*.

It is an asset. The question is if that asset is an albatross or one
that is actually delivering value to BDS' customer base.

While it's true dotNET gets used mostly for new project, I wouldn't
feel that bad if I could just recompile(or almost just recompile) to
have my "fantastically stable and revenue generating" program to be
ready for dotNET should the need arise. And it probably will at
some point.

Ok, how much are you willing to pay for that? Are you willing to pay
for that insurance policy at the cost of other important things like
unicode for VCL?

Also, this "need" hasn't materialized in the last 5 years, I doubt it
will materialize in the next 5 years. Singularity is certainly
something to watch, and at that point it might make sense to pursue this
strategy, but perhaps yet again this strategy is ahead of its time.

FWIW, it's not that I don't think the current strategy is a wonderful
idea, I just don't think it's realistic or effective.

One thing that's really not forgivable to DevCo, however, is the
lack of an included TStringList for dotNET.

There isn't a TStringList in VCL for .NET?

If there isn't, IMO there are more significant unforgivable things about
BDS' .NET support. ;)

Again, should the need arise, and it *will* some time in the future if
things keep being this steady, a soft migration using VCL.NET seems
quite reasonable to me.

Right...should the need arise. Delphi for .NET is an expensive and
resource intensive insurance policy. One that if we're focusing on
what's likely to happen rather than a fearful possibility is pretty
superfluous.

How likely is it that MS will drop Win32 any time soon? There are just
too many applications out there utilizing it, remember what Gates said
about Win32 support? Let's take a step back and not act out of fear.

The same goes for components development: if you do your homework
(that is, don't use pointers, use wrapping classes when you can't
avoid it, etc), they'll recompile just fine.

Indeed, which I think makes my point about interop stronger.

Regarding CF: it's been asked hundreds of time if you can
develop PDA applications with Delphi: it's time to say a
resounding YES!.

I know, I want it too, but in life and in business decisions have to be
made and you can't do it all. Tough decisions have to be made in tough
times and I see BDS' .NET strategy facing tough times right now and in
the near future.

I'd really push ECO for ASP.NET; I'd move what's currently at the
Enterprise level down to the Pro level sku. I understand that ECO is

This is, imho, more difficult, because there must be some
differentiating factor between Pro and Enterprise.

Eliminate the Architect SKU and slide everything down. ;)

I think what you wrote would give Delphi the kiss of death.

Maybe, but at least we're having a challenging conversation with some
substance right? ;)

--
Brian Moelk
Brain Endeavor LLC
bmoelk@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
.

Relevant Pages

  • Re: Delphi Product Manager questioned
    ... spoken with have said "If we're doing DotNet, ... Have you not replied to them that Delphi (BDS) *does C#*? ... Wayne Niddery - Winwright, Inc ...
    (borland.public.delphi.non-technical)
  • Re: Delphi Product Manager questioned
    ... Wayne Niddery [TeamB] wrote: ... spoken with have said "If we're doing DotNet, ... Have you not replied to them that Delphi (BDS) *does C#*? ...
    (borland.public.delphi.non-technical)
  • Re: Rename Delphi to Turbo Delphi Upgrade to "Special Offier"
    ... includes both Delphi and C# instead of just Delphi, they are going to quit ... You say they don't like BDS, I can only guess because the ... might as well be able to do it in DotNet 2.0... ...
    (borland.public.delphi.non-technical)
  • Re: Delphi Product Manager questioned
    ... they need to support in order for BDS to be considered a viable alternative ... DevCo will get more resources, I'm not certain it will be enough. ... with those that have suggested similar for Delphi pretty much from its start ... a mixed-mode compiler would address many of the .NET interop issues ...
    (borland.public.delphi.non-technical)
  • Re: Delphi Product Manager questioned
    ... To me the choice of Delphi is effectively a "lock-in" to Windows ... because adoption might take 6 months to a year that BDS can afford to ... Developers need time to learn new things and to figure ... MS can just kill interop when they want and then it's going to be ...
    (borland.public.delphi.non-technical)