Chaddaï Fouché a écrit 100 commentaires

Rassurez vous, Haskell gère très bien l'Unicode, mais pas pour l'affichage dans une structure imbriquée.

Ce passage peut intriguer… Le problème n'est pas tant qu'Haskell ne gère pas l'affichage d'Unicode dans une structure imbriquée (pour le coup ce serait problématique !) mais qu'ici Guillaum utilise la fonction print, cette fonction affiche le résultat de show sur son argument et cette fonction est destiné au débogage ou à l'affichage rapide de valeurs quelconques dont le type est une instance de la typeclass Show. L'objectif n'a jamais été de présenter correctement ou joliment une structure de donnée mais plutôt d'en donner une expression qu'on puisse éventuellement recoller dans son code sans problème. En particulier l'instance de Char est telle que lorsqu'on show un caractère hors de l'ASCII, son code caractère est affiché à la place, de sorte qu'on puisse le recoller dans le source sans aucun problème de compatibilité.

Si à la place vous utilisez putStr sur une String comportant de l'Unicode, vous verrez que cela fonctionne parfaitement (pour peu que votre locale soit bien réglée).

Ici par exemple on pourrait utiliser :

showResult :: Maybe [String] -> IO ()
showResult m = putStr (maybe "Pas dans le dictionnaire" unlines m)

Qui afficherait un anagramme (accents compris) par ligne, ou "Pas dans le dictionnaire" si le mot n'est pas trouvé.

Ligne 11, définition de getAnagram qui regarde dans la structure si la clé y est. Pas d'opérateur pour l'accès aux cases d'un dictionnaire en Haskell, il faut utiliser Map.lookup qui renvoie Nothing si la clé n'existe pas ou Just value si elle existe.

Il existe en fait un opérateur : (!) comme dans dict ! "clé" mais la plupart des utilisateurs d'Haskell préfère la fonction lookup car celle-ci renvoie une valeur de type Maybe ... et oblige donc l'utilisateur à traiter le cas où la clé n'existe pas dans le dictionnaire plutôt que de soulever une exception comme le fait (!). On peut dire que cette différence résume bien l'esprit d'Haskell : ne pas utiliser de fonction partielles (qui peuvent échouer sur certaines entrées), préférer encoder le fait qu'une fonction puisse échouer dans son type de sorte qu'un utilisateur doive traiter le cas d'erreur (mais fournir des combinateurs comme maybe pour rendre cela facile !!).

Notez que les opérateurs en Haskell sont des fonctions comme les autres (en dehors de leur syntaxe) et peuvent être définis dans n'importe quel module. C'est une force qui peut parfois être légèrement abusée au goût de certains… ;-)

Ce que dit maclag est vrai mais en même temps, l'un des avantages de NixOS c'est qu'une fois installée, tu es assez tranquille : même s'il y a des changements qui cassent ta distribution, tu peux toujours revenir en arrière (même si elle ne démarre plus comme expliqué dans l'article). NixOS est très robuste de ce point de vue, bien plus que des distributions plus matures.

Je dirais que le principal écueil que tu risques de rencontrer c'est le nombre de paquets, si tu as des besoins bien particuliers. Ce n'est pas comme si nixpkgs était vide, la plupart des gros paquets y sont (bureautique, édition, internet, graphisme, etc) mais si tu veux un logiciel à l'écart des sentiers battus… il faudra peut-être que tu fasses un paquet pour l'ajouter à nixpkgs, ce n'est pas trop difficile (c'est même très simple pour un logiciel bien conçu comme le montre l'exemple dans l'article, mais si le modèle de déploiement est très non-standard, ça peut devenir plus dur).

Alors actuellement… Sur le site version française,
sur le côté :
- les versions pour mac et sources sont la 1.0,
- pour win32 la 0.8.9,
sur la page de téléchargement, il y a marqué version stable, 0.8.9 (sic…) :
- source 1.0
- mac et win32 0.8.9

La page de téléchargement sur le site anglais semble n'avoir pas été mis à jour du tout (sources toujours en 0.8.9).

Légèrement bordélique donc !

Sauf que les onglets de Chrome sont toujours sur un seul écran, plus on en met et plus ils sont étroits… Ce qui n'est pas idéal lorsqu'ils n'affichent plus que les favicons et que tu as 12 onglets sur un même site. Les onglets de Firefox ont une largeur minimale, au delà, les onglets dépassent de l'écran et on peut les faire défiler à la roulette.

Peut-être qu'on peut régler Chrome pour éviter ça (mais vu le manque de personnalisation possible dans l'interface de Chrome, je n'en suis pas sûr du tout) mais à l'inverse l'apparence de Firefox est très facilement personnalisable et avec les extensions, on a un grand nombre d'options. De plus Chrome n'a pas les groupes d'onglets, ce qui est une raison supplémentaire d'avoir trop d'onglet à la fois (on peut utiliser plusieurs fenêtres mais la gestion est beaucoup plus complexe et fragile).

Bref… dans mon expérience Chrome/Chromium est plus robuste, parfois plus performant (parfois moins) et plutôt bien fichu mais il est bien moins configurable que Firefox en tout domaine et il supporte moins bien le style "10000 onglets ouverts à la fois" que j'affectionne. J'ai donc fini par revenir vers Firefox (Aurora plutôt).

Dans ce cas Linux n'est pas si malléable que ça… ;-)

Juste pour un exemple : modifier l'emplacement des fichiers utilisateurs se fait en allant voir les propriétés (clic-droit) des dossiers spéciaux Documents/Musique/…, il y a un onglet dédié à ça. Je n'appellerait pas ça "bidouiller comme un goret".

Bien que Windows soit loin d'être aussi malléable que Linux (c'est une évidence), il est également clair que tu ne t'y connais absolument pas car pratiquement la moitié de tes exemples sont faux… Peut-être aurais-tu dû te limiter aux parties basses de l'OS qui sont effectivement non-remplaçable et éviter de dire des bêtises sur les emplacements, le shell, le logo, les icônes, le thème graphique (sans même parler des logiciels tiers) et les systèmes de fichier. Au minimum, et je ne suis pas certains pour certaines autres parties.

En fait tu as exactement démontré l'affirmation que tu citais : bien que moins malléable que Linux, Windows l'est bien plus que la plupart des Linuxiens ne se l'imagine.

Soyons sérieux une minute… Tu as déjà vu de beaux sous-titres dans les productions professionnelles (DVD, bluray…) ? Parce que moi, pratiquement jamais !

Tout au plus quelques professionnels plus au fait font un léger effort pour la lisibilité du machin mais ils sont souvent pressés par le temps et sous-payés de toute façon donc le positioning, les légers changements de nuance pour faire ressortir un sous-titre, etc, passent à la trappe.

Le fansub que tu décries est en fait la seule source qui prouve de façon régulière qu'il est possible de faire bien mieux que l'habituel lorsque le sous-titrage est un labeur de passionné. Evidemment, de temps en temps tu tombes sur des horreurs qui te font regretter d'avoir des yeux !

Note que tous les fansubbers sérieux (du moins dans le monde anglo-saxon, je ne regarde pas les fansubs français) mettent leurs sous-titres en soft, généralement en ASS intégré au conteneur (MKV).

Haskell a effectivement été créé pour la recherche en informatique (par un comité de chercheurs convaincus par le paradigme fonctionnel) mais aujourd'hui, plus de vingt ans après sa création, il a évolué en un langage plus généraliste.
On le retrouve dans les outils utilisés pour créer les programmes embarqués dans des véhicules de transport, il est utilisé dans un certain nombre d'institutions financières pour modéliser les produits complexes, Galois utilise Haskell à la base pour répondre à la plupart de ses contrats dont certains avec le gouvernement étasunien … et maintenant pour la création d'un jeu libre. C'est d'ailleurs l'un des domaines où Haskell est le moins mûr, car le paradigme fonctionnel pur ne se prête pas de façon évidente à une telle entreprise, il y a encore beaucoup de recherches (NB : cela ne signifie pas qu'Haskell ne peut pas faire aussi bien que des langages plus classiques, simplement les chercheurs expérimentent encore pour trouver des façons plus élégantes de faire les choses que dans des langages impératifs).

Exemples d'utilisation d'Haskell dans un contexte commercial : http://www.haskell.org/haskellwiki/Haskell_in_industry

Haskell a l'un des modèle de threads léger les plus avancé, ainsi qu'un large choix de librairies de gestion du parallélisme dont les classiques mutex/locks, de la STM (mémoire transactionnelle logicielle), des canaux pour les agents, une modèle de stratégie qui permet de décrire de façon non-invasive et déterministe comment exécuter du code purement fonctionnel en parallèle ainsi qu'une librairie de vectorisations des opérations (DPH data parallel Haskell, voir Repa) à la pointe de la recherche.

Mais clairement Haskell n'a pas du tout le même objectif que Rust : Haskell est bien plus haut niveau et met l'accent sur un cœur purement fonctionnel (discernable par les types). Est-ce un bon choix pour écrire le browser du futur… pourquoi pas, mais cela aurait impliqué un très grand effort des développeurs Mozilla pour changer leur perspective du paradigme impératif au paradigme fonctionnel.

Tu as manqué l'essence de l'article : le truc révoltant dans la proposition de Sony c'est qu'ils n'envisagent pas de réécrire un équivalent de Busybox et son environnement en propriétaire, ce serait parfaitement légitime (et beaucoup trop coûteux de leur point de vue, déjà qu'ils auraient préféré continuer à exploiter Busybox...).

Non, ils veulent juste un équivalent de Busybox même, qu'ils feront alors tourner dans un environnement toujours sous GPL qu'ils ont modifié sans rediffusion des sources de façon à enfermer leur client de façon artificielle dans leur circuit de redistribution et offre de service !
Mais comme cet environnement (en particulier le noyau Linux) n'a pas fait appel à la SFC pour défendre ses droits et ne le fait pas lui même en général, Sony pourra ainsi violer la licence GPL sans souci (puisque uniquement Busybox avait délégué la protection de ses droits à une organisation active comme la SFC).

Donc ton :

Ce n'est pas du piratage si le code libre n'est pas utilisé.

est malheureusement parfaitement exact mais sans objet ici puisque du code libre est justement utilisé et modifié de façon contraire aux idéaux du libre et contraire à la licence.

Ok... C'est peut-être un abus mais franchement vu ce qu'ils demandent et qui il y a en face (entreprises qui ne se privent pas d'exploiter tout vide juridique), c'est tout de même un peu fort de café de dire que c'est malsain de la part de la SFC.

Ils ne demandent pas de sources de logiciels sous une autre licence que la GPL. Or si l'on choisit la GPL c'est bien que l'on souhaite que son code reste libre et ne puisse être modifié et diffusé sans diffusion des modifications, c'est l'objectif même de cette licence !

Donc personnellement quand tu dis :

Ça pose une vraie question, quand on code un soft sous GPL, on veut évidemment que la licence soit respectée, mais si on garde les droits en tant que simple auteur, on souhaite également faire valoir ses droits en personne.

Ça me fait bien rigoler dans le genre argument de mauvaise foi...

L'un des problèmes de la GPL est bien que les auteurs (souvent multiples) n'ont ni les moyens ni le temps de protéger leur création contre le genre d'exploitation que les cibles de SFC en font. Et souvent ces auteurs ne sont pas conscient de la possibilité de déléguer cette protection à un organisme comme la SFC, ou n'ont pas le temps, ou ne prennent pas la peine de le demander.

Donc ton indignation devant les procédés de la SFC me semble plus que légèrement hypocrite, ce n'est pas comme si elle utilisait ces procédés contre des gens de bonne foi, il est difficile d'intégrer la Busybox dans son matériel sans avoir la moindre idée de ce que ça implique !

Il veut parler d'un daemon sur le client qui synchronise automatiquement en continu un dossier local avec le stockage distant. Autrement dit tu n'as pas à gérer le transfert de fichier ou la synchronisation entre ton stockage local et distant, le daemon se charge de tout. Ainsi il n'y a pas de délai ou de risque que tu perdes des données si tu as oublié de déclencher la synchronisation suffisamment récemment.

A vrai dire je n'aime pas trop ce que j'ai pu voir de ce "beau" langage, mais le choix du "==" se défend car il ne s'agit pas d'une égalité mais d'un test d'égalité ! On peut écrire "2 == 3", c'est une expression légitime et valide, donc comme égalité...

En bref "x == y" correspond à la question "x et y sont-ils égaux ?" et non pas au "x = y" des Mathématiques, il est donc justifié d'utiliser un autre symbole (et c'est un choix qu'on retrouve dans la plupart des langages fonctionnels conçus par des gens fort en théorie et en formalisme).

Jedaï

voire à la rigueur la définition (soit x=3)

Ben... Voila.

Une définition, ça se fait une seule fois : maintenant que tu as dit que x ça valait 3, tu ne va pas dire trois lignes plus loin que ça vaut 4 !! Sale menteur !

Bien sûr on peut avoir d'autres définitions de x dans un autre contexte mais ça c'est acceptable, ce n'est pas vraiment le même x (les définitions sont locales).

Dans les langages de programmation fonctionnelle (Haskell, OCaml, Scala, F#, ...) le signe égal est réservé aux définitions, une fois un nom défini, la valeur désignée ne peut plus changer. Lorsqu'ils ont une notion de "variables" et d'affectation, ces langages utilisent une autre syntaxe que le "=", comme d'ailleurs certains langages impératifs autres que C (Pascal par exemple).

L'emploi d'un "=" pour l'affectation est à mon sens l'un des choix les plus discutable du C, malheureusement hérité par la plupart des langages mainstream.

L'exemple d'erreur fourni n'est pas vraiment convaincant car finalement peu fréquent, c'est plus la perversion de l'égalité mathématique, et le manque de clarté dans le raisonnement qui en résulte chez beaucoup d'étudiants, que je déplore.

Jedaï

Ça c'est facile, il y a des tas de gens qui pensent beaucoup de mal de leur entreprise et de son utilité au delà de leur salaire direct... Mais les commerciaux quoi qu'ils en pensent, ne diront jamais de mal de leur employeur, ce serait une façon radicale de se faire virer à coup sûr.

De plus il me semble que Gower ne dit pas que les éditeurs sont inutiles, simplement que leurs pratiques commerciales actuelles sont crapuleuses et entravent le progrès scientifique.

Oui, je trouve l'article un peu injuste envers ces excellents violons qui probablement étaient véritablement et constamment meilleurs que le gros de la production des autres luthiers de l'époque... Le mot clé étant "de l'époque", nous en savons plus maintenant sur l'acoustique, nous avons accès à d'excellent matériaux, à d'excellents outils et à de très bonnes formations, il n'y a donc rien d'étonnant que les violons modernes de bons luthiers soient au moins équivalent à des Stradivarius.

Évidemment il est tout de même bon qu'une telle étude vienne bousculer l'idée "mystique" que les Stradivarius seraient le zénith inatteignable des violons parce que réalisés par des "grands maîtres" du passé qui connaissait probablement un "grand secret". Quant aux prix de ces instruments, ils n'ont aucune base réelle, comme la plupart des pièces de collection de toute sortes...

Ce jugement me semble très dangereux... Escroc n'est pas un mot directement insultant et en suivant cette logique, beaucoup de mots neutres en général ou ayant plusieurs sens pourraient se trouver exclus des suggestions (exemple bête : chienne... mot parfaitement légitime mais apposé au nom d'une célébrité, il devient une insulte). Le jugement me semble absurde, s'il y a des coupables d'injure c'est l'énorme quantité d'internaute qui ont publié des documents accolant le terme "escroc" au nom de cette société, pas Google.

Non que j'apprécie particulièrement Google, mais cette décision me semble abusive et met en danger la notion même de suggestion automatisée de toute sorte (qui n'est pas forcément lié, rappelons-le, à une violation de la vie privée).

Vraiment ? Et tu as une étude là-dessus ? Et puis tu parles de quels ingénieurs ? Ceux qui pissent du code médiocre en PHP pour faire marchouiller des sites webs auxquels ils manquent les 3/4 des fonctionnalités (pour pouvoir vendre les améliorations subséquentes) ou ceux qui essaient de trouver une solution à un problème de fuite d'un réacteur nucléaire à Fukushima ? Ou d'inventer une solution innovante pour diminuer la consommation d'un véhicule motorisé.

Et les auteurs pareils, il y a un monde entre les auteurs de romans à l'eau de rose qui en sortent 4 par an (parce que vu ce qu'ils sont payés ils n'ont pas le choix) en repompant comme des fous sur les classiques et les bouquins des collègues et l'auteur de "grande litérature" snob qui essaie de polir chaque phrase et de la bourrer d'allusion subtile au post-post-modernisme... (c'est pas une histoire de morale, j'ai pas forcément plus de sympathie pour l'un ou l'autre)

Franchement ton avis est bien trop généralisant et semble fondé sur une certaine méconnaissance d'au moins l'un des mondes dont tu parles.

Il y a en fait un certain nombre d'études qui laissent planer des doutes... Par contre là où il n'y a absolument aucun doute c'est sur la facilité avec laquelle des semences OGM peuvent "déborder" et "infecter" des champs voisins. Autrement dit renfermer le diable dans sa boite est extrêmement difficile, il aurait donc été logique de faire des tests longs et indépendants en environnements fermés avant d'admettre les semences à ciel ouvert.

Un grand nombre de chercheurs indépendants sur les OGMs n'étaient pour le moins pas favorable à la culture en plein champ des OGMs et on parle là de personnes qui ont consacré leur vie à développer des OGM et croient aux bénéfices qu'ils promettent.

Les méthodes de création des OGMs et les conséquences même lorsque l'insertion du gène se passe bien sont toujours mal maîtrisées, la plus élémentaire prudence a été délibérément ignorée, souvent pour de très mauvaises raisons (l'histoire des OGM aux États-Unis est très clairement lié au lobbying et à d'autres manœuvres encore plus douteuses de Monsanto). Si l'on rajoute à cela l'introduction inévitable de l'idée de "droit d'auteur" ou de brevets sur des êtres vivants...

Autrement dit Monsanto est une entreprise assez monstrueuse dont les pratiques et les objectifs sont à faire pâlir même les entreprises criminelles souvent dépeinte dans la littérature d'anticipation mais le problème des OGMs ne se limite pas à Monsanto.

Ok, pour être plus précis, C c'est bien pour certains domaines, ce que je conteste (et qui est objectivement faux) c'est l'affirmation que : "Le C n'a rien à envier aux autres langages".

Le C est un langage de bas niveau avec un système de type assez faible et peu expressif, très fragile, offrant d'innombrable occasions d'être exploité, n'offre que peu d'options pour gérer la mémoire automatiquement (pas forcément un GC mais même les capacités de C++ sont très supérieures à cet égard), sa syntaxe est restrictive et les capacités d'abstractions sont très limitées.

Néanmoins Git n'essayait pas de s'imposer dans un champ où il y avait déjà un leader fort, Subversion n'est pas un DVCS et continue à être utilisé dans bien des cas où le modèle centralisé a ses mérites. Les concurrents de Git (dont Mercurial, darcs, Bazaar...) avaient montré que les DVCS avaient d'intéressants avantage mais aucun ne s'était imposé comme Git l'a fait : le paysage des DVCS est maintenant franchement dominé par Git (je ne dis pas que les autres ont disparu) et Veracity rentre en retard sur le champ de bataille. Le choix du C et d'une approche de réimplémentation indépendante de toutes les parties de l'application ne me semble pas judicieux dans ce cadre, Veracity n'a pas une communauté derrière elle de la même ampleur que celle soutenant git.

Bien sûr ça fait penser à git et on ne peut pas dénier que git soit maintenant un énorme succès (à l'échelle des VCS en tout cas) mais il faut tout de même voir que git avait derrière lui tout le poids de Linus et bien vite d'une bonne part de la communauté de développement du noyau, bon nombre de développeurs d'exception habitués à travailler vite et bien et en C (ce qui rendait le choix du langage assez évident !). Et même git n'était pas aussi ambitieux que semble l’être ce nouveau projet.

Créer un nouveau langage de programmation n'est pas exactement la même chose que coder une nouvelle application...

Ok, et tu as essayé quelques autres langages moderne de haut-niveau (Go, OCaml, Haskell, Clojure, Scala...) ? Parce que dire que C/C++ c'est bien après avoir essayé C, C++, un peu de Java et une touche de Python, ça n'est pas des plus convaincant. C a sa place, pour écrire des bibliothèques robustes et performantes de base ; pour ce qui est d'une application complexe avec un cœur algorithmique important, communicant avec l'extérieur et une grande importance de la sûreté d'exécution, je crois que C n'est plus depuis longtemps le bon choix.

D'accord, les bibliothèques de fonctions existent en C... Mais visiblement pour ce projet il est hors de question d'utiliser des bibliothèques solides écrites à l'extérieur, il faut tout réécrire par eux-même (et bien sûr le résultat sera forcément meilleure et plus robuste, hein ?).