Re: I really hate .NET especially inside Delphi


"Nick Hodges (Borland/DTG)" <nickhodges@xxxxxxxxx> wrote in message
news:45241a60$1@xxxxxxxxxxxxxxxxxxxxxxxxx
Chad Z. Hower wrote:

We call it metadata - C# users call
it "garbage".

One /could/ say that the C# folks need to expand their world view and
realize that there are other languages out there in the world besides
the MS ones.

To what end? Play in the same sand-box with a different syntax? Sorry,
Nick, that's not going to cut it. Because its not a reason for Visual
Studio users to change since they are already living and breathing a C#
syntax to do their work now.

You've got to give these people a reason to switch, and you aren't going to
do that within the .NET paradigm. Anders Hjielsberg (yep, probably mangled
his name, sorry) et. al. has got you snookered in terms of controlling the
sand-box chock full of features many of which were borrowed directly from
Delphi and expanded. (The CLR was borrowed from Java but we Delphites don't
need it.)

Nick, what follows is a long letter presenting my perspective:

ECO on the other hand presents an opportunity to go up one level and create
a whole new playing field. I'll get to some of its drawbacks in a minute.
With ECO a whole new way of creating software can be pioneered with DevCo
firmly planting its stake in ground. Architecturally, there is no reason
why ECO needs to be tied to a single platform. Once the paradigm is
established it should be possible to offer ECO all Linux, Unix, Mac (if its
still around and not just MacTel) and Windows.

One drawback with ECO is that it was ported from Bold/Win32 to .NET. People
say that ECO could only have been implemented on .NET and I say that's
complete nonsense. The fact that it now is implemented on .NET just limits
its platform options (MONO is a red-herring in my opinion). Why is MONO a
red-herring? For the same reason that Borland/DevCo cannot officially
support it.

But back to the point I want to make: now that it is implemented on .NET you
may as well run with it and (here is the important idea) hide the .NET
implementations details from the user! That's really the point. It
shouldn't matter that ECO is implemented on ECO or Win32/64 or Linux. This
OS/Platform details should be encapsulated and dealt with, allowing the user
to go about the business of building RAD projects that will run on any
platform.

Now that ECO is a .NET creature an opportunity presents itself to port it
another platform that also has a VM runtime - J2EE, and architectural
sibling to .NET.

If ECO were ported to Java, you would then definitely have a product
representing a new Software Dev Paradigm that would run on any OS.

Now, Nick, I realize the above scenario may in fact not involve you as the
Delphi/C# product manager, since I am talking about something beyond that.

On the Delphi front the vast majority of your users are firmly tied to
Win32. Since they are Delphi Developers they have very little reason to
switch tools since .NET gives them no real benefits over what they've got
now. What these users would respond favourably to, waving cash in the air,
is a Win64 Delphi compiler. A strategy of trying to get your Delphi win32
users to "upgrade" to Delphi.NET is a strategy that will continue to fail;
because, although you will retain some of these customers (especially those
still using Delphi/Win32) I think you will lose an equal number of customers
(if not more) to Visual Studio. Because, I see know compelling reason to
use Delphi.NET, when C# is very easy to use by Delphites; and Visual Studio
represents the state of the art .NET implementation, i.e. .NET 2.0 and very
soon .NET 3.0. For those die-hard pascal syntax bigots who really have no
further need of Win32, they even have a pure Visual Studio, state of the art
..NET implementation in Chrome.

If I were DevCo, I'd acquire Chrome while there is an opportunity to do so.

And NO, IMO a viable strategy is not to sink even more resources into .NET
development only to remain behind the power curve. I don't think you are
going to beat MS at the .NET game. You've got to do something different.
And the different strategy needs to be implemented asap.

The fact that you are both the C# and Delphi product manager is troubling
to me; because it says to me that your primary focus for Delphi is the same
focus as C# - .NET!! . If this wasn't the case, then the C# and Delphi
product managers would be different people.

I, personally, see no gain in offering a C# personality in BDS at all. You
aren't going to woo any Visual Studio users over to this camp when they've
already got the state-of-the-art implementation of that language. Instead,
you'll just be draining more development resources.

As long as .NET remains the primary focus for Delphi, your product
management strategy will continue to fail. I've seen the list of Win32
"enhancements" you posted awhile back and I'm not impressed. When you rise
up to challenge this statement, be careful, I've already seen your "list" of
enhancements. Most of the "enhancements" that made it into Win32 were
necessitated by the requirement to have them in Delphi for .NET. So these
types of enhancments are .NET driven and .NET focused.

I think part of the problem is thinking that enhancing the IDE is a key to
getting customers to upgrade and/or retaining them as customers at all. I
don't think enhancing the IDE is the key to success. "Nice to have", maybe;
but that's all. The D7 IDE gives me all the productivity I really need.
Plus, the help works.

For my day to day choice of IDE, here is how it is for me:
Frankly, I still do almost all my coding in D7 even now. To be honest, at
this point its probably mostly inertia. Some of the reasons for using D7 in
existing projects might be D7 third party support (especially in my huge
projects); other reasons may be the slower D2006 IDE and slightly less
stability issues. The broken help system is just another nagging item that
lessens the experience. I think for all of those reasons, my subconscious
just tells me: "Got an idea for a new project? Fire up D7, you won't be
sorry".

To sum up, it sounds to me that you are staying with the exact same product
management strategy that has been in place for the last three years. What
has changed? Can you list the items that are different? I know about your
re-commitment to "releasing a quality product", IOW getting the bugs before
your customers get them first... But I am not so sure if this kind of item
should go on "The List"; but instead should go under the rubric of
"Developing software correctly".

Where on your Product Management list of priorities is a native Win64
compiler for Delphi? Can you tell us? Please don't say that "it's a
secret". That answer among other things lacks integrity. Have you begun
working on the Win64 compiler yet? When can we expect a preview? Will we
be seeing something on this front in 2007? Can some of us sign up as "early
experience" beta testers for the new Native Win64 compiler?

Perhaps its time for another Newsgroup Win64 compiler campaign? Actually,
its too late for that. We need to be hearing something positive on this
front now. Or its just too late.

And the beginning of this year I was gearing to switch over to C++ when I
heard about Delphi/Win64 on the roadmap; and unless I we hear something
about Win64 soon; I will reluctantly need to start the gears turning to make
the switch.

-d





.

Relevant Pages

  • Re: Chrome - competition for Borland?
    ... >> particularly damning of Borland. ... At this point the only reason I have to upgrade Delphi, ... I can't think of another reason. ... On the .NET side, ECO II might be a compelling reason, but after the D8 ...
    (borland.public.delphi.non-technical)
  • Re: Vote for it: ECO Visual Studio plugin
    ... I won't get any further down into this part with you, because we are both agreed that if evaluated in terms of existing ECO users, there's a logic behind continued C# support. ... But if you expect to invest most of your $$ into building and growing developer tools such as Delphi, you have to have product differentiators that are available exclusively in your developer tool. ... And when you tell me that Delphi "can't compete on .net, it's just that simple" how can you deny you're flying the white flag? ...
    (borland.public.delphi.non-technical)
  • Re: Roadmap Review - My Questions
    ... ECO is somewhat expensive and I have reservations about not having ... Chrome offers additional value above and beyond Delphi for .NET. ... "Again it can be a productivity issue - one already knows the VCL, ... Delphi for .Net, for those preferring C#, ECO is just as much an advantage ...
    (borland.public.delphi.non-technical)
  • Re: Vote for it: ECO Visual Studio plugin
    ... ECO confined to Delphi. ... CodeGear is no longer producing a C# IDE/product. ... why is anyone BOTHERING to compete with it. ...
    (borland.public.delphi.non-technical)
  • Re: Chrome - competition for Borland?
    ... > (unlike a Delphi.Net port). ... > bullet successor to Delphi, but just a look-alike from afar. ... >> Chrome won´t have a VCL, so it is only an option for full rewrites ... loose marketshare, but a bunch of them can make a difference (i.e. ECO, ...
    (borland.public.delphi.non-technical)