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
84. Vous ne pouvez pas participer à ce sondage.
  • D

    5 5,95%
  • Rust

    21 25,00%
  • Go

    1 1,19%
  • Autre langage (lequel ?)

    3 3,57%
  • Aucun langage ne peut remplacer le C

    50 59,52%
  • Pas d'avis

    4 4,76%
Langages de programmation Discussion :

Quel langage pourrait remplacer C ?


Sujet :

Langages de programmation

  1. #1
    Chroniqueur Actualités

    Homme Profil pro
    Webmaster
    Inscrit en
    Janvier 2014
    Messages
    1 089
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Webmaster
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2014
    Messages : 1 089
    Points : 26 554
    Points
    26 554
    Par défaut Quel langage pourrait remplacer C ?
    Quel langage pourrait remplacer C ?
    Après avoir comparé Go, Rust et D, le choix d'Andrei Alexandrescu se porte sur D

    Le langage C est un des langages de programmation les plus utilisés au monde. Et pour cause, il dispose de nombreux atouts tels que la vitesse d’exécution du code, la possibilité d’écrire une application qui pourra être exécutée sans avoir forcément besoin de bibliothèque ou machine virtuelle, l’existence d’un grand nombre de compilateurs et bibliothèques, une compatibilité avec plusieurs architectures…

    Ayant été inventé dans les années 70, ce langage jouit encore aujourd’hui d’une forte communauté. Toutefois, en raison de certains inconvénients qu’on lui connait, plusieurs solutions ont été proposées en vue de remplacer ce langage.

    Nous avons par exemple C++ qui est apparu en 1983, la même année de la création d’un comité de normalisation du langage C. L’objectif était d’améliorer ce dernier en introduisant certains concepts comme les classes, les classes dérivées, les typages forts, etc.

    La soif d’améliorer le langage C n’ayant pas pu être étanchée avec C++, certaines personnes se sont lancées dans une entreprise visant à fournir de nouveaux outils pour remplacer ces deux langages. Dans ce sens, on peut citer le langage D apparu en 1999 qui s’appuie sur C++, Java et Eiffel. Google a suivi le pas depuis ces dernières années en proposant Go qui s’inspire de C et Pascal et enfin Rust qui a été dévoilé par la fondation Mozilla en 2010.

    Pour soutenir son choix, Andrei Alexandrescu (un des co créateur du langage D) s’est proposé de présenter D, Go et Rust dans un tableau comparatif.


    Inconvénients de Go

    Problème de performance : parmi les caractéristiques principales de Go, l’on a les appels indirects de fonction et l’implémentation d’un ramasse-miettes. Toutefois, selon Andrei, ce sont des éléments qui constituent des régressions dans la mesure où ils font décroitre les performances du code exécuté.

    Absence de programmation générique
    : le fait que la programmation générique n’est pas encore possible avec Go constitue, du point de vue d’Andrei, un gros handicap. Les développeurs ont réclamé cette fonctionnalité, mais ces derniers doivent attendre jusque-là. Selon Andrei, ce choix est fait sciemment et est plus de l’ordre politique qu’autre chose.

    La simplicité qui devient un handicap : Go se veut par essence relativement simple. Rob Pike, l’un des trois créateurs de Go, affirmait au sujet des jeunes développeurs « qu’ils ne sont pas capables de comprendre un langage brillant, mais nous voulons les amener à réaliser de bons programmes. Ainsi, le langage que nous leur donnons doit être facile à comprendre et facile à adopter ». Toutefois, Andrei explique qu’à cause de cette volonté de faciliter les choses, les développeurs se retrouvent à écrire et réécrire les mêmes choses, car Go n’offrirait pas beaucoup d’abstraction de code. Eu égard à ce fait, Andrei souligne qu’un développeur qui a utilisé Go dans un projet ne souhaiterait plus retourner vers ce langage.


    Avantages de Go

    Langage alternatif pour la programmation système : Go a été conçu afin d’offrir un langage de programmation simple pour le développement des applications système. Ce domaine a été longtemps dominé par Java. L’équipe de Go qui souhaitait également faire une percée dans ce domaine a usé de stratégies afin de pénétrer le marché des services de réseau.

    Bonne équipe en amont : pour assurer un code de qualité à Go, Google a fait appel à une équipe solide. Cela constitue un point important, souligne Andrei, qui estime que les ingénieurs derrière ce langage ont su compenser le manque de performance du langage par la qualité de Go et précisément avec la bibliothèque et les outils réseau dont dispose Go.

    Bonne image de marque : le fait que Go a été développé par Google représente selon Andrei un élément essentiel pour attirer les développeurs vers cette plateforme, même s’il n’est pas foncièrement extraordinaire. La seule image de Google est suffisante pour inciter les développeurs à adopter le langage.


    Inconvénients de Rust

    Répartition disproportionnée des efforts : selon Andrei, l’équipe de Rust alloue beaucoup d’efforts à la gestion de la mémoire, mais néglige les autres aspects du langage.

    Syntaxe atypique : pour Andrei, la syntaxe de Rust est peu commune aux autres langages de développement. Cela pourrait être frustrant ou même constituer un frein au cas où certaines personnes n’auraient pas de motivation pour s’investir dans un tel apprentissage.


    Avantages de Rust

    Nouvelles théories
    : des trois langages évoqués, admet Andrei, Rust est le seul langage disposant de théoriciens en langage de classe mondiale. Cela dénote de la précision et de la profondeur de l’approche technique de Rust.

    Un langage beaucoup plus sécurisé : l’objectif de Mozilla en implémentant ce langage est d’offrir un langage sécurisé, concurrent, et disposant de fonctionnalités essentielles pour réaliser ce que l’on souhaite. Pour Andrei, l’aspect sécurité est un avantage à ne pas omettre dans les atouts de ce langage.

    Bonne préversion : pour pouvoir atteindre la première version stable, l’équipe de Rust a mis environ cinq années en enchainant préversion sur préversion. Selon Andrei, cela constitue un avantage, car le produit fini est meilleur et comporte moins de bogues. L’effet collatéral est que la communication autour des différentes itérations a été assez forte.


    Inconvénients de D

    Mauvaise perception : à l’origine, D avait été conçu pour être le successeur de C. Mais depuis sa création en 1999, il bénéficie d’une adoption limitée. Cela est dû au fait que les gens perçoivent D comme un langage assez jeune. Cette perception complique davantage les choses dans le milieu professionnel, car les ingénieurs et décideurs sont réticents à adopter un langage qui ne parvient pas à décoller depuis toutes ces années.

    Rejet du ramasse-miettes : D dispose d’un récupérateur de mémoire qui ne jouit pas d’une bonne réputation. L’introduction du ramasse-miettes dans ce langage a été rejetée en grande partie par la communauté des développeurs C et C++. Et même s’il est vrai que l’on pourrait utiliser D avec RAII pour libérer la mémoire des objets non utilisés ou encore utiliser un style de gestion manuel, pour Andrei, cela reviendrait à créer tout le noyau de l’infrastructure et donc à utiliser ce langage de manière bancale.

    Manque du soutien de grandes firmes : il est notoire que plusieurs langages de développement ont été fortement adoptés du fait du soutien de grandes entreprises. Malheureusement, D ne bénéficie pas de ce coup de pouce. Son développement est donc laissé entre les mains de sa communauté fortement peuplée d’ingénieurs qui font plus preuve de perspicacité que de leadership, charisme ou vision à long terme.


    Avantages de D

    Vitesse de compilation du code : la compilation du code D est beaucoup plus rapide que celle du C++ pour des performances équivalentes en ce qui concerne les performances du code exécuté. Go se compile beaucoup plus rapidement, mais produit à l’exécution un code plus lent.

    Également langage de script rapide : D peut être également utilisé pour écrire rapidement des scripts. Et qui plus est, les scripts exécutés bénéficient de performances énormes indépendamment du nombre de scripts écrits (qu’ils soient en petit nombre ou en grand nombre). Par ailleurs, D dispose d’un nombre important de bibliothèques.

    Interfaçage facile avec les bibliothèques C : D utilise la même structure de mémoire que C et C++, ce qui fait que la bibliothèque entière de C est facilement accessible à D. Andrei ajoute que des travaux sont en cours pour faire la même chose avec C++.


    Langage de prédilection pour remplacer C et C++

    Pour Andrei, les caractéristiques d’introspection statique, le temps de compilation assez rapide ainsi que les nombreux atouts uniques au langage D font de celui-ci le remplaçant idéal à C. Partant de ce fait, il trouve que Go est dépassé et n’a même pas saisi le problème, tandis Rust s’essaye à donner quelques éléments de solutions. Et pour aller encore plus loin, Andrei estime que comparativement à D même C++ « s’est égaré dans les bois ».

    Source : Quora

    Et vous ?

    Que pensez-vous des conclusions d’Andrei ? Pensez-vous que D est le successeur idéal face à C ?

    Quel est votre choix personnel pour remplacer C ?

    Voir aussi

    Forum C
    Contribuez au club : Corrections, suggestions, critiques, ... : Contactez le service news et Rédigez des actualités

  2. #2
    Membre expérimenté Avatar de SkyZoThreaD
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Juillet 2013
    Messages
    583
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : Technicien maintenance
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : Juillet 2013
    Messages : 583
    Points : 1 615
    Points
    1 615
    Par défaut
    Citation Envoyé par Olivier Famien Voir le message
    Toutefois, en raison de certains inconvénients que l’on lui connait, plusieurs alternatives ont été proposées en vue de remplacer ce langage.
    Un petit rappel des inconvénients svp? A part les overflows (inévitables en quasi-lowlevel), et en ne considérant que les domaines dans lesquels il est utilisé, c'est un très bon langage à mes yeux...

    ps : le gros inconvégniant de Rust c'est qu'il est un peu rouillé
    La liberté est à la sociologie ce que l'instant présent est à la physique relativiste.

  3. #3
    Membre émérite
    Avatar de imperio
    Homme Profil pro
    Étudiant
    Inscrit en
    Mai 2010
    Messages
    852
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2010
    Messages : 852
    Points : 2 298
    Points
    2 298
    Par défaut
    Citation Envoyé par Olivier Famien Voir le message
    Quel langage pourrait remplacer C ?
    Inconvénients de Rust

    Répartition disproportionnée des efforts : selon Andrei, l’équipe de Rust alloue beaucoup d’efforts à la gestion de la mémoire, mais néglige les autres aspects du langage.

    Syntaxe atypique : pour Andrei, la syntaxe de Rust est peu commune aux autres langages de développement. Cela pourrait être frustrant ou même constituer un frein au cas où certaines personnes n’auraient pas de motivation pour s’investir dans un tel apprentissage.
    Pour le développement de Rust, il y a plusieurs équipes qui se concentrent chacune sur un aspect du langage. Je n'ai plus entendu parler "d'efforts de la gestion de la mémoire" depuis un moment. Après je me trompe peut-être...

    La syntaxe du Rust est très proche des langages actuels donc à ce niveau-là, pas de souci. C'est plutôt avec le borrow checker que les développeurs passeront le plus de temps.

  4. #4
    Membre éclairé
    Inscrit en
    Juillet 2012
    Messages
    231
    Détails du profil
    Informations forums :
    Inscription : Juillet 2012
    Messages : 231
    Points : 870
    Points
    870
    Par défaut
    Citation Envoyé par Andrei Alexandrescu
    Rust puts safe, precise memory management front and center of everything. Unfortunately, that's seldom the problem domain, which means a large fraction of the thinking and coding are dedicated to essentially a clerical job (which GC languages actually automate out of sight).
    Je n’ai pas l’impression que ça ne soit centré tant que ça sur la gestion de la mémoire. L’un des concept central en Rust c’est le concept d’ownership et ça s’applique aux ressources de manières générale (la mémoire bien sûr, mais aussi mutex, fichiers, socket, …).
    C’est aussi de ce concept que découle la promesse de Rust de permettre de faire de la programmation concurrence garantie (à la compilation) sans data race.

    Parmi les trois langages discutés ici, pour moi Rust est la meilleure alternative au C. Après, je ne pense pas que quoique ce soit remplace le C à court terme…

    Go est une blague à ce niveau-là, il ne joue pas dans la même cour que le C (d’ailleurs Go attire plus les gens qui viennent de Python et Ruby que les gens qui viennent de C et C++).
    Pour D, je ne connais pas trop si ce n’est qu’il y a eu une sorte de split de la communauté et qu’il y a eu deux bibliothèques standard (Phobos et Tango)… Mais maintenant que Andrei à quitté Facebook pour se consacrer au D les choses vont peut-être s’améliorer pour le langage.

  5. #5
    Expert confirmé Avatar de DonQuiche
    Inscrit en
    Septembre 2010
    Messages
    2 741
    Détails du profil
    Informations forums :
    Inscription : Septembre 2010
    Messages : 2 741
    Points : 5 485
    Points
    5 485
    Par défaut
    Citation Envoyé par grim7reaper Voir le message
    Je n’ai pas l’impression que ça ne soit centré tant que ça sur la gestion de la mémoire. L’un des concept central en Rust c’est le concept d’ownership et ça s’applique aux ressources de manières générale (la mémoire bien sûr, mais aussi mutex, fichiers, socket, …).
    Oui mais 99% du temps c'est bien de mémoire dont on parle puisque tu manipules celle-ci en permanence. C'est d'ailleurs cette omniprésence du vérificateur d'emprunts (borrow checker) qui rend Rust parfois pénible à utiliser.

    Parmi les trois langages discutés ici, pour moi Rust est la meilleure alternative au C. Après, je ne pense pas que quoique ce soit remplace le C à court terme…
    La base de code installée étant immense, C/C++ seront là pour longtemps. Mais pour les nouveaux projets je pense que Rust va rapidement s'imposer comme leur remplaçant. D'autant que là où les concepteurs de matériel commençaient auparavant par écrire un compilo C, de plus en plus souvent ils écrivent plutôt un backend LLVM.

    Go est une blague à ce niveau-là, il ne joue pas dans la même cour que le C (d’ailleurs Go attire plus les gens qui viennent de Python et Ruby que les gens qui viennent de C et C++).
    Pour D, je ne connais pas trop si ce n’est qu’il y a eu une sorte de split de la communauté et qu’il y a eu deux bibliothèques standard (Phobos et Tango)… Mais maintenant que Andrei à quitté Facebook pour se consacrer au D les choses vont peut-être s’améliorer pour le langage.
    Go ne joue effectivement pas du tout dans la même cour, c'est à se demander si ses dévs savaient où ils allaient quand ils l'ont présenté comme tel. En revanche Go pourrait devenir *le* langage pour les centres de données grâce au nom de Google.

    Quant au D, pour moi il appartient à la même génération que Java et C# et s'est fait bouffer par ces deux-là.

  6. #6
    Membre éclairé
    Inscrit en
    Juillet 2012
    Messages
    231
    Détails du profil
    Informations forums :
    Inscription : Juillet 2012
    Messages : 231
    Points : 870
    Points
    870
    Par défaut
    Citation Envoyé par DonQuiche
    C'est d'ailleurs cette omniprésence du vérificateur d'emprunts (borrow checker) qui rend Rust parfois pénible à utiliser.
    Je préfère un truc pénible à la compilation qu’a l’exécution


    Citation Envoyé par DonQuiche
    Mais pour les nouveaux projets je pense que Rust va rapidement s'imposer comme leur remplaçant.
    J’en suis pas si sûr, mais j’espère me tromper.

    Citation Envoyé par DonQuiche
    D'autant que là où les concepteurs de matériel commençaient auparavant par écrire un compilo C, de plus en plus souvent ils écrivent plutôt un backend LLVM.
    Tu as une (des?) source à ce sujet*?

  7. #7
    Membre expert
    Avatar de Metalman
    Homme Profil pro
    Enseignant-Chercheur
    Inscrit en
    Juin 2005
    Messages
    1 049
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Enseignant-Chercheur
    Secteur : Enseignement

    Informations forums :
    Inscription : Juin 2005
    Messages : 1 049
    Points : 3 532
    Points
    3 532
    Par défaut
    Même question que SkyZoThread : quels sont les inconvénients de C ?...
    Parce que "l'assembleur portable" me semble toujours être super : pas de fioritures, juste des instructions sous une forme compréhensibles.
    --
    Metalman !

    Attendez 5 mins après mes posts... les EDIT vont vite avec moi...
    Les flags de la vie : gcc -W -Wall -Werror -ansi -pedantic mes_sources.c
    gcc -Wall -Wextra -Werror -std=c99 -pedantic mes_sources.c
    (ANSI retire quelques fonctions comme strdup...)
    L'outil de la vie : valgrind --show-reachable=yes --leak-check=full ./mon_programme
    Et s'assurer que la logique est bonne "aussi" !

    Ma page Developpez.net

  8. #8
    Membre éprouvé
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Janvier 2007
    Messages
    697
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 36
    Localisation : France, Calvados (Basse Normandie)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Janvier 2007
    Messages : 697
    Points : 1 241
    Points
    1 241
    Par défaut
    Je pense qu'il serait pas mal de mentionner que Andrei Alexandrescu n'est autre que le créateur du langage D. D'une certaine façon son avis est forcément biaisé.

    Edit : @Niark13 : effectivement, désolé de l’imprécision. +1 à tout ce que tu as dit.

  9. #9
    Membre confirmé

    Inscrit en
    Décembre 2009
    Messages
    164
    Détails du profil
    Informations forums :
    Inscription : Décembre 2009
    Messages : 164
    Points : 490
    Points
    490
    Par défaut
    Comme l'avait dit Bjarne Stroustrup dans cppcon2015, pour qu'un nouveau language prenne, il faut attendre au minimum 10 ans.
    Aujourd'hui, pour moi les remplaçants du C/C++ c'est C++11/14/17.
    Il y est possible de coder autrement tout en restant backward compatible avec le legacy code.
    Pour des projects personnles/open source, utiliser un langage moderne est faisable. Mais dans l'industrie, avec un historique de code et de produits, sans librairie standard/ librarires riches, sans communauté ou consulting, ceci est tout bonnement pas possible.

    Bref, l'avenir du C/C++, c'est le C/C++.

    MG

  10. #10
    Membre éclairé

    Profil pro
    Inscrit en
    Mai 2005
    Messages
    264
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2005
    Messages : 264
    Points : 725
    Points
    725
    Par défaut
    Citation Envoyé par atha2 Voir le message
    Je pense qu'il serait pas mal de mentionner que Andrei Alexandrescu n'est autre que le créateur du langage D. D'une certaine façon sont avis est forcément biaisé.
    Il n'est pas créateur (c'est Walter Bright), mais il est effectivement à l'origine du reboot du langage en 2010 (D 2.0). Officiellement il est « Architect ».

    Pour moi, D n'est pas le remplaçant de C, car il est un peu trop gros pour tourner sur des microcontrôleurs par exemple. C'est plutôt un C++ sous stéroïdes qu'un remplaçant de C.
    "By and large I'm trying to minimize mentions of D in C++ contexts because it's as unfair as bringing a machine gun to a knife fight." - Andrei Alexandrescu

  11. #11
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 559
    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 559
    Points : 15 484
    Points
    15 484
    Par défaut
    Il serait quand même important de noter dans l'article la place centrale de Andrei Alexandrescu dans le développement de D, ce qui permet de comprendre que son avis est forcément orienté. Il ne s'en cache d'ailleurs pas dans le message original.

    Citation Envoyé par SkyZoThreaD Voir le message
    Un petit rappel des inconvénients svp? A part les overflows (inévitables en quasi-lowlevel), et en ne considérant que les domaines dans lesquels il est utilisé, c'est un très bon langage à mes yeux...
    La liste est longue, mais globalement il lui manque la gestion native des fonctionnalités que l'on trouve généralement dans les langages de plus haut niveau (polymorphisme, génériques, ...) et il n'y a pas la moindre notion de sécurité :
    - La mémoire est manipulée sans le moindre contrôle (overflow, double free, ...)
    - Il y a aussi dans la syntaxe des choix naturel a l'époque qui se sont avérés plus a risque d'erreur (mutabilité par défaut, switch non exhaustifs, pré/post-incrémentation,...)
    - Le typage est certes statique mais permet de convertit trop facilement tout en n'importe.

    Citation Envoyé par imperio Voir le message
    Pour le développement de Rust, il y a plusieurs équipes qui se concentrent chacune sur un aspect du langage. Je n'ai plus entendu parler "d'efforts de la gestion de la mémoire" depuis un moment. Après je me trompe peut-être...

    La syntaxe du Rust est très proche des langages actuels donc à ce niveau-là, pas de souci. C'est plutôt avec le borrow checker que les développeurs passeront le plus de temps.
    C'est une contrainte générale du langage, de toute façon on ne peut plus vraiment changer la façon dont ça fonctionne actuellement, même si il devrait être légèrement allégé grace au travail sur le compilateur(une nouvelle représentation intermédiaire).

    Citation Envoyé par atha2 Voir le message
    Je pense qu'il serait pas mal de mentionner que Andrei Alexandrescu n'est autre que le créateur du langage D. D'une certaine façon sont avis est forcément biaisé.
    Ce n'est pas le principal créateur du langage, mais en effet c'est actuellement le membre central du projet.

  12. #12
    En attente de confirmation mail
    Femme Profil pro
    pape n'aimant pas les censeurs
    Inscrit en
    Janvier 2010
    Messages
    803
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Vatican

    Informations professionnelles :
    Activité : pape n'aimant pas les censeurs

    Informations forums :
    Inscription : Janvier 2010
    Messages : 803
    Points : 1 407
    Points
    1 407
    Par défaut
    Chers membres de la communauté des développeurs.

    Vous avez tous des arguments pour démontrer à quel point il serait judicieux de promouvoir tel ou tel langage pour remplacer le C... Et tout autant d'arguments pour prévoir un futur radieux pour ce bon vieux C!


    A mon sens, vous oubliez un élément essentiel: Ce n'est malheureusement pas que la qualité d'un langage ou l'avis des développeurs qui fait loi mais bien l'argent!!!


    La "réussite" d'un nouveau langage dépend énormément de la puissance financière qui est engagée pour le promouvoir... Si un Google ou un Microsoft décide que le prochain langage à la mode sera le "Zozo", nul doute que ce langage sera rapidement adopté par de nombreuses grandes entreprises, que du jour au lendemain des postes de développeurs "Zozo" seront à pourvoir et qu'une grosse communauté de développeurs spécialisés dans le Zozo apparaitra

    Dura lex, sed lex!

  13. #13
    Membre éclairé
    Inscrit en
    Juillet 2012
    Messages
    231
    Détails du profil
    Informations forums :
    Inscription : Juillet 2012
    Messages : 231
    Points : 870
    Points
    870
    Par défaut
    Citation Envoyé par Metalman Voir le message
    Même question que SkyZoThread : quels sont les inconvénients de C ?...
    Parce que "l'assembleur portable" me semble toujours être super : pas de fioritures, juste des instructions sous une forme compréhensibles.
    Typage relativement faible ?
    Undefined/Unspecified/Implementation-defined behavior à tous les étages ?
    Langage peu défini sur certains points (on ne te garanti pas IEEE 754, on ne te garanti pas le complément à deux, …).
    Assembleur portable je veux bien, mais dans la réalité faire du code vraiment portable au sens de la norme (et pas aux sens de « ce que j’ai observé dans ma vie c’est tel comportement sur tel archi ») c’est loin d’être simple (d’où la célèbre référence à la DS9K que l’on rencontre parfois sur comp.lang.c).
    D’autant plus que le C n’est pas si bien équipé que ça pour du code bas-niveau (impossible de packer une structure de manière portable (ce qui se fait très bien en Ada, et en Rust aussi il me semble) par exemple) donc bon, le coup de l’assembleur portable…

    Citation Envoyé par NSKis
    Si un Google ou un Microsoft décide que le prochain langage à la mode sera le "Zozo", nul doute que ce langage sera rapidement adopté par de nombreuses grandes entreprises, que du jour au lendemain des postes de développeurs "Zozo" seront à pourvoir et qu'une grosse communauté de développeurs spécialisés dans le Zozo apparaitra

    Dura lex, sed lex!
    Bah nope, suffit de regarder Go : y’a Google derrière et pourtant je n’ai pas vu « de nombreuses grandes entreprises » se mettre à l’utiliser.
    Idem pour certains langages de Microsoft qui ont fait des flops.

  14. #14
    Inactif  

    Homme Profil pro
    NR
    Inscrit en
    Juin 2013
    Messages
    3 715
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : NR
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Juin 2013
    Messages : 3 715
    Points : 1 184
    Points
    1 184
    Billets dans le blog
    9
    Par défaut
    Pourquoi remplacer le C ?

    J'ai jamais trop compris l'intérêt de vouloir "remplacer". Le C à des avantages et des inconvénient, ces forces et ces limites font qu'il répond a un besoin: la performance.


    En générale, moi je code les partis critique d'un programme en C et le reste en Python.

  15. #15
    Membre expert
    Avatar de Metalman
    Homme Profil pro
    Enseignant-Chercheur
    Inscrit en
    Juin 2005
    Messages
    1 049
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Enseignant-Chercheur
    Secteur : Enseignement

    Informations forums :
    Inscription : Juin 2005
    Messages : 1 049
    Points : 3 532
    Points
    3 532
    Par défaut
    Merci grim7reaper des exemples !
    Les arguments me paraissent soutenables, en effet.
    Excepté le typage : je suis très compréhensif sur l'ultra-manipulabilité des types, étant donné un de ses buts de bas niveau (à méditer cependant)

    Ceux de Uther me paraissent moins solides, car on sait déjà que l'on va rencontrer ces "difficultés" vu que le langage est prévu pour faire du bas niveau depuis toujours (après, il faut ajouter ce que grim7repear a dit sur le low level...).

    (sinon je suis comme sazearte : pourquoi vouloir absolument remplacer ?...)
    --
    Metalman !

    Attendez 5 mins après mes posts... les EDIT vont vite avec moi...
    Les flags de la vie : gcc -W -Wall -Werror -ansi -pedantic mes_sources.c
    gcc -Wall -Wextra -Werror -std=c99 -pedantic mes_sources.c
    (ANSI retire quelques fonctions comme strdup...)
    L'outil de la vie : valgrind --show-reachable=yes --leak-check=full ./mon_programme
    Et s'assurer que la logique est bonne "aussi" !

    Ma page Developpez.net

  16. #16
    Membre éclairé
    Inscrit en
    Juillet 2012
    Messages
    231
    Détails du profil
    Informations forums :
    Inscription : Juillet 2012
    Messages : 231
    Points : 870
    Points
    870
    Par défaut
    Citation Envoyé par sazearte
    J'ai jamais trop compris l'intérêt de vouloir "remplacer".
    Citation Envoyé par Metalman
    (sinon je suis comme sazearte : pourquoi vouloir absolument remplacer ?...)
    Il y a remplacer et remplacer.
    Remplacer totalement je n’y crois pas : on ne jette pas une base de code si énorme d’un claquement de doigts (COBOL en est la preuve vivante…). Et puis le temps qu’il faudrait investir dans ce genre d’entreprise est colossal, pour un gain discutable (ce temps pourrait être mieux utilisé à mon avis).

    Par contre, la question du remplacement du C dans certains de ses usages actuels se pose et est pertinente je pense.

    Exemple : OpenSSL. C’est quoi l’avantage du C dans ce genre de code (sur les bouts de code sensible aux timing attack, je dis pas mais ça ne concerne pas tout le code…) ? On a vu les résultats avec Heartbleed & cie…
    Et histoire de bien répéter l’histoire, on fait une nouvelle implémentation (LibreSSL) en C encore…
    Je préfère l’approche des gens qui sont en train de faire une implémentation de TLS en (quasi)pure OCaml.

    Citation Envoyé par sazearte
    Le C à des avantages et des inconvénient, ces forces et ces limites font qu'il répond a un besoin: la performance.
    Je trouve qu’on sacrifie beaucoup de choses sur l’autel de la performance…
    En a-t-on besoin à ce point que l’on sacrifie sécurité, vérification statique, notre temps à débugger, … pour avoir cette performance ?
    Encore aujourd’hui alors que nous avons (ou commençons à voir) des alternatives qui peuvent nous offrir le même niveau performance (ou quasiment, selon le langage, et ce sont des choses qui progressent au fil du temps) sans avoir à sacrifier autant ?

    Et la performance c’est bien beau, mais les ordinateurs ont changés depuis la création du C, et le C ne suis pas toujours ces évolutions qui pourtant permettent d’exploiter au mieux les machines actuelles (et donc d’avoir cette performance si recherchée) :
    - parallélisme (CPU multi-core, hyperthreading, …), concurrence : il a fallu attendre C11 pour avoir la notion de thread dans le langage (Ada le faisait déjà en 1983…)
    - SIMD : rien en C. Normal me direz-vous, car ce n’est pas portable et je suis d’accord. C’est donc le boulot du compilateur de faire la vectorisation : le problème c’est que le langage est tellement « souple » que le compilateur galère (car il doit être très conservateur), problème que l’on ne rencontre pas dans d’autres langages car ils laissent le compilateurs avoir plus d’informations (Haskell par exemple).
    - GPGPU : un peu la même chose que le vectoriel, dans l’idéal ça serait le boulot du compilateur. En C il faut réécrire le code pour en tirer partie, en Haskell pas besoin (je cite pas mal Haskell car c’est un langage que je connais, mais il y en a sûrement d’autres).

    Donc bon, la performance et le C c’est pas si rose.

    Ça n‘empêche que j’aime bien le C quand même (j’en fait très souvent) et que je ne serais pas contre son remplacement dans pas mal de cas. Mais de là à vouloir le remplacer totalement…

    Édit :
    Citation Envoyé par Metalman
    Excepté le typage : je suis très compréhensif sur l'ultra-manipulabilité des types, étant donné un de ses buts de bas niveau (à méditer cependant)
    Même pour ce genre de chose le C joue parfois contre toi.
    Exemple avec le type punning qui peut te mettre dans un UB (ce qui entraîne des bugs du genre cité dans cet article (C++, mais pour le coup ça s’applique aussi bien au C)) grâce aux règles de strict aliasing (cf. ici pour un tour d’horizon).
    Pour un langage qui se veut bas-niveau, ça devrait être trivial. Mais ça ne l’est pas tant que ça.

  17. #17
    Inactif  

    Homme Profil pro
    NR
    Inscrit en
    Juin 2013
    Messages
    3 715
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Suisse

    Informations professionnelles :
    Activité : NR
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Juin 2013
    Messages : 3 715
    Points : 1 184
    Points
    1 184
    Billets dans le blog
    9
    Par défaut
    Je trouve qu’on sacrifie beaucoup de choses sur l’autel de la performance…
    En a-t-on besoin à ce point que l’on sacrifie sécurité, vérification statique, notre temps à débugger, … pour avoir cette performance ?
    Encore aujourd’hui alors que nous avons (ou commençons à voir) des alternatives qui peuvent nous offrir le même niveau performance (ou quasiment, selon le langage, et ce sont des choses qui progressent au fil du temps) sans avoir à sacrifier autant ?

    Et la performance c’est bien beau, mais les ordinateurs ont changés depuis la création du C, et le C ne suis pas toujours ces évolutions qui pourtant permettent d’exploiter au mieux les machines actuelles (et donc d’avoir cette performance si recherchée) :
    - parallélisme (CPU multi-core, hyperthreading, …), concurrence : il a fallu attendre C11 pour avoir la notion de thread dans le langage (Ada le faisait déjà en 1983…)

    Heureusement que j'ai dit :
    En générale, moi je code les partis critique d'un programme en C et le reste en Python.
    Pour nuancer mon propos...

    Je voulais dire par la que j'ai trouvé un compromis entre simplicité de développement et performance dans certaines partie de mon code.

  18. #18
    Membre éclairé
    Inscrit en
    Juillet 2012
    Messages
    231
    Détails du profil
    Informations forums :
    Inscription : Juillet 2012
    Messages : 231
    Points : 870
    Points
    870
    Par défaut
    @sazearte  : j’ai bien lu ton propos.
    Ce que je voulais montrer c’est que le raisonnement « j’ai besoin de perf’, vite du C » n’est pas forcément le meilleur parce qu’il y a des alternatives qui existe.
    Pour rebondir sur Python, selon ton code tu peux parfois te rabattre sur cython (100% compatible Python il me semble), pypy (certaines bibliothèques sont pas disponibles).

  19. #19
    Membre confirmé
    Profil pro
    Inscrit en
    Septembre 2009
    Messages
    204
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Septembre 2009
    Messages : 204
    Points : 540
    Points
    540
    Par défaut
    Citation Envoyé par sazearte Voir le message
    Pourquoi remplacer le C ?

    J'ai jamais trop compris l'intérêt de vouloir "remplacer". Le C à des avantages et des inconvénient, ces forces et ces limites font qu'il répond a un besoin: la performance.


    En générale, moi je code les partis critique d'un programme en C et le reste en Python.
    Justement tu pourrai très bien le faire en Rust, voire en D. Go me parait compliqué à intégrer car son garbage collector n'étant pas désactivable il risque d'entrer en conflit avec celui de python. Concernant les performances, il me semble avoir lu des articles dans lesquels les devs de du core Rust pensent que d'ici peu il sera plus rapide que le C car le langage étant plus restrictif il permettra au compilateur de faire des optimisations plus agressives.

    A titre personnel si je veux faire du bas niveau je préfère faire du Rust que du C. Néanmoins le C étant le seul langage dont tous les autres (ou presque) peuvent s'interfacer avec, il n'est pas près de disparaitre. Ce n'est pas le cas du C++ qui lui risque de souffrir des langages mentionnés dans l'article.

  20. #20
    Expert éminent sénior Avatar de Uther
    Homme Profil pro
    Tourneur Fraiseur
    Inscrit en
    Avril 2002
    Messages
    4 559
    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 559
    Points : 15 484
    Points
    15 484
    Par défaut
    Citation Envoyé par NSKis Voir le message
    Vous avez tous des arguments pour démontrer à quel point il serait judicieux de promouvoir tel ou tel langage pour remplacer le C... Et tout autant d'arguments pour prévoir un futur radieux pour ce bon vieux C!
    A mon sens, vous oubliez un élément essentiel: Ce n'est malheureusement pas que la qualité d'un langage ou l'avis des développeurs qui fait loi mais bien l'argent!!!

    La "réussite" d'un nouveau langage dépend énormément de la puissance financière qui est engagée pour le promouvoir... Si un Google ou un Microsoft décide que le prochain langage à la mode sera le "Zozo", nul doute que ce langage sera rapidement adopté par de nombreuses grandes entreprises, que du jour au lendemain des postes de développeurs "Zozo" seront à pourvoir et qu'une grosse communauté de développeurs spécialisés dans le Zozo apparaitra
    Je suis a moitié d'accord. Par exemple pour Swift, oui c'est un succès garanti, non pas a cause des mérites du langage (bien qu'il en a assurément), mais uniquement car c'est LE langage d'avenir promu par Apple pour les iBidules.
    De même le Javascript c'est imposé non pas grâce à ces mérites (bien qu'il ... heu, en fait non), mais parce que c'était le seul langage géré en natif coté client web.

    Mais dans le cadre de programmation système, on peut utiliser tout ce que l'on veut tant que ça finit en code machine, imposer sa technologie n'est pas aussi systématique. La qualité du langage et du compilateur joue énormément, le poids de l'existant aussi.

    Citation Envoyé par grim7reaper Voir le message
    Bah nope, suffit de regarder Go : y’a Google derrière et pourtant je n’ai pas vu « de nombreuses grandes entreprises » se mettre à l’utiliser.
    Idem pour certains langages de Microsoft qui ont fait des flops.
    Go a été quand même relativement bien adopté pour un langage si jeune, maintenant il est plutôt employé dans le domaine des serveurs, pas celui de la programmation système.
    Dont il est de fait plus en concurrence avec Python, Java, C#, ... que des langage comme C++, D ou Rust

    Citation Envoyé par sazearte Voir le message
    Pourquoi remplacer le C ?

    J'ai jamais trop compris l'intérêt de vouloir "remplacer". Le C à des avantages et des inconvénient, ces forces et ces limites font qu'il répond a un besoin: la performance.
    Remplacer l'intégralité du code C existant, ce n'est évidemment pas prêt d'arriver : la base est trop énorme. La question se pose pour les projet à venir.
    Envisager d'utiliser, à la place du vénérable C, un langage plus récent, comme C++, Rust ou D, qui offrirait des mécaniques plus avancées et/ou plus propres sans pour autant transiger sur les performances, ce n'est pas forcément dénué de sens.

    Citation Envoyé par Metalman Voir le message
    Merci grim7reaper des exemples !
    Ceux de Uther me paraissent moins solides, car on sait déjà que l'on va rencontrer ces "difficultés" vu que le langage est prévu pour faire du bas niveau depuis toujours (après, il faut ajouter ce que grim7repear a dit sur le low level...).
    (sinon je suis comme sazearte : pourquoi vouloir absolument remplacer ?...)
    On a beau savoir le type des difficultés auxquelles on s'expose, ça ne suffit pas a les résoudre toutes pas pour autant. J'ai beau être au courant des risques du C, si on dépasse une certaine taille de code, je suis sur que je vais commettre des erreurs qui ne me seraient pas arrivées avec un langage plus strict. Et je ne pense pas que ce soit uniquement du à mon incompétence vu qu'on trouve très régulièrement des problèmes de sécurité mémoire dans les applications les plus surveillées au monde (OS, navigateurs, ...).

    Un langage comme Rust permet d'avoir la garantie que l'on n'aura pas de problème de sécurité mémoire ou de "data race". Ça ne suffit bien évidement pas a faire un programme garanti correct, mais c'est une aide dont il serait idiot de se passer.
    De plus, si l'on peut avoir accès à des fonctionnalités de plus haut niveau sans que ça coûte en performances, je ne vois pas pourquoi s'en priver sous prétexte que l'on fait du bas niveau.

Discussions similaires

  1. Créer un site web - en quel langage ?
    Par Thierry92 dans le forum Débuter
    Réponses: 90
    Dernier message: 13/04/2015, 14h42
  2. quel langage choisir pour faire de script sous windows
    Par pas05 dans le forum Langages de programmation
    Réponses: 7
    Dernier message: 18/11/2002, 22h42
  3. Comparer des fichiers de données : Quel Langage ?
    Par Anonymous dans le forum Langages de programmation
    Réponses: 6
    Dernier message: 24/04/2002, 22h37

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