Re: Opportunity passed by

Nathaniel L. Walker wrote:

C#Builder is just an IDE with add-on libraries/tools using Microsoft
tools and ever-growing foundation library for most of the donkey work.

Indeed, and it would bear comparison with JBuilder if it was as
stand-alone package rather than a BDS "personality" (and likely
emulate JBuilder's now very lack-lustre sales too)

Their C++ toolchain has no .NET support whatsoever

This is only one area where their current C++ compiler is starting to
look like something archaeologists unearthed from a dusty tomb.

Delphi and
C#Builder support a deprecated version of .NET.

Because under Borland's stewardship very little of the profits being
generated by language products were being invested in improving them.


Do they not
realize that many people who use both Delphi and C# are actually
migrating from Delphi to C# for .NET development?

I think they do realise this, but realising something and wanting to
help with the process of killing one's own product are two very
different things. Of course, one could argue that by embracing .NET,
Borland already sealed their own fate insofar as dev. tools were
concerned, or at least dev. tools as something that could allow anything
beyond quite a small company to live from. The .NET frameworks already
offered more modern versions of much of what's in the VCL, and MS had
begun to demonstrate a new-found ability to build IDEs that were half-way
decent, so Borland had much less opportunity to distinguish themselves
than had been the case with Java in its early days.

What do they
offer developers moving to/using C# by showing them an IDE that is
subpar for .NET 2.0 development.

Not much, hence the fact that so many of those left in the Delphi camp
are native code developers. I wouldn't use any current Borland tool for
..NET work when I can download a free Express product from MS that
supports much more modern versions of the frameworks, but by the same
token, I wouldn't relish using VS for native apps that have significant UIs.

> The reason why I say this is although it is called Borland Developer
*Studio*, the only integration it seems that these development environ-
ments offer is the fact that they are all under the same IDE, and some
share common tools (Together, ECO, etc.).

Well, to be fair, that was the only integration MS offered with VS in the
pre-.NET days, and it's still the only integration they have if you want
to develop native code stuff.

I don't really see the
benefit of putting a tool like C++Builder (only useful for Win32 dev-
elopment) in an IDE that will not install unless you install .NET 1.1 SP1
and the J# redistributable.
The same can be said about a lot of multi-language development environments
though. People who want to (for example) use Eclipse for PHP or C++ development
will have to install Java and SWT even though they don't plan on using either,
and C++ programmers who want to develop DirectX games with VS have to install
vast amounts of .NET stuff that they don't want or need.

They share the same IDE, but their feature
sets are VERY fragmented.
Just like Microsoft's in the pre ".NET with everything" days.

You don't see this in development environ-
ments like Visual Studio (apart from J#, which is more of a "port your
app to .NET" thing than anything else).

You don't now because everything is .NET centric, but there was little if
any convergence between (for example) VB, VC++, and Java in Visual Studio
prior to that, and there's still no real convergence between all the ..NET gubbins
and native code C++ applications (which is still a major market for VS).

If they actually believe BDS is/was a viable alternative to Visual Studio
for .NET application, they should have delivered a C# 2.0 development
environment (perhaps with the ability to multi-target 1.1 and 2.0) while
working on, improving, and bringing their Delphi .NET compiler up to
snuff.
Borland didn't believe that BDS was anything except a cow whose milk
could be used to feed their ALM babies, so they devoted less and less
resources to it over time, and then tried to sell the whole kit and kaboodle
after finding that fat, happy cows give more milk than starving miserable
ones.

They also should have molded equivalent VCL.NET support into
the C#Builder personality of the IDE (I've heard good things like VCL
.NET, like it being faster than WinForms, etc.) and at least implemented
Managed Extensions for C++Builder in an attempt to move towards
a mixxed-mode compiler on that end.

They could have done many other things that people have been asking
for, but it's likely that the decisions to sell off the tools division had been
made quite a while before it was announced, so Borland had little incentive
to invest more than they had to in something that they hoped would soon
belong to someone else.

If they cannot keep up, they should not compete, but rather
maintain a strong hold in their niche market.

I don't think it was so much an inability to compete as a reluctance to
invest the necessary resources in something they were hoping to rid
themselves of.

> There is a free version of JBuilder available, and it has been that way
since version 4?

The free one lacked much of what was in the paid for ones, and was often
a version behind the current JBuilder, which meant that it sometimes
required an obsolete version of the JDK. Who's going to bother wasting
disk space on a crippled IDE and old JDK when they can use it for a full
version of NetBeans or Eclipse that uses that latest Java technologies
throughout?

But Borland's OTA has always been poorly documented and marketed
to developers outside of enterprise users and ISVs/Partners who produced
JBuilder Add-Ins. The same is true for Delphi/C++Builder/BDS.

They also needed to make money, which meant that Enterprise versions
of JBuilder (which were the only ones that competed feature wise with the
free IDEs as time went by) cost a lot of money.


There were [poor] ways to make VCL code somewhat CLX-compatible,
but I think the point was to enable source:source compatibility of solutions
via CLX.

It was what people wanted from a Delphi For Linux, which is what most
were expecting Kylix to be.

What I means is that it was IMO foolish to think you could load
your VCL applications in Kylix and recompile them.

The foolishness was deciding to craft a framework which didn't allow this

If that was the case
then there wouldn't have been a CLX for Windows and the CLX on Linux
would have had classes/objects/types starting with the letter "T" to avoid
having to change them over via some rediculous conversion tool.

There should never have been a CLX for Windows. A sanely designed CLX
would have been a cross-platform VCL, which Borland could have built
more easily than a few developers who have implemented a great deal
of just such a beast for Lazarus. Not only would this have helped them
target UNIX-like systems, but it would also have provided a ready foundation
for the .NET VCL, thus making Delphi for .NET somewhat easier to build.


How about altering GCC to output OMF object files, different calling
conventions (things that may be there but work differently due to
implementation differences), etc. I think it's a vast amount of work that
would have to be done.

GCC can already output OMF files, so this is one area where they wouldn't
have to do anything (gcc -Zomf).


Yea, and the Intel compiler generated some faulty code on occasions, and
made compile times 50-150% longer.

But could target newer CPUs with more effectively optimised code, which is
why Borland took the easy route of including it instead of improving their own
compiler.

Turning Borland C++ into C++Builder was probably the worst thing they could
have done with that product line, IMO.

The worst thing they did with the product line was making C++ Builder depend
on a framework written in a different language. A lot of C++ programmers were
pretty excited about the idea of Delphi-style RAD, but that enthusiasm largely
evapourated when they discovered that this meant using a framework written
for Delphi in Object Pascal that imposed Object Pascal restrictions on what
C++ could do, and required non-standard extensions to support. The best compiler
in history couldn't have helped C++ Builder overcome that rather glaring handicap,
so most opted to continue struggling with MFC or whatever instead.
.

Relevant Pages

  • Guess for Borlandīs new Corporate Roadmap
    ... I donīt work for Borland nor do I have any other source of information ... While the latest JBuilder-release has a superb CaliberRM-integration, Delphi ... Other ALM-tools such as Together are available for JBuilder and even ... Java group and the .NET-business unit at borland on this unified IDE, ...
    (borland.public.delphi.non-technical)
  • Re: The alternative Delphi roadmap to success
    ... Delphi 4 is a pretty fast and stable IDE that even runs stably ... Unfortunately Borland is behind right now, ... The Explorer Edition is exactly the same as the Professional ...
    (borland.public.delphi.non-technical)
  • Re: Win32, Linux, .NET >> Where is this mess going to?
    ... I already work with both Delphi and VS/C# - which I use depends on my ... Borland have always "lost" in the sense that more people used VS than ... forgot), D8 and now D2005 are a progression, changing from the old IDE ... Borland have no choice but to support .NET if they want to continue ...
    (borland.public.delphi.thirdpartytools.general)
  • Re: Borlands IDE bugs and plans
    ... IDE bugs have never been a priority to me. ... Borland is screwing up on Delphi. ... How about some white papers per Nick Hodges on the Borland Web ...
    (borland.public.delphi.non-technical)
  • Re: Kylix is dead?
    ... >> CLX, Borland should find a way to work with them. ... > Compilers on Linux are generally free, How much do you think Borland ... Now C# comes together with Delphi 2005, whether you want it or not. ...
    (borland.public.delphi.non-technical)
Quantcast