Discussion :

[Tatiekamlionel]

Le langage qui peut remplaçer le C est le Java puisqu'il est portable et peut fonctionner sur toutes les plates formes

[Médinoc]

Mais il ne remplit pas du tout la même fonction que C.

[Iradrille]

Le langage qui peut remplaçer le C est le Java puisqu'il est portable et peut fonctionner sur toutes les plates formes

Si Java pouvait remplacer le C, il l'aurait déjà fait.

[Bktero]

Sur toutes les plateformes où des gens se sont cassés la tête à porter la JVM et le runtime (au moins une partie) XD

Et ce n'est pas une mince affaire !

[Vincent PETIT]

Et en plus le langage C est porté par un secteur probablement plus important que l'informatique; l'électronique et l'embarqué dans le sens général du terme. C'était mon métier !

Dans quasiment tous les appareils qui t'entourent il y a probablement un petit microcontrôleur avec un programme qui tourne dedans. Tous les fabricants, de ce genre de composants, fournissent des compilateurs C (libre comme AVR-GCC, MSP-GCC, ARM-GCC etc... ou privé Keil, IAR etc...)

Pourquoi le C ? Car tu as des micro qui n'ont que 512 octets de RAM (j'ai bien dit octets) et c'est largement suffisant pour ce qu'on lui demande de faire puisque dans beaucoup de cas de figure c'est le PC qui fait les gros calculs. Tout ça pour dire que tu as besoin d'avoir un langage qui te permet de tout maîtriser. Tu imagines que dans les 512 octets tu as la pile et le tas ! Inutile de penser à un langage de haut niveau avec des notions d'héritage, POO, polymorphisme etc... adieu aussi tout ce qui est langage avec Garbage collector (ramassé miette). C'est hyper efficace mais on a pas assez de maîtrise.

On peut quand même imaginer prendre du C++ ou Java mais ça sera pour programmer en fonctionnel comme le C (du coup y a aucun intérêt si ce n'est le masochisme)

Pour moi, il n'y a aucun langage qui peut remplacer le C à cause de l'embarqué (et ce n'est pas une discipline à part car chez vous je suis quasiment sur qu'il y a très certainement au moins 5 fois plus de petits systèmes embarqués que de PC) des petits micro il peut en avoir dans les jouets, manettes de console, télécommande TV, dans la TV, Box, radio réveil, machine à laver, sèche linge, posté à souder, radiateur, thermostat programmable, etc. On est cerné !

[Uther]

Et ça c'est loin d'être fait. AMHA c'est parce que les langages comme ceux cités par le monsieur de l'article (qui bien évidemment prêche pour sa paroisse, parce que quitte à devoir choisir dans ces trois-là je préfère encore Rust plutôt que D) se concentrent sur seulement quelques aspects de langage, au détriment d'autres tout aussi importants pour lesquels le C restera bien meilleur comparé à eux.

Tu aurais des exemples précis d'aspect du langages meilleurs en C ? Parce que j'ai au contraire plutôt l'impression que ces langages ont été bâtis sur la longue expérience du C/C++ et ont essayé de traiter le plus globalement possible les problèmes tout en en gardant les principales forces. Je ne vois pas de fonctionnalités qui soient vraiment mieux gérés en C que dans des langages comme D ou Rust.

Le seul point que je vois, mais pour moi c'est une qualité, c'est que le code peut parfois paraitre plus complexe, car le langage a fait le choix de rendre explicite les problèmes techniques qui font que tu peux te tirer un balle dans le pied. C'est particulièrement le cas en Rust.

Pourquoi le C ? Car tu as des micro qui n'ont que 512 octets de RAM (j'ai bien dit octets) et c'est largement suffisant pour ce qu'on lui demande de faire puisque dans beaucoup de cas de figure c'est le PC qui fait les gros calculs. Tout ça pour dire que tu as besoin d'avoir un langage qui te permet de tout maîtriser. Tu imagines que dans les 512 octets tu as la pile et le tas ! Inutile de penser à un langage de haut niveau avec des notions d'héritage, POO, polymorphisme etc... adieu aussi tout ce qui est langage avec Garbage collector (ramassé miette). C'est hyper efficace mais on a pas assez de maîtrise.

On peut quand même imaginer prendre du C++ ou Java mais ça sera pour programmer en fonctionnel comme le C (du coup y a aucun intérêt si ce n'est le masochisme)

Je vais parler de Rust, parce que c'est celui que je connais le mieux, mais cela s'applique normalement aussi, du moins en partie, au D.

Rust est multi-paradigme et peut donc tout a fait être programmé en fonctionnel, et ça n'a rien d'une hérésie comme en Java : le langage est parfaitement prévu pour ça.

En fait Rust est beaucoup plus orienté fonctionnel que objet : il n'a notamment pas de notion de classe avec héritage. Il permet certes de faire du polymorphisme via les traits, mais le langage et sa bibliothèque n'invite pas en abuser et préfèrent plutôt se reposer sur la généricité. Le langage visant a laisser un maximum de contrôle sur le système, il n'a évidement pas GC et on peut maîtriser totalement l'allocation mémoire, sur la pile comme sur le tas.

Alors certes, le poids de l'existant fait que Rust ne sera probablement pas supporté par autant de compilateurs et d'architectures embarquées que le C aujourd'hui, mais techniquement il en est capable.

[Vincent PETIT]

Intéressant !
Je suis mitigé pour le coup car en regardant de plus prés le langage D, je vois que :

• Pour du bas niveau (config des registres), il est très ressemblant au C par contre un peu trop ressemblant pour le remplacer car il n'y a pas de réelle plus-value.
• Pour du moyen niveau (gestion de module plus complexe) il présente un avantage par rapport au C car ça notion d'objet "light" apporterait de la légèreté au code
• Pour du haut niveau (interface graphique) il a les avantages des langages tels que C++ et Java

Effectivement D est polyvalent, pas de doute là dessus.

+1
Même si je pense qu'on est pas prêt de voir disparaître le C, je partage ton point de vu.

[watchinofoye]

Tu aurais des exemples précis d'aspect du langages meilleurs en C ? Parce que j'ai au contraire plutôt l'impression que ces langages ont été bâtis sur la longue expérience du C/C++ et ont essayé de traiter le plus globalement possible les problèmes tout en en gardant les principales forces. Je ne vois pas de fonctionnalités qui soient vraiment mieux gérés en C que dans des langages comme D ou Rust.

Le seul point que je vois, mais pour moi c'est une qualité, c'est que parfois le code peut parfois paraitre plus complexe, car le langage a fait le choix de rendre explicite les problèmes techniques qui font que tu peux te tirer un balle dans le pied. C'est particulièrement le cas en Rust.

Je t'avoue que je parlais surtout de manière générale, parce qu'à chaque fois qu'il y a un débat sur "quel est le meilleur langage", le constat qui ressort toujours c'est que chaque langage est différent, le plus souvent parce qu'il est conçu pour un ou plusieurs usage(s) en particulier, et ne peut donc être considéré meilleur qu'un autre.

Si on s'en tient seulement aux langages cités dans l'article, j'ai bien l'impression de retrouver le même problème. J'élimine Go d'entrée de jeu puisqu'un de ses objectifs semble être de simplifier la programmation, à outrance visiblement. Comme dit dans l'article (même si ce dernier semble biaisé), ce côté simpliste semble être un gros inconvénient.

Pour ce qui est de Rust et de D, faudrait que je voie ça plus en détails. A priori, je trouve que ça se voit que Rust est inspiré de OCaml. Lorsque j'ai essayé de m'intéresser à Caml, même si je lui ai vu un certain potentiel, la seule conclusion que j'en ai tiré c'est que c'est "un langage de matheux" (et quand je dis matheux je parle bien de maths fonda, pas de maths qu'on te fait faire au lycée pour te donner deux trois bases élémentaires pour attaquer la physique appliquée).
Par langage de matheux je veux dire que l'optique de programmation est assez différente (rien à voir avec le dev qu'on peut faire généralement en C, on entre dans la programmation formelle). Pour en revenir à Rust, à cause de cette inspiration prononcée, je trouve la syntaxe assez rebutante. J'affectionne cependant la sûreté vantée du langage, c'est un point qui peut prévaloir sur la syntaxe (mais seulement si je dois absolument faire la transition de C vers Rust), tout comme j'aimerais bien passer à d'autres langages plus sûrs que le C. Là encore, ça dépend si l'usage impose de passer à quelque chose de plus adapté.

Concernant D, le peu que j'en ai vu pour l'instant me donne l'impression qu'il est autant un remplaçant de C que peut l'être C++. Il faudrait que j'entre plus dans le détail pour voir ce qu'apporte D de plus par rapport au C ET C++. Si toi (oui, toi qui lit ceci et qui est en train de fulminer parce que j'ai osé dire que D ne vaut pas mieux que C++ ) ou quelqu'un d'autre a envie de me faire une synthèse des avantages et inconvénients de D par rapports à C/C++, je suis preneur. Ça ne m'empêchera pas de rester sur C ni d'essayer D par moi-même quand j'en aurai le temps, mais ce sera toujours ça de pris.

Petite parenthèse, je ne dénigre pas ces langages. Je leur trouve des côtés qui pourraient éventuellement me séduire, des aspects que j'aurais trouvé dans d'autres langages et que j'aurais aimé avoir dans C voire C++. Mais dans l'immédiat, ils ne sont pas prêts à remplacer C. Et je le répète, il ne s'agit pas d'une question de performances, d'efficacité, ou que sais-je encore. Il faudrait un langage "meilleur" que C mais qui en soit suffisamment proche pour assurer sa transition. Oui je sais, dit comme ça ça paraît un peu ridicule vu que quitte à proposer un langage proche du C, autant rester sur le C, voire passer à du C++ (mais là on rentre dans le débat stérile C vs C++) quand c'est possible.

Je le redis, ce n'est pas la peine de chercher absolument un remplaçant au C, surtout quand il n'en a pas besoin. Il sert encore beaucoup, surtout dans le domaine de l'embarqué (dont je fais partie). Quand il deviendra obsolète, on lui cherchera un successeur.
En attendant, je veux bien essayer ces trois langages de mon côté pour me faire une idée plus poussée de leur fonctionnement. Et si vraiment l'un d'eux me séduit davantage que le C, pour les mêmes usages que j'en fais, alors je viendrai dire que, pour moi, ce langage est le remplaçant du C.

[diralark]

Quel langage pourrait remplacer C ?

mauvaise question faudrait déjà que des gens se plaignent du C pour vouloir en changer.. et tout ceux qui code en C adore ça

[Iradrille]

Pour ce qui est de Rust et de D, faudrait que je voie ça plus en détails. A priori, je trouve que ça se voit que Rust est inspiré de OCaml. Lorsque j'ai essayé de m'intéresser à Caml, même si je lui ai vu un certain potentiel, la seule conclusion que j'en ai tiré c'est que c'est "un langage de matheux" (et quand je dis matheux je parle bien de maths fonda, pas de maths qu'on te fait faire au lycée pour te donner deux trois bases élémentaires pour attaquer la physique appliquée).
Par langage de matheux je veux dire que l'optique de programmation est assez différente (rien à voir avec le dev qu'on peut faire généralement en C, on entre dans la programmation formelle). Pour en revenir à Rust, à cause de cette inspiration prononcée, je trouve la syntaxe assez rebutante. J'affectionne cependant la sûreté vantée du langage, c'est un point qui peut prévaloir sur la syntaxe (mais seulement si je dois absolument faire la transition de C vers Rust), tout comme j'aimerais bien passer à d'autres langages plus sûrs que le C. Là encore, ça dépend si l'usage impose de passer à quelque chose de plus adapté.

Concernant D, le peu que j'en ai vu pour l'instant me donne l'impression qu'il est autant un remplaçant de C que peut l'être C++. Il faudrait que j'entre plus dans le détail pour voir ce qu'apporte D de plus par rapport au C ET C++. Si toi (oui, toi qui lit ceci et qui est en train de fulminer parce que j'ai osé dire que D ne vaut pas mieux que C++ ) ou quelqu'un d'autre a envie de me faire une synthèse des avantages et inconvénients de D par rapports à C/C++, je suis preneur. Ça ne m'empêchera pas de rester sur C ni d'essayer D par moi-même quand j'en aurai le temps, mais ce sera toujours ça de pris.

Même sensation pour moi.
Rust (que je connais pas vraiment) semble être entièrement basé sur le fait de pouvoir prouver mathématiquement que le programme marche (ce qui est une bonne chose quand on bosse sur du code critique), mais avec un syntaxe dégueu (yep ils ont réussi à faire pire que Python et les blocs basés sur l'indentation ).

Pour D, il y a quand même quelques avantages par rapport au C / C++. En vrac :
* Une syntaxe plus propre que le C++ (en C++ ça devient vite bordélique avec des templates).
* Des vrais objets constants (immutable) et pas simplement une "vue constante" comme en C / C++ (bien qu'on ai constexpr maintenant en C++ qui répond en partie à ce besoin)

Code C++ :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
void foo(int const& i, int& j) {
   // passer un int par const ref c'est étrange, c'est qu'un exemple
   int const copy = i;
   ++j;
   assert(copy == i); // on s'attend à ce que se soit vrai car i est const,
   // mais on a seulement une vue constante de la variable
   // i n'est pas réellement const
}
 
int i = 42;
foo(i, i);

* La prog par contrats (qui arrive doucement en C++)
* Un système de modules plus simple / performant que les #include (qui devrait arriver en C++ ? Je sais pas trop où ça en est)
* Tests unitaires intégrés au langage

Bref le D apparait comme ce que devrait être le C++ (les points noirs étant la présence d'un GC et pour l'instant un écosystème peu développé).

Mais clairement D est plus un remplaçant au C++ qu'au C. Il semble trop haut niveau pour répondre aux mêmes besoins que le C.

[Uther]

Rust (que je connais pas vraiment) semble être entièrement basé sur le fait de pouvoir prouver mathématiquement que le programme marche (ce qui est une bonne chose quand on bosse sur du code critique), mais avec un syntaxe dégueu (yep ils ont réussi à faire pire que Python et les blocs basés sur l'indentation ).

Rust ne vise absolument pas a faire la preuve mathématique du programme. Il s'assure seulement de la sécurité mémoire en contrôlant l'usage qui en est fait. En gros les variable sont propriétaire de la mémoire qu'elle utilisent et les pointeur sont contrôlé de manière a ce qu'il ne puissent modifier un variable en même temps.

Qu'est ce que tu reproches précisément à la syntaxe? Elle est plutôt classique, pas du tout sensible a l'indentation et au contraire très éloignée du Python.

[progdebutant]

Atha (dans un des six premiers posts) a écrit :

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

Je ne vois pourtant pas le message de @Niark13 avant le sien.

Pour en revenir au topic, je suis par rapport à vous tous un débutant mais je trouve que le C est super au vu de tout ce qu'on peut faire avec (jeux rapides, systèmes, etc) et le fait qu'il puisse être dans des micro-contrôleurs.
Et que sa syntaxe me semble facile à comprendre et mémoriser.

D'après une grande partie des messages que j'ai lu je ne pense pas que le C soit actuellement remplaçable donc c'est ce que j'ai voté.

[Iradrille]

Qu'est ce que tu reproches précisément à la syntaxe? Elle est plutôt classique, pas du tout sensible a l'indentation et au contraire très éloignée du Python.

L'inférence de type à outrance semble être la norme (bon ok, c'est pas un problème de syntaxe mais de convention). Et le type est "caché" derrière un mot clef quand il est donné

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
int i = 42;
// vs
let mut i: i32 = 42;

De même pour les fonctions

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
int foo() { return 42; }
// vs
fn foo()->i32 { 42 } // pas de ";"

Le rebinding de variable est aussi assez dérangeant, en particulier lié à l'inférence de type. Utilisé correctement ça peut être utile, mais ça peut (et sera) exploité pour faire des horreurs.

La syntaxe me semble pas pratique tout simplement.

[Uther]

Je ne suis moi même pas un grand fan de l'inférence de type et ce que j'apprécie justement dans Rust, c'est qu'elle est volontairement limitée à l'intérieur des fonctions. Quand en C++, on peut désormais utiliser `auto` presque partout, en Rust les fonctions doivent impérativement déclarer le type des paramètres et du retour. De plus comme il n'y a pas de conversion de type implicite, je trouve qu'à l'usage, il est bien plus facile de savoir avec quel type je travaille en Rust qu'en C++.

Le fait de ne pas avoir le type en premier, ça m'a surpris au tout début, mais ça deviens très vite naturel. Avoir systématiquement le mot clé `let` devant les déclarations et `fn` devant les fonctions les rend au contraire plus visible.

[RPGamer]

Je ne crois pas que les ingénieurs en automobiles cherchent à savoir ce qui pourrait remplacer la boîte séquentielle manuelle et le volant de nos véhicules qui ont plus de 100 ans (et de nombreux défauts) alors je ne pense pas qu'il soit pertinent de chercher à remplacer un langage si étroit avec le fonctionnement des ordinateurs, fonctionnement qui a fondamentalement que peu évolué depuis beaucoup moins de 100 ans encore.

Pour moi il n'y aura un remplaçant du C qu'avec l'arrivée de l'informatique quantique... et encore... il y a maintenant des véhicules électriques qui chamboulent totalement la vision de l'automobile mais sans changer d'un iota l'interface homme-machine.

[Iradrille]

Pour moi il n'y aura un remplaçant du C qu'avec l'arrivée de l'informatique quantique... et encore... il y a maintenant des véhicules électriques qui chamboulent totalement la vision de l'automobile mais sans changer d'un iota l'interface homme-machine.

Bah regarde ce qu'il se passe avec l'arrivé du GPGPU : le C n'est pas utilisé : on utilise des langages particuliers pour les kernels. Il y a fort à parier que ce sera pareil pour l'informatique quantique (d'autant plus que la façon de penser est radicalement différente, et donc que le C ne sera pas adapté).

[RPGamer]

Je le pense aussi (c'est ce que je dis) mais je crois surtout que personne ne peut vraiment de dire aujourd'hui car le C évolue aussi et est porté par beaucoup d'acteurs.

[munstef]

D permet d'écrire des programmes static ce qui met en tord que le langage D n'est pas capable de programmer de mini micro-processeur de 512 o
Mais à cette taille, il vaudrait mieux utiliser l'assembleur. Et l'assembleur est possible dans le langage D.
Ecrire en D est plus facile de programmer que le C++; bien que ce dernier propose des possiblilité plus complexes, mais plus dificile à programmer.
Il n'est pas rare d'utiliser des structure complexes sans pour autant utiliser des objets avec la possibilité de programmer avec des conditions statique de façon naturelle.
Finir avec les fichers en-têtes.
Si le seul moyen de programmer des mini-proceseurs en C (quelques octets), il est n'est pas excus d'utiliser le langage C. Mais ce serait dommage de passer à coté du D pour de la programmation plus complexes.

[nhugodot]

Je pense à Julia: aussi lisible que Python, compatible avec des bibliothèques C et Python, aussi rapide que C, etc. (Voir aussi Crystal Nom, etc.)
Python étant le langage le plus enseigné, ces jeunes développeurs se tourneront plus aisément vers Julia que C ou Rust. Et comme Java l'a été en son temps pour faire tout, du web, apps mobiles ou système , Julia est plus facile, maintenable, rapide, compatible C ou Python ...
Non pour programmer un OS (quoique?) comme C/C++ ou Rust mais pour remplacer C/C++ (et java, go, ...) en programmation d'application rapides: rapide pour programmer, rapide a l'exécution, rapide a maintenir/évoluer...
Qu'en pensez-vous ?