Philippe F a écrit 2214 commentaires

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.

Personne ne se plaint d'avoir trop de choix, au contraire.

Ben si justement, quelqu'un se plaint, c'est la personne à laquelle tu réponds. C'est quand même gonflé de dire que cette personne n'existe pas.

Tu peux me rajouter aussi, je me plains d'avoir trop de choix. Nous sommes donc au moins deux, et à mon avis pas tous seuls. Détail qui a surement une importance, je n'utilise plus Linux sur mes ordi depuis longtemps, uniquement sur quelques serveurs par ça par là, tout comme mosfet. Je reste cependant passionné par le sujet et par le logiciel libre en général, que j'utilise à fond sur mon OS propriétaire (dont le nom commence par W).

Pourquoi est-ce génant d'avoir trop de choix ?

1. Interférence avec le but initial
2. Choix compliqués à trancher
3. Choix indécidables

Alors, je détaille:

1 Interférence avec le but initial

Je veux naviguer sur le web. Je me pose pas plus de questions que ça, juste naviguer. Lequel de 6 navigateurs suivants dois-je choisir, sachant que je ne suis pas un spécialiste des logiciels libres: Firefox, Epiphany, Konqueror, Chrome, Opera, Dillo ?

Et encore, j'en ai exclus des moins matures.

Mais moi, je veux pas choisir entre 64 trucs, je veux juste aller sur le web.

2 Choix compliqués à trancher

Mettons que finalement, je suis prêt à chercher à comprendre de quoi il retourne. Je vais passer du temps à me documenter sur Firefox, puis sur Opera, puis sur Chrome. Bon, côté javascript, ça se tient à peu près, côté support plugin aussi. Donc il faut creuser encore pour savoir lequel serait le meilleur navigateur. Finalement, aucun ne sort vraiment du lot, Opera est juste un peu moins populaire.

Idem si tu regardes les bureaux. Pour quelqu'un de pas trop regardant, Gnome, KDE, XFCE, c'est Schtroumpf Vert et Vert Schtroumph. La place du bouton OK/Cancel doit elle être un critère dans mon choix de décision de mon environnement du bureau ?

En fait, je suis obligé de me rajouter tout plein de critères qui n'ont pas tant d'importance pour moi et qui ne serve qu'à une chose: décider un truc difficile à décider. C'est donc une construction semi-artificielle.

Mais à quoi sert tout ce temps passé ?

3 Choix indécidables

Un certains nombre de choix des distributions Linux sont à mon sens indécidables, dans la mesure où ce qui différencie deux choix est hors de portée de l'utilisateur. LibreOffice ou OpenOffice ? Pour qq'un qui se fout de savoir si c'est GPL et si Oracle est méchant ou pas, le choix est indécidable. KDE ou Gnome rentre à mon avis dans la même catégorie.

Mais, après tout le travail d'analyse sur le choix que tu peux faire, l'utilisateur a l'impression au final de ne rien comprendre et de ne rien choisir. Finalement, cette notion de choix est plus marketing que réelle.

C'est un peu comme le sketch de Pierre Palmade:

Tu préfères avoir la grippe toute ta vie ou avoir 20 canards qui te suivent partout ?

Mais tu me dis « te plains pas, on te propose un choix ».

Oui, mais c'est pareil pour les voitures, les machines à laver, les téléphones portables, les abonnements téléphone portable.

Tout à fait, et ça me pose le même problème.

Depuis 15 ans, ça doit bien faire la 15e fois que je vois ce type de projet: aider les projets à trouver des développeurs. Aucun n'a marché, bien qu'à chaque fois, tout le développement technique ait ét fait.

Pourquoi ça ne marche pas ? Parce que il n'y a aucun marché tout simplement. Pour avoir un marché, il faut des vendeurs et des acheteurs (des proposeurs et des réalisateurs dans ton cas).

Bien sur qu'il y a des vendeurs/proposeurs: 100% des logiciels libres pourraient utiliser un peu d'aide dans n'importe quel domaine: documentation, traduction, portage, correction de bug, nouvelle fonctionnalité, amélioration d'interface, plus de test, etc etc. C'est pas comme si un projet avait plus besoin d'aide qu'un autre.

Du côté des acheteurs/réalisateurs, qui trouve-t-on ? En grande majorité des développeurs pour travailler sur le code, quelque fois des utilisateurs avancés qui peuvent contribuer de l'aide, des traductions ou des suggestions intelligentes.

Cette population là n'a pas besoin de toi pour s'intéresser à un logiciel. Perso, je suis développeur. Si je veux contribuer à un logiciel, je vais choisir un logiciel que j'utilise, ou qui me plait par son concept. Je vais d'abord m’intéresser un peu à la communauté, m'inscrire à des mailing list, suivre un peu les versions qui sortent, le rythme, etc. Une fois que je suis familier, je vais contribuer quelque chose à ma portée.

Pour certains logiciels, petits, je peux avoir un élan spontané et corriger un bug ou me lancer dans un sujet précis (fonctionnalité, portage, …).

Dans tout ce processus, je n'ai eu aucun besoin d'intermédiaire, et ton système de petites annonces ne m'apporterait rien.

C'est pour ça que tous ces projets se plantent au bout de 6 mois ou 1 an.

A voir, car le parement de laine de verre brûle très bien aussi (c'est du papier kraft) et beaucoup plus vite que du chanvre. Ta maison partira encore plus vite en fumée…

Note que on a le même problème avec bash vs sh. Une très très grande partie des scripts shell qui sont écrits aujourd'hui se croient compatible sh alors que dans les faits, ils ne sont compatibles que bash. Les subilités sont extrèmement pointues, je ne m'en rappelle plus mais dans les faits, on a bloqué à coup de script le shell qu'on utilise (par exemple, dans l'init Sys5).

Le même problème existe aussi avec gcc. Nombre de logiciels libres écrits en C ou C++ ont en fait vérouillé leur plate-forme indirectement par l'utilisation de constructions supportées uniquement par gcc (au hasard, les macros avec nombre d'arguments variables).

Bref, plus ça va, plus on se recentre sur des logiciels dominants de l'écosystème. Est-ce un problème à ce point-là ? Je n'en suis pas sur.

On peut citer aussi dans le monde de la carte à puce la .NET card, carte à puce censée prendre le marché très réservé de la Javacard, elle même censée prendre le marché des cartes multiapplicatives qu'on peut mettre à jour à distance et sur le terrain. Elle faisait tourner un sous-ensemble des fonctionnalités .NET .

La seule vente de ce produit semble avoir été à Microsoft, pour ses employés.

C'était d'ailleurs le deuxième ratage de Ms dans le monde de la carte à puce, ils avaient aussi fait une tentative tout aussi ratée par le passé.

Pour un client qui utilise des systèmes mixtes Windows / Linux, leur nouveau FS est inutilisable. Ca veut dire que pour ces cas-là, on prendra du FAT32 si on est conservateur, du NTFS si on n' pas trop peur de se lancer.

Microsoft reconnait aujourd'hui l'existence de Linux sur le marché professionnel, et propose même un certain nombre de pont. Ils sont présents au salon Linux, etc etc. Donc ce positionnement est incohérent.

C'est vrai que Microsoft pourrait montrer sa bonne volonté en nous pondant un petit driver libre pour Linux, ça nous changerait du passé !

Python est un projet collaboratif international, mais je salue quand même le travail considérable qui a été fait par nos deux développeurs français sur cette version, à savoir Antoine Pitrou et Victor Stinner. Et en plus, ils lisent linuxfr !

Petite question sur le yield from: est-ce que c'est juste de la simplification de syntaxe, ou est-ce que on peut en attendre des légers gains de vitesse si on l'utilise par rapport à l'ancien idiome ?

Tu pourrais nous donner quelque chiffres sur la popularité de Gambas ? Et quelques exemples de programmes réels ?

Côté utilisateurs, tu as plutôt des développeur power-user, ou des débutants en programmation ?

Du coup, on pourrait surement écrire un interpréteur Gambas en PyPy ! Je serai curieux de voir les perfs par rapport à du llvm.

Oui, mais le neveu Gnome fait toujours comme Tonton faisait il y a 20 ans…