La puissance brute et la capacité de stockage des Nspire (plusieurs membres dans la famille) sont en effet plus élevées que celles des TI-68k, mais plus difficiles à programmer
Le CAS des Nspire n'est que marginalement meilleur que celui des TI-68k (c'est la même base de code) - et sur certains points, il est plus buggé (de nouveaux bugs sont apparus dans les versions récentes d'OS).
Il y a principalement trois langages pour la Nspire:
* un langage proche du BASIC des TI-68k, mais la version Nspire est complètement merdique: elle ne sait ni lire au clavier, ni faire des écritures arbitraires à l'écran. Même les TI-81 et TI-80 d'il y a vingt ans savent faire;
* depuis peu, une implémentation propriétaire de Lua, qui est significativement incompatible, dans les deux sens, avec le Lua standard. Par exemple, pas d'entrée-sortie fichier; mais l'implémentation de TI possède un framework de programmation graphique événementielle pas trop bête - c'est juste qu'il n'existe sur aucune autre implémentation de Lua.
Le langage est purement interprété (le projet est manifestement antérieur au support ARM dans LuaJIT), donc il n'est pas super rapide - mais au moins, il permet de dessiner à l'écran et de lire au clavier;
Il y a déjà eu plusieurs casses de compatibilité antérieure en quelques mois. Il n'y a pas de SDK officiel convenable pour programmer en Lua sur ordinateur, et pas du tout de SDK officiel pour programmer on-calc. Des tiers (ExtendeD, ici présent) ont fait Luna et OCLua.
* la pleine puissance du code natif, venant du C, C++ ou de l'ASM direct. Pour y avoir accès, il faut un compilateur sur ordinateur, et avoir installé Ndless, équivalent du jailbreak des iP*, lui aussi fait par ExtendeD.
Bien entendu, TI bloque Ndless à chaque nouvelle version de l'OS, puisque contrairement à ce qui se passait pour les TI-Z80 et TI-68k, TI ne veut absolument pas que les gens aient accès au code natif sur les Nspire...
J'espère que ça répond à une partie de tes questions
