Discussion :

[Artemus24]

Salut à tous.

Il faut vraiment ne pas connaître Ada pour sortir qu’il n’est pas utilisé en entreprise et qu’il n’a pas été créé pour répondre à un besoin (il suffit de se renseigner sur l’histoire de la création du langage…).

Il ne faut pas supposer des choses avant de savoir de quoi on parle. Voici ce que j'ai dit au sujet d'Ada :

Je prends aussi comme exemple Ada qui était très prometteur en son époque ou encore Prolog. Hors d'un contexte universitaire, je n'ai jamais vu ces langages en entreprise.

Si je parle de ce langage, c'est qu'il y a fort longtemps, je l'ai appris croyant qu'il deviendrait un langage commun aux entreprise, genre langage universel comme PL1 à son époque.
Il se trouve que j'ai travaillé d'abord en gros système BULL et ensuite en IBM, dans le secteur bancaire, sans avoir jamais rencontré le langage Ada.
Si je ne m'abuse pas, c'est bien dans les années 1980 et chez Bull que ce langage a été créé.
Or il se trouve que j'ai travaillé sous GCOS 7 et 8 des systèmes d'exploitations de chez BULL, fort utilisés par les banques à une certaines époques, avant d'être remplacé par de l'IBM MVS/OTSO/ISPF, voire même par de l'AS400.

Et quand je parle du besoin, c'est celle des entreprises. En tout cas, cela n'a jamais répondu au besoin des banques !
Donc il fait relativiser le soi-disant succès d'un langage quand la grande majorité des entreprises ne l'utilisent pas.

Justement l’intérêt est parfois de simplifier les concepts a appendre.

Je ne suis pas contre cette idée, mais ce n'est pas la simplification d'un concept que recherche les entreprises.
Il s'agit bien du temps nécessaire pour développer un projet qui est le nœud gordien des projets. Et comme vous le savez, le temps c'est de l'argent.
Sinon pourquoi le cobol aurait autant de succès en entreprise alors que c'est un très vieux langage ? Avez-vous au moins entendu parlé de PacBase ?

Le C++ est une horreur a ce niveau : il est inutilement complexe. Le but de langage comme le Go est justement d'être bien plus simple a maîtriser.

Je ne trouve pas si compliqué que cela le C++. Cela dépend des langages que vous avez pratiquez avant, enfin je suppose.
Il est sûr, que si vous avez pratiqué en premier du Python, le C++ doit vous paraître très compliqué, voire même préhistorique comme langage.

Je remarque que la majorité de ceux qui critiquent les autres langages que leur chouchou ne les connaissent pas:

vous tombez mal par votre réflexion. Je connais environ un trentaine de langage, surtout en gros système et sous Unix.
Ils ont tous des avantages et des inconvénients, mais aucun ne sort du lot.
Certains répondent à un besoin spécifique pour lesquels ils ont été développés.
Maintenant si vous les utilisez en dehors de ce pourquoi ils ont été crées, je peux comprendre la volonté de changer de langage.

Google a été clair : Go répond a un véritable besoin pour eux.

Là encore Rust a été créé spécifiquement pour répondre à ces besoin et y répond très bien.

Dans ces deux exemples, on voie nettement qu'un besoin se fait ressentir.
D'où la création d'un langage spécifique pour répondre à ces besoins.
Et vous croyez qu'en partant du besoin spécifique à ces entreprises, on va généraliser cela à tout le monde ?
Mais quand est-il des autres qui n'appartiennent pas à Google ou à Mozilla ?

Désolé de le dire, mais vous êtes très enthousiaste !

@+

[Uther]

Et quand je parle du besoin, c'est celle des entreprises. En tout cas, cela n'a jamais répondu au besoin des banques !
Donc il fait relativiser le soi-disant succès d'un langage quand la grande majorité des entreprises ne l'utilisent pas.

En même temps le langage universel parfait n'existe pas. Ada n'a jamais prétendu être le langage parfait pour réponde a tous les besoins.
De plus il faut voir que le bancaire dans lequel vous semblez travailler, c'est un domaine très particulier ou le poids de l’existant est souvent énorme. Dans d'autres domaines, il est moins déterminant (même s'il reste généralement important) et on peut plus facilement se permettre d'utiliser de nouvelles technologies.

Je ne suis pas contre cette idée, mais ce n'est pas la simplification d'un concept que recherche les entreprises.
Il s'agit bien du temps nécessaire pour développer un projet qui est le nœud gordien des projets.
Et comme vous le savez, le temps c'est de l'argent.

A court terme peut-être, mais une base de code vieillissante sur des technologies mal maîtrisées ça peut coûter encore plus cher à long terme. On a plusieurs projet chez nous qui auraient gagné à être refondus il y a longtemps.

Sinon pourquoi le cobol aurait autant de succès en entreprise alors que c'est un très vieux langage ? Avez-vous au moins entendu parlé de PacBase ?

Oui j'ai entendu parler de PacBase, bien que je n'en ai jamais fait personelement. Chez nous, je ne dirais pas que le Cobol est un succès : on a des gens qui font avec dans certains projets bancaires, mais c'est généralement par contrainte et non par choix. On essaie de le remplacer par autre chose dès que c'est faisable sans trop de surcoût.

Je ne trouve pas si compliqué que cela le C++. Cela dépend des langages que vous avez pratiquez avant, enfin je suppose.
Il est sûr, que si vous avez pratiqué en premier du Python, le C++ doit vous paraître très compliqué, voire même préhistorique comme langage.

En général si on trouve le C++ simple, c'est qu'on l'utilise mal. Les concepts ne sont pas foncièrement complexe au premier abord, mais si on ne les connais pas bien toutes les implications parfois subtiles, on se retrouve très facilement avec des erreurs sournoises.

Dans ces deux exemples, on voie nettement qu'un besoin se fait ressentir.
D'où la création d'un langage spécifique pour répondre à ces besoins.
Et vous croyez qu'en partant du besoin spécifique à ces entreprises, on va généraliser cela à tout le monde ?
Mais quand est-il des autres qui n'appartiennent pas à Google ou à Mozilla ?

J'ai cité Google et Mozilla comme exemple et car se sont les créateurs des langages et que s'ils pris la peine de faire ça c'est bien avant tout pour répondre a leur besoins. Mais la simplicité, l'efficacité et la sécurité, c'est des besoins somme toute assez communs, il est évident qu'ils sont partagés par bien d'autres entreprises.

Désolé de le dire, mais vous êtes très enthousiaste !

Je ne vois pas ce que l'enthousiasme a à faire là dedans. Je ne parie pas sur le vainqueur d'une course de chevaux. Comme tout le monde ici, je sais bien que le C n'est pas prêt de disparaître. Mais tout comme le Cobol n'est plus la référence indispensable pour les nouveaux projets, je pense qu'il y a clairement de la place dans les projets bas niveau a venir pour des langages plus modernes qui apportent plus de simplicité, sécurité, ...

[Traroth2]

"Quel langage pour remplacer le C ?"

Je trouve la question mal posée. Le C est un langage fantastique, qui n'a pas besoin d'être remplacé. Si quelque chose de réellement mieux se présente, pourquoi pas, mais il faut vraiment que ça apporte un plus.

[Chauve souris]

Ca dépend de ce qu'on veut programmer ! AMHO le C/C++ reste incontournable et il évolue (corrections, extensions). Car il est le plus rapide vu qu'il ne gère pas les vacheries possibles et que c'est au programmeur de le faire au coup par coup. Dites moi si je me trompe mais je pense que les jeux, où la rapidité de réaction compte, sont programmés en C/C++. Pour d'autres usages (gestion, bases de données) il est inutile de s'encombrer avec la complexité du C/C++ puisque la rapidité n'est pas aussi nécessaire et qu'elle est régie par les interventions humaines et les accès disques.

[Uther]

Ca dépend de ce qu'on veut programmer ! AMHO le C/C++ reste incontournable et il évolue (corrections, extensions). Car il est le plus rapide vu qu'il ne gère pas les vacheries possibles et que c'est au programmeur de le faire au coup par coup. Dites moi si je me trompe mais je pense que les jeux, où la rapidité de réaction compte, sont programmés en C/C++. Pour d'autres usages (gestion, bases de données) il est inutile de s'encombrer avec la complexité du C/C++ puisque la rapidité n'est pas aussi nécessaire et qu'elle est régie par les interventions humaines et les accès disques.

En effet le principal usage du C/C++, c'est quand on veut avoir un contrôle optimal de ce qui se passe à bas niveau. Cela permet d'avoir généralement de meilleures performances pour peu que l'on sache bien ce que l'on fait. A ce niveau là des langages comme Go ou Java ne sont plus en course.

Cependant Rust et D(avec GC désactivé) sont capables de se débrouiller tout aussi bien en code bas niveau, tout en offrant plus de fonctionnalités haut niveau que le C, moins de complexité que le C++ et bien plus de sécurité que ces deux langages. Donc la question de les utiliser à la place n'est pas du tout incongrue.

[Artemus24]

Salut Luther.

De plus il faut voir que le bancaire dans lequel vous semblez travailler, c'est un domaine très particulier ou le poids de l’existant est souvent énorme. Dans d'autres domaines, il est moins déterminant (même s'il reste généralement important) et on peut plus facilement se permettre d'utiliser de nouvelles technologies.

Ce que vous dites est tout à fait vrai. Je rajouterai que ce poids de l'existant est particulièrement contraignant car c'est fréquemment le client qui impose ce choix par nécessité.

A court terme peut-être, mais une base de code vieillissante sur des technologies mal maîtrisées ça peut coûter encore plus cher à long terme.

Si vous soulevez le problème de la maintenance, je suis encore d'accord avec vous.
Plus la base de code devient énorme, voire gigantesque, plus la maintenance va coûter cher, ce qui implique une impossibilité même à long terme, à tout réécrire dans un langage qui serait plus adapté.

Imaginez un seul instant, la refonte total du cœur du métier bancaire, en passant du cobol à un langage mieux adapté !
En l'état actuel, c'est quasiment impossible à faire, car le problème vient essentiellement de la connaissance du métier de la banque.
Il faut maîtriser ce cœur et je peux vous assurez que même chez les banquiers, cette condition n'est pas toujours présente dans leur effectif.
Voire même, pour répondre à ce genre de question, on interroge fréquemment les informaticiens. Oui, vous avez bien lu, la connaissance n'est plus chez les banquiers mais dans deux corps de métiers, qui sont les informaticiens et les financiers.
Alors quand le créateur d'une application vient à disparaître des effectifs de la banque, celle-ci perd une part de sa connaissance et de sa culture.
Il arrivera un jour où plus personne ne maîtrisera ce système d'information, qui d'une part sera devenu extrêmement complexe, mais d'autre part le niveau de connaissance requis pour le maintenir n'existera plus.
Oui, je parle aussi de la formation des gens qui seront les informaticiens de demain, dans le domaine bancaire. Le cobol n'est pratiquement plus enseigné dans les écoles, et quelqu'un qui sort d'une de ces écoles préfère se mettre à son compte pour faire du web car c'est plus rémunérateur, et il peut aussi faire ce qu'il veut.

On a plusieurs projet chez nous qui auraient gagné à être refondus il y a longtemps.

D'où ma question : qu'elle est la raison qui fait que vous remettez à demain ce que vous pourriez faire aujourd'hui ?
Est-ce un problème de compétences que vous ne trouvez pas sur le marché, un problème de budget ou encore pas le temps nécessaire pour faire une refonte de vos projet ?
C'est ce poids de l'existant qui est un problème dans le milieu informatique, quelque sort le métier.
Si vous faites toujours du neuf alors le problème se ne pose pas et n'importe quel langage qui répond à vos besoins fera l'affaire. Sur ce point, je suis en conformité avec ce sujet.

Oui j'ai entendu parler de PacBase, bien que je n'en ai jamais fait personnellement.

J'ai fait du pacbase et c'est une grosse merde qui a été imposé par IBM dans les banque. Le slogan étant de nous faire gagner du temps dans les développements.
Mais au final, cela posait plus de problème dès que les traitements devenaient complexes. En fait, pacbase est adapté pour des tous petits projets qui évolue autour du noyau centrale.

Chez nous, je ne dirais pas que le Cobol est un succès : on a des gens qui font avec dans certains projets bancaires, mais c'est généralement par contrainte et non par choix

A ma connaissance, le cobol est utilisé essentiellement sur le gros système IBM et plus rarement sur des mini-systèmes.
Oui, vous avez encore raison, ce n'est pas par choix, mais parce que le client impose ce choix par nécessité !

On essaie de le remplacer par autre chose dès que c'est faisable sans trop de surcoût.

Quand vous en avez la possibilité, je veux bien, mais sur gros système IBM, à part Pacbase et le cobol natif, il n'y a pas grand chose d'autre. Peut-être de l'assembleur IBM 370 ???

En général si on trouve le C++ simple, c'est qu'on l'utilise mal.

Tout dépend comment vous développez. D'après mon expérience, beaucoup de gens qui font du C++ ne maîtrisent pas correctement la POO. Autrement dit, ils utilisent du C++ pour faire du procédurale.

Les concepts ne sont pas foncièrement complexe au premier abord, mais si on ne les connais pas bien toutes les implications parfois subtiles, on se retrouve très facilement avec des erreurs sournoises.

Pour être honnête avec vous, je n'ai jamais travaillé sur des projets très complexe en C++. Et d'après ce que j'ai vu, notre façon de développée était plus du procédurale que de la POO.

J'ai cité Google et Mozilla comme exemple et car se sont les créateurs des langages et que s'ils pris la peine de faire ça c'est bien avant tout pour répondre a leur besoins.

Je ne vous fait aucun reproche. Je dis simplement que c'est le besoin de Google et de Mozilla mais pas nécessairement le besoin de ceux qui sont extérieurs à ces deux entreprises.
Je prends le cas de la Macif, à Niort, où ils utilisent le Natural/Adabas, qui créé par la société allemande Software AG et qui est très bien adapté pour ce qu'ils font. Donc vous ne pouvez pas conclure qu'ailleurs, cela sera de même.

Mais la simplicité, l'efficacité et la sécurité, c'est des besoins somme toute assez communs, ...

Oui, mais pour qui ? C'est cette dimension que vous avez tendance à généraliser.

... il est évident qu'ils sont partagés par bien d'autres entreprises.

Définissez moi les besoins de l'entreprise et je vous dirais si cela répond à ses besoins.
Il n'y a pas qu'un seul corps de métiers en informatique et de ce fait, il n'y a pas qu'un seul besoin.

Je ne vois pas ce que l'enthousiasme a à faire là dedans.

Je parlais de Olivier Famien et de son manque d'objectivité. Il se trouve, mais je n'en sais rien, qu'il est peut-être très impliqué dans ce projet pour avoir les idées suffisaments claires.

Comme tout le monde ici, je sais bien que le C n'est pas prêt de disparaître.

Tout à fait car ce langage est directement lié à Unix et par voie de conséquence à Linux et à ces dérivés.
Et quand on parle du C, est-ce du langage qui porte ce nom, ou du concept dont beaucoup de langages s'inspirent ?
Je pense plus à un enrichissement qu'à un changement de concept, donc oui, le langage va évoluer mais pas nécessairement disparaître.

Mais tout comme le Cobol n'est plus la référence indispensable pour les nouveaux projets, je pense qu'il y a clairement de la place dans les projets bas niveau a venir pour des langages plus modernes qui apportent plus de simplicité, sécurité, ...

Je ne dis pas le contraire, mais vous avez tendance à sous-estimer la lourdeur de l'existent qui a justement tendance à freiner les innovations.

@+

[Uther]

Imaginez un seul instant, la refonte total du cœur du métier bancaire, en passant du cobol à un langage mieux adapté !

Je sais très bien que ça n'est pas près d'arriver, tout comme ça n'arrivera pas au C et même les supporters les plus fanatiques de D et Rust, sur se forum et même ailleurs en sont parfaitement conscient. Il n'a jamais été question de remplacer l'intégralité de l'existant C par un autre unique langage.

Oui, je parle aussi de la formation des gens qui seront les informaticiens de demain, dans le domaine bancaire. Le cobol n'est pratiquement plus enseigné dans les écoles, et quelqu'un qui sort d'une de ces écoles préfère se mettre à son compte pour faire du web car c'est plus rémunérateur, et il peut aussi faire ce qu'il veut.

Je ne suis pas certain que le développeur Web lanbda soit mieux payé que le développeur Cobol, au contraire les profils Cobol étant plus rare, il sont généralement bien mieux rémunéré que les développeur PHP qui ne manquent pas.

D'où ma question : qu'elle est la raison qui fait que vous remettez à demain ce que vous pourriez faire aujourd'hui ?
Est-ce un problème de compétences que vous ne trouvez pas sur le marché, un problème de budget ou encore pas le temps nécessaire pour faire une refonte de vos projet ?

Le problème est généralement toujours le même : l'argent, le client n'a souvent pas une vision a assez long terme et va au moins cher sans voir qu'a long terme ça lui coutera plus. Il faut voir qu'il sont obligé de faire avec le budget qu'on leur donne qui sont généralement prévus a l'année.
Après parfois en effet le cout d'une refonte n'en vaut vraiment pas la peine. Je ne dis pas qu'il faut tout jeter a la poubelle parce que la techno, n'est pas dernier cri, loin de là.

Oui, mais pour qui ? C'est cette dimension que vous avez tendance à généraliser.
Définissez moi les besoins de l'entreprise et je vous dirais si cela répond à ses besoins.
Il n'y a pas qu'un seul corps de métiers en informatique et de ce fait, il n'y a pas qu'un seul besoin.

En effet et vous pensez beaucoup au domaine du bancaire/gestion ou de toute façon le C n'est déjà pas la plus grosse référence.
Le C est surtout actuellement utilisé dans le domaine de l'embarqué et des hautes performance et globalement du bas niveau. Je ne vais pas vous citer toutes les entreprise que ça touche.

Je parlais de Olivier Famien et de son manque d'objectivité. Il se trouve, mais je n'en sais rien, qu'il est peut-être très impliqué dans ce projet pour avoir les idées suffisaments claires.

Olivier Famien est juste l'auteur de l'article qui est essentiellement une traduction d'un commentaire de Andrei Alexandrescu le principal développeur de D.
Donc c'est bien évidement orienté, mais en même temps ça n'a rien de caché.

[Bktero]

Le C est-il encore vraiment tant que ça utilisé ? Faut-il le remplacer dans les endroits où il est toujours là ?

Je travaille dans l'embarqué et le C y est toujours (et le sera encore pour très longtemps) présent, mais l'embarqué est un contre-exemple. En plus, l'embarqué évolue, on voit de plus en plus de gens utiliser du C++, mais aussi du Java ou du C#.

Ma question porte sur le monde PC (workstations et serveurs). Qui utilise encore du C aujourd'hui pour coder des applications complètes ? Le C reste présent dans certains domaines (système d'exploitation, haut-performance), souvent il sert à faire des morceaux des applications (écrites en Java ou Python mais avec des parties en C, grâce à des mécanismes comme JNI). Au-delà de ces domaines, existe t-il encore des endroits où C est utilisé alors qu'on aurait intérêt à utiliser d'autres langages ? Beaucoup de gens sont passés au C++ pour avoir un compromis performances / langage + moderne, à la limite ; si les besoins de performances ne sont pas si critiques, alors des tas d'autres langages sont utilisés.

Je ne dis pas que le C n'est plus utilisé, j'ai simplement l'impression que le C n'est plus utilisé que dans des domaines où de toute façon, on aura toujours besoin de lui. Et on aura de toute façon encore besoin de lui pendant très longtemps. Car Python et Java dont je parlais de Java, que ferait-il si l'interpréteur n'était pas codé en C et si l'OpenJDK n'était pas codé (en grande partie ?) en C ? Dans des cas comme ça, y a t-il un intérêt à remplacer C ? La question même de "remplacer" C a telle un sens ?

[Artemus24]

Salut Luther.

Dans l'ensemble nous sommes d'accord !

En effet et vous pensez beaucoup au domaine du bancaire/gestion ou de toute façon le C n'est déjà pas la plus grosse référence.

Je parle de ce que je connais, c'est-à-dire du milieu bancaire, et on n'a pas vraiment besoin d'un nouveau langage car le problème est complètement différent.
Croyez vous qu'il serait facile de faire de la maintenance en gros système iBM, si nous devions gérer plusieurs langages ?
Déjà avec le cobol et Pacbase, ce n'est pas toujours facile, alors imaginez avec d'autres.

En ce qui concerne le C, c'est essentiellement dans l'environnement Unix (ça va de soi) et c'est un langage que l'on rencontre de moins en moins souvent.
Il y a bien plus de liberté que dans le gros système IBM, d'où la multitude des langages que l'on peut rencontrer aujourd'hui.
Et comme je l'ai dit, quand on a commencé à développer dans un langage, on continue souvent dans le même langage.

Par contre, je ne sais pas trop ce qui se fait dans le monde du Web.
Je pense que j'ai été mal compris, car fréquemment les intervenants parle du web, pensant que c'est le seul qui prédomine dans le monde informatique.

@+

[Uther]

Je ne dis pas que le C n'est plus utilisé, j'ai simplement l'impression que le C n'est plus utilisé que dans des domaines où de toute façon, on aura toujours besoin de lui. Et on aura de toute façon encore besoin de lui pendant très longtemps. Car Python et Java dont je parlais de Java, que ferait-il si l'interpréteur n'était pas codé en C et si l'OpenJDK n'était pas codé (en grande partie ?) en C ?

Je vais redire ce que j'ai déjà dit a "Chauve souris" : il ne s'agit pas de remplacer C par Java ou Python qui en effet ne sont pas adaptés, mais par des langages comme D ou Rust qui sont parfaitement adaptés aux domaines ou on utilise le C.

[jopopmk]

[..] Au-delà de ces domaines, existe t-il encore des endroits où C est utilisé alors qu'on aurait intérêt à utiliser d'autres langages ? [..]

Ben si on "avait intérêt à utiliser un autre langage" on utiliserait un autre langage
Perso je fais du C pour des applis web, ça vous en bouche un coin, hein ?
(en fait c'est pas tout à fait vrai, mais pas complètement faux)

[Iradrille]

Tient j'écrivais quelques lignes de C, et je me suis rendu compte à quelle point la généricité était chiante en C (void * / macro).

Pourquoi on voit pas mal de "C with classes" mais très peu (voir pas du tout) de "C with templates" ?

Le "C with classes" c'est une abomination, soit en code en C soit en C++... Mais du C avec des templates (pour répondre au manque évident du C dans ce domaine), pourquoi pas ?
Les templates (et les exceptions) sont les premiers composants de C++ à sauter quand un mélange de C/C++ est utilisé, pourquoi ?

Pour les exceptions c'est souvent l'argument du coût : un if toutes les deux lignes serait moins cher qu'un bloc try / catch par ci par là, mais les templates ?

[SurferIX]

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.

J'aimerais bien savoir qui t'a mis 3 down et surtout pourquoi

La question "Quel langage pourrait remplacer C ?" ou ses dérivés ("Est-ce que le C va mourir ?" etc) revient tout les ans, dans 20 ans on aura toujours du C et niveau concept il n'aura pas bougé d'un poil.

Il n'y a qu'a voir sur les 10 dernières années, les développeurs les plus demandés, et dans quels domaines : en gros, c'est toujours C, C++ et Java. Sur les 20 dernières années, c'est toujours C et C++. Donc bon... heureusement qu'à l'IUT les étudiants mangent du C++ pendant presque deux ans... quand on connaît bien C++, tous les autres langages paraissent à la fois simples et peu évolutifs... car le C++ a absolument toutes les choses que les autre langages acquièrent au fil du temps : classes, héritage, héritage multiple, surcharge opérateurs, bas niveau, etc etc.


Bref d'ici que le C ne soit plus dans le top 3 on sera tous grands-parents... si jamais ça arrive

[RyzenOC]

J'aimerais bien savoir qui t'a mis 3 down et surtout pourquoi

Parce que j'ai dit Python, j'ai l'impression les membres de ce forum semble ne pas trop aimer le python


Vouloir supprimer le c c'est supprimer tous ces "cousins" (Python, PHP...etc), beaucoup de langages de script sont fais en C.

[Uther]

J'aimerais bien savoir qui t'a mis 3 down et surtout pourquoi

Personnellement je l'ai fait pour un mix de ces raisons :
- Entre l'article et les réponses, des raisons il y en a, on peut ne pas les trouver suffisantes, mais elles existent.
- Il parle du C comme si c'était le seul langage valable pour le bas niveau alors que le Rust et le D en sont tout à fait capable.
- Il parle comme si on voulait faire disparaitre le C du jour au lendemain, ce qui est idiot. Il ne s'agit que de discuter des alternatives possibles pour les développements a venir.

Ça donne l'impression qu'il s'est focalisé sur un seul mot du titre, l'a mal interprété et lu le reste en diagonale.

Vouloir supprimer le c c'est supprimer tous ces "cousins" (Python, PHP...etc), beaucoup de langages de script sont fais en C.

Python n'a rien d'un cousin du C et malgré une ressemblance au niveau de la syntaxe, j'aurais du mal a classer PHP dans sa famille directe.

Si tu veux dire que les interpréteurs/VM de ces langages sont généralement fait en C, c'est vrai. Mais ça n'a rien d'obligatoire. Il y a des implémentations dans d'autre langages. Des interpréteurs performants pour ces langages peuvent tout à fait être écrit en Rust ou D.

Si c'est parce qu'ils peuvent s'interfacer avec le C, alors sache que Rust et D peuvent utiliser l'ABI de C et donc en faire autant.

[RyzenOC]

Python n'a rien d'un cousin du C et malgré une ressemblance au niveau de la syntaxe, j'aurais du mal a classer PHP dans sa famille directe.

Si tu veux dire que les interpréteurs/VM de ces langages sont écrits généralement fait en C, c'est vrai. Mais ça n'a rien d'obligatoire. Il y a des implémentations dans d'autre langages. Des interpréteurs performants pour ces langages peuvent tout a fait être écris sans problème en Rust et D.

Oui mais faudrait tout recoder. Devoir tout recoder l'interpréteur Python et PHP, ainsi que tous les modules et pourquoi au final ? C VS Rust excuse moi mais pour moi les avantages ne vaut pas un tel investissement.

Remplacer, dans le sens recoder l'existent, non je ne suis pas d'accord avec l'article.

Remplacer, dans le sens, coder un nouveau projet et choisir un autre langage que le C, oui je suis d'accord.

[Uther]

Justement le problème c'est que tu as pris le mot "remplacer" hors contexte, et répond donc hors sujet. Il n'a bien évidement jamais été question dans l'article de recoder toute les applications C, ça serait idiot et même impossible.

[Médinoc]

Tient j'écrivais quelques lignes de C, et je me suis rendu compte à quelle point la généricité était chiante en C (void * / macro).

Pourquoi on voit pas mal de "C with classes" mais très peu (voir pas du tout) de "C with templates" ?

Le "C with classes" c'est une abomination, soit en code en C soit en C++... Mais du C avec des templates (pour répondre au manque évident du C dans ce domaine), pourquoi pas ?
Les templates (et les exceptions) sont les premiers composants de C++ à sauter quand un mélange de C/C++ est utilisé, pourquoi ?

Pour les exceptions c'est souvent l'argument du coût : un if toutes les deux lignes serait moins cher qu'un bloc try / catch par ci par là, mais les templates ?

Là, je suis parfaitement d'accord. Une grande faiblesse du C est qu'on ne peut pas, à moins de faire des usines à gaz basées sur des macros et de l'inclusion multiple de fichiers dépendant de ces macros, faire des conteneurs typés. Résultat, dès qu'on a besoin de quelque chose de plus élaboré qu'un tableau (liste chaînée, table de hachage etc.) soit un a droit un à code copié-collé avec les bons types (par vraiment de la généricité...) soit on réutilise un conteneur de void* et on a des casts partout, façon Java old-school ou .Net 1.0.

Dans un langage à bas niveau et typage statique comme le C, on a besoin de conteneurs fortement typés pour un code plus lisible et maintenable.

[grim7reaper]

car le C++ a absolument toutes les choses que les autre langages acquièrent au fil du temps : classes, héritage, héritage multiple, surcharge opérateurs, bas niveau, etc etc.

Tiens, depuis quand le C++ permet de faire du filtrage par motif ? D’avoir des type algébrique de données ? …
1C++ est un langage très riche, on est d‘accord. Mais il ne faut pas exagérer : il n’a pas « absolument toutes les choses que les autre langages acquièrent au fil du temps ».
Surtout que ce que tu cites c’est très orienté POO et que la POO ce n’est pas l’alpha ni l’omega de la programmation.

Devoir tout recoder l'interpréteur Python et PHP, ainsi que tous les modules et pourquoi au final ? C VS Rust excuse moi mais pour moi les avantages ne vaut pas un tel investissement.

Certains semblent penser le contraire : regarde PyPy (Python) et HHVM (PHP).
En plus tant que l‘interpréteur est compatible avec celui de référence, tu n’as pas à recoder tous les modules.

Résultat, dès qu'on a besoin de quelque chose de plus élaboré qu'un tableau (liste chaînée, table de hachage etc.) soit un a droit un à code copié-collé avec les bons types (par vraiment de la généricité...) soit on réutilise un conteneur de void* et on a des casts partout, façon Java old-school ou .Net 1.0.

Oui, ou se rabattre sur ce que tu dis dans la phrase précédente : faire « usines à gaz basées sur des macros et de l'inclusion multiple de fichiers dépendant de ces macros ».
Ce qui revient à faire son système de template à la main, et en moins bien…

[watchinofoye]

J'estime qu'il n'est pas encore venu le temps de dire adieu au langage C, encore moins pour un énième "remplaçant". Déjà parce qu'il n'en a pas besoin, comme beaucoup l'ont dit avant moi. Pourtant, même en tant que développeur C, j'admets qu'il n'est pas parfait. Tout seul, il a quelques inconvénients de manière générale et, selon l'usage que l'on souhaite en faire, sûrement davantage lorsqu'on le compare à d'autres langages.

Mais il y a une autre raison qui me fait penser que le C a encore de beaux jours devant lui. Il est tellement implanté que tous les autres langages déjà existants qui pourraient aisément le supplanter en termes de simplicité, d'élégance, d'optimisation, de performances ou de portabilité (et il y en a, on ne va pas se mentir) n'ont pas encore réussi à le détrôner.

Lorsqu'on effectue un développement, on a plus facilement tendance à se tourner vers le langage que l'on connaît le mieux, c'est normal. Si tant est que le langage en question est, bien évidemment, adapté à cet usage, ce qui est généralement le cas du C. Et quand vient la question du changement de langage, on trouve facilement une bonne raison de rester sur celui de départ, le plus souvent étant que ça ne vaut pas vraiment le coup/coût de changer.

Si un jour le C devait être remplacé, ce ne serait pas par un langage qui serait "seulement" plus efficace, plus portable, plus sûr, plus élégant, plus simple ou plus rapide. Il faudrait qu'il soit tout ou grande partie de cela, mais surtout qu'il soit autant voire davantage polyvalent, au point de faire largement préférer son enseignement dans quasiment toutes les formations et son usage dans quasiment tous les projets de développement.

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.

Le C reste une base (pour celles et ceux dont il est le langage de prédilection du moins) et les autres langages sont là surtout pour apporter quelque chose en plus pour un usage en particulier. Ils peuvent remplacer le C de manière ponctuelle, mais jamais de manière générale.