Yeah, true, sadly.

I got another idea. Couldn't they "save the state" of the calc (not everything of course, but things like "PTT activated" or "CAS activated") before a native program is run, then restore it when the program exits if it was changed. This way, native programs are completely harmless for their interest.

When they do something for developers it's usually not see how slow Lua is compared to ASM/C. If TI really cared about us, Lua would at least be proportional to Grammer speed compared to 84+ ASM.

You are comparing a scripting langage with a compiled one.
You are also comparing an interpreted (tokens) langage with a scripted one.
A scripted langage has to parse caracters, not tokens, its obviously slower !


The point you may be able to discuss, on the other hand, is the GUI API of the TI-Nspire Lua API.
There is a big mistake (but not so much possibilities) that the screen is prebuffered and disallows direct modifications. But, there are also plenty of functionnalities (like stroke width) that slow down a normal "stroke" to be drawn.
Another mistake are TI-Images, but we all know that. The fact is, that format is close to the one used by resources (like icons).

In case you didn't know, Grammer is not a compiled language

Where have I said that ?

Granted, Grammer uses tokens rather than individual characters for its commands

It's exactly what I said.

You said that I was comparing a scripted language with a compiled one, so since I was only talking about Lua and Grammer, it seemed to me that you thought that Grammer is compiled.

I took your sentence in the way you said it : "Lua" then "C" then "Grammer" then "Lua"
Now, let's paste my answer : "scripted" with a "compiled" then "interpreted" with a "scripted" one.
Comparing Lua to C is not the same as comparing Grammer to ASM. That was my POV.
But of course, the TI-Nspire Lua API can be optimized, I was just worried you were complaining about Lua using a false comparaison.

Actually, Lua is an interpreted language. If the script isn't already bytecode, it will 'compile' it to Lua bytecode, to then be interpreted by the Lua VM. On the Nspire you can't have scripts that are already bytecode so the conversion happens at launch. That means launch time might slow down, but for the rest of the run time it will be running Lua bytecode (unless you use loadstring).