Re: Delphi Product Manager questioned

Andrea Raimondi wrote:
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.

I think it's certainly a factor, but it's not the only factor.

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.

You missed my point. The point is when a consumer buys something, all
that matters is the quality of the product. The internal processes of
the company that produces it are irrelevant.

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

I'm positive too, just not about Delphi for .NET.

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

I don't know why we have this lag, but I think it's a combination of a
few factors including that it's a tough and large job to support .NET 2.0.

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

I'm not sure if VS.NET actually profits at all, but the point is that
VS.NET is the most popular IDE for .NET. IMO, it's also the best for
..NET development.

However, VS.NET means *lock-in*, while Delphi means choice.

To me the choice of Delphi is effectively a "lock-in" to Windows
development. IOW, when people want platform choice, they'll use
something like Java.

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.

Sure, but the process of adoption also includes trying of those new
things, learning what has changed. I don't buy the argument that
because adoption might take 6 months to a year that BDS can afford to
lag that long. Developers need time to learn new things and to figure
out how that adoption process is going to actually occur.

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".

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

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.

Maybe, again, I don't think this is a big selling point. Most
developers expect some pain when upgrading from one version of a
framwork to the next. I know I do.

Again, from the Roadmap you can't really tell what is going on.

I think you can tell more from the Delphi roadmap than the JBuilder one. ;)

Maybe the smartest people can come up with things that we can't
come up with.

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

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.

That's perhaps one minor example. Look at the big picture, .NET is far
far better than Win32 and COM, etc.

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.

But at the end of the day these are just excuses. BDS must find a way
to compete even with these constraints.

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.

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?

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.

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

P/Invoke is pretty much a hack by MS to avoid complete refusal from
developers to adopt it.

I think it's a practical solution for a problem MS recognized from day one.

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.

You are missing my point again. I could have easily thrown the 64-bit
compiler support and made the same point. Would you then reply that the
64-bit compiler is on the RoadMap (which apparently to you provides
little or no meaningful insight into BDS' long term strategy)?

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.

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?

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.

I don't understand 4 and 5 is ridiculous. The rest I don't think are
significant at all. What competitive advantage does it give you?

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

Well, what I was refering to is that interop will inherently use unsafe
code and thus will be more difficult or less secure to deploy. Thus
there is an advantage to having pure .NET code. The problem is that
Delphi for .NET has some issues with that!

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.

Give me the concise easy-to-understand, easy-to-justify list. You know,
like the ones we could use in the Win32 world.

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.

Well...you can buy Together modeling for VS.NET if that's your thing. ;)
Regardless, you have pointed out exactly one advantage: ECO. But
balancing that with the many disadvantages, I don't think it's enough.

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

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

I instead don't understand this - irrational, from my POV - gloom and
doom about Delphi.NET future.

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 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.

I don't think you're looking at it objectively.

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.

:) I think BDP makes little sense...

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.

I wasn't worried. I'm not a doom/gloom kind of guy. Don't confuse
serious concern and inquiry as doom/gloom.

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,

In my experience if a manager wants to move it to .NET, they are going
to feel more comfortable with VS.NET anyway. At this point I would too.

it may even make sense to have both a
native and managed version of the same application to satisfy a larger
market.

IMO, end users don't give two craps about the technology used. They
care about features, what the UI looks like, etc.

This is much easier to do with a single source approach and
appropriate programming(i.e. use of interfaces, business objects, etc).

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

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?

How well did that work for Linux? ;)

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.

I disagree. I think it would be irresponsible not to retest when moving
from Win32 -> .NET even with single source. With interop, you have to
retest the interop layer, but since the code is running on the same
platform, I would have more confidence that things that did work before,
will work again.

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

Anything is possible. Everything is not a good idea.

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.

Yes, I did.

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.

True, they are sunk costs, but you don't put good money after bad.

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.

You missed my point about pricing. It's not important to understand the
justifications for the price difference. My point is that they already
don't have any price play to push costs out to their customers. If
anything, I think they need to lower prices.

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?

You're underestimating the cost of the .NET insurance premium.

"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

They certainly won't if this community doesn't invite them or treats
them without respect.

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.

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

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.

If performance is adequate on the Win32 side, what difference does it make?

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.

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

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

So you have inside informations?

No, I have none. But to say the RoadMap doesn't provide an indication
of BDS' long term strategy is foolish.

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.

I'd love to hear their ideas. This is why I'm asking for ideas, but so
far the only ideas that you have is more of the same and trust DevCo.
Not exactly giving me the warm and fuzzies.

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.

But that's what I'm asking for. Regardless, I don't know much about
Peleton, but IMO, integrating NHibernate doesn't intice me very much.
IOW, you can use NHibernate with VS.NET just fine. It's not significant
enough.

The distinguishing things have to be something that you could do in BDS
that you can't do with VS.NET. Or it has to be something that everyone
does that is painful with VS.NET that is super easy with BDS.

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.

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

--
Brian Moelk
Brain Endeavor LLC
bmoelk@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
.

Relevant Pages

  • 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: 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)
  • 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: How can you drop Winforms support?
    ... Being able to use that shiny VCL Office 2007 Ribbon Bar from ... The support for WinForms in Delphi ... Get 3rd paty developers on board with a partner VCL.NET program with the idea of a coordinated release of the VCL.NET IDE and VCL.NET 3rd party ports to get an initial influx of the biggest 3rd party names. ...
    (borland.public.delphi.non-technical)
  • Re: How can you drop Winforms support?
    ... I'm not certain you've provided any reason for those third party vendors ... that VCL simply cannot. ... The product was not in great shape (Delphi 8) ... meant no developers, which meant no components, and so on. ...
    (borland.public.delphi.non-technical)