Discussion :

[Michael Guilloux]

C2 : un langage qui se présente comme une évolution de C
plus rapide, sans fichiers d'en-tête, avec système de build intégré et d'autres changements

Malgré ses 45 ans, le langage C a certainement encore de beaux jours devant lui, parce qu'il est déjà largement utilisé et qu'il y a des domaines qui restent encore sa chasse gardée, notamment l'embarqué et le développement d'applications où il est essentiel d'avoir du contrôle sur le matériel. N'empêche que certains essaient de se montrer comme un meilleur C. C'est le cas par exemple des langages D et Ritchie. Parmi ces langages, il y a également C2 qui est présenté par ses créateurs comme une évolution de C, plutôt qu'un remplaçant du langage de Dennis Ritchie.

« Le langage de programmation C existe depuis longtemps et est encore très utilisé de nos jours. Le noyau du langage est très solide, mais d'autres aspects montrent leurs limites avec le temps. C2 tente de moderniser ces parties, tout en gardant l'expérience de C. Il devrait être vu comme une évolution de C », est-il indiqué sur le site officiel du langage C2, en guise de philosophie du projet.

Cette philosophie a conduit l'équipe C2 aux objectifs de conception suivants :

• une vitesse de développement plus grande ;
• une vitesse d'exécution similaire, voire meilleure ;
• de meilleurs temps de compilation ;
• un système de build intégré ;
• une syntaxe plus stricte (plus facile pour le tooling) ;
• un excellent tooling (outil de formatage, outil graphique de refactorisation) ;
• une intégration facile avec les bibliothèques C ;
• un langage qui devrait être facile à apprendre pour les programmeurs en C ;
• un langage qui devrait aider à éviter les erreurs communes.

Essayant de positionner leur langage par rapport aux langages de programmation actuels, l'équipe derrière C2 explique qu'il y a eu une tendance vers davantage d'abstractions de plus haut niveau, dans l'évolution des langages au fil du temps. « Java et C# reflètent particulièrement cette tendance. Pour les langages de niveau système, D et Rust se sont éloignés de cette tendance, pour fournir de meilleures performances et un meilleur contrôle », dit-elle. Avant d'ajouter que « pour un langage de niveau système, les fonctionnalités offertes par C++, D et Rust sont très appropriées. Cependant, ces langages ne semblent pas combler le vide pour les programmes de bas niveau/embarqués, car ils sont souvent encore programmés en C. C'est exactement ce vide que C2 tente de combler. »

C2 vise à être utilisé pour les problèmes où C est actuellement utilisé. Donc, les programmes de bas niveau comme les chargeurs d'amorçage (bootloaders), les noyaux, les pilotes et les outils de niveau système. Puisqu'il se veut une évolution de C, son équipe de développement a explicitement précisé que son objectif n'est pas d'introduire des fonctionnalités de niveau supérieur (comme l'orientation-objet, la récupération de mémoire, etc.) ou créer un langage complètement nouveau. Si C2 se présente comme une évolution de C, quels sont donc les changements par rapport à C ?

Ce qu'il faut savoir parmi les principales différences entre C et C2, c'est qu'il n'y a aucun fichier d'en-tête dans C2. C2 utilise en effet une approche dite moderne pour l'utilisation de symboles externes. Il n'y a qu'un seul type de fichiers, les fichiers source .c2. Pour remplacer #include, il existe une instruction d'importation. Tout le code source est également divisé en modules.

C2 vient en plus avec un système de build intégré. L'intégration du système de build dans le compilateur peut sembler restrictive, mais d'après les développeurs du langage, cela permet en réalité de nombreuses améliorations. L'une des fonctionnalités offertes par le système de build intégré est la compilation par cible (pas par fichier). Traditionnellement, les programmes C sont compilés par fichier, c'est-à-dire que chaque fichier est d'abord transformé en module LLVM. Mais en C2, le développeur peut choisir entre deux modes : le mode multimodule et le mode module unique. En mode multimodule (par défaut), tous les fichiers source d'un même module C2 sont transformés en un seul module LLVM. Le mode module unique quant à lui vise à permettre encore plus d'optimisation, car C2 convertit tous les fichiers source en un seul module LLVM, permettant une LTO (link-time optimization ou optimisation à l'édition des liens) complète.

Compilation (par fichier) avec C


Compilation avec C2 : mode multimodule (par défaut)


Compilation avec C2 : mode module unique

C2 fournit aussi les types primitifs prédéfinis suivants : bool ; i8, i16, i32, i64 ; u8, u16, u32, u64 ; f32, f64 ; et char (égal à i8). Les types int et float par défaut ont été supprimés avec les modificateurs de type short, long, signed ou unsigned. La macro NULL a aussi été remplacée par le mot-clé nil.

Une autre différence entre C et C2 est que C2 introduit une syntaxe de type uniforme. L'équipe derrière C2 estime en effet que les définitions de type en C sont parfois difficiles à lire. Aussi la syntaxe est un peu bizarre avec le typedef. Pour cela, C2 fournit une syntaxe uniforme pour définir de nouveaux types. Entre autres différences entre les deux langages, on peut encore noter des diagnostics plus stricts, les attributs, un tooling et des fonctionnalités spéciales dans C2. Les changements par rapport à C sont plus détaillés dans la documentation officielle de C2.

Cela dit, pourquoi donc choisir C2 par rapport C ? La réponse à cette question, d'après les créateurs de C2, se trouve dans les avantages que présente leur langage :

• un développement plus rapide. Leurs tests auraient en effet montré une diminution d'environ 30 % du temps de développement avec C2 ;
• un accès facile à des fonctionnalités telles que LTO (link-time optimization) ;
• de meilleurs diagnostics (ce qui, encore une fois, accélère le développement) ; et
• un contrôle plus facile de l'architecture avec c2reto.

Source : C2lang

Et vous ?

Que pensez-vous des objectifs du langage C2 ?
Croyez-vous qu'il fera une bonne alternative à C ? Pourquoi ?

Voir aussi :

Pourquoi les langages C et C++ auraient-ils encore de nombreuses années devant eux ? Donnez votre avis
Index TIOBE : C sacré langage de programmation de l'année 2017, Python enregistre encore la plus forte progression annuelle sur PYPL
Quel langage pourrait remplacer C ? Après avoir comparé Go, Rust et D, le choix d'Andrei Alexandrescu se porte sur D

[Matthieu76]

Bof, je sais pas trop quoi en penser ... Je trouve que c'est beaucoup pour pas apporter grand-chose.

Personnellement, je pense qu'il y a trop de language de programmation. Après ça sera quoi, le C++2 ???

[transgohan]

Je reste très sceptique...
Cela ne semble pas apporter grand chose, de plus quand je vois qu'ils annoncent 30% de gain de temps de codage alors que l'exemple hello world :

Code :

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

1
2
3
4
5
6
7
8
module hello_world;
 
import stdio as io;
 
func i32 main(i32 argc, char*[] argv) {
    io.printf("Hello World!\n");
    return 0;
}

Comporte plus de mot clé qu'un programme codé en C... On a envie de leur demander un compte rendu exhaustif de leurs tests...
Parce que personnellement je mettrai forcément plus de temps à écrire ce code que le même en C, c'est physique...

[Taserface]

Je reste très sceptique...
Cela ne semble pas apporter grand chose, de plus quand je vois qu'ils annoncent 30% de gain de temps de codage alors que l'exemple hello world :

Code :

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

1
2
3
4
5
6
7
8
module hello_world;
 
import stdio as io;
 
func i32 main(i32 argc, char*[] argv) {
    io.printf("Hello World!\n");
    return 0;
}

Comporte plus de mot clé qu'un programme codé en C... On a envie de leur demander un compte rendu exhaustif de leurs tests...
Parce que personnellement je mettrai forcément plus de temps à écrire ce code que le même en C, c'est physique...

Voici l'exemple 5 lignes contre 6

Code :

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

1
2
3
4
5
#include <stdio.h>
int main(int argc, char* argv[]){
	printf("Hello Word\n");
	return 0;
}

[transgohan]

Voici l'exemple 5 lignes contre 6

Va falloir détailler un peu ton argumentation car je peux aussi écrire des phrases (ou des lignes de code) sans jamais retourner à la ligne et ainsi obtenir moins de ligne qu'un autre.
Ce n'est pas le nombre de ligne que je ciblais dans mon commentaire mais la verbosité.

Code :

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

1
2
#include <stdio.h>
int main(int argc, char* argv[]){printf("Hello Word\n");return 0;}

Et hop 2 lignes contre 6 !

[Uther]

Je pense pas que le nombre de mot clé a taper ait la moindre incidence sur la vitesse de codage : on passe généralement bien plus de temps a lire et réfléchir au code qu'à le taper.
Avoir un code clair et bien structuré fait gagner bien plus de temps que les fractions de secondes utilisées a saisir des mots clé.

[Taserface]

Va falloir détailler un peu ton argumentation car je peux aussi écrire des phrases (ou des lignes de code) sans jamais retourner à la ligne et ainsi obtenir moins de ligne qu'un autre.
Ce n'est pas le nombre de ligne que je ciblais dans mon commentaire mais la verbosité.

Code :

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

1
2
#include <stdio.h>
int main(int argc, char* argv[]){printf("Hello Word\n");return 0;}

Et hop 2 lignes contre 6 !

Là n'est pas ce que je veux dire pour afficher un "Hello World" on a besoin que de l'import de la bibliothèque stdio.h or dans l'exemple fourni avec le C2 on a une déclaration de module(que je ne connais pas) et un import de bibliothèque je pense un message et un return alors qu'en C un include un affichage et un return.
Ceci étant dit je pense que ce langage n'a pas lieu d'être on a vu plusieurs langages dérivés du C et apporter d'autres paradigmes de programmation mais aucun n'a su le remplacer.
Un autre paradigme, un nouveau concept peut être discutable mais la version amélioré du C reste C++

[grunk]

Après ça sera quoi, le C++2 ???

C++20


Le "problème" de C c'est qu'il évolue très doucement. Une spec en 99 , une en 2011 , je comprend que si on commence un projet en 2018 , travaillé avec un spec d'il y'a 7 ans peu être frustrant.
C++ de son coté à un rythme de màj de 3 ans (11,14,17,20,...) qui apporte à chaque fois des évolutions bienvenues

[MikeRowSoft]

Le "problème" de C c'est qu'il évolue très doucement. Une spec en 99 , une en 2011 , je comprend que si on commence un projet en 2018 , travaillé avec un spec d'il y'a 7 ans peu être frustrant.
C++ de son coté à un rythme de màj de 3 ans (11,14,17,20,...) qui apporte à chaque fois des évolutions bienvenues

Comme tu semble vraiment bien t'y connaitre, je me permet de te poser une question qui me tracasse depuis quelque temps et pour laquelle je n'ai pas vraiment envie de fouiller sur Internet.

Question E.D.I. , des changements ont-ils été nécessaires lors de " l'évolution " du compilateur ?

[Kannagi]

Je doute que le langage C sera remplacé , encore une fois concurrencer le C veut dire vouloir concurrencer toutes les plateformes qu'ils visent (et ça doit être le seul qui vise effectivement tout les CPU existants ) , les lib et tout le code fourni jusqu’à présent chose très peu probable que C2 va être une alternative sérieuse.
Surtout que le C est utilisé sur des programmes très spécifiques , qui code une GUI en C ? presque personne x)
Qui va le faire donc en C2 ? Ben presque personne xD

Par contre un truc ou il risque pas de concurrencer le C , c'est dans un langage portable et performant (et je me demande vraiment si les concepteurs du langages ont réfléchi mûrement a leur décisions) :
"Les types int et float par défaut ont été supprimés"
Cool on va devoir remplacer manuellement tout nos i32 par i16 ou i8 suivant la plateforme

Le C est utilisé pour Linux , bon la c'est certain on va pas recodé les millions de lignes sur C2 (en plus il vise moins de plateforme que le compilo GCC ).
L'embarqué ? oui en utilise le C , mais aussi son remplaçant commence a être le C++.

De toute façon depuis l'arrivé de LLVM j'ai remarqué que de nombreux nouveau langages sont apparu :p

[hotcryx]

Cool on va devoir remplacer manuellement tout nos i32 par i16 ou i8 suivant la plateforme

Dans le genre "code bien pourri", il suffirait de les laisser typer sans préciser la taille int, short, long, bigint... (comme le fait le c).
C'est à la compilation que tout va se définir pour les tailles réelles en 8, 16, 32.
De cette manière, le code source ne change pas.

[grunk]

Question E.D.I. , des changements ont-ils été nécessaires lors de " l'évolution " du compilateur ?

Oui et non.
Disont que si ton compilo est à jour et que ton EDI est capable de travailler avec n'importe quel compilo tu n'as pas forcément besoin de mettre à jour ton EDI pour développer.
Dans les faits , même si le compilo n'est pas étroitement lié, l'EDI propose tout un tas de fonctionnalité (auto complétion , analyse statique , etc ...) qui ne sont compatible que jusqu'à une certaine version de C ou C++. Si tu veux utiliser une fonctionalité de C++17 dans un EDI qui ne supporte que C++11 par exemple tu aura des erreurs.

[nougatine999]

A la relecture des posts, on a l'air tous d'accord pour reconnaître que le C c'est la maman de tous les langages. Heu vive le C !

[MrKuja]

Je reste très sceptique...
Cela ne semble pas apporter grand chose, de plus quand je vois qu'ils annoncent 30% de gain de temps de codage alors que l'exemple hello world :

Code :

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

1
2
3
4
5
6
7
8
module hello_world;
 
import stdio as io;
 
func i32 main(i32 argc, char*[] argv) {
    io.printf("Hello World!\n");
    return 0;
}

Comporte plus de mot clé qu'un programme codé en C... On a envie de leur demander un compte rendu exhaustif de leurs tests...
Parce que personnellement je mettrai forcément plus de temps à écrire ce code que le même en C, c'est physique...

Pour voir son intérêt il ne faut pas se limiter à un simple hello world.
Si le C2 apporte plus de cohérence cognitive, quitte à ce que certains morceaux soit un poil plus verbeux sincèrement c'est mieux.

Le gain de la syntaxe et du système se verrait sur des cas concrets dépassant le hello world.

On verra dans le temps si ça prend. Ou non...

[huguesacker]

Je trouve que c'est une bonne nouvelle. Oui, il y a beaucoup de langages, mais le boulot c'est aussi de choisir celui qui est le plus adapté, et qui offre le plus d'outils et facilités de développement, pour ce qu'on veut faire.
Bien entendu il faut aussi des bibliothèques, mais rien que le fait d'avoir des importations de modules plutôt que des includes, sans parler de toutes les simplifications au niveau du préprocesseur et des types, c'est déjà formidable. En effet, u64 pour "unsigned long long" (par exemple), c'est quand même plus parlant, sans compter que les tailles int et long varient en fonction des machines et/ou compilateurs...
Cela fait plaisir de voir que des informaticiens continuent à réfléchir à comment améliorer nos outils de développement, je trouve.
Chez nous, on a décidé de l'essayer, et on va voir ce que cela va donner. C'est le genre d'initiatives à encourager.

[Uther]

A première vue je trouve qu'il y a de très bonnes choses mais le positionnement est mauvais.
Viser a se présenter en successeur du C peut être une bonne stratégie, mais dans ce cas là, il faudrait garder une compatibilité maximale avec l'existant, quitte a ce que ça soit sous forme dépréciée. Or là, de ce que je vois, des points basique de la syntaxe comme la déclaration des fonction et des types sont changés.

Si c'est pour avoir un langage incompatible, autant prendre un langage qui propose plus. Parce que des langage qui se posent en remplaçant de C pour la programmation bas niveau, et qui offrent tout ce que propose C2 et bien plus, ça se bouscule déjà au portillon avec notamment Rust, Jai ou Nim.

Je doute que le langage C sera remplacé , encore une fois concurrencer le C veut dire vouloir concurrencer toutes les plateformes qu'ils visent (et ça doit être le seul qui vise effectivement tout les CPU existants ) , les lib et tout le code fourni jusqu’à présent chose très peu probable que C2 va être une alternative sérieuse.

Pour les libs, à peu près tous les langages savent plus ou moins bien s'interfacer avec du C. Et comme le C2 se veut un langage de bas niveau, comme Rust et Nim, ça devrait se faire sans problème.
Et de ce que j'ai pu voir de la doc il est prévu de pouvoir générer du C ce qui résoudrait le problèmes des CPU non mainstream.

[Madmac]

Il n'y a pas beaucoup de chair sur l'os. L'introduction de nouveaux type de base va nous débarrassé de la gestion de la destruction de ces types. Un véritable progrès aurait été de nous débarrasser de ces corvées, même pour les type définies par l'utilisateur. Après tout, le principal handicap de ce langage est les fuites de mémoire qu'il produit.

D'un autre coté, le principal progrès n'est peut-être pas évident. Cette nouvelle représentation interne du langage va peut-être permettre de nouvelle optimisation. En C++, l'utilisation des directives d'optimisation ressemblent encore à une forme de loto. Espérons du progrès de ce coté

[LordMacharius]

Il n'y a pas beaucoup de chair sur l'os. L'introduction de nouveaux type de base va nous débarrassé de la gestion de la destruction de ces types. Un véritable progrès aurait été de nous débarrasser de ces corvées, même pour les type définies par l'utilisateur. Après tout, le principal handicap de ce langage est les fuites de mémoire qu'il produit.

Tu sembles encore une fois donner un défaut au C qui n'en n'est pas un. Les fuites mémoires du C sont le fait des développeurs et non pas du langage. Le C est là pour avoir le contrôle sur la mémoire justement et donc c'est de la responsabilité des développeurs de savoir la gérer. Si tu retires cette partie de ce que propose le C, l'intérêt est moins grand d'un coup pour ce langage.

Pour revenir sur le sujet, effectivement le manque de compatibilité avec l’existant est un vrai frein à son adoption en tant que successeur.

Je pense que chaque nouveau langage qui émerge de nos jours n'est qu'une surcouche du C avec une optimisation de la façon de le coder pour certains (comme le C2). On simplifie peut-être la forme mais on ne change pas le fond ..

Je suis tout à fait d'accord avec ce que tu dis nougatine, néanmoins je ne manquerais pas de me pencher dessus et de le tester pour un projet perso ou deux histoire de me faire une opinion plus construite.

[nougatine999]

Je pense que chaque nouveau langage qui émerge de nos jours n'est qu'une surcouche du C avec une optimisation de la façon de le coder pour certains (comme le C2). On simplifie peut-être la forme mais on ne change pas le fond ..

[mister3957]

Y'a un truc que je ne comprends pas, c'est que le C ou le C++ n'ont pas de gestionnaire de paquets.

En Java il y a Maven, .Net a NuGet, NodeJS a NPM, Python a PIP etc. et rien pour C/C++.

Pour moi si il doit y avoir une évolution dans l'écosystème C/C++ c'est pas "pouvoir programmer plus vite", mais un gestionnaire de paquets pour maîtriser les versions, les déploiement, les dépendances etc.

Il y a eu quelques projets pour ça, mais flop. Est-ce que c'est parce que ce n'est pas suivi / supporté ? Ou des contraintes particulières ?