Re: Thinking Clearly



Brian Moelk wrote:

Well, I don't think I can say anything to make you understand.

Well, yes you can. By clarifying your position (which you do further on
in your post).

How would you be embarrassed?

By going in all guns blazing with a rebuttal that has absolutely
nothing to do with the point you were trying to make.

Well, the easiest technical points to make are the ones that have been
hammered at many times: .NET 2.0 and CF. I recognize that Highlander
will bring BDS back on par,

OK, I see what you mean. And I concede that not having .NET 2.0 support
available yet is less than ideal. And whilst I'm personally very keen
to have full CF support, I'm not sure how sought after it is by other
developers. To my mind, .NET 2.0 support would be a lot more important
to most .NET developers.

but then there's 3.0 right around the
corner.

As far as I understand it, this is more a marketing ploy by Microsoft,
and is actually a few extra sub-frameworks and classes, rather than a
major framework upgrade which will require significant IDE and compiler
reworking before Highlander users can access them.

For more technical reasons, I've previously pointed out some things
that WinForms has over VCL.NET.

See, thats one of the things that confused me about your point. With
Delphi I can choose WinForms *or* VCL.NET. With VS I don't get that
choice. Below are some more choices I can think of that Delphi gives me
:-

- Standard ADO.NET or Borland Data Providers
- Traditional Database/DataSet based application or ECO MDA application
- Better support for non Microsoft technologies
- More Win32/.NET interoperability options
- Ability to use implicit or explicit boxing
- Ability to save a project to a new directory after creating it
(granted, a little fine grained but a VS pet peeve of mine)

I'm sure there are more, but these are ones that I can think of off the
top of my head.

Another thing that I just
remembered: in regards to ASP.NET, Delphi for .NET can't be used "in
the page" right now. I'm certain this is technically feasible, but
it means freeing up the compiler from a licensing perspective and
doing some integration/installer work.

Based on Nick's comments on this very issue in the past, I wouldn't be
surprised to see some movement on this front in the future.

But beyond the technical reasons, I think the political, social and
economic options are overwhelmingly in favor of VS.NET.

So the only place that DevCo can compete is technically.
Historically, they have done so quite effectively, as they've been
significantly better. They must remain significantly better to
combat all the other "options" that VS.NET provides.

On a personal note, thats all I ask of DevCo going forward. Keep the
technical innovation going, and provide a BDS that is good enough to
remain economically viable so I have an alternative to VS. There are
some things about VS I like, but many other things I loathe, and that
BDS does much better.


But IMO they aren't making a convincing enough technical case with
Delphi for .NET and VCL.NET. Their main advantage is code migration;
but most .NET projects that I see are new development efforts.

See thats where we (unsurprisingly) disagree. Have you ever done any
WinForms development (not having a dig, genuinely curious).

I love a lot of things about the .NET Framework, but WinForms is not
one of them. Sure the databinding model is nice in some aspects (but
not all), but there are many things that are so much easier to achieve
using VCL. Here is one example I encountered a while back :-


http://dcleggsblog.blogspot.com/2005/06/showing-true-read-only-datagrid.
html

or

http://tinyurl.com/7b6ft

Anyway, many Delphi developers agree with me since they are adopting
VS.NET and C# for their .NET work. I don't see many C# guys running
to get their hands on Delphi for .NET;

No, but you may be able to convert C# VS users to using BDS. Probably
less of a chance for died in the wool MS tools only types, but
certainly feasible for ex-Delphi developers who have migrated to C# for
..NET work. After all it was probably more than just the language that
attracted them to Delphi in the first place.

And before you counter with "Aha! See, Delphi.NET isn't needed for a
DevCo .NET strategy after all!", I believe there is still a viable
market of existing Win32 developers who haven't dipped their toes in
the .NET pond yet. Sure, the current trend appears to be to use C#, but
I don't think it is impossible to break this trend. Especially
considering the excellent code migration support that is already in
place.

Damn! I told myself I wouldn't get drawn into this thread, but I just
couldn't help myself. But I agree with Bruce on this one, and I've
really enjoyed listening to both view points.

--
Cheers,
David Clegg
dclegg@xxxxxxxxx
http://cc.borland.com/Author.aspx?ID=72299

QualityCentral. The best way to bug Borland about bugs.
http://qc.borland.com

"Oh, well, of course, everything looks bad if you remember it." - Homer
Simpson
.



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: Captain Jakes Top Ten List of what Id like to see in thenextversionofDelphi
    ... MFC and WinForms do not. ... For the Delphi developer, there is less of an argument. ... How many VCL Win32 customers have been asking their vendors to support ... Delphi developers, moving their existing Win32 application to .NET ...
    (borland.public.delphi.non-technical)
  • Re: Captain Jakes Top Ten List of what Id like to see in thenextversionofDelphi
    ... is vastly smaller than the Winforms component market. ... VCL.NET developers = less market for VCL.NET components. ... Borland has put Delphi at a disadvantage. ... code directly to the Win32 API. ...
    (borland.public.delphi.non-technical)
  • Re: VCL.NET revisited...
    ... That's probably because I *am* an existing Delphi developer (among ... WinForms but I'm hard put to blame all the sluggish response of .NET ... Adding Avalon support isn't what I had in mind for new WinForms ... The .Net framework, yes, but not WinForms. ...
    (borland.public.delphi.non-technical)
  • Re: first impression and uneasy feeling... (long)
    ... I read in one blog that VCL.Net is way faster than Winforms as Winforms is ... based on the GDI+ (which is a performance disaster) and VCL.Net is not. ... > - IDE is very familiar to Delphi users ... > I think a very large percentage of developers using Delphi to do GUI ...
    (borland.public.delphi.non-technical)