Discussion :

[Amnael]

Bonsoir,

pardonnez cette interruption dans les débats, j'ai essayé de suivre tout ce qui s'est dit, mais je ne suis pas sûr d'avoir tout compris.
En espérant que mon avis d'étudiant en L3 puisse valoir quelque chose, je vais vous le livrer^^

1-Au sujet de l'indentation, je suis navré, mais moi, je trouve ça "normal" de nos jours que l'indentation soit une convention, et donc imaginer un code non indenté générer une erreur de compilation, et bien je dis oui à 200%
Il y a déjà des outils qui font ça, je me rappelle l'an dernier en java d'avoir vu quelques appli permettant de vérifier ce genre de convention du style

if(...)
{

était considéré comme une erreur car la forme if(...){ était attendu.

Trop souvent, on nous donne des projets à retaper avec des codes mal indentés, et franchement c'est infect.

Comment comparer, c'est comme si en ouvrant un bouquin, vous aviez tous les mots d'un index lexical sur la même ligne. Bah non, la convention c'est un mot suivi de toutes les pages où il apparaîtra, sinon la visibilité est nulle.

Donc ça c'est un bon point pour un langage, je pense que tous les langages devraient l'adopter de nos jours...



2- C'est là que je ne suis pas certains d'avoir compris; ce langage apporte quoi concrètement ? Le C est un langage bas niveau non ? Je veux dire c'est la base du système d'exploitation en général; donc pourquoi vouloir rajouter un langage par dessus, qui va en plus générer une sorte de pseudo code C derrière ?

Cela pourrait se justifier si ce nouveau langage permettait de faire des choses que le C ne permet pas de faire, mais si c'est le cas je ne suis pas certain de l'avoir compris dans vos précédents message.

Un autre point me tracasse, j'ai cru comprendre que chacun pourra définir sa propre version du langage en quelque sorte. C'est un peu comme si on revenait genre 30 ans en arrière à l'époque ou les conventions n'existaient pas non ? Imaginez si on avait ce genre de langage pour faire communiquer des réseaux entre eux ? Sa ne serrait pas un peu fumeux ?



A propos de l'inférence de type, rien à redire, c'est une des forces des langages fonctionnel et le voir appliquer sur une architecture semblable au C, ça pourrait être bien sympathique. Sauf que pour ça il faudra des règles, des opérateurs précis pour un type précis ou générique, sauf que, si comme je le pense chacun se fait sa propre version, alors ça sera vite infect, et ce qui pouvait être une force se transformera en foutoir sans nom.


De mon humble point de vue d'étudiant, ce n'est clairement pas un langage qui me donne envie, tout du moins de ce que je crois en avoir compris.

[foetus]

étudiant en L3 [...] Au sujet de l'indentation, je suis navré, mais moi, je trouve ça "normal" de nos jours que l'indentation soit une convention

Jeune et impétueux Prends du grade et reviens après.

Lorsque

• tu ne pourras pas installer ton IDE-éditeur magique dans ta nouvelle boîte
• les délais seront ultra-tendus (à moins que ton IDE-éditeur magique envoie grave du bois),
• tu devras soit maintenir du code et que le développeur a oublié les "coding conventions" (en python, on peut faire plusieurs lignes en 1 seule) (*) soit coder sur une machine sans environnement (**) (comme discuté dans ce fil: machine de production avec un vi ou un emacs)
• ton git/ svn est mal configuré et te transforme tous tes espaces en tabulations et que l'admin traine les pieds (<- ou un problème comme cela)

ou inversement, lorsque

• ton chef te demande de respecter les "coding conventions", même si par exemple la longueur de tes sources sont plus grandes (surtout pour le code qui tient en 1 ou 2 écrans)
• tu devras apprendre l'IDE-éditeur magique pourri de ta nouvelle boîte

* -> Le flacon peut-être très joli mais le contenu
** -> Et souvent ce genre d'interventions sont ultra-urgentes

[Logan Mauzaize]

Je pense que l'idée du langage est mal exprimée et qu'il s'agit d'enhanced les constructions et inventer des DSLs. Cette possibilité est une grande force des langages Groovy et Scala dans l'ecosystème Java.
Il est intéressant de noter que JetBrains propose de son côté Meta Programming System. Ce qui a donné notamment naissance à mbdeddr.

Je pense que l'ajout de "verbe" est une opportunité d'ajouter beaucoup de sens et lisibilité à notre code mais doit avoir un périmètre (scope) limité. Cela est nécessaire pour ne pas avoir de conflit avec le compilateur mais aussi le (re-)lecteur.
Au même titre qu'on conçoit de belles APIs que ce soit en termes de nommage mais aussi d'organisation des méthodes et des classes.



Concernant l'indentation : il est vrai qu'une bonne indentation est primordiale pour une bonne lisibilité. Néanmoins cela nécessite que les blancs n'aient pas de sémantique puisqu'il s'agit avant tout de présentation et que l'on puisse être libre en disposer. De plus, l'absence de sémantique des blancs me semble logique dans la mesure ils ne sont pas affichés (la plupart du temps).

Si je prends une configuration standard mon IDE et mon écran actuel, j'ai environ 115 caractères affichables par ligne. Il n'est pas rare d'avoir 4 niveaux d'indentation en Java, avec un affichage équivalent à 4 espaces cela me prend déjà 16 caractères et il en reste 99. Si je prends une méthode dont le nom (et les parenthèses) occupent 14 caractères appelées depuis une variable de 12 caractères, il reste plus que 72 caractères pour les paramètres. Soit 18 caractères pour 4 paramètres.
Et je compte pas les concaténations, les conditions un peu complexes, les chaînages de méthode (ex: Fluent API).

Il arrive donc assez fréquemment que mes instructions tiennent sur une plus d'une ligne et avoir la liberté de les présenter correctement est vitale pour la bonne visibilité.




Concernant le point-virgule : cela rejoint ce que je disais précédemment, ne pas donner de sémantique aux blancs (sauts de lignes inclus). Après je trouve ce point plus discutable mais cela devient INDISPENSABLE si vous travaillez dans des environnements où la taille des ressources est critique (ex: JavaScript pour le Web).
Oubliez de mettre ";" et passez dans le code dans un "minifier", je vous laisse apprécier les surprises qui vous attendent ...




Concernant l'ordre des verbes : c'est surtout que "if" et "for" ont été très mal choisi par rapport à leurs écritures respectives. "then" et "in" auraient été bien plus judicieux. Exemples qui auraient été plus pertinents :

Code :

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

1
2
3
a > 0 then a == 0
i in [ 0 .. n ] then print i
[ 0 .. n ] foreach i then print i

Concernant les déclarations de variable : il manque clairement un "marqueur" pour le distinguer d'une assignation. L'utilisation d'un "var", "let" ou "dim" me parait obligatoire.

[DonQuiche]

Donc ça c'est un bon point pour un langage, je pense que tous les langages devraient l'adopter de nos jours...

Bien entendu. On a simplement de nombreux programmeurs qui ont eu l'habitude de placer des accolades et des poins-virgule partout et de saborder leur canal carpien, et qui ont du mal à s'adapter à ce changement (ce que je trouve bienvenu pour ma part bien que j'ai passé l’essentiel de mon temps en syntaxe C).

Cela dit il faut que le langage prenne quelques précautions, pour déclarer invalide les cas où tabulations et espaces ont été mixés, voire remplacer automatiquement l'un par l'autre. Python ne fait pas ça. Il ne permet pas non plus de continuer un propos (statement) sur une seconde ligne en l'indentant en retrait de la première, ce qui serait utile.

2- C'est là que je ne suis pas certains d'avoir compris; ce langage apporte quoi concrètement ? Le C est un langage bas niveau non ? Je veux dire c'est la base du système d'exploitation en général; donc pourquoi vouloir rajouter un langage par dessus, qui va en plus générer une sorte de pseudo code C derrière ?

Tout le monde veut remplacer le langage C parce qu'il est improductif : c'est un langage des années 70 dont la sémantique est centrée sur la manipulation d'adresses mémoires, ce qui rend fastidieux l'écriture du moindre algo. Mais beaucoup de machines ne peuvent être programmées qu'en C parce que le fabricant ne fournit que ce langage et qu'il y a un assembleur spécifique.

Or le design des langages s'améliore d'une décennie à l'autre. A peu près dans l'ordre historique de "commoditisation" (partiel pour certaines) depuis le C :
* exceptions
* objets
* GC
* générateurs
* types paramétrés
* réification des types
* dispatch multiple
* acteurs
* coroutines
* lambdas et closures
* continuations de listes et foncteurs vectoriels (map/reduce/filter/linq)
* évaluation paresseuse
* types anonymes et n-uplets
* inférence de types
* types valeurs et références
* syntaxe Python
* contrats
* continuations délimitées (async/await)
* mémoisation auto
* types algébriques
* types de raffinage (adjectifs basés sur des pédicats)
* types dépendants (type X de l'instance Y : thisList.element)
* meilleur traitement des nulls (typage explicite en x? + safe navigation operator)
* métaprogrammation par étapes (le code contient du code qui modifie le code)
* programmation réactive
* transactions mémoire
* etc.

Bref, on pourrait ajouter "deux ou trois" trucs au C qui ne seraient pas de trop, loin s'en faut.

A propos de l'inférence de type, rien à redire, c'est une des forces des langages fonctionnel et le voir appliquer sur une architecture semblable au C, ça pourrait être bien sympathique.

Par inférence on entend plusieurs choses :
- Détection auto du type d'une variable (limité aux seules variables locales via leur assignation initiale, ou étendu aux paramètres et types de retour).
- Création auto de types, comme pour compiler un langage dynamique.

Le premier est utile notamment pour les grosses constructions paramétrées. Sauf que ce genre de constructions devient rapidement incompréhensible. Les langages fonctionnels regorgeant de celles-ci, l'inférence y est évidemment essentielle mais c'est un sparadrap sur une plaie purulente.

En-dehors des constructions paramétrées lourdingues, je pense qu'il vaut mieux expliciter le type des paramètres et du retour, sauf si le nom de la variable ne laisse aucun doute.


Quant à la création auto de types, les langages dynamiques nécessitent d'excellents IDE pour garder les gros projets gérables. C'est rarement le cas.

[imperio]

Oh mais j'ai déjà fait du debug sous vi, il y a longtemps. Aucun intérêt si ce n'est le destin qui le force (production...).

Qu'est-ce qui t'empêche de mapper les fichiers du serveur sur un autre pour bosser tranquillement ? Les programmes sshfs et consort ont été inventés pour ça après tout.

[Amnael]

Tout le monde veut remplacer le langage C parce qu'il est improductif : c'est un langage des années 70 dont la sémantique est centrée sur la manipulation d'adresses mémoires, ce qui rend fastidieux l'écriture du moindre algo. Mais beaucoup de machines ne peuvent être programmées qu'en C parce que le fabricant ne fournit que ce langage et qu'il y a un assembleur spécifique.

Dans ce cas là, il me semble qu'il serait plus intéressant d'essayer de faire évoluer le langage C (de la même façon qu'évolue les différentes versions de java) plutôt que de vouloir en recréer un de toute pièce.
Mais j'ai probablement tort à cause de mon manque d'expérience dans le milieu^^

[Logan Mauzaize]

Dans ce cas là, il me semble qu'il serait plus intéressant d'essayer de faire évoluer le langage C (de la même façon qu'évolue les différentes versions de java) plutôt que de vouloir en recréer un de toute pièce.
Mais j'ai probablement tort à cause de mon manque d'expérience dans le milieu^^

En fait c'est surtout de la naïveté et elle ne touche pas que les gens en manque d'expérience. Le problème touche à la "possession". Pour autant que je sache le langage est normé mais je ne sais qui en est responsable. Si on voulait faire évoluer le langage, il faudrait mettre en place une sorte de consortium.

Déjà la formation de ce groupe poserait certainement problème. Certains acteurs étant en compétition, voir en "guerre". Une fois tout ce beau monde réunit, il faut arriver à lister et filtrer une liste de "fonctionnalités" (le fond). Ce qui demanderait certainement déjà un deuxième lot de négociation. Ensuite viendrait un troisième lot de négociation concernant la forme. Ce qui aboutirait à une "proposition".
Laquelle serait soumis à validation auprès d'utilisateurs. Lesquels remettront tout en cause à partir de la première étape.

Je ne dis pas que cela est impossible. Cela a bien réussi à C++ mais regarde le temps que cela a pris.


De l'autre côté, tu as un gus qui sort un produit qui génère du code C. Juste des négociations en interne et si la mayonnaise prend c'est jackpot. En fait l'idéal avec ce type de solutions, c'est qu'elle peut inspirer et s'appuyer sur de futures normes. C'est donc très pratique

[FCWilk]

Le Julia n'était pas déjà fondé sur ce principe ?

[DonQuiche]

Dans ce cas là, il me semble qu'il serait plus intéressant d'essayer de faire évoluer le langage C (de la même façon qu'évolue les différentes versions de java) plutôt que de vouloir en recréer un de toute pièce.
Mais j'ai probablement tort à cause de mon manque d'expérience dans le milieu^^

En plus des aspects humains discutés par Logan, tu dois prendre en compte :

a) Compatibilité ascendante : les compilateur écrits il y a vingt ans pour une machine donnée ne seraient pas mis à jour.
b) Compatibilité descendante : les nouveaux compilateurs doivent compiler à l'identique les codes sources existants.
c) Les bases mêmes du C ne sont pas forcément celles qui sont désirables pour un langage moderne. Par exemple le préprocesseur est bon à jeter, et avec lui les inclusions et macros : trop de problèmes, trop lent.

[maske]

De l'autre côté, tu as un gus qui sort un produit qui génère du code C. Juste des négociations en interne et si la mayonnaise prend c'est jackpot. En fait l'idéal avec ce type de solutions, c'est qu'elle peut inspirer et s'appuyer sur de futures normes. C'est donc très pratique

C'est le cas de beaucoup de DSL qui produisent un code simple, efficace et même aussi lisible qu'un code fait à la main, à partir d'un langage «simplifié» - en fait dédié. Mais ça ne permet de faire que des choses très ciblées, DSL oblige, le faire sur l'ensemble d'un langage (C ou autre en fait...) c'est beaucoup, beaucoup plus ambitieux et il faut encore expliquer pourquoi et comment on le fait. La démarche ici, à moitié commerciale, ne me convainc pas vraiment.

Qu'est-ce qui t'empêche de mapper les fichiers du serveur sur un autre pour bosser tranquillement ? Les programmes sshfs et consort ont été inventés pour ça après tout.

Et bien dans certains cas la politique de sécurité de ta boite, dans d'autres la loi =)

[Matt_Houston]

c) Les bases mêmes du C ne sont pas forcément celles qui sont désirables pour un langage moderne. Par exemple le préprocesseur est bon à jeter, et avec lui les inclusions et macros : trop de problèmes, trop lent.

O RLY? J'aimerais bien savoir en quoi le préprocesseur est bon pour la casse...

Le C est un outil comme un autre, avant de décréter que c'est un outil de mauvaise qualité il faudrait s'assurer que c'est l'outil adapté à ce que l'on veut faire.

[souviron34]

O RLY? J'aimerais bien savoir en quoi le préprocesseur est bon pour la casse...

Le C est un outil comme un autre, avant de décréter que c'est un outil de mauvaise qualité il faudrait s'assurer que c'est l'outil adapté à ce que l'on veut faire.

c) Les bases mêmes du C ne sont pas forcément celles qui sont désirables pour un langage moderne. Par exemple le préprocesseur est bon à jeter, et avec lui les inclusions et macros : trop de problèmes, trop lent.

euh... compiler avec 250 Boost, c'est mieux ?? plus rapide ???

Quant à tes jugements de valeur :

Tout le monde veut remplacer le langage C parce qu'il est improductif : c'est un langage des années 70 dont la sémantique est centrée sur la manipulation d'adresses mémoires, ce qui rend fastidieux l'écriture du moindre algo

Je ne vois pas comment tu peux te permettre de dire ça...

Plusieurs sur ce forum, dont moi, écrivons des 100 000 lignes de code par an ..

Que ça ne plaise pas aux adeptes du tout cuit, des IDE, et autres générateurs de code, à la pensée pas forcément très claire, certes...

Mais la "fastidiosité" ou "l'improductivité" ne me semble pas être une caractéristique objective du C..

[DonQuiche]

Le C est un outil comme un autre, avant de décréter que c'est un outil de mauvaise qualité il faudrait s'assurer que c'est l'outil adapté à ce que l'on veut faire.

Le C en lui-même est un langage dépassé en termes de fonctionnalité et productivité.

Mais il reste souvent le meilleur choix pour le bas niveau pour des raisons liées à l'écosystème et parce que très peu de nouveaux langages se sont attaqués à cette niche. Ce qui est heureusement en train de changer (Rust et Julia, et d'autres pour les systèmes critiques).

O RLY? J'aimerais bien savoir en quoi le préprocesseur est bon pour la casse...

Le modèle de compilation du C/C++ est hérité du temps où les compilateurs n'avaient pas assez de mémoire pour y loger tout le code source.

Le résultat aujourd'hui ce sont des temps de compilation inutilement longs, des déclarations redondantes avec les définitions, la nécessité de jongler avec l'ordre d'inclusion, et des bugs insidieux lorsque ton code a un autre sens que celui que tu lis parce qu'il est inclus quelque part dans un fichier B après un autre fichier C.

C'est tout simplement obsolète. Pas différent ou mieux adapté à tel besoin.

Je ne vois pas comment tu peux te permettre de dire ça...

Plusieurs sur ce forum, dont moi, écrivons des 100 000 lignes de code par an ..

Et j'ai énuméré un peu plus haut trente raisons qui font qu'avec un langage moderne vous n'auriez eu besoin que de 30k lignes, avec trois fois moins de bogues et une complexité bien moindre.

C'est tout à fait objectif et ça se mesure en euros.

[souviron34]

Et j'ai énuméré un peu plus haut trente raisons qui font qu'avec un langage moderne vous n'auriez eu besoin que de 30k lignes, avec trois fois moins de bogues et une complexité bien moindre.

C'est tout à fait objectif et ça se mesure en euros.

Quand je vois les taux d'échecs aujourd'hui, et les rapports de bogue, et les budgets; et les grosseurs de package et!ou nombre de bibliothèques tierces nécessitées, je ne suis vraiment pas sûr que ta conclusion soit objective

[Matt_Houston]

Le C en lui-même est un langage dépassé en termes de fonctionnalité et productivité.

C'est pas cher à écrire mais ça ne le rend pas plus vrai.

Le modèle de compilation du C/C++ est hérité du temps où les compilateurs n'avaient pas assez de mémoire pour y loger tout le code source.

On cause de C ou de C++ ?

Le résultat aujourd'hui ce sont des temps de compilation inutilement longs,

Plus longs que Rust ?

des déclarations redondantes avec les définitions, la nécessité de jongler avec l'ordre d'inclusion, et des bugs insidieux lorsque ton code a un autre sens que celui que tu lis parce qu'il est inclus quelque part dans un fichier B après un autre fichier C.

Ça ne m'est jamais arrivé.

Et j'ai énuméré un peu plus haut trente raisons

Oui j'ai lu. Et j'ai ri. Un langage moderne a besoin d'un GC (how about no), d'objets , d'exceptions et doit faire respecter l'indentation sous peine de mort.

Non soyons sérieux, C n'a besoin que :

• d'une interface multithread : c'est fait ;
• d'un outil d'analyse mémoire : c'est fait, ça s'appelle valgrind ;
• d'un support natif de l'UTF-8 digne de ce nom : ça on l'attend toujours .

Perso je n'ai besoin de rien d'autre pour écrire du code, je pense pas trop dégueu.

qui font qu'avec un langage moderne vous n'auriez eu besoin que de 30k lignes, avec trois fois moins de bogues et une complexité bien moindre.

C'est tout à fait objectif et ça se mesure en euros.

Et mon code C s'exécute cinq fois plus vite : ça aussi on n'en sait rien mais comme c'est gratuit, hein.

[ChristianRoberge]

Je trouve un peu enfantin de compter les nombre de caractères d'un code surtout à l'ère de l'auto-complétation dans tous les compilateurs. Si cette affirmation serait vrai, l'APL règnerait en roi et maitre dans le monde informatique car du point de vue concision on n'a jamais fait mieux ni même approcher cette concision. LA concision n'est pas un critère d'après moi. Nous devrions parler plutôt de clarté du code...

[Amnael]

Je trouve un peu enfantin de compter les nombre de caractères d'un code surtout à l'ère de l'auto-complétation dans tous les compilateurs. Si cette affirmation serait vrai, l'APL règnerait en roi et maitre dans le monde informatique car du point de vue concision on n'a jamais fait mieux ni même approcher cette concision. LA concision n'est pas un critère d'après moi. Nous devrions parler plutôt de clarté du code...

Tous les codes concis ne sont peut être pas clair, en revanche je pense que tous les codes clairs sont concis.

C'est pas pour rien qu'il y a des conventions pour le nombre max de char dans une ligne de code (80 si je me souviens bien ?) et le nombre de ligne max dans une fonction. Il me semble qu'on considère qu'une fonction ne doit pas faire plus d'une page. Sinon il faut la découper en sous fonction. Mais j'ai l'impression que sur ce genre de choses tous le monde y va un peu à sa sauce et qu'au final, les conventions n'ont de conventions que leur nom...un peu comme avec le code de la route tant que tu te fais pas attraper par la patrouille...

[imperio]

Plus longs que Rust ?

Et encore ils se sont bien améliorés ! La dernière version a d'ailleurs une amélioration des temps de compilation de 20%. Je pense d'ailleurs que ça va encore s'améliorer dans les mois à venir quand ils auront fini le passage avec les types MIR et HIR.

[souviron34]

des déclarations redondantes avec les définitions,

Ca c'est une convention d'écriture, qui vient du C des origines et du Pascal, et dont on peut tout à fait se passer...

Je ne l'ai plus utilisée depuis 1990.... Je sais qu'elle a continué à être enseignée, mais ça n'est en rien attaché à la pratique du C..

La seule pratique courante est de faire un ".h" avec "extern" pour utilisation AILLEURS... Cela fait belle lurette que les programmeurs C (en tous cas ceux que je connais, ceux qui ont de la bouteille) ne mettent plus des déclarations redondantes si ça ne sert pas à l'extérieur... et c'est alors dans le ".h", et spécifié en "extern"...

et des bugs insidieux lorsque ton code a un autre sens que celui que tu lis parce qu'il est inclus quelque part dans un fichier B après un autre fichier C.

WTF ?????

Inclure du code dans un autre code est d'une mauvaise pratique absolue...

Et j'ai énuméré un peu plus haut trente raisons qui font qu'avec un langage moderne vous n'auriez eu besoin que de 30k lignes, avec trois fois moins de bogues et une complexité bien moindre.

Je ne répondrais pas point par point (ou peut-être que si...plus tard) mais Matt_Houston a bien commencé..


Je pense que tu n'as pas eu une bonne formation, ou de bons mentors..

[DonQuiche]

On cause de C ou de C++ ?

Le modèle de compilation est le même et C++ est aussi concerné par nombre de mes critiques mais laissons-le à part.

Plus longs que Rust ?

La compilation initiale de Rust est plus longue parce qu'il fait du travail en plus (analyse mémoire), sinon ce serait vingt fois plus rapide que le C.

En revanche la compilation incrémentale ne pose aucun problème avec Rust, contrairement au C où le préprocesseur gêne cette fonctionnalité.

Et j'ai ri. Un langage moderne a besoin d'un GC (how about no), d'objets , d'exceptions et doit faire respecter l'indentation sous peine de mort.

Je ne dis pas que ces trente fonctionnalités sont désirables pour un langage bas-niveau mais, oui, un GC serait par exemple une excellente idée.

Car un GC ça ne veut pas forcément dire un algorithme traçant, ça peut vouloir dire un algorithme qui utilise les mêmes méthodes que toi, à la Rust (libération déterministe notamment). Ça ne te fiche pas en rogne de passer des heures à faire ce qu'un fichu algorithme pourrait mieux faire que toi ?


Et, oui, les exceptions sont une excellente chose (même s'il faudrait pouvoir les désactiver dans certains cas). Elles posent problème en C parce que vous libérez les ressources manuellement, encore trop souvent.

L'autre problème des exceptions c'est qu'elles te permettent d'oublier que tu dois implémenter un rollback mais en pratique ça n'est vraiment un souci que pour les codes critiques, pour lesquels le C est de toute façon un piètre choix. La bonne solution pour ça ce sont des exceptions avec rollback automatique (et annotations des méthodes natives)


Enfin l'indentation plutôt que les accolades te permet simplement de ne pas bousiller ton canal carpien inutilement et de rendre ton code plus lisible. C'est une amélioration claire et nette.

Perso je n'ai besoin de rien d'autre pour écrire du code, je pense pas trop dégueu.

On peut aussi faire une maison avec seulement de la boue et du soleil, à vrai dire on a même fait de beaux monuments avec ça.

Et mon code C s'exécute cinq fois plus vite : ça aussi on n'en sait rien mais comme c'est gratuit, hein.

Et d'autres font aussi bien sans les mêmes problèmes.

Ca c'est une convention d'écriture, qui vient du C des origines et du Pascal, et dont on peut tout à fait se passer...

Si tu ne sépares pas ton code en headers et sources tu te retrouves avec des temps de compilation qui explosent.

Je pense que tu n'as pas eu une bonne formation, ou de bons mentors..

J'avais oublié cette morgue bien mal placée qui te caractérise.