GuieA_7 a écrit 675 commentaires

Je pense en effet que Rust est assez "élitiste" et la courbe d'apprentissage un peu rude ; j'ai d'ailleurs un peu peur qu'à cause de ça Rust reste assez marginal à l'instar de OCaml ou Haskell.

Un article assez intéressant qui résume assez bien la situation :
http://arthurtw.github.io/2015/01/12/quick-comparison-nim-vs-rust
Bon en l’occurrence il est très probable que Nim reste lui aussi marginal, mais peu importe : Rust est sûrement le langage dans lequel on aimerait avoir codé un gros projet quand sa taille devient un problème, mais ne sera pas peut-être pas être assez "fun" pour débuter ledit projet, quand on ne sait pas encore qu'il va être gros :)

Bon après j'espère me tromper, et l'arrivée de bons outils (aide au refactoring automatisé, autocomplétion, voire même IDE) pourrait bien changer un peu la donne.

Je pense que tu as lu un peu vite, ou que je n'ai pas été assez clair.

Il se trouve que dans le cas particulier qui nous importe, l'interface Evaluable existe déjà à mon sens dans le langage, et c'est ce que j'appelle un callable (appelable comme une fonction donc). Je lui conseille donc de ne pas traduire le code Java trop bêtement en évitant de définir une nouvelle interface.

Mais comme je l'indique dans ma dernière phrase, il peut remplacer __call__ par eval (dans ce cas il faudra faire f.eval(1) et plus f(1) évidemment), et de même il pourrait rajouter des méthodes eval2 ou zigouigoui si il veut.

Ainsi que François l'explique au dessus, en général tu vas définir une classe AbstractMachin ou BaseBidulos, dans laquelle tu vas mettre des fonctions :

• qui soulèvent une exception NotImplementedError
• qui fournissent une implémentation de base (comme les Adapter de la lib standard Java si je me souviens bien).

un peu comme tu peux le faire en C++ et ses classes abstraites.

Il n'y a pas (à ma connaissance) de classe maitresse de toutes les autres

o = object()

Bon après rajouter des méthodes à un objet/classe ça arrive et parfois ça "sauve la vie", mais on le fait assez rarement.

S'il n'y a pas d'interface formelle[*] en Python c'est parce qu'on raisonne en terme de duck-typing, ce n'est pas à cause de la dérivation multiple.

Ton interface dans l'absolu c'est juste un callable (un truc qui s'appelle comme une fonction). Tu peux faire un truc comme ça:

class Courbe(object):
    def __init__(self, f):
        self.f = f

def main():
    [...]
    c = Courbe(lambda u: u * u)
    [...]

Ou bien avec une "vraie" fonction (que je définis bien ici depuis l'intérieur d'une autre fonction, comme toi):

def main():
    [...]

    def foobar(u):
        return u * u

    c = Courbe(foobar)
    [...]

Voire même avec une classe qui définit la méthode __call__ et peut donc être appelée comme une fonction:

def main():
    [...]
    class Foobar(object):
        def __call__(self, u):
            return u * u

    c = Courbe(Foobar())
    [...]

(évidemment si tu tiens vraiment à ta méthode 'eval' tu peux modifier mon dernier exemple, mais je trouve ça moins pythonique).

[*] Ce qui n'est plus tout à fait vrai: https://docs.python.org/release/2.7/library/abc.html#module-abc

Tu te rends compte que tes exemples ne font qu'apporter de l'eau à mon moulin ?

Non et je vais ré-expliquer pourquoi.

Linux, comme dit avant moi, n'est pas parti de rien, il s'est appuyé sur des briques déjà existantes à l'époque, notamment le userland GNU, et GCC

Je n'ai pas prétendu que Linux était parti de rien. Évidemment qu'il utilise un langage/compilateur existant ; même si tu utilises C++ et SFML pour ton projet, je considère que tu l'as codé depuis 0, au contraire de si tu avais par exemple forké un jeu existant (après ça reste discutable). Ce que je dis c'est qu'il est issu d'un développement intensif, et pas d'un simple assemblage de briques existantes faisant une chose et une seule (scheduler, gestionnaire de mémoire, VFS…) ; si de telles briques avaient existé chez GNU, ça voudrait dire que Hurd était disponible.

Blender et OpenOffice : beaux exemples de développements intensifs… non-libres

Tout à fait mais que tu le veuilles ou non, ce sont maintenant des projets libres, et sans cette phase de développement non-libres, ils n'existeraient pas. Difficile de savoir si la communauté auraient été capable de faire aussi bien, et c'est pour ça que j'ai parlé des hypothétiques équivalent libres à Photoshop et cie, qui me font dire que non, on aurait pas aussi bien que Blender.

Développer un logiciel proprio et le libérer ce n'est pas ma façon de faire, ni la tienne, mais ça reste une option qui a donné des résultats.

Et tu décris toi-même le processus en cours chez LibreOffice : ils utilisent un maximum des briques libres.

Oui maintenant ils ré-usinent le code (et c'est très bien), mais dans un premier temps il se sont foutu de faire des briques standards (parce que coder de telles briques était déjà suffisamment difficile comme ça), et s'en sont préoccupé largement après que OO est devenu une référence.

Quant à Firefox, il a commencé comme un navigateur basé sur une brique libre (Gecko) plutôt que par un développement from scratch.

Gecko est né des cendres de Netscape (avec donc une histoire un peu similaire a Blender/OpenOffice), et reste donc un logiciel développé de manière intensive par une grosse équipe, et pas un assemblage épars de briques standardisées.

On ne fait pas des bons jeux avec des hacks dans le libre. Le libre a la particularité de ne pas fonctionner avec des logiciels jetables mais avec du durable et du réutilisable.

• As-tu lu le code de beaucoup de logiciel libres ? Bon nombre de logiciels libres de référence (OpenSSL :) ) ont un code crade.
• hacks ! = jetable. Parfois un hack est nécessaire à un instant T pour que les utilisateurs aient un logiciel qui marche, et on l'enlève quand on peut. Les codeurs de Linux ou de Python par exemple sont les premier à avouer avoir eu recours à des hacks, ce n'est pas sale :)
• Attention je ne veux pas avoir l'air de prôner le code dégueulasse, en revanche la vertu numéro 1 d'un soft c'est de fonctionner (il faut juste ne pas s’arrêter à ce stade).

Je me suis peut-être mal exprimé mais il ne s'agit pas de partager des assets mais des formats. Si je reprends l'exemple des dialogues, on peut très bien avoir un format unique mais des dialogues différents pour chaque jeu. L'avantage du format unique est qu'il permet d'avoir des outils commun pour le manipuler.

Je comprends tout à fait l'idée, mais dans la mesure ou il n'y a pas de jeux libres d'aventures du genre d'akagoria, difficile de savoir quels vont être les besoins des autres jeux, qui devront donc être satisfaits pas cet éventuel format. Évidemment des tas de gens ici seront capable de te dire qu'il faut absolument ceci ou cela (moi le premier), mais sans être vraiment confronté au problème dans un vrai jeu, il est probable que tu finisses pas implémenter des fonctionnalités dont personne ne va se servir au final, et oublier les besoins réels des futurs jeux.

Si Ruby on Rails et Django sont si bons, c'est parce qu'ils ont été écrits par des gens ayant écrit par mal de sites/apps web, ce qu'il leur a permis de voir les besoins réels, les patterns récurrents, les abstractions qui seraient utiles. S'il les avaient conçus avant même d'avoir ne serait-ce qu'un seul site à moitié fini, ces frameworks serait sûrement morts et enterrés.

Ils ont du mal, pas tant dans le code que dans l'organisation.

Difficile de leur jeter la pierre, rien de ce que j'ai pu écrire étant étudiant ne vaut quoi que ce soit.

le libre ne se construit pas à grand coup de développements intensifs

Hum, c'est une vision un peu idéalisée des choses je pense. Un certain nombre de logiciels star du libre en sont le contre-exemple :

• Linux et ses milliers de contributeurs ; oui il implémente le standard POSIX, mais on ne peut pas dire qu'il ait vraiment pu utiliser des briques standards pour se faciliter le boulot.
• Blender a été développé intensivement durant sa période propriétaire (200 ingénieurs à un moment si je me souviens bien), et il ne serait pas le logiciel libre qu'il est sans ça (il n'y a qu'à regarder la concurrence libre). Évidemment il utilise des libs existantes, certaines avec des standards (ex: jpg, mpeg, png…) et d'autres non (ex: bullet), mais il est très loin d'être un assemblage de petites briques qui géreraient les maillages 3D pour une, les squelettes pour une autre, la texturisation encore à côté etc… (à mon avis une telle approche serait vouée à l'échec).
• Open/LibreOffice : là aussi développé à la base intensivement chez Sun. Les dépêches sur LinuxFr nous ont permis de voir qu'en pratique ils ont développé pas mal d'outils spécifiques (qui n'existaient pas en standalone) et se retrouve aujourd'hui à supprimer ces outils en faveur d'outils 'standards'. J'ajouterai que ODT a été standardisé longtemps après la création du logiciel, mais c'est sûrement une bonne chose, afin d'avoir une bonne idée des besoins et des problèmes rencontrés.
• Firefox

À côté de ça, les logiciels libres qui justement nécessiteraient peut-être d'un développement intensif (parce que les petites briques ne sont pas toujours une solution) mais qui n'en bénéficient malheureusement pas, sont en général à la traîne ("hey je suis un noob sous Linux et je cherche un équivalent gratuit à Photoshop/AfterEffects/Illustrator/SolidWorks…"). Pour le coup je pense que le financement participatif fait sûrement partie de la solution, puisque c'est naturel dans le libre de financer le développement avant plutôt qu'après, à coup de licences payantes.

une solution, c'est de faire des propositions, mais c'est aussi le risque de tomber dans le syndrome xkcd.

À mon sens, faire des propositions de standards n'est justement pas la chose à faire tout de suite ; ce qu'il faut faire c'est des bons jeux, avec des besoins variés, quitte à ce qu'il fasse des hacks chacun dans leur coin. Et ensuite on essaiera de rationaliser les besoins des uns et des autres afin de ne pas faire de standard bancal qui serait un boulet plus qu'autre chose.

Les fichiers standardisés c'est fondamental pour sauver les données créées par les utilisateurs et garantir l'interopérabilité. Dans le cas des jeux, cela n'a pas vraiment de sens si on parle des utilisateurs finaux : tu ne vas pas importer ta sauvegarde de FrozenBobble dans Hedgewars. Et si on parle des développeurs, le problème se pose rarement ; parce que très peu de jeux, donc peu de chance qu'il y ait un projet suffisamment proche pour que lui prendre des assets.

Je pense vraiment que akagoria est trop ambitieux pour quelqu'un qui ne peut évidemment pas bosser dessus à plein temps (mais la série d'articles n'en est pas moins excellente) [*] ; le fait de n'avoir pas à ce stade un prototype pour tester si les mécaniques fonctionne ou pas est bien plus inquiétant que d'avoir 3 parsers plutôt qu'un.

PS: j'ai hâte de voir une rétrospective des jeux qu'auront pu faire tes étudiants.

[*] j'ai du moi-même abaisser grandement les ambitions de mes jeux au cours des années, et je n'ai pourtant encore rien à montrer doit je puisse être fier…

Il y a déjà un beau moteur graphique

Ce n'est pas un moteur graphique, mais un moteur de jeu spécialisé dans les RTS.

Et oui Spring fait parti des moteurs libres les plus aboutis ; mais pour appuyer mon 1er commentaire, au final la moitié des jeux l'utilisant (http://springrts.com/wiki/Games) ne sont pas libres (contraintes NC et/ou ND).

Il ne permet donc pas de faire n'importe quel type de jeu, mais j'imagine qu'on doit pouvoir écrire son propre RTS sans toucher au code (ce qui est bien).

C'est dommage qu'on ne parle jamais de ce projet sur linuxfr.

Tu en sais sûrement plus que la plupart des linuxfriens sur ce projet, c'est donc peut-être à toi de faire le premier pas et d'écrire un journal ou une dépêche dessus ! :)

Et ce qui manque le plus dans les jeux libres, ce sont ces formats standardisés

J'aurai tendance à dire que non, c'est un problème très secondaire. Le jour où il y aura des tas de jeux libres de qualitay, et qu'on aura à gérer des tas de moteurs maisons avec leurs formats propres, et leurs différentes sous-versions etc…, alors le problème des standards se posera (d'ailleurs l'industrie du jeu y est confrontée — j'avais vu un article sur Gamasutra à propos de Collada y a quelques années par exemple).

Je ne peux pas ouvrir mes fichiers .blend (de Blender donc) dans un autre modeleur 3D ; c'est dommage mais en pratique, je m'en tape parce qu'aucun autre modeleur libre ne lui arrive à la cheville. Je préfère avoir un seul logiciel libre/gratuit/multi-plateforme qui assure, plutôt que plusieurs interopérables mais qui font le tiers de ce que je veux.

À côté de ça, ça plus de 10 ans qu'on peut facilement exporter les modèles 3D de Blender vers Ogre3D. Pourtant tous les jeux utilisant Ogre un tant soit peu aboutis sont propriétaires [*]. Pas parce que les libristes sont mauvais, mais parce que faire un bon jeu ça demande beaucoup de temps, qu'il y a peu de libristes graphistes, etc… De manière générale les créateurs de jeux libristes sont très peu nombreux, la comparaison avec les jeux propriétaires est donc forcément décevante.

Ton jeu utilise 3 formats : et bien tant pis c'est pas grave ! Quand tu auras des milliers de joueurs tu pourras proposer à tes étudiants un projet consistant à régler ce problème (ils seront ravis de toucher à un programme utilisé par des tas de gens).

Les formats standardisés ne vont pas t'apporter de graphiste libriste. A l'inverse un outil de création de jeu accessible à des non codeurs serait un vrai plus ; ces dernières années un certains nombre de très bons jeux indépendants utilisent des logiciels comme GameMaker. Mais :

• qui va écrire un tel soft en libre (c'est sûrement beaucoup de travail aussi) ?
• paradoxalement, un tel soft, gratuit et de qualité, serait sûrement utilisé avant tout pour faire des jeux proprios ! :)

J'espère ne pas avoir l'air trop négatif, je pense juste que le problème est complexe, et la solution pas forcément technique ; l'organisation de Jam et le prosélytisme de la part de tes étudiants est peut-être plus efficace au final !

Ah oui, félicitation pour ta série d'articles !

[*] Je dis ça sans méchanceté aucune, j'ai moi-même pas mal d'embryons de jeux libres dans mes cartons, dont un utilisant Ogre.

Je n'aime pas trop cette construction, ce n'est ni intuitif, ni très connu.

Je n'ai pas l'occasion de m'en servir tous les jours (comme des tas d'autres fonctionnalités au final), mais moi j'aime beaucoup cette construction. C'est à la fois lisible, et plus court et plus performant que par exemple avoir un booléen qu'on testerait en sortie de boucle. En fait j'ai même toujours pensé que ça irait bien d'autres langages genre le C.

Dans ce même registre, j'aurai aimé connaître ton avis sur Rust (en faisant abstraction du fait que la v1.0 ne soit pas sortie) ; il me semble qu'en ayant une bonne part de la puissance (concision/sûreté etc…) de langage comme Haskell/OCaml/Erlang tout en étant un vrai langage système (plus son concept de référence protégeant statiquement des data races par exemple), j'ai l'impression qu'une bonne part des analyses statiques sont déjà parties intégrante du langage (sans rebuter gens qui cherchent les performances brutes).

Quand les gens faisant du Rust s'appuient naturellement sur les forces du langages, dans le but d'obtenir des programmes élégants et performants, on y gagne en sécurité "gratuitement". Les programmes ne deviennent évidemment pas sécurisés par magie (la sécurité ça n'est pas que supprimer les buffer-overflows et cie), et pour le coup Capsicum ne perd aucun intérêt

Mais évidemment cela nécessite la ré-écriture des programmes, peut-être que c'est pour ça que tu évoques d'autres solutions.

Ceci est absolument faux. Tu confonds pas mal de choses.

Non. Parce que comme dit au dessus tu pointes le droit d'auteur "normal" (celui pour les livres, photos etc…) mais qu'il y a des exceptions spécifiques à l'écriture de code en entreprise.

Maintenant une entreprise peut-elle supprimer le nom d'un de ses salariés (ou sous-traitant) en tant qu'auteur ? Je n'en sais rien je l'avoue. Je n'ai peut-être pas été très clair, mais je parlais plus du fait de rajouter les informations manquantes fournies par la société 'C' en vue de libérer ; auquel cas il faut qu'il y ait au minimum la mention de 'A' en tant que détenteur des droits. Les salariés de 'C' ne seront que les auteurs ; je n'ai pas parlé de supprimer leurs noms, mais plutôt de les rajouter s'il ne l'ont pas fait eux-mêmes (en leur demandant leur avis). Je ne sait pas si 'A' aurait le droit de supprimer leurs noms comme je l'ai dit, mais en même tant ça serait un peu une attitude de merde de toute les façons, et j'étais plus dans l'optique de rendre à César ce qui lui appartient (à savoir un peu de reconnaissance).

J'imagine que les salariés de 'C' ont le droit de refuser, c'est pour ça que je dis de leur demander leur avis. Et le code ayant déjà été livré, je ne vois pas où 'A' s'oppose à ce qu'ils mettent leurs noms dans le code ; éventuellement ça serait la faute de 'C', je propose justement de rétablir la situation.

Mais encore une fois, si je n'ai pas été assez clair : je parlais uniquement d'ajouts.

Attention il faut faire la différence entre auteur et détenteur du doit d'auteur. Lorsque le salarié 'a' de la société 'A' écrit du code dans le cadre de son travail, il est l'auteur du code mais c'est 'A' qui détient les droits d'auteurs (j'admets que 'a' ne travaille pas en régie dans une société 'C'). Si ici 'B' a bien cédé ses droits à 'A' (cela dépend du contrat entre les 2 sociétés), alors c'est bien 'A' le détenteur des droits, quand bien même les auteurs sont des salariés de 'B'.

Seul le détenteur des droits doit figurer dans les sources, mais il est classique et sympa de citer les auteurs, ainsi qu'éventuellement leur rôle dans le code et une adresse e-mail, généralement dans un fichier AUTHORS. Cela ne leur donne aucun droit sur ledit code, mais à moins que le code ne soit honteux, ça fait plaisir un peu de reconnaissance ! Je serai donc d'avis de demander aux auteur chez 'B' s'ils souhaitent y figurer.

Pour la permissivité, attention cela veut dire que le code sous licence permissive peut tout à fait être intégré dans un code sous une autre licence (libre ou proprio) ; en revanche cela ne veut pas dire que la licence originelle du code peut être modifiée. Elle reste la même, tandis que le reste du code a une autre licence, mais ça ne pose pas de problème.

Auriez vous des suggestions de licences pour un mode permissif ou un mode contaminant ?

Restes sur des licences classiques et éprouvées :

• GPL/LGPL/AGPL pour du héréditaire/contaminant.
• BSD/MIT/Apache pour du permissif.

C'est déjà assez compliqué comme ça les licences libres pour ne pas aller en chercher une exotique que personne ne connaît.
Et si celles-ci ne te satisfont, que tu veux des clauses supplémentaires (genre obligation de remonter les modifications à l'upstream, ou avoir la photo de la sœur des contributeurs), tu vas te rendre compte que tu ne cherches pas à faire du libre.

Pourquoi? Du point de vue de l'acheteur non codeur, pwivateur sans DRM ou libre, c'est la même chose.

Oui, mais du point de vue du développeur/éditeur (celui qui prend des risques donc), ce n'est pas pareil. Dès que le jeu va être un peu connu, des parasites peuvent apparaître et vendre le jeu rebrandé. C'est vrai pour le jeu proprio sans DRM ou pour le jeu libre, mais dans le 1er cas il y a des recours, dans le second c'est explicitement autorisé. Or comme tu l'as dit toi-même, les joueurs s'en fichent, en tout cas aujourd'hui, que le jeu soit libre.

Bilan, le fait de faire un jeu libre apportent des soucis supplémentaires (moins de protections contre les parasites, même si on ne peut pas s'en débarrasser dans tous les cas), mais pas de ventes supplémentaires. D'un point de vue strictement économique c'est malheureusement compréhensible.

Personnellement je pense être un libriste plus que convaincu (j'ai fait beaucoup d'effort pour aujourd'hui vivre de mon logiciel libre, travailler pour une boîte classique qui fait du proprio aurait été bien plus facile et rémunérateur), pourtant même moi je ne prendrai pas le risque de faire un jeu entièrement libre si c'était pour en vivre. En revanche j'opterai pour des assets proprios:

• soit pendant la période de commercialisation (j'entends par là quelques années tout au plus).
• soit pourquoi pas une campagne de financement participatif dont l'objectif serait la libération des assets (à la manière de l'OpenBundle, histoire de voir ce que les libristes sont vraiment prêt à donner pour avoir des assets libres.

Le 4ème lien fait mention de "CreamCRM" => CremeCRM.

Très bonne question.

Si ça ne tenait qu'à moi, on serait déjà passé à Python 3. Mais :

• on tient à ce que Creme soit installable facilement sur une Debian stable ; parce que c'est ce qu'on a sur nos infrastructures, mais aussi que ça représente assez objectivement l'inverse du bleeding-edge, donc ça sera installable à peu près partout.
• je souhaite passer à Python 3.3 au minimum, parce qu'en dessous ça semble plus pénible de migrer depuis Python 2 ; or la Debian 7 vient avec Python 3.2.

Donc on ne passera à Python 3 qu'avec la prochaine Debian stable ; et encore pas immédiatement, vu que par exemple Creme 1.4 tourne sur Python 2.6 car on a encore des Debian 6 sur certains serveurs, et on ne demandera Python 2.7 qu'avec Creme 1.5 (j'ai déjà pas mal de patches en préparation). Ça n'est donc pas pour tout de suite, mais ça va arriver, et ce n'est pas l'envie qui manque !

Je pense qu'on sautera le pas directement, on ne gérera pas à la fois Python 2 & 3, car pour un logiciel "final" (pas une bibliothèque) ça n'a pas beaucoup d’intérêt (en plus de nécessiter plus de travail). Je verrai bien ce passage à l'occasion de Creme 2.0, mais rien n'est décidé à ce niveau.

Sinon dans nos dépendances en effet rien n'est bloquant techniquement à part pygraphviz, mais c'est une dépendance très dispensable, qui pose déjà des problèmes (pas installable sous Windows), et dont je me débarrasserai quand j'aurai le temps.

Merci pour les liens.
J'avoue n'avoir rien compris au PDF sur LRA, il m'a l'air destiné au gens connaissant bien le fonctionnement interne et les nomenclatures de GCC. Tant pis.

En revanche le lien sur REE était sympa. Voici un résumé pour les lecteurs pressés :
Dans certaines situations le compilateur génère des instructions inutiles (car le boulot a en fait déjà été fait), ou bien 2 instructions qui peuvent être fusionnées en une seule. C'est notamment le cas sur x86-64 lorsqu'une valeur 32bits est chargée dans un registre 64bits, et que le processeur étend implicitement cette valeur avec des 0 dans les 32 autres bits (d'où le nom "extension instructions"). Cette passe va donc éliminer les instructions inutiles ou bien fusionner 2 instructions. Le gain de performance est apparemment assez faible sur les processeurs avec ré-ordonnancement dynamique, mais peuvent aller jusqu'à 10% sur Atom par exemple.

dans sans avoir à suivre les autres directives

Le backend AArch64 profite également de l'activation de la passe d'optimisation

Outre les nombreux changements liéS

Sinon très bonne dépêche ; j'aurai bien aimé une petite explication pour REE (Redundant extension elimination) et LRA (local register allocator), ça m'avait l'air intéressant.

Pour la peine, est-ce qu'ils n'auraient pas gagné en perf en faisant une distinction entre int et Integer comme en Java ?

Ça marche en Java (et C#) grâce au typage statique ; le langage sait s'il faut convertir un int en Integer (ou l'inverse) car il connaît le type des variables et celui des paramètres des méthodes. Mais comment faire en Python ? Ta fonction "def foo(a): […]" comment peut elle savoir si elle reçoit de la part de l'appelant un int ou un *PyObject (au sens C) ? Tout repose sur le fait que les variables sont toutes des *PyObjects, et qu'ensuite on applique le duck typing.

A noter quand même :

• Dans CPython, y a pas mal d'endroits où la VM prend des raccourcis quand elle rencontre des types de base. Par exemple avec "if a:", la méthode __nonzero__/__bool__ de "a" n'est pas appelée en cherchant dans la virtual table lorsque Python s'aperçoit que "a" est un *PyInteger ou une *PyList par exemple, car en pratique on appelle rarement "if" sur des instances classes utilisateur. Python reste évidemment lent, mais il le serait beaucoup plus s'il était codé naïvement.
• PyPy est capable de générer du code machine travaillant avec des simples int lorsqu'il s'aperçoit que c'est possible et pertinent ; par exemple il va utiliser une version spécialisée de liste si elle ne contient que des *PyInteger.

Non ça ne marche pas (mais c'était drôle quand même). Il se trouve que dans CPython (mais a priori c'est une question d'implémentation, ce n'est pas portable), les entiers jusqu'à 256 sont des singletons (ils sont pré-alloués en plus me semble-t-il). Chez moi (Python 2.7.6):

> a = 256
> b = 256
> a is b
True

Mais

> a = 257
> b = 257
> a is b
False

Donc on n'a pas "==" et "is" qui sont équivalents de manière général (et donc pas avec "0xdeadbeef" en particulier).

Il y a un problème avec ton 2ème exemple. On rentre dans le bloc else d'un for (ou d'un while) à la fin de l'itération, sauf si on est sorti avec un break justement. Ton bloc else ne peux donc pas être le traitement d'erreur tel que présenté.

Sans parler des cas très pointus où le GC va permettre, en défragmentant le tas, d'améliorer la localité des données et ainsi améliorer les performances (parce qu'il faut quand même que cet avantage surpasse l'inconvénient qu'est l'arrêt de la tâche), un GC pallie le problème des cycles de références, qui vont engendrer des fuites mémoires même avec des pointeurs intelligents. C'est pour ça par exemple qu'avec CPython ou en PHP, il y a un GC qui s'occupe des cas problématiques (les cycles donc), même si le refcounting fait la majorité du boulot.

Sinon sinma a bien répondu juste au dessus je pense, à savoir que le GC est par tâche, et ne s'occupe que des références qui le concernent, ce qui fait qu'on est loin d'un langage entièrement sous GC.

Je rajouterai que:

• le runtime est entièrement remplaçable/supprimable : zero.rs est utilisé par les gens qui font des noyaux et enlève le runtime classique et la possibilité d'un GC.
• la bibliothèque standard n'utilise pas le GC (ni de refcounting je crois).

Du coup la logique du "tu payes pour ce que tu utilises" est vraiment poussée loin.

En même temps il s'agit dans tous ces cas d'exprimer f(n+1) grâce à f(n), c'est conceptuellement très proche. Après quelle est la manière la plus efficace de l'enseigner; je ne sais pas. Mon prof en prépa qui nous a enseigné la récursivité, a immédiatement fait le rapprochement avec la récurrence et ça marchait bien, mais il y sûrement d'autres approches possibles. Tant que c'est bien enseigné ça me va.

Pourtant on voit ça pour le bac, il me semble. Faire des dérivées de logarithmes et d'exponentielles, j'en ai fait en Bac STL Chimie, il doit bien y en avoir des restes dans toutes les filières à vocation scientifique, non ?

Les gens qui atterrissent en BTS info ont, j'ai l'impression, souvent du mal avec la théorie, sinon ils seraient allés en IUT/prépa/Fac. Je ne serais pas étonné qu'ils sachent trouver le bouton 'log' sur leur calculatrice pour appliquer une formule, mais trouver une complexité algorithmique nécessitera sûrement un rappel.

Malgré un passage par Math Sup, je n'ai pas le souvenir du concept de récurrence (mais c'était il y a 15 ans). Mais ça ne m'a pas empêché de comprendre immédiatement le concept des fonctions (programmatiques) récursives. D'ailleurs, peut-être que la factorielle est une fonction (mathématique) récurrente ?

Tu n'a jamais fait de démonstration par récurrence ? J'ai fait une prépa de 1999 à 2001 et c'était au programme ; en fait je suis même à peu prêt sûr de l'avoir vu aussi au lycée en S. Peut-être que ça t'a aidé à comprendre au début la récursivité (que tu utilises encore régulièrement j'imagine) même si tu l'as oublié depuis.

Je suis bien d'accord qu'il faut des bases, c'est pourquoi je suis un fervent opposant à la mode d'enseigner la programmation par le Basic à la mode (en ce moment c'est Python).

Je suis partagé à ce sujet. Pas mal de hackers de talent, ou moi, ont commencé par le Basic, qui leur a fait découvrir la joie de faire un programme qui vit sous ses yeux ; au final le goût de la rigueur, de la théorie, vient avec le temps (tout comme j'estime n'avoir fait des Maths qu'en prépa, avant c'était du bricolage avec des nombres). Les gens qui ne s'orienteront pas vers l'info auront vite tout oublié de toutes les façons (mais peut-être que l’informatique leur paraîtra moins mystérieuse, ce qui est déjà bien), et dans les filières info d'autres langages seront enseignés. Mais on s'écarte du débat :)

ce sont les carences en orthographes et grammaires qui sont les plus graves.

Je suis d'accord, mais le problème c'est que ces carences auraient du être éradiquées bien avant, genre au collège. Que ce soit au BTS de corriger ça indique un vrai problème, et ce n'est pas au BTS de le faire ; le français est indispensable dans toutes les filières, et ce bien avant le lycée.

néceçaires

tu parlais d'ortaugraf c'est ça ? :)

je ne vois pas plus utile

Savoir ce qu'est un logarithme ou un polynôme pour comprendre la notion de complexité algorithmique me semble indispensable (et je sais d'expérience que les gens sortant de BTS ne savent pas ça en général). Et même avant ça, comprendre la notion de récurrence aide à saisir comment raisonner avec la récursivité ; ça me semble assez basique et pourtant c'est une carence répandue. Si on veut faire des programmes un tant soit peu correct, il faut faire un minimum de théorie. Des tas de non informaticiens pondent le logiciel interne (boiteux) de leur entreprise en Windev, mais sans aucune approche scientifique ça va être difficile aux gens sortant de BTS de se démarquer des premiers.

Si ma mémoire ne me fait pas défaut, on peut lancer Blender en lui donnant en paramètre un script Python à exécuter immédiatement, ce qui permet de faire basiquement ce que tu demandes.

Après je ne sais pas si l'API Python actuelle (2.50+) permettrait d'attendre des commandes (activement ou passivement), venant d'un pipe/fichier/socket, afin de piloter plus finement, et interactivement, Blender depuis une console classique. Je suis à peu près sûr en revanche que cela n'était pas possible avec la vielle API (2.49 et avant).

Dans mon Gimp (2.6), dans Filtres/Flou tu as un effet 'Pixéliser', qui semble faire ce que tu veux.