Re: Chrome - competition for Borland?

From: Leonardo Pasta (lhpasta_at_nada.yahoo.com)
Date: 11/04/04 

Date: 4 Nov 2004 09:32:13 -0700

Eric Grange wrote:

> Well, I started some porting in the early D8 days, but it became
> painfully clear that the work required to get both a working port
> and a comparable performance would be as gigantic a task as a rewrite
> from scratch, making C++ into a more simple port target despite
> all the syntaxic changes... while bringing benefits to the table
> (unlike a Delphi.Net port).
  Yes, I agree with you, but for OLTP applications, raw processing
speed isn´t as important, because you should be bottlenecked by the
network and database before you reach the limit of processor speed in
.Net.
  As I said, I think .Net will be used first in OLTP applications.
  And I think that D2005 is offering a broader range of components
converted to .Net (i.e. dbGo) and third-party are starting to offer
".Netted" versions of their traditional packages. This should make
conversion easier (although I don´t think it will ever be "easy")

 
>
> Obviously it depends on applications, but Delphi.Net isn't the magic
> bullet successor to Delphi, but just a look-alike from afar.

  Yes, no doubt about it, but we are discussing .Net options, not if
.Net is best suited for some projects than win32 or win64. Chrome
doesn´t offer native win32 or win64.
  If you (as I do) still don´t think .Net is worth the conversion,
then chrome isn´t a path either.

>
> > Chrome won´t have a VCL, so it is only an option for full rewrites
> > or new projects.
>
> A VCL under .Net is bound to be a liability as it is IMO, as it will
> restrict you to those .Net platforms that ALSO support Win32 (making
> the porting into a wasteful exercice).

  Yes, but currently WinForms don´t run under mono as well. This may
change, but I don´t take it for granted.

> VCL may port to Avalon, but there is no guarantee of that, and what
> you would get would only look like VCL, but would have a hard time
> running third-party components (and if you're limited to the standard
> VCL components, VCL is quite puny nowadays).
  Well, I am not concerned with Avalon, even MS doesn´t appear to know
what it will be when they finish it, how winforms will be "migrated"
etc.
  As the thirty-party you may be correct, I hope that DevEx port their
components (I don´t know if they already didn´t). But for migrated
apps, it is not a big issue.

> There are three points to keep in mind with libraries:
> - they can be interfaced and used in another tool
> - they target only a fraction of the users of the language
> they were programmed in
> - they can be replicated by competitors, once ideas have
> matured, and this replication is cheaper to achieve
> than the original design
  Yes, I agree with some of this points, but
  - it isn´t always easy to interface a library to use in another
tool, ECO and BDPs can only be used with Borland .Net products for
example.
  - they can be replicated, but this take time, and you may have other
issues (patents, etc), meanwhile, the original developer benefit from
this differential and is always a step ahead than the competition.
These same issue could be said about compiler features, especially in a
.Net environment.
  - As for the target, I don´t think 1 feature can make Delphi gain or
loose marketshare, but a bunch of them can make a difference (i.e. ECO,
BDP, Intraweb, etc). I am not saying that these ones will make a
difference, I am just making an example.

>
> This means that should Delphi survive f.i. because of ECO, Borland
> would probably end up porting ECO to VS.Net, to make more money and
> reach a broader market, because if they didn't, MS would occupy that
> VS spot before them.
> ECO isn't Delphi-specific in any way, it isn't a new VCL, it doesn't
> rely on specific language or compiler features of Delphi.
>
> That said, I don't see ECO becoming anything more than a niche
> within a niche. :p
  Yes, if Borland would depend only on ECO success to survive they
would be in a bad position. I´m betting more on a combination, like:
ECO, intraweb, ALM, win32, refined IDE,etc. Of course we could hope to
extend this list to include win64 ;)

Relevant Pages

  • 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: Borlands Net Loss Desaster
    ... -A real cross GUI VCL ... Make a full port of MIDAS on .NET, ... - Improve VCL.NET and promote it as the main way making fat client .NET applications with Delphi ... - Bridge VCL .NET with ECO ...
    (borland.public.delphi.non-technical)
  • Re: Chrome - competition for Borland?
    ... Well, I started some porting in the early D8 days, but it became ... painfully clear that the work required to get both a working port ... VCL *may* port to Avalon, but there is no guarantee of that, and what ... ECO could be offered to VS, ...
    (borland.public.delphi.non-technical)
  • Re: Win32, Linux, .NET >> Where is this mess going to?
    ... possible to do something like that in a short time period for Delphi. ... development with their VCL components. ... port seamlessly, but some things would have to be modified. ... .NET and Mono, development of future apps with Delphi will be much simpler ...
    (borland.public.delphi.thirdpartytools.general)
  • Re: 24 hours of Delphi public chat log
    ... - ECO is heavily dependent on and built on extended run time type ... - the VCL for Win32 does not provide this level of RTTI ... - Doing this port does not seem to be on the short list of priorities at the ... revised, rearchitected, modernised VCL for native Win32 and native Win64 ...
    (borland.public.delphi.non-technical)