Discussion :

[souviron34]

Généralement un nouveau langage est née lorsqu'il y a eu des nouveaux concepts.
...
A l'avenir je ne doute pas que de nouveaux langages permettant de modéliser des concepts inédits voient le jour!

Exact.

Cependant "nouveau" ne veut pas dire "remplace" ou "remplacera"..


C'est la question posée, et l'étonnement est étonnant

Pour qu'un nouveau langage en supplante un autre, il faut qu'il fasse MIEUX pour le boulot auquel il est destiné, et qu'il soit AUSSI facile à apprendre...

Sinon, ce n'est qu'un nouveau langage parmi les cenatines d'autres..


Or, jusqu'à preuve du contraire, pour ce pourquoi il a été fait et ce à quoi il sert, aucun langage ne détrône C PARCE QUE il ne fait pas mieux, et qu'il est (plus) compliqué à apprendre.. (parce que par exemple les concepts et la manière de penser dovent être spéciales).


Donc dire "nouveau" ne revient pas du tout à dire "remplace"... ou même "pourrait remplacer"

C'est tout...

Donc les "étonnements" sont étonnants...

[psykokarl]

Lorsque dans un projet, la manière dont un programme s'exécute devient aussi importante, voir plus importante que la nature de la tache pour lequel le programme est conçu, tout ce qui est abstraction devient superflu voir nuisible. C'est ce qu'on pourrait qualifier d'informatique de précision.

C'est bien beau de parler de nouveaux langages et de dire que le c++ permet de faire la même chose que le C avec des features en plus. Si ces features ne fonctionne pas comme souhaité, on ne les utilisera pas.
On se retrouve à faire du C avec un autre langage. Autant rester sur du C/ASM.

Si les utilisateurs de C constatent des carences au niveau de leur langage, ben il est probable que le C connaisse une évolution. Enfin j'ai l'impression que pour les dev en C, les carences si il y en a, viennent d'avantage du développeur que du langage...

Bon point pour eux !

[SpiceGuid]

@souviron34
aucun langage parmi ceux proposés (BitC,Haskell,ATS,...) n'est plus performant que le C et tous sont plus difficiles à apprendre.

Par contre il font mieux en matière de sûreté et je trouve qu'il serait honnête de leur reconnaître au moins cette qualité, même si, apparemment, elle n'est pas primordiale à tes yeux.

[souviron34]

Par contre il font mieux en matière de sûreté et je trouve qu'il serait honnête de leur reconnaître au moins cette qualité, même si, apparemment, elle n'est pas primordiale à tes yeux.

je trouve ton assertion simplement fallacieuse : elle repose sur la sureté des LANGAGES, mais pas sur celle de la programmation...

La sureté est certes primordiale, ce dont je doute et qui est confirmé par l'article en référence et par les diverses inteventions sur ce thread c'est que beaucoup de gens aiment laisser la sécurité à un automatisme...

C'est comme la voture qui se conduit toute seule, le robot qui fait tout le ménage chez toi, etc etc.. Entre le tout automatique et ce que veulent les gens, il y a un monde que vous semblez oublier..


Que ce soit les éventuels ralentissements, les défauts (certains voient les GC comme des défauts), ou la maîtrise de ce qu'on fait, sans parler des compatibilités avec l'existant, il y a simplement toute une branche de personnes qui préfèrent ça..

Que ça vous ne convienne pas, c'est correct. Que l'on s'étonne que cela soit le cas c'est tout simplement étonnant...

Comme a en signature un membre ur ce site "le bug se situe toujours entre la chaise et le clavier"... Certains préfèrent avoir la maîtrise de ce qu'ils font...


(je suis par exemple beaucoup contre les GC, car j'estime que vérifier et savoir ce qu'on fait quand on maipule de la mémoire est essentiel dans ce métier).

[gangsoleil]

le compilateur [C] fait silence radio quand je lui dit que compiler en 64 bits, par contre si je compile en c++, je me fais insulter dans tous les sens, donc je ne plantais plus lamentablement en exécution, mais je ne pouvais plus compiler, je trouve ça quand même plus secure.

Donc tu as un mauvais compilateur C. Je suppose que tu n'en as essaye qu'un seul, et que tu n'es pas alle voir ce que dit la norme du langage sur le sujet.

Un compilateur n'est qu'un outil. Dans ton cas, c'est l'outil qui n'est pas adapte, pas le langage.

[patate_violente]

J'attendrais qu'on change les opérations fondamentales de mon processeur pour développer autrement qu'en C

[shenron666]

Une bibliothèque aussi large ( en comprenant la liste de code source non incluse dans la bibliothèque mais qu'on peux reprendre facilement )
Une communauté aussi large.
Un contrôle bas niveau, avec la possibilité d’écrire en ASM si besoin.
Pas de "mécanismes caches"
Des compilateurs au moins aussi bon que ceux de C
Une aussi grande portabilité

j'ajouterai la maturité du langage
et la lisibilité du code, comme l'a souligné Christuff

[Freem]

J'attendrais qu'on change les opérations fondamentales de mon processeur pour développer autrement qu'en C

Je ne vois pas le rapport... Le langage C est utilisé sur une multitude de processeurs et de PIC, et ça marche très bien.
C'est d'ailleurs l'intérêt numéro 1 du C: sa très grande portabilité (qui ne sacrifie pas la performance "accessoirement").

[Bktero]

J'attendrais qu'on change les opérations fondamentales de mon processeur pour développer autrement qu'en C

Je suis d'accord avec Freem, il y a une erreur dans cette phrase : patate_violente a écrit C au lieu d'ASM

[Wizard50]

aucun langage parmi ceux proposés (BitC,Haskell,ATS,...) n'est plus performant que le C et tous sont plus difficiles à apprendre.

Permettez moi de douter très largement de cette assertion : je suis d'accord sur le premier point, aucun des langages proposée n'est plus performant que le C. Mais de là a dire que tous sont plus difficile à apprendre que le C, c'est vraiment une question de point de vue. Je reprend encore l'exemple de l'Ocaml mais des étudiants de niveau Licence apprennent bien plus facilement l'Ocaml que le C et la raison est simple : leur esprit est généralement "neuf" et vierge de préjugé, ils n'ont aucun appriori sur les langages et sont aptes à recevoir tous concept de programmation, Ocaml comme C. Une fois passé le chapitre sur la récursivité qui est omniprésente en Ocaml, tout va bien alors que le chapitre sur les pointeurs en C peut devenir un problème éternel chez certains étudiants. Pour une personne ayant des années d'expériences en C, l'apprentissage d'un langage fonctionnel est forcément plus lent : perdre certaines habitudes et en adopter de nouvelles, notamment des concepts qui changent tout, n'est pas chose aisée, surtout si on y va a reculons.

[gangsoleil]

Permettez moi de douter très largement de cette assertion

des étudiants de niveau Licence apprennent bien plus facilement l'Ocaml que le C et la raison est simple : leur esprit est généralement "neuf" et vierge de préjugé, ils n'ont aucun appriori sur les langages et sont aptes à recevoir tous concept de programmation, Ocaml comme C.

Niveau L1 peut-etre, a condition de ne pas apprendre quelque chose d'autre avant ! J'ai commence par du Pascal en L1, et lorsque j'ai vu simultanement le C et l'OCaml en L3, j'ai eu beaucoup plus de mal a apprehender la conception en ML, qui me semble beaucoup moins logique

Une fois passé le chapitre sur la récursivité qui est omniprésente en Ocaml, tout va bien alors que le chapitre sur les pointeurs en C peut devenir un problème éternel chez certains étudiants.

La recursivite doit etre vue en cours d'algorithmique, et n'a rien de difficile a apprehender, que l'on comprenne le C ou le ML.
En revanche, il semble effectivement que la notion de pointeur soit assez complexe (bien que naturelle pour pas mal de personnes).

Pour une personne ayant des années d'expériences en C, l'apprentissage d'un langage fonctionnel est forcément plus lent : perdre certaines habitudes et en adopter de nouvelles, notamment des concepts qui changent tout, n'est pas chose aisée

C'est certain, mais ce genre de changement se voit tous les jours, C ou pas, ML ou pas.

[Bktero]

Une fois passé le chapitre sur la récursivité qui est omniprésente en Ocaml, tout va bien alors que le chapitre sur les pointeurs en C peut devenir un problème éternel chez certains étudiants.

Ca me rappelle ce message, posté par un professeur canadien de systèmes ordinés ^^ Les pointeurs sont un problème de compréhension de stockage de l'information et non d'algorithmie, comme l'est la récursivité.

[gerfaut83]

J'ai déjà entendu différents arguments, certains relèvent plus du troll, d'autres sont assez pragmatiques :

Au sujet du kernel Linux, je crois que le refus du C++ est motivé par l'impression générale des mainteneurs qui sous-entendent que la proportion de mauvais codeurs est beaucoup plus grande en C++ qu'en C, et qu'ouvrir la porte au C++, c'est également ouvrir la porte à des bibliothèques adhoc, jugées non fiables. Sur cet exemple, entre troll et réalisme, chacun se fera son idée

Un autre argument, bien plus pragmatique, m'a été avancé par spécialiste en développement de systèmes embarqués : généralement lorsqu'on a un projet sur le feu, on a déjà 6 mois de retard quand on reçoit le nouveau composant, et le seul compilateur fourni est le compilateur C. Si on veut coder en Ada, ce qui peut être vu comme 'mieux' dans l'absolu, il faut encore attendre 6 mois de plus pour que le compilateur passe toutes les épreuves de certification. Cette attente supplémentaire n'est généralement pas envisageable industriellement.

Après, du point de vu performances, quand on voit des bouts de x264 réécrits en assembleur, on se dit certains sont vraiment prêts à sacrifier la maintenabilité et la réutilisabilité au profit d'un gain de quelques cycles CPU

Habituellement, je suis assez en faveur des langages de haut niveau. Mais ça dépend du contexte... Et de manière générale, quelques routines optimisées et fiabilisées par des spécialistes du domaine pendant des années seront toujours difficile à battre, même avec le meilleur des langages et le meilleur des compilateurs.

[lilington]

Une fois passé le chapitre sur la récursivité qui est omniprésente en Ocaml, tout va bien alors que le chapitre sur les pointeurs en C peut devenir un problème éternel chez certains étudiants.

comme dit Bktero un peu plus haut, c'est pas le meme probleme. le C est un langage tres simple a apprendre moins que l'assembleur (oui j'ai bien dit ASM) certe mais simple. le probleme des pointeurs n'est pas un probleme de C mais un probleme... laisses moi dire d'"ordinateur". si tu ne comprends pas comment marche l'ordinateur alors tu dois tout simplement eviter tout programme qui demande de comprendre comment marche une machine et par ricocher de diriger vers des langages fait pour ecrire des programmes qui n'ont rien avoir avec l'architecture materielle.
et l'assembleur c'est la meme chose, pour preuve achete ART OF ASSEMBLY la premiere edition de preference et tu veras que les 90% du livre parle d'ordinateur et non d'assembleur. le langage en lui meme est d'une simpliciter deconcertante, c'est ce pour quoi on l'utilise qui est complique. les pointeurs c'est la meme chose, ce n'est pas le C qui rend l'utilisation du pointeur complique mais simplement le faite que le programmeur (qui n'aime pas les pointeurs) n'a pas envie de comprendre ce que c'est et espere que une entite parle a la machine a sa place. dans se cas pourquoi ecire en C?
C = simplicite du langage + demande de bagage et effort pour comprendre ce qu'on veut faire.

les langages plus Haut niveau que C = concentre toi sur ton resultat le compilo/VM/ou_autre se charge du reste.

le cas de C++ est un peu different. puis qu'il nous laisse autant de liberte que le C et de prison que Java, c'est au programmeur de choisir. au sujet du choix je vois pas trop l'interet d'ecrire un programme en C++ qui aurait pu/du etre ecrit en C.
ce dernier point est plus une question qu'une remarque.

[Wizard50]

On est bien d'accord que la récursivité est une question qui est d'abord vu en en cours d'algorithmique mais dans ce cas là, l'explication des pointeurs en C relève du cours d'architecture matérielle que tout bon étudiant en informatique a reçu ^^ Mais entre ce qu'un étudiant pense avoir compris dans un cours et son application concrète dans un autre cours ...

Ce que je voulais dire au final, c'est que l'Ocaml n'est de façon général pas forcément plus facile a apprendre que le C, mais ce langage n'est certainement pas plus dur à apprendre que le C.

[ManusDei]

Le C a une vision plus proche de l'électronique, là où l'OCAML a une vision plus proche des mathématiques (je dis bien mathématiques et pas arithmétique :p).

L'apprentissage de l'OCAML en L1 s'est fait sans douleur car les premiers concepts (même la récursivité) collaient bien avec mon niveau de maths, par contre quand on est passés aux concepts plus évolués (fonctions partielles etc...) là j'ai été largué.

Le passage au C a été bizarre, j'ai ramé avec quelques concepts de base (pointeurs, pointeurs de pointeurs, addition d'un int et d'un char), mais la suite est venue plus vite.

Ma conclusion, fonctionnel ou impératif, le plus simple a apprendre est celui qui correspond à la formation initiale de l'élève. Avec un bonus pour l'impératif si on est "vierge" de totue formation, car l'être humain fait les choses en séquence.

[Bktero]

De la poignée de langages que j'ai appris, je ne peux pas vraiment dire qu'il y en a eu des compliqués. Il y a toujours des choses auxquelles on a dû mal à se faire, de la souplesse déroutante (Python), des points contraignants d'écriture (les parenthèses en Scheme !), des problèmes de compréhension matérielles (VHDL), l'inefficacité du langage à écrire rapidement des programmes complexes (ASM), etc. Dans l'ensemble, je pense c'est avant tout une question de philosophies changeantes et c'est ça qui déroute.

En revanche, je connais un langage qui fait très peur à apprendre et qui, lui, est certainement TRÈS compliqué : http://en.wikipedia.org/wiki/APL_%28...ng_language%29

Personnellement, j'ai découvert le mot "Ocaml" dans cette conversation, je ne peux juger. C n'est pas forcément un langage simple de part sa gestion bas niveau de la mémoire et des adresses. souviron34 est un fanatique du C, ses messages étaient totalement en cohérence avec lui et son point de vue se comprend et est partagée par des gens.




Rendons-nous compte qu'on débat pour savoir si on peut échanger C contre Ocaml (ces noms peuvent être changés ^^), mais clairement on compare ce qui n'est pas comparable. Tous les langages ne sont pas dédiés à faire la même chose

[Freem]

comme dit Bktero un peu plus haut, c'est pas le meme probleme. le C est un langage tres simple a apprendre moins que l'assembleur (oui j'ai bien dit ASM) certe mais simple. le probleme des pointeurs n'est pas un probleme de C mais un probleme... laisses moi dire d'"ordinateur". si tu ne comprends pas comment marche l'ordinateur alors tu dois tout simplement eviter tout programme qui demande de comprendre comment marche une machine et par ricocher de diriger vers des langages fait pour ecrire des programmes qui n'ont rien avoir avec l'architecture materielle.
et l'assembleur c'est la meme chose, pour preuve achete ART OF ASSEMBLY la premiere edition de preference et tu veras que les 90% du livre parle d'ordinateur et non d'assembleur. le langage en lui meme est d'une simpliciter deconcertante, c'est ce pour quoi on l'utilise qui est complique. les pointeurs c'est la meme chose, ce n'est pas le C qui rend l'utilisation du pointeur complique mais simplement le faite que le programmeur (qui n'aime pas les pointeurs) n'a pas envie de comprendre ce que c'est et espere que une entite parle a la machine a sa place. dans se cas pourquoi ecire en C?
C = simplicite du langage + demande de bagage et effort pour comprendre ce qu'on veut faire.

les langages plus Haut niveau que C = concentre toi sur ton resultat le compilo/VM/ou_autre se charge du reste.

le cas de C++ est un peu different. puis qu'il nous laisse autant de liberte que le C et de prison que Java, c'est au programmeur de choisir. au sujet du choix je vois pas trop l'interet d'ecrire un programme en C++ qui aurait pu/du etre ecrit en C.
ce dernier point est plus une question qu'une remarque.

Pour moi, l'intérêt du C++ par rapport au C c'est qu'on est libre de choisir sa prison, comme tu dis, justement.
Et on peut même prendre les deux.
En fait, je dirais que le C++ permet de coder une application sur deux niveaux (je parle pas des marques de PQ multi-couches ou des rasoirs 50 lames, je parle au niveau gestion de la machine physique): le bas niveau, royaume du C, et d'ensuite appeler les classes qui gèrent la mémoire de façon efficace qu'on (ou un autre dev) a écrite pour des programmes de plus haut niveau, sans avoir a mixer les langages. Enfin, sauf en incrustant de l'assembleur pour les fanatiques du cycle, naturellement, mais on perd du coup la portabilité.

Le C++ peut ausse permettre, par exemple, d'utiliser les techniques de gestion des exceptions pour du code en C, histoire centraliser la gestion des erreurs (ce qui peut se faire avec les longjump et les signaux aussi si on veut rester en C pur).

Par contre, je trouve C++ assez radicalement différent de JAVA, du fait qu'on aie pas de garbage collector. Et il n'y en a juste pas besoin pour moi, grâce au mécanisme de destructeur.
En fait, si je devais ne citer qu'un seul avantage du C++ par rapport aux autres langages que je connais ou ai abordés (abordés à tout niveaux donc pas assez pour pas mal d'entre eux, hein : PHP, JAVA, C, ASM, QBasic, perl, prolog) je dirai:
mécanisme de destructeur.
C'est ce mécanisme qui permet de gérer la mémoire de façon semi automatique (pas aussi manuellement qu'en C mais mois automatiquement qu'en JAVA) qui représente à mes yeux la plus grosse force de C++.
Ca permet de se passer de VM et de GC (qui sont pour moi des outils inutiles, peut-être parce que j'ai d'abord appris à être près de la machine - asm et C ont été mes 2nd et 3eme langages - et que la gestion mémoire me semble naturelle?) tout en ayant pas à gérer la mémoire soi-même, exception faite d'un petit nombre de classes spécialisées dans ce point.

Mais il y a fort à parier que d'autres verront d'autres fonctionnalités comme étant le plus important...

Par contre, sur la simplicité de l'ASM, je te rejoins entièrement. Y'a pas plus simple: un opcode fait un truc, rien n'est caché. Les seuls trucs qui le rendent illisibles sont: 1)des mots-clés de 3 ou 4 lettres 2)un code extrêmement verbeux.
Mais un programme simple est juste vraiment, foncièrement, extrêmement simple. D'ailleurs, c'est marrant, mais en asm intel, il y a un truc que je me suis toujours demandé pourquoi ça n'existe pas (à ma connaissance) en C: SWAP

En revanche, je connais un langage qui fait très peur à apprendre et qui, lui, est certainement TRÈS compliqué : http://en.wikipedia.org/wiki/APL_%28...ng_language%29

Y'a pire: brainfuck. Enfin... plus simple que l'asm, mais ô combien plus illisible XD (genre il doit y avoir 8 "mots-clé" au total...)

Au sujet des langages pas faits pour la même chose, je ne suis pas d'accord.
Je dirais, perso, que les paradigmes des langages ne sont pas adaptés à tous les programmes. Parce que pas mal de langages se marchent sur les pieds...
C# et JAVA en sont les plus beaux exemples pour moi.
Le truc qui change le plus entre eux, c'est la librairie standard, le "framework". C# sans .NET ou JAVA sans la pléthore d'API qui viens avec sont aussi pratiques à utiliser l'un que l'autre, à quelques détails près, éventuellement.

En revanche, le paradigme est ce qui fait qu'un langage deviens vraiment adapté, ou pas, à une application. Et les paradigmes sont nettement moins nombreux que les langages...

Et la, je pense qu'en effet certains paradigmes ne sont pas adaptés à certaines applications: l'objet pour dev des scripts, c'est débile, par exemple, parce qu'on passe plus de temps à concevoir un truc qu'autre chose.
Utiliser C en lieu et place de prolog pour faire du dev d'IA me semble aussi assez tiré par les cheveux (je viens de m'y mettre au prolog, et j'en vois la puissance et la facilité de lecture même si je pige pas encore très bien le paradigme)
Mais ce qui change dans ces cas la, ce n'est pas le langage (enfin, si, mais la n'est pas le plus important) c'est la façon de penser.

[Taurre]

Donc tu as un mauvais compilateur C. Je suppose que tu n'en as essaye qu'un seul, et que tu n'es pas alle voir ce que dit la norme du langage sur le sujet.

Un compilateur n'est qu'un outil. Dans ton cas, c'est l'outil qui n'est pas adapte, pas le langage.

En toute logique, une conversion d'un type pointeur vers un type entier est une conversion explicite sans quoi le compilateur envoie un avertissement (gcc le signal sans aucune option, c'est dire). Or, dans ce cas, le compilateur ne dira rien, peut importe les options utilisées puisqu'une conversion explicite suppose que le programmeur sait ce qu'il fait.

le code de base a peut être été mal fait, ce n'est pas le propos, le compilateur fait silence radio quand je lui dit que compiler en 64 bits, par contre si je compile en c++, je me fais insulter dans tous les sens, donc je ne plantais plus lamentablement en exécution, mais je ne pouvais plus compiler, je trouve ça quand même plus secure.

Dans le cas d'une conversion explicite, il me paraît évident de ne pas recevoir d'avertissement. C'est la logique même du C : "trust the programmer". Ce n'est que mon avis, mais pour moi une conversion explicite signifie "t'inquiète, je sais ce que je fais", je m'attends donc à ne recevoir aucun avertissement.

quant au c99, et là c'est un avis perso, si c'est pour avoir du c qui ressemble à du c++, autant faire du c++. mais ces types sont quand même bienvenue.

Chacun son opinion, mais personnellement je ne vois pas en quoi le C99 ressemble à du C++. Cette remarque est encore plus flagrante avec le C11.

[hl037]

Je trouve qu'il est dommage qu'on veuille toujours réinventer la roue en ajoutant encore de nouveau langage... Je rejoins un avis déjà exprimé : le C++, malgré certaines "peau de banane" (bien que personnellement, je n'en voie que très peu, et celles-ci sont très ciblé) ça reste le plus polyvalent : on bénéficie de toute la bibliothèque C, avec les avantages en terme de conception d'un orienté objet simple à utiliser, et sur lequel on est MAÎTRE de la mémoire, mieux : on deviens au fur et à mesure maître : le débutant va faire avec les mécanismes par défaut quand il va apprendre, puis une fois un peu à l'aise, il codera ses propres constructeurs/destructeurs puis arrivera un moment où il aura besoin peut-être de gérer toute la mémoire, quitte à passer par de l'ASM (certes, simple dans la gestion mais galère tout de me de piger un programme en assembleur avec tous les jumps etc.).

En fait, LE problème, ce sont les nouveaux cursus*: je suis étudiant en première année de licence info, et là, c'est le Java le premier langage qu'on apprend. Mais HEUREUSEMENT j'avais appris à programmer en C puis C++ avant... Un des problèmes cités de C et C++ est le mécanisme des pointeurs, mais pourquoi pose-t-il problème, c'est ça la question*! Je vais y répondre*: premièrement, parce que c'est une notion semblable aux références, (même niveau langage, Java et C++ utilise le même new), du coup, ils en oublient le fondamental*: quand on demande de la mémoire en C++, elle nous appartient, c'est donc à nous de dire "J'en ai plus besoin"... Pas ce stupide (oui, je le pense vraiment, même si ça ne fait qu'un an que je programme en Java (mais 6 en C)) Gerbage Collector qui fait tout pour nous... Personnellement, quand j'ai vu comment ça se passe en java, et qu'il a fallu que je programme mes premiers algo, voilà ce que je me suis dit*: "ok, en gros, faut faire un code dégueu"
...Après, ce n'est qu'une histoire de philosophie, mais comment faire un programme performant (ce qui est quand même un objectif fondamental dans la programmation d'OS) si on ne maîtrise pas ce qu'il y a derrière*?

Le C est irremplaçable pour la simple est bonne raison que c'est LE langage du... "libre", (dans tous les sens du terme^^) car rien n'est plus facile que d'utiliser une bibliothèque écrite en C depuis un autre langage (je pense notamment au Pascal qui a certaines similarités avec le C, et à bien d'autre, ainsi que directement en ASM) ...De même que le C++ bien qu'il faut faire un plus attention à certaines subtilités...
Ensuite, c'est (de mon point de vue personnel) LE langage le plus simple à apprendre (car l'assembleur a tout de même pas mal de mots clefs, puis on doit gérer les registres etc. bref très verbeux et un peu prise de tête, même si c'est ce qui est le proche de la machine, évidemment) parce que des mots clef simple et intuitif (pour peu qu'on ait un minimum de vocabulaire anglais ) un fonctionnement, mine de rien assez proche de l'assembleur.
Et enfin mon dernier argument*: GCC, porté sur (presque?) toute les plateforme
...Le C est LE langage utilisable partout*: du dernier super(hyper?)-calculateur hi-tech sortie a votre grille-pain... Pourquoi vouloir créer un nouveau langage pour le remplacer*? Si c'est une histoire de POO, la réponse est évidente*: C++. (et vue qu'il assure une quasi-compatibilité avec le C, ça ne pose pas de prob.)