lasher a écrit 2738 commentaires

À chaque fois que tu écris « saloperie de réalité » (ou une de ses variantes), tu décrédibilises l'intégralité de ton message, même quand il y a des bouts qui sont pertinents dedans. Genre le message auquel je réponds.

C'est quand la dernière fois que t'as eu une carte Ethernet qui ne fonctionnait pas directement (même en mode dégradé, genre mode compatibilité NE2000) sous Windows > XP?

Bon, j'admets c'est très anecdotique, mais nous avons des imprimantes HP laser monochrome au boulot, et si je télécharge le driver pour Windows ou Mac (parce que pour le coup, Windows ET OS X sont à l'ouest pour ce modèle d'imprimante spécifique), alors je suis forcé de manuellement appuyer sur le bouton de validation de l'imprimante pour la faire changer de bac de chargement. Sous Linux, le driver est dispo out-of-the-box (au moins sous Ubuntu), et je peux spécifier quel bac utiliser par défaut. Le driver officiel d'HP ne me le permet pas.

Ceci étant dit, je suis d'accord pour dire que depuis Windows Vista (en gros), la recherche et l'installation automatique de drivers est quand même globalement simple. Juste que, lorsque je mets une clef USB sur le PC, ou bien que je mets un dispositif Bluetooth pour avoir un pointeur/changeur de slides, j'aimerais que Windows ne mette pas 3 plombes à « chercher un driver » (c'est une putain de clef USB, de quel driver Windows a-t-il besoin ?)

Le compilateur d'Intel en -O2 déroule 2 à 8 fois automatiquement la plupart des boucles qu'il rencontre (sauf si le nombre d'instructions dépasse les limites, cas d'exception). Je n'ai pas vérifié pour le compilateur GNU, mais avec -O3 il y a des chances qu'il fasse pareil.

Tu « triches » dans le sens où tu mets le corps du while sur la même ligne. :) J'aurais pu faire pareil avec mon corps vide dans le for.

Ensuite, utiliser n /= 2 dans la post-condition n'est absolument pas un détournement, car il s'agit bien d'une façon d'itérer sur la boucle. Par exemple, écrire un truc comme ceci (en supposant une liste chaînée) :

link_t*
find(list_t* list, const void* data)
{
    link_t* cur = NULL;
    for (cur = list->head; cur != NULL && list->cmp(cur->data,data) != 0; cur = cur->next)
        ;
    return cur;
}

est parfaitement idiomatique, et clair. Tu pourrais bien sûr écrire quelque chose du genre :

link_t*
find(list_t* list, const void* data)
{
    for (link_t *cur = list->head; cur != NULL; cur = cur->next)
        if (list->cmp(cur->data,data) == 0) 
            return cur;

    return NULL;
}

Et ce serait (peut-être) plus clair pour un nouveau venu dans le monde du C, mais à mon avis ni plus ni moins pour quelqu'un qui connaît « raisonnablement bien » le langage (c'est-à-dire qui a plus de 6 mois d'expérience avec).

Utiliser une connaissance en maths, physique, …, bref une connaissance du domaine auquel s'applique la fonction qu'on écrit pour optimiser/simplifier le code, oui, c'est astucieux. Perso, je n'aurais jamais pensé au coup du n & (n-1). Il faut accepter le fait que l'informatique est l'enfant des maths et de l'électronique, et donc que tout « truc et astuce » tombera souvent dans un domaine ou l'autre. Et de temps en temps, utiliser les propriétés du langage utilisé sera une utilisation astucieuse du langage, et donc sera une « astuce de programmation ».

En résumé : si à chaque fois que quelqu'un utilise une astuce pour simplifier/optimiser du code, on contre en disant « mais c'est pas de l'info, c'est des maths », alors on peut dire la même chose de 90% des « astuces » utilisées dans les autres domaines (mécanique, électronique, etc.), car après tout, toute modèle passant par une science « dure » est exprimé en termes mathématiques…

Une astuce c'est un truc qui peut casser dès qu'on met à jour le compilateur et/ou le runtime ou dès qu'on change d'environnement.

Non. Par exemple si je veux savoir si un nombre est une puissance de 2, je peux écrire

_Bool
is_power_of_2_naive(unsigned long n)
{
    unsigned long remainder = 0;
    while (!remainder) {
        remainder  = n % 2;
        n         /= 2;
    }
    return remainder == 1 && n == 0;
}

Ça marche, c'est assez direct, et au pire j'aurai itérations (puisque je divise par 2 à chaque itération).

On peut quand même simplifier :

_Bool
is_power_of_2_naive(unsigned long n)
{
    if (n == 0) return false;
    while (n%2 == 0) 
        n /= 2;
    return n == 1;
}

On peut même rendre l'écriture plus compacte :

_Bool
is_power_of_2_naive(unsigned long n)
{
    if (n == 0)  return false;
    for (; n%2 == 0; n /= 2) 
        ;
    return n == 1;
}

Mais bon jusque là, « l'astuce » c'est juste connaître le langage, et savoir exprimer la même chose de différentes façon. Il s'agit donc purement de style.

Mais je peux être réellement astucieux, et répondre en temps constant :

_Bool
is_power_of_2(unsigned long n)
{
    return (n > 0) && ((n & (n-1)) == 0);
}

Un entier non-signé ne changera jamais ses propriétés, donc j'ai la garantie que ce code fonctionnera toujours en C/C++ (et en fait n'importe quel langage qui permet les opérations bit-à-bit sur des entiers).

J'ai oublié de répondre à ça : si le bouquin/poly/bla est meilleur que le prof, et qu'on parle bien d'un amphi, alors aller en cours ne sert à rien, et les étudiants ne devraient juste pas y aller. J'ai fait ça pour certains profs qui clairement ne savaient pas bien enseigner, et dont le poly était bien meilleur que le cours magistral. En fac, il n'y a aucune obligation d'assister aux cours, sauf TP et examens. Je veux bien croire qu'en première année on reste « scolaire » et qu'on aille à tous les cours parce qu'on vient du lycée, mais dès la deuxième année, je m'attends à ce que les étudiants qui estiment qu'il perdent leur temps (y compris en TD) ne viennent pas. Ce sont des adultes, on les traite comme tels.

Mince, je ma mémoire me joue des tours. :(
Bon ben, pan sur le bec alors.

"Si à cinquante ans, on n'a pas une Rolex, on a quand même raté sa vie."

Je ne sais pas pour les autres citations, mais celle de la Rolex a été complètement détournée. Si tu trouves la vidéo de l'interview initiale (ou une retranscription), tu verras que cette phrase est utilisée dans un contexte ironique.

Je ne comprends pas bien pour le globbing. J'utilise fréquemment ce genre de code (simplifié avec say pour l'exemple) :

use v5.014;
say for ( <*.txt>,<subdir/*.txt> ); 

# Ou en plus explicite : 

use strict;
use warnings;
use v5.014;
for my $file (<*.txt>,<subdir/*.txt>) {
    say $file
}

Certes, il faut rajouter les < et >, mais ça s'arrête globalement là. N'importe quel bouquin qui enseigne le Perl correctement (je pense entre autres aux bouquins de chez O'Reilly) expliquent comment utiliser le globbing.

L'avantage du |> c'est que c'est lisible et donne naturellement l'ordre des opérations. Quelque part, le fait qu'il y ait une écriture de type fonction op fonction op fonction ... op ... me permet de visuelle situer ce qui se passe, alors qu'avec ta solution (qui fonctionne, pas de souci là-dessus), il faut que mon cerveau réfléchisse un chouïa plus.

Concernant le parallélisme : en OCaml je ne sais pas si les pipes le permettent, mais j'avais cru comprendre qu'en F# c'était faisable.

Disons que c'est peut-être ma méconnaissance de sh/bash (zsh je ne connais vraiment pas), mais un script qui fait plus de 20 lignes en (ba)sh, ça me pique les yeux, même si c'est moi qui l'écris. Dès que j'ai besoin d'écrire des fonctions, j'ai tendance à très vite aller voir du côté de Perl. Ça a aussi sans doute à voir avec le fait que si je ne peux pas simplement chaîner des commandes et que j'ai besoin d'ajouter de la logique, s'il ne s'agit pas de boucles très simples où tout est visible depuis celle-ci, je trouve le shell trop peu expressif (bon c'est pas exactement comme ça que je le pense¹, mais j'ai le cerveau embrumé ce matin…).

En fait je suppose que dès qu'on parle de manipulation « fine » de chaînes de caractères, j'ai tout de suite tendance à penser à un langage plus expressif (et avec plus de modules déjà écrits pour moi) que le shell.

Ce qui manque à Perl selon moi, c'est la possibilité d'utiliser les pipes à l'intérieur d'un programme Perl (un peu comme |> qui existent OCaml comme l'a expliqué Michaël, mais aussi Scala et le cousin d'OCaml, F#). Mais à part ça, je ne vois pas en quoi le shell est tellement plus abstrait que Perl/Python/Blah, surtout si le langage a une REPL.

En Perl, par exemple, je peux faire un truc du genre alias perlstd='perl -ne' pour avoir un interpréteur Perl en ligne de commande (mais il sera très fragile, assurément). Ça me permettra d'écrire ce genre de choses:

perlstd 'print' /usr/include/stdio.h # cat en plus lent, WOUHOU!
perlstd 'print reverse <>' < /usr/include/stdio.h # rev en plus lent, WOUHOU!

Donc évidemment, s'il existe des commandes pour faire la même chose, qui en plus ne nécessiteront pas de créer une instance d'interpréteur perl, mieux vaut les utiliser (et en plus les noms seront plus cours, même si je pourrais faire les alias qui vont bien pour pallier ce genre de problème).

Par contre, avec ce même alias perlstd, je peux aussi faire tout ce que proposent sed, awk, grep, ce qui par définition indique que Perl est plus abstrait que ces outils. Et plus général aussi, bien sûr. Bref, ceci est de la sodomie de diptères pour dire que je ne suis pas d'accord pour dire que le shell est plus abstrait. Au contraire, le shell est moins abstrait, et c'est ce qui fait sa force.

Bon, je préfère Perl pour ajouter des filtres perso (quand un truc genre grep/sed/awk devient compliqué), mais il ne faut pas oublier qu'écrire un programme en C ne signifie pas forcément « écrire un programme en C en ne se servant que de string.h comme base » : tu peux parfaitement utiliser des bibliothèques (par exemple, la bibliothèque de regexps du projet GNU), et simplifier grandement ton code plutôt qu'utiliser strtok. De même, tu peux parfaitement avoir commencé à construire un ensemble de wrappers (genre smalloc qui va crasher si y'a un problème d'allocation, et qui te permet de ne pas te soucier de la gestion d'erreur, sread pour gérer les erreurs et le besoin de répéter l'opération en cas d'interruption, etc.) qui vont simplifier grandement ton code et le rendre suffisamment lisible pour te concentrer sur l'essentiel : l'algorithme.

J'insiste, je pense qu'un langage de plus haut niveau (Perl/Python/Ruby/Lua/Bla) serait sans doute meilleur pour gérer ce genre de choses, mais je pense aussi que le meilleur outil pour faire un programme de taille raisonnable est celui qu'on maîtrise bien.

Alors que les riches Français financent les arts et lettres. C'est très différent.

Je ne comprends pas bien cette remarque. Le principe du « tout fichier » c'est (à ma connaissance hein) pour tout ce qui concerne les entrées-sorties. Un mutex n'en fait pas partie (par définition il s'agit d'un objet en mémoire partagée).

On laisse généralement passer si l'élève a des notes correctes. Si ce n'est pas le cas, l'élève risque non seulement de doubler, mais aussi de se faire expulser.

Oui, mais en moyenne, la TVA vaut ~10%. Donc même en la rajoutant, on n'arrive pas au prix français.

Ceux qui discutent à 10 dans un amphi se font remarquer, et je connais plus d'un prof qui donnait aux élèves un choix :

1. Ils se la ferment/parlent plus discrètement (au-delà de 2, c'est quasi impossible pour être plus discret, même en chuchotant),
2. Ils partent,
3. Le prof part, et il considère le cours comme fait.

Dans les facs de médecine / pharmacie / etc., qui ont un concours à la fin de l'année, ça peut (pas toujours) être un élément dissuasif.

Bon déjà, dans les écoles d'ingé classiques, normalement la présence est obligatoire. Ensuite, même dans le cas où ce n'est pas vrai, je peux te dire que la méthode pédagogique peut fortement différer d'un établissement à l'autre. En IUT, le cours magistral pour (par exemple) la matière « d'environnement de programmation » parlait finalement comment un OS fonctionne : système de fichiers, inodes, services d'un OS, séparation des droits, etc. Alors qu'en TD/TP, on nous faisait faire des Makefiles, de la programmation shell, etc., et donc même si l'ensemble consistait bien à apprendre comment un OS fonctionne, il était séparé entre savoir théorique (cours magistral sur les principes des OS) et savoir pratique (comment exploiter les fonctionnalités d'un OS en tant qu'utilisateur).

Lorsque j'étais en école d'ingénieur, j'allais en cours magistral et TD et TP, car le prof était bon (charismatique et pédagogue), et comme il montait un nouveau cours à l'époque, il n'y avait tout simplement pas de PDF dispo à l'époque. Au contraire, le prof de recherche opérationnelle était un cador dans la recherche, mais son cours magistral était à chier : même le poly officiel du cours, ce n'était pas lui qui l'avait écrit mais un de ses thésards. Du coup, pas mal d'entre nous allions lire le poly au lieu d'aller écouter le prof.

Pas besoin de BÉPO, il suffit d'activer la touche compose, et tu te retrouve avec tout plein de caractères: ø, ±, →, etc. Bon après j'avoue qu'étant sur un qwerty, ça aide pas mal d'avoir la touche compose rien que pour les accents. :)

Tu te l'achètes comme une fourniture scolaire, pas toujours besoin de prendre un modèle à 1000€, pour prendre des notes en droit tu peux en prendre 1 sur plusieurs années à 300€

On repart sur des problèmes d'autonomie. À part un netbook genre EeePC qui tenait facilement 10 heures sous Linux, mais qui a un clavier riquiqui/pas confortable, il y a très peu d'ordinateurs qui ont un OS et un matériel qui sont capables de tenir ~8h par jour. D'ailleurs, contrairement à ce que j'ai pu lire ailleurs, c'est effectivement l'une des grandes forces des portables Apple : ils ne sont pas les plus puissants, mais par contre il durent longtemps.

Je me méfie fortement des étudiants qui prennent des notes sur un portable. Tout le monde n'a pas la volonté pour résister aux sirènes du Net qui se trouve là, tout près. De plus, c'est peut-être juste moi, mais à moins d'être juste en mode « prise de note » (et dans ce cas j'ai tendance à taper plutôt vite), si en plus mon interlocuteur me demande de réfléchir et de répondre à des questions, je trouve que prendre des notes avec un stylo c'est plus « organique » / moins intrusif pour mon mode de pensée.

Sinon, mon expérience en tant que prof (très anecdotique, je l'admets), c'est que les rares étudiants en France qui utilisaient un portable pendant les cours étaient ceux qui ne faisaient pas réellement attention en cours.

Mouais. Tu es dans un monde « différent » de la majorité des gens alors. Pourtant je bosse dans une université US, avec plein de gosses de riches, et donc plein de portables Apple. Ce qui fait que dans notre salle de conférences, on essaie d'avoir toujours un adaptateur à disposition pour Mac. Sauf que … Si t'as un mac un chouïa trop ancien, c'est pas le bon !

Donc voilà, je suis d'accord avec Pierre Roc, grosso modo, j'ai plus l'expérience de devoir aller dans tous les bureaux voisins pour chercher le bon adaptateur Mac que cherche un câble (micro-)USB…