That's a very good explanation,

Thank you very much indeed.

I had a "small problem" with a teenager in my programming classes who asked:

"If Livecode is written using C++ why don't we just bypass Livecode completely?"

Which prove that his English is up to a high standard :)

I found a book in a junk shop that was an introduction to C++ and sent him home with it and asked him to start teaching himself C++ and to duplicate the simplest exercise stacks we were doing in the classes.

On the Monday he turned up with a big box of chocolates for me and an apology.

I will be forever grateful to the Livecode team that they have saved me from having to learn C++.

Richmond.

On 8/2/17 9:07 pm, Mark Waddingham via use-livecode wrote:
Increasingly less - and in contrast the amount that could be done in LC instead 
of C++ continues to increase (far more slowly than I'd like - but hey, if 
wishes were horses...)

Indeed, a lot of the 'heavy lifting' seen in the engine comes down to either 
the core abstractions which the LiveCode script language requires (i.e. the 
VM), direct access to C exposed APIs, or for speed.

For example a lot of 'compound' operations such as the set operation commands 
can be implemented in LCS - indeed it is a very readable way to define their 
behaviour - but become far more effective for large arrays if done in C++ (i.e. 
for optimisation purposes). Although that is largely because we don't have a 
native code compiler for LCS.

LCB has started to provide more of what is needed to 'get away from C++' - 
admittedly its performance is not great as yet, but for its current purposes it 
is more than sufficient. In particular, UI elements generally require little 
'hardcore' performance - just rendering and property marshalling; similarly, 
wrapping system and third-party APIs to the level where they are 'more natural' 
in LCS mainly just requires appropriate type mapping and indexing of objects 
(enter LCB).

LiveCode Script is a complete programming language in its own right; it lacks 
direct access to third-party APIs certainly, however it is perhaps surprising 
how much outside of user interaction related tasks require that. Even in 7+, 
it's speed is perfectly reasonable for 'reasonably sized' computational tasks 
(for certain types of thing it is actually much more memory efficient due to 
copy on write being used for values - which increase the memory size of tasks, 
if not speed).

As a mode of expression of algorithms, it perhaps start to approach Knuth's 
idea of 'literate programming' *without* using a blended typesetting + code 
approach (which is how TeX and MetaFont are written, for example).

So, if for that reason alone there's rarely harm in writing something in LCS 
first, and *then* taking to rewrite critical parts in a lower level language if 
required for speed reasons.

Warmest Regards,

Mark.

Sent from my iPhone

On 2 Aug 2017, at 13:50, Klaus major-k via use-livecode 
<[email protected]> wrote:

Hi Richmond,

Am 02.08.2017 um 13:43 schrieb Richmond Mathewson via use-livecode 
<[email protected]>:

" remember that LC is made with LC, so everything in the IDE is a stack resp. 
scripted and can be modified!"
recently claimed by someone elsewhere [Hi, Klaus :) ]
hi mate! :-)

BUT: it that really true?
Why do I have a funny feeling that a lot of the "heavy lifting" is done with 
C++ ?
Yes, that is true, except for the engine and its functionality which is made 
with C++ or whatever.

Richmond.
Best

Klaus

--
Klaus Major
http://www.major-k.de
[email protected]


_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Reply via email to