GuieA_7 a écrit 675 commentaires

Python, ruby, C, C++ : erreurs dans les calculs simplissimes ex 0.1 + 0.7 = 0.79999999

Dans ces langages, les nombres à virgule flottante sont mappées sur ceux gérés par le processeur (avec les erreurs inhérentes à ce type de données), et on les utilise pour des questions de performances quand les erreurs sont acceptables (ex: 3D), et c'est très bien comme ça.
Maintenant en Python par exemple tu as dans la bibliothèque standard (donc ça fait partie du langage) le type Decimal qui fait ce que tu veux ; pour les autres des bibliothèques qui font la même chose existent j'imagine.

Dans Django (framework web python) ce type Decimal est fourni de base pour les modèles sauvés en base de données. On s'en sert dans CremeCRM pour la facturation par exemple, et ça fonctionne nickel.

Maintenant les logiciels de gestion ne sont franchement pas les plus exigeants de manière générale, dans le sens où n'importe quel langage que tu apprécie peut faire l'affaire, et les problèmes que tu cites semble être des détails tout à fait anodins. Aucun des langages n'est parfait, mais une chose est sûre, si tu en créé un il sera bien plus mauvais que n'importe lequel des langages que tu as cités.

Je ne suis pas vraiment d'accord avec toi, mais ton commentaire est constructif cette fois, ça va être intéressant de discuter.

Les chances que cela soit de l'incompetence technique sont infinitesimales.

(Je ne peux pas trop en dire, mon identité n'étant pas un secret) tu sous-estimes le fait que dans nos instances dirigeantes (ou à la tête de grandes entreprise, je côtoie les deux) :

• des tas de gens agissent pour leur propre intérêt, pas le bien commun, quitte à couler un projet qui marche pour se faire mousser, ou à l'inverse mettre en avant une solution boiteuse en échange de service, par exemple.
• je ne sais pas si c'est typiquement français, mais ici on voit peu de techniciens dans les sphères dirigeantes. Les hiérarchies ont un niveau technique très faible, et se font facilement rouler par des roublards (des gens de leur staff aux dents longues par exemple), ou bien prennent des décisions techniques aberrantes par orgueil (ils pensent y comprendre quelque chose).

Ces choix sont dans l'enorme majorite des cas des compromis apres reflexion, de rares fois des choix evidents, et tres rarement une decision totalement stupide.

Je suis d'accord pour le compromis (en technique il est toujours question de compromis).

Mais surtout même les décisions stupides le sont rarement assez pour être fatales, ça ne veut pas dire que c'était de bonnes décisions pour autant. Par exemple un de nos ex-prospects, une école faisant partie d'un groupe d'écoles, c'était fait imposer un logiciel par ledit groupe. Ce logiciel avait été choisi car c'était le leader du secteur global, mais l'école ne l'utilisait pas, car il ne correspondait pas vraiment au besoin. L'école s'est ensuite fait imposer en remplacement un second logiciel (le leader au niveau des écoles), mais là encore il n'était pas très pertinent et restait inutilisé. Mais bon au final les gens s'en sortait quand même avec du bon vieux papier (et sûrement des fichiers excel). Je pense que cet exemple n'est pas isolé.

Mais cette habitude qu'on certains ici de mettre au pilori automatiquement toute decision qui va dans le sens de MS, sans rien savoir de la situation sinon leurs prejuges pourris, est vraiment a vomir.

Oui j'ai aussi horreur des fanboys/hateboys de tous bords, mais de manière générale je trouve que le MS-bashing se fait moinser rapidement. Et dans le cas qui nous intéresse on a quand même des gens qui sont partis en masse, dégoûtés par leur hiérarchie, et ici en France les mauvais techniciens préfère généralement rester planqués. Je ne peux tout de même pas me prononcer sur la prétendue incompétence de l'armée, mais on a plus d'arguments factuels que s'il s'agissait d'un simple MS-bashing je trouve.

Ce qui est drôle c'est ce que tu fais exactement ce que tu dénonces, à savoir affirmer de manière arrogante. Si encore tu avais dit "ce n'est pas forcément de l'incompétence".

Des gens en interne nous donnent un témoignage ; leurs avis n'est pas pour autant 100% objectif, mais ils connaissent à priori mieux le dossier que toi. Tu affirmes que ça ne peut pas être de l'incompétence, comme si ça n'arrivait jamais qu'une hiérarchie n'ayant pas de compétence technique prenne des décisions techniques (à l'encontre de leur staff) ; personnellement je l'ai vu plusieurs fois.

Ça me fait un peu penser aux Exceptions (sans les problèmes de sûreté) mais la syntaxe est quand même assez différente et… perturbante. Ça me parait plus souple que les exceptions, mais à voir à l’utilisation.

Si ça ressemble visuellement aux Exceptions, la sémantique est assez différente, puisqu'il manque la fonctionnalité la plus puissante (mais aussi la plus controversée), à savoir la remontée au travers de la pile (et donc des appels de fonctions). En effet dans Rust, le gestionnaire de conditions est exécuté à l'endroit du raise, et ne constitue pas une autre façon de sortir de la fonction.

Bien utilisée, la remontée dans la pile permet d'écrire du code court et d'éviter pas mal de code boilerplate. Malheureusement ce comportement casse la sémantique de Rust, qui ne pourrait plus fournir ses garanties.

Je suis assez sceptique sur l'utilité des conditions, parce que si le discours est qu'on peut coder le comportement que l'on veut face à une erreur, j'ai l'impression qu'il faudrait plus ou moins penser à tous les comportements possibles, afin que la signature du handler permette dans les faits de gérer l'erreur comme on le veut. Je me dis que dans la pratique on va peut-être la plupart du temps finir par gérer l'erreur d'une manière figée et retourner un Option/Result.

Mais j'espère me tromper, et je vais faire confiance aux développeurs de Rust qui ont fait du super boulot pour le reste, donc y a pas de raisons ! Et Rust possède à côté d'autres outils permettant d'éviter le boilerplate.

Mon précédant jeu est en "pause" ; le choix de notre moteur 3D (JME) s'est avéré mauvais à l'usage ; ça a beaucoup ralenti le développement, et la motivation est partie. Mais j'ai attaqué un jeu un peu moins ambitieux depuis (avec Ogre), dans lequel je peux réutiliser en grande partie mes assets ; je vais essayer d'avancer substantiellement pendant mes vacances.

Autant GIMP peut clairement me servir pour SàT (icônes, tutos, etc), autant Blender c'est juste pour le plaisir

Il y a quelques années j'avais utilisé Blender pour faire des icônes avec un rendu assez réaliste pour un prototype client, et ça marchait plutôt bien. Avec un peu d'imagination ça peut être un outil très utile pour de la 2D ; on pourrait aussi imaginer des avatars sous la forme de sprites animés etc….

Il me semble que dans une autre vie tu as eu droit à une formation Blender… :)
Mais le problème c'est que son IHM a beaucoup changé depuis quelques années (pour le plus grand bien), et que quand on en a pas fait depuis longtemps le retour peut être difficile.

Sinon, tu as l'intention de mettre de la 3D dans SàT, ou c'est pour autre chose ?

Hum c'est quand même loin d'être aussi simple. Phil Fish n'est pas un dev, c'est le créateur de Fez, il code, fait les graphismes, le game design et le level design, et à plein temps. Même si Fez était fini à 50%, la communauté du libre a-t-elle des Phil Fish en puissance pour faire les 50% manquants ? Je dirais non malheureusement, sinon il y aurait des tas de jeux libres de la trempe de Fez.

Il ne suffit de balancer un truc pas fini en libre pour qu'une armée de volontaires arrivent et fassent un produit fini. D'ailleurs il y a des jeux libres qui finissent dans l'oubli faute de volontaires (genre Wormux) ; et je pense que si tu laissais tomber Newton Adventure aujourd'hui, personne ne le continuerait avec la même dévotion que toi (le jour où il aura une grosse communauté de fans ça sera différent).

Certains projets font des choses superbes avec bien bien bien moins que ça

Effectivement le projet que tu pointes demande très peu je trouve. Mais dans le cas de 0 A.D, il faut à mon avis prendre en compte que le jeu au final est libre et gratuit. Un jeu propriétaire kickstarté est vendu lorsque son développement est terminé ; le financement sert à payer les développeurs pendant le développement initial avec des petits salaires, et ils se rattrapent (si ça marche évidemment) par la suite en vendant leur jeu. Ce n'est pas le cas pour 0 A.D.

En tout cas va falloir qu'ils communiquent mieux s'ils veulent se donner une chance. À la fois sur leur indiegogo et en faisant de la promo extérieure (sites de JV et d'actus du libre)

Oui, vu la qualité du jeu et le peu d'argent récolté pour le moment il semble qu'il faille améliorer la communication du projet. Mais il est clair que l'aspect libre ne touchera qu'une petite frange de joueurs malheureusement.

Je sais bien que les joueurs libristes sont une niche, mais j'espère que cette niche peut quand même financer la création de jeux de qualité.

Tout d'abord même si je n'ai pas encore pris le temps de tester ton jeu, il a l'air très sympathique.

En revanche, même si j'imagine qu'on t'a déjà fait la remarque, comment comptes-tu gérer la ressemblance visuelle avec Pokemon ?? Que soit ce qui semble être une Pokeball au pixel prêt, l'interface des combats où même le sprite des héros, la similarité avec la licence de Nintendo est flagrante.

Tant que ton jeu restera confidentiel ça ne sera pas un problème, mais s'il devient un peu connu (ce qu'on ne peut que te souhaiter), tu vas avoir des ennuis, big N n'étant franchement pas aussi gentil que ses mascottes. D'autant que tu dis vouloir faire de l'argent avec ton jeu.

Tu parles de beta testeur, pour un jeu en pre-alpha ; tu cherches un alpha testeur ? Au final, dans ta tête, à combien de pour-cents évalues-tu la finition du jeu ? Parce qu'en phase de beta (classiquement en tout cas) le jeu est proche du résultat final, mais là à mon avis il va falloir au moins repenser l'habillage du jeu (ce qui fait beaucoup de boulot).

Faire un jeu où des personnes peuvent capturer des créatures et les faire combattre, ça n'est pas un problème, il y en a déjà un certain nombre. Mais il va falloir trouver un univers qui s'éloigne un minimum de Pokemon. Je ne sais pas, remplaces les pokeballs par un aspirateur à monstres, une épuisette magique, des cartes à jouer mystiques ; fais des créatures inspirées des Korrigans, des Yôkai (bon pour ce dernier j'ai vu un jeu qui va bientôt sortir et qui le fait), des dragons, ou des objets du quotidiens (ce ne sont que des exemples trouvés en 10 minutes hein).

Je n'ai pas encore joué, mais y a-t-il des mécaniques qu'on ne trouve pas (à ma connaissance, j'ai juste fait un épisode GameBoy il y a 15 ans) dans ton inspiration originale ? Comme le fait de fusionner 2 monstres, qu'ils aient des caractéristiques uniques (genre 2 Marmottes Infernales de niveau 36 qui ne seraient pas identiques), des blessures persistantes etc…

En tout cas bon courage pour la suite.

try:
    prev_feed = loaded_feeds[url]
except KeyError:
    prev_feed = None

prev_feed = loaded_feeds.get(url)

if not list(set(item['taglist']) & set(feed['wotags'])):

if not set(item['taglist']) & set(feed['wotags']):

if item["updated_parsed"] == None:

if item["updated_parsed"] is None:
voire:
if item["updated_parsed"]:

(pas équivalent si jamais __eq__ ou __bool__ a été définit, mais je crois que là c'est bon).

Le gros avantage c'est que tu sais que cette méthode n'a pas d'effet de bord. Seul ton code accède à ce dont il est le seul à avoir besoin.

Tout à fait d'accord, vu que tu répète ce que j'ai dit (peut être pas assez clairement ?). Cette fois, le hack était très peu risqué et avait d'énormes retombées en terme d'élégance dans le reste de l'application, notamment en permettant d'économiser beaucoup de lignes de code. Mais d'autres fois le compromis est beaucoup moins favorable, et je vais faire autrement. En technique, on est sans arrêt dans le compromis.

Mais dans le fond on est d'accord je pense, donc pas la peine de chipoter pendant 3 heures.

Je ne connais pas les refinements de ruby, mais les classes d'extension de C# d'après ce que l'on voit dans le lien plus haut ne permet que d'ajouter des choses, donc les collisions se voient déjà bien mieux.

Je ne ferai pas de journaux sur Rust en disant que j'ai hâte de m'y essayer si je pensais que l'approche dynamique de Python était l'alpha et l'oméga.

Dans n'importe quel modèle objet tu peut hériter des classes en question, c'est à mon humble avis nettement plus propre car une fois que tu es construis ton objet tu sais qu'il est fini, il faut pas en plus que tu lui ajoute des choses en plus pour le finir. De plus c'est un énorme effet de bord. Si tu passe cet objet en paramètre d'une méthode celle-ci peut écraser ta modification. Enfin ça n'apporte que du sucre syntaxique face à garder la méthode séparée (sachant que garder la méthode séparée permet de ne pas créer d'effet de bord).

Mon problème est que ce n'est pas moi qui instancie les-dits objets, et donc qui choisit leur classe. Donc je pouvais :

Méthode 1:
- Copier toute la machinerie d'instanciation, (et donc la mettre à jour quand Django évolue).
- Dériver de la classe de base pour faire ma propre classe de base, puis refaire toutes les classes filles que me fournit Django (des dizaines). Même remarque sur la maintenance.
- Utiliser ces nouvelles classes dans mon code, et dupliquer les classes fournies en contributions à Django qui utilisent les classes de Django, et pas les miennes forcément.

Méthode 2:
Maintenir les informations supplémentaires que je veux dans un arbre d'objets en parallèle. Ça c'était envisageable (contrairement à la méthode 1), mais ça restait moche, pas très objet pour les utilisateurs du code.

Ma méthode permet d'avoir un résultat élégant (comme si c'était intégré à Django de base), et sans écrire/dupliquer des pans entiers de Django. Je pense donc, dans la mesure où en des années de développement sur ce projet j'ai fait un tel "hack" 2 fois, qu'on se situe dans le domaine du hack intelligent (dont on se serait bien passé mais qui sauve la vie).

Mais oui j'ai fait attention de prendre des noms qui limitent la probabilité de collisions, et mon code est super bien testé (pas pour ce hack en particulier hein, de manière générale). Et je le répète c'est à utiliser en dernier recours.

Mais si Ruby propose ses refinements, C# ses classes d'extensions (je crois), c'est que c'est un vrai besoin. Pas dans le sens où sans ça on ne pourrait pas écrire certains programmes (Turing complete toussa), mains dans le sens où cela apporte une nouvelle solution, meilleure que les autres (ou moins mauvaise) que les autres dans certains cas.

Mes collègues qui font du Java à côté de moi, confrontés au même genre de problème, sont obligés de faire des trucs bien plus crades (surcharge de package, introspection pour modifier des trucs private…).

Mais surtout, je trouve que pour un usage qui devrait être quasi inexistant, on explique cela bien trop tôt. Comme si c'était une fonctionnalité de base du langage.

Ça c'est un autre problème, moi je dis juste que ce n'est pas inutile. Maintenant si je dois faire la promotion de Python, ce n'est pas dit que j'en parle en effet.

Ceci dit, je ne vois pas pourquoi je devrais considérer une variable différemment selon que c'est une constante ou non. Dans le cas de Python, c'est trompeur, puisque les constantes n'existent pas.

Marrant, à partir du même constat technique, je fais la conclusion inverse. Le manque de const en Python est éventuellement un problème ; mais si de toutes les façons tu fais un projet en Python, et que tu as besoin d'une constante, pourquoi risquer de te tromper toi-même en ne la mettant pas en majuscule ? Si en faisant la revue de code d'un de mes dev il me fait un module.MYCONST = blabla, je le vois immédiatement et il a droit a coup de pied au cul (virtuel). C'est sûrement pourquoi en 10 ans de Python ce n'est pas quelque chose qui m'a provoqué un seul bug je pense (d'autre trucs oui, mais pas ça).

Je rejoins le commentaire de xcomcmdr, ça fait partie des outils à manipuler avec précaution et le moins possible (comme l'assembleur inline en C par exemple), mais qui peuvent te sauver la vie.

Sur ton propre code c'est en effet assez inutile, en revanche même les meilleures bibliothèques ou frameworks ont des limites qui peuvent te gêner. Forker un framework de 100K lignes de code parce qu'il manque une méthode dans une classe de base (pour ton usage en tout cas) c'est un peu pénible, et maintenir un patch par dessus ça rend ton soft pénible à installer pour tes utilisateurs.

Je fais ça genre 2 fois dans mon soft de 40K lignes de code pour modifier légèrement Django (derrière j'ai ma batterie de tests unitaires qui va bien) ; ça me semble raisonnable, et la moins affreuse des solutions (ça m'économise des milliers de lignes de code).

En même temps ton commentaire est vraiment évasif, on ne sait pas si tu parles d'esthétique, d'ergonomie, de simplicité, d'"intuitivité". As-tu juste regardé les captures d'écran (pas forcément à jour je crois), as-tu testé la démo, as-tu installé ta propre instance ?

Si tu parles d'esthétique, le 1er thème laisse en effet rarement indifférent (on aime ou on déteste), mais comme les retours positifs sont majoritaires j'aimerai le garder. Le 2ème thème a été créé pour ceux qui préfèrent les apparence plus classique ; mais tu ne le verra pas dans les screenshots (il te faudra tester la démo par exemple).

Autant dire que tu sembles plus critique vis à vis du travail des autres que de tes commentaires.

Merci pour toutes remarques pertinentes.

Pour revenir dans le sujet spécifique de Creme, votre changement de thème ne fonctionne pas sur votre version de démo (ou alors les deux thèmes sont strictement identiques)

Non, tu as raison il y a un problème dans la version déployée, au niveau des assets statiques je pense (les icônes du 2ème thème sont les bonnes, mais pas le CSS), et je viens de le signaler à l'administrateur.

Avec le peut que j'ai pu voir, je pense que tu peut trouver pire …

Ce n'est pas uniquement parce que j'ai fait en grande partie les graphismes, mais oui en effet parmi les CRM un peu connus on peut trouver bien pire, même si évidemment ce n'est pas une raison pour ne pas faire mieux que ça (j'y reviens après).

Mais la réponse tient probablement dans le fait que ce n'est souvent pas considéré comme important (que ce soit par les devs ou les clients, d'ailleurs). Et que du coup c'est fait à l'arrache / repoussé au dernier moment …

Oui tu es assez dans le vrai. Nous sommes un très petite boîte qui a créé le logiciel depuis zéro, et qui en vit (même si nous avons d'autres projets à côté, plus alimentaires). Or pour être compétitifs (le CRM est un marché très concurrentiel, et on a des concurrents bien plus gros/vieux/riches), nous avons du nous concentrer sur les fonctionnalités, en nous débrouillant avec nos petites ressources. Et je pense que sur ce point c'est plutôt réussi, puisque nous avons un certain nombre de killer features (ex: récemment une dame ayant assisté à une de nos présentations nous a avoué avoir pris SalesForces "parce que c'est le plus connu", et était dégoûtée de ne pouvoir importer ses fichiers excel [ou alors elle n'avait pas trouvé]). Si nous avions privilégié l'esthétique, ça aurait forcément été au détriment des fonctionnalités, nous perdrions sûrement à chaque fois que nous sommes en concurrence pour un client (ce qui est presque toujours le cas), et il y aurait juste un CRM mort de plus.

Autre point intéressant je pense : dans l'équipe il y a une personne balaise en interface utilisateur, mais elle n'a pu commencé à bosser sur Creme que récemment, car occupée sur un projet alimentaire en parallèle. Il a par exemple bossé sur UN formulaire (l'application en contient sûrement plus d'une centaine) pendant une semaine ou deux, à raison de 12h par jour, pour faire un des prototypes dont je parle dans la dépêche. Il s'agissait de retravailler un formulaire fait il y a 3 ans, et qui faisait son travail de manière convenable, mais perfectible ; mais avec les années c'est devenu un des points de frustration prioritaire. Cette 1ère version avait du prendre à l'époque un jour de boulot, et ce code a rempli son œuvre tout ce temps; maintenant que nous avons une application complètement comparable à la concurrence, on peut enfin prendre le temps que nous n'avions pas il y a quelques années. Mais ce travail d'interface est réellement énorme, compte tenu de la taille de l'application.

Donc même si nous sommes complètement conscients qu'il y a des millions de choses à améliorer, et qu'il est normal que nous acceptions les critiques (nous les prenons en compte, mais on doit faire des choix), je trouve dommage de se cantonner à des remarques aussi peu constructives que "c'est moche". Pour le coup, les tiennes sont bien argumentées.

Accessoirement, il me manque un élément que je trouve vital pour de la configuration, c'est le retour à l'utilisateur.

Oui, le combo de changement de thème est clairement raté de ce côté là ; je vais essayer de prendre le peu de temps qu'il faut pour l'améliorer pour la 1.4. Pour notre défense c'est un peu un cas à part en termes d'ergonomie, ce que tu ne peux pas voir dans la démo, car tu n'as pas accès au reste de la configuration histoire de ne pas pouvoir tout saccager.

Autre point: "Calendrier de démo par défaut", la checkbox "Non" dans "Est public ?" n'est pas clickable. Si ce n'est pas un bug, ça me gène qu'il n'y ait pas une indication claire qu'elle est désactivée (grisage ou autre). Le bilan, c'est que je ne sait pas si c'est un bug ou si c'est voulu …

Dans l'application, les booléens sont représentés par des checkboxes (désactivées) avec un label Oui/Non. Mais c'est peut être une mauvaise idée au final (si tu trouves ça confusant c'est mauvais signe). Si tu veux modifier cette ligne de configuration il faut cliquer sur le petit stylo au bout de la ligne.

Dernière chose: vous n'utilisez pas la place verticale qu'il peut y avoir à l'affichage, c'est dommage parce que du coup les blocs sont collés les uns sur les autres, et la page fait un peu brouillonne.

Certaines vues de détail contiennent classiquement une quinzaine de blocs. On peut certes enrouler les blocs (à la manière de pas mal de Window Manager) pour gagner de la place, mais ça fait beaucoup d'informations à afficher. Et souvent les gens veulent scroller le moins possible pour voir l'information qu'ils cherchent. Mais oui c'est difficile d'être compact et lisible.

Lui a parlé d'inutile, toi d'inutilisé, ce n'est pas la même chose.

Exactement. Sachant qu'on peut quand même partager de la mémoire entre les tâches (via les ARC - Atomic Reference Counter - par exemple) ce qui est utile aussi, par exemple pour partager une grosse image dont les différentes parties vont être traitées en parallèle. Mais on va vraiment pouvoir limiter le nombre de ces objets au strict minimum.

Ça ne remplace pas les processus systèmes : on ne peut pas faire de la séparation de privilèges, si une tâche plante toutes les autres plantent aussi du coup (ce qui est censé être rare, vu que le langage, une fois finalisé, ne devrait pas permettre les segfaults, mais ça peut arriver si on se lie à une lib C). Mais ça facilite beaucoup la programmation avec des threads, comme Go ou Erlang, chacun avec ses avantages et inconvénients.

le premier compilateur de RUST a été écrit en OCaml, il a été bootstrapé depuis.

J'ai hésité a en parler, mais j'ai eu peur que ça fasse trop d'informations d'un coup. D'ailleurs si le code généré est encore perfectible, le code du compilateur lui-même est de l'aveu des développeurs Rust un exemple à ne pas suivre en terme de code Rust, car rempli de vieux patterns considérés comme mauvais dans les versions récente du langage.

Bref, je pense que Rust peut raisonnablement s'approcher du 1,2 plus lent que c++

Oui tout à fait d'accord, c'est bien pour ça que je suis aussi enthousiaste : j'espère pouvoir délaisser Python et C++ sans avoir l'impression d'avoir fait trop de compromis.

J'ai vu passer plusieurs benchmarks, et si souvent il s'en sort très bien, il y a quelques cas pathologique où Rust est bien plus lent ; mais s'agit de problème localisés dans l'implémentation encore jeune. Au final, j'ai mis 5 fois plus lent comme un compromis (j'aurai pu le dire mais il était tard), histoire de ne pas tomber tout de suite dans le fanboy-isme, j'attends la 1.0 pour ça !

Je ne pense effectivement pas que le crowdfunding soit adapté à ton problème, je ne faisais que répondre sur la façon dont le crowdfunding fonctionne.

Je rejoins les gens qui t'invitent à fermer certains modules (particulièrement ceux qui sont en rapport avec des produits propriétaires) et d'arrêter de faire du support top moumoute gratuitement. Par exemple, je réponds aux questions sur le forum de mon logiciel libre (qui me fait vivre) quand j'ai du temps libre.

Si j'ai bien compris le principe, les fonds ne sont libérés qu'après développement.

Non les fonds sont libérés à la fin de la campagne de financement, si l'objectif de base est atteint ; dans le cas contraire les micro-financeurs sont remboursés.

Sinon comment feraient les porteurs de projet pour mener leur projet à terme (et payer les gens, acheter du matos etc…) ? Ils devraient faire un vrai emprunt à la banque ? Ça n'a pas de sens.

C'est comme du financement classique, le projet peut tout à fait capoter, et les financeurs ne rien obtenir à la fin, ou un truc à moitié fini (un peu comme avec Diaspora).

Dans l'absolu il existe des SCM spécialisés dans la gestion d'assets. J'en ai même vu passé un qui était libre, mais je sais pas ce qu'il vaut.

Il est clairement plus pratique de commencer avec du code "calculatoire", les IHM sont pénibles à tester et souvent on fait l'impasse dessus.

Ce qui est souvent mal compris dans le TDD, c'est qu'il ne faut pas écrire 150 lignes de tests avant de commencer le vrai code (c'est chiant et pas hyper efficace). Il faut écrire un test avec une assertion, faire péter le test, coder pour faire passer le test de la manière la plus simple, puis recommencer le cycle. C'est assez déroutant au début, parce que les premiers tests qu'on écrit ont vraiment l'air stupide, genre:

def test_empty():
     assertEqual([], sort([]))

def sort(l):
    return []

mais on comprend l’intérêt plus tard quand on code les cas vicieux et que ces assertions détectent une régression.

Du coup, pour détecter une merde dans le déploiement c'est assez pratique, je dois l'avouer, alors qu'il ne me semble pas que le TDD permette de vérifier que le problème vienne de l'installation de ton application, puisque les tests ne sont pas inclus dans le binaire (je ne crache pas sur TDD, au contraire, je ne fais que demander ce que tu en penses).

Le TDD n'empêche évidemment pas de mettre des assertions dans le code, ainsi que des logs, qui sont en effet bien plus indiqués pour vérifier que l'installation est correcte.

j'imagine que tu peux comprendre qu'écrire 4 fois plus de code de test par classe que de code réel me semble trop lourd.

Je peux le comprendre, et ta façon de penser est naturelle pour quelqu'un n'ayant pas pratiqué le TDD. Mais là où tu te trompes c'est qu'on s'en fout du nombre de lignes, ce qui compte c'est le temps que tu mets à écrire ta feature correctement (si tu torches un code vite fait plein de bugs, il faut compter tout le temps de debug, ainsi que le temps que tes collègues ont perdu etc…).
Je t'ai donné un vrai exemple tiré de mon expérience ; mon collègue pensait réellement gagner du temps en n'écrivant pas de test. La réalité c'est que j'ai quand même écrit plus de code utile que lui pendant le même temps (le nombre de lignes de code n'est pas une super métrique, mais en l'occurrence mon code était bien factorisé et objectivement bien meilleur pour le même prix).

Sachant que la moyenne de mes méthodes ne dépasse pas les 15 lignes (mes "algorithmes" se situent en fait plus dans le diagramme de classes, chacun s'occupant uniquement de ses affaires. Ca n'évite pas les bugs, mes le code est plus lisible pour moi, et 20 fois plus simple à réutiliser),

Tu n'a pas à te dévaloriser parce que tes fonctions font rarement plus de 15 lignes : c'est normal et c'est pareil pour la plupart des gens ; ou bien ça devrait l'être, et la super fonction de la mort de 300 lignes peut être réécrite proprement en 20. Quant à écrire du code objet bien modulaire, là encore c'est en parfaite accord avec le TDD, où tu es obligé, si tu le fais bien, à écrire du code facilement testable.

En te fournissant un filet de sécurité permanent, tu en viens à refactorer ton code en permanence sans avoir peur des régressions (le fameux syndrome du "ça marche je n'y touche plus"). C'est vraiment très agréable, et ça a complètement changer ma vision du code, sans exagérer. Écrire les tests après c'est vraiment pénible, mais les écrire en même temps est amusant (mais il faut essayer c'est difficile à croire).

Le principe me semble réellement intéressant, mais la quantité de code de tests à écrire au début de l'application me semble quand même vachement excessive

Oui il m'arrive lorsque j'écris un prototype/proof of concept de ne pas le faire en TDD, mais le faire lorsque l'essai est transformé (et écrire alors les tests pour le "vieux" code à posteriori). Ce n'est pas un dogme non plus :)