GuieA_7 a écrit 704 commentaires

(Désolé si ma définition n'est pas très rigoureuse). C'est une routine pour laquelle l'environnement va sauvegarder le contexte d’exécution entre chacun de ses appels, ce qui fait que d'un appel à l'autre l’exécution de cette routine se fait de manière continue. Bon je vais éclaircir avec un exemple en Python.

Si j'écris une fonction de ce style :

def foo():
    return 1
    return 2
    return 3

Tu vois bien que ce code est stupide : il va retourner '1' à chaque appel, et les 2 autres 'return' sont inutiles. En revanche si j'écris :

def foo():
    yield 1
    yield 2
    yield 3

Grace à 'yield', Python va me générer tout seul une classe d'itérateur qui utilise mon code pour générer les valeurs successives. Je peux alors faire ça :

it = foo()
print it.next() # '1'
print it.next() # '2'

Ça aurait été faisable à la main évidemment, mais là c'est beaucoup plus court et simple. Ça permet rapidement de faire des choses complexes sans trop de se prendre la tête.

J'ai l'impression que les goroutines de Go justement permettent de faire des continuations (et c'est bien).

Pas de continuation nativement en C++, mais c'est sûrement faisable via des hacks bien pointus (ou avec des threads mais pas terrible pour les performances du coup). Et un goto c'est bien pour rester dans la frame d'une fonction, pas pour remonter dans la pile d'appel, si ton algo est récursif par exemple.
Il y a une petite dizaine d'années ma prof de Ocaml nous conseillait d'utiliser une exception pour remonter le résultat d'une recherche récursive de manière efficace. Ceci dit je ne suis pas un pro en Ocaml (je n'en ai pas fait depuis) et c'est peut être un mauvais conseil.

Désolé pour les erreurs et approximations, dues à ma flemme de chercher (l'important étant la position de Nintendo face au libre) et merci pour tes corrections.

Autant j'espère que ce que tu dis est vrai, autant je reste circonspect, car je pensais comme le post auquel tu réponds. En effet, si je me souviens bien, il y a quelques années il y a eu une affaire avec EA qui avait fait développer un jeu pour plateforme Nintendo par un studio. C'était un jeu d'aventure point n' click, et ledit studio avait utilisé ScummVM (sous GPL). Quand cela s'est su, la libération des sources a été demandé pour se conformer à la licence de ScummVM, mais d'un autre côté la licence du SDK de Nintendo interdisait justement le libre[]. EA s'est donc retrouvé pris en étau avec 2 licences contradictoires qu'il devait respecter, et avait finit par donner une somme d'argent aux développeurs de ScummVM, comme pour acheter une licence propriétaire, et n'avait pas libéré les sources.

[*] comme quoi on peut apprécier certains aspects d'une boite (je pense que Nintendo a certain des meilleurs game designers du monde, et j'admire leur ténacité face à des entreprises autrement plus grosses), et trouver au final que ce sont des gros b*t*rds !

Je n'ai pas été très clair, je vais reformuler. Firefox est un logiciel libre, destiné au grand public (RedHat ne l'est pas par exemple) et qui rapporte beaucoup d'argent à ses auteurs. Je ne voit pas d'autres soft dans ce cas (c'est à dire réunir les 3 critères - des cas qui réunissent 2 critères j'en voit beaucoup), mais je peux me tromper.

Je vais faire plusieurs remarques suite à tes différents posts :

• Premièrement tu compares l'argent récoltée par un logiciel libre (avec des dons visiblement) et les prix d'un freelance, ce qui n'a pas beaucoup de sens. Il faudrait comparer à l'argent gagné par un logiciel propriétaire gratuit 'équivalent' et qui accepterait les dons lui aussi. Au final ça ne serait sûrement pas bien différent à mon avis : le don n'est pas un business model valide pour du logiciel.
• Tu as l'air de penser qu'un freelance se fait 10 000€ par mois ; si certains s'en sortent certainement très bien, la réalité est bien différente. Il y a les taxes évidemment, mais surtout le freelance ne facture pas tous les jours du mois, vu qu'il va passer un certain temps à trouver des contrats. S'il ne facture rien dans le mois et bien il gagne 0€. Si être freelance c'était la recette facile pour une richesse assurée ça se saurait hein. Ceci dit tu es libre de faire freelance à mi-temps (et gagner 5000€ par mois selon toi) et faire du libre bénévolement le reste du temps…
• Il est clair de gagner sa vie comptant sur les dons (ou même en vendant) un logiciel libre pour le grand public ça ne marche pas malheureusement : Firefox est l'exception (et ce n'est pas une entreprise), Mandrake ne faisait pas que vendre son logiciel etc… Il faut vendre quelque chose qui apporte un plus. À une entreprise tu vends du support, de la formation, des jours de développement spécifique. Pour un particulier, il faut trouver autre chose ; par exemple sur pokecraft tu pourrais vendre les assets (et ne pas les mettre sous une licence libre), si ça te semble acceptable (parce que du coup le soft n'est pas vraiment libre). Tu serais assez vite fixé sur le nombre de gens réellement prêts à payer, et ce n'est pas du tout dit que tu gagne un smic.

En espérant avoir éclairé ta lanterne.

+ 1

À coté de ça, les jeux libres sortent régulièrement des releases mais le jeu ne passe rarement la phase de développement

Je me demande depuis longtemps si ça serait envisageable que la communauté des libristes rachète les sources (code et assets) de jeux propriétaires ; un peu comme pour Blender, mais en allant chercher les éditeurs (alors que NaN a fait sa proposition lors de sa faillite). Par 'envisageable' j'entends 'combien ils demanderaient' (vu que tout à un prix). Je pense principalement à:

• des jeux indépendants ayant reçu de bonnes critiques mais étant passé un peu à coté de leur public.
• des jeux un peu anciens et plus commercialisés.

Dans les 2 cas peut être pourrait-on obtenir la libération pour un prix attractif, les ayants droits recevant une somme inespérée.

Comme tu le dis, les jeux libres faits bénévolement passent rarement la phase de développement : c'est dur, il faut un moteur, suffisamment de ressources graphique et sonores, des niveaux bien conçus, pas mal de polish… En revanche pour un soft ayant déjà atteint un bon niveau (voire ayant déjà une communauté), le développement serait plus attractif. Je pense à Blender ou à Warzone 2100 qui sont de bons exemples ; ou même, dans un genre très différent, TrackMania, qui démontre que beaucoup de joueurs sont prêts à faire de la création pour un jeu qui les amuse.

Tu prends un exemple où les choses se passent plutôt bien à l'heure actuelle: un projet bien défini, 100% informatique où des tonnes de solutions toutes prêtes existent.

Non pas forcément. Quand tu te mets à utiliser un ERP, il faut beaucoup de customisation derrière quel que soit le degré de finition de l'ERP (et donc ça ne se passe toujours bien du tout).

si une entreprise s'arrange pour avoir dans son personnel (managers, ingénieurs) quelques personnes qui savent programmer, alors […]

Oui je suis d'accord, si elle arrive a avoir des gens qui savent en plus programmer, ça va être cool pour elle. Mais comment font les employeurs profanes en info pour savoir si un de leurs managers sait programmer ? Dans la vraie vie, le gars-qui-sait-programmer (selon le profane) c'est souvent un gars qui à réussi à faire une macro Excel. Pour l'avoir vu un bon nombre de fois, ça finit en souvent une appli interne infâme en Access ou en WinDev totalement non maintenable.

Je ne dis pas que sous traiter change cet état de fait, je dis juste que "il suffit de trouver quelqu'un qui sait programmer" ça sonne bien, mais il n'y pas de solution magique malheureusement.

Je ne suis pas sûr de te suivre. Tu veux dire que si une entreprise qui fait, par exemple, de l'ébénisterie, et fait toute sa gestion manuellement depuis des années, veut mettre en place une gestion informatisée (stocks, clients, commandes etc…), elle doit chercher un ébéniste qui sait programmer ?

Ah mais on est d'accord. Le pire c'est les boites qui arrivent à sous traiter leur coeur de métier où elles sont compétentes en interne, à des gens moins compétents (oui ça existe) !!

Je dis juste que quand on n'y connait rien, embaucher ou sous-traiter sera difficile ; si le mec qu'on embauche (que ce soit pour se constituer des compétences en interne, ou pour surveiller la sous traitance) est mauvais, et bien la suite s'annonce compliquée.

Pour la petite histoire, le SI de bras cassés a passé, au début, le plus clair de son temps à faire croire au patron que c'est nous qui étions la cause des problèmes de la bonne marche du projet (plutôt que de faire son boulot). Depuis, le patron a finit par comprendre qu'ils payaient toute une bande d'incapables depuis des années, et il cherche à dégraisser…

Mon commentaire disait justement qu'on a le même problème avec les employés ! Si tu es incapable de comprendre que tes employés sont incompétents, tu seras incapable de savoir que ton sous-traitant est incompétent.

D'où le fait que je dise que c'est compliqué.

perso je ne le traiterai pas d'incompétent

Je me suis peut être mal exprimé : je parlais précisément de mon 2ème exemple ; ces gens ont pondu une espèce d'ERP en PHP/MySQL. Donc oui, ils sont censés savoir faire une requête SQL (et les preuves de leur incompétence sont nombreuses, mais peu importe).

cest que les ssii essayent de tout faire et du coup ne font rien correctement

Je n'ai pas dit le contraire ; en fait j'ai même dit que je n'aimais pas les SSII…

les entreprises devraient commencer à embaucher quelques employés qui savent utiliser un ordinateur

Si je suis d'accord dans le fond (j'ai horreur des grosses SSII), ce n'est pas forcément aussi simple que ça. En effet, lorsque ladite entreprise n'a pas la culture informatique (ce n'est pas du tout son métier), et bien c'est difficile pour elle d'embaucher des gens compétents : ils sont rares, contrairement aux incompétents qui ont appris à cacher leur incompétence (surtout à ceux qui n'y connaissent rien). J'ai vu ce cas de figure à 2 échelles ; une fois un petit service informatique de 4 personnes dans une PME de quelques centaines d'employés, et une fois un service informatique de 150 personnes pour une entreprise de la grande distribution. Dans ce 2ème cas, les plus compétents du lot arrivent difficilement à pondre une requête SQL simpliste en 3 jours… Au moins le sous-traitant on peut s'en débarrasser un peu plus facilement.

et les geeks végètent en SSII

Mouais. Contrairement à un ouvrier peu qualifié qui n'a pas trop le choix, un informaticien compétent peut trouver un boulot sympa s'il s'en donne la peine. S'il se contente des mêmes SSII qui embauchent tous les bras cassés, et ben il ne peut s'en prendre qu'à lui même.

C'est un « ou » ou un « et » ?

Je parlais bien d'un « et ». On va dire qu'effectivement on ne peut pas toujours améliorer à la fois tous les critères que j'énumère, mais 2 ou 3 sans dégrader les autres est très souvent possible. Je travaille beaucoup avec des (talentueux) juniors, mais bien souvent ils se contentent de faire du code qui marche (ce qui est déjà bien) ; j'essaie de relire systématiquement leur code, et je les surprends souvent en améliorant tous (ou du moins la plupart) de ces critères. Et leur code est bien meilleur que ce que j'ai pu voir écrit par le mec lambda en SSII, ce qui doit représenter une grosse partie du code écrit dans le monde. Je n'ai évidemment pas la prétention d'en faire de même dans le kernel, mais l'informaticien de gestion de base n'est pas Linus Torvalds malheureusement…

Et moi je me suis toujours demandé comment on pouvait être aussi sûr qu'un code n'est "pas correct".

Autant il est difficile de dire qu'un code est correct, autant il est bien souvent facile de montrer qu'un code ne l'est pas. Si on peut le réécrire en 3 fois moins de lignes, en plus simple, plus robuste, plus lisible et plus performant, c'est que le vieux code n'était pas bien fameux.

Heu c'est normal d'avoir 50 après 15 (alors que les autres constantes vont en décroissant) ?

PS: en tant que développeur python, j'aurai créé un alias du genre "diff = self.f.score - self.old_score", histoire de gagner en lisibilité et en performance.

Ok alors toutes mes excuses ; le C est conservateur, pas le Fortran (les conservateurs ce sont les pappies qui s'accrochent à leur f77 :) )

Un bémol cependant : il me semble que des fonctionnalités obligatoires du C99 vont devenir optionnelles dans la version suivante (genre les nombres complexes). Si c'est le cas, un code C99 (utilisant ces fonctionnalités) ne passera pas forcément sur un compilateur C11.

Ça a déjà été galère quand j'ai mis à jour ma machine de 2.5 vers 2.7 (je ne connais que très très peu python)

Je souhaite bon courage aux pythonistes pour maintenir leur code à chaque évolution de leur langage.

Il n'y a pas à toucher un programme qui tourne en 2.5 pour qu'il tourne en 2.7 : la cassure est avec la branche 3, les versions d'une même version ont bien heureusement la compatibilité ascendante.

Personne n'a envie de réécrire des millions de lignes de code en f77 qui fonctionnent bien et ont été méticuleusement testées sur au moins vingt ans, et tout le monde veut bien les utiliser.

C'est bien ce que je dis, il y au moins une personne qui passe son temps libre, ou bien qui est payée, pour maintenir f77 dans GCC. Si demain ce n'est plus le cas, et que tu es le dernier utilisateur, tu devras aussi te garder sous le coude la dernière distribution gérant f77, et utiliser une machine virtuelle par exemple.

Si ces projets ne sont pas activement maintenus (les étudiants finissent leur thèse puis passent à autre chose), il sera impossible de les exécuter quelques années après l'abandon de python2. Ou alors avec un vieux livecd de 2012, s'ils démarrent encore sur les ordinateurs de demain.

Je ne sais pas quand le support de Python2.7 sera perdu dans la pratique ; si des tas de gens sont prêts à payer pour qu'il soit maintenu (plutôt que passer les 2h à modifier leur programme) ça peut être dans longtemps (de base le projet Python a tablé sur 5 ans, mais dans les distributions comme Debian ça devrait être là plus longtemps). Mais effectivement, si en 2025 tu es vraiment intéressé pour faire tourner le code de tes thésards de 2010, tu devras peut être te garder une Debian de 2024 + Machine Virtuelle, c'est bien triste pour toi. Quelque chose me dit que si personne n'est motivé pour passer quelques heures sur ces programmes d'ici 15 ans, c'est qu'ils ne doivent pas être si utiles que ça... Je peux comprendre cependant que tu sois déçu.

Mes scripts perl qui ont 10 ans sans maintenance dans /usr/local/bin

Pareil que f77 (quelqu'un fait la maintenance).

Tout cela est une histoire d'offre et de demande en quelque sorte. Une communauté peut se former pour faire Python2.8, Python2.9 etc.. qui ne cassent pas la compatibilité. Si ça ne se fait pas, c'est que les "conservateurs" ne sont pas prêts à payer, simplement.

Je ne dis pas que l'approche de Python ("progressiste") est mieux que l'approche Fortran ("conservatrice"); les 2 ont leurs avantages et leurs inconvénients. L'approche des langages n'est que le reflet de leur communauté ; il faut croire que la communauté Python préfère corriger les petites erreurs (je le répète, elles sont petites), plutôt que de pénaliser les futures implémentations. Je préfère l'approche Python, sans nier qu'elle a aussi des inconvénients ; tous les choix techniques sont des compromis, je l'ai déjà dit.

En ce qui me concerne faire évoluer mes programmes n'est pas une contrainte mais une véritable philosophie (et même un grand plaisir).

Cette notion que casser des programmes qui marchent, c'est toujours "les améliorer" me fatigue. Un programme qui a été développé, qui marche bien, qui est en prod depuis plusieurs années, pourquoi devrait-il être modifié ?

Je ne force personne à changer son code (enfin sauf mes collègues ! :) ). Ceci dit, je pense que dans l'ensemble, en informatique, on souffre beaucoup plus du pattern "ah oui ce truc a été écrit par Jean-Louis y a 15 ans, personne ne sait ce que ça fait exactement alors on y touche pas" que gens qui aiment réécrire leur code en mieux.

Ça ne veut pas dire qu'ils faillent tout refaire depuis zéro tous les 3 mois ; mais dans le cas présent passer 2 jours en 10 ans, ça me paraît acceptable. Tous les choix techniques sont des compromis, et en tant que Pythoniste je suis content que cela soit cette voie qui soit prise (plutôt que l'immobilisme de Java par exemple).

De toutes les façons, il ne faut pas rêver, un système informatique nécessite de la maintenance, l'immortalité n'est pas de ce monde. Si il veut recompiler son programme Fortran77 avec le dernier GCC et bénéficier des dernières optimisations, il faut que des gens aient porté Fortran77 avec la dernière infrastructure de GCC. S'il veut juste tourner sur le dernier Linux sans recompiler son programme, il faut que les développeurs Linux fassent attention à ne pas casser l'ABI. Si il ne veut rien changer du tout au soft, et compte faire tourner la bécane telle quelle pendant 30 ans, il lui faudra quand même prévoir des pièces de rechange, car le hardware ça vieillit.

Mais si un jour plus personne n'est prêt à payer (en temps ou en argent peu importe) pour que Fortran77 soit maintenu dans GCC, et bien le support sera jeté, c'est comme ça. Mais croire que ne rien toucher suffira pour que ça continue à marcher comme avant, alors que le coeur de GCC aurait été réécrit pour bénéficier des dernières avancées en terme de compilation, c'est se mettre le doigt dans l'oeil. On ne peut pas avoir le beurre et l'argent du beurre.

Pour l'instant la communauté Fortran77 est sûrement assez active, peut-être même que des tas de gens sont prêts à payer pour ne pas avoir à changer leur vieux code. Mais au final il y a forcément des gens qui payent cette maintenance. Et comme c'est du libre, on peut en profiter sans avoir soi-même payer quoi que soit ; mais rien de magique la dedans.

En fait nous sommes d'accord je pense, je voulais juste tempérer tes propos. Parce que la phrase "le compilateur n'a qu'a optimiser", je l'ai souvent entendu prononcée par des mauvais codeurs, qui pondent 100 lignes de code toutes pourries, là où 10 lignes simples suffisaient (mais fallait utiliser sa tête).

D'ailleurs, quand on réécrit du code en 4 fois de lignes, en ayant la volonté première d'avoir un code plus simple, lisible et maintenable, mais qu'en bonus le code devient plus rapide, est-ce de l'optimisation ?

ça sous-entend déjà qu'ils pourraient décider d'arrêter et ça rassure pas du tout pour la pérennité de l'éventuel code que je pourrais écrire si je m'y mettais.

Ce n'est pas un sous entendu : le destin de la branche 2 est de mourir, remplacée par la branche 3 (encore une fois les différences sont minimes et valent le coup à mon avis). Donc effectivement, si ta façon de bosser est d'écrire du code, et de ne plus y toucher pendant 30 ans, alors non le Python n'est pas pour toi. Mon post n'avait pas pour but de faire la promotion de Python, il a déjà une active communauté (que d'autre bons langages n'ont pas).

Il faut bien voir qu'une nouvelle version de Python sort en moyenne tous les 2 ans, avec à chaque fois des fonctionnalités bien vues, qui vont permettre d'améliorer lentement mais sûrement les applications. Passer de Fortran77 a Fortran90, ça serait comme passer de Python1.0 à Python3.0, ce que personne ne fait, ne serait-ce que parce que personne n'utilise plus la branche 1, et les premières versions de la branche 2 ne doivent plus l'être non plus. Si il y avait eu Fortran79, Fortran81, etc... avec à chaque fois tous les compilateurs mis à jour en même temps, des fonctionnalités alléchantes mais qui permettent une évolution progressive, peut-être que ton code Fortran77 aurait été amené en douceur vers Fortran90, pour un code plus simple et maintenable (peut être même plus efficace, je ne connais pas Fortran).

Je pratique (ou ai pratiqué) le C++ et le Python à titre personnel comme à titre professionnel, et ce sont 2 langages que j'affectionne beaucoup.

Je vais répondre à la pique sur Python. Tu penses que la cassure Python2/Python3 est une erreur, et tu as raison dans la mesure où, si cette politique était appliquée au C++, cela provoquerait une catastrophe. Mais les situations de Python et de C++ sont très différentes, et donc ce qui est bon pour l'un ne l'est pas forcément pour l'autre. Je m'explique.
Le Python a une implémentation de référence (CPython), qui est utilisée par 99% des gens. On peut trouver ça dommage. Mais bon cette implémentation est libre, gratuite, multiplateforme, plutôt performante, ce qui fait que globalement on n'a pas trop à se plaindre.

• Du coup quand une nouvelle version sort, on peut si on le veut utiliser les nouvelles fonctionnalités tout de suite, pas la peine de se demander quand est-ce que la majorité des implémentation auront un support suffisant (par exemple la gestion catastrophique des templates par VC++6), ou bien de faire plusieurs version du même code suivant le compilateur (avec de la compilation conditionnelle). Pas non plus de fonctionnalité dans le standard mais implémentée par personne ('import' du C++).
• La branche 2 sera maintenue par l'équipe Python pendant des années ; en plus les dernières versions de cette branche (2.6, 2.7) se sont beaucoup rapprochées de la branche 3. Au final l'effort à fournir est minime (et il existe un outil officiel qui fait la conversion) et on a des années pour faire ce petit effort. À côté de ça, dans la pratique, malgré la non cassure du monde C++, si tu trouves un vieux projet C++ qui a traîné des années sans avoir bougé, pas sûr qu'il compilera sans problème, pour peu qu'il s'appui sur d'autres bibliothèques qui elles auront évolué. De toutes les manières un code non maintenu finit par mourir.
• Il y a évidemment bien moins de logiciel en Python qu'en C++, et leur code est sûrement bien plus petit (c'est bête mais pragmatique).

Je vis en faisant du Python (c'est donc un peu plus qu'un simple amusement sans conséquence), et le passage à Python3 ne m'effraie du tout, j'ai même hâte de le faire.
Les langage C++ et Python évoluent de manière différente, mais à mon avis les 2 le font assez bien (même si je suis assez déçu de la dernière version de C++).

(En même temps, c'est un faux argument, ce n'est pas à l'humain de faire les optimisations mais au compilateur.)

C'est un peu plus compliqué que ça malheureusement. Même dans les langages fonctionnels, il est par exemple conseillé de faire des récursions terminales, histoire d'utiliser efficacement la pile. Or la version avec récursion terminale est souvent un peu moins jolie que la version naïve.
Peut être que des compilateurs sont capable de faire cette transformation tout seuls cela dit (je ne suis pas un spécialiste), mais je pense que le programmeur aura toujours une part de responsabilité dans l'optimisation.

Malgré les qualités intrinsèque de FireFox (et plus récemment de Chrome), il est clair qu'il a percé aussi parce que IE6, pourtant installé de base sur 90% des machines de bureau, est une vraie bouse. Je pense qu'en limitant la casse (en laissant une poignée ingénieurs sur le projet) afin de le rendre juste assez médiocre pour que la fuite des utilisateurs soit faible, IE serait encore en quasi monopole. Et du coup Bing serait sûrement bien moins à la traîne.
En somme pour économiser quelques dollars, ils ont craché à la figure de millions d'utilisateurs, et maintenant des milliards leur passent sous le nez. Ahah, bien fait !