Discussion :

[Kannagi]

Justement , heureusement que le C reste encore assez "basique" son but pour ma part reste aussi que faire un compilateur C doit rester accessible , "facile".

Néanmoins je ne comprend pas cette mode de vouloir améliorer le langage C , le C a pas mal de défaut , il me semble plus intelligent de partir sur des nouvelles bases (comme le Rust ) que d'essayer de faire un C amélioré !

[Pyramidev]

Julia permet aussi d'appeler manuellement le ramasse miette ou le désactiver : Base.gc() et Base.gc_enable

Merci pour l'info.

C'est dommage qu'il n'ait pas évolué il y a une vingtaine d'année vers un C-for-all avec de la surcharge, une gestion d'exception des bibliothèques décente (string, ...).

Ça, c'est le C++98, non ?

[Uther]

Pour moi C a toujours été une sorte d'assembleur compréhensible et portable, et je l'ai vu utilisé la plupart du temps dans ce contexte. Pour des fonctionnalités évoluées, C++ offre je crois à peu près tout ce dont on peut rêver. Sinon, pourquoi ne pas prendre un langage vraiment nouveau plutôt que de tordre C ? J'avais jeté un œil à Go par exemple...
Il ne faut pas oublier qu'un développeur est aussi sensé savoir écrire un code capable de bien se comporter même si le langage qu'il doit utiliser n'offre pas le dernier machin à la mode.

Sur ce point, je suis tout a fait d'accord. le problème des alternatives à C comme C2 ou C-for-all est qu'elles sont perdues entre l'envie de rester proche du C, dont la stabilité est une qualité autant qu'un défaut, et l'envie de vouloir offrir plus comme le fait déjà le C++.

Mais est-il aussi performant que C ?

Go peut remplacer C dans pas mal de situations, mais, comme Julia, il ne peut être considéré comme un langage avec des capacités système, notamment à cause de son ramasse miettes quasi-obligatoire.

Julia permet aussi d'appeler manuellement le ramasse miette ou le désactiver : Base.gc() et Base.gc_enable

Sauf que le langage Julia (comme pour le Go), n'a pas du tout été conçu pour marcher sans ramasse miette. Si tu désactives le ramasses miette, ton programme va consommer de plus en plus de mémoire jusqu'à en manquer. Désactiver le GC n'est faisable que pour les programmes à courte durée de vie dont on sait qu'il se termineront avant d'avoir utilisé trop de mémoire.

Et que la course au langage parfait est parfois un masque pour la paresse et/ou l'incompétence.

Par contre, là je ne suis pas d'accord. Aucun langage ne sera jamais parfait vu que les besoins de chacun sont différents, mais avoir un langage qui évite les erreurs est un gros plus.

Le développeur qui ne fait pas d'erreur est un mythe. Il suffit de regarder les release notes des correctifs des navigateurs, base de donnée, OS et autre logiciel très surveillés et donc pas développés par des amateurs incompétent. Au moins la moitié des failles auraient généralement pu être évitées avec des langages plus restrictif.

De plus un développeur est rarement seul donc quand on intervient sur une section de code qu'on a pas écrit soi même avoir des garanties sur le bon fonctionnement de certaines abstractions est une aide non négligeable.

[TJ1985]

Pour moi C a toujours été une sorte d'assembleur compréhensible et portable, et je l'ai vu utilisé la plupart du temps dans ce contexte. Pour des fonctionnalités évoluées, C++ offre je crois à peu près tout ce dont on peut rêver. Sinon, pourquoi ne pas prendre un langage vraiment nouveau plutôt que de tordre C ? J'avais jeté un œil à Go par exemple... Mais est-il aussi performant que C ?
Il ne faut pas oublier qu'un développeur est aussi sensé savoir écrire un code capable de bien se comporter même si le langage qu'il doit utiliser n'offre pas le dernier machin à la mode.
Et que la course au langage parfait est parfois un masque pour la paresse et/ou l'incompétence.