Re: Delphi Product Manager questioned

Andrea Raimondi wrote:
I've always thought of software as a quite different market where
"normal" rules simply don't apply, starting with things like
eulas or free tools. I still have to see a shop really giving away
something for free except in the software world.

IMO, software is a business just like anything else. As a consumer of
developer tools, I don't care about this kind of stuff:

It's a tough and large job all you want, fact is however that they have
been delayed by ever changing betas first, the leave of a key person,
the fact they've gone through underfunding, etc, all contributing
factors to the current situation.

I just want my tools to work well. If Borland can't deliver value to
me, why should I care about their internal challenges? On the other
hand, if a company does deliver value do you care at all what's going on
inside?

Sure it may be interesting to ponder these things and important to
understand these things, but at the end of the day I choose to use the
best tools I can find.

"Profits" was a bad picked word. "Capitalizes" fits more.
It's the "best for .NET development" if you're on new projects, want a
lock-in in Windows and use only MS technology. Then yes.

BDS doesn't lock you into Windows? Come on Andrew.

From what I can see, there're many successful cross platform projects
based on native code.

Most are C/C++. ;)

Well, to be adopted they need to be understood by the tool provider
first. It's surely not easy but I think it can be done and again,
DevCo guys have always popped out with very cool things to have.

Again, if my competitors are using VS.NET, they will have much more time
than I will if I choose to use BDS to learn the most recent stuff. How
is that a competitive advantage to *me*?

That's not what I've seen. I think the 2.0 adoption has been very rapid
indeed.

Framework release: Oct 2005

Paint.NET: Feb 2006
DotNET Nuke: Apr 2006
Subtext: On the roadmap(not yet ported)

If I looked for more I could probably find other examples.

Those are interesting examples...open source projects typically move
slower because they are done in developers spare time; how about looking
at companies and internal IT usage.

http://www.ftponline.com/channels/net/reports/vslivesf/2006/soma/

"Somasegar also provided an update on the acceptance of Visual Studio
2005 since its launch on November 7, 2005. Ten million copies of .NET
Framework 2.0 have been downloaded, and Somasegar claims this is the
fastest adoption rate seen so far for a new or upgraded runtime."

Why do you think I'm asking all the smart people on non-tech? ;)

They may still have no answers to the points because, again,
DevCo might have things we're not aware of.

I'm not looking for *answers* I'm looking for *ideas*.

So you know a lot of developers using Delphi for .NET? You know a lot
of developers that actively *choose* and *recommend* using Delphi for
.NET? In starting a *new* project, which most of .NET projects are, you
would choose to use Delphi for .NET?

If I couldn't go the native route, yes I would :D

We totally disagree on this point and I think you're in the minority on
this one. Almost all of the Delphi developers I talk with are quite
content with using C# for .NET development.

Again, at what cost to DevCo? Do you think they are reaping appropriate
ROI?

I haven't got the foggiest idea if they are, but you're not either.

I don't have any evidence, although I'd like to see the evidence, I'm
not asking for evidence. I'm asking you what you *think*, which I'm
quite happy to acknowledge is completely speculative.

The roadmap just states what's in the works, not how they're going to
accomplish it, and the latter is what makes a strategy, in my book.
Nonetheless, your book could be different.

No, strategy is a plan of action; tactics are how a plan is carried out.

Exactly. But where do BDS customers want to go? What are they using
now and what things do they want to be using in .NET?

As others have pointed out, there're many customers in the Delphi world.
What I really don't understand is why you keep saying it's not a viable
option when we don't have the "numbers" to say the trends.

I just don't understand the reasons for Delphi for .NET. Those reasons
that have been given, IMO, are not significant enough.

I'd love to see any numbers that prove my intuition wrong, but I'm
asking to be *sold* on the concept of Delphi for .NET not to be told
that my intuition is wrong and that I don't know the numbers and to
trust that DevCo will produce something great that I'll love and that
it's all MS' fault that BDS still doesn't support .NET 2.0, etc.

I'm growing tired of hearing that kind of stuff. Sell me; I'm currently
a happy Delphi customer, a captive use of BDS. I'm DevCo's target
market here and I can't see the value in Delphi for .NET. Make me see
the value...sell me.

You don't understand 4, fine, I'll expand on that: people change jobs,
applications evolve, etc.
Having a "static" piece of software that doesn't get mantained means
that "no one" will ever look back into it, inherently this means nobody
will be able to understand that code and it'll be in the end killed.

That just doesn't make sense. If the software needs to be maintained
what difference does it make if it's in Delphi for .NET or Delphi Win32?
IOW, that's not an argument for using Delphi for .NET over interop
techniques.

You consider 5 ridiculous now, but I'm not so sure it really is
going to be in the long run. After all, MS has a well proven track
record of this kind of things.

It is ridiculous because MS made it one of .NET's design goals from the
very start. That's like saying that multiple language support is great,
but be afraid, MS will pull it.

Again, there're several things that make up Delphi.NET part and I'm not
sure we've seen all of it yet.

That's what I'm hoping to get some ideas about...those things that we
haven't seen. Got any ideas or are you going to continue to tell me how
wonderful Delphi for .NET is?

I agree, but VCL for .NET isn't a strategic asset. Neither is Delphi
for .NET IMO.

Brian, sorry to be pedantic and repetitive, but what official *numbers*
do your claims come from?

I never claimed to have any numbers. I'd love to see them, but numbers
has nothing to do with capturing mindshare of developers. I want to be
waiting with bated breath for the upcoming releases...which ITO Delphi
for .NET I'm not at all.

Perception is a great thing, except it's not reality.

Developer's perception is reality when they go to start new projects,
make recommendations about toolsets, learn new skillsets, etc.

IMO, it's not irrational. I'd love to be as optimistic about Delphi for
.NET and BDS' .NET support as I am about Delphi Win32, but I'm not.

I think it's too early to make such definitive statements, I'd rather
give DevCo a chance.

IMO, we've given the Delphi for .NET strategy 3 versions to flourish. I
will certainly give DevCo a chance, but my point is that I don't believe
their existing .NET strategy is working. If they can't possible earn
mindshare among Delphi developers, there's no way they can compete long
term at all when it comes to sales and market penetration.

Mmmmh... you see, "objectivity" is very hard to achieve, especially
when things have yet to happen. Again, I'd rather give DevCo a chance.

ISTM, the same .NET strategy has been in play since Delphi 8, which was
released Dec 2003. It's now June 2006, almost 3 years later and IMO
there is only one reason to choose BDS over VS.NET (ECO) and a whole
bunch of reasons not to. That's the "objectivity" that I'm talking about.

You haven't given me any reasons to use BDS rather than VS.NET. Faith
in DevCo and giving DevCo a chance and historical precedent of Borland
being able to deliver compelling products are not good enough sorry.

Delphi.NET is here since a relatively short time and mind you, I am not

Nearly 3 years is a short time? .NET was originally released in Jan
2002. .NET is more than 4 years old.

saying you're certainly wrong, I'm simply saying that maybe we should
first see what *DevCO*, without the Borland burden can do.

But if what they have planned for Delphi for .NET on their RoadMap isn't
of interest or is too late compared to VS.NET, then why should I see
what DevCo has to offer here? Why shouldn't I just use VS.NET.

The point here is that I'm very interested and hopeful about what DevCo
can bring to the native side of BDS. I think it's going to rock. But
on the .NET side, I'm less interested/hopeful because I think their
fundamental strategy is flawed.

I'm all for single source; but I'm also for DevCo being able to compete.

There's no proof that DevCO won't be able to compete.

The "proof" is in the last 3 releases.

You don't need to retest *everything*, just the parts which were
subject to change. [...]

The whole underlying platform just changed. IOW, everything has changed.

That's simply ridiculous...many are moving to VB.NET or C#.

Except those who have *literally* millions of dollars in invested
code. Those aren't going anywhere, and I can tell you for sure.

I think you're making my point here about the value of Interop.

The difference is that some shops are choosing dotNET as a platform and
this has to be taken in consideration.

I am taking that into consideration, I think BDS should continue to
support C#.

WPF support? VCL for Avalon? I'm guessing those aren't exactly trivial
endeavors.

Again, there've been several "not trivial endeavours", yet Delphi
managed to play in the field.

Delphi for .NET is *not* a player in the .NET space IMO.

I agree that more information would be welcome, but I guess it's not
going to happen anytime soon. Till more information doesn't come out,
it's arguable to say "kill Delphi.NET".

Andrew, let's get this straight:

1) I'm asking the community for ideas. If DevCo wishes to add to the
discussion they are free to do so, but I don't expect them to.

2) I'm not trying to be argumentative or provocative. I'm trying to
come up with a reasonable and attainable strategy for DevCo and the way
they can compete in the .NET space. IMO, they haven't been successful
in the past.

3) In no way am I "happy" about throwing out the idea of discontinuing
Delphi for .NET. I'd love to see Delphi for .NET, VCL for .NET, VCL for
CF, ECO IV, etc. All of those things they have on the roadmap. I'd
also love to see Kylix started up again and have it work on every Linux
distro out there. I'd also love to see DevCo roll in a VB dialect or a
Common Lisp environment or Smalltalk.

But, the reality is that DevCo can't do everything. They can't be
everything to everyone in the development world. They have to pick and
choose their battles in terms of what will bring them the best ROI and
deliver value to their customers. In business tough choices have to be
made and I think it's time for those decisions to be made regarding
their .NET strategy.

However, the point is not what *I* think, but what they'll do and
right now there's not enough information.

But that's what I'm asking for...is ideas about what *you* think they
should do with their .NET strategy. If you think they should simply do
more of the same, that's fine, we don't have to have any more discussion
on the matter.

Sure, but that's why I'm asking the question. So far I've heard very
very few points that I think are credible.

What *you* beleive credible is different from what *I* beleive
credible. I don't know who's right(we could both be wrong after all),
but I'm willing to discover :D

It's not about what's right/wrong. It's not about our different
criteria. I'm asking to be sold on the concept of Delphi for .NET or an
easier sale: why should I use BDS for C# development. Give me specific
reasons not anti-MS/pro-DevCo rhetoric.

This is the situation. I'm not at all sold on Delphi for .NET and I
don't think many developers are...including existing Delphi developers.
No, I don't have any numbers, it's a mindshare thing.

From what I can see, those that have embraced .NET are doing so in C#.
Which is exactly what I would do as well, which means that the choice is
between VS.NET and BDS. Right now, I would choose VS.NET over BDS
because it has more compelling features/capabilities.

I'm getting frustrated explaining this over and over again. I want to
choose BDS so give me some reasons to do so.

P.S. The post hasn't been triple checked, it's late Sunday here and I
might have written one or more "not quite on target" things, so
please bear with me.

I don't think we should bear with each other anymore unless you want to
throw out some crazy ideas about what DevCo could possibly do with
Delphi for .NET. I'm feeling like we're treading water here so enjoy
the rest of your weekend. ;)

--
Brian Moelk
Brain Endeavor LLC
bmoelk@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
.

Relevant Pages

  • Re: Captain Jakes Top Ten List of what Id like to see in thenextversionofDelphi
    ... I must have missed all the Delphi developers talking about how Delphi ... more productive than what Microsoft is offering. ... it's hard if DevCo doesn't build on top of WinForms since I don't ...
    (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)
  • Re: Turbo Delphi... Why ? :(
    ... developers that were the key target for Borland for the past few years. ... complexity fo the BDS. ... What are differences between Delphi 200x and Turbo Delphi? ...
    (borland.public.delphi.non-technical)
  • Re: Turbo Delphi... Why ? :(
    ... language will they be using - C++, Delphi Win32, C# or Delphi .NET. ... So you will never need to use more than one language at a time? ... The thing is, BDS satisfies some of our customers needs, and Turbos ... In addition - NEW developers and students how ...
    (borland.public.delphi.non-technical)
  • Re: Delphi Product Manager questioned
    ... DevCo will improve both management and funding, but as a consumer, these ... I mean, we've had several wonderful Delphi releases, as well as *way less* than stellar ones. ... and R&D resources MS is pumping into .NET and VS.NET. ...
    (borland.public.delphi.non-technical)