Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Will Delphi 8 be Linux compatible?

2 views
Skip to first unread message

Kristofer Skaug

unread,
Jul 12, 2003, 2:49:09 PM7/12/03
to
I've hung out in Siberia (aka. b.p.k.non-tech) the past days, it is
*reeeeeeaalllly* depressing over there.
The vocal majority there is totally convinced that Borland has killed Kylix.
And lo, the whole newsgroup is in a funereal mood, mourning and grieving
people are licking their wounds and wiping each others' tears...

What is really even *more* depressing is that Borland does not seem to be
doing *anything* to contradict this rumour, not even with so much as one
little glimmer of hope (a Kylix related press release, an update pack for
CLX, a BDN article, whatever...).

So this prods me to restate my question from earlier this week in slightly
different way:

Will there be a CLX in Delphi 8? and if so, why?

Is Linux still a target platform for Borland (and I don't mean Java) in the
next couple of years?

If not, why doesn't Borland just put us Delphi/Kylix people out of our
misery with a harsh statement, so we can at least go look for something else
before it's too late?

Kristofer

Jari Kettunen

unread,
Jul 12, 2003, 4:02:56 PM7/12/03
to
I had tried several times use Kylix. If some one asked from me there is the
time Borland to face the facts.

1) There is no develop once use it in Linux and Windows. (only in wet
dreams on men with suites).
2) Linux is not Windows. If B$ DbExpress-drivers don't work on my computer
(with xyz version of MySql or other) I NEED SOURCES so solve my problem and
if I solve it I give it FREE to all other others.
3) I can do all on Linux side with FREE QT-tools.

4) I love Borland. They learned to me to how to code.


"Kristofer Skaug" <ya.ierfgnf@thnxf.x> kirjoitti viestissä
news:3f105832$1...@newsgroups.borland.com...

Oliver Feins

unread,
Jul 12, 2003, 4:54:44 PM7/12/03
to
Hi,

>What is really even *more* depressing is that Borland does not seem to
>be doing *anything* to contradict this rumour, not even with so much as
>one little glimmer of hope (a Kylix related press release, an update
>pack for CLX, a BDN article, whatever...).

To me, Kylix future is in Mono. I hope Borland sees it that way too. I
guess it is from stuff I read.

You are right to say that Borland sometimes leave its clients in the blank
and that it is not good for them from a developer's relationship viewpoint
but I believe they listen because they keep going one with nice products
but more feel connection would indeed be needed particularly when there is
a strong goodwill and trust in the Borland's client's developer's world.

Now, to me, what Borland should do or have done with Kylix is what it _is_
doing now with .Net. That is, releasing a top class IDE over a foreign
compiler (MS .NET or GNU GCC or GCJ).

If Borland had developed a first class IDE over GCC or GCJ, Kylix would be
further away than it is today in term of market share and adoptance. Most
Linux developers are C++ developers. To me, Linux developers are still in
search of a robust C++ development environment 'Delphi'-like. Linux OS
continues to advance days after days steps by steps but surely. So, this
kind of development tool is more needed tomorrow then yesterday.

I also believed it is nice to have the Object Pascal (Delphi language)
compatibility with the Win32 Delphi but my idea is that this strategy
doomed a bit the Kylix project because of the Linux people natural feel for
C++ and that that appeals mostly to current Delphi developers not taking
care of the Linux developers, the normal target.

Now, converting from Pascal syntax to C++ syntax is not that much difficult
for a Delphi developer provided we keep with the VCL library. Also, I still
don't understand why they have been with Qt way and not the wxWindows one
particularly when no one?, can I say that, like the Qt rendering look in
Windows.

I am also sure there is plenty of Delphi developers that would like to help
with the Kylix project if they could. Your call sounds like one to me.

So, open standards: GCC, GCJ, Mono and a way to integrate the goodwill of
Borland's client base in an open world to support the Kylix _commercial_
toolkit is the way to go. Borland, please, show us you have big ears.

Regards,

Oliver

Rosimildo da Silva

unread,
Jul 12, 2003, 5:24:13 PM7/12/03
to
Oliver Feins wrote:
> Now, to me, what Borland should do or have done with Kylix is what it _is_
> doing now with .Net. That is, releasing a top class IDE over a foreign
> compiler (MS .NET or GNU GCC or GCJ).
>

Many people has beat this key point many times. You right on it.
Any company that does not target GCC as the backend tool for Unix/Linux
developoment, it is certainly target for failure.

Rosimildo.


Kristofer Skaug

unread,
Jul 12, 2003, 5:44:40 PM7/12/03
to
"Oliver Feins" wrote

>
> Now, converting from Pascal syntax to C++ syntax is not that much
difficult
> for a Delphi developer provided we keep with the VCL library.

Hrmpf! As long as I can have a macro so I can write begin-end instead of {}
!!! <g>
(oh and various other dirty C++ stuff I couldn't bend my keyboard around)

> Also, I still don't understand why they have been with Qt way and not
> the wxWindows one particularly when no one?, can I say that, like the
> Qt rendering look in Windows.

Very good question...
and some other very good points.

Kristofer

Alessandro Federici - RemObjects Software, Inc.

unread,
Jul 12, 2003, 6:20:23 PM7/12/03
to
"Rosimildo da Silva" <rosi...@yahoo.com> wrote in message
news:3f107ba6$1...@newsgroups.borland.com...

> Many people has beat this key point many times.

And many many more... ;-)


Rosimildo da Silva

unread,
Jul 12, 2003, 9:04:18 PM7/12/03
to

That I know for sure. <g>

Rosimildo.

ckd

unread,
Jul 13, 2003, 1:07:59 AM7/13/03
to
On Sat, 12 Jul 2003 23:44:40 +0200, "Kristofer Skaug"
<ya.ierfgnf@thnxf.x> wrote:

>
>> Also, I still don't understand why they have been with Qt way and not
>> the wxWindows one particularly when no one?, can I say that, like the
>> Qt rendering look in Windows.
>
>Very good question...

Well, this was answered way back in the days when Siberia was more
like, umm, Moldova.

If I remember correctly, the architecture of Qt made wrapping it in
VCL pretty nice and tidy. Much more so than the other GUI toolkits
available. In other words, Qt was just a really good fit for the
requirements.

Ender

unread,
Jul 13, 2003, 1:35:03 AM7/13/03
to
OF> Now, to me, what Borland should do or have done with Kylix is what
OF> it _is_
OF> doing now with .Net. That is, releasing a top class IDE over a
OF> foreign compiler (MS .NET or GNU GCC or GCJ).

I think this is impossible. GNU Pascal & GNU C++ does not inclue some key
features actively used by Borland in their libraries. For example "finally"
clause.

OF> If Borland had developed a first class IDE over GCC or GCJ, Kylix
OF> would be further away than it is today in term of market share and
OF> adoptance. Most
OF> Linux developers are C++ developers.

Not exactly. Many of them are "plain C developers". :-) Just to be precise.

OF> Now, converting from Pascal syntax to C++ syntax is not that much
OF> difficult for a Delphi developer provided we keep with the VCL
OF> library.

How about some core language features like interfaces, only heap objects,
managed strings? I don't think that it will be easy.

OF> So, open standards: GCC, GCJ, Mono and a way to integrate the
OF> goodwill of
OF> Borland's client base in an open world to support the Kylix
OF> _commercial_
OF> toolkit is the way to go. Borland, please, show us you have big
OF> ears.

In Russia there is joke: "He is smart as dog, understand everything but not
able to talk." :-)

Ender

unread,
Jul 13, 2003, 1:40:05 AM7/13/03
to
KS> I've hung out in Siberia (aka. b.p.k.non-tech) the past days, it is
KS> *reeeeeeaalllly* depressing over there.
KS> [...]

I think such depression lasts from times of K1. After first exitement is
faded. I think most people bought K2 and K3 in hope to see bugs eliminated.
Unfortunately, K3 has plenty of problems that was in K1.

Paul Qualls

unread,
Jul 13, 2003, 2:04:21 PM7/13/03
to

"Kristofer Skaug" <ya.ierfgnf@thnxf.x> wrote

> The vocal majority there is totally convinced that Borland has killed
Kylix.

Borland didn't kill Kylix. All the people that responded to early surveys
stating that they wanted and would buy Kylix then didn't purchase - killed
it.

pq


Doug Chamberlin

unread,
Jul 13, 2003, 8:56:05 PM7/13/03
to
On Sun, 13 Jul 2003 12:04:21 -0600, "Paul Qualls"
<paul@paulqualls_nospm_.com> wrote:

>Borland didn't kill Kylix. All the people that responded to early surveys
>stating that they wanted and would buy Kylix then didn't purchase - killed
>it.

Are you saying the inferior quality of the final product has nothing
to do with it? Are you saying those people should have purchased it no
matter what it eventually became? What a joke.

Alessandro Federici - RemObjects Software, Inc.

unread,
Jul 13, 2003, 10:17:24 PM7/13/03
to
"Doug Chamberlin" <dchamberlinATandoversoftwareDOTcom> wrote in message
news:6nv3hvo96e3e6a964...@4ax.com...

> Are you saying the inferior quality of the final product has nothing
> to do with it? Are you saying those people should have purchased it no
> matter what it eventually became? What a joke.

The quality of a product is also proportional to the money it generates
since that is the most important
aspect to decide how many resources should be put on it.

No money=no resources put into it.
No resources=no improvements.

I don't see anything wrong with this.

Kylix 1 was a major effort. If it had generated the revenues the hype around
Linux seemed to
indicate, we would have seen a splendid Kylix 2 and 3. Apparently that
wasn't the case so
IMHO is very good Borland is dedicating their resources to something more
valuable and important
such as Delphi for .Net, C#Builder or JBuilder.


--
Regards,
Alessandro Federici

RemObjects Software, Inc.
http://www.remobjects.com


juliusz

unread,
Jul 13, 2003, 3:28:35 PM7/13/03
to
Kristofer Skaug wrote:
>
> If not, why doesn't Borland just put us Delphi/Kylix people out of our
> misery with a harsh statement,

It can be possibly explained with these words: "reaction of
stockholders"; publicly admitting that they will no longer develop
Kylix would diminish the Borland's image as the independent software
tool maker and Borland would be considered just as a another Microsoft
dependent satellite company.

We have to remember that on the end of last year Borland acquired a
relatively big company and this acquisition must have an impact on
company priorities. They are after a bigger corporate customers, to
serve the master, that's where the money are... But does it really
matter what exactly the reasons are?


> so we can at least go look for something else
> before it's too late?
>

The TrollTech's multiplatform development environment looks very
promising and can be used along with Kylix..While we are waiting for
Kylix 4, of course ;-)

juliusz

Ender

unread,
Jul 13, 2003, 10:44:10 PM7/13/03
to
>> The vocal majority there is totally convinced that Borland has killed
PQ> Kylix.

PQ> Borland didn't kill Kylix. All the people that responded to early
PQ> surveys stating that they wanted and would buy Kylix then didn't
PQ> purchase - killed it.

They expected at least same quality as in Delphi. If product does not meet
their expectations why they should buy buggy product? And why they should
buy this product again if they see that bugs not getting fixed in next
releases?

juliusz

unread,
Jul 13, 2003, 3:43:09 PM7/13/03
to

Highly desired product, with a superior qualities, normally sells by
itself.. Kylix is a fine product but it creates a negative first
impression to most anyone who wants to try it... ;(

Phillip Flores

unread,
Jul 13, 2003, 11:39:58 PM7/13/03
to
juliusz wrote:
>
> Highly desired product, with a superior qualities, normally sells by
> itself.. Kylix is a fine product but it creates a negative first
> impression to most anyone who wants to try it... ;(
>

I think part of the problem is that most of the developers that try out
Kylix are seasoned Delphi developers and as such expect the same level
of performance from Kylix as in Delphi.

--
Cheers,
Phillip Flores
"Keep track of your time...Use VeriTime"
http://www.pcfworks.com

Alessandro Federici - RemObjects Software, Inc.

unread,
Jul 14, 2003, 12:18:46 AM7/14/03
to
"Ender" <linuxm...@h.o.tm.a.i.l.NO.S.P.A.M.commerce> wrote in message
news:10581531...@jet.ru...

> They expected at least same quality as in Delphi. If product does not meet
> their expectations why they should buy buggy product?

Maybe because they were foolish and make sure the product fit their needs
using the trials Borland provided?
You cannot blame Borland for everything. Bugs are in every product. The
responsibility for choosing the
right tool for the job is not in the software vendor but in the buyer.

> And why they should buy this product again if they see that bugs not
getting fixed in next
> releases?

They shouldn't if the bugs stop them from producing their end-product but I
strongly doubt Kylix is that bad.


Alessandro Federici - RemObjects Software, Inc.

unread,
Jul 14, 2003, 12:24:40 AM7/14/03
to
"juliusz" <juliusz...@superobject.com> wrote in message
news:3f12...@newsgroups.borland.com...

> Highly desired product, with a superior qualities, normally sells by
> itself..

Not in this world, sorry ;-)
The product with best marketing sells.


juliusz

unread,
Jul 13, 2003, 5:11:13 PM7/13/03
to
Phillip Flores wrote:

> I think part of the problem is that most of the developers that try out
> Kylix are seasoned Delphi developers and as such expect the same level
> of performance from Kylix as in Delphi.
>

Absolutely, it can be one of the reasons. But, there are many more
trivial and easy to remedy things that effectively impair the sale
figures of Kylix, things which unnecessary create a negative
impression on the first time Kylix user.

Outdated product: Kylix is certified on very old distributions, a
contemporary customer runs normally a current Linux distribution;
would you like to purchase a development tool for Win95.?

Installation problems with the downloaded version of Kylix:
Many people would like to try Kylix first, before they by it. There
are thousands of Kylix downloads from Borland web site. The idea by
itself is great, but when the potential Kylix buyer is trying to
install Kylix and see a bunch of errors on the screen during the
installation to a current LSB compliant RPM based modern distribution
and consequently the installation fails... The first impression
counts? How many sales are lost? As mentioned many times before, this
installation problem could be corrected easily in a few minutes (for
the downloadable version), and in my opinion it should be corrected
many months ago. Why shouldn't be? It could probably generate many
many boxes of Kylix sold in the period of the last several months. And
this is only one of many rather trivial but important problems with
how the product is presented to a potential buyer. And we are not
talking here about performance, capabilities or any other relevant
properties of the product..as yet..


juliusz

juliusz

unread,
Jul 13, 2003, 5:23:10 PM7/13/03
to
Alessandro Federici - RemObjects Software, Inc. wrote:

I most certainly disagree, any highly desired product with superior
properties, sells by itself .. just look on Linux, it does not have
multibillion dollar PR advertisement campaign, and it sells like a
hot cakes. ;-)

Ender

unread,
Jul 14, 2003, 1:19:54 AM7/14/03
to
AFR> Maybe because they were foolish and make sure the product fit their
AFR> needs using the trials Borland provided?

So you say that customer is fool because he bought a new car (that
deffinitely fit his needs according to specifications) from manufacturer
that usually sell high quality cars and car broke after 100 kilometers of
road? Even if he have a test-drive and everything seems ok?

AFR> You cannot blame Borland for everything. Bugs are in every product.

I'm not blame Borland for everything. They released buggy product. Shit
happens. Everybody know. As long as product is young it may contain many
bugs and responsibility of developer is to hear customers and to fix the
bugs. Quickly as possible. Seems for Borland it is impossible to fix bugs
because practically all bugs (except for C++) in QC section Kylix is live
from times of K1. So customers may find to impossible to buy product because
of Borland impossible to fix bugs.

I'm blaming Borland exclusively because they do not fix bugs in adequate
time. Adequate time for me - one or two months after detection of bug.
However they don't fix the bugs in the longer period of time. Of course, to
be precise, they fix very few bugs, a small percentage from total amount,
but this does not made them better in developer's eyes.

AFR> The responsibility for choosing the right tool for the job is not
AFR> in the software vendor but in the buyer.

Seems you don't catch the idea. If sales of Kylix is not good, this means
that many from those who voted for Kylix taken their responsibility for
choosing the right tool and decided do not to buy Kylix because of... see
above. Kylix 1 and following months after it's release clearly show why one
should not buy Kylix.

>> And why they should buy this product again if they see that bugs not

AFR> getting fixed in next
>> releases?

AFR> They shouldn't if the bugs stop them from producing their
AFR> end-product but I strongly doubt Kylix is that bad.

Do you work with Kylix? Areas please. Yes i know that console "Hello world"
usually executes without problems. Ah, you may visit QC also, section
[Linux].


Arthuro

unread,
Jul 14, 2003, 5:25:01 AM7/14/03
to
In borland.public.delphi.non-technical, juliusz
<juliusz...@superobject.com> wrote in message <3f123ba4
@newsgroups.borland.com>...

Hmm why then all (or perhaps with the exception of Red Hat) the Linux
distribution makers have to do much side business to make enough money to
stay afloat.
Linux of and by itself does not generate enough money for these companies..

--
***Posted by Jake's Custom Newsgroup Reader***

Posted using Jake's Super Newsreader 0.9.2.953


Buch

unread,
Jul 14, 2003, 6:48:12 AM7/14/03
to

>Will there be a CLX in Delphi 8? and if so, why?

They had QReport included for compatibility reasons, so I don't see why should they leave CLX out.

Rosimildo da Silva

unread,
Jul 14, 2003, 8:41:26 AM7/14/03
to
Alessandro Federici - RemObjects Software, Inc. wrote:

> Maybe because they were foolish and make sure the product fit their needs
> using the trials Borland provided?
> You cannot blame Borland for everything. Bugs are in every product. The
> responsibility for choosing the
> right tool for the job is not in the software vendor but in the buyer.

I hope car makers do not follow this trend in software. <G>
otherwise, I may have to take a degree in every aspect of a car. The
software indistry got to a point that only people that they do not care
about it, are the customers.

Rosimildo.

John Kaster (Borland)

unread,
Jul 14, 2003, 1:38:05 PM7/14/03
to
juliusz wrote:
> multibillion dollar PR advertisement campaign, and it sells like a hot
> cakes. ;-)

It "sells" like hot cakes?

It is certainly used a lot, like lots of other free software is used a
lot. I don't see a lot of copies of it being "sold" or the financials
from Linux distribution vendors would be quite different.


--
John Kaster, Borland Developer Relations, http://bdn.borland.com
$1280/$50K: http://homepages.borland.com/jkaster/tnt/thanks.html
Make a wish: http://qc.borland.com * Get source
http://codecentral.borland.com

Doug Chamberlin

unread,
Jul 14, 2003, 1:58:52 PM7/14/03
to
On Sun, 13 Jul 2003 21:17:24 -0500, "Alessandro Federici - RemObjects
Software, Inc." <alef....@remobjects.com> wrote:

>"Doug Chamberlin" <dchamberlinATandoversoftwareDOTcom> wrote in message
>news:6nv3hvo96e3e6a964...@4ax.com...
>
>> Are you saying the inferior quality of the final product has nothing
>> to do with it? Are you saying those people should have purchased it no
>> matter what it eventually became? What a joke.
>
>The quality of a product is also proportional to the money it generates
>since that is the most important
>aspect to decide how many resources should be put on it.

Of course.

However, the business plan has to accomodate some level of committment
to the product regardless of sales for some ignificant period of time.
Otherwise, the product dies of starvation before given a reasonable
chance. It sure looks like Borland's level of committment to Kylix has
not been adequate to fully establish the product as a credible
offering. Perhaps a business plan which is too demanding of near term
revenue?

In the case of the new language and new tool on a new platform the
level of committment needs to be larger than we have seen. Either that
or the timing of the product introduction was off and it needs to be
re-released. Either way, neglecting the product's evolution as the
required OS platform moves out from under it is a sure way to strain
the relations with the product's current customers and also keep new
customers away.

Time will tell if all this dancing in the dark was correct or not.
Only Borland knows the pertinent facts.

Brian Moelk

unread,
Jul 14, 2003, 2:13:06 PM7/14/03
to
> Kylix 1 was a major effort. If it had generated the revenues the hype
around
> Linux seemed to
> indicate, we would have seen a splendid Kylix 2 and 3. Apparently that
> wasn't the case so

There is the danger to look at these things in isolation.

Even if Kylix didn't sell well outright, which may or may not be the case,
Kylix may have well improved the existing sales and adoption of Delphi. It
is impossible to know for sure, but on some level the option for Linux
development is a feature that adds indirectly to the Windows-only Delphi
option.

I think it's important from a strategic perspective even if not widely used
to maintain Kylix and at the very least fix bugs. Which is what Borland
seems to be doing. The biggest improvement to Kylix development will be the
additional third-party support in the middleware/server side area which is
already happening regardless of what Borland does.

--
Brian Moelk
bmo...@NObrainendeavorSPAM.FORcomME
http://www.brainendeavor.com


Mamcx

unread,
Jul 14, 2003, 3:56:27 PM7/14/03
to
Support for linux take me the 40% of the decision for buy D8 when
available.. so if is not supported..arghhh!. But kill the K-guy when are so
young to prove that can do the job is not so smart...


juliusz

unread,
Jul 14, 2003, 8:17:03 AM7/14/03
to
John Kaster (Borland) wrote:
> It "sells" like hot cakes?
>
> It is certainly used a lot, like lots of other free software is used a
> lot. I don't see a lot of copies of it being "sold" or the financials
> from Linux distribution vendors would be quite different.
>

I was just metaphorically specking about "sale" of Linux as an example
of a desirable product which sells, grows, etc.., just because of its
unique properties in the context of advertisement spending.

I agree 100 percent with all you said, but Linux is not free in the
sense that, most likely, this way or another we have to pay for the
medium; it can be $1.5, $29, $150, or hundreds of dollars or just the
download cost. The real savings is on any subsequent installations of
it, in edition to the low cost of of usage. To be honest, in reality
we cannot put a definitive price tag on Linux as it is now, the same
way we cannot easily put a price on a customer relationship... I
think, Alessandro was right on the money, saying that marketing sells.
Just wonder, what could happened to the real Linux sales figures if
the product would be vigorously advertised, it probably would helped
Kylix too. ;-)

juliusz


--
InstallMade - Kylix-specific installer/builder
http://www.superobject.com/installmade/
Packages: tar.gz, self-installable, RPM, LCR,
and now creates standalone executables.
http://www.superobject.com/installmade/stalone/standalone.html

John Kaster (Borland)

unread,
Jul 14, 2003, 4:21:56 PM7/14/03
to
juliusz wrote:

> I was just metaphorically specking about "sale" of Linux as an example
> of a desirable product which sells, grows, etc.., just because of its
> unique properties in the context of advertisement spending.

Ok, tx for the clarification.

Dennis Landi

unread,
Jul 14, 2003, 7:21:05 PM7/14/03
to
"Brian Moelk" <bmo...@NObrainendeavorSPAM.FORcomME> wrote in message
news:3f12...@newsgroups.borland.com...
>

> Even if Kylix didn't sell well outright, which may or may not be the case,
> Kylix may have well improved the existing sales and adoption of Delphi.
It
> is impossible to know for sure, but on some level the option for Linux
> development is a feature that adds indirectly to the Windows-only Delphi
> option.

I think you are absolutely right. I would even go further than that. Give
the current trends (.NET), its time to deliver C++Builder for Windows and
Linux and Delphi for Windows and Linux in the same box; and just make the
whole natively compiled RAD suite just one big cross platform product since
it all hangs off of VCL/CLX, anway. THEN I WOULD COMMIT to supporting this
native compiler suite on the 64-bit platform.

I have no problem with Borland's .NET aspirations. I hope they make a ton
of money. But there is still a market for native compilers. At least for
the next 3 to 5 years and much longer on Linux.

-dennis


Danny Thorpe

unread,
Jul 14, 2003, 9:32:18 PM7/14/03
to
"Kristofer Skaug" <ya.ierfgnf@thnxf.x> wrote in message
news:3f105832$1...@newsgroups.borland.com...
>
> Is Linux still a target platform for Borland (and I don't mean Java) in
the
> next couple of years?
>

Yes, Linux is still a target platform for Borland. Long live Kylix, and
long live JBuilder.

Kylix is a long term investment for Borland just as JBuilder was a long term
investment in its infancy. We don't expect to see overnight financial
success from a market that is still in the "emergence" phase. When the
Linux market picks up speed, Kylix will be swept up with it, just as
JBuilder rode on the coattails of the Java market surge.

Kylix is on a development schedule proportionate to its revenue, as are
nearly all Borland products. That means Kylix may not be updated as
frequently as Delphi for Win32, or Borland may not assign as many people to
work on the next Kylix release as on the next Delphi for Win32 release.
That does not imply Borland is withdrawing from the Linux tools market. It
simply means Borland is managing its resources as any responsible,
profitable business should.

Kylix is the #1 most-used IDE for Linux application development. Period.
(Evans Data Corp, Linux Developer Survey, Fall 2001) Kylix achieved a major
share of that market within only a few months of its first release, and it
has maintained that top position ever since.

Borland has no plans to squander that hard-earned market position.

-Danny Thorpe
Compiler Architect, RAD Tools Group
Borland Software Corp.


Sebastian Moleski

unread,
Jul 14, 2003, 10:09:03 PM7/14/03
to
"Danny Thorpe" <nom...@borland.com> wrote in message
news:3f13595b$1...@newsgroups.borland.com...

> Kylix is the #1 most-used IDE for Linux application development. Period.
> (Evans Data Corp, Linux Developer Survey, Fall 2001) Kylix achieved a major
> share of that market within only a few months of its first release, and it
> has maintained that top position ever since.
>
> Borland has no plans to squander that hard-earned market position.

Besides, doing so would fly in the face of the considerable investments Borland
had to make when creating Kylix and CLX in the first place. Considering that it
didn't exactly happen over night, I would be surprised if Borland gave up that
quickly. This becomes even more true if one remembers that most Borland products
didn't exactly start off as money makes but matured into solid products with a
profitable market share.

sm


juliusz

unread,
Jul 14, 2003, 3:36:38 PM7/14/03
to
Danny Thorpe wrote:
> Yes, Linux is still a target platform for Borland. Long live Kylix, and
> long live JBuilder.
>
> Kylix is a long term investment for Borland just as JBuilder was a long term
> investment in its infancy. We don't expect to see overnight financial
> success from a market that is still in the "emergence" phase. When the
> Linux market picks up speed, Kylix will be swept up with it, just as
> JBuilder rode on the coattails of the Java market surge.
>
> Kylix is on a development schedule proportionate to its revenue, as are
> nearly all Borland products. That means Kylix may not be updated as
> frequently as Delphi for Win32, or Borland may not assign as many people to
> work on the next Kylix release as on the next Delphi for Win32 release.
> That does not imply Borland is withdrawing from the Linux tools market. It
> simply means Borland is managing its resources as any responsible,
> profitable business should.
>
> Kylix is the #1 most-used IDE for Linux application development. Period.
> (Evans Data Corp, Linux Developer Survey, Fall 2001) Kylix achieved a major
> share of that market within only a few months of its first release, and it
> has maintained that top position ever since.
>
> Borland has no plans to squander that hard-earned market position.
>
> -Danny Thorpe
> Compiler Architect, RAD Tools Group
> Borland Software Corp.
>


Bravo, that's the spirit!. It surely sounds like a beginning of a
very difficult but undoubtedly very fruitful endeavor. Once more,
Borland, this often underestimated company, showed business
integrity, so rare qualities in today's corporate world.

Thank You.

juliusz

--
InstallMade - Kylix-specific installer/builder
http://www.superobject.com/installmade/
Packages: tar.gz, self-installable, RPM, LCR,

and creates standalone executables.

Ingvar Nilsen

unread,
Jul 15, 2003, 12:14:39 AM7/15/03
to
Paul Qualls wrote:

> Borland didn't kill Kylix. All the people that responded to early surveys
> stating that they wanted and would buy Kylix then didn't purchase - killed


Paul,
what people did Borland ask? Developers?
Developers do not decide whether to buy Kylix or not, managers do.
I find it hard to believe Borland asked developers only about this.

Borland could impossibly have made its decisions on such a unqualified
"marketing analysis". It is a big difference in saying "yes it would
be nice with a Linux tool" and then cough up the money the day it is
released.

--
Ingvar Nilsen

Paul Lambadaris

unread,
Jul 15, 2003, 4:17:39 AM7/15/03
to
In article <3f13595b$1...@newsgroups.borland.com>, nom...@borland.com
says...

>
> Yes, Linux is still a target platform for Borland. Long live Kylix, and
> long live JBuilder.
>
> Kylix is a long term investment for Borland just as JBuilder was a long term
> investment in its infancy. We don't expect to see overnight financial
>
> -Danny Thorpe
> Compiler Architect, RAD Tools Group
> Borland Software Corp.
>

Thanks for the info Danny, you said more than any other official.

-------------------------------
Paul Lambadaris
Delta Singular S.A.
mailto : p...@NOSPAMsingular.gr
www : http://www.singular.gr

Phil Shrimpton

unread,
Jul 15, 2003, 4:47:06 AM7/15/03
to
In article <3f13595b$1...@newsgroups.borland.com>, Danny Thorpe says...

Hi,

> Yes, Linux is still a target platform for Borland. Long live Kylix

Excellent statement, give the man a job in customer relations <g>

> Kylix is on a development schedule proportionate to its revenue, as are
> nearly all Borland products. That means Kylix may not be updated as
> frequently as Delphi for Win32, or Borland may not assign as many people to
> work on the next Kylix release as on the next Delphi for Win32 release.

This is a classic "chicken and egg" situation. Kylix, for a number of
people, for a number of reasons, is not 'suitable for use', so these
people are not purchasing, not upgrading, or cutting there losses and
running to an alternative. This means decreased revenue for Borland,
and thus, according to your above statement, longer release cycles and
less development staff. In order to keep these people, Borland needs to
increase the release cycles and assign more staff, but according to the
above statement, that is dependant on the revenue.

Phil

Dennis Landi

unread,
Jul 15, 2003, 8:49:52 AM7/15/03
to

"Phil Shrimpton" <ph...@nospam.co.uk> wrote in message
news:MPG.197dcfe88...@newsgroups.borland.com...

> This is a classic "chicken and egg" situation. Kylix, for a number of
> people, for a number of reasons, is not 'suitable for use', so these
> people are not purchasing, not upgrading, or cutting there losses and
> running to an alternative. This means decreased revenue for Borland,
> and thus, according to your above statement, longer release cycles and
> less development staff. In order to keep these people, Borland needs to
> increase the release cycles and assign more staff, but according to the
> above statement, that is dependant on the revenue.

Borland you can take a leadership role in the Linux world. Announce your
intention for a Kylix64 (initially AMD-only will work) and a commitment to
server-side development and watch the converts roll in! Few of the converts
will be coming from the MS side of the fence so you win on both sides. (and
get a mini-release/patch schedule going to keep pace with the linux vendors
distro releases...)


Michael Schnell

unread,
Jul 15, 2003, 9:08:46 AM7/15/03
to
>> I also believed it is nice to have the Object Pascal (Delphi language)
> compatibility with the Win32 Delphi but my idea is that this strategy
> doomed a bit the Kylix project because of the Linux people natural feel for
> C++ and that that appeals mostly to current Delphi developers not taking
> care of the Linux developers, the normal target.

IMHO many of the today's Windows developers are tomorrow's Linux
developers, as Microsoft's license strategy to come will force many
customers away from Windows due to high prices, security problems (see
e.g. XP EULA that allows MS to look into your PC and change things
without asking you and not being reliable for any damage done) and
creating ab X-BOX like PC market with dedicated MS-approved hardware,
software and encrypted document formats not readable by non MS products
and older or not newly licensed MS products.

-Michael

Michael Schnell

unread,
Jul 15, 2003, 9:39:20 AM7/15/03
to
> Kylix is on a development schedule proportionate to its revenue, as are
> nearly all Borland products. That means Kylix may not be updated as
> frequently as Delphi for Win32, or Borland may not assign as many people to
> work on the next Kylix release as on the next Delphi for Win32 release.
> That does not imply Borland is withdrawing from the Linux tools market. It
> simply means Borland is managing its resources as any responsible,
> profitable business should.
>

Read

http://aaxnet.com/editor/edit029.html

to find that many users and with them many developers will move from
Windows to Linux in the near future.

-Michael

Kristofer Skaug

unread,
Jul 15, 2003, 10:27:59 AM7/15/03
to
"Danny Thorpe" wrote

>
> Yes, Linux is still a target platform for Borland. Long live Kylix,

Thanks Danny, that's exactly the kind of statement I was hoping for!
Of course we do not assume that you speak officially for Borland policy
here, but by the assertiveness of your words, it would seem unlikely that
you were strongly at odds with the company baseline in this matter.

Kristofer


Ingvar Nilsen

unread,
Jul 15, 2003, 6:18:32 PM7/15/03
to
Danny Thorpe wrote:

> Kylix is on a development schedule proportionate to its revenue, as are

[..]

> Kylix is the #1 most-used IDE for Linux application development. Period.

[..]


> Borland has no plans to squander that hard-earned market position.

Danny,
while some of your points are inevitable and obvious, it is really
reassuring to read what you say. Borland is still Borland :) I hope as
many as possible have read your post. Thank you!

--
Ingvar Nilsen

Danny Thorpe

unread,
Jul 16, 2003, 12:41:29 AM7/16/03
to
> Danny,
> while some of your points are inevitable and obvious, it is really
> reassuring to read what you say. Borland is still Borland :) I hope as
> many as possible have read your post. Thank you!
>

Ingvar,

My high school science teacher always said I had a brilliant grasp of the
obvious. :>

-Danny


Ender

unread,
Jul 16, 2003, 2:17:53 AM7/16/03
to
Michael Schnell wrote:
> IMHO many of the today's Windows developers are tomorrow's Linux
> developers, as Microsoft's license strategy to come will force many
> customers away from Windows due to high prices, security problems (see
> e.g. XP EULA that allows MS to look into your PC and change things
> without asking you and not being reliable for any damage done) and
> creating ab X-BOX like PC market with dedicated MS-approved hardware,
> software and encrypted document formats not readable by non MS products
> and older or not newly licensed MS products.

Do not forget that many of Windows developers even don't thinking about
Linux as possible target. IMHO most of Windows developers don't think about
Linux.

Michael Schnell

unread,
Jul 16, 2003, 2:29:32 AM7/16/03
to Ender
> Do not forget that many of Windows developers even don't thinking about
> Linux as possible target. IMHO most of Windows developers don't think about
> Linux.

They will need to as soon as their customers start to move. I hope that
Borland will offer a decent pass for their customers.

Time will tell <g>

-Michael

Brion L. Webster

unread,
Jul 16, 2003, 12:37:34 PM7/16/03
to
"Phil Shrimpton" <ph...@nospam.co.uk> wrote...

> Excellent statement, give the man a job in customer relations <g>

Oh, no, please keep him right where he is! I like the products he's
responsible, and taking away any of that time for fluff like this would only
increase my short-term happiness at the expense of my long-term happiness!

Unless that cloning adults thing is finally working...or he can function just
as well with zero sleep or personal life <g>

--
-Brion
Team JEDI, 2001 Spirit of Delphi Award Winners
http://www.delphi-jedi.org
Fresno Area Delphi Users Group
http://groups.yahoo.com/group/FresnoDelphi


Simon Kissel

unread,
Jul 17, 2003, 11:57:45 AM7/17/03
to
Danny Thorpe (nom...@borland.com) wrote:

>
> "Kristofer Skaug" <ya.ierfgnf@thnxf.x> wrote in message
> news:3f105832$1...@newsgroups.borland.com...
> >
> > Is Linux still a target platform for Borland (and I don't mean Java) in
> the
> > next couple of years?
> >
>
> Yes, Linux is still a target platform for Borland. Long live Kylix, and

Thank you for this statement :)

Simon

Oliver Feins

unread,
Jul 19, 2003, 5:08:45 PM7/19/03
to
Hi Ender,

> OF> Now, to me, what Borland should do or have done with Kylix is what
> OF> it _is_
> OF> doing now with .Net. That is, releasing a top class IDE over a
> OF> foreign compiler (MS .NET or GNU GCC or GCJ).
>
>I think this is impossible. GNU Pascal & GNU C++ does not inclue some
>key features actively used by Borland in their libraries. For example
>"finally" clause.

Yep, there is the 'finally' problem but it is possible to write exceptions
catching code without it. And isn't 'finally' finally! integrated into GCC
C++ now ? I remember some debate about it.

But, I agree with you, it makes things more difficult. Using wxWindows
instead of Qt would also have made things more difficult but at the end, if
it is to have a product that is bought and used by the developers, it is
worth it.

To me, the great value of Delphi on Windows is the VCL (I know it is a bit
aging now but it is still much better, cleaner and easier than MFC and it
does the job well) and the ability to write components in a very easy way
which opened a nice 3rd party market. We would need a Delphi-like IDE for
Linux with the GCC C++ compiler as a back-end and compatibility with the
existing VCL interface-wise.

> OF> If Borland had developed a first class IDE over GCC or GCJ, Kylix
> OF> would be further away than it is today in term of market share and
> OF> adoptance. Most
> OF> Linux developers are C++ developers.
>
>Not exactly. Many of them are "plain C developers". :-) Just to be
>precise.

Yep, I know I did simplify about C and C++. To do RAD and GUI applications,
C++ is nonetheless the obvious choice for me on Linux.

>
>How about some core language features like interfaces, only heap
>objects, managed strings? I don't think that it will be easy.

To me, the idea is not to build an exact replica of Delphi with GCC but to
offer a first class Delphi-like environment (IDE, libraries...) for GCC.
Surely, we would miss some features but are those absolutely necessary for
building GUI and C/S applications in a RAD way ?

Regards,

Oliver

Brian Moelk

unread,
Jul 21, 2003, 2:55:35 PM7/21/03
to
> Yep, there is the 'finally' problem but it is possible to write exceptions
> catching code without it. And isn't 'finally' finally! integrated into GCC
> C++ now ? I remember some debate about it.

C++ follows the principle of RAII and therefore finally will probably never
be part of the C++ standard. STL's auto_ptr's and boost's additional Smart
Pointer Library round out C++'s concern on this matter.

I don't know anything about GNU Pascal, but without a "try...finally"
statement or reference counted interfaces writing exception safe code would
be onerous.

Ender

unread,
Jul 21, 2003, 1:52:45 PM7/21/03
to
>> I think this is impossible. GNU Pascal & GNU C++ does not inclue some
>> key features actively used by Borland in their libraries. For example
>> "finally" clause.

OF> Yep, there is the 'finally' problem but it is possible to write
OF> exceptions catching code without it. And isn't 'finally' finally!
OF> integrated into GCC
OF> C++ now ? I remember some debate about it.

No. Not integrated.

OF> But, I agree with you, it makes things more difficult. Using
OF> wxWindows instead of Qt would also have made things more difficult
OF> but at the end, if it is to have a product that is bought and used
OF> by the developers, it is worth it.

I exchange with few letters with one of participants of C++ standard group.
He said that this question was already debated and they decided not to
include 'finally' into language specification. Just because "everything can
be written without it". I'm not so good in English and in C++ to debate with
bunch of guys who deffinitely know both these languages better than i'm.
Additionally they has their own points of view that have nothing with my
points of view about "usefullness" of this feature.

>> How about some core language features like interfaces, only heap
>> objects, managed strings? I don't think that it will be easy.

OF> To me, the idea is not to build an exact replica of Delphi with GCC
OF> but to offer a first class Delphi-like environment (IDE,
OF> libraries...) for GCC.
OF> Surely, we would miss some features but are those absolutely
OF> necessary for building GUI and C/S applications in a RAD way ?

Maybe not. But many of these features is very useful. One of good things in
commercial software companies is that they do things not because of purity
of language or ideas but because of desire of customers.


Ender

unread,
Jul 21, 2003, 11:41:54 PM7/21/03
to
>> Yep, there is the 'finally' problem but it is possible to write
>> exceptions catching code without it. And isn't 'finally' finally!
>> integrated into GCC
>> C++ now ? I remember some debate about it.

BM> C++ follows the principle of RAII and therefore finally will
BM> probably never be part of the C++ standard. STL's auto_ptr's and
BM> boost's additional Smart
BM> Pointer Library round out C++'s concern on this matter.

Can you provide a small example how people implement open/close operations
on dataset without finally?

For example in Delphi it will be:

DataSet.Open;
try
// do something with dataset
finally
DataSet.Close;
end;

... pretty simple thing.

Now please same thing with C++ without finally.


Brian Moelk

unread,
Jul 22, 2003, 9:02:04 AM7/22/03
to
> Can you provide a small example how people implement open/close operations
> on dataset without finally?

Sure. Disclaimer: I'm a bit rusty with my C++ and I don't use C++Builder so
the TDataSet type may not be quite correct. You create a class like:

class CDataSetClose
{
public:
explicit CDataSetClose (TDataSet* aDataSet): m_DataSet(aDataSet)
{ m_DataSet->Open(); };
~CDataSetClose () { m_DataSet->Close(); };
private:
TDataSet* m_DataSet;
};

Then you just use it in your code:

int main()
{
CDataSetClose myDataSet(DataSet); //The DataSet is opened on the
constructor


// do something with dataset

return 0;
} //here the DataSet is closed

> Now please same thing with C++ without finally.

There is no finally in the code above and is not needed; CDataSetClose is
allocated on the stack and its destructor will be invoked when the stack is
unwound.

Brian Moelk

unread,
Jul 22, 2003, 9:20:23 AM7/22/03
to
I should have also made the copy constructor and assignment operator
private:

> class CDataSetClose
> {
> public:
> explicit CDataSetClose (TDataSet* aDataSet): m_DataSet(aDataSet)
> { m_DataSet->Open(); };
> ~CDataSetClose () { m_DataSet->Close(); };
> private:
> TDataSet* m_DataSet;

//no copying
CDataSetClose(const CDataSetClose& aDataSetClose) {};
//no assigning
CDataSetClose& operator=(const CDataSetClose& rhsDataSetClose) {};
> };

Scott Metzger

unread,
Jul 22, 2003, 1:57:54 PM7/22/03
to
Ender wrote:
> For example in Delphi it will be:
>
> DataSet.Open;
> try
> // do something with dataset
> finally
> DataSet.Close;
> end;
>
> ... pretty simple thing.
>
> Now please same thing with C++ without finally.
>
>

DataSet->Open();


try
{
// do something with dataset
}

catch(...) // the ... catches everything :)
{
DataSet->Close;
}


Dave Nottage (TeamB)

unread,
Jul 22, 2003, 2:49:37 PM7/22/03
to
Scott Metzger wrote:
>
> DataSet->Open();
> try
> {
> // do something with dataset
> }
> catch(...) // the ... catches everything :)

Even *no* exception?

> {
> DataSet->Close;
> }

--
Dave Nottage (TeamB)


Ender

unread,
Jul 22, 2003, 2:09:38 PM7/22/03
to
>> Can you provide a small example how people implement open/close
>> operations on dataset without finally?

BM> There is no finally in the code above and is not needed;
BM> CDataSetClose is allocated on the stack and its destructor will be
BM> invoked when the stack is unwound.

You made things as i expected. You created entrie class just for one
operation. Another class for another similar (resource lock/unlock)
operation. Third class for managing cursor state (crHourGlass/crDefault) and
so on... That's bad. "finally" concept simple and far more straight that
this game with classes.

Of course there is possibility to never use such schemes. Just never throw
exception.


Ender

unread,
Jul 23, 2003, 12:24:07 AM7/23/03
to
SM> DataSet->Open();
SM> try {
SM> // do something with dataset }
SM> catch(...) // the ... catches everything :)
SM> {
SM> DataSet->Close;
SM> }

Even if there no exception? :-)


Brian Moelk

unread,
Jul 23, 2003, 8:57:04 AM7/23/03
to
> You made things as i expected. You created entrie class just for one
> operation. Another class for another similar (resource lock/unlock)
> operation. Third class for managing cursor state (crHourGlass/crDefault)
and
> so on... That's bad.

Why is that bad? Exceeds your class quota? Overflows your application's
class buffer?

I don't agree with your argument, but there are things you can do in C++ to
mitigate/generalize: smart pointers and template based resource managers.

> "finally" concept simple and far more straight that
> this game with classes.

I can easily argue (and C++ devs would) that placing "try...finally"
statements around every allocation statement is a PITA and that RAII is more
straightforward. The argument is simple: you write a class *once* and use
it throughout your code rather than writing "try...finally" statements for
each and every resource acquisition.

I don't necessarily agree, but I understand their perspective and could
argue that point. <g>

In C++ you typically allocate on the stack, use smart pointers, or you wrap
the resource allocation/deallocation in a class as I've done. It's just a
different style for different languages; C++ devs see no need for a finally
statement and the fact is that there is no *need*. Some believe that a
"try...finally" is more straightforward, others do not.

> Of course there is possibility to never use such schemes. Just never throw
> exception.

IMO, exceptions are a powerful tool that should be used. Not an option.

Ender

unread,
Jul 23, 2003, 2:51:07 PM7/23/03
to
BM> Why is that bad? Exceeds your class quota? Overflows your
BM> application's class buffer?

It is that bad because it:
1. Offers some _not_simple_, not _straightforwad_ way.
2. Forces to write more code than necessary.
3. Increases count of program entities which usually makes program more
complex and less suited for understanding and support.

BM> I don't agree with your argument, but there are things you can do in
BM> C++ to mitigate/generalize: smart pointers and template based
BM> resource managers.

>> "finally" concept simple and far more straight that this game with
>> classes.

BM> I can easily argue (and C++ devs would) that placing "try...finally"
BM> statements around every allocation statement is a PITA and that RAII
BM> is more straightforward. The argument is simple: you write a class
BM> *once* and use it throughout your code rather than writing
BM> "try...finally" statements for each and every resource acquisition.
BM> I don't necessarily agree, but I understand their perspective and
BM> could argue that point. <g>

I just see result of this apporach. Most of Delphi-based apps fighthing to
death and often survive even EAccessViolation, which helps to save work.
Most of C/C++ based apps calls Dr.Watson and crashing. :-)

BM> In C++ you typically allocate on the stack, use smart pointers, or
BM> you wrap the resource allocation/deallocation in a class as I've
BM> done. It's just a different style for different languages; C++ devs
BM> see no need for a finally statement and the fact is that there is no
BM> *need*. Some believe that a "try...finally" is more
BM> straightforward, others do not.

So you said this again. You need additional class for each type of
operation.

>> Of course there is possibility to never use such schemes. Just never
>> throw exception.

BM> IMO, exceptions are a powerful tool that should be used. Not an
BM> option.

I'm asked my familiar C++ developers about exception handling and found that
they desperately trying do not touch this "plague zone". When there is
selection between returning result as code or throw exception they always
choose code. Guess why? ;-)


Brian Moelk

unread,
Jul 23, 2003, 4:10:14 PM7/23/03
to
> It is that bad because it:
> 1. Offers some _not_simple_, not _straightforwad_ way.

IMO, this depends on your reference point. RAII is simple and
straightforward if you are accustomed to it. Also, if you don't clearly
understand stack-based allocation, then it will be confusing.

> 2. Forces to write more code than necessary.

Depends. If you only have one instance of the resource
allocation/deallocation, yes perhaps you write more code in C++. But, if
you have hundreds of places in your code where you allocate and deallocate
resources, you will write less code. In the latter case, I typically use
Interfaces in Delphi to accomplish the exact same thing as C++ does.

> 3. Increases count of program entities which usually makes program more
> complex and less suited for understanding and support.

Nonsense. Is the VCL more difficult to understand because of its size? is
it less suited for understanding and support as it grows? IMO, it has to do
with how the abstractions are done not the number of them.

> I just see result of this apporach. Most of Delphi-based apps fighthing to
> death and often survive even EAccessViolation, which helps to save work.
> Most of C/C++ based apps calls Dr.Watson and crashing. :-)

This has nothing to do with a try...finally statement. It has to do with
catching exceptions at the outer most layer. A properly written C++
application is just as stable as a Delphi application; Delphi just gives you
more out of the box.

> I'm asked my familiar C++ developers about exception handling and found
that
> they desperately trying do not touch this "plague zone". When there is
> selection between returning result as code or throw exception they always
> choose code. Guess why? ;-)

Nonsense. The C++ developers I know overwhelmingly prefer and advocate
exceptions over return codes. C developers (that are using a C++ compiler)
OTOH, prefer return codes because that's the only option in C.

Ender

unread,
Jul 24, 2003, 5:00:40 PM7/24/03
to
BM> IMO, this depends on your reference point. RAII is simple and
BM> straightforward if you are accustomed to it. Also, if you don't
BM> clearly understand stack-based allocation, then it will be
BM> confusing.

Yes! That's i'm trying to say. You need to format your brains to some ideas
belong to someone else, while Delphi uses both ways. This completely looks
no good. Language dictates to you some way of thinking instead of express
your thoughts. Just remember JCL Guards. It offer same mechanics as C++
stack based stuff. But people keep using finally. Just because it is simply
and easy to track and understand what you doing and where.

>> 2. Forces to write more code than necessary.

BM> Depends. If you only have one instance of the resource
BM> allocation/deallocation, yes perhaps you write more code in C++.
BM> But, if you have hundreds of places in your code where you allocate
BM> and deallocate resources, you will write less code. In the latter
BM> case, I typically use
BM> Interfaces in Delphi to accomplish the exact same thing as C++ does.

No. There is no developers that only allocate and deallocate something.
There is many _different_ situations when object should be returned to some
state not counting what was happened. Stack based objects offer to write
object on each type of operation. And moreover - you actually not control
order of finalization unless you write additional code. This is not good.
This just creates not necessary work. And language is deffinitely guilty.

>> 3. Increases count of program entities which usually makes program
>> more complex and less suited for understanding and support.

BM> Nonsense.

You don't agree that increasing count of entities in program is bad? You
don't agree with idea that programs should be simple? If yes, i'm stopping
discussion right now.

BM> Is the VCL more difficult to understand because of its size?

Yes. Have you read how much things was hidden under VCL coat?
For me there is no problem to trace VCL. But most heavy thing that VCL is
adptation of some brilliant ideas to the Windows reality. The most
idealogically clear thing was TurboVision.

BM> is it less suited for understanding and support as it grows? IMO, it
BM> has to do with how the abstractions are done not the number of them.

As i said before, VCL is not best example of OOD.

>> I just see result of this apporach. Most of Delphi-based apps
>> fighthing to death and often survive even EAccessViolation, which
>> helps to save work.
>> Most of C/C++ based apps calls Dr.Watson and crashing. :-)

BM> This has nothing to do with a try...finally statement. It has to do
BM> with catching exceptions at the outer most layer.

This has something with careful and reasonable resource and object state
management.

BM> A properly written C++
BM> application is just as stable as a Delphi application; Delphi just
BM> gives you more out of the box.

Then why such bad reality?

>> I'm asked my familiar C++ developers about exception handling and
>> found

BM> that


>> they desperately trying do not touch this "plague zone". When there
>> is selection between returning result as code or throw exception they
>> always choose code. Guess why? ;-)

BM> Nonsense. The C++ developers I know overwhelmingly prefer and
BM> advocate exceptions over return codes. C developers (that are using
BM> a C++ compiler)
BM> OTOH, prefer return codes because that's the only option in C.

Seems we rotate in different circles.


Brian Moelk

unread,
Jul 25, 2003, 7:37:48 AM7/25/03
to
> your thoughts. Just remember JCL Guards. It offer same mechanics as C++
> stack based stuff. But people keep using finally. Just because it is
simply
> and easy to track and understand what you doing and where.

In the case of Interfaces, it's more about what people are used to and
understand rather than clarity IMO. Some Delphi programmers don't really
understand Interfaces.

> No. There is no developers that only allocate and deallocate something.
> There is many _different_ situations when object should be returned to
some
> state not counting what was happened. Stack based objects offer to write
> object on each type of operation.

Sure, but anything more than trivial state I tend to wrap up in classes
anyway, even in Delphi. Again, I don't really see the *need* to minimize
the number of classes. If the problem is complicated, then the solution
must implement that complexity at a reasonable level; i.e. more code and
classes are required.

> And moreover - you actually not control
> order of finalization unless you write additional code. This is not good.
> This just creates not necessary work. And language is deffinitely guilty.

AFAIK this is not true, the stack will unwind as a stack. IOW, the
deallocation happens in a predictable order, the reverse of the allocation
order. Static initialization and finalization order is not defined, but
that's different.

> You don't agree that increasing count of entities in program is bad? You
> don't agree with idea that programs should be simple? If yes, i'm stopping
> discussion right now.

No I don't agree. Increasing the quantity of classes is not necessarily
bad. I do agree that programs should be simple, however IMO the number of
classes does not equal simplicity. In some cases the more classes you have,
the simpler the overall design becomes. To say with certainty that as you
increase the number of classes you increase complexity is, IMO, nonsense.

> This has something with careful and reasonable resource and object state
> management.

IMO, not really. This has to do with understanding the language that you
are using and testing properly.

> BM> A properly written C++
> BM> application is just as stable as a Delphi application; Delphi just
> BM> gives you more out of the box.
>
> Then why such bad reality?

C++ is a more complex language than Delphi. Some developers using C++ don't
understand C++, some developers using Delphi don't understand Delphi. If
you make a mistake in C++, the consequences are typically more harsh than
mistakes made in Delphi. This has nothing to do with the try...finally
statement however.

The fact is that MSVC and I believe that C++Builder both support
try...finally statements but do they produce more stable applications?
Apparently not, in your experience.

> BM> Nonsense. The C++ developers I know overwhelmingly prefer and
> BM> advocate exceptions over return codes. C developers (that are using
> BM> a C++ compiler)
> BM> OTOH, prefer return codes because that's the only option in C.
>
> Seems we rotate in different circles.

Very much so; the C++ standards committee seems to as well.

--
Brian Moelk
bmoe...@SPAMbrainendeavorFOR.MEcom
http://www.brainendeavor.com


0 new messages