On 16/7/06 11:26, "Stefan" <[EMAIL PROTECTED]> wrote:
>
> Am 16.07.2006 um 12:14 schrieb Dan Stenning:
>
>> On 15/7/06 03:26, "Andy Dent" <[EMAIL PROTECTED]> wrote:
>>
>>> Do you really want RS to devote the resources to rewriting what is
>>> likely to be several hundred thousand lines of idiomatic C++ into RB,
>>> rather than putting that effort into improving the compiler and
>>> making its existing output faster?
>>>
>>
>> While other more important issues remain, maybe not. But there
>> would be
>> great benefits to both RS and us, once RB was fully written in RB.
>
> I don't hink so. Even Apple uses the GCC set of tools - and thus
> doesn't
> need to put much resources in GCC itself. As a result, the can put
> more in XCode e.g.
>
Not a valid argument - unlike RS Apple has never produced its own compiler
or language for OS/X. Xcode is merely a "shell" IDE for GCC. Apple doesn
need to develop its compiler since there are already compilers available for
its two languages Objective C and C/C++.
> I don't feel, that for a company of RS' size, it's a good choice to
> reinvent
> the wheel like rewriting a compiler for RB in RB.
Its not a case of reinventing the wheel. There are many good arguments for a
100% RB. The productivity gains for not having to work in two different
development environments woujd be huge.
It would also mean RS would have to improve the team development and version
control aspects of RB - all of which would make RS a more "grown up" and
powerful tool.
Remember, RB has a great strength in that it is the only truly CROSS
PLATFORM language out there that works, that compiles to native code (
unlike Java )
>
>>> I don't think any of us are writing compilers in RB. We are more
>>> likely to benefit from efforts to improve compiler optimisation for
>>> the kinds of applications we ARE writing :-)
>>
>> I have already used RB to write a translator from RB to C++ , which
>> requires parsing and translation algorithms, similar to compilers
>> ( but
>> naturally not so complex). I am now writing another to do the reverse.
>>
>> So please don't put artificial limits on what RB is used for. You
>> have no
>> idea of what RB is being used for out there unless you are
>> omnipotent :)
>
> We don't ask for artificial limits, just good use of resources.
Agreed. Resources have to be used wisely. But then exactly the same argument
could have beend used to persuade RS not de rewrite the RB IDE in RB, at
all. But they did. So obviously they saw the case, even if you don't.
> RB is not a compiler-writing tool.
A silly thing to say. It is a cross-platform programming language that
produces native code. Period. The only issue that determines whether RB is
suitable for writing a compiler is whether it can generate machine code of
sufficient quality and performance to run as quickly as a C++ equivalent. It
is merely an issue of how well optimised for speed the resultant executable
is. Those issues are all down to how clever the developers who write the
compiler are.
>The fact, that you write certain translators is ok - but the
> masses don't
> do this.
For sure, but the masses would all benefit from RB built apps that run
faster and are more reliable due to RS eating its own "dog food" :)
Its not about making RB suitable for writing compilers, its about making RB
produce tight and fast code, and simplifying the development process of each
version of RB. Think about it. Would you rather have to use two languages
to develop your product or one?.
>
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
>
> Search the archives of this list here:
> <http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
