arnaudus a écrit 5237 commentaires

Eh bien, je ne savais pas que savoir programmer rendait expert en voitures ou en machines à laver.

Relis mon argument : dans quelques années, tous ces outils seront programmables.

Tu as beau répéter plusieurs fois la même chose, ça ne le rend pas vrai. Il n'y a pas besoin de traduire "if (k==3) Faire_ci() then Faire_ca();". Ce n'est pas de l'anglais. Ce n'est pas un langage naturel, c'est une suite de symboles qui n'ont une signification que dans un contexte précis (langage de programmation particulier). Il y a tout un tas de mot-clés qui n'ont pas le même sens selon les langages (template, and, or, foreach…), et la maitrise de l'anglais ne peut pas aider à programmer à partir de la leçon n°2.

Et puis zut, if, while et repeat, c'est quand même de l'anglais niveau primaire, il ne faut pas abuser. Tant qu'on y est, tu peux aussi critiquer les nombres en notation scientifique, la définition des constantes pi ou e, etc, qui nécessitent aussi des connaissances. Franchement, quand tu es capable d'apprendre la logique de la programmation objet, tu peux quand même te farcir 5 mot-clés dans la langue de communication internationale.

En tout cas, personne ne code "dans sa langue". Si tu veux critiquer quelque chose, critique l'utilisation de paradigmes occidentaux (nombres, dates, ascii), pas la langue des mot-clés…

L'ignorance des consommateurs est la raison majeure pour laquelle les produits qu'on achète sont fermés, obsolètes rapidement, et liberticides : ils ne voient pas l'intérêt de les modifier ou de les bricoler. L'incompétence informatique est à l'origine de milliards d'euros de coûts de tous genres tous les ans : spam, virus, problèmes de sécurité. Je n'arrive pas à imaginer comment tu peux ne pas imaginer l'avantage d'une société cultivée informatiquement : Hadopi, les brevets logiciels, les machines à voter, la vente liée, les problèmes de sécurité dûs aux données sensibles dispersées dans "le cloud", les logiciels propriétaires incontournables, les spécifications matérielles fermées, tous ces problèmes qui nous pourrissent la vie au quotidien et qui menacent sérieusement la liberté des prochaines générations sont dues à une très grande part à l'ignorance et à l'incompétence des consommateurs et des citoyens. Et toi, tu ne vois pas l'avantage pour la société de comprendre comment fonctionnnent les outils qu'ils utilisent au quotidien et à qui ils confient leurs données, leur vie privée, et de plus en plus leur vie tout court?

Apprendre à programmer un ordinateur dans un monde où, de manière prévisible, les frigos, les voitures, les maisons et les aspirateurs seront des ordinateurs, ne me semblent pas vraiment insensé. C'est avant tout quelque chose qui ne peut qu'améliorer le bien être de la société, pouvoir maitriser les outils qui nous entourent est indispensable à la nouvelle génération.

Le fait que ça puisse aider à trouver du boulot par la suite est un argument de politicien, si c'est vrai, tant mieux, mais c'est ridicule de ne pas voir les avantages pour le citoyen et la société d'une telle politique parce qu'elle est présentée de manière astucieuse.

Le petit estonien se fout complètement de la susceptibilité nationaliste de la génération de dinosaures qui prend des décisions pour lui. Le petit estonien apprend que "if" symbolise le test conditionnel, et que "or" est un "ou" inclusif, ce qui est au passage beaucoup moins trompeur que d'utiliser des notions approximatives existantes dans sa langue.

Je pense que l'idée d'exprimer un programme à l'aide d'une langue naturelle est vouée à l'échec : 1) une langue contient beaucoup trop de subtilités, et 2) beaucoup trop de choses sont implicites dans la communication entre êtres humains. Je pense que c'est à l'origine de beaucoup d'incompréhensions, les gens pensent qu'ils peuvent communiquer avec un ordinateur comme avec un être humain, et ils sont malheureusement encouragés à faire ça par des développeurs et des marketteux débiles qui considèrent que c'est un objectif. Actuellement, un ordinateur se programme grâce à des instructions mathématiques rédigées dans un langage non-ambigü, pas avec des mots. Ce message passerait beaucoup mieux, à mon avis, si on omettait dès le départ la possibilité d'utiliser une langue humaine.

… mais il est d'usage ici de ne pas répondre aux questions contenant le mot "Urgent" (netiquette de base). La même question sans le "urgent", et précisant en quoi les réponses fournies par Google ne sont pas satisfaisantes devrait pouvoir attirer beaucoup plus de réponses constructives.

Une reprise ou une inspiration n'est pas pareil qu'un clone. L'objectif de beaucoup de jeux libres est de cloner un jeu propriétaire afin d'y jouer gratuitement et sous linux. Il est évident qu'il n'existe pas vraiment de plus-value associée à ce type de projet…

L'ADN (en solution aqueuse) se présente la plupart du temps sous forme de double hélice constituée de deux brins complémentaires entrelacés. Les deux brins contiennent exactement la même information, l'un en positif, l'autre en négatif. L'unité d'information est donc la «paire de bases», une paire de bases étant constituée d'un nucléotide (monomère d'ADN) et de son complémentaire sur l'autre brin. C'est cette complémentarité qui permet la réplication fidèle de l'ADN : on sépare la double hélice en deux parties, et chaque partie garde la totalité de l'information (un peu comme si on avait deux disques durs, l'un étant l'image de l'autre avec tous les bits inversés: on prend n'importe quel disque, on le met dans un autre PC et on le resynchronise avec un autre disque vierge).

D'ailleurs, en toute logique, on devrait dire «paire de nucléotides» et pas «paire de bases». Un nucléotide est constitué d'un phosphate (qui assure la liaison des nucléotides entre eux quand l'ADN est polymérisé), d'un sucre (le désoxyribose), et d'une base azotée (la partie variable du nucléotide). Le tout reste une sorte de gros Lego constitué de briques assemblées les unes aux autres.

Ça serait totalement inutile, il faut beaucoup moins d'information que ça pour donner un sens de lecture. La réponse est au dessus, ils se servent de la redondance pour maintenir une structure de l'ADN compatible avec la lecture et la copie sans trop d'erreurs. Ça reste tout de même très sous-optimal.

Pour la lecture, on peut le calculer. Les tout derniers séquenceurs peuvent se faire un génome humain (3 Gbp) en une journée, ce qui fait du 35 kbp/s. Ça progresse plus vite que la loi de Moore, dans quelques années, ça sera probablement instantané.

Pour la copie, la DNA polymérase fait du 50 bp/s à 1000 bp/s, mais bien sûr on va stocker sur plusieurs molécules d'ADN, un peu comme si on parallélisait (au final, la copie est beaucoup plus rapide que la lecture). La vitesse dépend de la polymérase, c'est un compromis vitesse / fidélité.

L'«écriture» est beaucoup plus compliquée. J'imagine que c'est l'étape bloquante du système.

Mouaip, mais c'est un chouilla plus compliqué quand même. Tu as de nombreuses structures à éviter :
* Les régions trop riches en A/T ou en G/C. Il faut donc, sur une fenêtre glissante de taille donnée, maintenir un ratio (A+T)/(A+T+G+C) dans une fourchette acceptable, probablement entre 30 et 70%, quelque chose comme ça.
* Les séquences répétées, qui sont mutagènes: AAAAAAA, AGAGAGAGAGAG, ATTATTATTATT, par exemple, auront beaucoup plus d'erreurs lors de la copie.
* Les palindromes, qui forment des structures secondaires (par exemple, ACTAGTXX..XXACTAGT peut facilement destabiliser la double hélice d'ADN)
Du coup, en général, aucune séquence n'est parfaite. Pour une séquence donnée, tu peux calculer une sorte de score avec un algorithme heuristique, et j'imagine que l'objectif serait de compresser au maximum l'information tout en gardant une lisibilité acceptable.

Ceci dit, je reste convaincu que la compression de 200% décrite dans l'article est largement sous-optimale—ce n'était pas le but de la manip. J'imagine même qu'il y aurait moyen de réaliser en même temps la compression (informatique) des données numériques et l'optimisation de la séquence, plutôt que de zipper d'abord puis de bricoler la suite binaire pour minimiser le nombre de nucléotides requis.

OK, j'aurais dû lire l'article. Ils ont donc choisi de rendre l'information redondante pour améliorer la fiabilité.

Le truc, c'est qu'évidemment chaque nucléotide contient bien deux bits d'information, mais que pour des raisons pragmatiques, ils préfèrent n'en coder qu'un. Cependant, si leur méthode pouvait trouver de vraies applications, il sera tout à fait possible de mieux compresser tout en préservant la fiabilité de la lecture et de l'écriture, par exemple en compressant sur des mots de 4 ou 6 nucléotides, voire plus.

Lorsque les deux brins sont ensembles, A est toujours associé à T et C à G : logiquement, A et T codent donc pour la même information.

Non, c'est faux. Je veux dire que A et T sont toujours associés, mais on ne lit qu'un seul des deux brins. Par conséquent, des séquences comme TTA et ATT sont différentes, et un nucléotide contient bien 2 bits d'information.

Et pour résumer : c'est cher, pas pratique à lire/écrire (le 0 binaire doit être codé en A ou C, comme on veut, et le 1 binaire en G ou T), mais a un taux de d'erreur de 2 par million de bits.

Pas très performant : mieux vaut coder 2 bits par nucléotide (A=00, C=01, T=10, G=11), on en stocke deux fois plus.

Eh eh, ma manière de lire cette courbe, c'est "plus le temps passe et plus il y a de bugs dans les nouvelles versions" :-)

Le rasoir d'Occam promeut la simplicité dans la conception et le développement des théories (philosophiques, physiques, ce que tu veux).

La simplicité et la parcimonie sont deux notions distinctes. Ce qui est simple n'est pas nécessairement parcimonieux, et vice-versa. D'où ma remarque : ça n'a pas grand à voir.

Le KISS s'applique au départ au développement, pas à l'interface utilisateur, comme tu le supposes avec l'exemple de ton volant. Cf Arch.

Je ne vois pas pourquoi le KISS s'appliquerait au développement en priorité, il s'applique au design en général (Wikipédia mentionne la naissance du concept dans le domaine de l'aviation). Mais justement, je suis d'accord avec ton exemple, c'était exactement mon objectif avec l'exemple du volant de voiture : il est tout à fait légitime de privilégier l'ergonomie à la simplicité, et donc de rejeter le principe du KISS.

De toutes manières, à mon avis, personne ne fait exprès d'obfusquer quelque chose. Les choses deviennent complexes parce qu'elles sont construites sur l'existant, parce qu'on a essayé de faire simple sans y arriver, parce que ce qui parait simple pour quelqu'un ne l'est pas pour quelqu'un d'autre, ou simplement parce qu'un algo efficace n'est pas forcément simple. C'est bien beau de gueuler KISS!, mais qu'est-ce que c'est qu'un code simple? Est-ce que function DoThis(); function DoThat() est plus simple que function Do(doThis = TRUE) ? Est-ce que déporter tous les algos dans des fonctions bien cachées dans internal.cpp pour ne garder que la structure du programme quand on lit le code est plus simple que de programmer gentiment en explicitant les instructions?

Je maintiens : ça n'a rien à voir. Mon commentaire était peut-être succinct, mais le KISS est un principe de minimalisme (appliqué à la conception d'artefacts), alors que le rasoir d'Occam est un principe de parcimonie (adapté à la conception de modèles explicatifs). Le rasoir d'Occam est un axiome de la logique scientifique, il ne peut pas être remis en cause. Le KISS est un concept de design vaguement fumeux, qui utilise la notion de "simplicité" sans vraiment la définir, et il peut évidemment être remis en cause—c'est un choix, une convention de développement.

Le seul point commun entre les deux repose sur l'idée qu'un système simple est plus élégant et plus facile à manipuler (en gros, ça exclut certains concepts artistiques), mais ça s'arrête là. L'assimilation du KISS avec le rasoir d'Occam est trompeuse, car elle pourrait faire croire que, par exemple, les choix de développement de Gnome sont plus rationnels que ceux de KDE, ce qui est profondément stupide.

En particulier, on peut très bien défendre le point de vue que l'ergonomie d'un artefact se doit d'être intuitive, et pas simple. Parfois, une interface simple est intuitive, mais souvent, elle ne l'est pas. Un bon exemple est celui du volant pour diriger un véhicule. Étonamment, c'est assez intuitif de tourner le volant pour tourner les roues, mais le dispositif mécanique sous-jacent est terriblement complexe, et nécessite de transformer un mouvement circulaire en mouvement linéaire grâce à une crémaillère. Clairement, ce n'est pas KISS du tout. Un autre exemple, plus près de l'informatique, est la pratique assez étrange d'allumer un ordinateur grâce à un interrupteur, et de l'éteindre de manière purement "informatique". Ça a l'air assez intuitif pourtant, même les grand-mères trouvent "normal" de ne pas utiliser le même bouton pour allumer et éteindre un ordinateur, mais là encore, ça n'est pas KISS : le principe du KISS demanderait qu'il y ait une unique interface, et que la seule manière d'éteindre un ordinateur serait d'appuyer sur le même interrupteur que pour l'allumer.

Le rasoir d'Occam consiste à préférer une explication simple à une explication complexe. Par exemple, je clique sur "éteindre mon ordinateur", et l'ordinateur s'éteint. On peut se demander si mon action a entrainé l'extinction de l'ordinateur, ou s'il s'est éteint parce qu'il y a eu une panne d'électricité au même moment. Si je n'ai pas moyen de répliquer l'expérience, le rasoir d'Occam impose de choisir la première solution, qui ne fait pas intervenir de cause extérieure (la panne d'électricité). La rasoir est un critère de décision, il ne précise rien quant au design d'une interface.

D'ailleurs, il y a des cas où le KISS et le rasoir d'Occam sont en contradiction dans la construction d'un modèle. Par exemple, un pot de fleur tombe de ma fenêtre, et 2 secondes plus tard, je l'entends se briser par terre. À la question "à quelle distance du sol le pot était-il 1 seconde après le début de sa chute", le KISS et le rasoir d'Occam imposent deux résultats différents. Le KISS impose un modèle simple, probablement un modèle linéaire. Occam impose un modèle avec le moins de causes possibles, typiquement, un modèle d'accélération constante sans frottement. On voit bien que la diminution du nombre de causes ne mène pas nécessairement à un modèle plus simple.

Voir aussi : rien à voir.

Quand l'humour est tellement puissant que personne ne le comprend, ça s'appelle «un bide». Ici, c'est un peu trop bien fait : pas de ponctuation, pas de majuscules, pas de culture, pas de réflexion ; on est un peu trop dans le kikoolol, c'est un peu trop caricatural. Sans compter que je pense que même le plus profond des neuneus sait plus ou moins ce qu'est la TVA, donc la blague n'est pas très crédible…

Je pense que c'est déja ce qu'il fait. Je pense qu'il veut un truc pour afficher le tarif en temps réel, pour que le client sache à chaque instant à combien il en est.

Et voila, ça a l'air d'être un bug "chaud" avec plusieurs duplicats: https://bugs.kde.org/show_bug.cgi?id=295212. Et, surprise, c'est un bug KDE. LibreOffice n'y est pour rien, apparemment. Mais en tout cas, il s'en est pris plein la tronche dans ce journal, le monde est injuste.

Je viens d'enregistrer et de rouvrir un fichier testœøÀΔ.odt avec LibreOffice 3.5.3 sur mon Ubuntu. Donc, la description du problème est fausse, et tu ne donnes pas d'exemple reproductible. Je suppute qu'il y a un gros bug dans l'interface chaise-clavier.

Dans tous les cas, ça me semble absurde de changer de logiciel parce qu'il ne sait pas ouvrir un fichier avec des caractères spéciaux. Il suffit de renommer le fichier, voire de faire un lien symbolique, ce qui permet de gérer le problème de manière totalement transparente. À mon avis, ce que tu fais s'apparente à envoyer ta voiture à la casse parce que tu as toi-même monté les essuie-glaces à l'envers.

Sur le fond, oui, je sais, les pauvres chinois, ils ont le droit de mettre des caractères cabalistiques dans leurs noms de fichier. Les chinois ils font ce qu'ils veulent, mais personnellement je ne mets jamais de caractères non-ASCII dans les noms de fichier : ça n'a aucun intérêt, il serait stupide d'avoir des noms de fichiers qui ne diffèrent que par un accent ou un espace insécable, etc. Donc, quelque part, même si c'est un bug, c'est un bug généré par une demande (à mon avis) non-pertinente de l'utilisateur. Après, si le système l'autorise, alors ça doit marcher, j'avoue.

Oui, j'ajouterai même que R est devenu un véritable langage de programmation; on peut carrément exécuter des scripts en #!/usr/bin/env Rscript , il y a un générateur de bytecode pour les fonctions les plus gourmandes à interpréter, et de quoi jouer avec la programmation parallèle. On peu ajouter la capacité native à générer des graphes de très haute qualité directement dans le format souhaité (bitmap ou pdf), et 4000 paquets contribués. R est devenu incontournable en biologie, et je pense que ce n'est pas près de retomber (en 2012, R se classe 28e dans le classement des langages populaires, devant COBOL, Eiffel, D et Erlang…).

En plus, le langage S est assez esthétique et élégant, en plus d'être très concis. Je pense que c'est un excellent outil pour l'apprentissage de la programmation.

R n'a rien à voir avec un tableur, je doute que la comparaison ait un sens.

"pas compatible avec OOo" est mentionne comme inconvenient d'Office et "compatible avec Office" est mentionne comme avantage d'OpenOffice, bref une contradiction totale

Je ne vois pas où est la contradiction. OOo sait lire et produire (pas parfaitement) les documents MS Office, alors que MSO ne sait lire et produire que ses propres documents, et pas ceux générés par OOo. Ça me semble être limpide, question logique…