Board index » jbuilder » Re: Interview: Dale Fuller and Blake Stone on Borland directions

Re: Interview: Dale Fuller and Blake Stone on Borland directions


2003-11-17 07:44:10 AM
jbuilder15
Tim Anderson wrote:
Quote

Hope you find something of interest here.
Oh, I did! Very revealing in many aspects.
Thanks!
--
Kristofer
 
 

Re:Re: Interview: Dale Fuller and Blake Stone on Borland directions

"chrisC" < XXXX@XXXXX.COM >wrote in message
Quote
Not all Games as you know are 'winners'. Winning Games are designed with
languages and compilers specifically suited for their use.
Nonsense. This only holds for 3D first-person shooters and such games.
I know a guy who leads a very unglamorous life making seemingly boring games and
he has made more than 1 million USD with his games, over the past 20 years.
And other "non-winners", like the cheap educational games that are dumped on the
market, their creators became millionaires. But because it is low profile stuff,
people don't realize that you can make a truckload of money with ordinary stuff.
Remember the program with witch you could dress up Barbie? Highest sales income
ever on that game, making the copyright holder an instant millionaire.
Believe me, they didn't write their own compiler or rendering engine for that
game.
A "winner" is a "winner" when it sells, for Borland, at least 1 copy of Delphi.
And a "winner", is a "winner", for a game developer, when it pays his bills.
Anything else is just marketing.
 

Re:Re: Interview: Dale Fuller and Blake Stone on Borland directions

Not disagreeing with you about general Games making their coders rich.
Neither did I imply they wrote their own compilers and rendering engines
either.
Just getting the point across that you as a 'purist Game coder' or me as
a 'Database weenie programmer' must
be smart enough to use the right tool for the right job.
"Frank Andreas de Groot" < XXXX@XXXXX.COM >wrote in message
Quote
"chrisC" < XXXX@XXXXX.COM >wrote in message
news:3fb80b8f$ XXXX@XXXXX.COM ...

>Not all Games as you know are 'winners'. Winning Games are designed with
>languages and compilers specifically suited for their use.

Nonsense. This only holds for 3D first-person shooters and such games.
I know a guy who leads a very unglamorous life making seemingly boring
games and
he has made more than 1 million USD with his games, over the past 20
years.

And other "non-winners", like the cheap educational games that are dumped
on the
market, their creators became millionaires. But because it is low profile
stuff,
people don't realize that you can make a truckload of money with ordinary
stuff.
Remember the program with witch you could dress up Barbie? Highest sales
income
ever on that game, making the copyright holder an instant millionaire.

Believe me, they didn't write their own compiler or rendering engine for
that
game.

A "winner" is a "winner" when it sells, for Borland, at least 1 copy of
Delphi.
And a "winner", is a "winner", for a game developer, when it pays his
bills.

Anything else is just marketing.



 

{smallsort}

Re:Re: Interview: Dale Fuller and Blake Stone on Borland directions

"JBuilder versus Eclipse:
Tim: With the new licensing terms for JBuilder Foundation it looks like
Borland is going against Eclipse with a somewhat similar model: free basic
tool, encourage third party plug-ins.
Blake: Back in 1999 we had JBuilder 3.0 Foundation.
Dale: We gave it away free, anyone could download it, anyone could embed it
into their architecture. ***And that's why we have thousands of plug-ins
right now***..."
Hmm, I wonder how and where Dale Fuller counted thousends of plug-ins at
all. IMO he exaggerated a lot here. Actually I would have sadly to say, that
Eclipse is now the leader in this field here related to plug-ins vs. OTs.
-vkyr
 

Re:Re: Interview: Dale Fuller and Blake Stone on Borland directions

"chrisC" < XXXX@XXXXX.COM >wrote in message
Quote

Just getting the point across that you as a 'purist Game coder' or me as
a 'Database weenie programmer' must
be smart enough to use the right tool for the right job.
This a counter-productive and derogatory view.
Dismissing my desire for inline functions as having chosen the wrong tool, shows
more about your understanding of software development than about my judgment of
programming environments.
I have deemed Delphi the only viable language to at least develop & prototype my
program in.
This is based on 22 years in "the industry" and experience with programming
languages as varied as Forth, C, RPG-II, Cobol, BASIC and Assembly.
Form several evils, I chose the worst evil. Implying that I was stupid to
choose Delphi for the job and that I should just sod off, is not going to help
Borland keep more customers, is not going to help all the others who would like
inline functions, and is not going to help me either.
 

Re:Re: Interview: Dale Fuller and Blake Stone on Borland directions

Ingvar Nilsen wrote:
Quote
What is interesting is that the product line they had did not have
enough market value to be considered subject to trade.
The owner made a decision based on the desire to earn more money. Then
the same owner definitely would have considered selling the entire
product, warts and all, before giving it away, had it had market
value.
We don't know if TP even tried to sell their product lines. From
memory, their decision to cease trading came as a surprise even to
Borland, so it seems unlikely that they even made the attempt to sell
them. As far as I can tell, they simply made a gift of their products
to the community that had supported them for so long. This generous
action does not mean the products had no value.
Let's look at it from another economic point of view: if they sold the
product line, they may have had to let the team go with it (or had them
stolen away) to work with the new company. They wanted the team for
other work, so they may have thought they were better off to give the
products away and keep the team than sell the products and lose the
team. Who knows?
Christopher Latta
 

Re:Re: Interview: Dale Fuller and Blake Stone on Borland directions

Christopher Latta wrote:
Quote
You have been corrected on this many times. Turbopower did not go
bankrupt, they simply ceased trading. There is a huge difference.
[..]
Quote
No, it was not bankruptcy, legally or realistically. A company made a
decision that it could more profitably concentrate its resources on
other ventures, and so it did.
What is interesting is that the product line they had did not have
enough market value to be considered subject to trade.
The owner made a decision based on the desire to earn more money. Then
the same owner definitely would have considered selling the entire
product, warts and all, before giving it away, had it had market value.
Correct me if this view is wrong.
--
Ingvar Nilsen
 

Re:Re: Interview: Dale Fuller and Blake Stone on Borland directions

"Frank Andreas de Groot" < XXXX@XXXXX.COM >wrote in message
Quote
"chrisC" < XXXX@XXXXX.COM >wrote in message
news:3fb81146$ XXXX@XXXXX.COM ...
This a counter-productive and derogatory view.
Dismissing my desire for inline functions as having chosen the wrong tool,
shows
more about your understanding of software development than about my
judgment of
programming environments.

Frank,
No one is dismissing your need for inline functions. Many people in a
previous thread tried so hard and kindly to help you by suggesting perhaps
you look into different angles, options, including different languages,
constructs, hardware, algorithms etc.
If there is no way in the entire universe (other than your own highway) and
the Delphi language at present does not afford you this option. one would
have thought you should have stopped whinning but no .... you keep riding
your hobby horse. Don't you get tired or do you have ADS (Attention Deficit
Syndrome?)?
Quote
I have deemed Delphi the only viable language to at least develop &
prototype my
program in.
This is based on 22 years in "the industry" and experience with
programming
languages as varied as Forth, C, RPG-II, Cobol, BASIC and Assembly.

Implying that I was stupid to
Why do you always assume that people think you are "stupid"? After all you
do have 22 years of industry experience. Don't you?
I am beginning to think you may also have inferiority complex syndrome.
I will say no more....
Quote



 

Re:Re: Interview: Dale Fuller and Blake Stone on Borland directions

Christopher Latta wrote:
Quote
We don't know if TP even tried to sell their product lines. From
memory, their decision to cease trading came as a surprise even to
Borland, so it seems unlikely that they even made the attempt to sell
them.
Maybe right, at least it was a big surprise to me, almost a shock.
But I maintain my point of view that its CEO was not Santa Claus, and
that the decision to open source it is based on low revenue.
Quote
As far as I can tell, they simply made a gift of their products to
the community that had supported them for so long. This generous
action does not mean the products had no value.
Gift? Generous? To me and many others this is not positive at all. We
(my company) seldom use freeware, we prefer to buy software from well
reputable companies, companies that have support, documentation and an
upgrade policy.
--
Ingvar Nilsen
 

Re:Re: Interview: Dale Fuller and Blake Stone on Borland directions

Quote
Problem with operator overloading in Delphi si the problem of unnamed
(temporary) results

Simple example (my syntax):

function TMyType.operator+(A, B: TMyType): TMyType;
begin
Result := TMyType.Create(A.Value + B.Value);
end;

Now if the result is assigned to a variable, that is OK. But if it is
used in:

D := A + B + C;

this results in:

Temp := A + B;
D := Temp + C;

Temp is not named, and a garbage collected system will take care of it.
C++ has no GC, but it manages such results (if they are not heap based)
as well.
But, if you write your overloads like this:
operator Add(A,B: TMyType); overload;
begin
Result := TmyType.Create;
Result.Temporary := True;
Result.Add(A,B);
if A.Temporary then A.Free;
if B.Temporary then B.Free
end;
It works. You just have to tag the objects as temporary. In C++ this is what
the compiler does. In Delphi it could be left up to the programmer.
The C# implementation has one critical flaw. It does not allow to override
the Assign operator and you cant check if the object is temporary or not.
Of course the lost reference is garbage collected, but you loose any
custom data or settings in that object.
As for W32, you would have to allow the overload of the Assing (:=)
otherwise you are not able to free temporaries.
Quote
But I guess types like Complex can be done in records as well. <g>
Yes. Currently the only application... <g>
Atmpauri.
 

Re:Re: Interview: Dale Fuller and Blake Stone on Borland directions

"Ingvar Nilsen" < XXXX@XXXXX.COM >wrote in message
| we prefer to buy software from well
| reputable companies, companies that have support, documentation and an
| upgrade policy.
So you don't use Delphi then? :-)
 

Re:Re: Interview: Dale Fuller and Blake Stone on Borland directions

Will DeWitt Jr. wrote:
Quote
Rudy Velthuis (TeamB) wrote:

>Temp is not named, and a garbage collected system will take care of
>it. C++ has no GC, but it manages such results (if they are not heap
>based) as well.

Hmm, what would be so hard about recognizing if a type is a class vs. a
record and simply calling the temporary classes destructor?
When and where should it be called? If you have a class in a class, you
must also call the destructor yourself.
Quote
In the
same way that the compiler (generally) knows when to finalize classes
or fields in classes when they go out of scope, it should know to
dispose of the temporary object when it's finished with that specific
expression.
Fields of classes are only finalized when the destructor is called, and
that must be called manually, in Delphi. If you don't call a destructor,
but the variable leaves scope, you have a memory hole.
--
Rudy Velthuis (TeamB)
"Yes, I'm fat, but you're ugly and I can go on a diet." -- bumper sticker
 

Re:Re: Interview: Dale Fuller and Blake Stone on Borland directions

Andrew Rybenkov wrote:
Quote
(records can have methods, now)

And that is great!
But no virtual methods, and no inheritance.
--
Rudy Velthuis (TeamB)
"Life would be so much easier if we could just see the source code."
-- unknown
 

Re:Re: Interview: Dale Fuller and Blake Stone on Borland directions

Atmapuri wrote:
Quote
But, if you write your overloads like this:

operator Add(A,B: TMyType); overload;
begin
Result := TmyType.Create;
Result.Temporary := True;
Result.Add(A,B);
if A.Temporary then A.Free;
if B.Temporary then B.Free
end;
In Add you don't know if the result is a temporary:
D := A + B;
D := D + C;
If you perform your code in Add, after the first addition, the object
stored in D is marked as temporary. In the second addition, it is then
freed. That doesn't work. The *routine* has no knowledge whetehr the
result is temporary or not. This is only known where the routine is used.
Some of my routines use iterators that are classes (interfaces were *way*
to slow). To avoid a similar problem, I set a few rules for the use of
objects:
- Algorithms that return iterators must always return one of the input
iterators as result. Only that iterator may be modified during the
process.
- Other inputs must be cloned before they are modified, and freed at the
end of the routine. This is to retain the pass-by-value semantics,
while
avoiding unnamed intermediates, that can't be freed by the user.
Example:
function Copy(First, Last, Destination: TIterator): TIterator;
First and Last, if they are modified, must be cloned at the start of the
routine (or where appropriate), and the clones must be freed at the end.
Destination should not be cloned, and be modified to contain the result
value. Result should point to Destination.
The resulting code:
function Copy(First, Last, Destination: TIterator): TIterator;
begin
First := First.Clone;
try
while First.Index < Last.Index do
begin
First.TypeClass.CopyItemTo(Destination.DataPtr, First.DataPtr);
First.Next;
Destination.Next;
end;
First.Free;
finally
Result := Destination;
end;
end;
Every iterator has the members TypeClass (a class that knows how to
handle a certain data type, to which the iterator points), Clone (which
kinopws how to make a clone of that specific iterator), and DataPtr (a
Pointer which points to the data).
--
Rudy Velthuis (TeamB)
"The use of COBOL cripples the mind; its teaching should, therefore, be
regarded as a criminal offense."
- Edsgar Dijkstra
 

Re:Re: Interview: Dale Fuller and Blake Stone on Borland directions

Hrvoje Brozovic wrote:
Quote
Similar issue was with huge strings when introduced in D2.
Practically, they are class of some kind (many internal functions
for manipulation of those can be viewed as methods, additional
data as ref count and length as fields).
They are "magic" types, i.e. the compiler is aware of the lifetime issues
of them. This is not true for normal classes. If it were true, each class
would need copy semantics on assignment (otherwise the compiler would
simply free all classes at the end of a routine), etc. For speed, Delphi
classes don't have that.
Note that freeing one or ten records on the stack is simply a matter of
changing one machine register. Freeing an object on the heap is a lot
more difficult and time consuming. Delphi only knows heap objects. Note
that even C++ doesn't auto-free heap objects, only stack objects (which
are very similar to records).
So yes, it would be possible, but it would make Delphi slow.
--
Rudy Velthuis (TeamB)
"The covers of this book are too far apart."
- Ambrose Bierce (1842-1914)