Philippe F a écrit 2225 commentaires

Je trouve ton attitude un peu violente vis à vis des utilisateurs.

C'est plutôt sympa de continuer à faire évoluer l'ancien logiciel, c'est souvent d'ailleurs comme ça que se passe le relai entre deux logiciels avec un nouveau développeur.

Perso, je rajouterai un dialogue bien visible au lancement du logiciel ou à l'utilisation qui dit que c'est la dernière mise à jour pour SuperCopier et que pour des corrections de bug et plus fonctionnel, il y a aussi UltraCopier.

Comme ça, les utilisateurs sont informés, ils sont pas pris en otage et en même temps tu proposes une version plus fonctionnelle de façon non forcée.

Yep.

Réveil plutôt agréable pour moi et ça m'évite plus ou moins de réveiller ma compagne (bien que ça lui grille les yeux assez vite si je coupe pas très vite).

Par contre, je suis très sensible à la lumière pour me réveiller. Je dors avec un masque de sommeil (qui laisse passer un peu de jour) et pourtant, sur un cycle de lumière croissante de 15 minute, je suis réveillé dès la 2e ou 3e minute.

En tout cas, je trouve ça moins stressant que les bip bip et moins déprimant que la radio !

Et moi j'ai un réveil qui marche à l'eau. Faut juste mettre de l'eau dedans tous les 15 jours - 3 semaines. Et il se règle manuellement, donc attention quand même…

Avec ces arguements là, tu peux déposer une gerbe sur la totalité des opérateurs en France. De ce qu'il me semble aucun n'a jamais respecté la totalité des engagements qu'ils avaient pris auprès de l'ARCEP. Retard de couverture 3G de la population, ca te dit quelque choes ?

Tu peux même rajouter :
5. Distributions du profit aux actionnaires.

Ca peut servir quand tu es en dual boot windows / linux et que tu n'utilises pas le même client mail des deux côtés. Ou bien si tu accèdes à tes mails par ssh de temps en temps, et par thunderbird de temps à autre aussi.

Ca semble exotique dit comme ça, mais à une lointaine époque, mélanger kmail et mutt ne posait aucun problème.

Sauf que c'est très très loin d'un vrai support de Maildir. Ca résoud un problème, certes, on a des petits fichiers au lieu d'un gros paté de mbox.

Par contre, pour ce qui est de:
* compatibilité du format avec d'autres clients mail: nada
* partage du répertoire maildir aved d'autres clients mails: nada. Le stockage actuel est en fait personnel à Thunderbird. Si un fichier change sans que thunderbird ai déclenché le changement, il doit tout reparser pour mettre ses index à jour.

Bref, le support maildir, on l'aura sous Hurd.

Quand on voit le niveau d'activité, on peut en douter… Certes, il est pas mort, il bouge encore quand tu lui donnes un coup de pied. Mais guère plus.

On avait pas entendu un discours comme quoi la "communauté" allait reprendre tout ça en main ?

Attention en anglais, crime se traduit par délit. Il propose de punir Ubuntu pour ses délits, ça fait déjà moins grave.

ses prises de position sont toujours claires et justifiées.

Justifiées, dans une vision extrèmement étroite du monde. Défendre Gnome comme desktop depuis des années, je trouve que c'est une position difficile à justiifier pour RMS.

Sans être indiscret, tu arrives à générer un peu de revenu avec les dons / achats ?

Et quid de la liberté offerte par la licence BSD qui est pourtant aussi une brique fondamentale de l'écosystème du logiciel libre aussi ? Cette licence est non-libre du point de vue FSF.

On retrouve bien le manichéisme réducteur de M. Stallman pour lequel rien n'existe en dehors de son petit monde étriqué mais doté des 4 libertés fondamentales.

Si tu compares avec le travail de Creative Commons, l'approche est bien plus ouverte. On codifie les libertés qu'on peut donner ou pas à l'utilisateur, on explique les tenants et les aboutissants, on documente le tout sous un format facile à utiliser, référencer et expliquer. Et on a pas l'impression qu'on ira mourrir en enfer, si on a pas choisi la bonne licence. Voilà un travail ouvert qui sert l'écosystème du libre sans la logique de culpabilisation (typique des religions d'ailleurs).

Le travail de la FSF/RMS s'est arrêté à l'écriture des licences GPL, de Emacs et de GCC. Ce sont des contributions historiques très utiles, mais bon, où est la suite ? C'est bien de poser une brique de base dans les années 70, c'est mieux de continuer à évoluer. Cette institution a bien la place qu'elle mérite et c'est pas en pleurant sur l'utilisation du terme GNU (au mépris des autres logiciels non GNU d'une distribution linux) que ça va s'améliorer.

Sourceforge a fait bien plus pour le développement du logiciel libre, il a proposé des solutions et des moyens à des développeurs. Aujourd'hui c'est plus Github qui tient ce rôle fondamental.

Linus aussi, en plus de linux. Il trouvait que les gestionnaires de versions étaient minables, il s'est sorti le doigts du c** et nous a montré ce qu'était un gestionnaire de version potable selon lui. Voilà une avancée pour le logiciel libre.

On pourrait parler de Wikipedia aussi. Voilà une façon concrète de matérialiser les valeurs qui nous sont chères et la coopération internationale décentralisée sur quelque chose qui change le monde AUJOURD'HUI.

Pour résumé mon opinion, RMS et la FSF, aujourd'hui, c'est des pleurnichards passéistes et je préfère nettement les gens qui vivent (intelligemment) avec leur temps et qui réalisent des choses au lieu de pleurnicher.

Je pourrais en écrire 5 pages tellement il y a de choses à dire sur cette petite institution et ce petit personnage de RMS. Et je dis ça, je le respecte, j'avais même pris le thé avec lui à un salon Linux.

Là où on commence à s'amuser, c'est lorsqu'une fonction peut prendre en argument une fonction, et retourner une autre fonction.

Je ne connais pas la syntaxe Ada mais en Python, ça donnerait:

def compose(f, g):
    def h(v):
        return g(f(v))
    return h

Là, on est vraiment dans la programmation fonctionnelle déjà un peu plus avancée. Si tu rajoutes à ça la mémorisation de l'environnement de la fonction, tu obtiens les fameuses closures :

def call_and_add(f,delta):
    def h(v):
        return f(v)+delta
    return h

Il parait que c'est super pratique et les développeurs ruby en sont des grands fans.

J'imagine mal faire ça avec des pointeurs de fonction mais c'est sûrement possible avec beaucoup plus de lourdeur.

Je ne connais pas suffisamment Ada pour avoir un avis informé, mais visiblement, les ajouts permettent de traiter plein de "patterns" de programmation en une ligne, à coup de fonctions et d'expressions.

Pour moi, c'est clairement une diffusion lente vers les autres langages (python, ruby, Ada, …) de certaines pratiques de la programmation fonctionnelle. On est plus dans le strict procédural, 1) je teste, 2) je compare mon résultat, 3) j'agis, mais bien dans l'évaluation d'une expression par application d'une fonction, avec des possibilités plus étendues sur les fonctions qu'on peut mettre dans ces expressions.

D'ailleurs, est-ce que les fonctions sont des objets primaires en Ada ?

Tiens, je note que dans Ada, on rajoute quelques constructions inspirées par la programmation fonctionnelle. On a vu arriver la même chose dans python ces dernières années, et il me semble aussi dans les langages à la mode (Ruby, …) .

Serait-ce l'avènement si longtemps attendu que bientôt toute programmation sera fonctionnelle ?

En tout cas, j'imagine que ça fait bien rire les puristes de la programmation fonctionnelle par ailleurs, pour qui un Febdays: constant := (if Leap then 29 else 28); doit être le niveau 0 du fonctionnel.

Surtout que dans sa forme actuelle, le wikitext associe déjà le fond et le forme !

Est-ce que c'est pas aussi plus ou moins l'approche de NumPy ?

Ce qui est sérieux, c'est de signer un contrat avec un banquier pour pouvoir fait ce que fait weboob "à la mano".

Construire une société avec une source de revenu sur un flou légal, ça me semble à moi clairement pas sérieux.

Tu fais quand même preuve d'une certaine naïveté. Ton service peut se faire tuer à tout moment avec un petit procès.

Dire "il y en a d'autres qui le font donc c'est surement légal", c'est pas très solide pour construire une société dessus. Qui te dit que tes concurrents n'ont pas un accord qui rémunère la banque pour l'utilisation de son service ?

Ca fait longtemps qu'on a pas eu un bon troll Gnome-KDE-Freedesktop-GPL !

C'est dommage que Freedesktop soit devenu ce qu'il est. Quand le projet a été lancé, la volonté de coopération était là des deux côtés et tout le monde a apprécié le projet en général (avant les icônes, c'est la spec des menus et raccourcis d'applications qui a été partagée, sur la base d'un format proposé par KDE).

Ce qui aurait du être fait à l'époque, c'est de formaliser les objectifs du projet dans sa gouvernance. Il devrait y avoir une sorte de comité Freedesktop, avec des représentants de chaque projet, et un processus de validation d'une spec par ce comité. Cela a été discuté, mais bien trop tard et n'a jamais été mis en application.

Au lieu de cela, le projet est resté Gnome centric au niveau des administrateurs et de sa gouvernance. C'est à dire que Gnome peut pousser à peu près n'importe quelle technologie ou spécification et la voir acceptée comme projet Freedesktop. Des projets complètements immatures ont aussi été acceptés, dans une logique d'expérimentation (ce qui est bien) mais les règles d'acceptation et la distinction expérimental ou spec officielle sont floues. Et de nombreux projets KDE ont été refusés avec des critères discutables.

Le plus pathétique est arrivé avec ces projets où certains développeurs Gnome se contentent de labelliser une techno dans leur coin en la déclarant spécification Freedesktop sans se préoccuper une seconde de l'interopérabilité.

On a aussi l'évolution de Gnome, qui se revendique aujourd'hui comme une expérience utilisateur en soi, et recherche beaucoup moins l'interopérabilité ou la coopération. On croirait que leur modèle est devenu Apple !

Allez, je t'aide, ça remonte à ma jeunesse: SimpleKDE . Le projet qui prétendait simplifier KDE, menés par trois puceaux, du temps de quoi KDE 3 il me semble bien. Ou peut-être même KDE 2.

J'en ai pas d'autres en tête mais des gens qui croient que en quelques soirées, on peut forker un logiciel et faire mieux, il y en a des centaines.

Je ne voulais offenser personne encore moins cracher sur un travail.

Je te crois, mais réellement, le choix de l'adjectif "propre" est tendancieux.

Non, c'est plus un mélange de logique qui me titille la rétine

Il y a peut-être un travail de désapprentissage de la programmation OOP à mener. Lis la dépêche récente sur John Carmack et la programmation fonctionelle. Il y a des liens intéressant sur l'approche fonctionelle dans différents langages, y compris Python.

Pas d'interface générique sur des trucs qui ne le méritent pas, mais par contre, j'encourage les interfaces simplifiées pour favoriser le découplage.

C'est quand même un compromis à trouver, la difficulté c'est de le faire tout seul

Ca, c'est clair. L'expérience aide beaucoup. L'humilité aussi (je me suis planté, je reprends tout à zéro). Et le fait de se planter un certain nombre de fois est probablement le plus instructif.

De toute façon très clairement, pour savoir si tu as réussi ton découplage, il y a que le temps qui te le dira: le jour où tu dois faire une modif quelconque, le temps qu'il faudra pour l'appliquer, le nombre de méthodes, objets et fichiers touchés te diront si ton découplage était bien.

Voire même, tu n'avais prévu aucun découplage et c'était bien parce que à l'époque personne n'en avait besoin, ça aurait été une perte de temps de le faire et même si tu avais essayé, tu n'aurais jamais trouvé le bon niveau de découplage par rapport au besoin futur.

En ce sens, l'approche SCRUM / Extrem Programming sont intéressantes : le code est prêt au changement. Etre prêt au changement, ce n'est pas coller des interfaces qui abstraient tout et n'importe quoi, ça c'est juste être prêt à un changement très précis dans le code. Etre prêt à n'importe quel changement, c'est avoir plus ou moins les 4 points que je décris (et je prétends pas être exhaustif).

Ce qui me gène profondément dans ton journal, c'est cette notion de "propre". D'une part, c'est un adjectif qui sous-entend que l'opposé serait "sale", ce qui pour quelque chose de virtuel est impossible. D'autre part, c'est un mot qui n'a aucune définition pour du code.

Je suppose que tu veux dire propre = respectant un certain nombre de principes de qualités. Mais tu ne cites pas les principes, on est donc largement dans du subjectif.

Passons un peu dans de l'objectif. Déjà, utilisons des mots sans connotation péjorative, c'est toujours désagréable pour un auteur de voir son travail insulté, d'autant plus quand c'est pas argumentée.

Quelles sont les attributs d'un code logiciel ? Ce qui me vient pour mon code et celui de mon équipe :

1) Lisible: c'est un peu abstrait, mais ça découle des principes suivants:
* règle de nommage cohérent dans toute la base de code
* le nom des fonctions dit ce qu'elles font
* le nom des arguments disent à quoi ils font référence
* des fonctions qui manipulent des arguments de même type utilisent le même nom
* les fonctions/méthodes sont relativement courtes

2) Documenté
* les arguments des fonctions sont expliqués
* les exceptions qui peuvent être générées dans les cas courant sont expliquées
* les valeur de retour standard et exceptionnelles sont expliquées
* le top, c'est quand il y a un exemple
* le tout en étant raisonnable, 10 lignes de doc pour une fonction de 1 ligne, c'est débile.

3) Maintenable
* ça découle des principes sus-cités en partie
* une chose ne doit être faite qu'une seule fois à un seul endroit pour des modifications faciles de comportement
* des abstractions sont construites au bons endroits pour des services rendus (mais cette partie-là est subjective et pas facile à expliquer)
* code livré avec des tests unitaires

4) Testable: on entre dans la zone du code de très bonne qualité
* jeu complet de test unitaire sur tout le code
* jeu complet de tests fonctionnels sur tout le produit
* les tests sont exécutables avec un seul exécutable bien nommé
* les tests ont eux-mêmes les attributs du code de qualité

Je n'ai pas mis que le code devait respecter les canons de la conception objet, car réellement, je ne pense pas du tout que ce soit indispensable. J'aime bien le style fonctionnel qui justement est à l'opposé de l'OOP académique. Et beaucoup de constructions OOP académiques se remplacent en une ligne de Python tellement ce langage est flexible [1].

Je vais plutôt au niveau de mon équipe insister sur le concept de "Loose coupling", couplage léger entre les composants, permettant de faire facilement évoluer un composant indépendamment des autres. Si l'objet répond à cette problématique, très bien. Si le fonctionnel répond mieux, je prend aussi. Si un mixte des deux fonctionne, je prend aussi.

Je suis très attaché aussi au KISS. Pas d'interface générique sur des trucs qui ne le méritent pas, mais par contre, j'encourage les interfaces simplifiées pour favoriser le découplage.

Pour en revenir à ton sujet, ce qui me choque, c'est qu'on a l'impression que "propre", pour toi, correspond uniquement au respect d'un canon de la Programmation Orienté Objet. J'en conclus que du code qui respecte tous les principes plus haut mais pas l'OOP serait pour toi non "propre" ?

Je t'invite réellement, d'une part à ne pas juger le code des gens avec des adjectifs péjoratifs et subjectifs.

Il m'est arrivé comme tout le monde de travailler sur du code externe et d'avoir des reproches à lui faire. Mais contrairement à toi, je vais parler de code inutilisable pour notre projet, inexploitable, difficile à comprendre, difficile à faire évoluer.

Bref, je ne porte pas de jugement de valeur sur la personne, surtout dans un forum public.

Note [1]: pire, certaines constructions académiques comme le Singleton vont à l'opposé du code de bonne qualité, car rendent les choses non-testables.

Il y a plein d'entreprises, et plein de cas différents :

Les entreprises qui utilisent sans vergogne du code GPL et qui vont hurler si tu leur dis qu'ils violent une licence quelconque et qui globalement, ne contribueront ni ne respecteront la licence.

Les entreprises qui comprennent le modèle, utilisent du code BSD ou LPGL par exemple en connaissance de cause, font des correctifs mais ne reversent rien.

Les entreprises qui comprennent le modèle et sont OK pour participer à condition qu'on ne leur impose pas la GPL.

Je me permets de supposer que les "vraiment bons" l'étaient déjà avant. Que doivent-ils réellement à l'Epitech ?

De tous les stagiaires que j'ai eu, les epitech sont les plus ingérables en terme d'avancement de projet. Ils pondent du code au kilomètre, ne regardent pas les problématiques de lisibilité du code, simplicité de la solution, robustesse des choix, intégration dans la solution globale de l'entreprise, prise en compte des besoins particuliers de la solution, etc etc.

Ils avancent vite, c'est sur, ils te livrent un truc, c'est sur, mais ils oublient de poser plein de questions et font beaucoup trop de choix arbitraires, du coup leur truc est plutôt dans la catégorie inutilisable.

Au final, un stagiaire qui avance plus lentement et se préoccupe plus de son environnement me convient mieux qu'un gros bourrin de codage (désolé, y a pas d'autre mot). Expérience répétée sur plusieurs stagiaires, avec qualité décroissante au fur à mesure des années.

Quand je suis devant le rayon dentifrice et que je ne trouve pas celui que je prends d'habitude, j'en prends un au pif

Tu présupposes que les autres être humains font comme toi d'une part, et sont satisfaits avec cette façon de faire des fabricants de dentifrice (je noye le client sous l'information).

Je vais t'en apprendre une bonne: les êtres humains sont différents et tous ne réagissent pas de la même façon face à un choix.

Certaines personnes gèrent les choix indécidables sans soucis, chez d'autres, un choix va provoquer une angoisse: suis-je en train de faire le bon choix ? Ou surtout, est-ce que je ne suis pas en train de faire le mauvais choix ?

Parmi tous ces dentifrices, certains lavent bien les dents et donnent une haleine fraiche, alors que d'autres sont de mauvaises qualité. Comme distinguer le bon grain de l'ivraie ? Je n'ai pas envie d'avoir une mauvaise haleine parce que je n'ai pas du faire le bon choix. D'autre part, certains sont recommandés en cas de gencives fragiles, et d'autres en cas de grande sensibilité au froid. Mais donnent-ils une haleine bien fraiche ? Et si je suis à la fois sensible au froid et avec les gencives fragiles, comment faire ? Et avec tout ces trucs chimiques, vaudrait-il pas mieux se tourner vers les dentifrices bio et écolo ? Mais valent-ils vraiment les dentifrices chimiques en terme d'haleine fraiche ? Il aurait fallu me renseigner avant mais maintenant, je suis devant le rayon, c'est trop tard. Je dois me laver les dents ce soir et de mon choix dépendra mon haleine de demain … et la rencontre avec la femme de ma vie dans le métro, que je risque de rater à cause d'un p***** de mauvais choix de dentifrice !!!

Pour une personne comme je viens de la décrire, la bonne solution, c'est pas toujours zéro choix, c'est plutôt un choix simple entre des alternatives claires.