On Sep 14, 2006, at 2:59 PM, Daniel Stenning wrote:
It depends on how carefully and elegantly it is implemented. There
is no
reason why such stuff need be inelegant or cluttered.
All I am asking for is enough language/ compiler enhancements to
allow
developers to build and fine tune apps to the maximum. If RB is to
attract
as wide as possible a base of programmers it has to be able to enable
professionals to optimise the code, as well as being easy for
beginners.
What I want to avoid is the "if you cant do it in RB fast enough,
build a
plugin" philosophy.
I am of the opinion that in a truly "industrial strength"
language , the
only time one should have to resort to using libraries such as
plugins,
built in C - would be where one needs ASSEMBLER to achieve the
necessary
performance. Anything other performance optimisations should be
achievable
in the language itself.
Many developers writing commercial apps avoid 3rd party libraries
because of
all the dependency issues and support etc. In order to attract such
developers to the RB platform one would have to assure such
developers that
one can do the majority of the coding in the language itself and
not have to
continually resort to extra plugins or libraries to get the desired
performance.
I'm soooo in your camp on the need for high performance constructs in
RB... but i think we need RS to focus on makign what they have
faster, rather than hoping that additional syntax will yield faster
compiled code... whats to make your index any faster than the byte
offsets? the simplest way to add what you requested would likely be
slower than the byte offsets.
Over the years I've heard lots of requests for syntax changes to make
things run faster - as long as the compiler isnt optimizing, there's
very little chance that new syntax will yield any speed bump. I
think our best bet is to phrase the questions such as: can we have a
way to access our memoryblocks faster - this yielded ptrs (something
which direct requests for were lambasted on this list - often by RB
folks.)
that said... i'd like to see ptrs sped up even more... perhaps quick
ways to increment them, a way to copy arbitrary runs of bytes between
ptrs ala memcpy. even a way to alloc a ptr/memoryblock without
zeroing could come in handy and help speed up some situations.
mike
--
Mike Woodworth
[EMAIL PROTECTED]
_______________________________________________
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>
