Je suis d'accord en grande partie avec Bruno car il précise bien que le C ne disparaîtra pas mais je trouve qu'il omet un grand pan de l'industrie.
Pour rajouter un élément à la réflexion, dire que le langage C va être remplacé sans y mettre plus de bémol peut indiquer un manque de connaissance du marché global et des applications du langage C.
Pour celà, je vous laisse regarder les parts de marché/volumes des microcontrôleurs(uC) 8/16bits vs 32bits et même l'ensemble des microcontrôleurs vs processeurs (x86, server, etc) pour comprendre que le C n'est pas prêt de disparaître: c'est actuellement environ 50% embarqué vs processeurs pour PC/serveurs.
Le prix d'un uC 8/16bits étant < 1,ドル on ne voit pas pourquoi mettre des uC ou processeurs dont le coût des composants est > 10/15$ (car il faut rajouter de la ram, le pmic, du stockage...); sur des volumes de >10k pièces, celà ne se justifie pas. De plus, même avec des uC 32bits, on réduit le coût du produit en réduisant les tailles des mémoires, dont exit les langages qui ne génèrent pas du code ultra-optimisé, et ceux qui ne peuvent permettre les certifications de sécurité (e.g. SIL)
Et pour ces raisons (mais pas que), le langage C est encore le plus rencontré dans l'embarqué: plus rapide à développer qu'en assembleur et le footprint est plus réduit qu'avec des langages plus "évolués" (je préfère utiliser les termes "adaptés"). Du temps de mes études (fin des années 90), on nous disait que les processeurs/langage Java allaient envoyer le C aux oubliettes... ok, pourquoi pas... :D
Dans la plupart des machines à laver (les entrées/milieux de gamme), ce sont encore des uC 8/16bits, dans les capteurs des 8/16bits, dans les compteurs du 16bits, etc.
Par contre, dans d'autres applications, je suis assez d'accord avec le constat, la meilleur indication que j'ai à mon échelle est que j'ai appris successivement le perl, le python (et bientôt go?) pour générer du code sur les plateformes non-embarquée; Que j'embarque du linux plus rapidement/facilement sur les plateformes embarquées qui font de l'agrégation de données avant de les envoyer vers des serveurs... euh... ha oui, drivers toujours en C ;-)
[^] # Re: Aucun !
Posté par plr . En réponse au journal Go et Rust, lequel est le remplaçant du C ?. Évalué à 10. Dernière modification le 10 septembre 2018 à 16:12.
Je suis d'accord en grande partie avec Bruno car il précise bien que le C ne disparaîtra pas mais je trouve qu'il omet un grand pan de l'industrie.
Pour rajouter un élément à la réflexion, dire que le langage C va être remplacé sans y mettre plus de bémol peut indiquer un manque de connaissance du marché global et des applications du langage C.
Pour celà, je vous laisse regarder les parts de marché/volumes des microcontrôleurs(uC) 8/16bits vs 32bits et même l'ensemble des microcontrôleurs vs processeurs (x86, server, etc) pour comprendre que le C n'est pas prêt de disparaître: c'est actuellement environ 50% embarqué vs processeurs pour PC/serveurs.
Le prix d'un uC 8/16bits étant < 1,ドル on ne voit pas pourquoi mettre des uC ou processeurs dont le coût des composants est > 10/15$ (car il faut rajouter de la ram, le pmic, du stockage...); sur des volumes de >10k pièces, celà ne se justifie pas. De plus, même avec des uC 32bits, on réduit le coût du produit en réduisant les tailles des mémoires, dont exit les langages qui ne génèrent pas du code ultra-optimisé, et ceux qui ne peuvent permettre les certifications de sécurité (e.g. SIL)
Et pour ces raisons (mais pas que), le langage C est encore le plus rencontré dans l'embarqué: plus rapide à développer qu'en assembleur et le footprint est plus réduit qu'avec des langages plus "évolués" (je préfère utiliser les termes "adaptés"). Du temps de mes études (fin des années 90), on nous disait que les processeurs/langage Java allaient envoyer le C aux oubliettes... ok, pourquoi pas... :D
Dans la plupart des machines à laver (les entrées/milieux de gamme), ce sont encore des uC 8/16bits, dans les capteurs des 8/16bits, dans les compteurs du 16bits, etc.
Par contre, dans d'autres applications, je suis assez d'accord avec le constat, la meilleur indication que j'ai à mon échelle est que j'ai appris successivement le perl, le python (et bientôt go?) pour générer du code sur les plateformes non-embarquée; Que j'embarque du linux plus rapidement/facilement sur les plateformes embarquées qui font de l'agrégation de données avant de les envoyer vers des serveurs... euh... ha oui, drivers toujours en C ;-)