Résurgence des langages natifs face aux langages interprétés et managés

Un autre article qui va tout droit dans la section Ada.

Il y est question des langages natifs qui sortent de l’ombre que leur ont fait les environnements managés, depuis les 10 ou 15 dernières années.

Il y est question des problèmes de performances, les langages natifs étant toujours plus efficaces que les langages interprétés, même en byte‑code. Le pari à trop longtemps été fait que l’augmentation des performances des machines pouvait dédouaner de se soucier des problèmes de performances, comme si les ressources informatiques étaient sans limites. C’est ainsi qu’on s’est retrouvé avec des logiciels en langage interprété ou dans un environnement managé, fonctionnant plus lentement et consommant des dizaines de fois plus de mémoire, sur des machines modernes, que des programmes aux fonctions équivalentes, mais en langage natif, plus rapide et posant moins de problèmes de consommation de mémoire, même sur des machines 15 ans plus vieilles. Une aberration dont quelques personnes semblent enfin prendre conscience.

Il semble qu’il y ait aussi des déceptions concernant la fiabilité et que les environnement managés n’apportent pas la fiabilité qu’ils ont promis, même s’ils peuvent apporter de la sécurité, en évitant les classiques erreurs de pointeurs du C, inexistantes en Ada typique de toutes manières.

À lire : C++11 and Ada 2012 - renaissance of native languages? (electronicdesign.com). Juin 2012.

Tu as cent mille fois raison, et je ne me moque pas : vive l'assembleur !

Pour les petites choses à petites échelles, oui, mais pour les grands systèmes. Il a été démontré par la pratique qu’un langage de haut niveau produit un assembleur plus efficace que celui réalisé par un humain, qui n’a pas la capacité d’embrasser toute la complexité que représentent les opportunités d’optimisations d’un large programme. Par contre, pour les petites échelles, un humain peut imaginer des astuces qu’un compilateur ne pourra pas produire. Dans ce cas, on peut faire un fichier objet lié au programme, dont le source sera en assembleur, sans nécessairement écrire tout le programme en assembleur.

Maintenant, tout ça est pour les cas généraux et il y a sûrement des cas particuliers qui peuvent démentir cette généralité.

Tu pensais à des exemples en particulier en disant ça ?

P.S. Pour mon affirmation, j’essaierai de retrouver des sources. Fait moi‑y repenser par MP si je tarde trop ou si j’oublie.

Pas la peine de te justifier : tu as tout à fait raison !
J'aurais beaucoup de mal à imaginer un CS2 réécrit entièrement en assembleur et cela pour tout les processeurs susceptibles de la faire tourner.
Cependant, en tant que vétéran de chez Apple, je me souviens que les premiers OS (pour les processeurs 68000 de chez Motorola) étaient écrits en Pascal et hyper structurés. Ensuite les programmeurs reprenaient le code généré par le compilateur Pascal et réécrivaient chacune des routines en ASM. Un vrai travail de fourmi, impossible de nos jours.

Fatal error !
Heureusement je ne disais qu'une bêtise . Pas la peine de refaire mon message .

404 error
encore un qu'aimait pas les Peugeot

La Cinquecento ou plus récemment la Fiat 500, elles ne sont pas mieux : erreur 500, encore pire que l’erreur 404 .

Non non, ce n'était pas une erreur 404 . Je la connais celle là et ce n'est pas elle .


C'est son droit . En même temps, je le comprends elle est moche la 404 .

C'est quoi une erreur 500 ?

Erreur du serveur, c’est l’erreur la plus irrécupérable.

Bon, bref, comme les gens auront compris, ce forum qui produit des erreurs n’est pas en Ada, mais un plat de spaghettis en PHP, ce fléau du logiciel qui est malheureusement la norme sur le web, cette invention rétrograde, dont l’humanité aurait put se passer, un exemple de ces mauvais langages interprétés dans un environnement managé, que dénonce justement l’article du premier message. Je n’ai malheureusement pas le temps et la volonté de refaire tout le forum, oops, mais ça ne serait pas du luxe (peut‑être un jour, si j’ai le courage, en Ada, obviously).