arnaudus a écrit 4673 commentaires

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…

Ton commentaire est tellement biaise (tiens, il n'y a pas les accents sous Windows?) et incomplete (tiens, encore?) que c'en est franchement risible. Ca (tiens, pas de Ç non plus) manque tres tres serieusement d'objectivite. (L'objectivite, c'est comme la conjonctivite?).

Dans le document, inconvénients de MS Office: prix des licences, format de fichier propriétaire avec les problèmes de compatibilité qui vont avec, problèmes de sécurité avec les macros, mises à jour peu fréquentes. Je ne vois pas où est le problème, ça me semble assez objectif (même si pour les mises à jour, le compromis entre la fréquence peut être discuté, c'est pratique de mettre à jour souvent sur un poste perso, moins en production.

Avantages OpenOffice: interface unifiée (OK, je suis d'accord, c'est moyen comme argument), Licence libre, format ouvert XML (en 2005 ça n'était pas le cas pour MS Office), export natif en PDF (à l'époque, c'était une fonctionnalité très originale), compatible avec MS Office (argument à double tranchant), moins sensible aux virus (c'est factuel, même si on peut toujours balancer l'argument de la fréquence d'utilisation, qui n'est pas démontrable tant que les PDM ne bougent pas plus), multiplateforme.

Bref, c'est une liste d'avantages/inconvénients destinés à un public d'utilisateurs qui, comme presque tout le monde, n'utilise qu'une partie négligeable des fonctionnalités d'une suite bureautique, mais je ne vois rien de particulièrement faux ou choquant.

"Ça manque d'objectivité" est l'argument parfait pour ceux qui ont de la merde dans les yeux : pas besoin d'argumenter, on sait mieux que tout le monde (argumentum ad potentiam). J'aimerais bien connaitre les arguments objectifs que MS utilise pour refourguer MS Office, histoire d'être impressionnés par l'"objectivite".

Je crois que c'est toi.

Certes, mais si c'était vaible, ça serait fait depuis longtemps. Tu vas à Carrefour et à Auchan, tu ne trouves que des machines assemblées sous Windows. Pourquoi des grands groupes comme ça n'ont pas les moyens de vendre des PC avec une distrib Linux maison, 100€ moins cher que les PC Windows? C'est quelque chose que je n'ai jamais compris, et j'imagine qu'il y a une raison, c'est juste qu'elle m'échappe. Une piste serait peut-être que les PC sont vendus à prix coûtant, et que les marges sont faites principalement sur la logithèque (10 ou 15€ pour des softs qui impriment des cartes de visite ou d'autres trucs aussi inutiles). Sous Linux, la plupart de ces trucs existent déja; et en tout cas, on n'en achèterait plus en magasin. Ça serait cynique, mais les grandes enseignes ne sont pas à ça près…

Bah, il me semble que le deal évident, c'est que si tu administres ta machine, tu assumes, et tu corriges les boulettes (et tu réinstalles ta distrib si tu as tout pété).

Le problème, c'est qu'en recherche, tu as tout le temps besoin de faire des trucs sales : récupérer un programme écrit par des chinois, le compiler, l'exécuter, le modifier, le coller sur un serveur de calcul, et tout faire péter avec une fuite mémoire, par exemple, et le tout dans une seule journée. C'est la procédure normale, et toute autre procédure va simplement arriver au même résultat, sauf que ça prendra plus longtemps.

Dans mon cas, le service info me laisse gérer mon serveur de calcul et ma machine perso, plus les machines des étudiants. Je n'ai donc qu'à administrer un seul serveur, et j'ai déja l'impression de passer pas mal de temps à installer des trucs : des libs, des python-machin, des perl-machin, le même python-machin mais pas la même version, et des milliers de paquets pour R… ça ne s'arrête jamais, et ça peut être bloquant si tu en as besoin le vendredi soir. Et encore, on a imposé que les programmes perso ou non-packagés soient exécutés dans le /home , quitte à les dupliquer entre utilisateurs, de manière à n'avoir que les paquets de la distrib en root, sans /opt ni /usr/local. Franchement, je ne vois pas comment on peut réussir à gérer un parc de plusieurs dizaines de machines en production si on ne délègue pas ce genre de trucs. La seule solution serait de dire aux utilisateurs d'arrêter de faire des trucs crades, mais dans un labo de recherche, faire des trucs crades est justement ce pour quoi les gens sont payés.

Après, ça dépend aussi de l'environnement. Autant je trouve normal dans un environnement de production de ne pas laisser les utilisateurs jouer avec les ordinateurs, autant c'est assez contraignant dans un centre de recherche. Il y a quelques années, un service informatique m'avait «menacé» de m'installer une RedHat entreprise sur mon poste, sans les droits root—politique de l'université, je ne sais pas quoi. Je leur avais répondu que je les tiendrai pour responsables de ma perte de productivité sur le temps perdu à rootkiter ma propre machine. Résultat, ils m'ont laissé installer mon Ubuntu perso (mais pas Debian, les voies du Seigneur sont toujours aussi impénétrables).

Bah, ça s'apparente à de la mauvaise gestion. Si c'était du harcèlement que de ne pas donner les droits root à tout le monde, ça se saurait :-)

Il faut quand même apprécier l'ingéniosité des assembleurs et des producteurs de logiciels pour contourner à la fois la loi et les licences existantes afin de d'atteindre de manière la plus discrète possible la liberté de leurs propres clients. Pense à tous ces noyaux linux qui tournent sur une majorité de smartphones, de tablettes, de TruxBox, tous ces beaux logiciels libres dont tu peux tout à fait récupérer les sources, mais pour lesquels tu ne peux ni vérifier que tu exécutes bien les binaires compilés à partir de ces sources, ni modifier et redistribuer… Tout ça avec la bénédiction de la répression des fraudes, et sans soulever de vagues de protestation parmi les consommateurs. Ils sont très, très forts, et leur détermination (ainsi que leur force financière) fait que, sans base législative ultra-forte, la lutte promet d'être très difficile.

Au lieu de militer contre telle ou telle technologie, ce qui est perdu d'avance étant donné l'accumulation de nouveaux projets liberticides, il serait beaucoup plus sain d'interdire purement et simplement la vente d'équipements munis de dispositifs non-contournables visant à empêcher le consommateur d'utiliser le produit comme il le souhaite.

D'un autre côté, si le problème des jeux libres n'était que l'artwork, on ne serait pas si mal. Il y a une tripotée de jeux libres qui sont instables, pas finis, bourrés de bugs, pas multiplateforme, etc. J'imagine qu'on peut ajouter à la liste des problèmes le fait que l'équipe de développement est souvent composée de gens qui ne sont pas des programmeurs professionnels, qui font des mauvais choix techniques dès le début, et qui ont du mal à gérer un projet, avec des releases, des périodes où on ne fait que corriger les bugs sans ajouter de fonctionnalités, etc.

Le problème de l'artwork reste réel, cependant. Il y a relativement peu de gens compétents dans le domaine, et encore moins désirent passer du temps sur un projet libre. Maintenant, l'ambition dévorante des gens qui lancent des jeux, l'idée de produire un jeu complet à partir de rien, est probablement irréaliste et déraisonnable, et reste à l'origine de beaucoup d'échecs. Beaucoup de jeux ont par exemple des musiques dégueulasses, alors que la musique, si elle contribue à l'ambiance du jeu, n'est pas un élément bloquant. Pourquoi ne pas réutiliser les musiques libres existantes (jeux libres, enregistrements de musique classique libres)? Ça permettrait de se concentrer sur les aspects fondammentaux, et ça serait tellement plus agréable pour les joueurs! En plus, ça permettrait de se culturer en musique classique, plutôt que de se pourrir les oreilles avec de la bouillasse.

Ah oui, B FW = Battle for Wesnoth :-)

C'est un peu facile de balancer des critiques quand on ne fait rien, mais je trouve que le paysage des jeux libres est un petit peu déprimant. À part BFW, qui est un modèle du genre, j'ai un peu l'impression que les jeux libres sont soit des mini-projets bien finis (type frozen bubble), soit des trucs ambitieux jamais fignolés. Des trucs somme "sable" par exemple sentent bon les années 1990, le jeu n'a plus de page officielle, il est mort. Des projets très intéressants, comme OpenTTD, Freeciv, Freecol, Lincity, se trainent un peu comme des limaces et ne sont soutenus que par des équipes très réduites, dont la plupart aimeraient certainement passer le flambeau et se consacrer à autre chose. Même des jeux super innovants comme globutaion semblent à l'arrêt. Est-ce que ça veut dire qu'on a atteint la limite de la "niche écologique" des jeux libres? Étant donné le nombre de joueurs dans le monde, c'est fou qu'aucun projet d'envergure avec un budget conséquent n'apparaisse.

Ce n'est pas prouvé qu'ils ont plus de chance.

Une preuve statistique est considérée comme suffisante par les scientifiques qui ont eu la chance ou l'intuition de quitter les cours de maths le plus tôt possible.

Oui, rien à voir, mais n'empêche, blanc c'est bien, et noir c'est mal. Pareil pour la magie blanche, pareil pour une explication claire ou obscure. Aux échecs, les blancs jouent en premier et ont plus de chances de gagner. À force, j'imagine qu'on peut mal le prendre si on est noir ET parano (ou qu'on broie du noir :-S).

Après, on doit pouvoir trouver quelques exemples contraires. Les mariages blancs? Mais on ne parle pas de mariages noirs. Mine de rien, les termes de "blanc" et "noir" sont connotés. J'ai souvenir de cette expérience terrible menée auprès de gamins de 5-6 ans, auxquels on donnait une série de visages qui ne différaient que par la couleur, et on leur demandait "lequel a des bonnes notes à l'école", "lequel veut devenir médecin", et les réponses étaient incroyablement racistes. On n'y peut pas grand chose, mais c'est comme ça.

L'avantage de passer par une lib telle que la STL, c'est de pouvoir utiliser tout ces algos "de base" avec des opérateurs personnalisés, ce qui est bien pratique quand on veut trier des choux-fleurs.

C'est sûr, mais (i) est-ce que ça arrive si souvent que ça de vouloir trier ou additionner des choux-fleurs, par rapport à trier ou additionner des nombres ou des chaines de caractères, et (ii) techniquement, je ne vois que peu d'exemples où on veut réellement trier des choux-fleurs selon leur chou-fleuritude : on veut les trier selon leur taille, selon leur couleur, selon tout un tas de trucs qui s'expriment par leur valeur numérique.

Après, je ne critique pas l'existence d'une STL, qui reste un outil utile dans des cas assez spécifiques. Ce que je critique, c'est le paradigme de programmation qui consiste à faire des appels non-standard à des fonctions triviales dont tout le monde a besoin, et qui elles font des appels à la bibliothèque standard.

Par exemple, M. Dupont va programmer une fonction somme(iterator, iterator) qui va appeler std::accumulate; alors que M. Smith va programmer une fonction sum(vector) qui va appeler std::accumulate. Bref, les deux ont les mêmes besoins, ils appellent les mêmes fonctions standard en arrière plan, mais leur interface n'est pas standard. Ça duplique les efforts, ça rend le code plus difficile à maintenir et à lire, les fonctions résultantes ont peut-être des bugs ou elles ne sont peut-être pas optimales. Je ne vois pas du tout l'intérêt d'intercaler les couches de trucs standard et de trucs non-standard.

Il est évident que si la bibliothèque standard possède des fonctions min() ou sum(), elles ne vont pas toujours se comporter comme le programmeur souhaiterait qu'elles se comportent. Dans ce cas, il faudra de toutes manières repasser par la STL ou équivalent, avec un commentaire du style // je veux le plus petit élément qui ne soit pas 0, alors que la fonction min() renvoie 0. Mais dans 95% des cas, ces fonctions se comporteront exactement comme il faut, et ça fera gagner un temps fou à tout le monde. Je trouve déraisonnable d'estimer qu'un programmeur sur un langage bas-niveau n'a que ça à faire que de chercher dans la littérature l'algorithme optimal pour réaliser telle ou telle tâche triviale.

Ce sont des langages système, donc de bas niveau.

C'est exactement le sens de ma remarque. D ne sera probablement jamais utilisé pour coder un système d'exploitation ou un pilote de périphérique. Si on regarde l'utilisation de C++, c'est principalement du logiciel utilisateur (bureautique, logiciels spécialisés, etc). Dans mon domaine, le C et le C++ sont utilisés principalement pour coder des modèles "maison" (simulations, etc) quand les langages haut niveau sont trop lents. Au passage, matlab est un peu déprécié en biologie, les gens préfèrent de plus en plus R.

Les langages C/C++/D ne sont pas faits pour manipuler des vecteurs (au sens mathématique)

Les vecteurs de caractères ou de chaines de caractères n'a aucun sens mathématique, et pourtant, ils sont manipulés par le langage.

Le problème, à mon avis, ne vient pas vraiment du "niveau" du langage, mais du présupposé sur l'utilisation qui en est faite. Un langage bien foutu devrait pouvoir être utilisé par tout type d'utilisateur, et ce n'est pas le cas, ni pour C, ni pour D. Quelqu'un qui veut faire des choses très simples ne devrait pas avoir à récupérer un char** en argument du main() (en gros, on devrait pouvoir utiliser le langage sans pointeurs), et la librairie standard devrait permettre tout un tas d'opérations de base sans avoir à les recoder soi-même : min(), max(), sum(), mean(), il me semble un peu ridicule de passer par une STL (ou équivalent) pour des opérations aussi triviales.