Michaël a écrit 2935 commentaires

Oui, oui! :-)

Ce n'est pas du shell, c'est sed, si tu as une meilleure solution avec un meilleur outil externe, tu peux l'inserer ici!

Le concours est ouvert!

Mais tous les utilisateurs de systèmes non windows ne sont pas nécessairement, ni ne veulent être, de bons admin.

D'une on ne parle pas de tous les utilisateurs mais de ceux qui ont quelque chose `a faire de ce qui se passe au demarrage de l'ordinateur. Peut-etre qu'ils veulent lancer un service au demarrage qu'ils ont prepares. Et n'importe qui sachant programmer un service qui doit se lancer au demarrage a a priori les competences pour trouver le moyen de l'integrer a sa sequence de boot en moins d'une heure et demie, quelque soit le systeme de boot.

De deux, quand on utilise un systeme Unix, programmer le shell est la competence technique la plus importante, et donc baser un systeme technique sur le shell n'est pas une barriere d'entree au contraire!

Avec une mentalité comme ça on continuera à se cogner le shell pendant des années… Tous les trucs que je faisais (ou j’essayais de faire) auparavant en shell je les fait en Python. Même si en général c’est un peu plus verbeux, c’est tellement plus intuitif et lisible (même pour quelqu’un qui ne connait pas le langage).

Donc tu n'aimes pas le shell et tu preferes Python, mais en quoi ca nous concerne?

Sinon le shell est clair et lisible si on veut:

basedir="/path/to/basedir"

backup_query()
{
    find "$basedir" -type d -name '*.git'
}

backup_joblist()
{
    sed -e "
h
s@$basedir/@@
s@/@-@g
x
G
s@\\n@|@
"
}

backup_process()
{
    IFS='|'
    while read src dst; do
        git clone --bare "$src" "$dst"
    done
}

backup_query | backup_joblist | backup_process

C'est le petit script de cet apres-midi pour cloner les repositories git de $basedir/john/projet.git en john-projet.git.

D’autre part, je peux avoir envie de me faire une unité (service, minuteur) ou surcharger une unité existante sans être admin sys (et pour servir un des buts de systemd, à savoir maintenir l’unité systemd en amont, mieux vaut que ça soit simple pour que ça soit fait).

En gros tu me dis que tu peux avoir envie d'etre une personne avec un profil technique quand il faut avoir envie de faire une unite et un profil plutot pas technique quand on en vient a integrer cette unite au systeme de boot? Pas tres convaincant!

La verite, c'est qu'il s'agisse de systemd ou de l'init old-school, une personne avec un profil technique qui ne connait pas le systeme en question et qui veut integrer son schmouzin au boot va avoir besoin de 30min—1h30, et que si systemd a des atouts indiscutables, la simplicite est un argument completement pipeau.

(Pardon pour les accents!)

Ben oui, quand il faut apprendre un langage à la syntaxe à la con (avouez: la gestion des chaînes de caractères est loin d'être triviale en shell, sans parler des nombres.

Independemment de tout systeme d'init un admin doit connaitre le shell, donc en fait, un systeme d'init base sur le shell est base sur un systeme bien compris par un admin.

afin d'être capable d'analyser le code existant, dispatché dans de nombreux fichiers eux-mêmes disséminés dans l'arborescence, gérant toutes les situations de tous les systèmes possibles, ce n'est pas une aide, mais une gêne.

Chez moi, ce n'est pas comme ca (FreeBSD), il y a essentiellement /etc/rc, la bibliotheque /etc/rc.subr qui encapsule la logique de demarrage de services, puis chaque script de service, ce qui signifie que si tu veux comprendre un demarrage de service, tu dois lire rc.subr (qui a une page de man, en plus!) et ton fichier de demarrage de service: c'est une situation bien moins atroce que ce que tu depeins.

Les accents sont la:''^'

Bref, toutes ces choses permettent de gagner un temps fou dans de développement et la maintenance, et il est possible d'aborder des programmes autrement plus complexes.

Certainement, mais on aimerait plutôt savoir si toutes ces choses sont nécessaires à apprendre, si elles sont faciles à apprendre ou constituent des difficultés pédagogiques, parcequ'on parle des langages pour s'initier à la programmation!

Il y a des systèmes d'arithmétique modulaire que les gens connaissent bien, dans la vie quotidienne: les calculs de calendrier (heures, minutes, secondes, semaines, …), les preuves par 9, les calculs “numérologiques” aussi modulo 9, et la “ploume”.

On peut donc aussi parler d'arithmétique modulaire sans forcément avoir survécu à un cours d'algèbre élémentaire.

On parle de langages pour apprendre à programmer, et toi tu parles de l'ordre dans lequel il faut apprendre l'algorithmique et la programmation. C'est une ouverture actuelle du débat qui mérite à elle seule un journal mais qui en soi est ici un peu hors sujet.

Pour apprendre à programmer.

Ou alors on peut arriver à émettre une idée aussi difficile(!) et originale(!!) par soi-même, sans béquille d'autorité.

C'est le cas!

J'ai réalisé après coup que c'était le point de vue des auteurs cités et je me suis dit que ça pourrait donner des idées de lecture aux glandus qui moinssent sans se donner la peine de formuler une contradiction. :)

Le C est plus facile dans le sens où il te fait gagner du temps (et le temps, c'est du code).

Le C est aussi plus difficile que l'assembleur parceque:

• Il propose une mauvaise abstraction de la mémoire (les pointeurs): on ne comprend cette abstraction qui si on sait comment marche la mémoire, donc du coup on doit apprendre deux choses (la manipulation de la mémoire et l'abstraction de cette manipulation).

• Il est plein d'incantations mystiques comme include dont le rapport avec l'utilisation des fonctions n'est pas facile à éclaircir pour un néophyte.

• Il a un type à la con void qui n'a pas de valeurs.

• La notion de tableau est très voisine de celle de pointeur, avec des différences subtiles sizeof.

• Il y a des raffinements des déclarations de structures (padding), des unions…

Si l'assembleur était si facile que ça, on y serait resté.

Je te rappelle qu'on parle des langages pour apprendre à programmer.

Ta proposition …

En fait c'est surtout les propositions de Knuth dans The art of computer programming et de Abelson, Sussman et Sussman dans Structure and interpretation of computer programs.

Des livres pas importants du tout dans la bibliothèque d'un programmeur.

XP en l'occurence — le même que chez les clients — bon il faut être honnête et se souvenir que l'OS est sorti en 2001!

Une poignée de minutes…

Pour l'édition de liens!

La compilation complète dure bel et bien une cinquantaine de minutes sur un quad-core avec deux Go de RAM — à mon avis le HD n'est pas un foudre de guerre et le système de fichiers à fragmentation accélérée n'aide pas non plus aux bonnes performances!

Ça présuppose qu'on apprenne à programmer à des Unixiens barbus qui utilisent couramment la ligne de commande…

Ou bien ça suppose qu'on leur apprenne aussi la ligne de commande, genre au semestre d'avant.

(et ça devient cocasse quand certains de tes élèves sont habitués à zsh ou je ne sais quelle autre variation)

Donc c'est assez invraisemblable que les élèves s'intéressent à la ligne de commande mais s'il y en a, alors très certainement l'un fait du zsh? Cool!

Souvent considéré comme néfaste, car il change le code exécuté, rendant les erreurs aléatoires différente de l'exécution traditionnelle (ce qui généralement est une invocation à valgrind)

Le plus gros défaut c'est surtout que le travail de test et de debugging est essentiellement détruit après que le bug soit corrigé, alors que d'autres méthodes de débiguages (test unitaires p.ex.) créent plus de valeur car ils ne sont pas éphémères.

Enfin plusieurs minutes a linker ? Je ne sais pas sur quelle brouette tu bosses, mais sur un code déjà compilé 1 fois, avec tous les .o le link sur un petit projet d'1,3 million de ligne est inférieur à la minute.

De mémoire il s'agit d'environ 4,5 millions de lignes de code. Le problème vient de VS 2008 qui utilise un cache pour l'incremental linking dont la taille est limitée par l'OS (à cause d'une sorte de mmap vraismeblablement) et cette taille de cache est allégrement dépassée par le projet. Chaque linking repart donc de zéro et ça dure effectivement une poignée de minutes.

99% du temps la notation hongroise, c'est Captain Obvious (aka Captain Noise pour du code).

C'est surtout Captain Wrong vue que lorsque le programme évolue les types changent sans que l'expression des traitements ait forcément à être modifiée.

C'est du moins ce à quoi sert la surcharges des opérateurs en C++ et utiliser la notation hongroise en C++ montre surtout qu'on n'a rien compris!

La quantité de développeurs qui ne savent pas se servir correctement du typage de leur langage favori est hallucinant.

Elle est sérieusement concurrencée par celle de développeurs C++ qui ne savent pas ce qu'est l'héritage.

Pourquoi pas le C++ ? Y’a tout ce qu’il faut.

Il y en a un peu plus, je vous le laisse?

Le moto de Perl “there is more than one way to do it” s'applique à C++ en ajoutant “and none of them is right, nor is it obviously wrong!”.

Les deux langages les plus simples sont l'assembleur et le Scheme, ils mettents l'accent sur des choses très différentes.

L'assembleur (mon premier langage!) n'est absolument pas conceptuel mais il permet d'apprendre des tas de choses sur le fonctionnement des ordinateurs et permet de manipuler la mémoire de façon explicite. Et écrire un projet vaguement ambitieux en assembleur est l'occasion de se forger une discipline d'organisation qui survivra à tout!

Scheme au contraire est purement conceptuel et c'est très franchement le plus simple de tous les langages fonctionnels, un million de fois plus simple que Common Lisp, Perl, Python, OCaml ou Haskell.

(Et si quelqu'un dit que C est plus facile que l'assembleur c'est qu'il ne sait programmer ni l'un ni l'autre!)

Un jour j'ai découvert l'OCaml […] j'ai laissé tomber aussi (snif!).

Tu as fait l'erreur de ta vie! Tout simplement. ☺

L'idéal ce serait d'en voir plusieurs, et laisser les élèves choisir celui ou ceux qu'ils préfèrent.

L'idéal c'est d'apprendre à programmer indépendamment de tout langage (un peu comme ce que tu as fait, algorithmique puis Pascal) parceque tu apprends à distinguer entre les deux champs de connaissance: le conceptuel et l'implémentation. Il suffit de lire quelques CR d'entretien d'embauche menés par Joel Spolsky (cf. son blog) pour se rendre compte que c'est une qualité.

Si on t'apprend à programmer indépendemment de Pascal ou C++ ou bidule, tu es à même d'apprendre rapidement de nouveaux langages, et donc tu as beaucoup plus d'opportunités professionnelles et donc tu es plus libre d'organiser ta carrière.

L'énorme avantage du C++, c'est que tu peux prédire lorsqu'un destructeur sera appelé, et tu peux suivre la séquence à l'aide de printf debugging.

La possibilité de faire du déboguage à coups de printf? (Vive le C++, au passage!) Vu qu'un programme assez gros mets plusiurs minutes à linker je ne suis pas sûr que j'aie envie d'appeler ça un avantage!

Personnellement, j'ai débuté la programmation en faisant des scripts bash tout connement.

C'est une recommendation originale, mais elle a plusieurs mérites:

1. Transformer une ligne de commande en programme shell est super facile: il suffit de la retranscrire dans un fichier. Donc on apprend à programmer en disposant déjà d'un riche vocabulaire de fonctions élémentaires et on peut se concentrer sur la structure.

2. Au passage on apprend à utiliser inteligemment son ordinateur en automatisant des traitements que l'on faisait pas à pas, et c'est une perspective qui manque à un très grand nombre de programmeurs…

Je plussoie des deux mains!

== n’est pas réflexif pour NaN

C'est le choix de l'IEEE pour définir l'égalité des flottants, ça n'a absolument rien à voir avec Javascript. Pour tous les gens qui ignorent que == n'est pas réfléxif en IEEE ce comportement n'a aucune importance, et pour les autres, c'est le comportement à suivre!

Tout d'abord, pour éviter le monopole, un bon nombre de librairies pourrait commencer par améliorer leur qualité de service pour qu'on ait envie d'y aller.

J'ai lu dans le blog de Joel Spolsky (ou peut-être de Paul Graham) une anecdote illustrant bien ton propos. Une grosse librairie New-Yorkaise (une sorte de Fnac ai-je compris) a littéralement réduit à peau de chagrin la part de marché de ses concurrents traditionnels. Et ce, non-pas en cassant les prix ou en pratiquant quoique ce soit qui ressemblerait à une concurrence déloyale. Ce qui d'après Joel a fait le succès de la bibliothèque c'est l'aménagement de la librairie en un espace agréable où on peut s'asseoir, se détendre et lire en prenant un café, avec en arrière pensée l'idée simple que plus longtemps un client reste dans la bibliothèque, plus vraisemblablement ils achètera un livre.

Les librairies ne doivent pas absolument survivre. Pas toutes. Si elles ne font plus recette, c'est qu'elles ne servent plus. C'est aussi simple et évident que ça.

C'est un argument de type “néo-libéral” qui a une faiblesse simple et évidente.

L'allocation d'argent à tels et tels biens ou services permet aux agents du marché (ici les librairies et leurs clients) de traduire leurs préférences en terme d'utilité. C'est une préférence individuelle, mais le mieux pour chaque acteur n'est pas forcément le mieux pour la collectivité, d'où l'intérêt des réglementations, qui permettent d'introduire la préférence collective dans les choix individuels.

Par exemple si on estime à titre individuel que le savoir-faire des petits libraires est si peu important qu'on puisse le laisser disparaître, ou si on ne fait pas entrer cet aspect dans le prix qu'on est prêt à payer, la communauté peut le voir autrement et biaiser le marché en faveur du petit libraire — ce qui équivaut à obliger tout le monde à reconnaître une valeur à son savoir-faire.