Re: Thinking Clearly

Bob Dawson wrote:
"Brian Moelk" wrote
Yes, only if .NET code migration is important to you.

'Code migration' is a deceptive term, since migration generally implies
one-way. Cross-platform (win32/.NET) development will continue to be a
significant reality for some years.

I contend that "Cross-platform" is also deceptive. Certainly I agree
that cross-platform and multi-platform development will continue to be
important.

Cross-platform is more important when one is talking about Windows and
Linux, or Windows and OSX. These are things that make a difference in
deployment strategies, TCO, user interface, etc.

I'm not certain that there is any significant difference from a business
perspective between .NET and Win32 as a platform when it comes to the
kinds of problems VCL and VCL.NET solve. It's a distinction without a
difference.

Multi-platform development is important, and this is where there is a
difference between .NET and Win32.

And I don't see that Delphi developers have anything special about them in
needing to live in multiple worlds. That's where your 'code-migration'
terminology is misleading. Win32./.NET cross-compatibility is not just about
legacy code. It's about supporting both platforms for some time to come.

Sure...multi-platform development is important. I just don't think
having a single language or framework library is important for that
purpose. In fact, I think one has to make compromises in order to
derive that benefit.

difference at all. If the development is the same, using the same
framework, i.e. VCL, there is no reason at all to use .NET.

That doesn't follow at all. You can cook both haute cuisine and burgers on
the same stove. It's not like using VCL.NET prohibits exploiting the FCL for
all it's worth.

I disagree. VCL.NET does prohibit the use of FCL for all it's worth.
DataBinding and security are both issues in using VCL.NET.

IOW, the question is really why would you want to do both? IMO, the
reason to go .NET is to actually leverage what .NET has to offer. I
know, it sounds radical. ;)

No, it sounds obvious.

did you miss my ";)"?

It just has nothing to do with whether one chooses a
Form or a TForm for the front end.

I think it does.

Cross-platform evolution certainly makes sense for existing code bases.

Why? All of a sudden the application isn't working on Win32? If there
is nothing in .NET that is going to be utilized, why go .NET at all?

For
new work it might or might not. But I just don't see any reason why a
developer interested in learning TForm use in the win32 personality would
want to ignore that knowledge when writing another program destined only for
..NET existence.

I provided a bunch of reasons that you dismissed (inaccurately IMO) as
all being "standards" based ones. IMO, even if they were all
"standards" based arguments, they are still valid arguments and apply in
this regard.

If the intention is to spend as much time on the problem
domain as possible, and as little on the tools as possible, then why use
different tools in every other program to whatever extent commonalities
exist?

Come on Bob, you're sophisticated enough to know that the intention
isn't purely to spend as much time as possible on the problem domain.
The job of a good developer goes well beyond solving problems; the
quality of the developer is very often determined by how they solve the
problem, not if they solve the problem.

Which is why something like a mixed-mode
compiler is, IMO, a much better migration/integration strategy.

FWIW, I'd strongly support a mixed mode compiler. I'm just not interested in
arguing that its the only thing DevCo should be working on.

Neither am I.

My point is that it is important to view it beyond just that. It's
important to look at it in context of limited resources, importance
to the customer base (which remains largely Win32), opportunity
costs, what strategic advantage it provides and the competitive
landscape of the .NET development space.

I believe that that's all in Nick's job description somewhere. And I'd bet
he's doing it as fast as he can.

Sure, and I'm simply providing my input.

--
Brian Moelk
Brain Endeavor LLC
bmoelk@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
.

Relevant Pages

  • Re: Thinking Clearly
    ... only if .NET code migration is important to you. ... reason to go .NET is to actually leverage what .NET has to offer. ... platforms are Win32 and .NET. ... Cross-platform evolution certainly makes sense for existing code bases. ...
    (borland.public.delphi.non-technical)
  • Re: Looking for Beta testers for Linux model rocket simulation
    ... Lawndart was written to be cross-platform, ... precompiled executables won't work, but I see no reason why it ...
    (rec.models.rockets)
  • Re: attempt to build a widget library
    ... > I'm thinking about building my own XWindow / Win32 based cross-platform ... I don't want to jump into something that I ...
    (comp.windows.x)
  • Re: I dream of a LISP that...
    ... >1) Is open-source ... >2) Is cross-platform ... >3) Can deliver some kind of GUI (on X and Win32) ...
    (comp.lang.lisp)
  • Re: Borland on MacOSX
    ... I think that do not need a cross-platform delphi ide but a true ... cross-platform in windows see win32, win64, pocketpc in a way that my Txxx ... is causing CodeGear to lose existing (Win32) customers. ... Delphi doesn't support MacOS since Delphi 1. ...
    (borland.public.delphi.non-technical)