Discussion :

[Bruno]

C3 : un langage de programmation système basé sur le C, permet un accès sécurisé aux tableaux,
les conteneurs de haut niveau et manipulation des chaînes de caractères

C3 le langage de type C qui se veut être une évolution du C, plutôt qu'un langage complètement nouveau. En tant qu'alternative dans la niche C/C++, il vise à être rapide et proche du standard.

Grâce à la compatibilité totale de l'ABI avec le C, il est possible de combiner C et C3 dans le même projet sans effort. Comme démonstration, vkQuake, le portage de Quake d'id Software utilisant Vulkan au lieu d'OpenGL pour le rendu, a été compilé avec une petite partie du code converti en C3 et compilé avec le compilateur c3c. vkQuake est basé sur les portages populaires QuakeSpasm et QuakeSpasm-Spiked et fait tourner tous les mods compatibles avec QuakeSpasm comme Arcane Dimensions.

Le C ne dispose que d'un support de bibliothèque très limité : il faut ajouter des chemins de recherche pour les fichiers d'en-tête, inclure certains fichiers d'en-tête et établir des liens avec des bibliothèques statiques ou dynamiques. Ces étapes sont toutes séparées. Si vous appelez des fonctions de bibliothèque sans les lier, vous pouvez avoir des références non définies.

C2 a corrigé ce problème en faisant de l'utilisation de la bibliothèque une chose totalement automatique. Vous utilisez la bibliothèque ou vous ne l'utilisez pas. De plus, C2 supporte les bibliothèques sources. Il s'agit de bibliothèques qui sont utilisées sous forme de source (=C2). Cela permet une meilleure intégration et optimisation, en particulier lors de l'utilisation de nombreuses fonctions "simples" qui ne font que renvoyer un membre d'une structure opaque, par exemple. Cela permet également aux développeurs d'organiser leurs archives de code d'une manière beaucoup plus facile.

C3 est un langage de programmation système basé sur le C. C'est une évolution du C permettant les mêmes paradigmes et conservant la même syntaxe dans la mesure du possible. C3 a commencé comme une extension du langage C2 par Bas van den Berg. Il a évolué de manière significative, non seulement au niveau de la syntaxe mais aussi en ce qui concerne la gestion des erreurs, les macros, les génériques et les chaînes de caractères.

Le code suivant montre des modules génériques

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
module stack <Type>;
// Above: the parameterized type is applied to the entire module.
 
struct Stack
{
    usize capacity;
    usize size;
    Type* elems;
}
 
// The type methods offers dot syntax calls,
// so this function can either be called 
// Stack.push(&my_stack, ...) or
// my_stack.push(...)
fn void Stack.push(Stack* this, Type element)
{
    if (this.capacity == this.size)
    {
        this.capacity *= 2;
        this.elems = mem::realloc(this.elems, Type.sizeof * this.capacity);
    }
    this.elems[this.size++] = element;
}
 
fn Type Stack.pop(Stack* this)
{
    assert(this.size > 0);
    return this.elems[--this.size];
}
 
fn bool Stack.empty(Stack* this)
{
    return !this.size;
}

Principes de conception

Le travail de conception de C3 est terminé, à part la mise au point de certains détails, comme l'asm en ligne. Au fur et à mesure que le travail sur la bibliothèque standard progresse, des modifications et des améliorations du langage seront apportées. L'instruction asm permet d'inclure des instructions d'assemblage directement dans le code C. Cela peut aider à maximiser les performances dans un code sensible au temps ou à accéder à des instructions d'assemblage qui ne sont pas facilement accessibles aux programmes C.

Installation

Installation sur Windows

• Visual Studio 17 2022 doit être installé ;
• Installer CMake ;
• Clonez le dépôt github de C3C : git clone "https://github.com/c3lang/c3c.git" ;
• Entrez dans le répertoire C3C cd c3c. ;
• Configurer le build CMake cmake -B build -G "Visual Studio 17 2022" -A x64 -DCMAKE_BUILD_TYPE=Release ;
• Construire : cmake --build build --config Release ;
• Vous devriez maintenant avoir le c3c.exe.
• Vous devriez maintenant avoir un exécutable c3c.

Installation sur Ubuntu 20.10

• Disposer d’un compilateur C qui gère C11 et un compilateur C++, comme GCC ou Clang. Git doit également être installé ;
• Installez CMake : sudo apt install cmake ;
• Installez LLVM 12 (ou supérieur : C3C supporte LLVM 12-15) : sudo apt-get install clang-12 zlib1g zlib1g-dev libllvm12 llvm-12 llvm-12-dev llvm-12-runtime liblld-12-dev liblld-12 ;
• Clonez le dépôt github de C3C : git clone "https://github.com/c3lang/c3c.git" ;
• Entrez dans le répertoire C3C cd c3c. ;
• Créez un répertoire de construction mkdir build ;
• Changez de répertoire pour le répertoire de construction cd build ;
• Configurer CMake build : cmake ...;
• Build : cmake --build .

Vous devriez maintenant avoir un exécutable c3c.

Inventé au début des années 1970 pour réécrire Unix, 50 ans après, le monde reste toujours alimenté par la programmation C. Et ce, malgré la prédominance des langages de niveau supérieur. Le langage de programmation C continue de donner du pouvoir au monde et il y a de nombreuses raisons de croire que la programmation en C restera active pendant longtemps.

Le compilateur C3 peut être trouvé ICI

Source : C3 designer

Et vous ?

Avez-vous connu la programmation C ?

Quel langage utilisez-vous aujourd'hui ? Pourquoi ?

Quelle appréciation faites-vous du langage C ?

C2 et C3 se présentent comme des évolutions du C. Que pensez vous de ces langages ?

Selon vous, quel avenir pour la programmation C ?

Voir aussi :

Microsoft célèbre les 20 ans de .NET, son Framework de développement, les dépôts .NET seraient dans le top 30 des projets open source à plus haute vélocité sur GitHub depuis 2017

Microsoft a publié la version stable de Visual Studio 2022 avec une nouvelle expérience de rechargement à chaud pour les applications natives C++, cette version est disponible uniquement en 64 bits

Un développeur publie un langage de programmation qui peut être traduit automatiquement en C, C++, C#, Java, JavaScript, etc., avec une traduction rapide et sans machine virtuelle

[Uther]

Je vais lui faire le même reproche qu'au C2 : il a le cul entre deux chaise. Il y a trop d'incompatibilités syntaxiques et techniques pour que son principal argument, à savoir la proximité avec le C, ne soit vraiment pertinent. Et du coup il se retrouve opposé à des langages comme Rust ou Zig qui proposent bien plus.

[Fleur en plastique]

Je suis d'accord avec Uther.

Vivement le C-4 pour faire sauter la baraque. Avec des ajouts syntaxiques nécessaires pour faciliter la vie, mais en conservant la totale compatibilité avec le C. Moi, ça me brancherait.

[Sve@r]

Mouais bof. C'est oublier complètement le but du C.

Le C a été conçu pour aller le plus vite possible. C'est son credo, son fondement. Pour atteindre ce but il est obligé de rester très bas niveau (donc une syntaxe peu évoluée nécessitant 150 instructions pour faire des trucs qui en prennent 15 dans d'autres langages comme Python, VB, Ruby, etc) et surtout il ne vérifie rien concernant la logique des instructions. Ce qui autorise le codeur à taper dans tab[100] d'un tableau de 10 éléments s'il en a envie (résultats à ses risques).
Tout ça on l'accepte. On accepte de se taper des trucs à rallonge, de relire 500 fois son code pour être certain qu'on ne dépasse pas, et de rien biter au code du copain parce qu'il n'a pas la même façon de gérer ses pointeurs que moi mais on a en retour un truc qui carbure. Bien entendu il faut savoir gérer et adapter son besoin. Le type qui prend du C pour créer un logiciel de comptabilité il n'a clairement rien compris.

Et là donc arrive des gus qui nous disent "écoutez les gars, on a inventé un langage aussi pourri que le C mais qui vous préviendra si vous dépassez la zone ; mais bon en retour il sera moins rapide évidemment puisqu'il doit checker chaque fois que vous tapez dans la zone" hé bien ces gars là ils n'ont rien compris au C ni à ceux qui font du C.
Si je fais du C c'est pour la vitesse, donc je veux la vitesse max et je suis suffisamment grand pour gérer tout seul mes zones mémoires. Et si la vitesse optimale ne m'intéresse pas plus que ça mais que je veux un langage plus confortable, plus sécuritaire, qui me permette par exemple d'agrandir un tableau en une instruction, d'associer et traiter n tableaux en parallèle ou de créer un T2 par compréhension de T1, avec des structures sympa comme des dictionnaires ou ensembles, etc alors je me tournerai vers un langage dédié à tout ça.

C'est la même remarque que Uther à propos du cul entre deux chaises, mais en plus détaillée.

[Pyramidev]

Ça m'étonnerait que C3 réussisse face à Rust.

Et là donc arrive des gus qui nous disent "écoutez les gars, on a inventé un langage aussi pourri que le C mais qui vous préviendra si vous dépassez la zone ; mais bon en retour il sera moins rapide évidemment puisqu'il doit checker chaque fois que vous tapez dans la zone" hé bien ces gars là ils n'ont rien compris au C ni à ceux qui font du C.

D'après la documentation de C3, si on le compile en mode release, alors l'accès à un tableau avec un indice hors limites est un comportement indéfini. C'est en mode "safe build" qu'il y aura un contrôle à l'exécution. Lis la page : http://www.c3-lang.org/undefinedbehaviour/

[abriotde]

Je vais lui faire le même reproche qu'au C2 : il a le cul entre deux chaise

Totalement vrai et en plus de ça il arrive après que Rust ait commencé à faire son trou. Pour qu'il perce il lui faudrait un argument enthousiasmant (Comme Rust) ou un soutiens majeur (Comme Go et Swift).

Pour qu'il ait vraiment une chance de percer il faudrait qu'il soit compatible à 99% avec le C existant et qu'il y apporte une sécurité supplémentaire réel pour attirer des grands entreprises à minima.

[abriotde]

Et là donc arrive des gus qui nous disent "écoutez les gars, on a inventé un langage aussi pourri que le C mais qui vous préviendra si vous dépassez la zone ; mais bon en retour il sera moins rapide évidemment puisqu'il doit checker chaque fois que vous tapez dans la zone" hé bien ces gars là ils n'ont rien compris au C ni à ceux qui font du C.
[...]

C'est la même remarque que Uther à propos du cul entre deux chaises, mais en plus détaillée.

Je suis d'accord sur le fait que l'on fait du C pour l'optimisation d'un point de vue vitesse. Il n'empêche que l'on ne fait pas du C pour que ça plante et que même en vérifiant et en maîtrisant ça arrive. Rust à prouvé que l'on pouvait faire aussi rapide que C, en beaucoup plus sécurisé. Evidemment que mettre une "VM" comme Go (compilé au sein du programme) ou Java (A part) pour faire les vérifications est un compromis qui ne remplacera jamais le C.

PS : Dans les autres langages aussi, ça plante quand tu accède au 100° élément alors que ton tableau en a que 10... La seul différence c'est qu'en C, ça ne plante pas toujours justement mais que le programme ne fait plus ce que tu veux et ça fini en segfault au bout d'un temps indéfini après avoir fait on ne sait trop quoi (Heureusement, l'OS veille)... Et ce "on ne sait trop quoi" est une faille de sécurité exploitable par les hackers...

[Sve@r]

PS : Dans les autres langages aussi, ça plante quand tu accède au 100° élément alors que ton tableau en a que 10...

C'est ce que je voulais dire quand je parlais d'un langage plus sécuritaire. Si je veux être tranquille parce que je sais que mon code justement plantera dans le cas où je me rate avec mes indices, je ne choisirai pas le C

[Uther]

Le C a été conçu pour aller le plus vite possible. C'est son credo, son fondement. Pour atteindre ce but il est obligé de rester très bas niveau (donc une syntaxe peu évoluée nécessitant 150 instructions pour faire des trucs qui en prennent 15 dans d'autres langages comme Python, VB, Ruby, etc) et surtout il ne vérifie rien concernant la logique des instructions. Ce qui autorise le codeur à taper dans tab[100] d'un tableau de 10 éléments s'il en a envie (résultats à ses risques).

C'est quand même un peu plus compliqué que ça : aujourd'hui le Rust peut atteindre des performances similaires au C sans recourir à des fonctionnalités au comportement potentiellement indéfinis (ou alors de manière très cadrée).
Les comportements dangereux du C, c'est surtout la conséquence du fait qu'il a été créé à une époque où les compilateurs ne pouvaient se permettre le niveau d'analyse et d'optimisation actuels, car ils tournaient sur des machines avec au mieux quelques Mo de mémoire et quelques Mhz de fréquence d'horloge. Les compilateurs actuels peuvent optimiser bien mieux sans forcément prendre autant de risque, par exemple en supprimant automatiquement les "bound check" inutiles.

C'est la même remarque que Uther à propos du cul entre deux chaises, mais en plus détaillée.

Je vais détailler mon propos car ma vision est quand même quelque peu différente.

Ce que les annonces des projets C2 et C3 laissaient supposer au premier abord, c'est qu'il visent quelque chose de similaire à ce que Microsoft avait esquissé avec le Checked C : une évolution du C qui resterait dans le cadre de la compatibilité ascendante, quitte à déprécier à terme certaines parties du langage. Ça pourrait tout à fait se faire sans impacter lourdement les performances. Je pense qu'il y a une niche intéressante à prendre sur ce segment.

Malheureusement, quand on regarde les détails, on constate qu'ils se sont plutôt positionné comme un langage alternatif, certes proche du C, mais tout de même assez différent pour nécessiter une réécriture du code, ce que le Zig ou le Rust font déjà depuis un moment en proposant bien plus en matière de fonctionnalités et de propreté (particulièrement Rust), et qu'ils sont eux capable de s’intégrer avec du C (particulièrement Zig).

[Fagus]

permet un accès sécurisé aux tableaux, les conteneurs de haut niveau et manipulation des chaînes de caractères

Juste sur ces points, il y a plein de lib qui ajoutent ce genre de choses au C, à tel point que je n'ai jamais compris pourquoi ce n'était pas ajouté dans la bibliothèque standard de C, histoire que ce soit bien écrit et normé une fois pour toutes.

Pour les autres ambitions, ça ressemble beaucoup à Zig (qui lui aussi vérifie les limites à la compilation voire à l'exécution si demandé).

Goto removed. Rationale: It is very difficult to make goto work well with defer and implicit unwrapping of optional results.

Rien que pour ça je reste en C, le dernier langage qui permet d'utiliser cette instruction immorale ;-)

[Aiekick]

franchement depuis que rust est arrivé, je me dit que le remplacant du c est dans la place, pourquoi vouloir encore faire des moutons a 3 ou 5 pattes.

[smarties]

Je rejoins ce que les autres disent.

RUST est trop implanté (M$, Amazon, Google, ..., devrait commencé à être intégré dans Linux, ...) et l'écosystème est très bien, il manque "juste" des bibliothèques natives RUST mais ça viendra avec le temps.

Je sais pas si dans les études supérieurs on enseigne toujours le C mais je crois que dans quelques années il pourrait y avoir du RUST au programme.

De toute façon pour qu'un lange soit utilisé, il faut une qu'il soit enseigné et beaucoup utilisé en entreprise ou en perso. Il y aura toujours quelques cas ou le un langage comme C3 sera utilisé mais ça va rester marginal et sera vite étouffé/oublié par des langages populaires.

[e-ric]

Hi all

En ce qui concerne les goto, Pascal le permet toujours également, ça peut servir mais avec parcimonie.



La question est : est-il pertinent de sortir un nouveau langage pour si peu de choses qui sont déjà couvertes par d'autres.
La coséquence de tout cela est d'augmenter l'entropie (façon polie e parler du bordel ambiant en informatique) et de disperser les efforts, il vaudrait mieux investir en améliorant les choses existantes.

Cdlt

[jbrosset]

Bonjour à tous,
J'ai appris l'informatique en 1981... c'est-à-dire à une époque où les moyens informatiques étaient extrêmement limités (processeur, mémoire...) et déjà je considérais C comme un mauvais langage par le peu de sécurité qu'il apportait.
Mon premier langage de prédilection a été Pascal qui évidemment était plus contraignant mais infiniment plus sûr.
J'ai appris et pratiqué d'autres langages impératifs comme Ada et j'en garde un souvenir ébloui pour la fiabilité des résultats obtenus : ah oui, c'était moins drôle de programmer qu'avec C parce que le compilateur trouvait souvent à redire, mais les messages d'erreurs étaient hyper précis et les bugs étaient éliminés si rapidement !
Je n'arrive pas à comprendre qu'aujourd'hui, avec les moyens immenses de mémoire et puissance de calcul dont on dispose, on en soit resté à des langages aussi basique que C et ses compères, qui sont des usines à bugs !
Ca coûte des milliards et des milliards, les logiciels bugués, alors qu'un langage avec des concepts propres et sécurisés apporte une efficacité de développement GLOBALE bien meilleure : certes ça va moins vite au départ, mais quel gain de temps et de fiabilité ensuite !
Aujourd'hui, j'ai pris du large avec le développement informatique... mais je constate toujours énormément de bugs dans les logiciels que j'utilise, certains dont je devine la cause (des contrôles sémantiques pas faits), et je me dis... mais pourquoi ??? pourquoi fait-on tant de progrès par ailleurs et si peu en Génie Logiciel ? ça me semble aberrant.
Suis-je le seul vieux schnock à penser ça ?

[Sve@r]

et déjà je considérais C comme un mauvais langage par le peu de sécurité qu'il apportait.

Aucun langage de programmation n'est parfait. Il n'existe même pas un langage meilleur que d'autres ; il n'y a que des langages en adéquation ou peu conseillés pour des buts particuliers. (Herbert Mayer).
Le C n'a pas été créé pour apporter de la sécurité mais pour faire de la vitesse. Son credo c'est "le programmeur sait ce qu'il fait". Evidemment s'il ne sait pas ce qu'il fait...

J'ai appris et pratiqué d'autres langages impératifs comme Ada et j'en garde un souvenir ébloui pour la fiabilité des résultats obtenus : ah oui, c'était moins drôle de programmer qu'avec C parce que le compilateur trouvait souvent à redire, mais les messages d'erreurs étaient hyper précis et les bugs étaient éliminés si rapidement !

Les bugs style "attention tu dépasses" ok ils sont repérés. Les bugs style "je modifie la variable X alors que j'aurais dû modifier la variable Y" eux ils ne le sont pas, et aucun langage ne les repèrera jamais. Et ce sont les pires. Un de mes profs nous a racontés une fois (vérité/hoax j'en sais rien) que les premières fusées sont parties en vrac parce que le sinus était stocké en non signé (or dans l'hémisphère Nord, si le cosinus est toujours positif on peut avoir quand-même des sinus négatifs).
Ce même prof nous a dit qu'il avait travaillé sur l'analyse des premières versions de PGP (Pretty Good Privacy, un logiciel lbre de chiffement/déchiffrement qui avait été un des premiers du genre dans les années 90). Ce logiciel étant libre, les sources étaient accessibles. Et il nous a dit qu'il (son équipe) avait identifié une fonction qui était au coeur de l'outil et qui, quoi qu'il arrive, renvoyait toujours 0 !!!!! Il n'a jamais su si ça avait été un bug accidentel ou intentionnel et bon, ça devient l'histoire du copain du copain qui a vu... mais vrai ou pas, ça illustre le fait qu'aucun langage, tout aussi impératif qu'il soit, ne repèrera ce type de bug.

certes ça va moins vite au départ, mais quel gain de temps et de fiabilité ensuite !

On ne parle pas de vitesse de développement mais de vitesse d'exécution. Je travaille en temps réel, je fais de l'analyse de data lue par des machines diverses, je suis content de pouvoir en analyser 10000/s là où un autre langage n'en analyserait qie 8000/s. Mais comme je l'ai dit, il n'y a que des langages en adéquation ou peu conseillés pour des buts particuliers. Celui qui veut gérer son répertoire téléphonique il ne doit pas partir sur du C. Je me suis par exemple amusé à écrire un reader CSV universel, il ne me serait jamais jamais jamais venu à l'idée de l'écrire en C.

et je me dis... mais pourquoi ??? pourquoi fait-on tant de progrès par ailleurs et si peu en Génie Logiciel ? ça me semble aberrant.

C'est comme partout, il y a de bons ouvriers, et aussi de mauvais. N'as-tu jamais vu cette émission sur M6 (je ne la nomme pas pour pas faire de pub mais ceux qui l'ont vue la connaissent) qui montrent des artisans qui commencent des chantiers puis qui se cassent en laissant tout en plan ? Je me suis heurté à des chefs de projet qui m'ont dit "ah ben vous ne nous avez pas précisé que le nom pouvait contenir un espace" parce que leur script foiraient l'info (les scripts shells utilisent l'espace pour séparer les éléments donc quand on veut traiter une variable contenant un espace il faut la quotter => echo "$var" et non echo $var donc on la quotte systématiquement ce qui fonctionne dans tous les cas (avec ou sans espace) ce qui évite de se faire des noeuds au cerveau et comme tu le vois c'est vraiment peanut à écrire mais leurs ingénieurs ne l'avaient pas écrit !!!).
J'ai vu ces mêmes ingénieurs qui ont écrit textuellement à mon chef (qui ne connait pas l'informatique) "La RFC (sans dire laquelle) indique que l'apostrophe n'est pas autorisée dans une adresse email" (parce qu'on avait des types style "N'Chang" qui n'arrivaient pas à se connecter) ce qui est un pur mensonge car justement la RFC 5321 cite textuellement les caractères autorisés qui incluent l'apostrophe. Mais ils (ces ingénieurs) ne voulaient pas se faire chier à passer le login via la fonction escape_string() qui, d'une part, est une fonction généralement incliuse dans toutes les librairies diverses (donc pas besoin de l'écrire, elle est offerte) et qui justement permet de transformer une string "N'Chang" en "N''Chang" ce qui permet à la bdd de la traiter correctement. Pas compliqué à faire, suffit de remplacer dans la fenêtre de login (une seule fenêtre donc) l'instruction envoyer login à bdd par l'instruction envoyer escape_string(login) à bdd mais non, ils préféraient dire carrément (disons même mentir carrément) "c'est interdit".
J'ai vu une autre fois un dossier d'appel d'offre pour gérer nos données, le dossier contenait des infos style n° INSEE ou affection en cours (je n'étais pas dans un hôpital). Les types nous avaient simplement fait passer un ancien dossier juste pour "bourrer" en se disant qu'on ne le lirait pas (ok tu l'auras compris, je bosse dans l'administration où on se fait enfler par tous les trous par les sociétés privées tellement mes chefs sont des billes en informatique).

Suis-je le seul vieux schnock à penser ça ?

Je pense que tu vois le monde informatique comme ce forum, rempli de gens motivés, doués et altruistes, ne pensant qu'à aider ; alors qu'en réalité elle est pour moitié remplie de pourris qui cherchent toujours à gratter le plus possible en en faisant le moins possible et pour moitié de ce qui reste d'incompétents notoires. Ok les altruistes il y en a aussi, et comme eux ils sont plébiscités ils sortent facilement dans la lumière mais cela n'empêche pas qu'ils sont une minorité. Mais la fiabilité d'un logiciel n'est pas (enfin pas forcément) liée au langage utilisé.

[jbrosset]

"Aucun langage n'est parfait" : tout à fait d'accord.
Mais ils sont loin d'être tous bons.

Comme on l'a dit plusieurs fois dans cette discussion, C a été conçu avec l'objectif, peut-être oserais-je dire l'obsession de la performance.
Pour moi, c'est un mauvais angle, et il suffit de considérer l'évolution des performances, par exemple depuis 1981 (puisque j'ai commencé là) pour reconnaître que les performances Ne Sont Pas un problème, à part des cas très très particuliers.
Et quand on voit comment les développeurs développent aujourd'hui à coup de lourdes bibliothèques, on peut pas soutenir que les performances soient un vrai enjeu hors exceptions.

Par contre ce qui résiste depuis des années, c'est la fiabilité des logiciels.
Tous les logiciels que j'utilise ont des anomalies plus ou moins graves.

Alors oui, certains bugs de logique ne pourront jamais être détectés par un langage informatique.
Quoique... en utilisant du typage fort comme en Ada, en y exprimant des invariants algorithmiques, beaucoup de bugs étaient éradiqués rapidement lors des premières exécutions...

Je pense que cet enjeu de la fiabilité des logiciels et de la rigueur du codage informatique n'est pas assez pris au sérieux aujourd'hui.
Pire, la flexibilité des outils logiciels d'aujourd'hui favorisent à mon sens un relâchement de la rigueur (on essaie et on verra bien, c'est tellement facile de corriger en quelques clics).

Je ne développe plus aujourd'hui, et je vais rentrer dans l'âge de la retraite, mais j'ai constaté souvent avec tristesse ces dernières années que les connaissances algorithmiques avaient fortement baissé et que la volonté de "conceptualiser" une problématique avant de la coder (par exemple pour introduire de nombreux paramètres afin de rendre flexible l'algorithme et facilement évolutif) avait presque totalement disparue. Les jeunes me regardent avec effarement si je leur recommander de coder un algorithmes "en pensant aux évolutions possibles qu'on ne connaît pas aujourd'hui". "Ben, on ne pet pas y penser puisqu'on ne les connaît pas" me répondent-ils invariablement... ce qui témoigne d'un niveau d'abstraction nul. Or c'est en faisant des algorithmes un peu plus abstraits que le problème immédiat que l'on fait des choses peut-être un peu plus lentes j'en conviens (mais j'ai dit ce que j'en pensais au-dessus) mais beaucoup plus évolutives et beaucoup plus fiables.

Et quand je dis cela, j'ai bien conscience d'être compris par bien peu de personnes.
C'est juste le témoignage personnel d'un ancien spécialiste du génie logiciel, autrefois... une bouteille à la mer...

[Uther]

Le C n'a pas été créé pour apporter de la sécurité mais pour faire de la vitesse. Son credo c'est "le programmeur sait ce qu'il fait". Evidemment s'il ne sait pas ce qu'il fait...

Sauf que dans la pratique ça se traduit par "le programmeur doit être infaillible" et on sait bien que même les meilleurs ne le sont pas quand le code devient un minimum complexe.

Les bugs style "attention tu dépasses" ok ils sont repérés. Les bugs style "je modifie la variable X alors que j'aurais dû modifier la variable Y" eux ils ne le sont pas, et aucun langage ne les repèrera jamais. Et ce sont les pires.

Je vois pas en quoi ils seraient pire, la probabilité qu'ils entrainent un mauvais fonctionnement qui sera identifié lors des tests est bien plus élevée et surtout la probabilité qu'ils entrainent une exécution de code arbitraire est quasi nulle.

On ne parle pas de vitesse de développement mais de vitesse d'exécution. Je travaille en temps réel, je fais de l'analyse de data lue par des machines diverses, je suis content de pouvoir en analyser 10000/s là où un autre langage n'en analyserait qie 8000/s. Mais comme je l'ai dit, il n'y a que des langages en adéquation ou peu conseillés pour des buts particuliers.

Ta vision du spectre de ce qui est faisable entre le C et le Python est assez limité. Les Langages comme le Rust ou l'Ada peuvent apporter plus de sécurité sans forcément sacrifier les performances.

Je pense que tu vois le monde informatique comme ce forum, rempli de gens motivés, doués et altruistes, ne pensant qu'à aider ; alors qu'en réalité elle est pour moitié remplie de pourris qui cherchent toujours à gratter le plus possible en en faisant le moins possible et pour moitié de ce qui reste d'incompétents notoires. Ok les altruistes il y en a aussi, et comme eux ils sont plébiscités ils sortent facilement dans la lumière mais cela n'empêche pas qu'ils sont une minorité. Mais la fiabilité d'un logiciel n'est pas (enfin pas forcément) liée au langage utilisé.

Raison de plus, si on ne peut pas faire confiance à l'humain, d'avoir des outils qui limitent le type d'erreur qu'il peut commettre. Bien sur que le fiabilité d'un programme ne se limite pas au langage utilisé. Mais le langage et clairement un outil de plus en plus important de la chaine, comme les outils d'analyse statique et dynamique, la politique de relecture, les outils de mitigation d'attaque, le fuzzing, le suivi de la supply chain ...

[moldavi]

Bonjour.

C'est clair que le problème d'inclusion en C a toujours été une purge pour les débutants, sans parler des histoires d'inclusion circulaire.

Mais bon, un nouveau langage pour ça... Pourquoi ne pas améliorer le langage C directement. Encore des guerres d'égo, et des vas-y que je te réinvente la roue, et que je te complexifie l'écosystème.

Lorsqu'il y aura 50000 langages de programmation, ça va être compliqué pour les universitaires de choisir, mais aussi pour les professionnels.

[chrtophe]

La sonde Mars Polar Lander devait se poser à la surface de Mars, mais les vibrations de la haute atmosphère ont convaincu son logiciel embarqué qu’elle avait déjà touché le sol. Le logiciel a donc coupé les moteurs à 40 mètres du sol, et la sonde s’est écrasée.
Pourquoi ? Pour respecter le planning de lancement, les tests prévus n’avaient pas été menés à leur terme.

Tester prend du temps et représente un cout financier. Quand Windows sort une nouvelle version majeure tous les 6 mois, sur des millions de configurations différentes, rien de surprenant qu'il y ai des bugs. A cela vient se rajouter une complexité accrue par rapport à avant

[Madmac]

"Aucun langage n'est parfait" : tout à fait d'accord.
Mais ils sont loin d'être tous bons.

Comme on l'a dit plusieurs fois dans cette discussion, C a été conçu avec l'objectif, peut-être oserais-je dire l'obsession de la performance.

Il était avait tout un outil pour assembler des ligne de langage machine. Et créer des pilotes pour des cartes électroniques et des commandes pour les OS. Les types utilisés se limitaient à indiquer le nombre de bits des variables. Et s'ils était signés ou non. Et pour ce type de travail, le langage est parfait. Ce langage n'a jamais été pensé pour faire des applications.

S'imaginer qu'il est possible de faire un langage qui fait tout pour tous le monde est le fond du problème. La seule véritable solution pour simplifier le travail des programmeurs serait de faire évoluer les langages de vers une syntaxe commune avec des nom de fonction standardiser pour les tableaux , les chaines de caractère et les flux.