Re: Thinking Clearly



Bob Dawson wrote:
"Brian Moelk" wrote
solution is to rewrite existing code. In this case, is it fair to say
that it is best because of the things that the .NET framework itself
provides?

Actually, it's more because the business I'm in morphs continuously--the
basic requirements are constantly changing. Still, we patch far more often
than we rewrite. The basic economics remain in favor of buying over
building, and patching over rewriting.

Um...I agree with what you're saying in regards to the basic economics.
But here you sound as if you're disagreeing with me by say "Actually,
it's...", and yet below, you sound like you're saying "yes, that's why
we rewrite".

In a sense, the depth and breadth of the FCL means that the move to .NET can
really be seen as a transition from build to buy. For example, our
implementation of encryption is over 3000 lines of complex bit fiddling. By
contrast, wrapping the Rijndael managed object for easy use takes about 60
lines of dirt-simple code.

Right. I think I got the answer that I expected, just not in the form
of a simple "yes" that would have sufficed. ;)

Nevertheless, most of what we're doing in .NET remains new work. Rewrites
usually have to be forced on us.

Agreed and that makes sense.

If Borland had built VCL.NET with the intent of supporting CF
development with it, I could buy your argument a bit more than I do.

Not CF itself, but the VCL /was/ built with some intentional flexibility,
allowing it to be rewritten as the platform underneath it changed.

Ah..I gotcha. I'm not sure if it was relatively cheap to build VCL.NET
or VCL.NET for CF. ;) But we'll see how good it is with Highlander.

Was Win32 "bedrock" when Delphi 2 was released? MS could have changed
Win32 on a whim as well.

Not really. Delphi depended (and still depends) on main, published APIs that
cannot be easily changed without massive breakage. I don't think that the
sam is true of WinForm internals that the designers/debuggers rest on.

Well...if there isn't massive breakage with WinForms, then DevCo doesn't
have much to worry about. ;)

In regards to VCL.NET I think a realistic re-evalution will demonstrate
a poor ROI.

If and when it does, I have no doubt about DevCo making the call. They are
(will be) a for-profit company.

I am skeptical; it's a tough decision and Delphi is a product with many
devotees.

http://bdn2.borland.com/article/31983

Be sure to read Danny's CF rant.

Actually the 'Background' paragraph is more relevant to the current
discussion point: Borland tried WinForms first, but responded to customer
demand to get VCL compatibility. Even there, they tried first to ride on top
of WinForms, and only went to a parallel framework when they couldn't make
the add-over-WinForms approach work.

Right, and I think that listening to their customers about .NET in the
early stages might not have been the best thing in the long run for .NET.

I'm not advocating ignoring your customers at all, I just believe that
those remarks need to be put in context. IMO, asking your customers
about what they want with a new framework will result in the old
framework ported to the new one.

This is exactly what happened with Kylix, and IMO, it was a failure
because it didn't play to the strengths of Linux but rather the
strengths of Delphi.

So why play to your weakness rather than your strengths?

For the same reason that concentrating only on being a better buggy whip
manufacturer in 1910 wasn't a good idea.

Again, I think this demonstrates some Delphi myopia. I would have
preferred that you didn't trim my quote as I talk about what I think
having a compelling .NET strategy means.

Regardless, I don't believe even MS can afford to make Win32 as obsolete
as buggy whips considering the bulk of their application code is in
C/C++. So I suggest we dispose of the FUD of the buggy whip. IMO, if
Delphi follows MS' C++ .NET strategy, we'll be fine.

Win32 is going to put food on the
table at DevCo for a couple of years yet, but competing for the .NET dollar
simply isn't optional.

Right, I never said that DevCo shouldn't compete for the .NET dollar.

--
Brian Moelk
Brain Endeavor LLC
bmoelk@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
.



Relevant Pages

  • Re: Turbo Delphi to include Java bytecode generator
    ... let's see what Java bytecode brings to the table: ... Will existing Delphi customers keep on using Delphi because of bytecode ... Will DevCo lose existing customers by not doing bytecode? ...
    (borland.public.delphi.non-technical)
  • Re: Why arent you upgrading?
    ... But DevCo has very limited resources. ... thing to do, but then again - if it's so obvious, why did Borland ... Just take any kind of multimedia app - and Delphi still is quite ... have far more options than we Borland customers have? ...
    (borland.public.delphi.non-technical)
  • Re: Microsoft Release VS2003 SP1
    ... DevCo are you listening? ... DevTools, it was -NOT- Delphi. ... mean you should toss us aside just because we didn't buy the latest ... but if you continue to toss customers aside just because ...
    (borland.public.delphi.non-technical)
  • Re: A voice from the community
    ... for a "borlander" used to code in delphi with the VCL from the mitic Delphi ... I think the best way for DevCo is not to use a thirty part framework ...
    (borland.public.delphi.non-technical)
  • Re: VCL.NET revisited...
    ... whether DevCo can convince them that there's value in doing so. ... Delphi developers doing .NET work, if 70% of them choose to use Delphi ... resell sufficient existing customers to pay for the investment (I don't know ... very surprising if it were *not* taken advantage of by many - it's just a ...
    (borland.public.delphi.non-technical)