Apprendre la programmation en C.

Les protections du Kernel Linux :
https://www.kernel.org/doc/Documentation/security/self-protection.txt
https://eklitzke.org/memory-protection-and-aslr

Suite du roman feuilleton, Linus et ses rants.
https://lkml.org/lkml/2017/11/21/356

J'y vois un peu plus clair au niveau de la nature de l'informatique. J'ai fait quelques expérimentations en C, pour essayer de construire un environnement où programmer en ayant une idée de ce que fait le programme qu'on a créé, et pas seulement une idée de ce que pourrait faire le programme qu'on CROIT avoir créé en C est possible. Ca prend du temps, ça met des bugs dans les dents. Je comprends pourquoi les pointeurs sont réputés difficiles, par contre j'ai du mal à comprendre la manière dont on les utilise en C (dans la littérature pour débutants). C'est n'importe quoi, je dirais en première approximation. Peut être ça s'explique de façon historique, on pour des raisons d'optimisation énergétique. C'est peut être moins coûteux de mal programmer, on pourrait se demander en quoi, mais ça serait entrer dans un débat socio-économico-philosophique de peu d'intérêt pour réaliser des projets personnels.


Un de mes constats, c'est qu'on oublie vite ce qu'on fait, et de quoi on parle. Il y a une chaîne (stack on dirait en english, comme on parle de la stack des protocoles internets) qui va du monde physique, jusqu'au monde du langage et des échanges entre personnes, le monde des spécifications logicielle écrite pour être lues par des humains, et qui passe brièvement par une étape logique objective.


Monde physique <----> monde humain.
Entre les deux, il y a l'information, et notamment les processeurs, le hardware, puis les langages de programmation. Tout ça est un beau bordel, et les différentes strates sont assez mal conçues pour communiquer ensemble.

Il existe des langages de descriptions hardware propriétaires, il existe même des entreprises spécialisées dans la compilation des programmes c vers des langages hardware propriétaires, à destination en particulier de l'industrie financière.



Il existe des gens qui invente de nouveaux langage (Rust par exemple, ou Go, ou Lisp, Haskell), l'ennui c'est qu'ils mettent un coup d'épée dans l'eau, en ceci que leur langage s'intègre dans une stack complètement hétéroclites, et les couches en amont et aval du langage se parlent très très mal, avec des centaines de standards et façon différentes de dire et spécifier qui s'affrontent de manière informelle.


Ptet inventer un langage de programmation, ça serait déjà remettre un peu d'ordre et de cohérence dans la stack de l'informatique. La pile des manières de spécifier.

1. Spécifications physiques (grosso modo comment construire de portes logiques avec un monde physique, que ce soit avec des boules de billards, des automates cellulaires, ou des effets quantiques sur du silicium enrichi soumi à des tensions)
   
   
2. Spécifications logiques et temporelles (le hardware, les microprocesseurs, il existe des langages propriétaires spécialisé, le HDL, et du hardware bien adaptés à l'émulation : le FPGA. Il existe aussi des émulateurs logiciels assez lents). Comme vous le savez sans doute, Intel à racheté Xilinx, un vendeur de FPGA. A la fois pour intégrer la technologie à ses processeurs, mais aussi probablement du fait qu'il était un énorme consomateurs de FPGA pour mettre au point la partie logique de ses processeurs.
   
   
3. Programmation impérative (assembleurs). Là c'est l'explosion. On notera au passage que la force des assembleurs, c'est leur coté séquentiel. Tu fais ça, puis ça ... sauf que le monde réel est revenu à la charge, et que les processeurs sont de plus en plus plongé dans des environnements multiprocesseurs.
   
   
4. Programmation impérative / fonctionnelle (langages). On arrive aux langages traditionnels, C, Java, Go, Rust, Haskell, Lisp, Scala, Lua, .....
   
   
5. Programmation (autres) : prolog, mathematica, coq, .. langages de "haut niveau"
   
   
6. CAO : logiciels d'architectures (architecture des prorammes, des processeurs, ou des maisons, suivant le logiciel), Assistants à la création - simulations de flux sur des coques, simulateurs, design automatisé ou assisté, logiciels de modélisation 3D, Raytracing ....
   

Trouver LA (the) bonne abstraction pour parler de tout ça à la fois, de façon unifiée, et adaptée aux réalités de 2017 (ou 2018 notez, chui ouvert d'esprit)



Sources :
https://www.quora.com/Why-did-Intel-choose-to-acquire-Altera-and-not-Xilinx
http://fortune.com/2015/08/27/why-intel-altera/

Pour le fait que Intel utilisait des murs couvert de FPGA pour tester ses designs, j'ai l'impression que c'est un gars qui m'a dit ça. Aucune idée du contexte.
https://en.wikipedia.org/wiki/Hardware_emulation

Une page d'ingénierie.

It feels a little weird to put 100 hours into something that won't be noticed by its absence.

https://forums.tigsource.com/index.php?topic=40832.msg1363742#msg1363742

L'objectif du jour, c'est de me renseigner un peu sur les systèmes d'exploitation. Avoir au moins une vague idée de ce que c'est. Amusament dans la spécification du Multiboot loader, ils fournissent un exemple d'OS.
https://www.gnu.org/software/grub/manual/multiboot/multiboot.html

Sinon je vais lire un blog je crois, ptet celui là :
https://os.phil-opp.com/

notes de lecture:

(How to Write a (Lisp) Interpreter (in Python))

So, ironically, Tony wrote a Lisp program (with one small routine in C) because he was a C programmer, and I wrote a C program because I was a Lisp programmer.

http://norvig.com/lispy.html

Roger a écrit:

Code:


type instruction =
| SetReg of int * int
| Load of int * int
| Store of int * int
| Jump of int
| JumpZ of int * int
| Add of int * int
| Sub of int * int
| Print of int

let rec eval prog mem reg ptr =
  if ptr >= Array.length prog then (
    mem
  ) else (
    let nextPtr =
      match prog.(ptr) with
      | SetReg (r, cst) -> reg.(r) <- cst ; ptr + 1
      | Load (r, ra) -> reg.(r) <- mem.(reg.(ra)) ; ptr + 1
      | Store (r, ra) -> mem.(reg.(ra)) <- reg.(r) ; ptr + 1
      | Jump p -> p
      | JumpZ (r, p) -> if reg.(r) == 0 then p else ptr + 1
      | Add (r1, r2) -> reg.(r1) <- reg.(r1) + reg.(r2) ; ptr + 1
      | Sub (r1, r2) -> reg.(r1) <- reg.(r1) - reg.(r2) ; ptr + 1
      | Print r -> Printf.printf "%d\n" reg.(r) ; ptr + 1 in
    eval prog mem reg nextPtr
  )

let exec memSize regSize prog =
  let mem = Array.make memSize 0 in
  let reg = Array.make regSize 0 in
  eval prog mem reg 0

let _ = exec 100 4 [|
  SetReg (0, 10);
  SetReg (1, 50);
  SetReg (2, 1);
  SetReg (3, 0);
  Store (3, 1);
  Sub (0, 2);
  Add (1, 2);
  Add (3, 2);
  JumpZ (0, 10);
  Jump 4 ;
  SetReg (0, 10);
  SetReg (1, 50);
  SetReg (2, 1);
  Load (3, 1);
  Print 3;
  Sub (0, 2);
  Add (1, 2);
  JumpZ (0, 19);
  Jump 13
|]


Le code en OCaml fait appel à des concepts simples: des entiers, des tableaux et une récursion terminale. Il introduit simplement la notion de pointeur comme étant l'adresse d'une case mémoire, un indice dans un tableau. On a en prime la notion d'interpréteur, d'assembleur, de registres, etc.

Je me sens quand même intrigué par cette affaire. Même si clairement c'est encore un hors sujet qui va me conduire à investiguer des pistes et perdre de vue mes objectifs plus immédiats.

the grammar of Scheme generates a sublanguage of the language used for data. An important consequence of this simple, uniform representation is the susceptibility of Scheme programs and data to uniform treatment by other Scheme programs. For example, the eval procedure evaluates a Scheme program expressed as data.

Historiquement ça nous donne :
http://schemers.org/Documents/Standards/R5RS/r5rs.pdf
vs
https://en.wikipedia.org/wiki/ALGOL

Je ne suis pas un fan de l'aspect "recursif" vs "for loop". J'aime assez la notation "for i =0 to 125 do" (et toutes ses variantes). Il n'y a pas de version récursive aussi satisfaisante. A contrario on vante beaucoup l'aspect minimaliste de lisp, et son "élégance". Je me sens intrigué. J'ai déjà écrit vite fait des programmes dans des dialectes, et ça ne m'a pas marqué comme étant très agréable ou pratique. Mais peut être que je n'ai pas abordé les choses sous le bon angle. J'aimerais consacrer un peu de temps à me faire idée des forces et faiblesses du paradigme lisp.  Une faiblesse qui me semble évidente, est le coté trop générique de la forme simple [for i=0 to 125 do] car cette expression offre des garanties intéressante, et c'est d'ailleurs quelque chose que je n'aime pas du tout dans le langage C non plus que de fusionner cette forme très fortement garantie, avec un truc plus (trop) général : le while. (ou le tail recursion).

---

The JSON crowd is re-inventing LISP. Originally, JSON was a subset of what you could pass to "eval()".

https://news.ycombinator.com/item?id=13097872

---

What follows is largely a discussion of how to sum the first ten integers

http://wiki.c2.com/?WhyWeHateLisp

Ca prend une épouvantable quantité de temps (plus de 2h) de se faire même une vague idée de ce qui existe ou de ce qui a été tenté.

http://www.paulgraham.com/thist.html
http://mumble.net/~jar/tproject/
http://web.archive.org/web/20060925104715/http://mumble.net/~campbell/t/tman.pdf

Ce que je retiens pour le moment c'est que les lisps sont des langages naturellement faciles à implémenter, tant au niveau de l’interpréteur que du compilateur. Par contre à l'usage c'est pas forcément terriblement pratique, dans le sens que ça ne respecte pas trop les habitudes qu'on nous inculque (et peut être c'est juste merdique tout court). Mais du coup pour écrire un langage customisé pour une certaine tâche, il est tentant de s'intéresser à Lisp. Par exemple si on veut rapidement fournir un langage de script, on peut avoir envie de s'intéresser à Lisp.

Le projet T semble(ait) avoir pour objectif de transformer la syntaxe Lisp en un langage macro-assembleur (donc utilisable en programmation systeme). C'est assez intriguant, et néanmoins ça demande quand même de se pencher un peu sur l'ensemble pour se faire une idée de ce qui est possible, et de ce qui a été tenté.

https://swizec.com/blog/the-birth-of-lisp-a-summary-of-john-mccarthys-original-paper/swizec/5075

I tried to learn LISP (clojure really), I really did. But the syntax was just too jarring.

Le problème du jour : le mutlithread. Dis tonton, ça marche comment ?

- Quelles instructions sont disponibles sur les processeurs ?
- Combien ça coûte ?
- Quels sont les patterns (de haut niveau) les plus courants, avantages/inconvénients ?
- Est ce qu'il existe un moyen de se passer de synchronisation, et d'avoir un bidule qui fonctionne à la fin ?



Un premier lien pour se cultiver :
https://stackoverflow.com/questions/2538070/atomic-operation-cost

D'autres en vrac
https://en.wikipedia.org/wiki/Synchronization_(computer_science)#The_need_for_synchronization
https://en.wikipedia.org/wiki/Readers%E2%80%93writer_lock
http://moodycamel.com/blog/2013/a-fast-lock-free-queue-for-c++

https://carld.github.io/2017/06/20/lisp-in-less-than-200-lines-of-c.html

---

Stack languages ("Lisp without the parentheses") :
http://www.drdobbs.com/architecture-and-design/cat-a-functional-stack-based-little-lang/207200779
https://en.wikipedia.org/wiki/Joy_(programming_language)

Introduction to concatenative (aka stack based, aka lisp without parenthesis) language
http://ncreep.github.io/language_perils/blog/2013-03-18-the-joy-of-joy.html

Une autre publicité pour rust (english) et pour le nouveau mozilla.
http://bholley.net/blog/2017/stylo.html

Vocabulaire (game of life)
http://conwaylife.com/wiki/Lidka
http://conwaylife.com/wiki/List_of_long-lived_methuselahs

Une (en fait plusieurs) implementation présumée rapide de game of life (sur les CPU intel)
https://gitlab.com/apgoucher/lifelib
http://www.perlmonks.org/?node_id=1197250

Stauk a écrit:Vocabulaire (game of life)
http://conwaylife.com/wiki/Lidka
http://conwaylife.com/wiki/List_of_long-lived_methuselahs

Une (en fait plusieurs) implementation présumée rapide de game of life (sur les CPU intel)
https://gitlab.com/apgoucher/lifelib

Je ne sais pas pourquoi tu nous parles de tout ça, mais c'est quand même fascinant...

@Petitagore ... bah ... pour apprendre le C.

Y a aussi BBBEEAUCOUP de choses dont je ne parle pas; Grosso modo tout ce qu'il y a d'original dans mon approche. Vu que déjà c'est difficile d'en parler, et puis c'est con, mais on sait jamais, dans le tas y a peut être un truc utile.  Je crois que j'ai mal digéré le jour ou ayant la flemme de tester (plus avant ) des idées j'ai expliqué un truc sur une mailing list. Et puis quelques mois après y avait un papier qui testait la pertinence de mon idée (qui fonctionnait correctement, mais sans plus, ça n'a jamais été une révolution, juste une bonne idée à tester, puis à oublier). Mais rien qui relie le papier à ma contribution, c'est à dire de poser l'idée elle même. Ca m'a laissé l'impression qu'une idée qui n'est pas ancrée dans la réalité par une implémentation solide appartient à l’éther commun. Alors qu'une idée qui est implémentée concrètement appartient à celui qui l'a ainsi mis en valeur. Tout ça reste très subjectif bien entendu.


Pour ce qui est de ce que je mets ici, ce sont des ressources qui me semblent pertinentes pour apprendre le C, néanmoins ce qui est vraiment pertinent, c'est d'implémenter des trucs. Et ça reste le point faible de mon approche, je me sens mal à l'aise avec le hardware, je suis terriblement frustré de ne pas trouver un moyen de poser les choses à plat qui me convienne. Je gratte la surface, en espérant un miracle.

Pour faire simple, je suis extrêmement angoissé par ce monde, ces choix qui sont faits pour moi, et sur lesquels j'ai peu de pouvoir. Bien que ce ne soit pas la priorité immédiate, j'ai envie de pouvoir partager un minimum mes (éventuelles) réalisations, de montrer ce que j'implémente, à un moment, ne serait-ce qu'à mes proches, mais aussi pourquoi pas, un jour partager d'une façon ou d'une autre.

Réaliser des trucs sur FPGA (ou asic) n'est clairement pas pertinent, sauf si justement c'est pour offrir quelque chose qui est vraiment bas niveau (robot ou autre). D'ailleurs même les FPGA sont frustrants dans les choix qu'ils imposent. Je ne comprends pas tout ces choix, mais si je veux bien comprendre ce que j'estime être incompréhensible, il y a un moment où il va falloir plus qu'un gut-feeling. Et du coup le C est un moyen d'exploration de ces univers (les automates de façon générale, dont les CPUs sont des instances particulières).

---

Bah pour faire simple, après tout à défaut de parler des mes idées, je peux toujours parler de mes difficultés : j'ai choisis le C car c'est un langage qui demande peu d'investissement. Si je veux apprendre le rust, ou le C++, il va me falloir des années, et je n'ai pas envie d'être marié à ces langages qui me semblent défaillants (ou à défaut très angoissant dans le manque de contact qu'ils offrent avec le monde qui m'intéresse). Le C est en fait une manière de prototyper pour explorer le monde des automates (au sens général du terme, grosso modo pour explorer la programmation, dont malheureusement les instances actuelles sont finalement très contraintes et peu générique. Y a comme un manque généralisé d'élégance). Dans les envies concrètes, il y a les agents qui apprennent automatiquement (aka deep learning et assimilable) et également les interactions [graphique/souris/dream/clavier] (aka les jeux vidéos, en particulier les simulations du style Dwarf Forteress, même si je ne connais absolument pas Dwarf Fortress, j'ai lu des choses à propos de ce jeu, et ça représente bien l'esprit de ce qui me fascine : le monde des simulations).

Je dis que je veux apprendre à Programmer en C, et le reflexe d'un lecteur semble être "tiens, il n'a jamais programmé de sa vie". Ce qui n'est pas tout à fait exact. Je dis que je ne sais pas programmer, car je n'ai pas les idées claires sur pleins de choses. Mais plus mes idées se précisent, plus c'est difficile de programmer, car je suis angoissé par toutes les contraintes que l'environnement nous propose. D'un autre coté, sans cet environnement, je n'aurais jamais eu accès à un pc (qui est quand même pas évident à construire à partir du bush australien), donc je peux pas non plus cracher dans la soupe de la main qui me nourrit en sciant la branche sur laquelle je suis assis. Mais des fois j'ai envie quand même.


Références :

Optimisation automatique ( = learning)


https://github.com/wassname/viz_torch_optim



https://www.sfu.ca/~ssurjano/camel6.html

sur ce lien et cette animation

https://github.com/wassname/viz_torch_optim

on capte bien que l'optimisation est paradoxalement la meilleure quand l'itération "explore" une plus grande étendue de possibles

le learning en fait dépend fondamentalement des erreurs !

et si on injecte les écarts par rapport aux attentes, on apprend plus vite, c'est le principe de la régulation des lasers ceci dit si j'ai souvenir

le chaos du flux lumineux en sortie est rebalancé en entrée de telle manière que le flux soit tout dans tout relativement corrigé et vaguement constant

la prévision adaptative en stat fait la même chose

on a donc forcément une réduction progressive des écarts et une convergence

je suppose qu'en programmation en c on pourrait aussi coder une injection d'écart en quelque sorte mais ce serait surement pas très propre comme code

et évolutif, le code , ou l'auto code d'une ia permets ans doute cette liberté de reprogrammation

cela montre aussi accessoirement une faiblesse majeure des machines learning, elles ne peuvent proposer une solution que sur les entrées

cela implique que si les entrées sont partielles ou de mauvaises qualité, le learning ne sera pas bon

je le constate souvent en amazon par exemple

je suppose qu'ils ont le même problème à la nsa et c'est très bien ainsi :-)

Quelques informations sur les processeurs.    la notion de Pile fait partie de tous les processeurs que je connais. Et de toute façon la RAM aussi. Une RAM + un pointeur = une pile.

Stack based processor :
http://www.excamera.com/files/j1.pdf

Multi core processor (pas eu le temps de trouver ce que je cherche : comment ils synchronisent les procs)
https://upcommons.upc.edu/bitstream/handle/2099.1/7460/59395.pdf

---

Je cherche des benchmarks sur les instructions de shift des BigIntegers.
https://stackoverflow.com/questions/35001722/global-bitwise-shift-of-128-256-512-bit-registry-using-intrinsics

Hello Stauk,

Pour comprendre le C et avant d'aller trop loin dans des "détails" techniques, il est intéressant de comprendre la réelle puissance des concepts même du C et des instructions basiques. Je crains que sans cela, tu te perdes dans les normes et dans les méandres des architectures qui nécessitent pas mal de recul pour en comprendre les tenants et les aboutissements.

Si tu veux un exemple d'un exercice de style simple mais délicat c'est de programmer un simple algo de tri d'un fichier de données tabulaire dont tu ne connais ni structure ni la longueur avant l'appel de la fonction.
La structure des colonnes peut être donnée par un fichier tiers du type
Col_1 Integer
Col_2 String25
...
Col_n Bizarre

Le but du jeu est d'avoir un temps de réponse "presque" linéaire que tu traites 1 millions de ligne ou 1 milliards.

C'est très basique mais une base sûre pour faire pas mal d'erreur, de comprendre ses erreurs et de rentrer dans ce qu'est le traitement de l'information sans passer par les couches de haut niveaux.


Si tu veux t'initier à la programmation système, tu peux créer un driver Windows pour la gestion de joystick virtuel. Mais là c'est coûteux en investissement car il va falloir éplucher des tonnes de docs pour voir comment Windaube exploite les périphériques. Mais c'est amusant et éducatif  car sans trop de risque.

Bon jeu

Unefois a écrit:
Le but du jeu est d'avoir un temps de réponse "presque" linéaire que tu traites 1 millions de ligne ou 1 milliards.
C'est très basique mais une base sûre pour faire pas mal d'erreur, de comprendre ses erreurs et de rentrer dans ce qu'est le traitement de l'information sans passer par les couches de haut niveaux.

>on Oct 28 2015 AliCloud sorted 100 terabytes of data within 377 seconds, breaking the previous world record of 1,406 seconds set by Apache Spark. In the two most technically demanding contests GraySort and MinuteSort, AliCloud set four new world records in both the Daytona category for general-purpose sorting systems and the Indy category for specifics-customized systems for the task of sorting.

The news stunned the technical sphere, especially the Internet and computer fields that pay close attention to cloud computing. AliCloud’s record-breaking performance in the contest rekindled people’s interest in distributed computing. Discussions are going on in the big data and cloud computing circles about how difficult the task is, how AliCloud made it, what its significance is for the general public etc.<


https://www.alibabacloud.com/forum/read-71



>The concept changed in 1998 and distributed computing started to predominate. The focus of work turned to how to effectively dispatch the physical resources of hundreds or even tens of thousands of machines such as CPUs, memory, networks and disk IOs to complete data sorting within the shortest time.<

---

Si tu veux t'initier à la programmation système, tu peux créer un driver Windows pour la gestion de joystick virtuel. Mais là c'est coûteux en investissement car il va falloir éplucher des tonnes de docs pour voir comment Windaube exploite les périphériques. Mais c'est amusant et éducatif  car sans trop de risque.
Bon jeu

Je n'ai pas windows, et je n'ai pas de Joystick.




https://www.codingame.com/start

C + SDL 2 --> Web.

https://lyceum-allotments.github.io/2016/06/emscripten-and-sdl2-tutorial-part-4-look-owl/
https://github.com/emscripten-ports/SDL2

Bon j'ai choisis le C comme langage (de programmation), mais finalement l'informatique ce n'est pas juste la programmation. Il faut d'autres langages complémentaires.


Le C sert juste à manager la boite la plus en bas. J'ai choisis le C car c'est simple. Maintenant faut voir comment je gère les autres boîtes, avec quels langages ? Des langages simples, pratiques, faciles à apprendre, qui permettent de réutiliser ... etc etc.

Stauk a écrit:J'ai choisis le C car c'est simple.

Ben non, justement, c'est ce que plusieurs personnes ont expliqué : le C n'est pas simple. (Ça veut dire quoi, d'ailleurs, "simple" ? C'est comme l'utilité dont il a été question plus haut...)
Aucun langage n'est simple, ni les vraies langues parlées dans le monde, ni les langages du monde informatique. Parce qu'un langage ce n'est pas simplement des mots et une syntaxe pauvre, c'est une utilisation, une grammaire, des exceptions, des variations, beaucoup de pièges aussi, et surtout à la fin... un style !
Mais bon, si tu veux continuer de penser que le C est simple, tu le pourras et tu en seras convaincu tant que tu n'auras pas mené de "vrais" projets en C. (On peut bien sûr remplacer "C" par n'importe quel autre langage ;-)...)

Bon courage en tout cas !

Alexandre a écrit:
Aucun langage n'est simple, ni les vraies langues parlées dans le monde, ni les langages du monde informatique.

J'utilise "simple" par opposition à "complexe". Est ce que tu affirmerais qu'aucun langage n'est plus >non-simple< qu'un autre ? S'il existe des langages plus >non-simple<, alors il existe aussi des langage moins >non-simple<, et alors on peut designer l'un de ces langages par ce label qui représente bien une propriété. Après je suis d'accord que le mot "simple" n'est pas très parlant, en général une personne qui lit ce qu'on écrit ne se demandera pas ce qu'on essaye de dire, et même si elle le fait, elle n'aura pas nécessairement envie d'essayer de répondre en utilisant cette compréhension : comprendre ce que quelqu'un d'autre écrit (ou dit, ou veux dire) est complexe, sauf si le contenu n'est pas important, et que c'est l'échange qui prime.

Malheureusement j'aimerais échanger au niveau du contenu. Peut être le langage n'est pas approprié pour ça, et du coup le mot "simple" non plus. Le C est simple au niveau de sa structure, au niveau de ses compilateurs (au moins les minimalistes), il est impératif, et répond aux syntaxes intuitives dans lesquelles tout le monde baigne. Si tu donnes à un jeune de quatorze an quelques exemples, en quelques lignes il devrait comprendre la majorité de la syntaxe, excepté peut être les pointeurs, qui sont spécifiques aux langages assembleurs. Le C est aussi simple en ceci qu'on peut se faire une idée à priori du code généré, en ayant à l'esprit un modèle simple(encore). Le langage est aussi à considéré dans la pile des outils/langages/hardware dans lequel il s'inscrit. Le C est simple là encore, les outils sont (ou peuvent être) très simples, et le lien avec le hardware sans être immédiat, est accessible.

J'oppose donc le C au C++, à Rust, Javascript, Java, aux Lisps etc. Aucun n'est aussi "simple" que le C. Et donc le C est "simple".


Le fait que je considère que je ne sache pas programmer en C, ne signifie pas que je n'ai jamais écrit de programme en C.  Ni que je n'ai jamais écrit de programme en assembleur d'ailleurs, ou en Java, ou en Clojure, en Bash, en Rust etc. Le C est simple en ceci qu'on peut l'avoir en tête et même l'expliquer en quelques minutes, ou quelques heures, à une personne qui est compatible intellectuellement. A contrario le C++ ne peut pas être expliqué en quelques heure, même à une personne très compatible. D'ailleurs je ne sais honnêtement pas si le C++ peut être expliqué, dans le sens que peut être l'ensemble ne fait tout simplement pas sens. Ce qui ne signifie pas qu'il ne soit jamais "simple" pour personne d'utiliser du C++. Le C++ n'est pas >simple<, et le C est >simple<.


J'ai choisis le C, car il n'a pas de spécificités particulières, comparés à un langage assembleur c'est dans une large mesure un équivalent, avec une syntaxe plus intuitive et structurée, et doté d'un langage macro. Par ailleurs, si on prend la plateforme i686 comme référence, le C est un langage assembleur simplifié. Un certain nombre de détails sont masqués, et la prolifération des opérations est simplifiée. Dans la nomenclature que j'utilise, les langages assembleurs (même le i686 qui est particulièrement alambiqué) sont >simple<, essentiellement du fait qu'ils sont un moyen immédiat d'affecter la réalité physique sous-jacente. Avoir à l'esprit la place qu'ils occupe dans la pile des constructions qui rendent possible "la programmation" est simple. Par ailleurs les principes de bases sont peu nombreux également. Le système de typage est minimaliste (essentiellement la taille des entiers / flotants / pointeurs). Par contre il est clair qu'il y a des langages assembleurs plus simple que d'autres. Donc si j'écrivais que le langage assembleur bidule [exemple : https://github.com/cslarsen/stack-machine] est "simple", la réaction ici serait : mais non le langage assembleur n'est pas simple, fait donc du visual basic plutot. Bah, ouais. Enfin c'est pas idiot pris dans le référentiel de la personne qui me donne ce conseil, mais j'ai mes propres contraintes, qui font que de réaliser un logiciel qui trie le dataset des courses de chevaux [exemple de data set à prendre en input : https://www.kaggle.com/lukebyrne/horses-for-courses] en VisualBasic n'est pas ma priorité, même si c'est par ailleurs sans doute un excellent moyen d'apprendre pleins de choses intéressantes.

---

Bref ce que je cherche en fait, ce sont des interlocuteurs, et des contradicteurs. Finalement celui qui a le plus challengé mes conceptions, c'était Roger. Je n'ai pas aimé la manière dont il a présenté ses arguments, mais je suis bien obligé d'admettre qu'il y avait derrière l'expression de son dégoût, un contenu réfléchi et travaillé, et finalement une compréhension du sujet du fil.  Après si on lit en surface ce qu'il a écrit était "Le C c'est nul, fait plutôt du Forth ou du Lisp (enfin CamelObjet bidule, mais j'imagine que ça doit pas être très loin)". Mais la différence, c'est qu'il a essayé de fournir des liens vers des articles, et des arguments. Et il a également lu les arguments et les articles que je lui opposais, en dépit du fait qu'il semblait partir du principe que j'étais sois un gros con, soit un criminel. Enfin de compte c'était stimulant, et c'est ça que j'espérais tirer d'un fil avec pour titre "tiens j'aimerais bien apprendre le C".

Assez rapidement lire ce qu'écris une personne dans mon genre, un peu destructurée et qui manque d'organisation, sur un fil qui est disponible au quotidien, devient à peu près impossible en soi. Lire les référence demanderait encore plus d'investissement. Le format du fil n'est pas très adapté à l'interaction avec les gens qui veulent interagir.  Je vous propose donc qu'on ferme ce fil, et qu'on en ouvre un nouveau, avec des règles plus claires au niveau de ce qui est attendu.

https://www.cl.cam.ac.uk/~srk31/research/papers/kell17some-preprint.pdf

This essay is a
C programmer’s reaction to the call to abandon ship. It questions
several properties commonly held to define the experience
of using C; these include unsafety, undefined behaviour,
and the motivation of performance. It argues all these are
in fact inessential; rather, it traces C’s ultimate strength to a
communicative design which does not fit easily within the
usual conception of “a programming language”, but can be
seen as a counterpoint to so-called “managed languages”.
This communicativity is what facilitates the essential aspect
of system-building: creating parts which interact with other,
remote parts—being “alongside” not “within”.

La conclusion ...

C is far from sacred, and I look forward
to its replacements—but they must not forget the importance
of communicating with aliens.