On 29/9/07 17:14, "Charles Yeomans" <charles at declareSub dot com> wrote:
>
> You write as if a quick RAD IT tool for knocking up cross-platform
> GUI applications is not so much.
>
If I gave that impression then my mistake. Of course ( having happily used
three RAD IT tools so far ) these tools are magnificent pieces of software
engineering and tremendously useful and productive.
>>
>> RB has taken a step towards allowing us to code for better
>> performance -
>> notedly by adding Struct and Ptr datatypes. But its sad to see they
>> haven't
>> refined it more. This is "bootstrap" stuff. The more they can get
>> these
>> basics right the more they can move their internal code over to RB
>> which
>> benefits us all. I realise that most RB guys out there might not
>> need this
>> fine tuning, but every time we have to dip into C to eke out
>> performance or
>> functionality it just reinforces the impression that RB is not really
>> "pro-grade".
>
> Only among the stupid. To write high-performance code, you need to
> be close to the machine (C, for example)
That might be true before we had stuff like the Ptr type and Structs. Its
the COMPILER that gets close to the metal ( machine ). Although language
hints and the like do help, these days optimizers can achieve a lot, and
where they cannot, C programmers do not resort to C to get performance but
assembler.
Providing there are enough language elements to do this it should be
perfectly possible to the same performance in RB. There is no good reason
why the most basic operations such as looping, numerical calculations and
basic low level memory operations via pointers and structs shouldn't be just
as fast as C.
The closest level to the machine is ASSEMBLER. And in my opinion that should
be the only time one should need to resort to C ( because of the ability to
embed assembly code in C source ).
>or use a language optimized
> for the task (Fortran).
I really doubt that there is some fundamental theoretical reason why RB
cannot have both its language and compiler improved to the point where it
can match FORTRAN in speed. Much of the matrix/vector type of computation
common in scientific "batch" calculations is now used in other fields such
as multimedia and 3D graphics. A lot of the justification for Intel and the
like selling their colossal gigahertz speed CPUS to the masses rests on the
need for such kinds of processing. Lets face it - for every day business
tasks such as data entry, word processing, spreadsheets etc - the computers
of five years ago ( or more ) do the job quite adequately.
Cheers,
Dan
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|