Re: How can you drop Winforms support?

Randy Magruder wrote:
You can if you like, but it's such a basic common-sense assumption that
it seems like a waste of time to raise it continuously, or do you know
anyone here who thinks that 3rd party components should be produced out
of the goodness of the vendors' hearts?

I'm not certain you've provided any reason for those third party vendors
to do so except the goodness of their hearts.

Hardly. "Significantly better" includes the underlying framework that
it's based upon. Do you really think I don't realize that .NET might
offer something different/better than Win32? I might be your nemesis,
but I'm only your nemesis because I'm not an idiot.

We're resorting to name calling? Gee, I expected better from you...

Who am I calling a name? I stated that *I'm* not an idiot.

The real question is if VCL.NET can actually *leverage* it better and if
CodeGear is going to be willing to break compatibility for forward
progress.

Define "leverage" as used in the above sentence.

Leverage = utilizing it. The more interesting term to be elaborated
would be "better".

Something that could be better is if VCL.NET leverages WPF in a nice way
that VCL simply cannot.

Sure, but you're neglecting the fact that interop solutions exist today.

In my opinion, Interop sucks. But that's just me I suppose.

So does COM...but it works.

It's far easier to use Interop to sprinkle those good .NET bits into an
existing VCL Win32 application than it is to port the whole application
to .NET.

The only reason it is hard to port the whole thing to .net is the
components. Unless you are writing really low level pointer-based code
or going crazy calling Win32 stuff, your typical business application's
biggest problems are going to be with 3rd party components, and NOT with
your application level logic. So if the components exist for both sides
of the fence, it removes the single biggest obstacle to 'porting'.

I address the whole porting insanity later...testing is a big one.

This benefits the end user how? Better performance? As you well know,
performance is more about how one writes their code.

I'm throwing it out there as a hypothetical. Pick any particular
'reason' you want why someone would want a .net application. Heck it
could be political in nature ("we must have a .net product right now,
it's a feature checkmark", saith the trendy Dev Manager). I don't care
WHAT the reason is. I'm just saying pick any reason that you might want
to use the underlying

The reason is important though. Like I said so far, there hasn't been a
compelling reason for Delphi developers or third party vendors to
embrace VCL.NET. I don't see this changing drastically.

Which the Delphi *market* has clearly *rejected*.

This is far too simplistic of a comment. You think the market rejected
the idea 'in theory' or 'in practice'? There's a big difference.

IMO, both.

Something that sounds like a great idea, when poorly executed, will get
rejected.

Definitely.

Delphi.NET has, up to this point, had a LOT of things going
against it, totally aside from whether it is a good idea:

1. The product was and is stuck in .net 1.1.
2. Microsoft hype-wave towards WinForms as *the* way apps are supposed
to be developed
3. The product was not in great shape (Delphi 8)
4. The support for WinForms in Delphi (may have actually HURT things by
re-inforcing the idea that WinForms, not VCL, was the future-- even for
Delphi programmers, who might then just say -- well why not then just
switch to VS.NET ?!)
5. The chicken 'n egg loop of 3rd party components. Borland should
have had 3rd party vendors on board and releasing VCL.NET versions of
their stuff from day 1 to give Delphi coders an incentive to move
development to Delphi.NET. They didn't, there were no components, which
meant no developers, which meant no components, and so on.

I'm not so sure that the "idea" was so hot either, but certainly those 5
are part of the reason why the execution sucked.

These and undoubtedly a few more all contributed to make Delphi.NET a
ho-hum proposition at best. Something that was (and is) a great idea IN
THEORY got torpedoed IN PRACTICE by poor execution and an unclear
strategy. If we could turn back time and do the Delphi.NET launch
again, it would have been:

1. VCL.NET only
2. Unicode support
3. Up to date with whatever version of .NET was out there
4. 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.
5. New classes that would match functionality people like in FCL
(container classes, XML classes, etc).

IMO, this still wouldn't have been enough. It's not enough to do "just
as good"; it has to be significantly better than what is offered on
Win32 VCL.

This is why many using pre-.NET VS couldn't wait to dump the MFC and VB
to get .NET.

Had they done all these things and EXECUTED them well, I think Delphi
VCL.NET would have been a NATURAL option for Delphi developers, not the
problem it has been.

Why though? What difference would it make to the VCL developer? Even
if you take those 5 items, perhaps unicode or perhaps FCL class wrappers
would be enough...but I'm still skeptical.

You believe at this point it's too late for
VCL.NET.

Yes.

I couldn't disagree with you more strongly.

Surprise, surprise :)

I suppose you can
resort to calling me names again if you like....

What name did I call *you*?

but I think I made my
point very clear here.

Really?

WinForms and to some degree C# were diversions
from what should have been a well executed Delphi-centric,
VCL-on-any-platform strategy. CodeGear now realizes this, and also we
realize that WinForms wasn't the holy grail it was hyped as being, and
those two combined perhaps make for a climate more hospitable and
resistant to the Microsoft hypewave than in the past, when MS was
basically saying that all its OWN products were going to be .net based
(right down to the operating system!). Microsoft couldn't have scripted
a better headfake than they did in getting the rest of the development
community to get off balance.

Ok, so will you make a wager based on the future of VCL.NET? I'll bet
that it will flop.

I'm saying that it hasn't been *enough* of an advantage for VCL.NET to
be a highly desired item.

I would say the same argument could then be made against WinForms/WPF.

Winforms and WPF are different. From a Delphi developers perspective in
regard to WinForms, yes I would make that argument and actually say it's
worse than VCL. Most Delphi developers just stayed with VCL. Those
that went to WinForms, chose to use VS.NET and C#.

In the case of WPF, I suspect there is enough eye candy there to
convince people to adopt it...unfortunately we don't have .NET 2.0
support and will probably lack WPF designers.

I think there is still some vestigal fear about the security in
continuing with native development. On a technical level, Delphi native
might win many arguments. At a broader, less technical level, it might
not. We have gone from Microsoft promising .net for all to Microsoft
moving ahead with more native code support (such as the Steve T's
arguing it out in blogs).

There might be some fear there...who knows; everyone makes up their own
mind. But you yourself said that "Right NOW, I have no compelling need
to move my native code to .NET. " If that's not testament to how
appealing VCL.NET is, I don't know what is.

But do we really KNOW for sure that all the
framework goodies Microsoft will add will be readily accessible to
native code? No, I don't think we do.

MS' main language is C++. If Delphi had followed C++ more closely, we
would have to worry about obsolescence to the degree that Office would.

Microsoft can, at any time, make
life miserable for native coders wanting to do this or that Vista thing
or this or that WPF thing, or whatever. That puts native code
developers in a somewhat precarious position. I honestly just have my
doubts about whether we'll even be able to get access to some of the
higher level framework technologies Microsoft is putting out.

Interop, mixed-mode compiler. They aren't going to isolate C++.

What
about Silverlight ? What's its place out there for native coders?

None. It's interesting, but there's no place for it with Delphi for
..NET either. I doubt MS is going to distribute Delphi for .NET with the
standard distribution.

If anything Silverlight might be your best example to how all other
languages besides C# and VB.NET or the new DLR languages are going to be
second class citizens.

Microsoft continues to roll out their dev technologies as ..net, .net,
.net. And even if they do surface native API's, will it be done in a
timely fashion? There may yet be a need for developers to move
something into the .NET space to take advantage of these things, and I
honestly don't think many besides you are fond of interop solutions.
If I may be so bold, it's easier to develop and debug one body of
compiled code than be hopping across interop boundaries all the time,
and that's assuming no performance issues.

IMO, it's really simple. Delphi's .NET strategy: do what MS VC++ does
but make it better and easier to use.

Well, it's not like Kylix because Windows .NET and Windows Win32 is
still Windows. Linux is a different market entirely and is more
suitable for server applications than desktop ones.

Obviously. Don't get sidetracked onto which platforms I picked.

But they are highly relevant because they go to the nature of .NET.

Point
is, the platform can be a separate decision than the UI, and one doesn't
constrain the other. That's all I'm saying....and I think you actually
KNOW that.

If I want the *best* UI, I'm going to choose native tools for the
platform that I'm targeting. Call this the Skype strategy to cross
platform client development.

If I want to ease the cost of development and go for something that is
cross platform I'm going to use something that's cross platform like
Java. It might not be as nice, but it's good enough.

That's hilarious, you use VCL.NET so that you can be "pretty confident"
that your application will look as good as your VCL application? Why
take the risk at all?

Well, if your attention span exceeds the last paragraph, because I was
ASSUMING there was some underlying reason for changing platforms from
Win32 to .NET. ASSUMING this is true, then the UI component issue
ceases to be a deal breaker. You act as if the above paragraph was
spoken in a vacuum.

I definitely think UI components, how they look/feel could be a deal
breaker. This is one of the biggest reasons to use VCL, and third party
components. They look and feel great.

If we're talking about *real* cross platform development, like I said
before I agree...but if we're talking about Windows .NET and Windows
Win32...no. There is no substantial difference to the end user and they
don't care.

Someone has to make VCL.NET *more* compelling which means breaking
backward compatibility with the VCL for *forward* progress. Otherwise,
there's no point at all in VCL.NET, might as well keep going with VCL.
Economic incentive.

One might pose many of the same criteria you posed upon VCL.NET upon
WinForms and finding THAT technology falling flat on its face.

For the Delphi developer, this is exactly right. Which is why most of
them just stuck with Delphi Win32.

What,
honestly, is more spectacular about WinForms than VCL? So I can buy a
WinForms DevEx quantumGrid and ribbon bar instead of a VCL DevEx
quantumgrid and ribbon bar and use generally the same exact rad approach
to writing my app? If you can't make a case that WinForms is superior
to VCL development and worth jumping over to, then of course you're
going to have the same problem with VCL.NET.

Exactly. For the Delphi developer, I can't make that argument for WinForms.

Yet lots of people jumped
to WInForms...call it Shemitz's "learn once, write anywhere" if you
like...or just Microsoft's managing to scare the world into thinking
they better move to MS .net or fall behind, but based upon being a
superior development solution? I haven't seen that for WinForms.

Not sure if *lots* of people jumped, but a few did sure. I think most
that did were VB and MFC guys.

I'm not going to sit here and tell you that VCL.NET is where it needs to
be. It's not....absolutely not.

Ok good. :) We can agree on that point.

But as long as there is a significant
# of Delphi Win32 developers world wide who may at some point need to
move to .NET,

When those needs actually arise, then VCL.NET will have a place. Until
then...it's a nogo.

then there is a good reason to get rid of the distinction
between VCL and VCL.NET and just call it VCL (for as many platforms as
you like).

I'd rather see platforms supported that are actually different to the
end user/customer. :)

Any problems with VCL.NET were with execution of the plan, not the plan
itself

We disagree here. But we'll see since CodeGear apparently agrees with
you. If you want to take my wager, I'm game. :)

(and providing WinForms support for the last several years has
NOT helped clarify the message!).,

Sure.

--
Brian Moelk
Brain Endeavor LLC
bmoelk@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
.

Relevant Pages

  • 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: The Register interview Nigel Brown
    ... The VCL is one of the key factors that makes Delphi unique. ... Open sourcing it would probably attract some developers to it, ... competitiveness with the .Net framework. ...
    (borland.public.delphi.non-technical)
  • Re: Delphi 2005 Update 4 IS needed !!!
    ... I use a lot of 3rd party tools and am not doing much that requires web ... version just to make sure Borland didn't go completely out of business, ... I am wondering how many Delphi developers are in the same situation as ...
    (borland.public.delphi.non-technical)
  • Re: How about buying http://www.tmssoftware.com/
    ... DevCo became like Big Brother for Delphi developers. ... VCL is lack of big update for years, ...
    (borland.public.delphi.non-technical)
  • Re: DevExpress & D8
    ... application just like the Delphi literature promises - that requires ... that evolved for VB and C# developers and necessarily different to those ... It's not an easy task to convert a Developer Express component from VCL ... were a few others that were all AFAIK resolved in the Second patch. ...
    (borland.public.delphi.non-technical)