IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Affichage des résultats du sondage: Quel langage pour remplacer le C ?

Votants
50. Vous ne pouvez pas participer à ce sondage.
  • Rust

    21 42,00%
  • D

    0 0%
  • Go

    0 0%
  • C3

    0 0%
  • Autre langage (à préciser)

    2 4,00%
  • Aucun langage ne peut remplacer le C

    23 46,00%
  • Je n'ai pas d'avis

    4 8,00%
  1. #1
    Chroniqueur Actualités
    Avatar de Patrick Ruiz
    Homme Profil pro
    Redacteur web
    Inscrit en
    Février 2017
    Messages
    1 812
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Redacteur web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : Février 2017
    Messages : 1 812
    Points : 50 859
    Points
    50 859
    Par défaut 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.


    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 ?

    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 ?
    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 ?
    Ê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 ?
    Pourquoi le langage C pourrait encore avoir de longues années devant lui ?
    Le C a-t-il vraiment besoin d’un remplaçant en matière de programmation système ?
    Le problème avec le C n’est-il pas plutôt le mauvais usage que certains développeurs en font ?
    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 :

    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

    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

    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

    Facebook rejoint AWS, Huawei, Google, Microsoft et Mozilla dans la Fondation Rust, et renforce son équipe Rust par des nouveaux talents
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre confirmé Avatar de steel-finger
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Janvier 2013
    Messages
    180
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 39
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Janvier 2013
    Messages : 180
    Points : 529
    Points
    529
    Par défaut
    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.

  3. #3
    Expert éminent sénior
    Avatar de Sve@r
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Février 2006
    Messages
    12 629
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Février 2006
    Messages : 12 629
    Points : 30 859
    Points
    30 859
    Billets dans le blog
    1
    Par défaut
    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 ?
    Mon Tutoriel sur la programmation «Python»
    Mon Tutoriel sur la programmation «Shell»
    Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site
    Et on poste ses codes entre balises [code] et [/code]

  4. #4
    Expert éminent sénior
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    Juillet 2013
    Messages
    4 627
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 4 627
    Points : 10 548
    Points
    10 548
    Par défaut
    Citation Envoyé par Sve@r Voir le message
    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 Voir le message
    Moi je ne comprends même pas le concept "remplacer le C"
    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.

  5. #5
    Expert éminent sénior
    Homme Profil pro
    Analyste/ Programmeur
    Inscrit en
    Juillet 2013
    Messages
    4 627
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Analyste/ Programmeur

    Informations forums :
    Inscription : Juillet 2013
    Messages : 4 627
    Points : 10 548
    Points
    10 548
    Par défaut
    Après on peut penser qu'il y a 1 intérêt politique

    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.

  6. #6
    Invité
    Invité(e)
    Par défaut
    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.

  7. #7
    Membre habitué
    Profil pro
    Chef de projet
    Inscrit en
    Septembre 2008
    Messages
    40
    Détails du profil
    Informations personnelles :
    Localisation : France, Vosges (Lorraine)

    Informations professionnelles :
    Activité : Chef de projet

    Informations forums :
    Inscription : Septembre 2008
    Messages : 40
    Points : 181
    Points
    181
    Par défaut Tout dépend du problème
    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.

  8. #8
    Expert confirmé
    Homme Profil pro
    Développeur
    Inscrit en
    Août 2003
    Messages
    1 259
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Charente Maritime (Poitou Charente)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Août 2003
    Messages : 1 259
    Points : 4 038
    Points
    4 038
    Par défaut
    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.

  9. #9
    Membre extrêmement actif
    Avatar de Madmac
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2004
    Messages
    1 685
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Alimentation

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 685
    Points : 1 376
    Points
    1 376
    Billets dans le blog
    7
    Par défaut
    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 Voir le message
    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.

  10. #10
    Nouveau Candidat au Club
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2015
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Allemagne

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Août 2015
    Messages : 2
    Points : 0
    Points
    0
    Par défaut
    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.

  11. #11
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 552
    Points : 15 463
    Points
    15 463
    Par défaut
    Citation Envoyé par steel-finger Voir le message
    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 Voir le message
    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 Voir le message
    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 Voir le message
    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.

  12. #12
    Membre extrêmement actif
    Avatar de Madmac
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2004
    Messages
    1 685
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Alimentation

    Informations forums :
    Inscription : Juin 2004
    Messages : 1 685
    Points : 1 376
    Points
    1 376
    Billets dans le blog
    7
    Par défaut
    Citation Envoyé par Uther Voir le message

    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++.

  13. #13
    Expert confirmé

    Inscrit en
    Août 2006
    Messages
    3 941
    Détails du profil
    Informations forums :
    Inscription : Août 2006
    Messages : 3 941
    Points : 5 652
    Points
    5 652
    Par défaut
    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é ...
    Si les cons volaient, il ferait nuit à midi.

  14. #14
    Expert éminent sénior
    Avatar de Sve@r
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Février 2006
    Messages
    12 629
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Février 2006
    Messages : 12 629
    Points : 30 859
    Points
    30 859
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par droggo Voir le message
    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...)
    Mon Tutoriel sur la programmation «Python»
    Mon Tutoriel sur la programmation «Shell»
    Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site
    Et on poste ses codes entre balises [code] et [/code]

  15. #15
    Expert éminent
    Avatar de Pyramidev
    Homme Profil pro
    Développeur
    Inscrit en
    Avril 2016
    Messages
    1 460
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur

    Informations forums :
    Inscription : Avril 2016
    Messages : 1 460
    Points : 6 064
    Points
    6 064
    Par défaut
    Citation Envoyé par Sve@r Voir le message
    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 Rust : Sélectionner tout - Visualiser dans une fenêtre à part
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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

  16. #16
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 552
    Points : 15 463
    Points
    15 463
    Par défaut
    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.

  17. #17
    Expert éminent sénior
    Avatar de Sve@r
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Février 2006
    Messages
    12 629
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Oise (Picardie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Février 2006
    Messages : 12 629
    Points : 30 859
    Points
    30 859
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Pyramidev Voir le message
    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 Voir le message
    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.
    Mon Tutoriel sur la programmation «Python»
    Mon Tutoriel sur la programmation «Shell»
    Sinon il y en a pleins d'autres. N'oubliez pas non plus les différentes faq disponibles sur ce site
    Et on poste ses codes entre balises [code] et [/code]

  18. #18
    Responsable Systèmes


    Homme Profil pro
    Gestion de parcs informatique
    Inscrit en
    Août 2011
    Messages
    17 347
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Gestion de parcs informatique
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : Août 2011
    Messages : 17 347
    Points : 42 814
    Points
    42 814
    Par défaut
    Obligé de commencer toute instruction à la 8° position de la ligne car les 7 premières ne sont pas prises en compte (raison???)
    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.
    Ma page sur developpez.com : http://chrtophe.developpez.com/ (avec mes articles)
    Mon article sur le P2V, mon article sur le cloud
    Consultez nos FAQ : Windows, Linux, Virtualisation

  19. #19
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 552
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Pyrénées Orientales (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Tourneur Fraiseur

    Informations forums :
    Inscription : Avril 2002
    Messages : 4 552
    Points : 15 463
    Points
    15 463
    Par défaut
    Citation Envoyé par Sve@r Voir le message
    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.

  20. #20
    Modérateur

    Avatar de Bktero
    Homme Profil pro
    Développeur en systèmes embarqués
    Inscrit en
    Juin 2009
    Messages
    4 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Loire Atlantique (Pays de la Loire)

    Informations professionnelles :
    Activité : Développeur en systèmes embarqués

    Informations forums :
    Inscription : Juin 2009
    Messages : 4 481
    Points : 13 678
    Points
    13 678
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par Madmac Voir le message
    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 Voir le message
    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.

Discussions similaires

  1. Réponses: 12
    Dernier message: 18/03/2019, 15h51
  2. Réponses: 1
    Dernier message: 09/10/2013, 22h41
  3. Réponses: 3
    Dernier message: 13/09/2010, 21h39
  4. Réponses: 4
    Dernier message: 24/09/2009, 12h50
  5. Réponses: 8
    Dernier message: 20/09/2007, 12h57

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo