[gull] [SPAM] Rust et tuto. d'un nouveau langage de programmation en général

Daniel Cordey dc at pxcluster.com
Sun Oct 16 18:21:11 CEST 2022



Le 16.10.22 à 12:49, Concombre Masqué a écrit :

> Avec C j’étais perdu en terme de structurer un programme (NB: je ne suis pas un grand dév., plutôt hobby et personne du traitement du signal ne se cantonnant pas à Matlab).

Tous mes développements sont constitués d'outils, de librairies de bas 
niveau et finalement d'autres de plus haut niveau. Chaque fonction était 
un fichier (*.c), associé à un fichier *.h, avec des flags permettant 
d'utiliser le fichier *.h comme "définition" ou comme "déclaration"; 
ceci évitant d'avoir des versions séparées, et donc des informations 
potentiellement différentes.

Tout ceci était gérer par un IDE écrit en TCL/TK et utilisant un gros 
fichier GNU Make contenant plein d'automatismes et de pratiques 
conventionnelles (définies par moi un fois pour toute). Les tests de 
conformité étaient intégré au code et devaient ne pas avoir d'erreur 
pour la construction automatique des librairies et leur installation

Ce qui fait que je pouvais avoir des centaines de fichiers sources (et 
includes), mais la maintenant et le développement était hyper facile. 
J'avais tout automatisé et je n'avais pas besoin de perdre mon temps à 
configurer des usines à gaz hyper fragiles pour ça.

Ah, j'oubliais... la doc de la signature des fonctions était 
automatiquement générée en HTML et intégrée à la doc de la librairie.

> OCaml m’a appris énormément de ce point de vue.
> Rust sera peut-être la synthèse ou plutôt le "sweet spot" performant entre C et le monde ML.

J'ai aussi mis très vite mis à la poubelle tous les trucs lourdingues et 
non-intégrés liés à *ML et autres. Il vaut mieux définir des choses 
simples que tu peux faire et maintenir avec un minimum d'effort, plutôt 
que de te lancer dans le développement de monstruosité in-maintenable et 
qu'à la fin tu ne peux même plus faire évoluer tellement c'est gros.

D'ailleurs, cela rejoins exactement ce qu'essaie de faire SCRUM, qui 
démontre l'échec des ces trucs à grands projets...

> Carbon de google, cppfront d’un tout bon de chez krosoft s’inspirent largement de Rust. Et ce sont deux candidat pour remplacer ou faire drastiquement évolué C++. Google, Krosoft...

Un langage de programmation est toujours destiné à faciliter l'écriture 
de code pour un type de problème donné. Dans les années 60, on avait 
trois langages qui avaient clairement émergé, CAD FORTRAN, COBOL et 
ALGOL. Comme aucun de ces langage n'était satisfaisant pour traiter 
d'autres problèmes que cexu pour lesquels ils avaient été conçus, des 
ingénieurs ont eu la brillante idée de vouloir réunir le "meilleur" de 
chacun de ces langages pour un faire un seul. Oui, brillante idée qui 
pense qu'en réunissant le meilleur de chacun, on va avoir un truc 
extraordinaire à la fin. Le résultat fut "PL1"... un échec retentissant 
car finalement on a eu le pire de chacun... Pour moi, un gigantesque 
éclat de rire ! Donc, je regarde tout langage qui prétend faire la 
synthèse d'autres langages avec un filtre assez ironique en me 
remémorant PL1. Et tu sais quoi `Je suis chaque fois mort de rire. 
Combien de langage soit-disant révolutionnaires depuis 1990 ? Combien 
sont vraiment utiles et n'engendrent pas de nouveau problèmes, souvent 
pire que les précédents ? On oublie le fait qu'un bon langage de 
programmation c'est avant tout de la simplicité et un éco-système.

Autre magnifique contre-exemple... ADA :-)

Le seul langage qui a trouvé grâce à mes yeux, depuis cette époque, est 
Python. Donc, j'en reste à la combinaison Bash/Python/C suivant les 
besoins et je ne vois toujours aucune bonne raison d'ajouter un autre 
langage. Sachant qu'aucun langage ne va remplacer ce trio infernal à mon 
avis.

> https://cichocinski.dev/blog/trying-new-programming-languages-helped-grow-software-engineer

Oui, en théorie et je passe souvent du temps à investiguer des nouveaux 
langages (j'ai un peu cessé depuis un moment). Mais... Si tu es employé 
par une entreprise, tu n'as pas le choix du langage ! Si tu dois engager 
des développeurs, tu veux avoir le choix et pas te cantonner à une liste 
de 200 mecs en Europe qui maîtrisent le langage. C'est aussi vrai pour 
les outils du genre reactjs, ansible, maven, jquery, etc.

dc


More information about the gull mailing list