 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Des O'Toole
Guest
|
 Posted: Tue Apr 13, 2004 5:53 pm Post subject: Delphi/BCB Integration (Part 2) |
 |
|
After starting a recent thread and creating a couple of QC entries (#7837 &
#7838) suggesting the integration of Delphi and BCB I'd just like to
address some of the issues raised and re-iterate why I think the merging of
Delphi and BCB would be the best way forward (for BCB users, Delphi users
and even Borland themselves).
Issue: Is it technically possible?
-------------------------------
The answer to this has obviously got to be yes. BCB can already compile both
Delphi and C++ code, in fact it could even be argued that it would make more
sense to integrate Delphi into BCB. Undoubtably there are issues that would
need to be solved to provide a more harmonious marriage, but BCB has proved
that it can work. I would suggest that with a bit of creative thinking, and
a few leaps of faith, they could create a very efficient
interpret/compile/link model. Maybe the end result wouldn't quite be the
traditional C++ or Delphi method (obj,dcu etc), but it could still be a very
efficient way of creating VCL/.NET apps using as much traditional
methodology as possible.
Issue: Would it be cost effective for Borland?
---------------------------------------------
Again I would have to argue, Yes. It naturally follows that if Delphi were
to encompass BCB they would generate a lot more Delphi sales. The only
potential revenue they would miss out on is from those who currently need to
buy both Delphi AND BCB. One could argue that even this would be negated by
the fact that they could expect current BCB users to buy a completely new
product (ie Delphi). The follow on benefit to Borland would be that as well
as reducing development/marketing costs, Delphi would be a much stronger
package, one that would cause many new developers to sit up and take notice.
Issue: But It's not C++ enough
-------------------------------
There are many BCB users out there who have always hated the fact that the
VCL was not written in C++ and have been very vocal in asking Borland to
rewrite it. I would respectfully suggest that BCB was never REALLY the
product for them. It was just a stop gap until something 'proper' came
along. Hopefully CBX will turn out to be what they really want and need, it
does seem as though Borland are really targetting the C++ purist with this -
C++ framework, multiple compilers, multi platform etc. - I hope it all works
out. To these people I would suggest that Delphi/BCB integration is in their
interests too. Do they really want CBX developers spending precious time
providing the much requested VCL integration?
What are the benefits of integration?
--------------------------------------
Where to begin? Anyone who has used BCB over any period of time will know
that we have been the poor relations to our Delphi cousins. BCB has always
lagged behind Delphi development. 3rd party developers often omit support
for BCB. Bug fixes have seemed to have a much lower priority than Delphi's.
An ambidextrous Delphi should solve all of this. If, at the end of the day,
rather than having a dedicated C++ compiler, I had an extremely RAD VCL/.NET
tool that compiled the vast majority of my C++ code and was well supported,
then I would be completely satisfied. If I needed a 100% compliant, multi
platform, dedicated C++ development tool, then I would have the option of
using CBX.
Can voting make a difference?
-----------------------------
This is more difficult to answer. Borland have been playing their cards
close to their chest (excessively so, I think everyone would agree). However
Robert Ehteshamzadeh (Borland) left some tantalising hints that just such a
product may already be in development. If this is the case, then it can do
no harm whatsoever in letting Borland know (through QC) that such a product
would be welcomed with open arms and should not be delayed a moment longer
than necessary.
In conclusion
-------------
I know everyone will have their own opinion on exactly what Borland ought to
be doing, but think it through, would you like the option of 2 C++ products,
a RAD VCL Windows tool enjoying all the support of Borland's flagship
product AND a serious, highbrow C++ Compiler with CBX. If you agree with me,
vote for issues 7837 and/or 7838 on QC. (Remember you can even use ALL your
5 Delphi votes without affecting any existing BCB votes that are already
spoken for.
Thanks for listening
Des
|
|
| Back to top |
|
 |
Jeff Overcash (TeamB)
Guest
|
| Posted: Tue Apr 13, 2004 6:12 pm Post subject: Re: Delphi/BCB Integration (Part 2) |
|
|
Des O'Toole wrote:
| Quote: |
Issue: Would it be cost effective for Borland?
---------------------------------------------
Again I would have to argue, Yes. It naturally follows that if Delphi were
to encompass BCB they would generate a lot more Delphi sales.
|
BCB is a fraction of the sales of Delphi. It would not garner a lot more
sales. If you increase the price for C++ features then you might even lower
sales as you drive away Delphi users who don't need C++ and don't want to pay
for features they have no need for (the vast majority). If you keep the price
the same for Delphi today you are further reducing the revenue generated by BCB
by all the people that bought both products who now get the C++ part for free.
| Quote: | The only
potential revenue they would miss out on is from those who currently need to
buy both Delphi AND BCB.
|
Which is a large cross section.
| Quote: | One could argue that even this would be negated by
the fact that they could expect current BCB users to buy a completely new
product (ie Delphi). The follow on benefit to Borland would be that as well
as reducing development/marketing costs, Delphi would be a much stronger
package, one that would cause many new developers to sit up and take notice.
|
Resource wise you save nothing. BCB and Delphi (7 and lower) already shared an
IDE so you are still talking about sharing an IDE so the IDE resources stay
roughly the same. Documentation - same resources. VCL - same resources.
Compiler - same resources. I have yet to find a single resource that you think
will be saved by this. There was plenty of overlap before and the ROI was poor
for BCB, the overlap and non overlap is still roughly the same with this idea as
it was before with less overall revenue generated.
| Quote: |
Issue: But It's not C++ enough
-------------------------------
There are many BCB users out there who have always hated the fact that the
VCL was not written in C++ and have been very vocal in asking Borland to
rewrite it. I would respectfully suggest that BCB was never REALLY the
product for them. It was just a stop gap until something 'proper' came
along. Hopefully CBX will turn out to be what they really want and need, it
does seem as though Borland are really targetting the C++ purist with this -
C++ framework, multiple compilers, multi platform etc. - I hope it all works
out. To these people I would suggest that Delphi/BCB integration is in their
interests too. Do they really want CBX developers spending precious time
providing the much requested VCL integration?
|
It makes no sense at all for Borland to pull the Delphi resources (which give a
great ROI) and place them on BCB which gives them a low ROI. I can see why you
as a BCB user would love this, but it makes absolutely no business sense for
Borland.
| Quote: |
What are the benefits of integration?
--------------------------------------
Where to begin? Anyone who has used BCB over any period of time will know
that we have been the poor relations to our Delphi cousins. BCB has always
lagged behind Delphi development. 3rd party developers often omit support
for BCB. Bug fixes have seemed to have a much lower priority than Delphi's.
An ambidextrous Delphi should solve all of this. If, at the end of the day,
rather than having a dedicated C++ compiler, I had an extremely RAD VCL/.NET
tool that compiled the vast majority of my C++ code and was well supported,
then I would be completely satisfied. If I needed a 100% compliant, multi
platform, dedicated C++ development tool, then I would have the option of
using CBX.
|
Not a single benefit for Delphi users nor for that matter Borland. It would be
an increase on resources that would be taken away from Delphi to give to C++
when once again the good ROI is on the Delphi side.
--
Jeff Overcash (TeamB)
(Please do not email me directly unless asked. Thank You)
A human being should be able to change a diaper, plan an invasion, butcher
a hog, conn a ship, design a building, write a sonnet, balance accounts, build
a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act
alone, solve equations, analyze a new problem, pitch manure, program a computer,
cook a tasty meal, fight efficiently, die gallantly. Specialization is for
insects. (RAH)
|
|
| Back to top |
|
|
Des O'Toole
Guest
|
| Posted: Tue Apr 13, 2004 6:41 pm Post subject: Re: Delphi/BCB Integration (Part 2) |
|
|
Hi Jeff
"Jeff Overcash (TeamB)" <jeffovercash (AT) mindspring (DOT) com> wrote
| Quote: | The only
potential revenue they would miss out on is from those who currently
need to
buy both Delphi AND BCB.
Which is a large cross section.
|
IS a large cross section or WAS a large cross section? I can't envisage many
developers rushing to buy a discontinued product. All my comments were based
on the fact that BCB has been discontinued and the VCL in BCBX is very much
in question.
| Quote: | Resource wise you save nothing. BCB and Delphi (7 and lower) already
shared an
IDE so you are still talking about sharing an IDE so the IDE resources
stay
roughly the same. Documentation - same resources. VCL - same resources.
Compiler - same resources. I have yet to find a single resource that you
think
will be saved by this. There was plenty of overlap before and the ROI was
poor
for BCB, the overlap and non overlap is still roughly the same with this
idea as
it was before with less overall revenue generated.
|
I don't doubt that you know far more about the development of Delphi/BCB
than me. Perhaps you could tell me how much of Delphi's development
resources is spent on improving the language and how much is spent on the
VCL/IDE etc. It strikes me that if the work spent on the language is
considerably smaller, then once you have a model that compiles either
flavour language, the maintenence of it need not be such a huge undertaking.
I'm not trying to be argumentative - I certainly don't have all the facts -
it's just that from my point of view, it does make sense. Rather than having
2 complete products in one, I was imagining one, distinct 'VCL' product that
could parse either Object Pascal or C++ files.
| Quote: | Issue: But It's not C++ enough
-------------------------------
It makes no sense at all for Borland to pull the Delphi resources (which
give a
great ROI) and place them on BCB which gives them a low ROI. I can see
why you
as a BCB user would love this, but it makes absolutely no business sense
for
Borland.
|
Surely there must be some marketing merit to making Delphi a one-stop shop
for Windows development?
| Quote: | What are the benefits of integration?
--------------------------------------
Not a single benefit for Delphi users nor for that matter Borland. It
would be
an increase on resources that would be taken away from Delphi to give to
C++
when once again the good ROI is on the Delphi side.
|
There would be a market for 3rd party C++ components/libraries that Delphi
users would have access to. Isn't that a benefit?
Des
|
|
| Back to top |
|
|
Ed Mulroy [TeamB]
Guest
|
| Posted: Tue Apr 13, 2004 7:41 pm Post subject: Re: Delphi/BCB Integration (Part 2) |
|
|
One positive thing it would do is to give the BCB developer the
ability to create packages. He does not have that now. (packages can
be used under both BCB and Delphi, what BCB creates cannot do that).
.. Ed
| Quote: | Jeff Overcash wrote in message
news:407C2D97.BE91D1D0 (AT) mindspring (DOT) com...
|
|
|
| Back to top |
|
|
Jeff Overcash (TeamB)
Guest
|
| Posted: Tue Apr 13, 2004 8:52 pm Post subject: Re: Delphi/BCB Integration (Part 2) |
|
|
"Des O'Toole" <des> wrote:
| Quote: | Hi Jeff
"Jeff Overcash (TeamB)" <jeffovercash (AT) mindspring (DOT) com> wrote in message
news:407C2D97.BE91D1D0 (AT) mindspring (DOT) com...
The only
potential revenue they would miss out on is from those who currently
need to
buy both Delphi AND BCB.
Which is a large cross section.
IS a large cross section or WAS a large cross section? I can't envisage many
developers rushing to buy a discontinued product. All my comments were based
on the fact that BCB has been discontinued and the VCL in BCBX is very much
in question.
|
Was or Is has no difference, if they did this unless those
people do not come back (which of course defeats your whole
argument on doing this if they don't) the crosssection will
reamin roughly the same. If it is less they have to make it up in new sales.
Add to that that most people who were NOT in the cross section
hated the Delphiness of hte IDE/project manager and that the
framework was not in C++. That has always been a stumbling
block for BCB from day one. Your suggestion does not improve
this situation at all AFAICT.
| Quote: | Resource wise you save nothing. BCB and Delphi (7 and lower) already
shared an
IDE so you are still talking about sharing an IDE so the IDE resources
stay
roughly the same. Documentation - same resources. VCL - same resources.
Compiler - same resources. I have yet to find a single resource that you
think
will be saved by this. There was plenty of overlap before and the ROI was
poor
for BCB, the overlap and non overlap is still roughly the same with this
idea as
it was before with less overall revenue generated.
I don't doubt that you know far more about the development of Delphi/BCB
than me. Perhaps you could tell me how much of Delphi's development
resources is spent on improving the language and how much is spent on the
VCL/IDE etc.
|
They were spending nearly 5 team months a year of resources on
BCB from what I can tell (Delphi releases + patch release
schedule vs when the next version of BCB ships). During that
time almost nothing went on with the enhancments next version
of Delphi. This is a major drain on resources from Delphi
towards BCB. There was no drain from a complier standpoint as
the C++ compiler team was always separate from the Delphi
Team. So that 5 months was always QA, Doc, IDE, VCL for C++.
So unless you just want a compiler, but no designers in the
IDE, VCL enhancements, IDE enhancements to better support C++,
etc (which of course is the current state of CBX) you have to
continue to put these resources towards the C++ side of the
Delphi product.
The strange thing is is the product you are proposing has every
major problem people have complained about BCB from the very
first day. This complaint has always been it's Delphi centric
way of doing things. This very problem has cause major
adoption problems for BCB, but somehow you seem to think that
moving into a Delphi centric IDE is going to improve this? I
just don't follow that logic.
| Quote: | It strikes me that if the work spent on the language is
considerably smaller, then once you have a model that compiles either
flavour language, the maintenence of it need not be such a huge undertaking.
|
Why do you think the C++ compiler can just be brought to next
to nothing in resource consumption? The C++ language is not
static in nature. Also the C++ compiler is not a shared
resource AFAIK.
| Quote: | I'm not trying to be argumentative - I certainly don't have all the facts -
it's just that from my point of view, it does make sense. Rather than having
2 complete products in one, I was imagining one, distinct 'VCL' product that
could parse either Object Pascal or C++ files.
|
But you need two compilers, you need an IDE that can do much
more than just parse the files. The Delphi project manager is
insufficient for C++ work. Many things in Delphi are not
appropriate for C++ and many things in C++ are not needed in
Delphi. Is this was a simple thing they would have gotten the
resource allocation of BCB down by now, but they were not able
to. A lot of BCB 6 is the same in D6, but there were many
changes that have to be done to accomidate C++ in the IDE,
these same items still need to be done.
| Quote: |
Issue: But It's not C++ enough
-------------------------------
It makes no sense at all for Borland to pull the Delphi resources (which
give a
great ROI) and place them on BCB which gives them a low ROI. I can see
why you
as a BCB user would love this, but it makes absolutely no business sense
for
Borland.
Surely there must be some marketing merit to making Delphi a one-stop shop
for Windows development?
|
Quite frankly Delphi already is. So was BCB. You do not need
both language to write virtually any Windows app you want. In
VS, due to limitations in the languages/frameworks involved you
need to work in more than one language to be efficient, this is
not true in either Dlephi or BCB.
| Quote: |
What are the benefits of integration?
--------------------------------------
Not a single benefit for Delphi users nor for that matter Borland. It
would be
an increase on resources that would be taken away from Delphi to give to
C++
when once again the good ROI is on the Delphi side.
There would be a market for 3rd party C++ components/libraries that Delphi
users would have access to. Isn't that a benefit?
|
The Delphi component market is already mature. I can't see many companies starting with C++ only component sets. The value they get would be non existant compare to just writting them in Delphi to start with. I would also conjecture that
this market probably doesn't even represent $100,000 in revenue
(I think I'm being overly generous here) which may soudn a lot
to you or me, but is meaningless for a company trying to reach
the 1B revenue level.
Once again this seems like a good thing for the BCB users, but
is not healthy for Borland.
What it comes down to is BCB was not giving a good ROI to Borland (if it was BCB7 would be here today). The IDE and VCL was already grealty shared code, but still required a great deal of resources to make it acceptable (and many complain here it never even got to that level) to the normal C++ developer. Nothing in resource allocation seems to have changed in your proposal unless you lessen the extra resources they were allocating to make things more C++ friendly and if they made it less I don't see how that would ever grow a market.
The best bets, IMO, is for the VCL (a C++ one) to be developed
for CBX (a high initial resource investment but one that
reduces greatly after that), or that the VCL.Net be included
once the managed C++ compiler is available. The first has a
better chance at being accepted by the C++ community as a
whole, the second has a greatly reduce resource allocation. In
either case a larger ROI on the C++ product line. The better
the ROI the more resources a project will get.
Any suggestions in this area needs to show how the C++ line's
ROI will be improved with the suggestion. All the suggestions
I've seen so far are great for BCB developers (of which I am
one) but not good for Borland. In the end if Borland falters
due to continually putting too many resources towards projects
that have low return then they will falter hurting all the
customers and not just the one line that has to be trimmed or
changed in direction (like the C++ line did with CBX).
|
|
| Back to top |
|
|
Jeff Overcash (TeamB)
Guest
|
| Posted: Tue Apr 13, 2004 8:57 pm Post subject: Re: Delphi/BCB Integration (Part 2) |
|
|
"Ed Mulroy [TeamB]" <dont_email_me (AT) bitbuc (DOT) ket> wrote:
| Quote: | One positive thing it would do is to give the BCB developer the
ability to create packages. He does not have that now. (packages can
be used under both BCB and Delphi, what BCB creates cannot do that).
|
The problem with that has always been you can't just use the
package, but a DCU/DCP has also got to be generated. There are problems with generating this from C++ classes.
C++ packages can be used in Delphi apps today though. You can
call loadpackage and with a Delphi style interface work with
VCL classes in that package. Danny Thorpe has shown how to do
that in the past IIRC. They can't be loaded into the IDE though.
But once again I question just how much revenue is generated for Borland if they spent all the resources necessary to allow
C++ component developers to install their components in Delphi.
I just have a hard time see this as even a nitch market.
|
|
| Back to top |
|
|
Ed Mulroy [TeamB]
Guest
|
| Posted: Tue Apr 13, 2004 9:55 pm Post subject: Re: Delphi/BCB Integration (Part 2) |
|
|
| Quote: | But once again I question just how much revenue is
generated for Borland if they spent all the resources
necessary to allow C++ component developers to
install their components in Delphi. I just have a hard
time see this as even a nitch market.
|
Danny's thing is a clever scheme to manually twist what is there. It
is not a supported or even allowed feature of the IDE and is not
something that can be claimed for the product. It is analagous to
reprogramming the flash memory in your car to boost power and then
claiming that much power for that model of car.
If one is to have a product there are three choices. He ships a C++
product or ships a C++ like Delphi dialect code generator or ships one
that does both. The current choice is an 'almost' version of the
dialect choice and as such has a niche market. Pick one and do it
well.
| Quote: | ...I question just how much revenue is generated
for Borland if they spent all the resources necessary...
|
"how much revenue is generated for Borland" is both a common theme and
I think a mistake. It is the wrong question. BCB is a tool with
which the customers create products.
The question to ask is what products will generate the most revenue
for Borland's CUSTOMERS. Valid answers to that question will provide
plenty of revenue for Borland.
.. Ed
| Quote: | Jeff Overcash wrote in message
news:407c461d$1 (AT) newsgroups (DOT) borland.com...
One positive thing it would do is to give the BCB
developer the ability to create packages. He does not
have that now. (packages can be used under both BCB
and Delphi, what BCB creates cannot do that).
The problem with that has always been you can't just use
the package, but a DCU/DCP has also got to be generated.
There are problems with generating this from C++ classes.
C++ packages can be used in Delphi apps today though. You
can call loadpackage and with a Delphi style interface work
with VCL classes in that package. Danny Thorpe has shown
how to do that in the past IIRC. They can't be loaded into the
IDE though.
But once again I question just how much revenue is generated
for Borland if they spent all the resources necessary to allow
C++ component developers to install their components in Delphi.
I just have a hard time see this as even a nitch market.
|
|
|
| Back to top |
|
|
Ed Mulroy [TeamB]
Guest
|
| Posted: Tue Apr 13, 2004 10:17 pm Post subject: Re: Delphi/BCB Integration (Part 2) |
|
|
You've no idea how much I enjoyed your reply. I've been taking some
abuse lately about my replies on the newsgroups (most of it in emails)
and it's nice to hear that someone aggrees with me <g>
.. Ed
| Quote: | Kenneth de Camargo wrote in message
news:407c646d$1 (AT) newsgroups (DOT) borland.com...
"how much revenue is generated for Borland" is both a
common theme and I think a mistake. It is the wrong
question. BCB is a tool with which the customers create
products.
The question to ask is what products will generate the
most revenue for Borland's CUSTOMERS. Valid answers
to that question will provide plenty of revenue for Borland.
On behalf of the current BCB users' base, THANK YOU!!!
|
|
|
| Back to top |
|
|
Kenneth de Camargo
Guest
|
| Posted: Tue Apr 13, 2004 11:06 pm Post subject: Re: Delphi/BCB Integration (Part 2) |
|
|
Ed Mulroy [TeamB] wrote:
| Quote: | "how much revenue is generated for Borland" is both a common theme and
I think a mistake. It is the wrong question. BCB is a tool with
which the customers create products.
The question to ask is what products will generate the most revenue
for Borland's CUSTOMERS. Valid answers to that question will provide
plenty of revenue for Borland.
|
On behalf of the current BCB users' base, THANK YOU!!!
--
Ken
http://planeta.terra.com.br/educacao/kencamargo/
* this is not a sig *
|
|
| Back to top |
|
|
Randall Parker
Guest
|
| Posted: Tue Apr 13, 2004 11:39 pm Post subject: Re: Delphi/BCB Integration (Part 2) |
|
|
Jeff Overcash (TeamB) wrote:
| Quote: | They were spending nearly 5 team months a year of resources on
BCB from what I can tell (Delphi releases + patch release
schedule vs when the next version of BCB ships). During that
time almost nothing went on with the enhancments next version
of Delphi.
|
You are saying that they serialized their development. But why was that necessary?
| Quote: | This is a major drain on resources from Delphi
towards BCB. There was no drain from a complier standpoint as
the C++ compiler team was always separate from the Delphi
Team. So that 5 months was always QA, Doc, IDE, VCL for C++.
|
How could that take 5 months versus 7 months for Delphi if the bulk of the new IDE
features were introduced in Delphi?
Also, is their code so unmodular that they could not develop new features for the
next Delphi while using the last Delphi release's source code to add in some C++
specific stuff?
| Quote: | So unless you just want a compiler, but no designers in the
IDE, VCL enhancements, IDE enhancements to better support C++,
etc (which of course is the current state of CBX) you have to
continue to put these resources towards the C++ side of the
Delphi product.
|
They are already separately developing the next C++ compiler. Whether it is put in an
IDE with Delphi or in BCBX or both does not change the amount of effort that goes
into the C++ compiler and probably not the amount of effort into the linker either
since the C++ linker has to be able to link to OP code in either case.
| Quote: | The strange thing is is the product you are proposing has every
major problem people have complained about BCB from the very
first day.
|
Some people made that complaint. I have to say I don't care about it. Also, BCBX is
no more C++ centric than BCB since all that happened there was a switch from a
Pascal-based IDE to a Java-based IDE. Borland apparently switched to Java-based to
support other operating systems besides Windows.
| Quote: | Quite frankly Delphi already is. So was BCB. You do not need
both language to write virtually any Windows app you want. In
VS, due to limitations in the languages/frameworks involved you
need to work in more than one language to be efficient, this is
not true in either Dlephi or BCB.
|
In BCB we have found it a pain to modify existing third party VCL libs that we buy
because we don't have a full Pascal development environment or documentation. In
order to use BCB for our purposes we end up occasionally needing to modify the VCL.
That is of course all in Pascal.
| Quote: | The Delphi component market is already mature. I can't see many companies starting with C++ only component sets. The value they get would be non existant compare to just writting them in Delphi to start with. I would also conjecture that
this market probably doesn't even represent $100,000 in revenue
(I think I'm being overly generous here) which may soudn a lot
to you or me, but is meaningless for a company trying to reach
the 1B revenue level.
|
$100,000 for Borland or for Third Parties? I think the Third Parties are do not
expect to reach $1B in revenue.
| Quote: | Once again this seems like a good thing for the BCB users, but
is not healthy for Borland.
What it comes down to is BCB was not giving a good ROI to Borland (if it was BCB7 would be here today). The IDE and VCL was already grealty shared code, but still required a great deal of resources to make it acceptable (and many complain here it never even got to that level) to the normal C++ developer. Nothing in resource allocation seems to have changed in your proposal unless you lessen the extra resources they were allocating to make things more C++ friendly and if they made it less I don't see how that would ever grow a market.
|
One reason that BCB hasn't given Borland a better ROI is that Borland never really
refined BCB. It was too buggy. New versions introduced too many regression bugs that
never got fixed. It didn't stay competitive as a C++ compiler either.
| Quote: |
The best bets, IMO, is for the VCL (a C++ one) to be developed
for CBX (a high initial resource investment but one that
reduces greatly after that),
|
But we can't use VCL from third party sources unless it is Pascal VCL. As you state
above the market for it is not large enough at this point.
| Quote: | or that the VCL.Net be included
once the managed C++ compiler is available.
|
But for those of us who expect to be doing Win32 development for years to come that
option solves no problems.
Borland's problem is that they never did BCB incredibly well. Now they show all signs
of not doing BCBX incredibly well. Maybe BCBX v2.0 will be stunning and fix all the
major bugs in it while also adding in Win32 VCL designer support and CodeGuard. Then
again, maybe not too.
|
|
| Back to top |
|
|
Duane Hebert
Guest
|
| Posted: Wed Apr 14, 2004 1:58 am Post subject: Re: Delphi/BCB Integration (Part 2) |
|
|
"Kenneth de Camargo" <INVERT:rb.moc.arret@jcrk> wrote
| Quote: | Ed Mulroy [TeamB] wrote:
You've no idea how much I enjoyed your reply. I've been taking some
abuse lately about my replies on the newsgroups (most of it in emails)
and it's nice to hear that someone aggrees with me <g
In this regard, at least. :)
I believe those are difficult days to be a TemB member around here...
|
TeamB is here to offer us technical support and I think they do a great
job of that. I don't think they should be held accountable for Borland's
marketing/management decisions. I understand the frustration level
as well as anyone and I agree, it must be a difficult position for
these guys. I imagine that they do it for those astronomical bonuses
|
|
| Back to top |
|
|
Kenneth de Camargo
Guest
|
| Posted: Wed Apr 14, 2004 2:11 am Post subject: Re: Delphi/BCB Integration (Part 2) |
|
|
Ed Mulroy [TeamB] wrote:
| Quote: | You've no idea how much I enjoyed your reply. I've been taking some
abuse lately about my replies on the newsgroups (most of it in emails)
and it's nice to hear that someone aggrees with me
|
In this regard, at least. :)
I believe those are difficult days to be a TemB member around here...
--
Ken
http://planeta.terra.com.br/educacao/kencamargo/
* this is not a sig *
|
|
| Back to top |
|
|
Frank Gruber
Guest
|
| Posted: Wed Apr 14, 2004 10:28 am Post subject: Re: Delphi/BCB Integration (Part 2) |
|
|
| Quote: | The strange thing is is the product you are proposing has every
major problem people have complained about BCB from the very
first day. This complaint has always been it's Delphi centric
way of doing things. This very problem has cause major
adoption problems for BCB, but somehow you seem to think that
moving into a Delphi centric IDE is going to improve this? I
just don't follow that logic.
|
And offering the puristic C++ community a IDE written
in JAVA will make those adoption problems disappear ?
This fact for me is at least as ugly as the fact that VCL
is based on object pascal. But the second one gives me
access to a very large 3rd party market which I would
never have with a C++ based VCL. This makes living
with "that somewhat bad feeling" quite comfortable
whereas the first fact saves money for Borland but
does not give any benefit to me.
Just my 2 cents.
Frank.
|
|
| Back to top |
|
|
Frank Gruber
Guest
|
| Posted: Wed Apr 14, 2004 10:47 am Post subject: Re: Delphi/BCB Integration (Part 2) |
|
|
| Quote: | If one is to have a product there are three choices. He ships a C++
product or ships a C++ like Delphi dialect code generator or ships one
that does both. The current choice is an 'almost' version of the
dialect choice and as such has a niche market. Pick one and do it
well.
|
IMHO that's exactly the point.
BCB was a good idea but it was never done (very) well.
Maybe it would have been a better idea to integrate
C++ into Delphi from the beginning. One of the main
drawbacks IMHO was that BCB was a one way street.
What you did there could never reach the large community
of Delphi users AND it would never reach the large communtiy
of puristic C++ users.
Frank.
|
|
| Back to top |
|
|
Kenneth de Camargo
Guest
|
| Posted: Wed Apr 14, 2004 11:18 am Post subject: Re: Delphi/BCB Integration (Part 2) |
|
|
Duane Hebert wrote:
| Quote: | TeamB is here to offer us technical support and I think they do a
great job of that. I don't think they should be held accountable for
Borland's marketing/management decisions.
|
Oh, I don't disagree with that. And most of them don't try to justify
the unjustifiable.
| Quote: | I understand the
frustration level as well as anyone and I agree, it must be a
difficult position for these guys. I imagine that they do it for
those astronomical bonuses <g
|
Nah, when they behave they are allowed out of the cages.
--
Ken
http://planeta.terra.com.br/educacao/kencamargo/
* this is not a sig *
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
