Ça permet de retrouver tous les avantages de l’interprété.

Le use case classique, c’est d’être facilement cross-platform.
Le code à exécuter reste le même partout et il suffit d’implémenter un interpréteur pour les plateformes qu’on veut supporter.

Un autre use case peut être de sauter la phase de compilation pour passer directement à l’exécution et donc gagner du temps de développement. C’est d’ailleurs ce qu’ils expliquent sur le lien que j’ai donné :
“For some tasks, C and its compile/ link/execute/debug process are not productive. As computer hardware becomes cheaper and faster, to be productive and cost effective, script computing in C/C++ can be an appealing solution”

Je ne rentrerai pas dans le débat “c’est nul ou c’est bien”, ce n’est pas le sujet.

wanou a dit:

Merci pour cette critique construite. Je vais essayer de mon côté d’étayer un peu mes propos.

Au plaisir, je vais tâcher de faire au moins aussi bien

Basiquement, les languages de script permettent de coder très rapidement des programmes mais ce qui fait leur souplesse constitue également leur talon d’achile. J’ai cité la compilation en exemple car l’interprétation, même sous forme de bytecode, ne remplacera jamais du code natif en terme de vitesse d’exécution. On peut cependant arger que même les processeurs x86 pratiquent l’interprétation mais c’est un autre débat.

Encore une fois, l’utilisation classique de Java, c’est de le compiler via javac pour produire un bytecode et de donner ce dernier à la JVM qui va le compiler à la volée en natif.
Il en est de même pour le javascript (si il tourne dans V8 au moins et il me semble que le moteur JS de mozilla aussi).

Dans énormément de cas, la vitesse d’exécution n’est pas le problème. Faire une API ultra optimisé a l’infini, ça a peut être utile si elle doit servir des millions de requêtes à la seconde mais ça n’arrive pas si souvent que ça. Dans l’immense majorité des cas, le facteur limitant est de toute façon ailleurs (réseau, disque, parfeu par exemple) et le programme passe son temps à se tourner les pouces.

Quand je dis “sérieux”, je pense aussi à la capacité de tel ou tel language à se préter à des projets d’envergure. C’est ma définition de logiciel. Dès lors, l’absence de typage fort rend souvent les choses complexes avec les languages de script où des problèmes d’intégration surviennent en partie à cause de cela.

Chaque outil a ses avantages et ses inconvénients, bien sûr. Personne n’a jamais prétendu qu’un outil était parfait dans toutes les situations (et si quelqu’un l’a fait, il se trompe).

Le paradigme objet aide il est vrai à l’intégration mais les grand principes de la POO ne sont pas tous bien implémentés. Java par exemple qui se pose en référence en la matière ne gère même pas l’héritage multiple. C’est risible je trouve. Ceux qui ne voient pas en quoi cela est important peuvent regarder le fonctionnement de Qt pour y voir une utilisation massive de l’héritage multiple.

Je ne crois pas que Java ai déjà prétendu être la référence des langages objets.
Depuis Java 8, il est possible d’hériter de plusieurs interfaces.
Je ne connais pas assez Qt pour en parler mais il est tout à fait possible (et même assez simple) de faire de très belles et fluides interfaces utilisateurs en Java, par exemple sur Android. (note : je ne dis pas que toutes les applications Android ou java sont bonnes, je dis qu’il est tout à fait possible de faire des choses biens). Donc à moins d’avoir mal compris, le fait que Qt utilise massivement l’héritage multiple n’est pas une condition nécessaire à faire des choses biens.

Enfin, je ne considère pas comme sérieux un language pour lequel la gestion de la mémoire n’est pas accessible au programmeur. Le comportement du ramasse-miettes et la gestion globale de la mémoire de java rend impossible tout contrôle des latences des intefaces utilisateurs et c’est la raison pour laquelle je trouve qu’élever java au rang du c ou du c++ est malhonète. La consommation de mémoire élevée est une caractéristique forte des languages interprété même si j’arrive à faire des traitement assez dingue sur des tables de données d’un milions de lignes en mémoire en perl.

La mémoire est toujours accessible par le programmeur. Faire un new en Java ou en C++ va bien provoquer une allocation mémoire. Déclarer une variable en javascript via bien créer une entrée dans la pile. Même en Prolog la mémoire est accessible au programmeur.
J’imagine que vous voulez juste parler de la libération de la mémoire et même dans ce cas là, ça se discute.
Est-ce que Rust est mauvais car on ne libère pas la mémoire à la main ?
Est-ce que Java est mauvais car on ne libère pas la mémoire à la main ?
Est-ce que C++ est mauvais quand on l’utilise avec une library de garbage collection ? (https://v8.dev/blog/high-performance-cpp-gc)

Bien sûr que non et je ne comprends pas du tout ce genre de remarque que je trouve très élitiste en plus d’être fausse (confusion entre le langage et l’implémentation).
La bonne manière de choisir et d’utiliser un outil, c’est d’en comprendre les tenants et les aboutissants. Si l’utilisation d’un garbage collector pose problème lors de l’exécution, alors il faut envisager de s’en passer. Si gérer la libération de la mémoire à la main pose problème, il faut envisager de laisser un outil s’en charger.

Pour enfoncer le clou, la gestion du multi-tâche est devenu une caractéristique importante et j’ai été très déçu récement quand en tentant de me mettre au python, j’ai constaté qu’il n’était pas réentrant et que de ce fait, un programme python ne sais pas utiliser plus d’un coeur d’exécution.

Il est possible de faire du multithread en python : https://docs.python.org/3/library/multiprocessing.html#contexts-and-start-methods =>
“spawn

The parent process starts a fresh python interpreter process.

fork

The parent process uses os.fork() to fork the Python interpreter."

Sur ce thème, j’ai été ému en lisant le tuto sur rust et j’ai commencé à m’y mettre car je consisère ce langage comme une base très solide pour construire de belles choses légères, rapides. Le rust apporte un sacré coup de jeune aux languages compilés et redonne de l’intérêt à ce type de programmation. Là où j’aurai peut-être choisi perl ou python pour une api rest que j’ai commencé, j’ai chosi de la faire en rust avec la bibliothèque rocket et cela est prometteur.

Je n’ai pas grand chose à dire là dessus, je suis d’accord pour dire que Rust apporte des nouveautés bienvenues et que c’est un langage qui mérite de l’intérêt.

D’une manière général, je trouve votre discours trop dichotomique. Soit c’est bien, soit c’est pas bien mais il n’y a pas d’entre deux. Or l’informatique, c’est avant tout des compromis.

Et en parlant de compromis, je dirai que vous omettez une chose : le prix.
Le nerf de la guerre, c’est l’argent.
Faire de l’optimisation mémoire de poil de cul en C++, c’est une chose. Le faire en un temps raisonnable et avec un coût raisonnable, c’en est une autre.
Ensuite la maintenabilité entre en jeu. Qui peut maintenir les programmes optimisés au poil de cul ? A quel coût ?
Et donc la question ultime : est-ce que ça en vaut le coût ? (pour les pinailleurs, je sais qu’on dit “coup” mais il est littéralement question d’argent ici)
La réponse a cette dernière question est évidemment a la discrétion de chacun et c’est pourquoi dire d’un outil qu’il est mauvais de façon univoque alors qu’il répond précisément a certaines problématique est, selon moi, une erreur.

wanou a dit:

Je ne vise que JAVA dans ma critique et je peux te dire que je n’ai jamais vu un autre langage créer des lags comme java quand il démarre son ramasse miette et fige les programmes de manière impromptue et non contrôlable. Devant utiliser au quotidien des programmes écrits en java, c’est, en plus des interfaces utilisateurs pas ergonomique du tout, très pénible.

Les applis Android sont majoritairement écrites en Java (ou en tout cas tournent dans une JVM donc avec un garbage collector) et elles ne posent généralement pas de problèmes de performances.
Peut on en conclure que le langage n’est pas en faute ?

Je ne crois pas que cela soit possible en java. Peut-être que je me trompe.

Je voulais dire que si un outil n’est pas approprié, il faut en changer. Si utiliser Java et son garbage collector pose problème, il faut envisager d’utiliser une autre solution.
Il ne faut pas blâmer l’outil mais la manière dont on l’utilise donc.
Personne n’aurai l’idée de dire qu’un marteau est nul car on ne peut pas visser avec. Là c’est pareil.

Oui mais les threads sont exécutés séquentiellement sur un seul coeur. L’interpréteur Python n’étant pas ré-entrant, il est impossible de bénéficier de l’exécution simultanée des tâches. C’est ce que j’appelle le faux multi-tâche.

C’est pourtant expliqué dans la première phrase de la doc… (je commence à me poser des questions sur votre bonne foi)

“spawn

The parent process starts a fresh python interpreter process."

Cet appel démarre un nouvel interpréteur. Si il y a plusieurs interpréteur, nécessairement, ils s’exécutent en parallèle.

Encore une fois, je ne nie pas l’intérêt des scripts mais je ne trouve pas sérieux d’utiliser les languages de script, fusent-ils compilés à la volée ou non, pour des projets d’envergure. Ce que l’on reproche très régulièrement aux gros programmes écrits en java, peu importe la version de ce dernier, c’est la consommation énnorme de mémoire et de ressources processeur pour pas grand chose. C’est pareil pour les amoureux du javascript qui voudraient s’en servir pour tout. Le débat dans ces cas là n’est pas de grater un poil de c*l de perf mais d’arrêter de mettre les machines à genoux par des programmes basés sur des mauvais choix de languages.

Le manque de discernement est plutôt à chercher chez les promoteurs du javascript à toutes les sauces.

Perso, je n’envisage le javascript que côté client, là où il est adapté au besoin.

On en revient au même problème : la qualité, ça se paye. Avoir des programmes correctes qui répondent bien aux besoins (souvent farfelus) de ceux qui les demandes, ça prend du temps et de l’argent.
Quand on a pas de temps ni d’argent, ça donne des résultats de mauvaise qualité et le langage n’est pas à blâmer la dedans.

Je ne peux que vous conseiller de vous intéresser de plus prêt à ce qui se fait ailleurs et les raisons qui ont poussé ces gens à faire ces choix.
Pourquoi Node a été créé alors qu’il existe déjà d’autres solutions ?
Pourquoi Typescript alors qu’il existe déjà d’autres langages typés ?
Pourquoi Go (qui se base sur l’utilisation d’un garbage collector d’ailleurs) alors qu’il existe déjà C++ ?
Pourquoi Java alors qu’il existe déjà C++ ?
Les gens qui font et utilisent ces choses ont certainement de bonnes raisons de les faire vu la taille ces projets et le succès qu’elles rencontrent.

J’ai le sentiments que vous êtes très fermé à ces nouveautés pour des raisons qui ont l’air plus idéologique ou à cause d’idées reçues que réellement techniques (sans jugement de valeur, c’est ce que je ressens en lisant votre message).

Il est parfaitement possible de faire une API Rest d’envergure tout à fait viable et performante avec Node (le combo Typescript/NestJS est d’ailleurs vachement bien)
Il est parfaitement possible de faire une interface utilisateur en java performante (voir Android)
Il est parfaitement possible de faire du multi-thread en Python
Il est parfaitement possible de faire un programme tout pourri qui rame et qui bouffe toutes les ressources en C++ ou en Rust

La faute n’en revient pas a l’outil mais à celui qui l’utilise mal.

Je n’ai accusé personne de troller. Vous avancez un argument et j’en avance un autre. Quel est le problème ?
D’ailleurs je constate que votre propos a évolué. Au début vous accusiez clairement les langages d’être les problèmes (en disant qu’ils n’étaient pas sérieux notamment), maintenant vous reconnaissez que c’est uniquement la manière dont on les utilises.

En revanche, je n’aime pas particulièrement java et son écosystème.
Je suis d’ailleurs d’accord pour dire que c’est une mauvaise solution dans beaucoup de situations.

Je vais continuer à me faire l’avocat du diable mais vous ne mentionnez que ce qu’Orange a “perdu” en passant de C++ à Java mais jamais ce qu’ils ont pu gagné (temps de dev ou facilité à trouver du personnel compétent, par exemple).
Comme je le disais, l’informatique c’est avant tout des compromis et il n’y a pas que les performances brutes qui comptent.