NumWorks, 1ère graphique française programmable en Python

[critor]

@Parisse :

Notez particulièrement le milieu de la page 7...

page 14 plutot.

Je voulais juste faire remarquer la citation de Critor, en page 7... Je n'ai pas été très clair.
J'ai corrigé ma formulation, plus haut.

En même temps, ce n'est pas nouveau.
C'est la citation qui était déjà présente sur leurs visuels pour les journées APMEP 2017.

Dont sur le poster dédicacé exprès pour proghy_v2, volé dans sa boîte à lettres en période de fêtes, et probablement tiré à la poubelle quand les voleurs ont vu qu'ils ne pourraient pas monnayer le contenu de ce colis pour grand chose.

[parisse]

Le numéro de version a été passé en 1.5 sur le site du code source. Les nouveautés:
* écriture naturelle (à activer dans les paramètres). Ça a l'air bien, un petit oubli: diff. Principalement le travail de LeaNumworks il me semble.
* calcul exact avec les complexes
* numérotation dans les scripts (mais la coloration syntaxique de zardam n'y est pas)
Pour le moment, je n'ai pas vu de solver d'équations, les calculs matriciels se font en approché (et le pivot de Gauss n'est pas implémenté pour les matrices à coefficients complexes).
Quelle taille pour le firmware?

[Thom986]

Je ne suis pas hyper pour l'écriture naturelle. Je trouve qu'on perd en sens pour la fraction / division et qu'on perd en priorité de calcul...

[parisse]

On n'est pas oblige d'utiliser l'ecriture naturelle. Moi non plus, je ne suis pas un grand fan, mais pour rentrer des matrices sur la Numworks, c'est nettement plus pratique.

[Adriweb]

J'ai beaucoup de mal à voir comment l'écriture 2D pourrait être moins pratique pour voir rapidement et efficacement une expression non triviale...

Bref, la version 1.5.0 est désormais sortie, en tout cas.

[parisse]

Je vois 2 inconvenients a la saisie 2d (la saisie, pas l'affichage): le premier est d'ordre pedagogique car ecrire en 1-d oblige a maitriser un minimum les parenthesages et priorites d'operateurs, or on s'apercoit que certains etudiants ont des problemes avec ca (ca doit etre plus frequent pour les eleves), le deuxieme est la modification d'une expression existante par exemple en cas d'erreur de saisie qui peut etre beaucoup plus compliquee qu'en ecriture 1d.

[parisse]

La lecture des commentaires sur la proposition de zardam pour la coloration syntaxique en Python https://github.com/numworks/epsilon/pull/435 illustre parfaitement l'erreur strategique qu'a fait Numworks de mon point de vue avec la taille de memoire disponible. Le 1er PR de zardam semble elegant et parfaitement fonctionnel, mais Ecco lui demande des modifications substantielles pour economiser de la memoire, mais c'est alors plus difficile a realiser, avec plus d'ajustements a faire a la main donc de risques de bugs, et le code n'est pas integre dans la release 1.5.
On voit aussi certains scripts Python du workshop utiliser des astuces pour economiser de la place (par exemple P=print ou indentation d'un espace) au detriment de la lisibilite du script.

[Adriweb]

D'après ce que j'ai rapidement lu de la discussion sur la PR, c'était plus "pour voir" si utiliser le lexer déjà présent de MicroPython serait viable - rien ne dit que ce sera la solution retenue (plutot le contraire, même, vu certaines limitations)

[parisse]

Mais si la capacite memoire n'etait pas un probleme, la proposition de PR initiale aurait certainement pu etre integree dans la version 1.5 sans se poser ce genre de questions (quitte a ce que quelqu'un y revienne plus tard s'il est interesse a optimiser). Cela illustre donc tres bien mon argumentation: si on n'a pas assez de memoire, on est oblige d'optimiser, ce qui coute du temps de developpement et augmente le risque de bugs. Donc ca diminue les fonctionnalites disponibles au temps t, ici ca donne un avantage concurrentiel a la casio au moins jusqu'a la prochaine release, a un moment ou ca peut influencer le choix de certains profs pour la rentree prochaine.

[Adriweb]

Mais si la capacite memoire n'etait pas un probleme, la proposition de PR initiale aurait certainement pu etre integree dans la version 1.5 sans se poser ce genre de questions (quitte a ce que quelqu'un y revienne plus tard s'il est interesse a optimiser).

J'en doute - une PR avec un tel impact, ça doit être vu, revu, testé, validé, etc. et en profondeur. Par exemple, un crash perdant le script aurait beaucoup plus de mauvaise presse que d'avoir à attendre un peu plus pour profiter d'une feature. Surtout que NumWorks comptait le faire à un moment ou à un autre (autrement dit, il faut que ça respecte ce qu'ils avaient prévu comme trucs).
Comme la 1.5 allait sortir peu de temps après, rajouter cette charge de travail là à l'improviste n'était ni prévu ni faisable. (Je comprends de mieux en mieux ce genre de contraintes et "process" professionnel avec mon boulot, au cours du temps, et c'est normal...)

L'argument de la limite de mémoire trop basse freinant le développement n'est pas mauvais, mais ça n'a pas été un obstacle dans ce cas là, selon moi.
Et perso, que ce soit dans la 1.5 ou non, ça ne me dérange pas vraiment, on sait que NumWorks est capable de sortir des updates sans pour autant prendre 6 mois comme la concurrence (au mieux...). Donc possible qu'une prochaine update pour ça arrive d'ici quelques semaines, par exemple