neil a écrit 428 commentaires

Le noyau actuel (en Python) lance l’interpréteur standard (GHCI) et fait des entrées-sorties sur son processus. Un vrai noyau utiliserait directement l’API de GHC pour être un vrai interpréteur.

En français, […] précédé d'un espace insécable

Sauf que les règles auxquelles tu fais références ne sont lois que dans l’imprimerie nationale française. Chaque éditeur est évidemment libre d’éditer son propre jeu de conventions (et c’est ce qui arrive en pratique), et les règles d’autres pays francophones sont différentes. Par exemple, les espaces fines précédant les doubles ponctuations sont très réduites en Suisse, voire souvent absentes.

Un autre projet GNU (sous GPL2) d’analyse de données est le langage R. R dispose d’une communauté très importante et d’une incroyable quantité de fonctions de manipulations de formats textes, de statistiques et de graphisme (en particulier l’excellent ggplot2).

Le premier exemple d’utilisation pourrait être traduit en :

a <- read.fwf ('testadd.txt', widths=c(10,10,10))
a$V4 <- 'Home'
write.table(a[c('V3', 'V2', 'V1', 'V4')], quote=FALSE, row.names=FALSE, col.names=FALSE)

R dispose aussi d’une grande quantité de fonctions semblables aux requêtes SQL (join et companie), ou inspirés de programmation fonctionnelle (telles que map).

On espère que cela inspirera d'autres personnes pour écrire des noyaux dans leurs langages préférés. J'attends avec impatience les notebooks haskell, perl, ruby, etc.

Il y a ihaskell-notebook (repo github).

Comme on parle de faire un routeur sous Linux avec ce genre de carte, ce n’est vraiment pas adapté et il s’agit vraisemblablement de domotique. Donc, il n’y a pas de commutateur, on n’utilisera pas les VLANs (802.1Q), mais juste un alias sur eth0 (en eth0:0, non-taggé), et le travail est quasiment nul (en gros, rajouter un truc du genre ifconfig eth0:0 192.… up).

Il y a différents cas où on peut vouloir ça, par exemple si on veut faire un routeur onion en n’utilisant qu’un seule interface (eth0 ou wlan0 selon les cas). Dans ce cas, on se moque du débit, on se moque d’avoir d’autres interfaces, on n’a pas besoin de tagging, et la machine est configurable aux petits ognons :p (eg sur raspberry, mais avec une seule interface)

Quand je parle de « calculer length », je sous-entend qu’on ne peut pas, et que length n’est pas calculable, au sens classique du terme.

si on peut calculer length, on peut résoudre le problème de l’arrêt

Euh, vraiment ? Ça suffit ?

Oui. Tu peux facilement créer une liste de toutes les instructions effectuées pour une machine de Turing donnée (en terminant la liste quand la machine s’arrête, en ayant une liste infinie, par construction, sinon). Trivialement, une méthode qui te dit si ta liste est infinie ou non (c’est à dire un length dans ℕ∪{∞}) résout le problème de l’arrêt.

J’assimilais la notion d’échec dans un map de LupusMic à la pureté de la fonction mappée. Ça n’empêche effectivement pas qu’on ait d’autres notions d’échec en Haskell, comme le fait qu’on ait des fonctions partielles, head dans ton exemple (mais on n’a pas trop le choix si on veut que head soit polymorphique, de part le free theorem), ou le fait que les fonctions ne soit évidemment pas toutes calculables vu qu’Haskell, comme tous les langages de programmation utiles, est Turing complet (si on peut calculer length, on peut résoudre le problème de l’arrêt). J’avoue avoir du mal à fusionner ces deux autres notions d’échec (la non-calculabilité et la non-totalité) en une seule comme tu le fait par l’adjectif « complèt[e] ».

Mon exemple reste très artificiel, principalement pour montrer qu’on peut considérer du code qui est effectivement utile en Haskell (et pas juste des fonctions pures). On peut suivre en Haskell la démarche du langage fonctionnel distribué de référence, Erlang, où l’échec (dans ton sens) est considéré comme normal (avec du monitoring de processus). Tu trouveras tout ça dans le chapitre 14, dédié à la programmation distribuée. Ça correspond à du Cloud Haskell.

Par contre, je me dis qu'il peut arriver qu'une opération map échoue

Ça dépend de ce que tu veux dire. Les fonctions Haskell sont pures (elles n’ont pas d’effet de bord), donc un cas comme celui plus au pour convertir une liste de chaînes de caractères en liste d’entier correspondant à leurs tailles pourra s’écrire :

> map length ["a", "aa", "aaa"]
[1,2,3]

Comme length est une fonction pure, elle n’échouera jamais, que son appel soit effectué via un map, ou en parallèle via un parMap.

Maintenant, tu peux vouloir utiliser des fonctions avec des effets de bord, ce qui correspond à la monade IO en Haskell. En imaginant une fonction length' qui peut échouer, une façon standard serait de renvoyer Nothing en cas d’erreur, mais on peut conserver l’entrée avec Left/Right. Le map devient alors un mapM dans la monade IO :

> resultat <- mapM length' ["a", "aa", "aaa"]
[Right 1,Right 2,Left "aaa"]

Tu peux remarquer que le code est quasiment identique (dans l‘interpréteur). Relancer le calcul pour les éléments pour lesquels la fonction a échoué se fera avec la même fonction mapM, et un simple encapsuleur pour length', ne ré-exécutant le code qu’en cas d’échec (pour le dernier élément dans l’exemple précédent).

> mapM (wrap length') resultat
[Right 1,Right 2,Right 3]

Où wrap est définie comme :

wrap f (Left s) = f s
wrap _ r = r

Rappeler plusieurs fois la fonction encapsulée avec mapM relève de la simple politique du programme. Ce qu’on peut conclure, c’est qu’Haskell donne tous les outils pour exprimer ces concepts de façon très concise.

De façon générale, il vaut mieux laisser le compilateur faire son boulot pour des cas triviaux comme celui-là. Sur mon installation (GHC 7.6.3) je n’ai pas de différence notables entre tes deux versions, et la version que j’ai donnée tout en haut est plus rapide en désactivant les optimisations. En activant les optimisations il n’y a pas de différence entre toutes ces versions.

Si tu avais un débordement de pile, le runtime te le dirait avec un message du genre :

Stack space overflow: current size 8388608 bytes.
Use `+RTS -Ksize -RTS' to increase it.

Effectivement, si on ne comprend pas bien comment marche l’évaluation dans Haskell, ça peut arriver, et l’exemple le plus parlant pour le montrer et la différence entre foldl et foldr.

Autrement c'est étonnant que le par(map|reduce|fold) semblent émerger maintenant sur OCaml/Haskell & autre alors que les collections parallèles et le fork/join sont dispo depuis super longtemps dans Scala/Groovy, et sont dispo dans Java 8.

Le parallélisme dans Haskell, aussi bien sur architectures à mémoire partagée que distribuée, remonte aux années 90 (par exemple avec GUM).

Ce n’est pas parce qu’un livre sort maintenant en étant uniquement dédié au parallélisme et à la concurrence que ça n’existait pas avant. Une bonne partie de ce qui est écrit dans ce livre n’est que description de l’état de l’art de ce qui se fait depuis des années en Haskell. Même dans l’ancien (bon seulement 5 ans) livre Real world Haskell, un chapitre était déjà dédié à tout ça (parlant aussi du MapReduce de Google), et l’accelération GPU directement en Haskell avec optimisations (Accelerate) existait déjà.

Cependant, pas une seule fois elle n'a essayé de savoir si nous étions bien les véritable titulaire du compte

En même temps, elle a peut-être faire une recherche inversée sur le numéro de téléphone qui l’appellait et vérifié qu’il correspondait bien au nom dans l’adresse e-mail, ainsi qu’à la géolocalisation des IPs depuis lesquels les e-mail étaient récupérés. :-D

D’après l’auteur, la version HTML ne devrait rester que quelques jours en ligne, le temps de l’OSCON. La version définitive librement accessible sera disponible ultérieurement.

Effectivement, impossible de stocker des mots de passe sur des cahiers manuscrits ou des clés USBs.

L’exemple qu’il donne est probablement extrême, en particulier s’il ne suit pas des conventions standards. Mais tu connais bien le langage Haskell, et le puissance (et concision) générée par la combinaison des opérateurs fonctionnels (eg $, (.).(.)), applicatifs (eg <*>, <|>), monadiques (eg >>=, >=>,) et autres.

Pour ce qui est des mathématiques, les notations ne sont pas limitées aux variables, mais concernent surtout les opérations que l’on peut effectuer. L’article de Babbage est joli sur ce point (je copierais-collerais bien ça ici, mais les maths ne passent pas). On pourrait prendre des exemples bateaux avec des représentations spatiales (division, simplification de fractions, etc). On pourrait aussi discuter des symboliques, certes plus simples, des autres domaines (diagrammes de Feynman, électroniques, etc). Derrière la puissance d’un langage graphique riche, il y a le fonctionnement de notre cerveau, où une partie très importante est accordée à la vision, en sus de la simplification apportée par la symbolique.

Les informaticiens connaissent bien […]

Et probablement encore mieux Paul Graham.

Oui, et on peut faire la même chose en binaire… Même les « mots » sont « des symboles [définits] pour les concepts courant » de toutes façons. Mais au plus le raisonnement est abstrait, au plus la nécessité de la symbolique se fait sentir. Les informaticiens connaissent bien Charles Babbage, un des pionniers de l’informatique, et son célèbre On the Influence of Signs in Mathematical Reasoning, où il développe bien sur cet effet, souvent résumée en :

The quantity of meaning compressed into a small space by algebraic signs, is another circumstance that facilitates the reasonings we are accustomed to carry on by their aid.

On sait bien comment même chez les enfants, l’algèbre permet d’aider au raisonnement de façon très efficace. On voit bien comment les mathématiques sans concepts algébriques, par exemple les Œuvres d’Archimèdes mènent à des démonstrations verbeuses et difficile à suivre, alors que ces longs paragraphes se résolvent en quelques lignes d’algèbre (en suivant des notations standards). Pour des démonstrations moins triviales, le symbolisme est obligatoire.

PS : Oui, je parle de vraiment utiliser des mathématiques, par de tout ce qui concerne son enseignement (y compris les exercices).

C’est rigolo parce qu’en mathématiques on n’utilise pratiquement que des symboles spéciaux, caractères grecs, et très peu de caractères romains, sur des tableaux (ou des cahiers). Et les caractères grecs qu’on utilise sont les versions non-cursives.

SCCS montre qu’il y avait quand même de la vie avant le GNU.

NumPy est rapide pour certaines opérations déjà optimisées dans BLAS et encodées en dur dans la bibliothèque, mais est assez lent pour tout le reste, y compris des choses basiques comme les convolutions. Rien que le fait que ce soit du pur Python (à l’utilisation, pas la bibliothèque en elle-même qui est en C) est déjà lent, il y a l’évaluation paresseuse qui manque (quand on écrit b + c + d il fait une copie mémoire pour b + c, puis encore une opération et une allocation pour le + d). Ensuite il y a le problème du parallélisme qui n’est pas géré (mais c’est général en Python).

L’avantage des bibliothèques comme Pythran (et comme le dit serge_paille en dessous), c’est de passer par une étape intermédiaire qui va appliquer tout un tas d’optimisations avant l’exécution (la liste en dessous pour Pythran est impressionnante : AVX, OpenMP, évaluation paresseuse [dans un autre sens], constant folding, …). L’un des gros avantages de Pythran c’est d’être compatible avec NumPy, ce qui est top pour pouvoir développer et partager du code rapidement (sous-entendu, par copier/coller, ce qui est l’outil fondamental des langages non-typés :p), et permet d’avoir une courbe d’apprentissage douce. En gros ça rajoute une partie de l’étape « compilation » qui manque à un langage de script.

les individus à l'esprit tortueux semblant aimer theano (vous vivez dans un monde peuplé de tenseurs vous ?)

Sachant que les tenseurs sont des tableaux multi-dimensionnels, avec tout un tas d’opérations bien définies dessus, et vu que la bibliothèque (ultra-lente mais) de facto standard pour faire du calcul scientifique sous Python est NumPy, basée sur des tableaux multi-dimensionnels, il me semble que oui, une énorme partie des applications scientifiques sous Python vivent dans un monde de tenseurs. Ne serait-ce qu’en raison de la facilité pour les opérations tensorielles à être implémentés de façon rapide voire parallèle.

En plus de la génération transparente de code pour GPU, Theano est aussi capable de générer du code C de façon dynamique. Vu que c’est aussi ce que fait Pythran (module le ++), comment est-ce que les algorithmes et technologies de ces générations de code se comparent ?

Theano se compare aussi à des bibliothèques écrites dans d’autres langages (comme Torch en LuaJIT ou RNNLM en C++). Il est d’ailleurs sympa de constater que même sans activer le support des SMP ou des GPU, Theano est plus rapide que la version C++ de RNNLM. Est-ce que des comparaisons du même ordre sont envisagées pour Pythran, histoire de ne pas comparer des pommes et des bananes (unique processeur VS SMP, ni code C++ généré VS code pur Python) ?

Je vois que tu n’as pas lu le commentaire de dave_null plus bas.

Ça prend à peu près 2 minutes pour refaire la même chose avec du JavaScript ou du Flash, selon le navigateur, et de faire une page en remplaçant Linux par Windows pour que l’utilisateur colle ça dans son cmd.exe. Ce genre d’attaque où la cible est l’humain, avec un appât du genre « vous allez être un warlord haxor » ou « le sultan Alladin va vous filer 1 million de dollars » est vieux comme le monde. Mettre ça sur le dos des environnement de bureau est d’une naïveté effarante.

Ce qu’il veut dire c’est que les communications entre threads se font par des canaux spécifiques d’envoi de message. C’est plus sûr que de pouvoir directement toucher à des morceaux de mémoire des autres threads, avoir besoin de faire des locks ou éventuellement les flinguer. Ça reprend donc un peu le modèle de communication inter-threads d’Erlang. Ça ne veut pas dire que chaque thread est dans un processus différent complètement cloisonné et Rust propose en fait un passe droit pour pouvoir directement toucher à la mémoire partager (on peut aussi de base accéder aux constantes des autres threads).

l'ordonnancement des threads (goroutines) est géré par le runtime […]

Si les goroutines étaient limitées à ça, personne n’en aurait jamais parlé. C’est ce qui se faisait déjà du temps de Java 1.1, et est facilement accessible dans la plupart des langages sous l’appellation plus courante de green thread (ou fiber sous Windows). Le fait que faire un yield appelle le scheduler est trivial.

Ce qui est plus cool avec les goroutines c’est que c’est intégré au langage, comme en Erlang par exemple et même si Scala et d’autres font ça entièrement en bibliothèque, et qu’on peut faire des choses mois sûres mais plus puissantes (grace à la mémoire partagée). Le tout en restant dans un cadre syntaxique très proche du C et sans nouveaux concepts (parfait pour ceux qui ont la flegme d’apprendre un nouveau langage).