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
_______________________________________________
gull mailing list
gull@forum.linux-gull.ch
https://forum.linux-gull.ch/mailman/listinfo/gull
