Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Une université canadienne propose C-for-All
Un projet open source d'extension du C ISO avec des fonctionnalités « modernes »

Le , par Patrick Ruiz

55PARTAGES

13  0 
Qui pour assurer la succession du langage C ? La question revient constamment au sein des communautés de développeurs. Par le passé, des noms de candidats ont fait l’objet de fuites ; depuis 2009 on évoque Go, un langage de programmation développé par Google et inspiré de C et Pascal. Mozilla Research aussi œuvre dans le cadre de cette mouvance et, depuis 2006, propose Rust, un langage qui permet de faire la programmation sous plusieurs paradigmes. Cette liste s’allonge avec C-for-All, une initiative conjointe du géant chinois Huawei et de l’université de Waterloo au Canada.

Le langage C a encore de beaux jours devant lui. Référence faite à un sondage paru sur cette plateforme en janvier de cette année, quatre raisons permettent de soutenir cette affirmation. Primo, n’en déplaise à ses détracteurs, C est encore largement utilisé. Secundo, il sera toujours nécessaire d’être à même de faire « joujou » de façon aisée avec le hardware et pour des tâches de ce type, le langage C continue de faire partie des premiers choix. Tertio, le langage est reconnu pour l’efficacité de son code source. Enfin, le langage se prête bien aux tâches de développement d’applications multiplateformes, ce à quoi les férus font souvent référence en parlant de portabilité.

Le langage C dispose d’un atout supplémentaire dans sa manche : il continue d’évoluer. C++ est né en 1983 pour répondre à ce besoin et connait des mises à jour régulières : C++11, C++14 puis C++17, des révisions qui ont respectivement vu le jour en 2011, 2014 et 2017. Il faudra désormais compter avec C-for-All dont l’université de Waterloo a publié la liste des extensions qui en font un C ISO qui continuera de traverser les âges.


C-for-All propose la gestion des exceptions comme extension à l’ISO C. La fonctionnalité dérive d’une thèse de génie informatique de 2017.

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
exception_t E {};                              // exception type
void f(...) {
	... throw E{}; ...                          // termination
	... throwResume E{}; ...             // resumption
}
try {
	f(...);
} catch( E e ; boolean-predicate ) {                    // termination handler
	// recover and continue
} catchResume( E e ; boolean-predicate ) {      // resumption handler
	// repair and return
} finally {
	// always executed
}
La surcharge de routines, d’opérateurs, de variables et de symboles est également à prendre en compte dans les extensions proposées par C-for-All. La fonctionnalité dérive des travaux d’une thèse de génie informatique de 1989.

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// selection based on type and number of parameters
void f( void );                                // (1)
void f( char );                               // (2)
void f( int, double );                      // (3)
f();                                                // select (1)
f( 'a' );                                          // select (2)
f( 3, 5.2 );                                    // select (3)

// selection based on  type and number of returns
char f( int );                                  // (1)
double f( int );                              // (2)
[ int, double ] f( int );                    // (3)
char c = f( 3 );                              // select (1)
double d = f( 4 );                          // select (2)
[ int, double ] t = f( 5 );                 // select (3)
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
int ++?( int op );                            // unary prefix increment
int ?++( int op );                            // unary postfix increment
int ?+?( int op1, int op2 );             // binary plus
int ?<=?( int op1, int op2 );           // binary less than
int ?=?( int * op1, int op2 );           // binary assignment
int ?+=?( int * op1, int op2 );         // binary plus-assignment

struct S { int i, j; };
S ?+?( S op1, S op2 ) {                 // add two structures
	return (S){ op1.i + op2.i, op1.j + op2.j };
}
S s1 = { 1, 2 }, s2 = { 2, 3 }, s3;
s3 = s1 + s2;                                  // compute sum: s3 == { 2, 5 }
Code : Sélectionner tout
1
2
short int MAX = ...;   int MAX = ...;  double MAX = ...;
short int s = MAX;    int i = MAX;    double d = MAX;   // select MAX based on left-hand type
Cette liste d’extensions n’est pas exhaustive et intègre d’autres éléments dont on perçoit mal l’impact réel sur des problèmes auxquels les utilisateurs du langage C font face. Illustration avec les instructions fallthru et fallthrough qui, au regard du code, sont des équivalents de goto.

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
choose ( ... ) {
  case 3:
	if ( ... ) {
		... fallthru;  // goto case 4
	} else {
		...
	}
	// implicit break
  case 4:
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
choose ( ... ) {
  case 3:
	... fallthrough common;
  case 4:
	... fallthrough common;
  common: // below fallthrough at case level
	...	 // common code for cases 3 and 4
	// implicit break
  case 4:
Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
choose ( ... ) {
  case 3:
	choose ( ... ) {
	  case 4:
		for ( ... ) {
			... fallthru common; // multi-level transfer
		}
		...
	}
	...
  common: // below fallthrough at case-clause level
Quoi qu’il en soit, C-for-All fait bien partie du paysage des nombreux remplaçants ou extensions du langage C. En génie logiciel, chaque projet impose de porter son choix sur un langage particulier en raison de l’existence de fonctionnalités que d’autres n’offriront pas. À chacun donc de juger et d’intégrer ce dernier à son flux de travail en fonction de la pertinence.

Source

uWaterloo

Votre opinion

Que pensez-vous de C-for-All ?

Quelles sont d’après vous les extensions qui sont les bienvenues ?

Quelles sont celles qui n’ont aucun impact sur la productivité ? Pourquoi ?

Voir aussi

Quel avenir pour le langage C ? Un développeur expérimenté fait ses adieux au langage et livre ses inquiétudes quant à son avenir

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de codec_abc
Membre confirmé https://www.developpez.com
Le 25/03/2018 à 12:37
Ajouter des exceptions au langage C sans RAII, quelle bonne idée! Bonjour les crashs ou memory/ressources leak a tout va. Et le C est un des rares langages qu'il faut faire évoluer doucement. Pour moi le C est destiné aujourd'hui a des secteurs bien spécifiques ou sa simplicité apparente a plus de valeurs que sa productivité assez faible (en comparaison avec des langages de plus haut niveau). Bref non merci, laissez le C tel qu'il est.
8  1 
Avatar de koala01
Expert éminent sénior https://www.developpez.com
Le 26/03/2018 à 7:21
Salut,

Je crois que C doit, comme tout langage, évoluer ou risquer d'être de plus en plus "mis au rencart"...

Mais je crois aussi que nous aurions tout à perdre à essayer de le faire évoluer trop vite, car c'est aussi un langage qui n'a aucun précédent. Et pour cause: il est plus ou moins reconnu comme... le père (ou l'aïeul) de tous les autres.

De plus c'est aussi le langage (de troisième génération s'entend) qui propose à la base le niveau d'abstraction le plus bas: avec moins d'abstraction que C, on écrit en assembleur.

Et le fait est que l'on aura toujours besoin d'un langage à très faible niveau d'abstraction, ne serait-ce que parce que l'informatique est (très) loin de se limiter aux PC de plus en plus puissants, équipés de windows ou de linux!!! L'informatique, c'est aussi tout un tas de "micro puces" que l'on peut programmer dans "une certaine mesure", mais qui n'ont pas la joie d'être soutenue par un système d'exploitation digne de ce nom, ou qui n'ont pas l'occasion d'attendre qu'une machine virtuelle ait pris le relais.

Or, pour cette partie (certains parleront sans doute de niche) de l'informatique, sans le C (même si C++ peut -- dans une certaine mesure -- prendre le relais), on n'a plus rien, si ce n'est l'assembleur...

Alors, nous pourrions envisager que "quelqu'un" développe un langage avec des caractéristiques fort semblable au C, en évitant (si possible) certains de ses affres, et que ce "quelqu'un" en fasse dont à l'ANSI ou à l'ISO. Peut-on rêver, ce langage *** pourrait *** être considéré --y compris par les développeurs C les plus intransigeants -- comme le digne successeur de C.

A ceci près qu'il y a toute la base de code écrite en C qui est purement phénoménale, qu'il faudra sans doute encore maintenir pendant des années. Ce qui fait que, quel que soit la qualité de ce nouveau langage hypothétique, il risque malgré tout d'avoir du mal à se faire sa "place au soleil"
5  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 26/03/2018 à 14:01
Citation Envoyé par Patrick Ruiz Voir le message
quatre raisons permettent de soutenir cette affirmation. Primo, n’en déplaise à ses détracteurs, C est encore largement utilisé. Secundo, il sera toujours nécessaire d’être à même de faire « joujou » de façon aisée avec le hardware et pour des tâches de ce type, le langage C continue de faire partie des premiers choix. Tertio, le langage est reconnu pour l’efficacité de son code source. Enfin, le langage se prête bien aux tâches de développement d’applications multiplateformes, ce à quoi les férus font souvent référence en parlant de portabilité.
- Primo, En effet C est largement utilisé un peu partout dans l'industrie pour tout ce qui est du bas niveau, et c'est une référence dans le domaine universitaire a cause d'UNIX. C'est sa principale qualité comme sont plus gros défaut : il est utilisé dans des domaines très conservateurs, ce qui explique qu'il peine tant a évoluer.

- Secundo et Tertio, Il est vrai que le C est très efficace et adapté au bas niveau, mais ça n'est pas le seul a pouvoir faire ça, il y en a d'autres qui sont tout autant capable comme le C++, le Nim ou le Rust par exemple.

- Enfin en ce qui concerne la portabilité, il faut reconnaitre qu'il existe un compilateur C pour quasiment toutes les architectures de processeur existantes, et que aucun langage ne peut prétendre en faire autant.
Mais si on regarde strictement du point de vue des spécificités du langage, le C est loin d'être ce qui ce fait de mieux. Sa norme est volontairement imprécise. Pour faire un programme C vraiment portable, il faut faire très attention a ce que l'on fait car beaucoup de chose vont réagir différemment en fonction de la plateforme. Si le C a pu être portable c'est surtout grâce a la norme POSIX et beaucoup d'huile de coude.

Citation Envoyé par Patrick Ruiz Voir le message
Cette liste d’extensions n’est pas exhaustive et intègre d’autres éléments dont on perçoit mal l’impact réel sur des problèmes auxquels les utilisateurs du langage C font face. Illustration avec les instructions fallthru et fallthrough qui, au regard du code, sont des équivalents de goto.
Je suppose que le but de "fallthru", comme pour les blocs avec label, c'est justement de pouvoir traiter le goto, qui est connu comme pouvant être abusé en C, comme une fonctionnalité déprécié. Du coup il faut remplacer les cas ou son usage se justifie encore par des syntaxes spécifiques.

Citation Envoyé par codec_abc Voir le message
Ajouter des exceptions au langage C sans RAII, quelle bonne idée!
L'article ne le précise pas, mais il y a aussi des constructeurs/destructeur, dont potentiellement moyen de faire de la RAII, avec ce langage.

Citation Envoyé par Gugelhupf Voir le message
Je suis déçu des features proposés par C-for-All, je trouve les features d'import et de paradigme objet léger de C2 bien plus intéressants.
Pour moi C2 était bâtard, il est certes plus propre au niveau de ce qu'il propose, mais ça se faisait au dépend de la compatibilité avec le C. Et quitte a avoir une syntaxe incompatible autant aller voir du coté de Rust ou Nim qui proposent bien plus qu'une petite amélioration du C.

Pour le coup C-for-All réussi a garder une meilleure compatibilité avec la syntaxe C actuelle que ce que proposait C2. Même si certains choix ne ne convainquent pas vraiment, surtout au niveau de la syntaxe (on sent la contrainte de l'héritage du C), il y a des fonctionnalité intéressantes.

Citation Envoyé par koala01 Voir le message
Or, pour cette partie (certains parleront sans doute de niche) de l'informatique, sans le C (même si C++ peut -- dans une certaine mesure -- prendre le relais), on n'a plus rien, si ce n'est l'assembleur...
Non, il y a d'autre langages qui sont tout a fait capable d'en faire autant comme le C++, Nim ou Rust par exemple.

Citation Envoyé par koala01 Voir le message
A ceci près qu'il y a toute la base de code écrite en C qui est purement phénoménale, qu'il faudra sans doute encore maintenir pendant des années. Ce qui fait que, quel que soit la qualité de ce nouveau langage hypothétique, il risque malgré tout d'avoir du mal à se faire sa "place au soleil"
C'est fou cette vision Highlander ("il ne peut en rester qu'un" des langages informatiques. A peu près tous les langages savent s'interfacer avec le C, particulièrement les langages bas niveau comme le C++/Nim/Rust. Il y a moyen d'introduire de nouveaux langages bas niveau sans avoir a tout réécrire.
3  0 
Avatar de Pyramidev
Expert confirmé https://www.developpez.com
Le 26/03/2018 à 20:38
Citation Envoyé par Neckara Voir le message
Citation Envoyé par Pyramidev Voir le message
C++ est riche et performant. Mais, même avec une telle richesse, il est plus compliqué qu'il ne devrait et contient plus de pièges qu'il ne devrait.
As-tu des exemples en tête ?
Voici quelques exemples de pièges qui ne viennent pas de la richesse du langage, mais d'erreurs de conceptions, soit héritées du langage C (à cause de la rétrocompatibilité), soit ajoutées en C++ :
  • Dans une classe, les variables membres sont accessibles même avant d'avoir été construites.
    Explication : Dans une classe MaClasse, si m_variable_membre_1 a été déclarée avant m_variable_membre_2, alors m_variable_membre_1 est initialisée avant m_variable_membre_2, quel que soit l'ordre dans lequel on les écrit dans le code du constructeur.
    Malgré cela, le code suivant compile :
    Code : Sélectionner tout
    1
    2
    3
    4
    5
    6
    MaClasse() : m_variable_membre_2{}, m_variable_membre_1{m_variable_membre_2} {}
    
    // Le code ci-dessus équivaut à :
    // MaClasse() : m_variable_membre_1{m_variable_membre_2}, m_variable_membre_2{} {}
    
    // Donc on construit m_variable_membre_1 en lui passant en argument une donnée non initialisée !!!
  • Quand un constructeur peut n'avoir qu'un seul paramètre, si on oublie le mot-clé explicit, alors on définit par mégarde une conversion implicite, ce qui affaiblit le typage. À la place, il aurait fallu un mot-clé implicit qu'on écrit uniquement si on décide consciemment de définir une conversion implicite.
  • Quand une classe Base a un destructeur public non virtuel et qu'on définit une classe dérivée Deriv, ça compile. Mais, si on fait un delete (directement ou indirectement) d'un Base* qui pointe vers un objet Deriv, le comportement est indéterminé. Il aurait été préférable qu'on ait une erreur de compilation quand on fait un delete sur un Base* si Base est dérivable. Pour cela, il aurait fallu que C++98 permette de distinguer une classe dérivable d'une classe non dérivable. Mais il a fallu attendre C++11 pour avoir le mot-clé final.
  • Par défaut, quand il le peut, le compilateur génère tout seul un constructeur de copie public et une affectation de copie publique, même si le destructeur a été redéfini, ce qui est un piège, parce que cela conduit souvent à libérer plusieurs fois la même ressource (exemple : double delete). Il aurait été préférable d'obliger l'utilisateur à les générer explicitement avec = default si le destructeur a été déclaré explicitement. Mais il a fallu attendre C++11 pour avoir = default. En pratique, ce piège concerne surtout ceux qui n'utilisent pas la règle du zéro, mais cela reste un piège.
  • Quand on fait un delete d'un pointeur vers un type incomplet (typiquement une classe déclarée en avance), ça compile, mais le destructeur de cette classe ne sera pas appelé. De même, si cette classe a un opérateur delete spécifique, celui-ci ne sera pas appelé. Ce piège ne touche que ceux qui utilisent delete au lieu de std::unique_ptr, dont l'instanciation du deleter provoque une erreur de compilation si le type de la donnée pointée est incomplet, mais ça reste un piège.
  • Dans un switch, oublier des case ne provoque aucune erreur de compilation, même si la valeur testée est un type énuméré. Ce problème est imposé par la rétrocompatibilité avec le langage C.
  • En C++, quand on initialise une variable globale x à partir d'une variable globale y d'une autre unité de compilation, on n'a pas de garantie que y est initialisé avant x. En D, par contre, l'ordre des initialisations statiques est déterminé par l'ordre d'import des modules (lien). En C++, ce piège touche surtout ceux qui abusent des variables globales, mais ça reste un piège.
  • Il y a trop de conversions implicites en booléens, ce qui affaiblit le typage. Si on combine ça avec le fait que l''opérateur = retourne une lvalue de même type que l'opérande de gauche au lieu de retourner void, cela démultiplie les risques d'erreurs, par exemple si on écrit par mégarde if(unEntier = unAutreEntier) au lieu de if(unEntier == unAutreEntier). C'est la faute du langage C.
  • >> sur un entier signé strictement négatif a un implementation defined behaviour. C'est encore une bêtise héritée du langage C.


Une partie des problèmes ci-dessus sont palliés par les avertissements du compilateur. Mais, parfois, on récupère du mauvais code pour lequel les nouveaux avertissements du compilateur sont noyés dans une masse d'avertissements déjà existants. D'autres fois, on travaille avec un compilateur qui n'est pas assez bon et omet certains avertissements.

Voici aussi quelques exemples de complexité inutile qui ralentissent l'apprentissage du langage :
  • Le mot-clé static a deux sens différents : durée de vie statique et lien interne. Il aurait fallu deux mot-clés différents : static et intern ou internal. En plus, static dans le sens de lien interne fait doublon avec les espaces de noms anonymes. Pour complexifier les choses, les variables globales constantes non volatiles non inlines ont un lien interne par défaut, alors que ce n'est pas le cas en C.
  • Il est possible de surcharger l'opérateur unaire &. Alors, en programmation par template, on utilise la bidouille std::adressof.
  • Il y a le problème du Most vexing parse.


Citation Envoyé par Neckara Voir le message
Vivement les modules.
C'est vrai que ce sera un grand pas en avant.

Citation Envoyé par Neckara Voir le message
De même, essayer d'avoir des syntaxes identiques, par exemple avoir du C++ avec une syntaxe de python serait pas mal et éviterait les problèmes d’accolades.
Personnellement, je pense qu'un langage idéal devrait laisser le choix entre les deux, comme le fait Haskell.
Par exemple, avec Haskell, voici deux bouts de code qui font la même chose : un avec des point-virgules et des accolades et un autre avec de l'indentation :
Code : Sélectionner tout
1
2
liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r
liftM2 f m1 m2 = do { x1 <- m1; x2 <- m2; return (f x1 x2) }
Code : Sélectionner tout
1
2
3
4
5
liftM2 :: (Monad m) => (a1 -> a2 -> r) -> m a1 -> m a2 -> m r
liftM2 f m1 m2 = do
    x1 <- m1
    x2 <- m2
    return (f x1 x2)
Edit 2018-03-26-20h52 : ajout d'un petit paragraphe sur les avertissements du compilateur.
Edit 2018-03-26-22h01 : correction de fautes de français.
3  0 
Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 03/04/2018 à 11:47
Citation Envoyé par TJ1985 Voir le message
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++.

Citation Envoyé par TJ1985 Voir le message
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.

Citation Envoyé par mdiam Voir le message
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.

Citation Envoyé par TJ1985 Voir le message
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.
3  0 
Avatar de Neckara
Expert éminent sénior https://www.developpez.com
Le 26/03/2018 à 9:32
Attention aux &nbsp;

Sinon, je détestes cette manie de vouloir réinventer la roue en permanence. Avoir 36 000 langages de programmation ne sert à rien.
Pourquoi ne pas utiliser/partir de ce qui existe déjà ? Pourquoi ne pas utiliser directement C++ ?

C'est comme pour générer de la documentation en JavaScript, on a 50 alternatives pour le faire, alors que Doxygen est utilisé pour les autres langages et marche très bien (et mieux que ces alternatives), au pire créer un plugin pour mieux gérer cela.

C'est comme les entreprises qui veulent héberger elles-même leurs propres services pour des raisons de sécurité... qui refont leur propre trucs ou choisissent des services obsolètes qui ne seront au final pas utilisées...

On déjà suffisamment de langages :
  • Python
  • C++
  • LaTeX
  • CSS
  • JSON
  • XML


Rien qu'avec cela on pourrait couvrir 99,99% des usages.

Regardez-moi ça, je parie que vous n'en connaissez même pas la grande majorité, et que la grande majorité est juste inutile.
2  0 
Avatar de Pyramidev
Expert confirmé https://www.developpez.com
Le 26/03/2018 à 14:20
Citation Envoyé par Neckara Voir le message
Sinon, je détestes cette manie de vouloir réinventer la roue en permanence. Avoir 36 000 langages de programmation ne sert à rien.
Pourquoi ne pas utiliser/partir de ce qui existe déjà ? Pourquoi ne pas utiliser directement C++ ?

[...]

On déjà suffisamment de langages :
  • Python
  • C++
  • LaTeX
  • CSS
  • JSON
  • XML


Rien qu'avec cela on pourrait couvrir 99,99% des usages.
Je suis d'accord pour dire qu'il y a trop de langages, mais ta liste est trop restreinte :
  • Python est accessible aux débutants et permet d'écrire du code concis, mais n'est pas performant. Cela conduit des chercheurs à coder deux fois la même chose : un prototype en Python puis un programme dans un langage plus performant, comme C++. On a donc besoin d'un langage avec les principaux avantages du Python, mais plus performant. Peut-être Julia.
  • C++ est riche et performant. Mais, même avec une telle richesse, il est plus compliqué qu'il ne devrait et contient plus de pièges qu'il ne devrait. En outre, il est lent à compiler, surtout s'il y a trop de code dans les fichiers d'entête, ce qui restreint l'utilisation des templates dans un gros projet. On a donc besoin d'un meilleur C++, beaucoup plus rapide à compiler, plus simple à apprendre et, tant qu'à faire, encore plus riche. Peut-être le langage D. D'ailleurs, je me demande si ce dernier peut aussi remplacer Julia.
  • Dans ta liste, je ne vois pas de langage qui supporte vraiment le paradigme fonctionnel comme Haskell. L'inconvénient de ce paradigme est qu'il est plus difficile à apprendre que la programmation orientée objet. Mais l'avantage est qu'il permet d'écrire du code beaucoup plus modulaire.


De manière générale, les langages au sommet du classement TIOBE ne sont pas assez bons. On a besoin de mieux.

Cela dit, les concepteurs de nouveaux langages ne devraient pas se contenter d'essayer de faire mieux que les langages au sommet du classement TIOBE. Ils devraient aussi, s'ils y arrivent, essayer de faire mieux que les langages moins connus qui ont du mal à s'imposer. Sinon, on augmente la liste des langages inutiles. Or, je pense que le C-for-All s'ajoute à cette liste.
2  0 
Avatar de Neckara
Expert éminent sénior https://www.developpez.com
Le 26/03/2018 à 15:31
Citation Envoyé par koala01 Voir le message
Mais, à part C++ (qui peut s'approcher énormément des cas d'utilisation de C, mais qui a quand même aussi un bon nombre d’incompatibilités avec lui), aucun de ceux que tu as cités ne peut prendre la "niche" du C.
Citation Envoyé par Aiekick Voir le message
Python, c++ ok
Latex, je sais pas
mais css ? un simple langage descriptif rien a voir avec de la programmation
Json, une simple structure de donnée
Xml langage descriptif, comme le html, plus une structure de donné qu'un langage de programmation.

rien a voir avec le c donc... mais je suppose que c'est voulu ?
Le C ne permet pas de tout faire, c'est bien pour cela que j'ai cité une liste de langages. On a besoin de plusieurs langages pour plusieurs utilisations, mais pas de plusieurs clones d'un même langage.

Du JSON/XML pour des données formatées, CSS pour tout ce qui est design, Python pour tout ce qui est scripts, C++ pour les perfs, LaTeX pour de la rédaction de documents.

Citation Envoyé par Pyramidev Voir le message
Je suis d'accord pour dire qu'il y a trop de langages, mais ta liste est trop restreinte
Ma liste est non-exhaustive, et bien sûr il faudrait regarder plus en détails.

D'ailleurs, il faudrait ajouter un langage de requête, e.g. SQL.

Citation Envoyé par Pyramidev Voir le message
Python est accessible aux débutants et permet d'écrire du code concis, mais n'est pas performant. Cela conduit des chercheurs à coder deux fois la même chose : un prototype en Python puis un programme dans un langage plus performant, comme C++.
Je dois avouer ne pas avoir beaucoup creusé sur point là.

À voir déjà si les outils d'optimisations ainsi que le fait de réduire la complexité algorithmique ne sont pas suffisant. Est-ce aussi des contraintes liées au langage en lui-même, ou à ses implémentations d'interpréteurs ?

Citation Envoyé par Pyramidev Voir le message
C++ est riche et performant. Mais, même avec une telle richesse, il est plus compliqué qu'il ne devrait et contient plus de pièges qu'il ne devrait.
As-tu des exemples en tête ?

Citation Envoyé par Pyramidev Voir le message
En outre, il est lent à compiler, surtout s'il y a trop de code dans les fichiers d'entête, ce qui restreint l'utilisation des templates dans un gros projet.
Vivement les modules.

Citation Envoyé par Pyramidev Voir le message
Dans ta liste, je ne vois pas de langage qui supporte vraiment le paradigme fonctionnel comme Haskell. L'inconvénient de ce paradigme est qu'il est plus difficile à apprendre que la programmation orientée objet. Mais l'avantage est qu'il permet d'écrire du code beaucoup plus modulaire.
On peut en effet l'ajouter si tu veux.

Citation Envoyé par Pyramidev Voir le message
Cela dit, les concepteurs de nouveaux langages ne devraient pas se contenter d'essayer de faire mieux que les langages au sommet du classement TIOBE. Ils devraient aussi, s'ils y arrivent, d'essayer de faire mieux que les langages moins connus qui ont du mal à s'imposer. Sinon, on augmente la liste des langages inutiles. Or, je pense que le C-for-All s'ajoute à cette liste.
Je suis tout à fait d'accord.

De même, essayer d'avoir des syntaxes identiques, par exemple avoir du C++ avec une syntaxe de python serait pas mal et éviterait les problèmes d’accolades.
Et même plutôt que de proposer des nouveaux langages, proposer des sucres syntaxiques qui serait convertis en un langage-cible (e.g. C++ avec syntaxe python -> C++).

Citation Envoyé par koala01 Voir le message
Et, surtout: même dans de si petites proportions, il faudrait combien de gars pour arriver à rendre la base de code (même en se limitant à celle qui est effectivement encore utilisée) compatible

Quand on voit que le seul bug de l'an deux mille a couté plus de 3 000 milliards de dollars pour être évité, combien couterait cette "petite mise à niveau" selon toi
Justement, quand on doit gérer que 5 ou 6 langages, c'est bien plus facile que si on devait en gérer 36 000.
2  0 
Avatar de gencoforlife
Futur Membre du Club https://www.developpez.com
Le 01/04/2018 à 17:49
Citation Envoyé par Neckara Voir le message

Regardez-moi ça, je parie que vous n'en connaissez même pas la grande majorité, et que la grande majorité est juste inutile.
C'est sûr, il y a des langages anecdotiques dans la liste : le brainfuck en est un bon exemple
2  0 
Avatar de Kannagi
Expert éminent https://www.developpez.com
Le 02/04/2018 à 14:42
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é !
2  0