Michaël a écrit 2935 commentaires

Je ne le soulève pas parce que le raisonnement présenté n'était basé que sur la rentabilité de l'opération.

Pour certaines personnes, le fait d'éviter de produire des déchets a de la valeur, une valeur qui est justement mise en évidence dans dans les décisions prises dans ce genre d'achats.

Sur le point particulier du raisonnement écologique, il faut faire hyper-attention, parce que les coûs écologiques cachés peuvent être très grands et très complexes.

C'est vrai et de plus c'est un sujet surlequel il est incroyablement difficile de se renseigner! Par exemple avec l'apparition des magasins “sans emballage” où l'on amène ses contenants pour acheter des pâtes ou ce genre de denrées, ce serait chouette d'avoir des données qui disent “ben oui c'est mieux d'acheter des pâtes sans emballage que des dans une boîte en carton, même s'il faut rouler 20 minutes de plus pour aller au magasin” (ou le contraire, le cas échéant).

Bref, les gens ne sont pas (tous) des cons. Je sais bien que c'est toujours glorifiant de penser "mieux" que les autres, mais dans cet exemple précis, il ne me semble absolument pas évident qu'il vaille mieux acheter un appareil deux fois plus cher si on pense qu'il durera deux fois plus longtemps.

Un point que tu ne soulève pas, c'est qu'acheter deux machines au lieu d'une, cela fait une machine qui va au rebut.

Sans faire de pub, une machine robuste et réparable (et pas qu'un peut) ça existe : Miele.

Sans faire de pub, c'est la vérité.

Pour expérimenter avec Linux je ne peux que te conseiller d'utiliser VirtualBox. Le logiciel VirtualBox est un logiciel libre qui te permet de simuler un PC, et donc d'installer Linux dans un environnement virtuel. Cette procédure est très simple et idéale pour se familiariser avec Linux. La solution d'une installation sur une partition dédiée est beaucoup plus technique – mais pas réellement difficile.

Il n'est pas difficile de trouver des procédures d'installation pas à pas, par exemple: http://www.brianlinkletter.com/installing-debian-linux-in-a-virtualbox-virtual-machine/

Voici une petite marche à suivre pour découvrir Linux:

• installe Linux dans une machine virtuelle, par exemple en suivant la procédure pas à pas ci-dessu
• prend contact avec un groupe d'utilisateurs de Linux de ta région, ce qui te permettra de pouvoir échanger avec des gens qui pourront t'apporter l'assistance ou les conseils dont tu as besoin.
• si tes impressions sont concluantes tu pourras faire le choix d'installer Linux “pour de vrai“ sur ta machine, ici aussi l'aide d'utilisateurs plus expérimentés te sera précieuse!

Je ne connais pas de projet qui soit à plus de 80% de couverture, mais ça n'empêche pas que s'empêcher de tester son code ne me semble pas du tout être une bonne idée.

Là où un peu de pédagogie est nécessaire est certainement qu'il faut bien expliquer qu'une partie de test et de mise au point est inévitable. Ceci étant quel statut donner à ce travail? Faut-il se contenter des résultats immédiats (ça marche, on livre) et oublier le reste du travail fait ou bien faut-il le sauvegarder, l'incarner, dans des artefacts sous contrôle de version, des tests automatiques? En plus des bénéfices que tu soulignes qui se révèlent payants sur le long terme, souligner que c'est un travail qui va de toute façon être fait et que la vraie question est s'il faut l'organiser pour l'automatiser ou juste l'oublier est un argument qui “touche” parfois.

Et toi tu as fait quoi pendant ce temps ?

Je moulais sur LinuxFR pardi!

Tristesse…

Boh, il ne faut pas être triste. La machine elle a déjà étudié beaucoup de parties jouées par des être humains, mais Lee Sedol lui n'en est qu'à son quatrième jeu contre la machine. Il faut bien s'habituer à ce nouveau genre d'adversaire.

Je joue aux échecs (comme une pignolle) et je n'aime pas trop jouer contre l'ordinateur parcequ'il a une approche très différente de l'humain. J'imagine que cette différence d'approche est le cas dans beaucoup de domaines. :)

Bref le développement dans le noyau ou en tout cas pour le noyau linux est très contraignant et ce n'est pas forcément une gynastique à la quelle les développeurs de ReactOS veulent se plier.

J'ajouterai que les noyaux utilisent parfois des représentations tellement différentes qu'il devient très difficile d'adapter le support d'une même fonction entre deux noyaux. C'est par exemple le cas des systèmes de fichiers sous Linux et FreeBSD, et explique l'interopérabilité plutôt limitée entre Linux et UFS d'une part et FreeBSD et extfs d'autre part. (Du moins historiquement, je ne suis peut-être pas très à jour, tout mes Linux tournent dans une VirtualBox.)

Heu, c'est assez éloigné de mon propos!

Il ne nous reste plus que la joie de vivre, comme un journal décroissant (en déroute) le martel depuis 10 ans.

Journal qui au passage avait écrit un article complètement aberrant dans sa rubrique “la saloperie de la semaine” dédié … au logiciel libre! Qui méritait bien d'être classé saloperie de la semaine au prétexte que Linux fait tourner beaucoup d'ordinateurs dans les data centers et est donc responsable d'une catastrophe écologique quotidienne. Au fil de son argumentation brillante l'auteur dévoilait qu'il était traumatisé par les câbles reliant entre eux les ordinateurs des data centers. C'était la première et dernière fois que j'achetais ce journal, probablement en 2008 ou 2009.

Oui je parle de ça. Il est utilisé par l'entreprise qui le développe (je suppose) et j'ai commencé à expérimenter avec. Il s'agit d'un port d'un projet Erlang, il est donc plus mature que ce que son numéro de version peut laisser supposer.

En gros, on est très très très loin de l'idée d'un algo qui apprend un jeu tout seul.

Aujourd'hui l'intelligence artificielle est sur toutes les lèvres et fait beaucoup fantasmer mais la réalité est souvent très terre à terre comme tu le rappelles. De plus, même si les avancées du machine learning sont très enthousiasmantes, il ne faut pas oublier que cela sert essentiellement à de l'estimation (parier sur la valeur la plus plausible d'une quantité inconnue) ou la reconnaissance de forme (classification, comptage, détection) mais ces activités sont très loin de constituer la palette totale des activités de l'intelligence.

La bibliothèque labltk est largement sous-estimée et j'ai commencé à travailler (trèèès lentement) pour ajouter les widgets Tk plus modernes qui manquent – l'idée serait d'avoir une bibliothèque lablttk. Les plus gros défaut de Tk est probablement de ne pas avoir de widgets pouvant afficher une page Html ou jouer une vidéo mais pour toutes les autres applications, elle fonctionne bien et test très facile à programmer.

Si on pouvait faire un serveur web correct comme en go, le problème serait bien plus limité.

Qu'est-ce que tu entends par serveur HTML correct? Il y a 36 000 bibliothèques pour faire ça, à défaut d'apprendre Eliom j'ai commencé à travailler avec webmachine, c'est très bien.

Au contraire de ce que tu dis dans ton article, la méthode d'AlphaGo était loin d'être pacifiste,

Ça change des robots qui jouent aux échecs, qui se livrent à une guerre de position ennuyeuse au possible!

Bref, Js, je débute, et pour être franc, ça me rebute un peu. Je trouve ce langage très difficile à appréhender, notamment par le manque de recommandations officielles et claires, mais passons. Et comme je débute, quoi de mieux que de commencer au début du langage.

C'est pour cela que Douglas Crockford a écrit son livre “JavaScript – The GoodParts”.

Le niveau 2 du singleton est le singleton paresseux: tu écris une objet qui délègue tous ses appels à un second-objet (avec la même interface) qui crée cet objet avant l'appel à la première méthode.

var create_counter = function(_my, _super) {
  var my = _my || {};
  var that = {};
  my.count = 0;
  that.tick() = {
    my.count+= 1;
    return my.count;
  }
  return that;
}

var create_lazy_counter = function(_my, _super) {
  var my = _my || {};
  var that = {};
  my.actual_counter = null;

  function delegate(meth) {
    that[meth] = function() {
      if(my.actual_counter === null) {
        my.actual_counter = make_counter();
      }
     return  my.actual_counter[meth].apply(my.actual_counter, arguments);
  }

  return that;
}

Dans l'exemple scolaire ci-dessus ça n'a pas trop d'intérêt mais cela peut être utilisé pour raccourcir les tenps d'intitlisation de programmes.

Autre point que je n'ai pas mentionné, c'est la bibliothèque standard. Celle de base, fournie par INRIA, est souvent jugée limitée

Honnêtement je trouve que c'est un reproche aussi fréquent qu'immérité. Est-ce qu'on fait ce reproche à C dont la bibliothèque standard est encore plus légère? Où à C++ qui pendant des années n'avait pratiquement pas de bibliothèque standard (pre-STL)? Alors bien-sûr, d'autres langages ont des approches différentes, comme Java qui propose une bibliothèque de base très étoffée.

Des utilisateurs industriels qui développent toute une infrastructure en OCaml ont évidemment des besoins qui les poussent à implémenter une alternative à la bibliothèque standard – mais c'est le cas de beaucoup de gros projets logiciels de toute façon – par exemple GTK+ a sa glibc, originellement écrite pour gimp, et divers logiciels métiers sur lesquels j'ai travaillé ont aussi leur bibliothèque standard maison.

Je trouve que c'est un faux problème maintenant que opam est disponible et fonctionne bien, on n'a quasiment aucun intérêt à avoir une bibliothèque de base tout-équipée – qui de toutes façons sera dans la plupart des cas d'application concrète trop générale, ou trop ceci ou pas assez cela – puisqu'on peut rassembler les composants dont on a besoin en quelques minutes.

Aussi, pour les mécanismes de mise à jour, correction de bogues, etc. il est plus intéressant d'avoir une multitude de petits projets qu'un gros monolithe mis à jour une fois tous les six mois, au prix d'interminables discussions pour changer une virgule ici ou là.

Pour terminer je réponds déjà à ceux qui grognent “oui, mais à quoi sert de réinventer la roue? je veux une bibliothèque standard avec totu dedans” en se réclamant d'un pragmatisme, souvent auto-déclaré et illusoire. Dans la pratique, il n'y a pas de recette magique: les solutions générales sont invariablement inadaptées aux problèmes particuliers! (Truisme du jour.) C'est pour ça que quand on étudie les math et l'info on étudie les preuves et les algorithmes: pour pouvoir adapter les théorèmes et les algorithmes aux cas particuliers que l'on rencontre et où l'énoncé général ne s'applique pas.

Pour résoudre le problème de l'infinité de solutions le robot emploi la méthode de l'auto aprentissage (machine learning). En gros, si je ne dis pas trop de bêtise, c'est la méthode empirique. Le robot ne sait pas trop jouer, parce que son programmeur non plus, alors il joue un peu au hasard, il élimine les mauvaises solutions et il garde les meilleures et ainsi de suite.

En fait c'est un peu plus subtil que cela. :) En gros le problème fondamental du machine learning, c'est la prédiction d'une variable booléenne, càd trouver le pari le plus avantageux à faire sur une question dont la réponse est oui ou non, connaissant tout une série d'exemples de questions similaires avec leurs réponses. On a ensuite plein de variantes (au lieu de oui-non, un nombre réel par exemple, etc.)

Dans beaucoup de problèmes plus complexes dont la résolution inclut des stratégies de machine learning, ont doit réduire la dimension du problème (qui est trop compliqué pour être abordé de façon frontale) ce qui mène à construire une sorte de machine dont les fonctions élémentaires sont, comme tu l'indiques, sous définies par le programmeur et entraînées, mais l'assemblage de la machine est lui-même est fixé par le programmeur, c'est une étape importante de modélisation.

Ainsi par exemple (complètement hypothétique), si on écrivait un programme pour compter le nombre de voitures sur une route à partir de photos, on pourrait essayer de fractionner le problème en deux sous-fonctions qu'on pourrait entraîner:

• La première apprendrait à reconnaître une route sur une photo (comme domaine)
• La seconde les voitures mais seulement dans le domaine livré par la première fonction – ce qui est a priori plus facile que dans le cas général, parcequ'en général il y a moins de diversité dans les objets trouvés sur une route que dans un paysage quelconque.

Si on utilisait la stratégie “frontale” de juste laisser une machine ingurgiter des milliers de photos de scènes incorporant des voitures associées au nombre de voitures qui sont sur la route (s'il y a une route sur la photo) on n'aurait aucune chance d'obtenir un résultat probant.

Même si le programmeur n'implémente pas explcitement la reconnaissance de route ou celle de voitures sur la route et s'en remet à un processus d'apprentissage, il utilise sa compréhension du problème pour élaborer une esquisse de solution.

De plus, pour moi un design pattern c'est un choix qui est en un sens arbitraire, parce que sinon, ce n'est pas un design pattern, c'est simplement une technique nécessaire.

Le but des design-patterns n'est pas seulement de participer à la résolution du problème qui fait l'objet de l'écriture du programme dans lequel ils sont utilisés. C'est une notion qui recouvre les méthodes d'ingénierie qui permettent de tirer parti du soft dans le software – il s'agit donc de méthodes qui facilitent l'évolutivité et la maintenance des programmes.

À ce titre les monades sont un exemple de design pattern, elles permettent par exemple d'éviter de programmer en style spaghetti comme lorsqu'on utilise des exceptions ou bien des callbacks en programmation asynchrone.

Je pense que c'est un peu plus que cela, c'est un « design pattern » au même titre que des objets dans un langage à objets.

Du point de vue du programmeur c'est un design pattern, si tu préfères. Après, comme toutes les choses de ce monde, elles ont plein d'aspects différents. Connaître la théorie mathématique des types qui permet de réconcilier “la monade du programmeur” avec “la monade du mathématicien” n'a un intérêt pratique que pour les spécialistes de théorie des types qui développent des langages comme OCaml ou Haskell – mais pour développer avec ces langages, on ne perd rien à s'en tenir à une considération rudimentaire se bornant à voir une monade comme un design pattern qui factorise la prise de décision si le dernier calcul a fini par une erreur alors ne fait rien sinon applique la fonction f au résultat.

La seule contrainte est que le sel doit être de taille suffisante (128 bits c'est très bien), et différent pour chaque utilisateur.

Question naïve: le choix (tout aussi naïf) consistant à prendre comme sel le nom civil de l'utilisateur (pas son login, souvent trop court pour arriver à 128 bits, mais son vrai nom) ou bien son login+date de naissance, numéro de personnel, etc. , sont donc des choix possibles et sains?

Et merci pour ce commentaire-journal très détaillé et intéressant!

Pourquoi avoir donné un sens spécial au caractère underscore ? Si je ne me trompe pas, il n'en avait pas jusque là.

Quel sens spécial? C'est juste un identifiant valide je m'en servais déjà pour marquer explicitement les arguments non-utilisés des fonctions ad-hoc passées à des fonctions d'ordre supérieur. Comme par exemple dans

                someArray.reduce(function(ax, _, _, _) {
                    return ax + 1;
                }, 0);

qui compte les éléments de l'array (exemple scolaire).

Ce que je fais me plaît, je n'ai pas besoin de l'aval de quelqu'un pour me sentir bien :)

Je dis juste ça en passant, mais imagine un peu que tu sois prof en lycée et prononce cette phrase devant une trentaine de pré-ados. ;)

Les monades sont juste un design pattern – ou patron de conception pour ceux qui connaîtraient, voire utiliseraient, l'expression française adéquate – qu'on peut très bien utiliser en JavaScript comme dans tous les langages qui permettent de créer des fermetures. Dans le cas de la programmation asynchrone, il est même recommandé d'utiliser un style monadique plutôt que le style spaghetti imposé par les callbacks car le premier permet de préserver l'idée de composition des traitement, qui disparaît complètement avec les callbacks.

(j'exagère le trait, certes, suffit de comprendre ce qu'est this dans un certain contexte, mébon)

Tu n'exagères pas tellement, c'est suffisamment complexe pour que Douglas Crockford conseille simplement de ne jamais utiliser this quand on écrit un programme. Les règles concernant l'usage de this ne sont, bien-sûr, pas incompréhensibles, mais c'est une chose d'écrire des programmes et une autre de faire la maintenance: dans cette perspective, il vaut toujours mieux préférer les solutions simples, robustes, et faciles à appréhender car lorsqu'un on fait la maintenance, on n'a pas une vision aussi claire du programme qu'au moment où on l'écrit.

Quant à la lib standard, c'est en fait essentiellement celle de Java, donc il on se retrouve à mélanger deux styles de programmation qui n'ont pas grand-chose à voir.

Pourquoi? Si tu fais allusion au impératif vs. fonctionnel Lisp est un langage multi-paradigme et pas du tout un langage fonctionnel pur.