Première question: est-ce que tu penses que pour tes cours, tu vas utiliser ta calculatrice pour des programmes complexes et gourmands en CPU ?
Deuxième question, mais je pense que la réponse est "oui" si la réponse à la première question est "oui": est-ce que tu es
sûr d'avoir besoin de l'écran couleur et de la mémoire supplémentaire ? Je pose la question car le CPU des CX ne tourne pas plus vite que celui des Clickpad & Touchpad.
mais qu'en est-il du LUA point de vue performance ? (j'ai pas vu de jeux qui roxxx jusqu'a maintenant)
Impossible d'imaginer un émulateur de GameBoy Color en Lua, c'est beaucoup trop lent.
Le Lua des Nspire permet de faire de la programmation graphique événementielle spécifique à la plate-forme (bon, le C/ASM des TI-68k aussi
) - mais bien que Lua soit un langage assez rapide à interpréter, les performances sont loin de ce que le code natif (quand il est possible) permet.
Il faut également savoir que le Lua des Nspire est bridé: en particulier, pas de fonctions d'I/O de fichiers (package io.*), pas de package system.*, etc.
Et points de vu CAS, je pense que la NSpire a enfin surpassé la 89, ou est-ce que je me trompe ?
Points positifs: quelques bugs en moins.
Points négatifs:
* c'est toujours le même CAS que sur les TI-68k, sans différence significative en termes de fonctionnalité;
* il y a des bugs en plus: les versions 3.x de l'OS des Nspire, c'est à dire les seules qui fonctionnent sur Nspire CX, ont introduit des bugs graves;
* même si les gens qui l'utilisaient directement en C/ASM était assez rares, le fait est que le CAS des Nspire est moins programmable. Sur TI-68k/AMS, on sait s'intégrer au CAS en C/ASM, mais pas sur Nspire.
L'API interne n'a pas changé (voir
http://www.ticalc.org/archives/files/fileinfo/437/43727.html ), mais le reverse-engineering de tout le bazar que constituent les documents TNS n'a pas été fait (et c'est du boulot, même en utilisant les versions plus anciennes de l'OS qui sont plus petites...). Le programme que je viens de mentionner n'est pas interactif: il n'est pas appelable depuis un document de type Calculator, il ne lit pas et n'écrit pas de variables CAS depuis/vers un document. Autrement dit, tel quel, en pratique, ce programme est inutile.
C'est moi qui l'ai fait, je peux le critiquer autant que je veux Les programmes Ndless ne sont pas des TNS bien formés, ils ne peuvent accueillir des variables CAS.
Ca risque d'être difficile d'écrire des variables vers d'autres documents, la machine étant faite pour n'ouvrir qu'un document à la fois (remarquez, elle fait déjà assez facilement des out of memory comme ça
).
Dernière question, mais je sais que j'aurais pas de réponse, y aura-t-il une chance de voir un jour du C/ASM sur la NSpire (NDless 3 ?) ?
Oui, car l'histoire de l'informatique montre que les plate-formes fermées à la programmation en code natif sont toujours ouvertes, tôt ou tard. Comme beaucoup de managers d'autres grosses entreprises, le management de TI (sauf exception) n'a toujours pas compris.
Mais quand... nobody knows, car ça dépend de plusieurs facteurs, et de toute façon, pas grand monde ne va dire en public ce qu'il en est.
