Re: Delphi Product Manager questioned

Brian Moelk wrote:
Additional funding doesn't make management better. I do believe that
DevCo will improve both management and funding, but as a consumer, these
are merely excuses.

Well, not quite, when bad management and insufficient funding hurt the
product that badly. If "we" are in this situation, it's mostly due to
that.

But that's just it, it doesn't matter. They are *internal* problems and
are ultimately excuses. I understand that things are going to get
better, I'm just not convinced that even when things are better they
will be able to compete if they continue doing what they have been doing
in the .NET space. In the native space, I'm thoroughly excited.

I don't agree on this. I mean, we've had several wonderful Delphi releases, as well as *way less* than stellar ones.

When things were "right" we mostly had great releases.

Now things are going to be straightened again and I'm positive.

.NET 3.0 is still going to include things that aren't slated for support
in Highlander. I think the transition from 2.0 -> 3.0 might be less
work intensive, but I think everyone agrees the lag is unacceptable.

The lag we have now is due to *well known factors*.
This is going to change and it'll be *definitely* better.

Disagree; they could have been much more aggressive with their support
of .NET 2.0. Certainly resources and management play a huge role in
that, but those aren't the only things. Again, this is a real problem
and blaming MS for a huge mess doesn't matter when VS.NET is a viable
option.

VS.NET profits from the monopoly position it has and from the far
greater number of developers.

However, VS.NET means *lock-in*, while Delphi means choice.
I know it's sometimes frustrating not to be able to try the very new
things that are available to VS users, but that doesn't change the
very fact those things also have to be adopted and integrated.
This in turn means that code evolutions won't take place so
easily and this has been the case with dotNET 2 as well, where
most of adoption has been pretty much "late".

It's also worth considering there's been quite a few voices
saying that ASP.NET 2 makes a mess with ASP.NET 1.1 projects' migration,
thus maybe it's not all roses and flowers and BDS R&D team might
well want to make this process smoother.
I beleive this is an area where big things are in the works.

You can have the smartest and hardest working people in the world on
your team, but without a strategy that makes long term sense, there's no
point.

Again, from the Roadmap you can't really tell what is going on.
Maybe the smartest people can come up with things that we can't
come up with.

Disagree, I think MS has clearly demonstrated that it's doing a better
job with .NET than it has with Win32 or COM or anything else if you look
back historically.

One example: they messed up ASP.NET 1.1 migration in 2.0.
Looking around the web you can find many voices whining about this.

I think they have continually invested in .NET and the schedules that
have slipped are something that DevCo cannot count on if they want to be
competitive.

Well, I'm not saying they can count on them, rather it's a hurting
factor, because they can't just recode everything for the changes MS
does in its betas and that's part of the reason of the lag.

It's not only funding/focus, it's the fundamental strategy. Don't get
me wrong, funding/focus will help but no matter how much funding DevCo
will have, I cannot imagine they will be anywhere close to the funding
and R&D resources MS is pumping into .NET and VS.NET.

That's granted, but old Borland could do outstanding things with
lots less funding. Even in recent years, they have demonstrated it's
possible to do wonders with a very low budget.

Is it? Almost all the BDS developers I know and have heard here are
either using Delphi Win32 or C#/ECO. The rest are using VS.NET.

USA situation is remarkably different from the rest of the world in
Delphi's usage and investments.

And he could probably have done the same with interop techniques that
would strain much fewer R&D resources to support.

Interop tecniques have sense where you can't have "source level"
compatibility. With Delphi this isn't the case and it has much
more sense to have a language in its own merit.
P/Invoke is pretty much a hack by MS to avoid complete refusal from
developers to adopt it.

I understand the specifics about unicode, what I'm asking is how much
you'd be willing to sacrifice for the .NET insurance policy? IOW, given
limited resources, where would you allocate them? On a possible, but
IMO short-term improbable, scenario where one must have .NET code or
something *like* unicode (not necessarily unicode) which is important
*today* and could deliver *more* value and ROI.

As others have correctly pointed out, dotNET doesn't do universal
unicode support(although many people still use and will use W9x) either.

You have *today* TNT Controls doing Unicode(and I agree that DevCo
should support them in some way, if you ask me) as well as
other components.

So in that case Win32 has a long...long life ahead of it. ;)

It just means that it'll take some time to get to deliver, but
doesn't imply that MS will stop pushing dotNET.

But why is a shared source approach preferable to an interop solution?
(I'm waiting for someone to mention .NET security ;) )

It's preferable for several reasons:

1) You already know Delphi
2) You don't lose your "knowledge" while still being able to
evolve the code as it matters
3) It's a more direct approach
4) You'll end up "losing" the knowledge using Interop because
programmers change: having an updatable source means that
knowledge won't be lost.
5) MS can just kill interop when they want and then it's going to be
*very* tough.

As to the "security" in dotNET, there're ways to use unsafe code,
thus you can still do "bad things".

And I think that's a problem. If customers don't have a clear and
coherent grasp of their long term strategy and can't easily justify a
products use by a concise list of significant advantages, then BDS for
.NET is going to die.

I think that you're missing a huge point here: BDS has built-in parts
that will ultimately play a big role in the future.
Just to make an example: Together modelling.
Ok, it's far from being optimal, but they already built on top of it to
support ECO. This can happen again, for example, in the context of
Windows Workflow Foundation.

The platform is there, imho, it just needs to be built on top and
tuned to evolve with the technology.

I don't share your confidence in this regard. I have great confidence
in DevCo in other areas, but their long-term .NET strategy especially
revolving around Delphi for .NET and VCL for .NET I think is flawed.

I instead don't understand this - irrational, from my POV - gloom and
doom about Delphi.NET future.
I am, however, very open to change mind if that is going to be the
case.
For now, however, I don't see a *good reason* to gloom and doom
about it.

ECO is the only thing they've got AFAICS, and that totally negates the
migration benefit anyway.

Not quite, sorry, we disagree here again.
I'm thinking of things like DataHubs or BDPs.

Perhaps, but I'd like to know. I'm willing to be patient, but at this
point, I can't and wouldn't recommend BDS for .NET use.

Few months ago there was gloom and doom for the depart of Danny Thorpe.
On that occasion, I highlighted that the roadmap had probably taken into
consideration Danny's departure before being published and it was
confirmed by Steve Threfethen.
I beleive this is the case again.

Delphi.NET is an insurance that if tomorrow your biggest client
comes over and says "hey, can you please move our app to dotNET?",

How often does this happen?

Well, according to customers and/or management, it may happen once or
more than once. After all, some managers just buy things according to
absolutely irrational factors, it may even make sense to have both a
native and managed version of the same application to satisfy a larger
market. This is much easier to do with a single source approach and
appropriate programming(i.e. use of interfaces, business objects, etc).

After all, this has been the case for Delphi 6 as well, where you would
have a single source to do both Windows and Linux(and it worked), so why
wouldn't it work again?

I think you're minimizing the effort here. If it's purely a business
proposition, again what's wrong with interop?

Using a single source you don't have to retest everything because it
already works and you just need to make sure things are treated
appropriately.

The very fact they could come up with a VCL.NET does demonstrate
that it's after all possible to have a single source.

lol...it's expensive to DevCo and I don't think they can't afford it.

I assume you meant "I don't think they can afford it" here.
However, most of the investment has been already done, the
language is there and infrastructure is there too, imho it'd be
simply pointless to make it dead.

They can't push those costs out to their customers either since they are
already priced higher than VS.NET.

Well, they're priced higher because they can't afford to do like MS
does, although lowering the SKUs prices *might* make people buy more
copies, if not for anything to explore it.

Not if it means that I can no longer compete, or if it were cheaper to
build out replication and have two data centers.

You're not considering the price of fixing the lost datacenter or
make a new one. How does it do now?

I think you're missing my point about Win32. It's all about limited
resources and how one allocates those resources. Regardless, if MS
doesn't want to continue playing the Win32 game, it's better for Delphi
Win32. Get those VB classic guys on board.

"Those VB classic guys" (makes me wonder why you didn't include girls as
well <g>) for the most part *won't ever jump ship* to Delphi, just
because they're either uneducated or unwilling to learn how to
program. Instead, they'll use VB6 until they can and then use Interop
like you'd want us to do with Delphi and finally rebuild things from
scratch in C# because the interop is either impossible or being
dropped or simply too sluggish to compete with JITted code.
The latter is another important point to have a Delphi.NET
language: dotNET is bound to improve its performance sooner or
later. I beleive it being sooner though, because of easiness in
doing threads and the uproar in systems' performances in the
64 bits field.

LOL, as if Gates doesn't have a long-term vested interest in MS.

As he himself stated, he's going to leave the guide roles he now has.
This means that, although he surely has and will have a heavy word in
decisions, his might not be the last one after he leaves the guide.

I agree, but what do these things have to do with DevCo's long term .NET
strategy?

It has when you look at all the things DevCO has in the VCL.NET for
server development.

It's adding *one* layer, and although it might not be "convenient" it's
certainly effective and in many cases a reasonable solution to the
problem.

Er... I'd fix the sentence by saying it's *one more* layer on top of
what might already be there, just think of component wrappers around
COM objects for example.

IMO, it would have taken DevCo far less resources to make interop
convenient than it did DevCo to build out code compatibility with Delphi

DevCO has *already* made interop convenient. You can in fact create a
"library" in Delphi.NET which is just that.

for .NET and build out VCL for .NET. Certainly these things are sunk
costs, but in terms of ongoing costs, I'm not sure it makes sense. Look
at what's planned for VCL for Vista and things like that...albatross.

Just a consideration: what is planned in the VCL for Vista is
probably based on what is being developed now.
That's why I disagree completely here.

I have some clues about what this strategy is about. Some of it is on

So you have inside informations?

the roadmap, some of it is a logical extension of what they've done with
Delphi in the past. What I see is what I'm claiming is a flawed strategy.

Again, the smartest people working for DevCO might come up with
things we can't think of and what is a "logical" extension for you
doesn't necessarily is "logical" for them - who may have one thing or two in their pocket that you're unaware of.

Ultimately it looks like more of the same to me, but I'd love to be
pleasantly surprised. If anyone has *any* ideas besides "more of the
same but with more funding and resources and better marketing", I'd love
to hear it.

One idea I'd pursue is to leverage frameworks for dotNET that are out
there already, much like they're doing for Pelothon.
I'm thinking of NHibernate, for example, creating custom modules for
dotNETNuke could be another good thing.

But these are just ideas thrown in the wild.

I think we can make assumptions as long as we recognize they are
assumptions. But it's not about assumptions, it's about ideas.

Ideas are based on assumptions, otherwise you have no ground to
throw them.

I've been trying to rack my brain about what DevCo can do differently to
get an edge in the .NET space and there's no clear cut winner there.

The fact we can't see it doesn't mean it's lacking.

Agreed, but I'm afraid it is probably too early for them to do so.

They can't surely go great lengths, but it's possible they could say
something.

Cheers,

Andrew
.

Relevant Pages

  • Re: Delphi Product Manager questioned
    ... Additional funding doesn't make management better. ... DevCo will improve both management and funding, but as a consumer, these ... MS resources will continue to dwarf DevCo's. ... job with .NET than it has with Win32 or COM or anything else if you look ...
    (borland.public.delphi.non-technical)
  • Re: Devco to encourage VB users to migrate to Delphi
    ... of imagination and lack of funding. ... My concern is that Devco may follow suit. ... The resources required to make Delphi go are ...
    (borland.public.delphi.non-technical)
  • Re: Delphi Product Manager questioned
    ... Borland and DevCo think it is a good idea to spend their main ... resources for the next two years and Delphi releases on the .NET side ...
    (borland.public.delphi.non-technical)
  • Re: ruby on rails
    ... I'm describing a strategy to keep the IDE business profitable. ... So it is about DevCo, not Borland. ... I'm not a soldier in the holy war of Delphi. ...
    (borland.public.delphi.non-technical)
  • Re: Delphi Product Manager questioned
    ... BDS doesn't lock you into Windows? ... DevCo guys have always popped out with very cool things to have. ... Almost all of the Delphi developers I talk with are quite ...
    (borland.public.delphi.non-technical)