Est-il possible de remplacer le C ? Le créateur du langage C3 explique pourquoi c'est difficile d'y parvenir

Est-il possible de remplacer le C ? Le créateur du langage C3 donne des raisons pour lesquelles ce type d’initiative est voué à l’échec
Au moment où le noyau Linux s’ouvre de plus en plus au Rust

Go, C3, D, … La liste des langages présentés comme des alternatives au C s’allonge avec les années qui passent. Celui qui a frappé un grand coup dans ces tentatives multiples de mise au rebut du langage C est le Rust. En effet, le noyau Linux s’ouvre de plus en plus au langage de programmation système de Mozilla. Le créateur du langage C3 met néanmoins en avant une liste de raisons pour soutenir que toutes ces initiatives de remplacement du langage C ont de fortes chances de se casser la figure.

Le créateur du langage C3 s’exprime sur divers aspects dont :

La chaîne d'outils du langage C

Le langage C n'est pas seulement le langage lui-même, mais aussi tous les outils de développement développés pour ce langage. Vous voulez faire une analyse statique de votre code source ? - Il y a beaucoup de gens qui travaillent sur ce sujet pour le C. Des outils pour détecter les fuites de mémoire, les courses de données et autres bogues ? Il y en a beaucoup, même si votre langage est mieux outillé.

Si vous voulez cibler une plateforme obscure, il est probable que vous utilisiez le C. Le statut du C en tant que lingua franca de l'informatique d'aujourd'hui fait qu'il vaut la peine d'écrire des outils pour ce langage, et de nombreux outils sont donc écrits.

Si quelqu'un a mis en place une chaîne d'outils qui fonctionne, pourquoi risquer de changer de langage ? Un "meilleur C" doit apporter beaucoup de productivité supplémentaire pour motiver le temps passé à mettre en place une nouvelle chaîne d'outils. Reste même à savoir si cela est possible.


Les incertitudes d'un nouveau langage

Avant qu'un langage ne soit arrivé à maturité, il est probable qu'il comporte des bogues et qu'il soit modifié de manière significative pour résoudre les problèmes de sémantique du langage. Et le langage est-il même conforme à la publicité ? Il offre peut-être quelque chose comme "des temps de compilation exceptionnels" ou "plus rapide que le C" - mais ces objectifs s'avèrent difficiles à atteindre lorsque le langage ajoute l'ensemble des fonctionnalités.

Et qu'en est-il des mainteneurs ? Bien sûr, un langage open source peut être bifurqué, mais je doute que de nombreuses entreprises soient intéressées par l'utilisation d'un langage qu'elles pourraient être obligées de maintenir plus tard. Parier sur un nouveau langage est un gros risque.

Le fait que le langage pourrait tout simplement ne pas être assez bon

Le langage s'attaque-t-il aux véritables points faibles du C ? Il s'avère que les gens ne sont pas toujours d'accord sur ce que sont les points sensibles du C. L'allocation de mémoire, la gestion des tableaux et des chaînes de caractères sont souvent délicates, mais avec les bonnes bibliothèques et une bonne stratégie mémoire, elles peuvent être minimisées. Le langage ne traite-t-il pas des problèmes dont les utilisateurs avancés ne se soucient pas vraiment ? Si c'est le cas, sa valeur réelle pourrait être beaucoup plus faible que prévu.

Et pire encore, que se passe-t-il si le langage omet des fonctionnalités cruciales qui sont présentes en C ? Des fonctionnalités sur lesquelles les programmeurs avancés du C comptent ? Ce risque est accru si le concepteur du langage n'a pas beaucoup utilisé le C, mais vient du C++, du Java, etc.

L’absence de développeurs expérimentés pour un nouveau langage

Un nouveau langage disposera naturellement d'un groupe beaucoup plus restreint de développeurs expérimentés. Pour toute entreprise de taille moyenne ou grande, c'est un énorme problème. Plus il y a de développeurs disponibles pour une entreprise, mieux elle se porte.

De plus, si l'entreprise a l'expérience du recrutement de développeurs C, elle ne sait pas comment recruter pour ce nouveau langage.

L'ABI C

Si le langage ne peut pas facilement appeler - ou être appelé - par du code C, alors toute personne utilisant le langage devra faire un travail supplémentaire pour faire à peu près tout ce qui est interface avec du code extérieur. C'est potentiellement un énorme inconvénient.

https://www.youtube.com/watch?v=CYvJPra7Ebk

Linus Torvalds fait-il fausse route en ouvrant le développement du noyau Linux au langage Rust ?

Les principaux mainteneurs du noyau Linux ont un âge qui commence par le chiffre 5. Certains se rapprochent même de la soixantaine. Du coup, la communauté du célèbre noyau open source commence à penser au changement de générations. Une nouvelle dont la tranche d’âge se situe dans la trentaine gravit les échelons, mais comme Linus lui-même le souligne : « Il s'avère qu'il est vraiment difficile de trouver des personnes qui sont des mainteneurs » ; un fait lié à ceci que le développement du kernel Linux continue de se faire en C et assembleur – des langages auxquels la vieille génération est plus accoutumée ? C’est une possibilité et elle est susceptible d’expliquer pourquoi 2022 pourrait être l’année du langage Rust au sein du noyau Linux. Linus Torvalds annonce en effet que Rust for Linux est susceptible d’être prêt pour la version 5.20 du noyau.

Linus Torvalds et Dirk Hohndel ont eu leur habituel échange lors d’une session de l’édition 2022 de l’Open Source Summit au cours du mois de juin 2022. Linus Torvalds commentait alors sur les évolutions du projet Rust for Linux en soulignant qu’il est susceptible d’être prêt pour Linux 5.20. Les publications de Miguel Ojeda, chef du projet Rust for Linux, avait déjà permis de dresser une liste des progrès de l’initiative : support d’un compilateur Rust bêta, test du support des architectures ARM et RISC-V, nouvelles abstractions Rust, etc.

15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans (chiffres du dictionnaire Common Vulnerabilities and Exposure (CVE)) sont liées à des tares que traînent le langage C : problèmes liés à la gestion de la mémoire – dépassements de mémoire tampon, allocations non libérées, accès à des zones mémoire invalides ou libérées, etc. Linus Torvalds s’est penché il y a peu sur un potentiel problème de sécurité avec les fonctions primitives d'exécution spéculative de la liste liée du noyau écrit en ANSI C. C’est en corrigeant ce problème qu’il s’est rendu compte qu’en C99 l'itérateur passé aux macros de parcours de liste doit être déclaré dans une portée en dehors de la boucle elle-même. C’est de ce constat que venait sa récente décision de faire passer le noyau Linux au C moderne (C11) dont la normalisation est achevée en 2011. C’est le genre de raisons techniques susceptibles de justifier la mise au rebut du langage C au profit du Rust pour le développement du noyau sur le long terme.

La nouvelle arrive dans un contexte où le regard de Linus Torvalds sur le langage Rust a changé. En effet, la prise en charge de Rust pour le développement du noyau Linux commence à prendre forme et est vue comme une « une étape importante vers la capacité d'écrire les pilotes dans un langage plus sûr. » Rust de Mozilla Research est le type de langage de programmation auquel ceux qui écrivent du code pour des systèmes d’entrée/sortie de base (BIOS), des chargeurs d’amorce, des systèmes d’exploitation, etc. portent un intérêt. D’avis d’observateurs avertis, c’est le futur de la programmation système en lieu et place du langage C. En effet, des experts sont d’avis qu’il offre de meilleures garanties de sécurisation des logiciels que le couple C/C++. Chez AWS on précise que choisir Rust pour ses projets de développement c’est ajouter l’efficacité énergétique et la performance d’exécution du C à l’atout sécurité.

Et vous ?

:fleche: Quel commentaire faites-vous de l’argumentaire du créateur du langage C3 ? Quels sont les aspects les plus pertinents ? Quels sont ceux qui le sont moins ?
:fleche: La difficulté de trouver des mainteneurs est-elle la conséquence de ce que le développement du noyau Linux continue de se faire en C et en assembleur au moment où les développeurs s’intéressent de plus en plus à des langages comme Rust ?
:fleche: Êtes-vous aussi d’avis que la communauté Linux anticipe non seulement sur les départs en retraite des actuels mainteneurs et sur les qualités que Rust offre en comparaison au langage C ?
:fleche: Pourquoi le langage C pourrait encore avoir de longues années devant lui ?
:fleche: Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?
:fleche: Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?
:fleche: Voyez-vous des firmes comme Intel faire migrer des projets comme l’UEFI vers le Rust ? Doivent-elles plutôt envisager de passer au Rust pour leurs futurs projets ?

Voir aussi :

:fleche: Programmation : une étude révèle les langages les plus voraces en énergie, Perl, Python et Ruby en tête, C, Rust et C++, les langages les plus verts

:fleche: Linus Torvalds souligne une bonne avancée du langage Rust dans le développement du noyau Linux, et aurait qualifié le C++ de « langage de m... », après le message de Google

:fleche: Microsoft, Google, AWS, Huawei et Mozilla s'associent pour créer la Fondation Rust, une organisation à but non lucratif chargée de gérer le langage de programmation

:fleche: Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents

Pour moi, aucun langage ne peut le remplacer, il a ce petit truc à lui, parfois, on l'aime comme on le déteste !
Blague à part, les bases de code existant en C sont immenses, ça aurait un coût financier non négligeable et je vois mal les entreprises ou projet changer de langage du jour au lendemain.
Malgré tout le bien que je pense de Rust, pour moi le C à encore de belle année devant lui.

Moi je ne comprends même pas le concept "remplacer le C". Il a quoi de tellement mauvais qu'on veuille à tout prix le remplacer??? Ok il n'est pas parfait, mais aucun langage ne l'est (Herbert Mayer). Donc s'il est adapté à l'usage qu"on en fait, pourquoi chercher alors à le remplacer??? Pourquoi on ne voit pas le même genre de question avec "est-il possible de remplacer le COBOL" ou "est-il possible de remplacer ADA" ???
C'est quand-même fou ça, il y a un langage spécifique à un usage ; pour cet usage il est alors majoritairement utilisé (un peu normal, le bateau est fait pour aller sur l'eau, tous ceux qui vont sur l'eau utilisent donc un bateau ce qui est parfaitement logique) et tout va bien. Mais non, on voit arriver des illuminés qui disent "il faut remplacer le C" et tout le monde embraye à chercher le "comment faire" sans même chercher le pourquoi de ce "il faut". Sans déconner, il n'y aurait pas des problèmes informatiques plus intelligents vers lesquels orienter les efforts ?

Citation:

---

Envoyé par Sve@r

Il a quoi de tellement mauvais qu'on veuille à tout prix le remplacer???

---

Parce qu'en C (comme avec le C++ avant 2011, quoique), on se focalise plus sur le "comment faire" et non sur le "ce que je dois faire"
Ce n'est pas pour rien que les mêmes "critiques" reviennent : gestion de la mémoire, gestion des dépendances, chaînes de caractères, multitâches, ...

Et je pense que ce qui embête les développeurs, 1 langage bas niveau rapide, il n'y a que le C ... et éventuellement le C++.
Le C "responsable" de "15,9 % des 2288 vulnérabilités qui ont affecté le noyau Linux en 20 ans" : je ne trouve pas cela énorme ... mais Linus et son équipe ont dû fournir 1 travail très très rigoureux

Citation:

---

Envoyé par Sve@r

Moi je ne comprends même pas le concept "remplacer le C"

---

:whistle: on peut toujours créer 1 langage qui transpile en C, comme le faisait le C++ (+ le cas depuis longtemps) et 1 autre exemple, le TypeScript vers JavaScript. Et ainsi, au prix d'1 complexité à la compilation et d'1 temps + long, on peut garder le langage C ... et les anciens projets.

Après on peut penser qu'il y a 1 intérêt politique :mrgreen:

Actuellement :

• les systèmes d'exploitation grand public sont américains : Windows/ Microsoft, Android (Linux)/ Google, OS et iOS (Unix)/ Apple et Linux (Linus Torvalds est américain et vit aux États-Unis)
• les processeurs grand public sont américains : Intel et AMD. PowerPc/ IBM est américain.

Donc, si tu arrives à faire 1 langage bas niveau rapide et qu'il soit "simple" à coder, au moins la Chine et la Russie (peut-être l'Inde) pourront faire leur propre système d'exploitation souverain.
La Chine est en train de faire des processeurs [RISC].
De toute façon, à terme, c'est ce qu'il va se passer : les américains vont perdre leur monopole technologique mais dans combien de temps ?
Ces pays là ont potentiellement des millions de développeurs, cela peut aller très vite.

Aucun langage informatique d'envergure n'a été massivement adopté à cause de ses qualités intrinsèques, mais parce qu'il correspondait aux besoins du moment.

La vraie question à se poser est donc : quel besoin pourrait satisfaire Rust que le C ne comble pas ?

Début de réponse : peut-être que la popularité de Rust grandira le jour où webassembly décollera.

Si c'est pour implémenter du code qui limite les failles "techniques", rust peut être une solution.

Pour le reste... C est un langage de bas niveau, et à ce niveau il est plutôt bon. Si c'est pour manipuler des matrices/faire du calcul réparti, certains ont pensé que python serait bon, mais de mon point de vue fortran+MPI (ou autre) était déjà mieux avant.

Le problème des langages informatique n'est pas la complexité du langage: c'est le temps pour maîtriser le langage. Alors tous les 4 ans, on nous sort un langage qui promet d'être meilleur, plus rapide, plus simple... Et qui au bout de 4 ans s'est complexifié au niveau du langage d'origine.

Et c'est se masquer la difficulté actuelle qui est la maîtrise des bibliothèques, des risques de sécurité, des interactions entre briques...

Si un nouvel ordi se programme dans un dérivé de Pascal, C et Basic, je n'y vois pas d'inconvénient.

Ayant ressorti un vieil atari 800, je peux dire une chose: à l'époque le basic était lent, mais très efficace: pas de configuration à rallonge, pas d'initialisation technique dans tous les sens... Juste une ligne de sélection de mode et le code du programme.
Et cette simplicité, sans le besoin de faire des imports, des init, des $(document).ready(), de connaître ses includes, son int main(char** argc), c'est ça qui manque pour ne pas faire peur aux nouveaux venus.

Le C n'est pas parfait ni RUST.
Cependant, je trouve pertinent de pousser le développement de nouveaux modules en RUST si on peut avoir un code sécure du premier coup.
Si un module complexe en C a souvent des vulnérabilités, l'écriture en RUST peut aussi s'étudier.

C excellent dans les trucs qui nécessite une gestion serrée de la mémoire. Et il y aura des situation où cela va rester une nécessité. Comme par exemple dans la fabrication de micro-contrôleurs.

Parce qu'il y avait une pénurie de langage compilé pendant l'émergence des ordinateurs personnels, le C est devenu un langage bouche-trou. Dans les faits, il y a très peu de raison de faire encore des programmes en C. Des librairies en C, dans certains cas, cela reste valable, mais ce n'est plus essentiel.

Citation:

---

Envoyé par Jeff_67

Début de réponse : peut-être que la popularité de Rust grandira le jour où webassembly décollera.

---

Ou quelque chose de semblable à webassembly. Mais ce qui devient de plus en plus flagrant est que nous pouvons pas exploiter les CPU multi-coeurs de façon optimal avec l'approche actuel.

Perso, je pense que rust n'est pas plus fait pour remplacer le C que python. C'est un langage de programmation système, certes, et de ce fait c'est un langage fait pour des utilisations telles qu'au sein d'un Kernel. Mais le C n'est pas qu'un langage pour Kernel, et idem pour rust. Mis à part cela, je trouve qu'ils ont des objectifs et designs très différent: je ne pense pas que l'on puisse parler de rust comme une amélioration du C, c'est un tout autre langage qui n'a que peux a voir avec C.

Si on cherche un compétiteur au C, je suggérerais plutôt Zig: ce langage est vraiment basé sur le design et les buts de C, et a une interopérabilité avec le C quasi parfaite.

Citation:

---

Envoyé par steel-finger

Blague à part, les bases de code existant en C sont immenses, ça aurait un coût financier non négligeable et je vois mal les entreprises ou projet changer de langage du jour au lendemain.

---

Tout dépend ce que l'on entend par "remplacer le C". S'il s'agit de réécrire tout le code C existant dans un autre langage, ça serait évidement idiot et même irréalisable dans des conditions normales de productivité.
Je pense que la seule façon intéressante de comprendre "remplacer le C", c'est "prendre sa place en tant que langage de choix pour faire des projets bas niveau".

Citation:

---

Envoyé par Sve@r

Pourquoi on ne voit pas le même genre de question avec "est-il possible de remplacer le COBOL" ou "est-il possible de remplacer ADA" ???

---

Soit sûr que ces questions ont été posées un nombre incalculable de fois, particulièrement pour COBOL où on se la pose encore aujourd'hui chez nous. C'est compliqué à faire à cause de la base de code existant, mais sans ça il aurait disparu il y a bien longtemps. Si COBOL est encore là, ce n'est certainement pas pour ses qualités intrinsèques.
Si on ne voit plus ces question partout dans les articles qui traitent de programmation ces derniers temps, c'est surtout parce que les alternatives à COBOL sont déjà très bien implantées depuis les années 90, alors que les alternatives au C étaient plutôt discrètes avant l'émergence de Rust ou Zig.

Citation:

---

Envoyé par Sve@r

C'est quand-même fou ça, il y a un langage spécifique à un usage ; pour cet usage il est alors majoritairement utilisé (un peu normal, le bateau est fait pour aller sur l'eau, tous ceux qui vont sur l'eau utilisent donc un bateau ce qui est parfaitement logique) et tout va bien. Mais non, on voit arriver des illuminés qui disent "il faut remplacer le C" et tout le monde embraye à chercher le "comment faire" sans même chercher le pourquoi de ce "il faut". Sans déconner, il n'y aurait pas des problèmes informatiques plus intelligents vers lesquels orienter les efforts ?

---

Bien évidement qu'on c'est posé la question du "pourquoi". Le C a beau répondre a un usage, les besoin évoluent aussi.
Le C traine derrière lui 50 ans d'histoire. Il a été créé dans les années 70 où il devait pouvoir être compilé sur des machines avec au plus quelques Mhz de fréquence d'horloge et quelques Mo de RAM. Des choix ont été fait à l'époque pour permettre une compilation simple qui ne se justifient plus vraiment aujourd'hui. De même à cette époque la sécurité du code était une préoccupation plutôt lointaine, les considération de qualité et de réutilisabilité du code étaient différentes, les besoins de modules tiers étaient bien moins importants, ...

Je ne dis pas que le C n'a pas évolué, mais il est clairement encore très contraint par des choix de design de l'époque qu'il ne peux pas remettre en cause, c'est pour cela que la question d'un langage alternatif n'est pas idiote.

Citation:

---

Envoyé par Madmac

C excellent dans les trucs qui nécessite une gestion serrée de la mémoire. Et il y aura des situation où cela va rester une nécessité. Comme par exemple dans la fabrication de micro-contrôleurs.

---

Dans ce domaine, des langages comme Zig ou Rust peuvent faire aussi bien le travail que le C. La contrainte technique pour le moment étant la disponibilité des compilateurs pour les architectures plus rare.

Citation:

---

Envoyé par Uther

Dans ce domaine, des langages comme Zig ou Rust peuvent faire aussi bien le travail que le C. La contrainte technique pour le moment étant la disponibilité des compilateurs pour les architectures plus rare.

---

Je ne connaissait pas Zig. Et effectivement il me semble être une alternative vraiment intéressante. Le fuites de mémoire en C m'ont tenu loin de ce langage. Ce langage semble offrir des solutions sérieuses pour s'en protéger. Et c'est le seul que j'ai vu qui offre une façon de se débarrasser de null. https://ziglang.org/fr/learn/overview/

Je vois plus Rust comme alternative pour des application plus lourdes qui demanderait l'utilisation de l'héritage en C++.

Bonjour,

Bien entendu, on ne peut pas affirmer que le C ne sera jamais remplacé, mais il est tellement implanté que ça va demander du temps. :)

Pensez au "bon vieux" Cobol encore utilisé ... :?

Citation:

---

Envoyé par droggo

Pensez au "bon vieux" Cobol encore utilisé ... :?

---

Il n'y a pas de quoi être dépité. Le COBOL possède deux avantages

• c'est une locomotive. Il est lent à se mettre en marche, mais une fois lancé, il avale tout fichier quel que soit sa taille
• c'est un des seuls langages à savoir calculer les décimaux sans la perte due à la conversion décimal => binaire. Sa façon de définir les nombres (exemple pic 99v99 signifiant 4 chiffres dont 2 après la virgule) en fait un langage privilégié pour tout ce qui a trait aux calculs où la vitesse compte moins que la précision (banques, impôts, etc)

Comme quoi, le coup des vieilles marmites qui font les meilleures soupes, ça marche aussi avec les langages. Peut-être que le C sera remplacé, je n'en sais rien, mais ce dont je suis sûr c'est que si ça doit se faire, cela se fera naturellement sans "forcer" les choses, comme le Trésor Public qui est en train de remplacer le COBOL par Python, autre langage qui peut aussi calculer les décimux avec précision via son module "decimal". Et Python est né en 1989 (33 ans à mûrir avant qu'il soit pris en considération pour commencer à remplacer le COBOL...)

Citation:

---

Envoyé par Sve@r

c'est un des seuls langages à savoir calculer les décimaux sans la perte due à la conversion décimal => binaire. Sa façon de définir les nombres (exemple pic 99v99 signifiant 4 chiffres dont 2 après la virgule) en fait un langage privilégié pour tout ce qui a trait aux calculs où la vitesse compte moins que la précision (banques, impôts, etc)

---

N'importe quel langage un tout petit peu évolué permet de coder une bibliothèque avec un type décimal. Parmi ces langages, n'importe quel langage qui supporte la surcharge d'opérateurs permet de manipuler ces nombres décimaux avec une syntaxe pas trop casse-pieds.

Par exemple, voici un script Rust qui utilise les crates rust_decimal et rust_decimal_macros :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

#!/usr/bin/env rust-script   // cargo-deps: rust_decimal="1.26.1", rust_decimal_macros="1.26.1" extern crate rust_decimal; extern crate rust_decimal_macros;   use rust_decimal::Decimal; use rust_decimal_macros::dec;   fn main() { let amount = dec!(25.12); let tax = dec!(0.085); let total = amount + (amount * tax); let price = total.round_dp(2); println!("total == {total}"); println!("price == {price}"); println!("Size of each Decimal object: {} bytes", std::mem::size_of::<Decimal>()); println!("Smallest possible value: {}", Decimal::MIN); println!("Largest possible value: {}", Decimal::MAX); }

---

Résultat :

Code:

---

1 2 3 4 5

total == 27.25520 price == 27.26 Size of each Decimal object: 16 bytes Smallest possible value: -79228162514264337593543950335 Largest possible value: 79228162514264337593543950335

---

Pour rajouter à ce que dit Pyramidev, même si le résultat affiché correspond mieux à ce que s'attend à voir un utilisateur final, l'utilisation d'un type décimal ne garantit absolument pas qu'il n'y aura pas de problème d'arrondis, sur les divisions par exemple, c'est juste qu'il n'arrivent pas dans les mêmes cas.

Citation:

---

Envoyé par Pyramidev

N'importe quel langage un tout petit peu évolué permet de coder une bibliothèque avec un type décimal. Parmi ces langages, n'importe quel langage qui supporte la surcharge d'opérateurs permet de manipuler ces nombres décimaux avec une syntaxe pas trop casse-pieds.

---

Oui évidemment. Mais ce sont les langages du jour. Le COBOL lui date de 1970 et à l'époque était le seul. Donc fatalement c'est celui qui a été utilisé pour ça.
Attention, je ne dis pas que j'aime le COBOL. C'est un langage ignoble rempli de contraintes innomables (identification division, data division et autres). Obligé de déclarer et définir les caractéristiques de tout fichier qui sera traité. Obligé de commencer toute instruction à la 8° position de la ligne car les 7 premières ne sont pas prises en compte (raison???). Aucune instruction de boucle autre que "goto".
Mais comme à l'époque c'était le seul capable d'additionner des décimaux, ça a été la raison qui a fait que. Et si on veut le remplacer par un langage plus récent il faudra tout recoder (d'ailleurs comme je l'ai dit c'est en cours car fin 2019 j'ai vu passer une offre de poste au Ministère des Finances de Nantes demandant un dev connaissant COBOL et Python pour réécrire tout leurs programmes).

Citation:

---

Envoyé par Uther

l'utilisation d'un type décimal ne garantit absolument pas qu'il n'y aura pas de problème d'arrondis, sur les divisions par exemple

---

Ah effectivement, je n'ai jamais dit que le type decimal pouvait régler ce genre de souci et trouver le résultat exact de par exemple 1/3.
En fait, le type decimal est fait pour travailler sur les nombres décimaux, ce que n'est pas la fraction 1/3 qui est un nombre rationnel.
Le type decimal pourra donc calculer avec exactitude des sommes (positives ou négatives) ainsi que des multiplications de décimaux (ce qui est parfait pour tout ce qui a trait aux finances et/ou domaine bancaire, raison pour laquelle le COBOL est encore si présent dans ce domaine) mais si on le confronte à des divisions ou autres calculs plus complexes, lui aussi sera bloqué par ce mur que sont les limites mathématiques.

Citation:

---

Obligé de commencer toute instruction à la 8° position de la ligne car les 7 premières ne sont pas prises en compte (raison???)

---

Citation:

---

Les six premières colonnes de chaque ligne de programme sont considérées comme une zone de commentaire, servant autrefois à numéroter les cartes perforées (en cas de chute du paquet, il suffisait de les passer sur une trieuse pour reconstituer la version correcte du programme). La septième colonne contient un caractère de contrôle : espace pour les lignes actives, étoile pour les commentaires, tiret comme caractère de continuation.

---

Citation:

---

Envoyé par Sve@r

Ah effectivement, je n'ai jamais dit que le type decimal pouvait régler ce genre de souci et trouver le résultat exact de par exemple 1/3.
En fait, le type decimal est fait pour travailler sur les nombres décimaux, ce que n'est pas la fraction 1/3 qui est un nombre rationnel.

---

C'est même plus subtil que ça. Si en COBOL tu as une précision décimale de deux chiffres (cas classique) un bête 1/8 qui est bien un décimal (0,125) sera arrondi alors qu'en binaire ça serait passé sans perte de précision. Le décimal n'est pas foncièrement plus précis, juste plus facile a appréhender pour les humains qui sont habitués à calculer en base 10.

Citation:

---

Envoyé par Madmac

Je vois plus Rust comme alternative pour des application plus lourdes qui demanderait l'utilisation de l'héritage en C++.

---

Sauf qu'il n'y a pas vraiment de classes et d'héritage en Rust.

En tout cas, on est très loin des possibilités de C++.

Citation:

---

Envoyé par Madmac

Je ne connaissait pas Zig. [...] Et c'est le seul que j'ai vu qui offre une façon de se débarrasser de null

---

Rust non plus ne connait pas null.

Je comprends l'engouement pour Rust et il a sa place dans ce type de projet (pour une fois qu'il sera choisi pour de bonnes raisons...)
Sauf qu'il a aussi des travers et il ça apporter son lot de crasses. Du coup on va avoir 3 langages dans le noyau, des soucis de compilation et des comportements de gestion de mémoire parfois compliqués à gérer. Rust c'est une bonne idée mais il ne faut pas le voir comme le messie.

Citation:

---

Envoyé par Sve@r

... le Trésor Public qui est en train de remplacer le COBOL par Python, autre langage qui peut aussi calculer les décimux avec précision via son module "decimal". Et Python est né en 1989 (33 ans à mûrir avant qu'il soit pris en considération pour commencer à remplacer le COBOL...)

---

Juste pour illustrer les limites d'un type decimal qui ont été évoquées plus haut, je ne peux rien dire en rust ou cobol, par contre je confirme qu'en python les modules standards sont vraiment pratiques pour le calcul. Le problème d'arrondi peut être géré voire totalement évité.
Le module decimal a une précision par défaut de 28 chiffres (précision pouvant être changée de manière arbitraire). Le module fractions permet le calcul exact des fractions.

Code:

---

1 2 3 4 5 6 7 8 9

In [2]: from decimal import *   In [3]: from fractions import *   In [4]: Decimal(1) / Decimal (3) Out[4]: Decimal('0.3333333333333333333333333333')   In [5]: Fraction(1,3)+ Fraction(2,3) Out[5]: Fraction(1, 1)

---

Le problème des arrondis peut bien sur être géré si on sait bien ce que l'on fait, mais certainement pas totalement évité, sauf si on ne va pas plus loin que la division.
Si on a besoin de trigonométrie, de certaines statistiques, voire même certaines formules comptables un peu complexes, ... on va vite se retrouver avec des nombres réels que l'on est obligé d’approximer comme π, e ou √2.

Comme on parle de fractions :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

#!/usr/bin/env rust-script   // cargo-deps: num-rational="0.4.1" use num_rational::Rational32;   fn main() { let one_third = Rational32::new(1, 3); let two_thirds = Rational32::new(2, 3); let one = one_third + two_thirds; let number = one_third * one_third + two_thirds * two_thirds; println!("{one_third}, {two_thirds}, {one} and {number}"); }

---

Résultat :

Code:

---

1/3, 2/3, 1 and 5/9

---

Le crate num-rational supporte plusieurs types de fraction.
Rational32 stocke une paire d'entiers de 32 bits.
Il existe aussi Rational64 qui stocke une paire d'entiers de 64 bits.
Si on veut une précision arbitrairement grande, on peut aussi utiliser BigRational qui stocke une paire de BigInt.

PS : je me rends compte que mes deux lignes avec extern crate n'étaient pas nécessaires dans mon précédent message.

J'ai essayé Rust pour voir ce qu'il en etait et si ca valait le coup d'investir du temps. J'ai rapidement laissé tomber. Pourquoi se reformer de 0 pour un langage qui fera la meme chose au final.
Je prefere peaufiner mes connaissances sur C++ et les dernieres normes pour me mettre a jour et tirer partie des ameliorations du langage (sans tout jeter les outils et autres que j'ai l'habitude d'utiliser).

Pour moi c'est autant une mauvaise raison que ceux qui se plaignaient de la gestion memoire ou des pointeurs en C. Trop compliqué de liberer la memoire allouée ? Il faut juste etre rigoureux. D'ailleurs ca se retrouve maintenant avec les nouveaux devs qui n'ont connu que C# dans mes equipes. Ils n'ont aucune notion de gestion des ressources; croient que les ressources sont infinies, l'optimisation de code pour eux c'est remplacer des foreach par des for etc. montent en memoire des listes de plusieurs GOs sans que ca ne les interpelle. Et quand ca ne va pas assez vite, ils mettent en cause le reseau, le manque de memoire etc. Bref jamais aucune remise en cause de leur code.
Bref, mauvais diagnostic et mauvaises optimisations a chaque fois car ils ne comprennent pas comment ca fonctionne et ce que fait concretement leur langage préféré.

J'ai repris recemment un bout de code que j'avais ecrit en C++ il y a 20 ans. Voulu le refaire en C# en equivalent (sans pointeur).
Beaucoup de manipulation de listes en memoire. Au final une perf catastrophique (x5) en C#.
Du coup j'ai prefere remettre a niveau le code vers C++20 pour beneficier des simplifications du langage mais en conservant le code ecrit il y a 20 ans qui fonctionnait toujours de maniere aussi performante (meme plus avec les nouveaux processeurs et compilos).
Bref j'ai arrete de vouloir reecrire des choses perennes qui font le boulot juste pour passer vers un langage a la mode dont la duree de vie n'est pas garantie.

Citation:

---

Envoyé par kilroyFR

J'ai essayé Rust pour voir ce qu'il en etait et si ca valait le coup d'investir du temps. J'ai rapidement laissé tomber. Pourquoi se reformer de 0 pour un langage qui fera la meme chose au final.

---

Avec ce type de raisonnement on en serait encore a l'assembleur.
Rust ne permet évidemment pas à l'application finale de faire plus qu'une application écrite en C, cependant, il apporte des abstractions évoluées, de bien plus fortes garanties sur la sécurité, un ensemble d'outils intégrés cohérents, ...

Citation:

---

Envoyé par kilroyFR

Pour moi c'est autant une mauvaise raison que ceux qui se plaignaient de la gestion memoire ou des pointeurs en C. Trop compliqué de liberer la memoire allouée ? Il faut juste etre rigoureux.

---

Ce qui ne marche pas dans la pratique. Si on a un programme un minimum complexe, même les développeur chevronnés finissent par laisser passer des erreurs mémoire qui passeront inaperçues.

Citation:

---

Envoyé par kilroyFR

D'ailleurs ça se retrouve maintenant avec les nouveaux devs qui n'ont connu que C# dans mes equipes. Ils n'ont aucune notion de gestion des ressources; croient que les ressources sont infinies, l'optimisation de code pour eux c'est remplacer des foreach par des for etc. montent en memoire des listes de plusieurs GOs sans que ca ne les interpelle. Et quand ca ne va pas assez vite, ils mettent en cause le reseau, le manque de memoire etc. Bref jamais aucune remise en cause de leur code.

Bref, mauvais diagnostic et mauvaises optimisations a chaque fois car ils ne comprennent pas comment ca fonctionne et ce que fait concretement leur langage préféré.

---

Des mauvais développeurs, il y en a toujours quelque soient les langages, mais pour le coup, c'est plutôt une excellente raison d'utiliser Rust qui est un langage très peu permissif et qui les oblige à apprendre a gérer correctement soi même pas mal de choses qui sont gérées automatiquement par C#/Java avec un impact sur les performances, ou qui seraient ignorées en C/C++ avec au final des problèmes de qualité.

Citation:

---

Envoyé par kilroyFR

J'ai repris recemment un bout de code que j'avais ecrit en C++ il y a 20 ans. Voulu le refaire en C# en equivalent (sans pointeur).
Beaucoup de manipulation de listes en memoire. Au final une perf catastrophique (x5) en C#.

---

Oui mais la on parle pas du même type de langage. Si tu passe d'un langage système à un langage managé, bien sur qu'il faut t'attendre a des performances inférieures. Là on parle des remplaçants à C, donc des langages systèmes comme Zig ou Rust qui sont censés avoir des capacités et des performances similaires.

Citation:

---

Envoyé par kilroyFR

Il faut juste etre rigoureux.

---

Fallait dire ça aux programmeur de Ariane 5: https://fr.wikipedia.org/wiki/Vol_501_d%27Ariane_5

Le gros désavantage du C , c'est son nombre d'UB et de manque de sécurité.
Et plus le programme est complexe, plus il est difficile de penser à toutes les "possibilité" pour éviter un bug.

Je suis d'accord sur le constat, même si pour le coup, l'exemple n'est pas bon : le code de pilotage qui a posé problème à Ariane 5 était programmé en Ada.

Citation:

---

Envoyé par Kannagi

Citation:

---

Envoyé par kilroyFR

Il faut juste etre rigoureux.

---

Fallait dire ça aux programmeur de Ariane 5: https://fr.wikipedia.org/wiki/Vol_501_d%27Ariane_5

---

Dans le rapport après accident, il est dit que les essais du système de navigation, qui provenait de Ariane4, n'ont pas été faits pour économiser 800000FF? Ca me semble pas être la faute des programmeurs (qui, eux, avaient codé ce système pour Ariane4 avec toute la rigueur nécessaire à ce lanceur) mais plutôt d'un chef de service quelconque qui a dit "ouais ça mache en v4 ça marchera en v5". Les programmeurs, eux, ne peuvent pas être accusés de manque de rigueur.

Citation:

---

Envoyé par Kannagi

Le gros désavantage du C , c'est son nombre d'UB et de manque de sécurité.

---

Oui, c'est comme ça qu'il se présente. Il dit clairement tout ce qu'on a le droit de faire en disant tout aussi clairement que ce qui n'est pas autorisé n'est alors pas garanti. On peut aimer ou ne pas aimer cet état d'esprit mais on ne peut pas venir le lui reprocher alors qu'on est au courant dès le départ. On n'est pas non plus obligé de faire du C si on juge ce langage inadapté au but à atteindre.

il y a un paquet d'interventions dans ce thread de personne qui semble ne jamais avoir touché une ligne de c ... bref ...

Citation:

---

Envoyé par Sve@r

Oui, c'est comme ça qu'il se présente. Il dit clairement tout ce qu'on a le droit de faire en disant tout aussi clairement que ce qui n'est pas autorisé n'est alors pas garanti. On peut aimer ou ne pas aimer cet état d'esprit mais on ne peut pas venir le lui reprocher alors qu'on est au courant dès le départ. On n'est pas non plus obligé de faire du C si on juge ce langage inadapté au but à atteindre.

---

un UB n'a rien à voir avec une autorisation, c'est un comportement non défini dans la spec O_o
le problème est donc dans l'identification des UB dans le code que tu as produit vu qu'en général le compilateur ne te dit justement pas où sont les UB possibles dans ton code ...

Citation:

---

Envoyé par stardeath

un UB n'a rien à voir avec une autorisation, c'est un comportement non défini dans la spec O_o

---

Ah c'est bon, arrête de jouer sur les mots. J'ai dit "autorisation" pour simplifier. Un comportement non défini parce que instruction (exemple taper dans tab[-1]) non autorisée.

Citation:

---

Envoyé par stardeath

le problème est donc dans l'identification des UB dans le code que tu as produit vu qu'en général le compilateur ne te dit justement pas où sont les UB possibles dans ton code ...

---

Ben oui. Ta fonction reçoit l'adresse d'un tableau dans un pointeur, puis elle décale ce pointeur de 50 sans savoir que le tableau d'origine en fait seulement 10 (sans parler du fait que l'appelant peut très bien avoir passé non pas le début du tableau à la fonction mais passé une adresse se situant au milieu du tableau) et va taper à cet endroit. Effectivement le compilateur aura du mal à voir ça. Et donc? Qu'est-ce que cela est censé prouver?? Que le compilateur doit remplacer ton cerveau???

Citation:

---

Envoyé par Sve@r

Ah c'est bon, arrête de jouer sur les mots. J'ai dit "autorisation" pour simplifier. Un comportement non défini parce que instruction (exemple taper dans tab[-1]) non autorisée.

---

lol, tu confirmes que justement tu ne dois pas faire souvent du c, une fois de plus, même pour simplifier, ça n'a RIEN à voir avec une autorisation, le code que tu écris peut potentiellement être totalement valide, exemple si ton compilateur complète la spec en définissant les comportement des UB ...
pire, l'exemple que tu prends peut être parfaitement défini ...

Citation:

---

Envoyé par Sve@r

Ben oui. Ta fonction reçoit l'adresse d'un tableau dans un pointeur, puis elle décale ce pointeur de 50 sans savoir que le tableau d'origine en fait seulement 10 et va taper à cet endroit. Effectivement le compilateur aura du mal à voir ça. Et donc? Qu'est-ce que cela est censé prouver?? Que le compilateur doit remplacer ton cerveau???

---

tu as déjà développé qqch? parce que l'homme, justement pour compléter ce que la spec et les compilateurs ne font pas, a créé des outils genre analyse statique et autres qui justement eux sont capables de détecter un paquet d'erreurs possibles ...
mais visiblement ton cerveau génial ne fait jamais d'erreur, ou ne code pas, au choix.

bref ...

C'est bien de faire des leçons sur les gens qui ne feraient pas de C, mais il faut éviter de dire des bêtises ensuite ;)

Citation:

---

ton compilateur complète la spec en définissant les comportement des UB

---

Non.

Il définit les comportements des "implementation-defined behaviors". Les "undefined behaviors" ne sont jamais définis.

Voir https://stackoverflow.com/a/2397995/12342718

non mais sérieux, tu lis ce que tu as écrit au moins?

Citation:

---

Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).

---

"documented manner characteristic of the environment" ça s'appelle définir le comportement ... mais au secours ...

Citation:

---

Envoyé par stardeath

lol, tu confirmes que justement tu ne dois pas faire souvent du c

---

Ouais, pas souvent. Tu as fait une recherche sur mon pseudo dans le fofo C pour voir ce que j'y avais écrit ou bien tu veux juste provoquer gratuitement ?

Citation:

---

Envoyé par stardeath

non mais sérieux, tu lis ce que tu as écrit au moins?

---

En tout cas on lit au moins ce que tu écris et ce qui en sort, en dehors des provocations gratuites... rien.

la première chose que je fais quand on me montre que je me suis planté sur un point technique c'est d'admettre que je me suis planté.
ici, le sport national c'est de trouver tous les moyens nécessaires pour ne pas perdre la face, quitte à se justifier avec un écrit qui au final ne contredit rien.

mais t'as raison, si tu ne tires rien de ce que j'ai écrit, je vais arrêter de lire/écrire sur ce sujet, j'ai autre chose à faire de mes journées :ptdr:

Citation:

---

Envoyé par Sve@r

Oui, c'est comme ça qu'il se présente. Il dit clairement tout ce qu'on a le droit de faire en disant tout aussi clairement que ce qui n'est pas autorisé n'est alors pas garanti. On peut aimer ou ne pas aimer cet état d'esprit mais on ne peut pas venir le lui reprocher alors qu'on est au courant dès le départ. On n'est pas non plus obligé de faire du C si on juge ce langage inadapté au but à atteindre.

---

Sauf que ça c'est de la théorie, mais ça ne tient pas l'épreuve de la pratique. Ce qui te dit ce que tu as le droit de faire ou non en C, ce n'est pas le langage mais sa spécification, que probablement moins de 1% des dev C ont lu. Je serais surpris que beaucoup de développeur C connaisse seulement la moité des presque 200 cas de comportement indéfinis dans le langage. Et même les cas que l'on connait, c'est pas toujours évident de les éviter. Dans un code un minimum complexe, même les meilleurs programmeur en laisseront passer.
Pour le coup un langage qui te dis bien ce que tu as et n'as pas le droit de faire c'est Rust. Il te met dans des clous qui font que tu ne peux pas rencontrer de comportement indéfini a moins que tu décides volontairement de prendre le risque en le signalant explicitement via un bloc 'unsafe'.

On peut tout a fait utiliser un langage pour certaines raison et trouver qu'il pose problème pour d'autres. Et non on a pas toujours le choix. Il y a encore beaucoup de cas ou il est difficile de faire autre chose que du C ou du C++, c'est pour ça que les alternative récentes comme Rust ou Zig changent la donne en offrant de vraies nouveautés au développeurs bas niveau.

Citation:

---

Envoyé par stardeath

la première chose que je fais quand on me montre que je me suis planté sur un point technique c'est d'admettre que je me suis planté.

---

Alors déjà ici on ne parlait pas de technique mais de généralités sur le C. Et surtout tu n'as absolument rien montré à personne (enfin rien d'autre que ton infinie suffisance), tu t'es juste contenté de pinailler sur les termes et provoquer sans rien apporter de concret au débat.

Citation:

---

Envoyé par stardeath

mais t'as raison, si tu ne tires rien de ce que j'ai écrit

---

Malheureusement je crois qu'il n'y a pas que moi qui ne tire rien de ce que tu as écrit. En fait, le seul à tirer quelque chose de ce que tu as écrit c'est toi.

Citation:

---

Envoyé par stardeath

, je vais arrêter de lire/écrire sur ce sujet, j'ai autre chose à faire de mes journées :ptdr:

---

Oui oui, c'est ça, fais bien le type qui s'en va comme un prince mais qui en fait s'en va juste pitoyablement parce qu'il n'avait en réalité rien d'intéressant à dire.

Citation:

---

Envoyé par Uther

Et non on a pas toujours le choix.

---

Ok, une fois on m'a imposé C là ou Python aurait été bien plus adapté (un programme qui selon les ordres qu'on lui passait en option, modifiait des valeurs dans un fichier). Mais c'est parce que le programme devait tourner sur une caméra avec un OS mini-linux et qu'il n'y avait pas Python dessus. Mais ça ne m'est arrivé qu'une seule fois et j'espère que c'est aussi une rareté chez les autres (en plus le demandeur était super sympa, quand je lui ai dit que je voyais mieux Python pour son truc il m'a expliqué le souci mais m'a demandé quand-même si je voulais qu'il essaye de compiler Python pour me simplifier le codage...)

Citation:

---

Envoyé par Uther

c'est pour ça que les alternative récentes comme Rust ou Zig changent la donne en offrant de vraies nouveautés au développeurs bas niveau.

---

A te lire (et aussi en survolant les tutos) ça donne envie et j'aimerais bien avoir le temps de regarder Rust (quand je me suis mis à Python c'était suite à un conseil analogue reçu sur un autre forum). En plus je viens de voir qu'il intègre Qt. Mais malheureusement je n'ai pas le temps (et j'en suis le premier désolé).

Citation:

---

Envoyé par Sve@r

Mais ça ne m'est arrivé qu'une seule fois et j'espère que c'est aussi une rareté chez les autres.

---

Quand je dis qu'on n'a pas le choix ça peut être soit pour des raison humaines (choix des responsables techniques, ...) ou par des contraintes technique comme dans ton cas. Il y a peu pour faire du bas niveau un minimum performant, il n'y avait pas trop le choix, c'était soit C ou C++, éventuellement Ada (mais c'était compliqué).
Avec l'arrivée des langage bas niveau modernes on a enfin un peu plus de choix quand on vise le bas niveau.

Citation:

---

Envoyé par Sve@r

A te lire (et aussi en survolant les tutos) ça donne envie et j'aimerais bien avoir le temps de regarder Rust (quand je me suis mis à Python c'était suite à un conseil analogue reçu sur un autre forum). En plus je viens de voir qu'il intègre Qt. Mais malheureusement je n'ai pas le temps (et j'en suis le premier désolé).

---

Attention Rust n’intègre pas Qt de manière très naturelle. De manière générale les interfaces graphique sont vraiment le point sur lequel Rust ne propose pas encore de solution vraiment satisfaisante. Il y a beaucoup de projets très variés mais aucun n'est vraiment mature.

Citation:

---

Envoyé par stardeath

non mais sérieux, tu lis ce que tu as écrit au moins?

---

Ton agressivité n'a pas sa place ici, que ce soit à mon endroit ou envers les autres personnes qui participent à cette discussion. Merci.

(en fait, on pourrait juste dire que l'agressivité n'a pas sa place ici)

Citation:

---

Envoyé par stardeath

"documented manner characteristic of the environment" ça s'appelle définir le comportement ... mais au secours ...

---

Ca s'appelle effectivement définir un comportement, mais tu tronques totalement la citation et en détourne le sens. Face à un "undefined behavior", le compilateur peut plusieurs choses. Une de ces choses est de définir un comportement et de s'y tenir. Mais ça reste une possibilité, et ce n'est pas obligatoire, comme le dit la citation complète.

Je conseille à tout le monde de lire cet article "What Every C Programmer Should Know About Undefined Behavior" http://blog.llvm.org/2011/05/what-ev...ould-know.html Ca montre vraiment à quel point les UB sont dangereux et imprédictibles.