Ours & Hippy — le blog

Un article des plus intéressants par des gens que je juge comme compétents, ça permet aussi de se retrouver soi-même dans les différents schémas d'évolution de l'apprentissage proposés.

Je suis très content de ne pas avoir raté cet article qui me permet d'avoir une sorte de vue d'ensemble du processus d'apprentissage autodidacte, de voir comment ces trois personnes, (oui vous là-bas), ce sont débrouillées et on vécues cette période.

Oui, je me situe effectivement au commencement de ce parcourt.
Pour l'instant je me débrouille en lisant des tutoriels et des bouquins, mais je ne suis toujours pas réellement passé dans une pseudo-phase productive temporaire.

Contrairement à bluestorm, j'ai hâte de passer dans une phase productive pour pouvoir tester mes compétences et me rassurer sur mon niveau.
Et aussi pour ne pas avoir passé environ trois ans à apprendre sans rien produire.

(Dangerous, jte fais la gueule)

Pressé de lire la 2ème partie.

Très intéressant, étant moi-même autoditacte depuis 6/7 ans je me reconnais fortement dans le schéma que propose rz0. Surtout dans la phase d'arrogance ^^
De plus, le fait d'être dans une école d'ingénieur spécialisée en info, remet un peu les idées en place (je parle de l'Ensimag, j'y suis aussi).. c'est du positif

Just remplacer des #define par des enum ne changerait pas grand chose, vu que tout ça va se retrouver dans des int après… donc ça change rien au debug.

Et oui, changer les #define par des enum empêche des tests du genre #ifdef ou encore les évaluations dans les #if.

thx. Je remarque en parcourant les <stdio.h> ou autres que beaucoup de constantes sont définies par des #define, ce qui est difficilement débuggable. Est-ce que toutes les remplacer par des enum est impossible, empêcherait la compilation, etc. ?

@Pantoufle C’est un classique. Le problème c’est quand tu veux placer ta macro à un endroit qui n’accepte qu’une seule instruction, typiquement dans une clause else :

#define bar() { ... }
if (...)
        foo();
else
        bar();

Et là ça coince, parce que bar(); devient { ... }; ce qui est en fait deux instructions : le point-virgule constitue une instruction vide !

Est-ce que la syntaxe { ... } n'est pas égale à do { ... } while(0) ? C'est que la deuxième m'a toujours parue un peu tordue.

@Ban

Même si je connaissais déjà les différentes petites choses décrites ici, je dois bien avouer que je n’avais pas pensé à toutes ces petites applications… bien intéressant :)

C’est le but ! Ce que je veux, c’est écrire sur des techniques et des idiomes, pas vraiment enseigner des constructions du langage, parce que je trouve que c’est cela qu’il manque, souvent ; on a les bases, on connait la syntaxe et on comprend la sémantique… mais on ne sait pas quoi en faire !

Point de vue d’un agileux pragmatique d’un point de vue "industrie" : http://martinfowler.com/bliki/UtilityVsStrategicDichotomy.html

tl;dr : L’informatique ça doit marcher quand c’est juste un outil, mais il faut des outils qu’on puisse modifier et comprendre lorsqu’ils deviennent un facteur clé de succès.

À propos, et toujours dans un contexte "industrie", ça pose problème avec les algos approchés de manière générale (algos génétiques, réseaux de neurones, certaines heuristiques, …) : on sait pas trop pourquoi ça marche ou pourquoi ça marche pas une fois qu’on a le résultat.

Oui, c'est troublant et ça fait peur ! Et plus on le souligne (merci méchantloup), plus c'est choquant !
Penser que dans un domaine capital/potentiellement puissant/dangereux comme l'informatique, peut de gens s'instruisent ou, disons-le, reste des demeurés... C'est la porte ouverte à 1984, au négationnisme, au VIH qui ne cause pas le SIDA, à l'obscurantisme !

Décemment et pour le bien de l'Humanité, les gens des pays riches (j'entends "qui ont le temps de penser") doivent voir la différence entre un ordinateur et leur télévision ou leur minitel ! De la même façon qu'on doit être au courant de notre passé...

Je rejoins un peu BadWolf sur l'idee du strict minimum d'education.

Non pas que voir tout le monde devenir un power-user m'enchante (sinon apres comment je pourrais me la peter avec mes connaissances "de ouf" et mes bureaux en tuile ?), mais une partie considerable de l'energie de chacun pourrait etre sauvegardee si tout a chacun prennait au moins la peine de lire un manuel (concu pour les beotiens, tout de meme) sur le fonctionnement exterieur de leur machine, ou sur quel clic faire suivant tel probleme.

Il le font bien pour monter leur armoire ikea, pourquoi pas pour cliquer au bon endroit ? Faudrait-il vendre toutes les machines en kit ?

Et puis l'exemple du sport n'est pas completement pertinent: en soi, la culture sportive n'apporte strictement rien a l'homme, si ce n'est le plaisir de l'expression de sa passion. Ce n'est pour lui ni un besoin ni une necessite.

Par contre, l'informatique est un outil de travail pour beaucoup, et un outil ca s'entretien, on apprend comment l'utiliser pour etre vraiment plus efficace avec et que ca ne nous apporte pas plus de galeres que ca nous en enleve.

Donc, je ne comprends toujours pas pourquoi Madame michu ne fait pas le strict necessaire pour ne pas avoir a dependre de son petit-ils (qui habite a 500km de chez elle).

Si moi, n'etant vraiment pas fan de taule qui roule je suis capable de changer une roue, une batterie ou une bougie, pourquoi ne sait-elle pas cliquer sur le bouton qui clignote et qui lui pop a la gueule tous les quarts d'heure "mettre a jour votre systeme" ? Il n'y a vocabulairement rien de complique dans cette phrase.

Ça ne les intéresse pas, ils ne vont faire aucun effort pour apprendre quelque chose dans ce domaine, et ils sont dans leur droit le plus légitime.

Certes, pour ce qui concerne par exemple les concepts du libre, ou même à la limite "lancer Google".

Pour rejoindre un peu ce que dit Amaury : le problème c’est que le jour où la page d’accueil du non-informaticien se retrouve changée par accident, il ne sait plus se balader sur Internet. Bien sûr, il appelle son neveu/voisin/facteur qui « s’y connaît » à la rescousse, qui essaye de lui expliquer que non non, Google n’a pas disparu de la surface de la Terre, et qui résout le problème tout en essayant d’expliquer ce qu’est une page d’accueil. Mais le non-informaticien s’en tamponne, et une semaine plus tard, quand le problème resurgit, le neveu/voisin/facteur est reparti pour un tour de manège.

Alors autant je peux comprendre qu’on n’en ait rien à faire des concepts du libre, autant c’est plus embêtant quand on pense que ça ne dérange pas le neuveu/voisin/facteur de venir faire 153 fois une manipulation tout simple parce que le non-informaticien ne veut pas faire l’effort de comprendre.

Étant perçu dans mon entourage proche comme "l'expert en informatique" (comme quoi tout arrive), je trouve bien plus agaçant cette manie qu'ont certains de mes amis à s'imaginer que règler leurs petits pépins représente un challenge intellectuel que je me dois de relever. Je n'appelle pas mes amis artistes pour repeindre mes toilettes après tout. Ceci dit, le hobbyiste passionné peut être horriblement agaçant aussi. Les grandes campagnes d'évangélisation qui fleurissent sur le net pour un navigateur, un langage ou tout autre logiciel minoritaire (à divers degrés), même si elles partent d'une bonne intention, se transforment bien trop souvent en guerre des chiffres, et toute cette énergie serait probablement bien mieux utilisée à contribuer à un projet phare mettant en valeur le-dit logiciel.

Je pense que tu as une vision très juste du problème des "spécialistes" et des gens que ça n’intéresse simplement pas.

Par contre, si je conçois bien que pour "ma mère" la question du logiciel libre soit de l’ordre du méta-physique, ce qui me choque vraiment, c’est dans le milieu professionnel, lorsque quelqu’un refuse de sortir de sa "petite" spécialisation (ex : "Non, moi je code _uniquement_ en tel langage, le reste, je n’y touche pas.").

Pour le probleme d'emacs, passer a la 23.2 devrait regler le probleme.

Sinon, une solution simple est de passer emacs en fullscreen, puis de le remettre en normal, et il reoccupe toute la place que lui alloue la fenetre.

Encore une autre solution est d'assigner emacs a un bureau et de ne pas switcher directement sur ce bureau quand on le lance.

Sinon, pour les utilisateurs de wmii, je vous propose de regarder du cote d'i3.
C'est fait par des gars qui utilisaient wmii mais qui lui trouvaient quelques petits defauts, notemment sa mauvaise/non gestion du multi-screen.

En plus de bien gerer le multi-ecran, les conteneurs (equivalents de colonnes sous wmii) sont sur les deux dimensions, et sont deplacables ou l'on veut.

Par contre, ne prennez pas la version dans votre gestionnaire de paquets, c'est un projet qui evolue tres vite et ces versions sont plutot obsoletes, referrez-vous plutot a la version git.

Ça fait longtemps que je n'espère plus qu'awesome implémente une gestion des colonnes à la wmii (le dev disait "oui oui pour la 3.1 ça sera possible", mais je vois rien sur le web qui en parle pourtant c'est demandé), donc je reste dessus même si awesome a plus de features.

drk-sd : http://i3.zekjur.net/

Moi j’ai testé le multi-écran sous wmii, ça marche pas. Donc les rares fois où j’en avais besoin j’utilisais xmonad justement. Mais j’ai jamais eu la motivation pour configurer le truc. Du coup pour une utilisation quotidienne je suis resté à wmii qui démande un minimum de configuration (j’ai changé de touche mode et de term) et me convient parfaitement.

Voilà voilà.

Je ne suis pas fan de l'administration de mon système (et d'ailleurs je suis encore plus incompétent dans ce domaine que dans les autres, donc hum…) Il faudrait peut-être que je teste un jour XMonad, la configuration en Haskell a l'air sympa, mais je dois avouer que pour ce que j'en ai vu, je ne suis pas fan niveau esthétique. Enfin on verra, peut-être que je n'ai pas vu les bonnes captures. :-' 

Sinon, moi je n'ai pas le bug d'Emacs avec awesome.

Pour les problèmes de licence, je voulais dire ion, et non pas ratpoison. J'ai testé ratpoison aussi mais c'est trop spartiate à mon gout.

Ce billet peut être intéressant pour faire naitre des vocations, il est par contre dommage que tu n'aies pas testé d'autre tiling window managers, pour pouvoir comparer.

Moi j'ai utilisé ratpoison, qui était bien mais il y a eu des problèmes de licence alors ça m'a un peu démotivé. Actuellement je suis sous wmii et j'en suis assez content. La configuration se fait via un script shell ce qui est plutôt satisfaisant, par contre je n'ai pas encore testé le support du multi-écran, ce qui est quand même une feature indispensable pour certains. Je précise que le bug lié à Emacs est aussi présent sous wmii, il l'est en fait sous tous les tiling window manager je pense. On peut le contourner en utilisant emacsclient.

Did not find this story boring at all :) . Please keep up the hard work on this project, I can think of at least 42 tasks where xmlgrep and xmlsed could be very helpful (for example, I would really like to be able to create an intelligent grep for C files which works on the code AST instead of lines) !

By the way, I’ll try to find some time during next week to create a xmltools-git package on AUR (Archlinux User Repositories).

Hum, ouais, avant on écrivait facilement x << 1 au lieu de x * 2. C’est d’ailleurs pas mal resté, dans certains cas. Mais yavait des trucs bien plus gores, genre des macros REGISTERn qui sont remplacées par des déclarations register selon la machine (ça permettait de classer par priorité les variables à mettre dans des registres ; les suivantes devenaient automatiques).

À propos de rugosité, je suis tombé récemment sur un assez vieil (2003) article sur MSDN sur comment rendre le code managé rapide et on peut y lire :

Good C programmers knew. Each operator and operation in C, be it assignment, integer or floating-point math, dereference, or function call, mapped more or less one-to-one to a single primitive machine operation.

C’est de moins en moins vrai avec l’avénement des compilateurs optimisants modernes, mais il y a toujours une certaine vérité à cela, en ce que l’on peut se donner une vague borne pessimiste sur nos performances, en gros. :p

Après, pour ce qui est d’instruire au compilateur comment effectuer certaines optimisations, euh… je ne vois pas trop où tu veux en venir. Tu peux développer ? Au final, on est limité au niveau langage, on ne peut pas vraiment toucher au-dessous. Que suggères-tu ? À quels langages penses-tu ?

J’ai toujours trouvé dommage qu’en C, les optimisations ne soient que locales : Il est facile de rajouter une couche d’abstraction pour spécialiser un bout de code avec des macros, mais le gain est limité au programme courant. Passer au cap supérieur et instruire directement le compilateur d’une optimisation possible n’est pas aussi simple que, par exemple, abstraire une fonction d’un bloc de code répétitif.

À mes yeux, il semble y avoir une ambivalence entre le désir d’être explicite (j’écris x.foo et j’ai une bonne idée mentale du code produit par le compilateur) et le désir d’être efficace, c’est à dire de rajouter des optimisations non existante dans le compilateur (ou qu’on suppose non existante.) Avec ton exemple, on perd complètement l’explicite et on obtient quelque chose d’assez boite noire, mais qui "fait le travail."

J’ai envie de penser que les "optimisations" suivantes devaient exister lors des premiers compilateurs (non-optimisants) (bien qu’elles aient probablement toujours été écrites directement) :

#define MUL(x, y) (x) * (y)
#define MUL2(x)   (x) << 1

En résumé, je ne suis pas sûr d’apprécier la distance entre ces optimisations de bas niveau et le compilateur (le pré-procésseur et l’assembleur étant placés aux extrêmes), mais ça résume assez bien ma vision du C. C’est un langage assez riche et compliqué, mais il est rugueux : Chaque concept est clairement délimité syntaxiquement, ce qui introduit sa dose de complexité au niveau de la grammaire, mais permet aux programmeurs de s’agripper solidement.

En Scheme, le problème est inverse : Il n’y a pas de rugosité du tout et le programmeur est perdu. Je trouve donc amusant que les macros C, qui sont nettement inférieures aux macros Lisp, aient l’avantage de cette limitation pour la structuration intellectuelle du programmeur. "S’il y a de la magie, elle tient toujours dans ma tête." Le problème n’est donc pas la notation préfixe mais "qu’est-ce qui se passe derrière ?"

D’une certaine manière, je trouve qu’OCaml a hérité de cette rugosité vis à vis des records, des accès aux tableaux et des constructeurs. Et ça m’emmerde à chaque fois que je les utilise. :)

Plutôt que de reciter Lisp et Forth, qui sont des solutions à mon goût à ce problème, mais qui souffrent également de leur solution, voici un lien qui propose d’utiliser des compilateurs orientés "extensions" pour le C : http://pdos.csail.mit.edu/xoc/ .

Je m’intéresse assez aux à la question de l’encodage, dans un langage plus bas niveau, des fonctionnalités d’un langage plus haut niveau. C’est un outil qui permet de comparer différents langages entre eux (tant d’un point de vue pratique que théorique : la traduction d’une solution vers une autre est une façon courante pour des chercheurs en langages de programmation de comparer ces solutions). J’ai récemment fait un monologue à ce sujet sur le siteduzéro.

Le point de vue que tu abordes est légèrement différent, puisqu’il est centré sur "le langage bas niveau" : en général, on discute de ce qui se passe quand on change de langage pour avoir des constructions plus haut niveau, et on néglige un peu les irréductibles qui veulent conserver leur langage d’avant, et utiliser quand même un style moderne. Les utilisateurs de C ont ce point de vue et c’est assez intéressant. Par ailleurs, la question de la portabilité est assez évidente quand on en parle, mais je n’y avais pas spécialement pensé avant, merci. Cela dit, au sujet de la portabilité, j’ai l’impression que beaucoup de langages font des choix d’implémentation relativement platform independent, comme une machine virtuelle, un bytecode, ou un langage plus bas niveau (C--, LLVM, ou même directement C), et spécialisent la partie bas niveau seulement dans ces couches là, qui sont plus basses que le C. Bien sûr, il y a quand même des choix qui sont fait très tôt, et la question des pointeurs que tu décris en fait sans doute partie.

Une autre application des études de la traduction langage-langage est l’étude de la méta-programmation à l’intérieur d’un langage donné. Par exemple, on peut considérer une partie de la métaprogrammation des LISP (macros et cie.) comme des éliminations d’abstraction syntaxique.

Excellent ! Moi à qui on avait toujours dit que goto c’est le Mal, ça fait du bien d’être libéré d’un coup là. :p