Ours & Hippy — le blog

Investissement personnel

(4.1)

rz0

Le public pas si général que ça associe souvent l’image du programmeur autodidacte à la culture geek. Et beaucoup de jeunes techno-enthousiastes se mettent en tête d’apprendre à programmer.

Vous reconnaissez-vous dans cette image ? Je ne vais pas nier que nous sommes tous plus ou moins geek (dans le sens où nous apprécions des usages de l’informatique un peu marginaux), mais l’étiez-vous avant de programmer ? Si oui, cela a-t-il été un facteur dans votre décision de commencer à apprendre en autodidacte ?

alp

Non je n’étais pas vraiment à fond dans l’informatique « grand public » avant d’attaquer la programmation au tout début de chez tout début. Je me reconnais dans geek selon la définition qu’on donne à ce mot. Je suis passionné par des domaines de l’informatique tout comme je le suis par beaucoup de domaines en mathématiques, ou en science en général. Et si geek est considéré ici comme désignant une personne qui est tellement passionnée qu’elle peut passer des heures et des heures, coupée du reste, à apprendre des choses, pratiquer, etc, alors oui. Dans tous les cas, non ça na pas été un facteur dans ma décision de commencer à apprendre la programmation en autodidacte. C’est vraiment la curiosité intellectuelle qui m’y a poussé.

bluestorm

Je pense que j’étais effectivement déjà curieux du fonctionnement des ordinateurs avant de commencer à programmer. Mais je ne connaissais pas du tout la culture geek à l’époque, qui n’a jamais été une motivation et dans laquelle je ne me reconnais toujours pas. Quand j’ai commencé la programmation, je considérais cette activité comme un jeu de l’esprit basé sur l’abstraction, un peu comme des mathématiques très appliquées, et pas du tout un outil pour créer des jeux vidéos, faire des blagues à ses amis ou pirater l’ordinateur de son voisin…

rz0

Pour ma part, ce n’était pas vraiment le cas. Je jouais un peu, je bidouillais trois fois rien pour avoir un beau fond d’écran et un thème Windows sympa, mais voilà tout. Geeker en venu après, au fur et à mesure que j’apprenais à mieux comprendre l’informatique.

Je trouve cela même quelque peu dangereux que l’amalgame soit si facile. Généralement, je n’aime pas que l’on me confonde avec le mec qui est au courant des derniers gadgets à la mode, suis l’actualité vulgarisée de tous les domaines possibles et imaginables de l’informatique, et possède sa carte de membre au parti^Wfanclub Apple/Google/Microsoft/etc. du coin. Cependant, pour le novice, apprendre à programmer pour se sentir plus geek est une motivation initiale comme une autre, que je ne critique pas ; mais je ne pense pas non plus qu’elle puisse demeurer la raison maîtresse qui continuera à guider l’apprentissage. Si elle ne laisse pas place à des objectifs plus sérieux, l’investissement ne sera pas au rendez-vous, et avec lui le niveau…

(4.2)

rz0

Revenons sur l’investissement. C’est une question difficile. Combien d’heures, de jours, de mois, faut-il consacrer à son apprentissage, et avec quel rythme, pour espérer devenir « bon » ? Je doute que quiconque ici ait la prétention de pouvoir apporter une réponse définitive à cette question.

En revanche, je peux répondre à la suivante : quel investissement m’a-t-il fallu pour arriver là où je suis aujourd’hui ? Si l’on s’en réfère à la fameuse règle des 10000 heures, je dois avoir fait mon quota. Est-ce que cela fait de moi un expert ? Faut voir. Avec la définition toute relative que certains ont de « maîtriser quelque chose » (en particulier sur les CV), je suis certainement un expert en pas mal de choses. :D Blague à part, je dirais simplement que la clef est certainement de pratiquer, et continuer à s’auto-former, régulièrement, année après année…

Qu’en est-il de votre expérience ?

alp

Je dois avoir mon quota aussi… Si l’on veut sérieusement connaître et « maîtriser » un langage, une technologie, une théorie, peu importe, il faut y consacrer beaucoup de temps. Qu’il s’agisse d’apprendre les bases, des les consolider, ou d’attaquer des choses plus avancées, et ce en théorie comme en pratique, cela demande toujours beaucoup de temps. Si l’on est pas prêt à passer beaucoup de temps sur quelque chose, autant laisser tomber l’idée de pouvoir vraiment bien connaître et savoir utiliser le « quelque chose » en question. Pour illustrer, imaginez combien de caps j’ai franchi entre le moment où j’ai appris à déclarer un int en C++ et le moment où j’ai commencé à savoir faire de la métaprogrammation vraiment sérieuse, toujours en C++… Donc oui, il faut persévérer, refuser de ne pas comprendre, être prêt à s’investir autant que nécessaire. Note : cela n’empêche toutefois pas d’avoir une vie sociale, il s’agit de savoir gérer son temps et d’être capable de se motiver lorsque l’on a du temps à consacrer à l’apprentissage.

bluestorm

J’ai tendance à estimer grossièrement trois niveau de connaissance : ce que je n’arrive pas à faire, ce que je sais faire, et ce que je sais expliquer aux autres. Je ne sais pas si transmettre aux autres suffit pour être « bon » dans un domaine, mais personnellement ça me suffit ; ce qui est sûr c’est que ça demande pas mal de pratique, et assez (mais surtout pas trop !) de confiance en ses compétences.

Pour couvrir un domaine aussi large que la programmation, il faut sans doute effectivement une ou plusieurs heures par jour, pendant des années. Après, c’est un apprentissage progressif, il y a des choses qu’on arrive à faire rapidement, et d’autres qui peuvent résister très longtemps. J’ai encore beaucoup à apprendre et je trouve ça excitant.

(4.3)

rz0

Un autre acteur que l’on retrouve souvent dans les discussions autour de l’apprentissage de la programmation en autodidacte est le logiciel libre. Faut-il s’investir dans le logiciel libre pour réussir sa formation d’autodidacte ? Quels gains ? Quelles contraintes ?

alp

Au début : aucun intérêt. Je dirais que le meilleur moment c’est quand on est à la phase 3 (cf. dans les premières questions) car on est capable d’apporter du bon code tout en en apprenant nous-même. Contribuer aux logiciels libres vous en apprend bien plus humainement que techniquement, pour peu que votre niveau soit assez élevé. De toute manière, avant d’en arriver à pouvoir contribuer à un logiciel libre, il faut avoir réalisé des projets personnels plus sérieux qu’un petit morpion, par exemple. Mais c’est une expérience intéressante et enrichissante que de participer à un projet libre, car vous vous familiariserez avec les outils entourant les logiciels libres (subversion/git/darcs/mercurial/autres pour le versionning, mailing lists, bug tracker, etc.) et apprendrez la collaboration à échelle plus ou moins grande. Donc non il ne faut pas nécessairement s’y investir, mais ce n’est pas une mauvaise chose et si vous en avez l’occasion cela s’avèrera probablement enrichissant.

bluestorm

Pour moi, aimer la programmation conduit naturellement à un soutien du logiciel libre. Une fois qu’on réalise que le code source est essentiellement une façon de transmettre des idées, on est conduit à souhaiter que ces idées soient distribuables, réutilisables et améliorables.

Le logiciel libre est aussi une chance pour celui qui veut apprendre à programmer : cela fait plein de code déjà écrit qui n’attend que d’être lu et compris. On apprend beaucoup en regardant comment font les autres, beaucoup plus qu’en se contentant de répéter les mêmes pratiques personnelles.

Ce qui est aussi essentiel à mon avis, c’est rencontrer une critique de ce que l’on fait. Demander des commentaires aux autres, les inciter à juger notre travail. Les communautés de logiciel libre sont de bons endroits pour le faire, mais cela peut aussi se faire ailleurs.

rz0

Ma contribution au libre est très récente et quasi inexistante, aussi, je n’ai pas grand chose à dire sur le sujet. Tout ce que je peux remarquer, c’est qu’elle ne m’a pas été nécessaire pour en arriver où je suis ; avec de la volonté et des idées, je considère qu’il est tout aussi productif de se fixer de petits projets à soi.

Technique

(5.1)

rz0

Pour démarrer avec les questions techniques, parlons de langages de programmation. Quels sont vos langages de prédilection ? Depuis combien de temps les pratiquez-vous ? Qu’est-ce qui a arrêté votre choix ? Envisagez-vous d’en changer bientôt ?

alp

Les deux langages que j’utilise vraiment souvent et couramment sont C++ et Haskell. Je pratique le C++ depuis mes 15 ans, ce qui fait donc six ans environ. Concernant Haskell, je le pratique depuis un peu plus d’un an à peine, mais très intensivement. Je suis resté sur C++ car bien que considéré comme complexe, il s’avère offrir une énorme puissance lorsque l’on combine les paradigmes, ce qui permet d’écrire du code assez bas-niveau avec une certaine abstraction, par exemple. Bref, en C++ on peut vraiment aller dans la direction que l’on veut, il suffit de savoir comment le faire, et c’est ce que j’ai appris avec les années et de très bonnes ressources. Concernant le Haskell, c’est principalement l’élégance et la communauté qui m’ont séduit. Beaucoup de bibliothèques/outils, le tout avec une façon de penser totalement fonctionnelle, et bien d’autres features qui m’ont plu. Plus j’en fais, plus j’en apprends, et plus je suis content de mon choix. Après toutes ces années à m’intéresser à pleins de langages, je pense que je tiens mon duo de choc et je n’envisage vraiment pas d’en changer.

bluestorm

J’utilise encore principalement OCaml. Entre le moment où j’ai appris OCaml pour faire de l’algorithmique, et la période où je me suis fixé en OCaml pour l’ensemble de mes besoins en programmation, j’ai fait des essais avec d’autres langages plus populaires (C, PHP), pour voir du pays. Plus tard, j’ai aussi appris progressivement le Haskell, qui est un langage très intéressant et qui serait un choix raisonnable, mais je trouve OCaml plus pratique comme langage généraliste : c’est un bon compromis entre l’élégance des langages fonctionnels statiquement typés et la simplicité à l’exécution.

J’aime bien lire du code même dans les langages que je ne connais pas ou très mal, et modifier des programmes pour les adapter à mes besoins. Il m’arrive donc occasionellement de toucher à du code Python, ELisp, PHP, des scripts shell, etc. Ce ne sont pas des langages de prédilection, mais parfois il faut faire des efforts pour se coordonner avec les autres. Il y a aussi les langages intéressants à apprendre, mais que je ne pratique pas du tout : Erlang, Prolog, Oz..

Je n’envisage pas de changer bientôt de langage principal, mais il y a des langages que je voudrais avoir le temps de découvrir (Scala, Forth, ATS) et j’aimerais faire plus de Coq. Tous les langages ont des défauts, et je pense qu’on peut faire mieux que ce qui existe : je changerai certainement de langage à long terme.

rz0

Pour ma part, le C m’a bien servi durant ces huit–neuf dernières années, et je n’ai pas tellement l’intention de le remplacer maintenant. Cependant, je cherche toujours un langage de script pour complémenter mon usage. Le script shell devient vite maladroit ; pour l’heure, je n’ai rien trouvé à mon goût…

(5.2)

rz0

Parlons un peu du parcours qui vous a mené à vos choix actuels : Par quels langages êtes-vous passés avant d’aboutir à votre outillage actuel ? À quel point avez-vous commencé à incorporer l’algorithmique dans votre apprentissage ? Et l’usage des outils (débogueur, gestionnaire de versions, etc.) ? Quelle place pour le génie logiciel ? Enfin, conseilleriez-vous aux débutants de suivre la même voie ?

alp

Dans l’ordre plus ou moins chronologique : Visual Basic, C, C++, HTML, PHP, CSS, Javascript, Java, Prolog, Python, OCaml, Haskell ; ce sont les langages auxquels j’ai vraiment touché un minimum. J’ai quelques connaissances en assembleur, (Emacs) Lisp, Pascal, etc. mais rien qui ne mérite vraiment d’être mentionné.

J’ai incorporé l’algorithmique assez tôt. Cela vient principalement du fait que j’ai toujours bien aimé les maths et j’ai donc assez tôt voulu résoudre des problèmes de maths avec des programmes, et il se trouvait que par enchantement mes algos était un cas particulier d’un algo plus connu, etc. Par contre, mon apprentissage structuré et solide de l’algorithmique est arrivé bien après. Et je suis d’ailleurs loin d’être un as dans le domaine, je vais régulièrement voir mon Cormen pour lire ou relire des passages. Le débogueur est arrivé quand j’ai commencé à faire des trucs non triviaux en C++ et que j’avais des bugs « mystiques » comme il nous arrive tous d’en avoir et que l’on n’arrive pas à résoudre à coups de std::cout << "Je suis dans MaClasse::MaFonctionMembre()", std::cout << "Je rentre dans cette fonction et tel et tel trucs valent ceci et cela" et j’en passe. Donc bien au bout d’un an et demi ou deux ans. Les gestionnaires de versions, wouah, là c’est carrément bien plus tard. J’ai dû commencer au bout de quatre ans environ, quand j’ai pour la première fois travaillé sur un projet avec d’autres personnes dans un cadre plus ou moins sérieux. Bref, cela ne fait pas si longtemps que « j’utilise des outils de grands ».

En ce qui concerne le génie logiciel, disons que c’est à mes yeux pas mal attaché à l’aspect « business » du développement, qui m’a beaucoup rebuté. Rares sont les situations où cela s’avère particulièrement pertinent selon moi de s’attacher à 400% au génie logiciel tel qu’il est pratiqué. En ayant pas mal investi le monde de la programmation fonctionnelle, je me rends compte que ce n’est pas « le design OO », les « schémas UML » ou autres qui comptent, mais la réflexion sur l’interface que l’on offre, dans un sens général. Bien sûr, on a un vocabulaire spécifique pour chaque paradigme, mais finalement ce n’est pas tant différent et il y a une majeure partie de la réflexion en amont qui demeure la même, et je trouve justement que dans le monde du « business » de l’informatique, on met tout ça de côté. Donc oui, je connais un minimum tout ça, mais non je n’ai pas tellement introduit ça dans mes projets, dans le sens « commun » de l’expression « génie logiciel ».

Enfin, j’ai un parcours similaire à bien des gens, dans le sens où j’ai pas mal vadrouillé entre les langages et paradigmes de programmation, j’ai lu des bouquins, articles, cours, tutoriels, howtos, etc. et chaque étape j’ai été amené à découvrir un nouveau langage, des techniques, des points de vue, des raisonnements, et je recommande tout simplement de se laisser « guider » comme cela, car au bout d’un certain temps de toute façon cela se stabilisera. Suivre le même parcours que moi précisément n’aurait pas vraiment de sens, car c’est ce qu’il m’est arrivé par rapport à mon expérience, aux choix que j’ai faits, etc.

bluestorm

J’ai longtemps erré sur le chemin de la programmation web (XHTML, PHP, SQL…), avant de me rendre compte que ça ne me plaisait pas. Je pense que ce qui la rend si tentante, c’est la facilité à montrer ce qu’on fait aux autres. Je me suis cependant rendu compte au bout d’un moment que ce n’était pas un environnement agréable pour programmer, entre autres à cause de la domination de mauvais outils (PHP) et de l’importance de normes à absorber avant de pouvoir faire les choses bien. Ça a l’air simple de loin, mais coder un parseur XML complet est une tâche quasiment insurmontable.

J’ai toujours incorporé l’algorithmique dans mes considérations. Je pense que j’ai mis un peu de temps avant que ça devienne vraiment naturel (sans doute un an ou deux). Il s’agit seulement des bases : quand on approfondit le sujet, l’algorithmique est un domaine extrêment technique qui ne m’intéresse en fait pas énormément.

Pour l’usage des outils, je suis extrêment paresseux et en pratique assez minimaliste et réactionnaire. Je n’ai jamais appris à utiliser un débugguer par exemple, tout simplement par flemme, et je débuggue mes programmes en ajoutant des instructions d’affichage aux bons endroits. Jusqu’à récemment, je faisais aussi très peu de tests. Pour programmer j’utilise un éditeur de texte et les outils de base de mon langage, pas d’environnements trop lourds et complexes.

Je suis par contre fortement convaincu par les gestionnaires de versions : j’ai fait l’expérience plusieurs fois du code qui « était juste il y a une heure, mais il ne marche plus du tout et je n’arrive plus à le refaire marcher », et on comprend vite l’intérêt de faire des sauvegardes régulières, et surtout expliquées, de son travail ; c’est encore plus utile quand il y a plusieurs auteurs.

J’attache beaucoup d’importance au fait de découper l’évolution du code en modifications atomique, que j’essaie de bien expliquer. On ne peut pas toujours avoir ce qu’on veut (parfois on est pressé et on n’a pas le temps de soigner cet aspect autant qu’il le faudrait), mais je crois que ça a globalement une influence positive sur la façon dont on organise les modifications de son programme.

Je m’intéresse au génie logiciel, mais j’ai parfois du mal à faire la différence entre le bon sens, les conseils de grand-mère, les choses carrément trompeuses et les idées nouvelles et intéressantes. Je pense qu’il y a beaucoup de choses à apprendre dans cette direction, mais je préfère les domaines plus formalisés, où il est plus facile de séparer l’important de l’accessoire.

Aux débutants, je conseillerais de commencer avec des outils simples, qu’ils comprennent bien, et de passer progressivement à des choses plus complètes dans les domaines qui les intéressent.

rz0

Je suis passé par le Turbo Pascal, puis je suis tombé directement sur le C, qui me suivra, à partir de là. Bien sûr, j’ai flirté avec bon nombre d’autres langages et de technologies, à partir de là. J’ai failli faire de C++ mon outil principal, et j’ai fait pas mal d’assembleur x86 également.

L’algorithmique un minimum non triviale n’est pas venue avant un bon nombre d’années, deux ou trois peut-être. Je crois que c’est autour de la Seconde que j’ai mis la main sur un Knuth (que je n’ai jamais réussi à digérer :) et un Cormen (bien plus comestible, mais j’en ai laissé des bouts…), et voilà… Et si je me suis spécialisé dans mon domaine, ce qui vaut aussi pour l’algorithmique associée, j’en apprends encore beaucoup, notamment en cours, à l’école ! Héhé, et oui, pas en autodidacte cette fois-ci…

Il en est un peu de même pour outils : cela ne m’est pas venu non plus avant bien deux ans dans l’obscurité, à déboguer à coup de printf… ça forge le caractère, dira-t-on. :p

Quant à savoir si je conseillerais le même parcours, c’est difficile à dire. Je pense que la voie de l’autodidacte est constituée d’une part non négligeable de hasard, et je pense que cet aléa fait partie de l’apprentissage : apprendre à se débrouiller, à faire la part des choses, entre ce que l’on doit savoir, et ce que l’on veut maîtriser.

Conclusion

(6.1)

rz0

L’interview touche maintenant à sa fin. Pour conclure, un mini-quizz !

1. Les trois plus importantes qualités d’un autodidacte ?
2. Le plus grand piège à éviter quand on débute ?
3. Le bon âge pour commencer ?
4. Livre ou cours sur Internet ?
5. Algorithmique avant langage, langage avant algorithmique, ou les deux en même temps ?

alp

1. Curiosité intellectuelle, persévérance et être débrouillard(e).
2. Ne pas faire face aux problèmes rencontrés (faire faire par quelqu’un d’autre, etc).
3. Fin du collège, lycée.
4. Livre si possible !
5. Un peu de langage, de quoi pouvoir implémenter les algos de base, avant d’apprendre l’algo, et ensuite apprendre les deux en parallèle.

bluestorm

1. Curiosité, persévérance, rigueur.
2. Se laisser entraîner vers des choses pénibles ou fastidieuses par

   envie de plaire aux autres.

3. N’importe quand, tant qu’on est vraiment intéressé.
4. Les deux : comparer les différentes sources.

5. En même temps. Pratique et théorie.

rz0

1. Curiosité intellectuelle, ténacité, résistance (à l’échec, aux conflits, au ridicule, etc. :-°).
2. Sombrer dans la justification de l’improductivité.
3. Collège ou lycée, quand on n’a rien à faire de ses journées.
4. Ça dépend si on est pauvre…
5. Langage avant algorithmique, pour moi… pas trop avant non plus, mais histoire d’avoir un truc avec lequel appliquer, quand on attaque l’algorithmique.

(6.2)

rz0

Un dernier mot pour vos fans ? ;)

alp

Comme le dit dangerous, et tous ceux qui le connaissent le reconnaîtront bien là, « Y’a pas de secret, faut bosser ! ».

bluestorm

J’espère ne pas avoir de fans ; pour programmer, les idées sont plus importantes que les gens.

Depuis quelques billets, je suis coupable d’une forme de lâcheté et de procrastination tout à fait scandaleuse. En effet, je réponds rarement aux commentaires que les gens écrivent sur mes billets.

Dans le fond, je trouve que c’est très mal, mais j’ai aussi des excuses. D’une part, je publie souvent mes billets un certain temps après leur écriture, ou du moins le début de leur rédaction. Je suis très content quand j’ai l’impression qu’ils intéressent les gens, et je lis leurs commentaires avec avidité, mais je suis parfois moi-même un peu décalé et je renâcle devant l’effort de me replonger dans le bain, pour avoir une bonne vue d’ensemble du billet et pouvoir répondre à un commentaire en particulier.

D’autre part, vu la taille de mes billets, j’essaie plutôt de me faire discret dans la section commentaires. Après avoir attendu avec impatience les premiers commentaires, l’envie est forte d’y répondre une tartine sur le champ, mais il faut aussi savoir laisser les gens s’exprimer pour rendre du recul et ne pas écraser la conversation.

Sachez en tout cas que ce n’est pas parce que je ne réponds pas aux commentaires que je ne les vois pas. Je les lis tous, et ça me fait plaisir d’en avoir, alors n’hésitez pas à continuer.

Ce présent billet est en fait né comme une réponse à un commentaire. En effet, bien qu’il ne soit pas de moi, je me sens concerné par les commentaires sur le billet La voie de l’autodidacte (1/2). terres y a fait une remarque sur une des questions que pose rz0, remarque se plaçant en opposition à ma propre réponse. C’est intéressant et ça m’a donné envie de développer un peu plus mon point de vue. Ce qui est né comme un commentaire un peu plus long que d’habitude est finalement devenu un billet un peu plus court que les autres.

Pour bien replacer le contexte, je vais citer ici la question de rz0, la partie de ma réponse qui est concernée, et enfin la partie commentaire qui m’a fait réagir.

Question de rz0 :

Cela m’a pris un bon nombre d’années (je dirais bien six ou sept ans au moins) avant de produire du code utilisable « dans la vie ». Pour moi, il y a donc une phase improductive nécessaire, durant laquelle on apprend sans se soucier du résultat, juste pour apprendre, avant la phase productive, où, par définition, on tente de produire quelque chose (et l’on doit y sacrifier une partie du temps que l’on aurait pu passer à apprendre).

Le même constat vous a-t-il frappé ? Y a-t-il eu des rechutes dans l’improductivité ? Si oui, comment vous en êtes-vous sorti ?

Ma réponse :

Ce n’est pas l’état improductif qui est anormal ; c’est l’inverse ! Pendant l’apprentissage, tout est excitant, on essaie de nouvelles techniques et on apprend de nouvelles choses. Quand on essaie de produire quelque chose de définitif, il faut se mettre à se soucier de tous les détails pénibles (documentation utilisateur, distribution…). C’est encore pire quand on a des utilisateurs ! Se forcer à finir un produit, c’est accepter de passer du temps sur des choses sans intérêt, pour en conterpartie être utile à quelqu’un d’autre que soi-même.

Le commentaire de terres :

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.

En tant qu’amateur de programmation, quand j’écris un programme je m’intéresse au processus de développement, au code, etc. J’ai aussi souvent un regard de développeur sur les programmes des autres : je regarde leur code, comment ils ont transcrit leurs idées.

Par rapport à un programme, on peut aussi avoir une position d’utilisateur : on regarde le produit fini, ce qu’il fait et comment interagir avec lui. Ce sont deux aspects orthogonaux, mais que l’on peut combiner en appréciant les programmes à la fois d’un point de vue développeur et d’un point de vue utilisateur ; c’est d’ailleurs souvent comme ça que j’approche les logiciels libres.

Le terme « productif », sorti du contexte, est assez vague. Il désigne essentiellement le fait de faire un effort dans une direction avec efficacité : arriver à son but, et si possible rapidement.

Il y a donc deux ici dimensions de productivité :

• Productivité pour le développement : est-ce que j’arrive à écrire du code propre et de qualité ? Est-ce que mon programme tient la montée à l’échelle, c’est à dire qu’il peut se complexifier et grandir en conservant une structure propre et modulaire ? Est-ce que je peux arriver à une version correcte du code, sans passer par un grand nombre d’étapes intermédiaires incorrectes et de cycles de corrections de bugs ? Est-ce que mon code est facile à maintenir et permet l’ajout de fonctionnalités ?

• Productivité pour l’utilisation : est-ce que les fonctionnalités utiles sont présentes ? Le programme est-il facile à installer et à utiliser ? Y a-t-il des utilisateurs satisfaits de ce programme ? Est-ce qu’il est utile ?

La définition de rz0 est légèrement ambiguë : « produire du code utilisable dans la vie ». Est-ce qu’il est utilisable parce qu’il satisfait des standards de qualité, ou est-ce qu’il est utilisable parce qu’il est destiné à être utilisé ?

Alp semble traiter principalement le premier aspect, la productivité de développement. Ma réponse se concentrait au contraire sur le second aspect, le rapport aux utilisateurs.

Pour moi, un programme est destiné à être utilisé si l’on est dans l’une des situations suivantes :

1. On se force à développer un programme dans le but de l’utiliser soi-même et-ou de pousser d’autres gens à l’utiliser. Situation courante chez les développeurs de petits projets libres.

2. On est forcé par quelqu’un d’autre à écrire un programme qu’il souhaite utiliser pour répondre à ses propres besoins. Situation courante dans le monde de l’industrie, mais aussi pendant un stage, etc.

Bien sûr, il y a aussi des cas limite où la personne ayant besoin du programme est en fait un groupe de personne auquel on appartient. Je pense que pour bien distinguer les deux situations (ou un intermédiaire entre ces deux situations), il faut se poser la question suivante : « Va-t-il vous arriver quelque chose de désagréable si, finalement, le programme ne répond pas aux besoins ? »

Attention, je ne parle pas de la deuxième situation comme d’une forme d’exploitation ou de torture où le développeur est maltraité. Au contraire, je pense que c’est celle des deux que je préfère : un peu de contrainte pour garder sa motivation, des utilisateurs extérieurs avec qui discuter pour aider à résoudre certains choix délicats, et surtout la sensation agréable de travailler à améliorer la vie d’autrui. Bien sûr, il faut que le sujet soit intéressant.

Cependant, dans ces deux cas, ces programmes sont placés sous le signe de la contrainte. Et, dans ces deux cas, atteindre un stade où l’utilisation est agréable demande de faire des efforts sur un grand nombre de petits détails qui ne sont pas forcément intéressants ni même agréables, et dont on n’avait pas besoin de se soucier tant qu’on s’intéressait surtout à l’expérience de développement, la qualité du code, etc.

C’est une expérience différente, qu’il est bon d’avoir fait ou de faire, et qui est elle aussi très formatrice. Cependant, je la trouve tout de même sensiblement moins intéressante que l’expérience du développement du cœur du programme. C’est ce que j’ai essayé de faire passer dans ma réponse : apprendre c’est bien et on est libre, être utile c’est bien aussi mais il y a des contraintes qui vont avec.

Introduction

Pour répondre à la demande populaire, je me dois de vous présenter, cher lecteurs, les protagonistes du jour :

bluestorm

L’autre auteur du blog, celui qui fait généralement dire « oulala, ya des trucs compliqués sur ton blog » et m’oblige à répondre « nanan, c’est pas moi, c’est pas parce que j’ai les cheveux longs que… ». Aime bien la théorie qui théorise bien, quand c’est tout formel, tout beau, et tout et tout. Un autodidacte avec quelques années dans le bidou.

alp

Un sale hérétique qui fait du C++ et nous vient de developpez.com, même s’il le cache bien, maintenant (juste developpez.com, pas le C++, ça il en est fier…). S’intéresse à divers trucs… trop divers, même, et a choisi de faire des maths dans la vie, au lieu de devenir riche et puissant avec l’informatique, mwahahaha, ahem. Un autre autodidacte de longue date.

rz0

Moi. Hum, j’ai la flemme et je vais dormir, là. Mais je vous suggère de lire cet article Wikipédia sur les cochons d'Inde, qui aura occupé ma soirée, à la place. (Comprendra qui pourra. :-°)

Motivation

(1.1)

rz0

Quel facteur vous a-t-il fait découvrir la programmation ? À combien de temps cela remonte-t-il ?

alp

Mon père avait quelques petites notions de programmation (basic, tout ça) et on s’était intéressés ensemble à Game Maker, un logiciel pour faire des jeux avec une partie scripting invoquée lorsque des évènements se produisent. Je crois que c’est la première fois que j’ai « programmé », avec l’aide de mon père ; je devais avoir 11 ans.

bluestorm

J’ai découvert la programmation il y a 7 ans.

Au milieu de mon année de seconde, un ami m’a montré un jeu qu’il avait sur sa calculatrice. Je ne me souviens plus du jeu, mais je me souviens que j’ai découvert qu’il était stocké dans un fichier de code source (c’était du TI-Basic). Je ne comprenais rien au langage, mais j’ai repéré les chaînes de caractères affichées pendant le jeu, et je les ai modifiées pour afficher des messages plus amusants.

Après une observation plus attentive du code source, j’ai pu essayer d’écrire mon propre jeu; je ne me souviens plus de ce que j’ai fait en premier, mais j’ai écrit ensuite un Puissance 4 à deux joueurs. Pour remplir les bords de l’écran, je lui faisais afficher aléatoirement à certains tours des smileys. Les amis qui l’ont essayé étaient persuadés qu’il analysait les parties pour mettre un smiley souriant au joueur gagnant, et un smiley triste au perdant.

Je n’ai pas continué longtemps la programmation sur calculatrice (pour commencer, je n’avais pas moi-même une calculatrice programmable). Mon professeur de mathématiques, que j’appréciais énormément, était responsable d’un « club Algo » au lycée. Un ami y participait, et je me suis décidé à y aller un soir pour voir à quoi ça ressemblait : il y avait quelques personnes qui suivaient des cours en ligne pour apprendre à programmer, et d’autres plus avancés qui faisaient de l’algorithmique. Il fallait choisir un langage à apprendre, et cet ami faisait du C ; mais je suis tombé, par hasard, sur un étudiant de classe préparatoire qui m’a expliqué d’un ton mystérieux que « si tu aimes les maths, il faut faire du Caml ». J’ai été tenté, et ça m’est resté.

rz0

Pour ma part, j’ai d’abord essayé tout seul, puis ça n’a pas pris, et, quelques temps après, j’ai rencontré quelqu’un qui m’a dit qu’il « écrivait des logiciels » ; je lui ai demandé de m’apprendre, et c’est ainsi que tout a commencé, il y a maintenant bientôt dix ans…

(1.2)

rz0

Comme beaucoup de gens, pendant quelques années, j’ai eu des ambitions très peu modestes : jeux, systèmes d’exploitation, etc. Au final, ça m’a fait voir du pays. :)

Était-ce pareil pour vous ? Quelle était votre motivation originelle ? Était-elle réaliste ? Combien de temps vous y êtes-vous tenus ? En rétrospective, vous ont-elles aidé à avancer ?

alp

De ce côté là, j’ai toujours été assez réaliste. J’ai peut-être au tout début eu des ambitions bien grosses par rapport à mes connaissances et à mon expérience, le seul example me venant à l’esprit étant, en bon marseillais que je suis, l’écriture d’un jeu de pétanque 2D avec deux autres personnes alors que je débutais en C++. On avait commencé, mais c’est vite tombé à l’eau par manque de motivation et disponibilité. Donc c’était très peu réaliste (pour moi), ça n’a pas duré plus de deux mois et donc ça n’a pas eu tellement d’impact si ce n’est que tous les projets que j’ai fait après cela ont plus ou moins tous été relativement cohérents vis à vis de mes connaissances et de mon expérience.

bluestorm

Je ne me suis jamais lancé dans des projets énormes. La méthode des membres du Club Algo était de donner de petits problèmes à chercher, de plus en plus difficiles, et on apprenait en trouvant tout seul la réponse, en demandant des indications, puis en étudiant les solutions données. Très vite, j’ai trouvé des cours plus avancés (je me suis concentré sur le Caml, plutôt que de faire de l’algorithmique), et j’ai dû choisir mes sujets moi-même, mais j’ai conservé cette méthode.

J’ai toujours été plus motivé par la façon de programmer que le résultat final. J’ai trouvé un cours de Caml assez complet (le DA-OCAML) que j’ai essayé de lire en entier, en faisant des efforts pour utiliser chaque fonctionnalité du langage. Ça m’a pris du temps (sans doute environ un an), mais j’ai beaucoup appris, et surtout un peu de tout : beaucoup de programmation fonctionnelle, un peu d’impératif, mais aussi un peu de graphique, de parsing, de bas niveau, de l’objet, du système, du réseau… Ça donne un point de vue d’ensemble.

Après-coup, je me rends compte que certains des exercices, si j’avais eu envie d’aller jusque au bout, d’écrire un système équivalent à ce qui existait, auraient été (beaucoup) trop gros pour moi. Je pense en particulier à une petite bibliothèque GUI (avec les primitives pixels par pixels de Caml, que du bonheur…), un forum Web (quand j’ai appris le PHP l’été suivant), et un serveur Web en Caml. Mais je n’avais pas d’ambition : après avoir obtenu quelque chose de simple mais qui marche, je suis passé à autre chose.

(1.3)

rz0

Quel est votre « but » aujourd’hui ? Avez-vous trouvé des domaines qui vous intéressent plus particulièrement ? Et si oui, les avez-vous rapidement trouvés ?

Pensez-vous que ce soit un facteur déterminant pour garder la motivation tout au long de son apprentissage ?

alp

Étant donné que je m’oriente vers les mathématiques académiquement, je suis naturellement attiré par tout ce qui s’en rapproche dans la programmation. Cela peut être du très abstrait comme la théorie des catégories mais aussi du très concret comme des algorithmes géometriques. Mais sinon, du point de vue du développement pur, je suis assez investi dans 2 domaines : le bon vieux C++ que j’ai commencé à apprendre il y a maintenant 6 ans, à quelques semaines près, ainsi que la programmation fonctionnelle avec les langages Haskell et Objective Caml. Le C++, je suis tombé dessus assez « rapidement ». J’avais fait mumuse avec un peu de Visual Basic et de C pur avant ça, et je me suis lancé dans le C++. Depuis, j’ai essayé bien d’autres langages mais aucun ne m’a sérieusement plu, à part justement les deux langages fonctionnels mentionnés ci-dessus, Haskell et Objective Caml. J’ai probablement commencé l’apprentissage d’OCaml il y a bientôt 2 ans, et plutôt 1 an pour Haskell — mais j’avais déjà tout le bagage d’OCaml avec moi ce qui a grandement facilité l’apprentissage. Donc pour le monde de la programmation fonctionnelle, il m’a fallu un bon moment avant de tomber dedans, et encore un moment avant de l’apprécier tout particulièrrement. En dehors de cela, de façon plus détachée des langages, je m’intéresse à des choses diverses et variées qui n’ont pas forcément traits aux mathématiques, comme les questions de design logiciel, tout ce qui tourne autour de la création de langages de programmation, le multithreading et la programmation parallèle, entre autres.

Je pense que tout autodidacte doit passer par une phase où il va un peu toucher à tout, afin de voir ce qui lui plaît. Mais effectivement après un certain moment (ça se compte en années, et pas seulement une ou deux…), avoir quelques domaines précis où l’on se spécialise en quelque sorte, est bénéfique car à mon sens cela permet d’approfondir (ce que l’on n’a pas trop tendance à faire dans la phase précédente) et d’acquérir une certaine expertise dans ce(s) domaine(s) et donc logiquement de pouvoir entreprendre la réalisation de projets sérieux dans ce domaine, ou carrément aller contribuer aux gros projets opensource liés au(x) domaine(s) en question. Et, c’est bien connu, lorsque l’on est autodidacte la motivation est généralement assez liée à la réalisation de projets !

bluestorm

J’ai envie de pouvoir implémenter ce qui me fait envie, d’une façon qui me plaît. De ce que j’ai fait au départ, j’ai gardé mon intérêt pour Caml, et plus généralement pour les langages de programmation. Je m’intéresse surtout à la sémantique (systèmes de type, formalisation des langages), à la compilation. Il y a d’autres sujets qui m’intéressent, comme la syntaxe (qu’est-ce qu’une bonne syntaxe ?), les outils autours des langages, les méthodes de programmation, etc.

Mais j’ai une préférence pour ce qui est formalisable, car la formalisation permet de faire des choix pour des raisons profondes. Quand un domaine repose uniquement sur des facteurs informels (par exemple : quel style d’indentation adopter ?), il y a souvent plusieurs possibilités mais pas de « bonne » réponse.

J’ai mis longtemps à vraiment me rendre compte de cette préférence. J’ai même fait de la programmation Web pendant plusieurs années. Je pense qu’au long de l’apprentissage, la curiosité des choses nouvelles est plus importante qu’une fixation sur un ou plusieurs sujets, tant qu’on ne se lasse pas.

rz0

En ce qui me concerne, on peut difficilement ignorer le fait que je suis particulièrement investi dans les langages, leur traitement, interprétation, compilation, etc. Ça, et le système, dans une moindre mesure. Rétrospectivement, cela a probablement été un facteur déterminant dans mon apprentissage, même si je ne l’ai pas compris tout de suite. Cela m’a permis d’arrêter les expérimentations foireuses à droite et à gauche pour me concentrer sur une direction, et lentement progresser sur cette voie.

Apprentissage

(2.1)

rz0

Pour moi, l’apprentissage en autodidacte s’est traduit par trois phases :

1. l’isolation (apprentissage dans mon coin, peur de la confrontation ; ~2 ans, dans mon cas) ;
2. l’arrogance (trop de confiance en mes compétences et mes connaissances nouvelles ; ~2-3 ans, dans mon cas) ;
3. la prise de conscience, lente et progressive (en cours :-°).

Vous y identifiez-vous ? Avez-vous un autre modèle à proposer ?

Idéalement, je pense que la phase arrogante pourrait être évitée, mais c’est un peu un effet de bord de la volonté et de l’ambition qui sont des sources de motivation majeures pour l’autodidacte. En ce sens, c’est un sacrifice raisonnable. Êtes-vous d’accord avec cet argument ?

alp

Je m’identifie totalement avec cette description. Et c’est marrant, quand on est à la phase 2 on pense tout savoir parce qu’on commence à avoir des connaissances respectables, et on cherche quelque part un peu à s’affirmer, et l’on voit pleins de jeunes autodidactes passer par cette phase, par exemple dans la communauté #sdz, qu’il s’agisse de simples « trolls » ou de discussions assez vives, ce qui ne fait que me rappeler que je suis passé par là.

Et oui, je me dis que quelque part la plupart des autodidactes « doivent » passer par là, car finalement on tire quelques leçons de cette phase — ce qui permet de passer à la phase 3 — et que c’est un sacrifice tout à fait raisonnable.

bluestorm

Je ne me reconnais pas vraiment dans les idées d’isolation ou d’arrogance (mais peut-être que d’autre m’y reconnaissent… j’espère que non). Je pense qu’il y a plutôt une série de cycles courts : au début, on a du mal avec quelque chose, on apprend progressivement comment le faire, puis il y a un déclic où on comprend bien et on veut l’expliquer aux autres, et on finit par se lasser de répéter la même chose, et passer à un autre sujet où on est à nouveau débutant.

(2.2)

rz0

Cela m’a pris un bon nombre d’années (je dirais bien six ou sept ans au moins) avant de produire du code utilisable « dans la vie ». Pour moi, il y a donc une phase improductive nécessaire, durant laquelle on apprend sans se soucier du résultat, juste pour apprendre, avant la phase productive, où, par définition, on tente de produire quelque chose (et l’on doit y sacrifier une partie du temps que l’on aurait pu passer à apprendre).

Le même constat vous a-t-il frappé ? Y a-t-il eu des rechutes dans l’improductivité ? Si oui, comment vous en êtes-vous sorti ?

alp

J’ai été frappé par le même constat. D’une part, au début de mon apprentissage du C++. Le code que j’écrivais n’était tout simplement pas assez robuste/efficace/etc. et je passais effectivement un temps monstrueux à en apprendre et en découvrir tous les jours dans mon exemplaire de « Le Langage C++ » de Bjarne Stroustrup, ainsi que d’autres bouquins, achetés par la suite. Ensuite, je commençais à bien connaître la programmation orientée objet et le C++ lui-même, mais pas énormément non plus ; j’étais tout juste familier avec les templates notamment (comparé à ce que je sais aujourd’hui, et ce qui se fait dans Boost par exemple). Et là, j’ai eu une rechute quand je me suis sérieusement mis à la métaprogrammation. J’ai passé à nouveau beaucoup de temps à apprendre et expérimenter, avant d’ensuite être capable d’écrire du code utilisable (et utilisé) «_dans la vie_». Il s’est ensuite à nouveau passé la même chose lorsque je me suis plongé dans le monde de la programmation fonctionnelle, d’abord en Objective Caml, puis en Haskell. Cela fait d’ailleurs pas si longtemps que j’écris du Haskell d’une qualité « acceptable » et je suis loin d’être au bout du tunnel pour cela… Quoiqu’il en soit, à chaque fois, c’est la motivation, la persévérance, le refus de ne pas comprendre qui m’a permis de m’en sortir et de surmonter les difficultés, bien que desfois on en ait un peu marre d’en ramer sur la compréhension d’une notion ou autre (« fuck that monoid in category of endofunctors shit » — à propos des monades).

bluestorm

Ce n’est pas l’état improductif qui est anormal ; c’est l’inverse ! Pendant l’apprentissage, tout est excitant, on essaie de nouvelles techniques et on apprend de nouvelles choses. Quand on essaie de produire quelque chose de définitif, il faut se mettre à se soucier de tous les détails pénibles (documentation utilisateur, distribution…). C’est encore pire quand on a des utilisateurs ! Se forcer à finir un produit, c’est accepter de passer du temps sur des choses sans intérêt, pour en conterpartie être utile à quelqu’un d’autre que soi-même.

Pour moi, l’important c’est de ne jamais se mentir. Si on a envie de recoder un programme déjà existant d’une façon novatrice, avec un design intéressant et tout, c’est qu’on est en phase d’apprentissage et qu’on code pour soi. Je n’aime pas qu’on prétende coder pour les autres alors qu’en réalité on s’amuse pour soi-même, sans se soucier des besoins réels des utilisateurs.

Formation

(3.1)

rz0

Comment positionneriez-vous votre formation autodidacte par rapport à la formation académique que vous avez reçue après coup ?

alp

Étant donné que je n’ai eu qu’un seul cours d’informatique pendant un semestre, dans toute ma vie, ce que je peux le plus assimiler à une formation académique ce sont les bouquins de référence utilisés par les professeurs dans le monde entier, que j’ai acheté pour me former moi-même sur ces sujets. Et pour moi ils constituent une base, solide, parfois un peu théorique, influence que je trouve complémentaire à celle de la formation autodidacte, qui consiste souvent à tâtonner, pratiquer, etc.

bluestorm

J’ai eu des cours plus ou moins théoriques qui concernaient des domaines de l’informatique, mais jamais de cours de programmation. Dans tous les cours où il y a de l’informatique, on suppose que les gens savent déjà programmer et se débrouillent par eux-mêmes pour pratiquer. Pour moi c’est donc deux choses complémentaires : la pratique est une expérience personnelle, et les cours peuvent apporter un aspect théorique qu’on n’aurait pas forcément la motivation de creuser tout seul.

rz0

Mon avis sur cette question est quelque peu partagé. D’un côté, il est clair que ma formation à l’Ensimag m’a apporté un point de vue plus généraliste et a aidé à consolider mes bases théoriques. En cela, les deux sont complémentaires. D’un autre, techniquement parlant, pour moi, il n’y a aucune comparaison possible : le cursus en école d’ingénieur (mais je crois que c’est partout pareil) ne peut rivaliser avec des années à se démêler par soi-même avec les ressources du bord ; ça donne des automatismes et ça forge le caractère. Pour reprendre le modèle ci-dessus, l’école, c’est la phase d’apprentissage, la phase improductive, dans tout son éclat ; ce n’est pas bien ou mauvais en soi, mais il faut en être conscient.

(3.2)

rz0

Avec le recul, je peux dire que j’ai appris un peu n’importe comment, chaotiquement, en lisant et en pratiquant ce que j’avais sous la main, et récursivement, en m’intéressant aux topics sous-jacents que je ne maitrisais pas. Mais je pense que c’est une bonne technique, si l’on a la motivation (et le temps) nécessaire, comme c’est le cas quand on est au collège ou au lycée. C’est une sorte de filtrage naturel : on va de soi-même vers les sujets qui paraissent intéressants. On commence avec un petit nombre de choses inconnues et à sa portée, et le processus est d’abord lent et très aléatoire, dans son contenu, mais il se dessine peu à peu des préférences, et à mesure que le contenu potentiellement accessible explose, on met instinctivement des priorités, et ainsi se forment les goûts et les vocations.

Quelle méthode avez-vous adoptée ? Était-ce conscient (wow, j’admire le méthodique) ? La conseilleriez-vous maintenant à des novices ?

alp

Moi aussi j’ai beaucoup appris de cette façon, même si avec le temps j’arrive un peu mieux à structurer mon apprentissage. Généralement, je me renseigne un minimum sur le sujet de mon apprentissage et me procure un cours ou livre de référence sur le sujet. Je peux faire ainsi car j’ai une assez bonne idée aujourd’hui des différents domaines de la programmation, en particulier de ceux qui m’intéressent. Mais ce n’était pas le cas il y a quelques temps… Toutefois c’est une bonne stratégie sur les novices, clairement, à mon avis.

bluestorm

Bien sûr, il n’y a pas de méthode miracle, pour pouvoir affiner ses goûts il faut machouiller un peu tout ce qui nous tombe sous la main. Après-coup, il y a quand même des choses qu’on se dit qu’on aurait pu faire selon un cheminement moins tortueux, par exemple en lisant directement un ouvrage de référence au lieu de s’éparpiller sur des dizaines de textes introductifs.

Ça s’apprend, et aujourd’hui j’ai une approche plus directe : trouver un bon document de référence sur le sujet, commencer par le survoler puis lire les parties qui m’intéressent. Mais pour certains sujets qui demandent plus d’efforts, on est parfois forcé de revenir au stade du machouillage pour que ce soit comestible.

Comme beaucoup d’utilisateurs d’interface graphique, je n’aime pas beaucoup la souris. Cela fait un certain temps que j’effectue la plupart des tâches avec principalement le clavier, en particulier tout ce qui doit être fait rapidement. La gestion des fenêtres en fait partie : on a envie de pouvoir passer très vite d’un logiciel à un autre (le classique Alt-Tab), d’un bureau virtuel à un autre, etc.

Cela fait donc quelques mois que j’utilise mon gestionnaire de fenêtres (quel qu’il soit, en pratique Kwin ou Xfwm selon l’humeur, mais à mon stage j’utilise Metacity) principalement avec le clavier. De là vient l’idée naturelle : pourquoi ne pas utiliser un gestionnaire de fenêtre pensé pour être utilisé avec le clavier ? Ce serait certainement encore plus adapté.

J’ai donc envisagé plusieurs alternatives (wmii, etc.), sans les tester (la flemme), et j’ai finalement choisi XMonad. C’est hype, c’est minimaliste, c’est codé dans un langage que j’aime bien (Haskell), bien conçu (Zipper et tout le tralala), bien documenté, ils insistent sur le fait d’avoir peu de lignes de code (j’aime bien), et ils essaient d’exprimer formellement et de vérifier des propriétés de leur programme (pas avec Coq, on ne peut pas tout avoir, mais avec QuickCheck).

J’ai donc fait l’effort d’installer XMonad, de lire la documentation de base (je n’ai retenu au départ que cinq raccourcis). Il y a quelques glitches (par exemple au lancement emacs n’occupe pas tout l’espace de sa fenêtre), mais qui n’en a pas ?

J’ai pris un peu de temps pour le configurer, en pratique ça veut dire installer et utiliser deux petits programmes qui « font une seule chose et le font bien », conseillés par la documentation XMonad :

xmobar

une petite barre de tâches que l’on configure en lui envoyant des infos sur l’entrée standard, simplissime.

dmenu

un outil de lancement de programme tout simple (on tappe le nom de l’exécutable jusqu’au moment où on peut auto-compléter, et on fait « Entrée ») ; écrit par les gens de suckless, qui sont cools et aiment Plan9.

Je me suis fait un fichier de configuration XMonad qui résume tout ça, au cas où ça vous intéresse. Dans la suite de ce billet, je détaillerai cette configuration. Ça n’est certainement pas une référence sur l’utilisation de ces outils, j’ai d’ailleurs sans doute fait une ou deux bêtises dans ces configurations, mais le but est de montrer que c’est plutôt facile, au cas où ça motiverait des vocations.

La base de la base

Pour installer XMonad, on peut télécharger la version de développement du code et l’installation à la main, ou passer par le gestionnaire de paquets de son système d’exploitation. La seconde version est évidemment plus simple.

Dans tous les cas, on se retrouve avec une installation plutôt de base, et en particulier un fichier de configuration essentiellement vide. Pour lancer XMonad, il suffit de partir d’une session X sans gestionnaire de fenêtres (par exemple en ayant lancé xinit depuis un terminal) et de lancer xmonad. Comme tout repose sur le clavier, il faut avoir à l’avance une idée des raccourcis ; man xmonad est là pour ça. D’après mon expérience, mod-j (changer de fenêtre), mod-shift-p (lancer une commande) et mod-space (changer de mode d’affichage) sont les seules commandes à retenir pour débuter.

L’inconvénient du fichier de configuration minimaliste, c’est qu’il faut rajouter tout ce qu’on veut configurer en plus. On peut le faire en lisant la doc mais c’est assez délicat : je trouve qu’on s’en sort beaucoup plus vite en bidouillant un exemple qui fonctionne déjà. J’ai donc téléchargé le modèle de configuration XMonad, un long fichier Haskell qui fait la même chose que la configuration par défaut, mais plus bruyamment. On peut alors jeter un coup d’oeil aux différentes parties de la conf, et bidouiller ce qui nous plaît.

Le reste du post est organisé comme une description du diff entre ma configuration XMonad et ce modèle (template) fourni : un bout du diff, et un commentaire sur la signification de la chose, et éventuellement les informations et les fichiers liés.

Imports sans grand intérêt

+import XMonad.Layout.NoBorders
+import XMonad.Hooks.DynamicLog
+import XMonad.Hooks.ManageDocks

Trois imports de bibliothèque en haut du fichier de configuration. Certaines parties de la configuration que j’ai changées dépendent de ces imports. Vous allez voir.

Dans XMonad, la fenêtre qui a le focus est entourée d’une fine et élégante bordure rouge. NoBorders permettra de configurer les dispositions de fenêtres (Layout) pour que les fenêtres en mode plein écran ne soient pas entourées : une telle fenêtre étant seule à l’écran, on se doute bien qu’elle a le focus.

ManageDocks permettra de réserver un peu d’espace d’affichage pour la barre de tâches xmobar. DynamicLog servira à envoyer en continu à cette barre de tâches des informations sur le système.

Changement du terminal par défaut

 -- The preferred terminal program, which is used in a binding below and by
 -- certain contrib modules.
 --
-myTerminal      = "xterm"
+myTerminal      = "gnome-terminal"

Attention à ne pas confondre les -, + du diff, et les -- qui dénotent un commentaire Haskell.

J’utilise gnome-terminal par défaut, parce qu’il affiche bien l’unicode (j’utilise beaucoup de lettres grecques dans mes programmes) et possède des tabs, ce qui reste bien pratique. Les gens de suckless, que j’ai déjà mentionnés car ils s’ocupent de dmenu, ont un outil qui s’appelle tabbed, qui permet en théorie d’apporter des tabs de l’extérieur à des programmes individuels, c’est sympa mais j’ai la flemme d’essayer.

Choix de la touche mod pour les raccourcis

-myModMask       = mod1Mask
+myModMask       = mod3Mask

La touche nommée mod dans la parlance XMonad est la touche centrale, utilisée pour la grande majorité des raccourcis claviers. C’est une touche abstraite, et on peut choisir la touche physique du clavier à laquelle elle correspond. On pourra l’associer par exemple à la touche « Contrôle » pour avoir des raccourcis de la forme ctrl+j, ou à la touche « Alt » pour avoir alt+j.

En réalité, l’association n’est pas si directe, elle passe par le serveur X, qui reçoit de votre clavier des keycodes (« code des touches » ?), et les transforme en keysyms (« symbole des touches » ?), qui sont ensuite envoyés aux applications. Dans XMonad, on choisit quel keysym représentera la touche mod, mais on peut aussi changer la touche en amont en s’attaquant directement à la traduction des keycodes, qui est faite par xmodmap, un outil du serveur X.

C’est d’ailleurs ce que je fais : j’ai mis le symbole mod3 comme touche mod dans XMonad, mais j’utilise xmodmap pour envoyer la touche « Caps lock » vers le symbole mod3. C’est fait dans un petit script, que j’ai nommé startxmonad.sh, qui appelle xmodmap juste avant le lancement de xmonad :

setxkbmap us intl
xmodmap -e "remove Lock = Caps_Lock"
xmodmap -e "add Mod3 = Caps_Lock"
xmonad

On charge la disposition par défaut du clavier, on réassigne la touche Caps_Lock au keysym Mod3, et le tour est joué.

Bureaux virtuels

-myWorkspaces    = ["1","2","3","4","5","6","7","8","9"]
+myWorkspaces    = with_tags ["web", "bibli", "code", "redac"]
+                where with_tags li = li ++ map show [(1 + length li)..9]

XMonad a l’équivalent des bureaux virtuels, qu’il appelle workspaces. On peut se déplacer dans le bureau virtuel numéro N avec le raccourci mod-N (mod-1, mod-2…). Par défaut, le nom de chaque workspace est son numéro, et c’est ce que ma barre de tâches affiche. Ma modification sert à donner aux quatre premiers bureaux des noms plus mignons et sémantiques, qui reflètent l’utilisation que j’en fait. La ligne where sert à montrer que je maîtrise le Haskell à fond, et que les bureaux suivants gardent leur numéro jusqu’à 9.

Légères modifications des dispositions des fenêtres

 -- The available layouts.  Note that each layout is separated by |||,
 -- which denotes layout choice.
 --
-myLayout = tiled ||| Mirror tiled ||| Full
+myLayout = avoidStruts (tiled ||| Mirror tiled ||| noBorders Full)

Comme dit au moment des imports, XMonad permet de choisir entre plusieurs dispositions de fenêtres différentes. J’ai repris les modes déjà présents (un mode plein-écran, Full, et deux modes avec une fenêtre principale, occupant la moitié de l’écran, et des fenêtres secondaires), en la modifiant légèrement. noBorders retire l’encadré rouge du mode plein écran, et avoidStruts sert à réserver de l’espace pour la barre de tâches ; je ne l’ai pas inventé tout seul, je l’ai lu dans la documentation.

Ajout de cas particuliers de fenêtres flottantes

 myManageHook = composeAll
     [ className =? "MPlayer"        --> doFloat
     , className =? "Gimp"           --> doFloat
+    , className =? "Display"        --> doFloat
+    , className =? "XVroot"         --> doFloat
     , resource  =? "desktop_window" --> doIgnore
     , resource  =? "kdesktop"       --> doIgnore ]

Par défaut, XMonad essaie de faire en sorte que chaque fenêtre occupe le maximum d’espace disponible. C’est chouette en général, mais ça peut devenir très laid quand on veut par exemple voir une image, et qu’elle est redimensionnée, sans respect des proportions, pour remplir parfaitement la place libre entre les fenêtres existantes. doFloat sert à rendre certaines fenêtres flottantes (non redimensionnées), et className =? fait visiblement un test sur la classe de la fenêtre X. Je ne connais pas les subtilités des fenêtres X, mais il y avait des lignes déjà présentes pour montrer l’exemple, et j’ai lu sur internet qu’il fallait utiliser l’utilitaire xprop pour récupérer la classe d’une fenêtre X. J’ai rajouté display et xv, mes visionnaires d’image en ligne de commande préférés (saviez-vous que display d’ImageMagick gère même le format de graphes dot quand il est compilé avec les bonnes options ?), et ça marche.

Configuration de xmobar

 -- Run xmonad with the settings you specify. No need to modify this.
 --
-main = xmonad defaults
+main = xmonad =<< xmobar defaults

main est la grosse fonction de Haskell, le moment où on lance carrément XMonad et tout. Je l’ai modifiée comme suggéré par la documentation de DynamicLog, pour qu’elle envoie des informations à xmobar, ma barre de tâches.

xmobar est un petit programme qui affiche une barre de tâches, lui aussi écrit en Haskell. Il faut le configurer indépendamment, concrètement j’ai mis le fichier suivant sous le nom ~/.xmonad/xmobarrc :

Config { font = "xft:DejaVu Sans-8:"
       , bgColor = "black"
       , fgColor = "grey"
       , position = Top
       , lowerOnStart = True
       , commands = [ Run StdinReader
                    , Run Network "eth0" ["-L","0","-H","32","--normal","green","--high","red"] 10
                    , Run Network "eth1" ["-L","0","-H","32","--normal","green","--high","red"] 10
                    , Run Cpu ["-L","3","-H","50","--normal","green","--high","red"] 10
                    , Run Memory ["-t","Mem: <usedratio>%"] 10
                    , Run Date "%a %b %_d %Y %H:%M:%S" "date" 10
                    ]
       , sepChar = "%"
       , alignSep = "}{"
       , template = " %StdinReader% }{ %cpu% | %memory% | <fc=#ee9a00>%date%</fc>"
       }

Je l’ai encore une fois adapté d’une configuration donnée dans la documentation. En gros, la disposition de la barre ressemble à ce qui est marqué dans template, et les définitions / configurations sont celles du champ commands. La partie StdinReader lit sur l’entrée standard, c’est-à-dire les informations données par xmonad, et affiche donc, sans que je lui ai rien demandé, mes bureaux virtuels en mettant en valeur celui sur lequel je me trouve, le nom de la disposition de fenêtres courantes, et le titre de la fenêtre qui a le focus. Le reste, c’est moi qui l’ai configuré comme un grand, ce sont des stats sur l’utilisation du CPU, de la mémoire (ça sert à rien mais c’est classe), et l’heure qu’il est (très utile par contre).

Utilisation avec Gnome

À mon stage, j’utilise une machine debian avec Gnome. Je pourrais installer autre chose, mais je n’aime pas beaucoup faire de l’administration sur mes heures de travail, et j’avais envie d’essayer pour voir comment ce bureau progresse.

À l’occasion d’un changement de machine, j’ai essayé la combinaison Gnome+Xmonad : utilise Gnome comme gestionnaire de bureau, mais avec Xmonad à la place de Metacity comme gestionnaire de fenêtre. C’est très facile à mettre en place, la démarche est expliquée dans la documentation. J’ai utilisé la solution la plus simple, à savoir créer /usr/share/applications/xmonad.desktop et /usr/share/xsessions/xmonad.desktop, et choisir Xmonad depuis GDM.

Ça donne un environnement assez agréable : la barre de tâches et la plupart des utilitaires Gnome sont actifs, ce qui est pratique pour avoir par exemple l’applet NetworkManager depuis notre session Xmonad (on pourrait peut-être coder quelque chose d’équivalent pour xmobar). mod-p appelle le lanceur d’application Gnome (que je trouve en réalité moins agréable que dmenu car plus intrusif), donc l’intégration est plutôt bonne.

Pour mon portable, qui a un petit écran 13", je préfère la sobriété et la finesse d’une xmobar configurée à la spartiate, mais je pense que les amateurs de gnome seraient satisfaits de la combinaison Gnome+Xmonad.

Multi-écran

Toujours à mon stage, j’utilise deux écrans. XMonad a, de base, un bon support du multi-écran : il met un bureau virtuel sur chaque écran, et on peut facilement changer le focus d’un écran à l’autre ou déplacer des applications.

Le mot de la fin

Voilà, j’ai fait le tour de ma configuration XMonad. C’est vraiment pas très compliqué. Est-ce que ça vaut le coup ?

Ce dont j’avais peur, c’est que ces outils (les tiling window managers) soient trop élite pour moi : le truc qu’il faut comprendre en profondeur pour pouvoir utiliser, et après on est super-productif de la mort, mais il faut commencer par se farcir des kilomètres de doc. En pratique ce n’est pas du tout l’expérience que j’ai vécue avec Xmonad, j’ai juste retenu deux ou trois raccourcis indispensables et bidouillé un peu la configuration en copiant-collant lâchement ce que je trouvais sur le net, et en quelques essais j’ai quelque chose de simpliste qui me convient bien.

Je pense que je suis essentiellement aussi productif qu’avant, avec Kwin ou Xfwm, et c’est vrai que je m’embête moins à agrandir mes fenêtres, les changer de bureau ou d’écran, etc. L’avantage principal reste le sentiment satisfaisant et rassurant d’utiliser un outil simple, que l’on peut modifier si l’on veut, et adapté à l’usage qu’on en fait.

Les spécialistes d’un sujet comprennent dans l’ensemble très bien que le reste du monde n’est pas spécialisé dans leur domaine. Ce qu’ils ont souvent du mal à comprendre, et essaient de combattre, c’est que le reste du monde ne cherche pas à devenir spécialiste, que ça ne l’intéresse simplement pas.

Dans le monde des hobbyistes de l’informatique, cette stupeur est largement répandue. Je l’ai longtemps partagée moi-même : comment, mon explication claire et simple sur les bienfaits d’utiliser Mozilla Firefox plutôt qu’Internet Explorer ne vous intéresse pas ? Vous ne trouvez pas important de pouvoir étudier le code des programmes qui tournent sur votre machine ? Vous n’êtes disposés à faire aucun effort pour retenir que non, on ne dit pas « je lance Google » quand on démarre un navigateur internet ? Les non-informaticiens sont d’une ignorance profonde, et on dirait qu’ils font exprès : quand on leur donne une occasion de la combler, ils s’empressent de ne pas en profiter.

Pour nous, spécialistes bénévoles persuadés que l’informatique est indiscutablement la voie de l’Homme Moderne, cette situation est intolérable. On fait des efforts pour éduquer, intéresser, faire apparaître l’esprit critique (car après tout, les logiciels libres sont successeurs des Lumières) des pauvres malheureux qui nous entourent.

Attention, la dure révélation arrive : ce contrariant état de fait est normal. Chacun ne peut s’intéresser qu’à un nombre fini de sujets à la fois, et l’informatique (ou tout sous-domaine véritablement passionnant) ne fait pas partie des heureux élus chez les gens qui vous entourent. Ç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. Si vous les forcez (par exemple en leur faisant utiliser un logiciel élitiste qui les force à comprendre la notion d’arborescence de répertoires), vous êtes une nuisance pour eux. Il faut le comprendre, l’accepter, et digérer.

Et dans le fond, chacun fait comme ça. Moi par exemple, je ne m’intéresse exactement pas aux matchs de basket. Je ne suis la progression d’aucune équipe, je n’ai aucune idée des tactiques utilisées et de ce qui fait l’intérêt du jeu, des joueurs importants, de l’organisation des tournois, etc. Imaginez la déprime du passionné de basket qui essaiera de m’intéresser à ce sport !

Pourtant le sport, comme tous les domaines dans lesquels on peut s’intéresser et se perfectionner, peut fournir des centres d’intérêt sincères, prenants et efficaces. Il y a une scène dans le film récent « Dans ses yeux » où le personnage principal, venu retrouver un ami poivrot dans un bar, assiste à une longue explication d’un des piliers locaux qui est une encyclopédie vivante sur son club de foot préféré; sa passion force le respect.

Plus proche de mon domaine, les questions de matériel informatique m’ennuient mortellement. Je ne veux pas savoir que tel site a publié un comparatif entre le processeur i17 Ultra PowerSafe et le disque SeaShore ESSID 3, et jusqu’à il y a quelques semaines je n’avais aucune idée de la tête d’un cable HDMI ou même DVI. D’ailleurs, dans le domaine spécifique du tuning d’ordinateurs, je suis pire que désintéressé, je suis malveillant : je pense secrètement qu’ajouter un néon bleu à son unité centrale avant de la montrer à ses potes est une activité stupide. C’est mal, et c’est un préjugé que je regrette.

Il y a une idée maintenant bien connue (je m’excuse d’avance si elle est devenue une platitude pour vous) que j’avais trouvée très intéressante quand je l’ai découverte. c’est la « technologie invisible » : une bonne technologie est une technologie qu’on ne voit pas, dont on n’est pas conscient de la présence. Selon cette idée, l’informatique aura vraiment réussi quand les gens auront oublié la présence des ordinateurs qui les entourent, de même que la majorité des gens ignorent complètement le petit monde mécanique situé sous le capot de leur voiture, ou la provenance des aliments qu’ils consomment.

L’administration de mon ordinateur est une activité sur la tangente. En général, elle ne m’intéresse pas et fait partie des nombreuses chose que j’oublie. Mais il m’arrive de m’y intéresser, et alors c’est toujours la frustration qui m’anime. Quand une mise à jour logicielle, nécessaire à priori pour pouvoir jouer avec la dernière version de tel ou tel programme qui m’intéresse, casse mon système, je suis très agacé et j’essaie de réparer ça rapidement.

La frustration qui me pousse à faire le plus d’efforts, c’est celle qui provient des outils que j’utilise. Elle est rampante, la plupart du temps étouffée, mais qui s’échappe parfois et fait des ravages. Elle est suivie par une période de doute, de réflexion et de recherche des alternatives, et s’arrête souvent à ce stade : je perds des dizaines de minutes à chercher ce qui se fait de mieux dans le domaine, et après avoir lu quinze descriptions d’alternatives révolutionnaires, je décide que j’ai la flemme de les essayer, et je repars satisfait pour un temps.

Régulièrement, je passe temporairement à la case suivante : changer quelques trucs. Je publierai ici quelques retours d’expérience, dans l’espoir que ça serve à d’autre, ou que ça les aide à se motiver.

Soon, it will be the Summer (of Code) again, and this year, too, NetBSD will be participating.^α At around the same time, last year, I was busy writing technical proposals for what would become xmltools, one of the accepted NetBSD SoC projects of 2009. Well, most of you have probably forgotten about that small project; some may even think it was a useless attempt and a waste of time and money, which could have been better spent elsewhere… Err, in fact, I’m writing this to say that my xmltools are not dead! And I still intend to contribute the code to the NetBSD tree sometime in the (near) future.

That being said, if you take a look at the Git repo, you’ll surely notice that nothing has moved for months… If you fool around a bit more, though, you may notice another project on the same Git host: regxml. Yep, this is a rewrite of my xmltools!

Why a rewrite, you ask? Well, basically because the old implementation was flawed by design, in addition to having become a mess.

The little boring story

And here’s the long answer, for those who care. Feel free to skip this section if it bores you.

During the second part of last year’s SoC, as I was trying to work on xmlsed, I realized my design was flawed. The main problem was that I had based all my efforts around a concept that was, for our purpose, completely inappropriate: node sets.

So what’s a node set? A node set is simply that: a set of nodes. Now, that’s great if you are extracting data from an XML document, as did xmlgrep, but it sucks if you’re going to operate further on that. In particular, removing arbitrary nodes from an XML tree doesn’t yield a tree, and replacing a node set made no sense at all. (How would you replace two far away nodes with one big chunk of XML? There are many ways to go about it… but they’re all wrong IMO.)

So what emerged at the end of the summer was that… I needed a new design, and as my original algorithm had become crippled with dubious ad hoc attempts to support operations that it never could, I needed a new algorithm too. (Besides, there was a deficiency in my algorithm that made it perform in super-polynomial time with some patterns and data sets, which was bad.)

It took me something like one month (since I wasn’t full-time on it) to jot down the new concepts and a (hopefully) good algorithm on paper. Then, for months, I’d try to implement it, but each time, something would feel really wrong, and I’d trash my new implementation. Well, that was till some days ago, when somehow, I got it right, and so the new xmltools were born!

XML intervals

So all this boils down to the following fundamental change: XML node sets have been replaced by XML intervals, as the core objects the xmltools operate on. An XML interval is really just that: a bunch of adjacent siblings and all their children. You should read the included xmltools(7) manual page for more information, from a user’s point of view.

From a more theoretical viewpoint, intervals have two important advantages over sets:

1. Inserting or removing an XML interval in an XML tree keeps it a tree. In other words, XML trees are stable by insertion and deletion of arbitrary XML intervals. (It may not have any meaning anymore, but remember xmltools are about syntax, not semantics.)

2. XML intervals map (injectively) to byte intervals in the XML file, hence all editing operations on XML intervals (sequences of insertions and deletions) can be expressed as operations on sequences of bytes in the file itself.

The first property is what I am convinced will make xmlsed possible. Previously, with node sets, it was a nightmare to give proper semantics to the various operations. But now, we have simple objects that still retain a great deal of expressivity but can be manipulated easily, with simple rules.

Although I do not use the second property yet, I’m definitely thinking about introducing an API for that sometime in the (not quite near) future.

The idea is that you run the XML matcher on a file mapped in memory (mapping new chunks as needed), and get a program script consisting of byte operations, that you can then run very efficiently on the memory-mapped file! Instead of printing an interval, you’d just copy over the entire memory region. Instead of deleting an interval, you’d just ignore that chunk. You get the idea. It could be used for efficient processing of massive data with complex transformation rules, but we’re not quite there, yet. :)

xmltools and NetBSD

As I’ve discussed with David (<dyoung>), I intend to import my core library, as well as xmlgrep into base sometime in the near future (once it has undergone more thorough testing). It depends on Expat for XML parsing, so I’ll need to import that too.

After much thinking, I think I’ll settle with a subdirectory in src/external/bsd, though I use the NetBSD build system, as I want to keep my development model using Git, and the ability to easily make packages of all my tools for non-NetBSD platforms.

The new code base uses (Net)BSD idioms more extensively than the old one (because I’ve got the time to read more NetBSD code since I started in May of last year). (E.g. I’ve followed David’s suggestion that I should make use of sys/queue.h.) Quite surprisingly, it compiles almost as is on GNU/Linux, with three additional defines and two trivial functions. I do provide a simple GNU makefile in addition to the default NetBSD build system makefiles, for GNU/Linux builds. Of course, you’re welcome to try to build it on other systems I don’t have access to!

What the future holds

Well, what’ll come next depends on a lot of factors, some of which are completely outside of my control. But there is one thing you can do: please download, compile, read the man pages, and test xmlgrep and give me some feedback, so I can fix bugs!

$ git clone git://git.huoc.org/regxml.git

Or through Git-Web: http://git.huoc.org/?p=regxml.git;a=summary

As far as the xmltools project is concerned, I’m now going to concentrate on xmlsed. I already have an idea of the implementation, and I think it’s not going to be too hard… hopefully, I’m not wrong. :)

P.S.: Oh, I forgot to talk about the new algorithm. Well, to get the idea, it’s basically an automaton backed by a backtracking memoizing work-queue-based interpreter, which roams the XML tree and try to match intervals. You should read the xmltools(7) man page for a high-level overview of the technique. Maybe I’ll write something more consistent on the subject later…