Michaël a écrit 2929 commentaires

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.

Dans le cas de lisp et consorts, le très fort parenthésage est un choix très fort qui ne plaît pas de toute évidence, à beaucoup de développeurs.

Les syntaxes de C, C++, Perl ou PHP ne sont pas moins abominables. Une syntaxe agréable n'est pas une condition sine qua non à l'adoption d'un langage.

Si justement. Le principe est : est-ce que ton programme continue de tourner si tu vires zlib. Si oui, cela va, sinon tu es en violation de la licence.

Merci pour cet éclaircissement. Je n'avais jamais réalisé que la définition de produit dérivé pour la GPL était si large!

clojure côté backend (ok, plus angularjs en front)

Un langage de type Lisp sera très probablement le prochain grand langage du web, si ce n'est pas déjà le cas car certains considèrent presque JavaScript comme un Lisp!

JavaScript a montré la pertinence de et familiarisé les développeurs avec certains traits typiques de Lisp comme les fermetures, les fonctions d'ordre supérieur, les fonctions anonymes, la programmation générique et un format de sérialisation qui correspond à la notation dans le code-source. Avec tous ces ingrédients, l'acceptance pour un langage de type Lisp a été bien préparée.

Je me pose pas mal de questions sur l'avenir du JavaScript.

JavaScript n'est pas près de disparaître car:

• Il a aujourd'hui une énorme communauté de développeurs

• C'est un langage définit par un standard

• C'est le soldat qui a gagné la “guerre” des RPCs, des standards comme CORBA n'existent plus qu'à l'état de niche, et le JSON/HTTP s'est établi comme standard de facto dans le monde des RPCs. Bien-sûr on peut utiliser JSON/HTTP sans JavaScript, mais beaucoup de services proposes des APIs JavaScript pour interagir avec eux via JSON/HTTP.

• Les interpréteurs de JavaScript sont à la pointe de la technologie en raison de l'attention qu'ils ont reçue dans les dernières années à cause de la compétition acharnée entre les navigateurs. Sans cette compétition très tendue en arrière plan, il y a peu de chance qu'on voie apparaître des interpréteurs aussi performants pour des langages plus confidentiels.

JavaScript n'est pas resté immobile. On a vu apparaître les Promise, puis certains ont détourné les générateurs. On parle beaucoup d'async/await. Il n'empêche, on est toujours dans un bourbier, coincé entre des API qui utilisent parfois des callbacks, parfois des promises.

Ce n'est pas un très gros problème. En pratique c'est presque toujours mieux de programmer
avec des promise (style monadique) qu'avec des callback (style spaghetti). Losqu'on doit
utiliser une bibliothèque qui utilise des callback c'est utile (ou nécessaire) d'adapter son interface
en style promise.

Le typage statique est également très intéressant pour détecter des erreurs.

Programmeur OCaml chevronné, je trouve que le typage statique brille tout particulièrement pendant les refactorings car les gros changements d'organisation dans un programme amènent leur lot d'erreur. Pour des programmes équivalents, un refactoring JavaScript me prend 4-5 fois plus de temps qu'avec OCaml.

Dernier point, avec ES6 et les versions futures, je trouve le langage de plus en plus complexe. […]

Je partage ton avis. Pour être honnête, je n'ai jamais beaucoup aimé JavaScript jusqu'au jour
où j'ai lu et apprécié le livre de Douglas Crockford *JavaScript – The Good Parts” qui propose
une méthodique de programmation très simple, cohérente, et claire. Quel contraste avec le côté
bidouille et fouillis qu'on voit dans la plupart des programmes qu'on peut lire!

Et vous, quels sont vos langages du moment ? Et que font-ils mieux que JavaScript ?

Mon langage du moment est – depuis 1999 – le OCaml. Son adoption dans l'industrie se solidifie d'année en année. Ce qui pourrait t'intéresser, c'est la présence d'un compilateur js_of_ocaml qui permet de compiler
son programme OCaml en JavaScript. Écrire des bindings pour utiliser ses bibliothèques JavaScript sur
avec ses programmes OCaml est très facile quand on a pris le tour de main – mais en général il faut
un peu plus de travail pour avoir une interface “OCaml-ienne”. Mais ça marche superbement!

le module zfs.ko ne peut être compilé sans les entêtes du noyau

On peut dire cela de tout programme ou toute bibliothèque qui utilise des fonctions venant d'un tiers composant logiciel (ici le noyau). Si par exemple j'écris un programme qui utilise la zlib je vais devoir lire zlib.h dans mon programme, mais ça n'en fait pas un produit dérivé! Qu'est-ce que c'est que cet argument farfelu? Y-a-t'il un détail plus subtil?

99% étant un nombre tiré de mon chapeau, ça pourrait être moins ou plus, mais on voit l'idée

Sarkozyste! (référence à la proportion d'énergie nucléaire produite en France, d'après lui.)