C'est vrai que j'ai trop simplifié les choses et que je n'ai pas pris en compte la consommation d'énergie.
Les gros GPUs sont energivores, un truc de malade.
Un langage interprété n'est pas compilé, il est, en temps réel, converti en langage machine in fine.
Et un langage basé sur une machine virtuelle est compilé tout comme les langages compilés vers le langage machine. La différence, c'est que c'est compilé pour un processeur virtuel, émulé. Mais je l'avoue volontiers, une machine virtuelle, mais si c'est ultra optimisé, a un coût en performances. Mais c'est presque négligeable sauf pour les applis qui font du calcul intensif et que la seule chose qui compte, ce sont les performances.
Mais les langages qui utilisent une VM, ont leurs avantages et leurs inconvénients, tout comme les langages compilés en langage machine.
Car il y a le cout de développement (temps, argent et donc énergie aussi) pour faire tous les portages (aidés en C++ par CMake d'accord) qui est minime (idéalement et souvent nul) pour les langages basés sur une VM.
Quand j'étais étudiant, j'avais Ubuntu et Windows sur ma machine. Pour les projets d'étude qui étaient en Java ou en SmallTalk (langage qui me répugne), je pouvais utiliser l'un ou l'autre OS. Pas de différence sur l'appli finale. Les interfaces étaient exactement identiques, et finalement, l'OS employé n'avait aucune incidence. Je passais de l'un à l'autre, et c'était pareil.
Je vous déconseille fortement de vous mettre au SmallTalk. C'est un langage de snob. Mais il faut reconnaître qu'ils ont inventé les machines virtuelles et les ramasse-miettes. Donc ça impose le respect.
Et en plus, un truc complétement inédit et qui n'a pas été suivi après, c'est que tout est objet, absolument tout. Le code est objet, les classes sont objets, les objets en terme de code évidemment.
Les nombres entiers peuvent aller jusqu'à l'infini aussi, il gère les points 2D directement aussi. Même le ramasse-miettes est objet.
L'ombre et la grosse c'est que ça nous ramène à du code qui a des performances catastrophiques. Et leurs interfaces graphiques sont misérables, on se croirait à l'époque de Windows 95.
Un délire de chercheurs, qui ont oublié la calculabilité, les performances d'un programme.
Mais il y a une communité très soudée aujourd'hui encore de développeurs SmallTalk. Je crois que le créateur de Wikipédia est un SmallTalker engagé et assumé.
(Car même si la syntaxe de ce langage est loufoque (rien à voir avec les syntaxes dérivées du C), il y a toujours des personnes qui persévèrent à l'utiliser). Ce n'est plus raisonnable, c'est de l'idéologie.
Une fois que l'on s'est fait à sa syntaxe bizarre, il y a beaucoup de points positifs. La gestion des données est exemplaire. Les collections. (tableau, liste, dictionnaire (qui correspond aux tables de hash) entre de multiples autres). Mais au bout du compte, se retrouver à faire un Tetris qui rame sur un ordi à 4 cœurs ...
Un autre truc sur SmallTalk beaucoup plus grave, il n'y a pas de droits sur les méthodes, appelées messages (car ils ont leurs propres termes ésotériques) . Elles sont toutes publiques. Donc si on veut éviter que les méthodes internes puissent être appelées de l'extérieur, il faut faire des blocs et non des méthodes. Bonjour la sécurité...
Donc pour résumer, les données et les blocs (qui sont des variables comme les autres, car je l'ai dit, le code est objet) sont privés, et les messages (méthodes)
sont publics. Et le "protected" n'existe pas. (Pour l'héritage, c'est pourtant important).
Bref, le SmallTalk est un langage de merde, dangereux et qui offre des performances pitoyables, utilisé seulement par quelques chercheurs et des idéologues abrutis. Pourtant enseigné à la fac.
Bon je tire sur un animal mort, mais j'en rajoute. L' IDE de SmallTalk est lamentable, sans parler de leur interface graphique archaïque et absolument ni ergonomique, ni intuitive. C'est un ensemble de pop-ups.
Quand vous voulez entrer du code, on vous ouvre un bloc note primitif. Alors que les concurrents( beaucoup plus utilisés d'ailleurs) contrôlent le code en temps réel, proposant des suggestions, ou des infobulles pour compléter un nom verbeux explicite, voire même signalent des erreurs basiques (variable non initialisée lue, variable non accessible qui sert à rien du coup, doublons), ou d'étourderie, de codage pendant son écriture. Ils proposent également les membres (variables ou méthodes) des objets directement dans des petits menus contextuels). En SmallTalk, il faut exécuter le programme pour voir et corriger les erreurs et il faut tout taper, ce qui fait que l'on se retrouve avec des noms d'un caractère de variables donc dénués de sémantique.
Quand j'étais enfant, c'est comme cela que je corrigeais mes programmes en BASIC sur mon Apple 2c Il y a 30 ans. Mais c'était un langage interprété alors que le SmallTalk est un langage compilé...
Car dans un langage interprété, au delà des erreurs de syntaxe, on ne se rend compte des erreurs que pendant l'exécution.
Décidemment l'animal mort va finir en bouillie, en deuxième année j'avais fait un démineur en SmallTalk. 30 mégas au final (affligeant), car ils intègrent la VM dans l'exécutable. Je l'aurais fait en Java, il aurait au maximum fait quelques centaines de ko. (Pourtant ces deux langages reposent sur le même paradigme : ils sont compilés et exécutés par une machine virtuelle).
Sauf que les ressources les plus gourmandes ne sont pas gérées par les ramasse-miettes. Il faut les libérer soi-même.