GuieA_7 a écrit 695 commentaires

Les assertions c'est bien, et ce n'est pas mutuellement exclusif avec les tests unitaires. Mais ça ne les remplace pas. Dès que tu as un algorithme non trivial (un algorithme quoi! ), tu as plusieurs chemins possibles : les combinaisons se multiplient et les assertions sont inutiles (ou deviennent 3 fois plus nombreuses que les lignes de code 'normales', et vont pourrir ton code).
Si tu fais un algorithme de tri, tu ne vas pas mettre 15 lignes d'assertions (avec des boucles et tout) pour vérifier que tous tes éléments initiaux sont présents, et qu'ils sont bien classés. C'est beaucoup plus sains et simple de faire une dizaine d'assertions dans tes test unitaires du genre :
assertEqual(sort([]), [])
assertEqual(sort([1]), [1])
assertEqual(sort([1, 2]), [1, 2])
assertEqual(sort([2, 1]), [1, 2])
etc…

Une SSII n'a pas forcément intérêt à ce que le logiciel fourni soit totalement fiable car cela la prive de juteux contrats de tierce maintenance applicative.
Vendre un logiciel, c'est vendre des bugs…

Malheureusement, je confirme, c'est un business model courant.

Ces gens là comprennent pas qu'un bon développeur est 15 fois plus productif qu'un mauvais, alors qu'il coute au pire deux fois plus cher.

Et même s'ils le comprennent, ça ne change rien : ils vendent des mois*hommes, pas des bons logiciels. Les grosses SSII fonctionnent avec des juniors inexpérimentés, et quand ils deviennent plus âgés ils se débrouillent pour qu'ils partent d'eux-mêmes, pour ne pas avoir à les augmenter ni leur verser d'indemnité.

Je pense que la formation est essentielle et qu'il faudrait essayer d'introduire les langages fonctionnels dans des formations bac+4 qui pullulent (des sous écoles d'ingénieurs).

Autant ça serait bien que les étudiants soient initiés aux langages fonctionnels, autant il y a des tas d'autres trucs qui serait bien de leur enseigner. Comme la complexité des algorithme par exemple : sans ça ils ne pourront jamais bien coder en impératif, même si c'est le seul paradigme qu'ils connaissent. Je ne crois pas que les BTS la voit, et c'est pareil pour plein de formations en BAC+4 (alors que J2EE ça ils le voient…).

Si j'avais pu travailler en OCaml j'aurais certainement torché ça en 5–6 semaines en prenant une semaine pour implémenter ou lier la bibliothèque en question.

Es-tu plus expérimenté en Ocaml qu'en Python ? Si oui, la comparaison est biaisée de toute les façons ; moi qui n'ai pas fait de Ocaml depuis l'école je mettrais 10 fois plus de temps qu'en Python et ça ne prouvera rien non plus.

C'est parceque les développeurs OCaml sont tous des gentils qui n'aiment pas écraser les autres.

Lol. Je suis bien content que Joseph Swan/ Thomas Edison n'étaient pas des gentils ayant peur de mettre les fabricant de bougies au chômage en inventant l'ampoule électrique.

Mais c'est vrai que c'est plus facile de se plaindre de son patron que de prouver ses dires (de la seule façon possible, à savoir passer à l'action).

• Mon post était bien évidemment provocateur pour le 99%. ceci dit je parle de temps, pas de nombre de bugs. Donc 50 bugs de type qui te prennent 3 secondes à corriger te font perdre moins de temps que la subtile race condition sur ton algo de cache réparti sur cartes graphiques qui va te faire pleurer pendant 2 jours. C'est ça qu'il faudrait comptabiliser pour parler de productivité.
• Je ne dis évidemment pas qu'il faut arrêter de faire de nouveaux langages parce qu'ils n'apportent rien et qu'on en serait au même point en codant tout en assembleur x86. Mais en l'occurrence je fais aussi du JS, mais mon langage serveur est Python, et moi aussi je vois clairement la différence de productivité entre les 2. Outre les (nombreux) défauts inhérents au JS, le fait que l'environnement de développement soit particulièrement hostile n'aide pas non plus (ça évolue, heureusement).

Non franchement, en pratique, quand OCaml te dit "ok, pour la compil, pas d'erreur" ton code bug rarement.

D'un côté je suis assez d'accord. La plupart du code qu'on écrit est trivial ; le plus important se situe plus dans son design général qu'on doit garder propre. Peu de codeur passent la majeure partie de leur temps à plancher sur les algos vraiment pointus. Pourtant, sans test unitaire derrière, je ne ferais pas confiance à un programme en Ocaml, aussi puissant soit son typage, pour ce qui est de la gestion des régressions notamment. Ce n'est pas le compilateur qui va te dire "Andouille ! Ta fonction n'était pas prévue pour gérer une liste avec des doublons, donc en changeant tel comportement, tu as cassé telle autre fonctionnalité de ton programme (que tu ne vas pas tester en cliquant forcément, tu testes celle que tu viens de coder)." En revanche des tests unitaires bien fait vont souvent le faire, et ce même dans un langage pas aussi bien que Ocaml.

Ça me semble acceptable en effet (il y a des tas d'autres facteurs c'est sûr). Je suis de toutes les façons un adepte des codes concis, et je passe une bonne part de mon temps de codeur à enlever des lignes de code, à factoriser. Quitte à avoir des bugs de type 5, autant ne pas les copier/coller.

Imaginons maintenant que les bugs de type 5 sont ceux qui prennent 99% du temps de debugage (c'est un chiffre sorti de mon chapeau, juste pour relativiser tes propos). Cela expliquerait pourquoi les codeurs Ocaml, malgré la supériorité de leur langage, n'arrivent quand même pas à écraser les autres codeurs, en écrivant le même genre de logiciel mais 10 fois plus vite et 10 fois meilleurs (comme certains aimeraient le croire).

Attention malgré tout mon amour pour Python, je reste lucide sur le fait que le typage dynamique est un peu une solution de facilité (mais Python a au moins le mérite de bien le faire, contrairement à d'autres - qui a dit PHP ?! ), et Ocaml a beaucoup de qualité que j'attends des langages du future.

Personnellement, le Développement Piloté par les Tests a plus contribué à la diminution du temps que je passe à chercher des bugs que l'apprentissage de n'importe quel langage.

J'ai personnellement écrit les 20000 premières lignes de MLdonkey en OCaml

Ok, enchanté et bravo !

Avant de faire de telles remarques, il faut se renseigner ! Des applications libres en OCaml, il y en a aussi (dont une partie des fameuses applis industrielles !)

Les torts sont partagés on va dire : je ne savais pas que Xen-Api était libre (je ne le connais même pas à vrai dire), mais en l’occurrence ça m'a l'air d'être un peu l'exception parmi tes super applis industrielles que tu citais en premier. Et c'est bien d'elles dont je parlais ("si dans le lot il y a avait des […]" ) ; parce que sinon, oui je sais qu'il y a des applications libres en Ocaml. Mais justement ce n'est pas forcément celles que tu cites pour convaincre qu'Ocaml c'est bien. Et pour cause, ce sont de 'petites' applications (cela n'a rien de péjoratif hein).

Donc je persiste, ça serait bien si il y avait plus de grosses briques à la fois libres et réussites industrielles en Ocaml. Par exemple en Java[*], même si ça va servir malheureusement à faire principalement des applications métiers proprios (mais ce n'est pas la question), il existe tout un tas de grosses briques libres qui font référence et rare sont les applications java qui n'en utilisent aucune.

[*] et je ne fais pas la promotion de Java, moi je suis principalement Pythoniste.

Je ne suis pas sûr de comprendre ce que tu veux dire dans cette phrase.

Alors je développe. Si un logiciel remplit mon besoin à 95%, je vais sûrement le modifier pour obtenir les 5% restants (et ce même s'il est écrit dans un langage vraiment tout pourri) plutôt que le réécrire depuis zéro an Ocaml, malgré toute la puissance de ce langage (d'où les 95% de lignes "qu'on n'a pas écrites").

Donc j'espère qu'Ocsigen sera une de ces briques libres de référence. Mais j'attends que des webapps reconnues l'utilisent ; les meilleurs frameworks ne sont devenus ce qu'ils sont que parce qu'ils étaient réellement utilisés par des tas d'applis qui les ont éprouvés. Voilà pourquoi je cherchais une section sur le site d'Ocsigen listant les utilisations de ce dernier.

En lisant ce forum, je m'aperçois que beaucoup ne savent pas encore qu'OCaml est sorti depuis longtemps du périmêtre clos des laboratoires, pour être utilisé dans de belles applications industrielles.

Ceci dit si dans le lot il y a avait des applications libres ça serait bien aussi ; maintenant on sait que Ocaml est sorti des labo et sert à faire des applications bien proprio aussi ! :)

Parce que les meilleurs lignes de code c'est aussi bien souvent celles qu'on écrit pas, aussi faciles soient elle à écrire.

Ocsigen semble donc aller dans la bonne direction, et sera encore plus convaincant quand de belles webapp libres et incontournables l'utiliseront (je n'ai n'ai rien vu de tel sur le site d'Ocsigen, fort joli au demeurant).

…la situation de tes commits à titre personnel. Il faudrait l'avis d'un juriste, mais à mon avis les commits que tu as fait sur ton temps personnel sont sous le copyright de ton employeur (tu es auteur, mais tu n'as pas le copyright).

• C'est sûrement dit dans ton contrat de travail : ça touche le domaine de ton entreprise (difficile de plus être le cas vu que c'est un projet de ton entreprise).
• Il est difficile de toute les façons de prouver que tu l'as fait sur ton temps libre (ton employeur peut dire que tu as codé au bureau, et ramené le patch chez toi).

Je pense que ton employeur ne te vole rien, tu lui a juste gracieusement offert ton temps (je sais ça ne te fait pas plaisir, mais je veux juste que tu ne te mettes pas dans la merde). Mais bon le mieux est de voir ça avec ton employeur ; du coup tu auras la réponse pour tes commits futurs.

Mais dans tous les cas (que tu aies le copyright ou non), en fait ça ne va pas changer grand chose pour le futur à mon avis. De toute les façons si 99% des commits viennent de ta boite, et bien elle contrôlera le développement. Il te reste le fork :

• Si ton employeur exige de récupérer ton copyright même pour ton temps libre, et bien du coup ça sera pareil pour le fork (ça restera du libre et tu contrôlerait ce projet ceci dit, mais pas sûr que ça te plaise).
• Cette fois ci parle en avant à ton employeur ; tu ne sembles pas vouloir te fâcher avec ta boite, mais ce n'est pas dit que cette idée leur plaise (ça fait un concurrent etc…).
• Avant le projet n'avançait plus du côté de ta boite, du coup tes commits allaient dans la seule version existante. Si tu forkes, la journée tes commits iront sur une version, et tes commits sur ton temps libre iront sur une autre version. Les 2 versions vont elles beaucoup diverger ? Essaieras tu de récupérer les avancées venant de ta boite dans ton fork ? Avec le temps ça risque d'être frustrant cette gymnastique et cette perte de temps.

Je dirais qu'au final il te restera les issues suivantes :

• Tant pis, tu as fait du zèle pour ta boite, et tu essais éventuellement d'en retirer quelque chose (une prime pour le site par exemple).
• Tu estimes être en position de force (car un technicien reconnu et difficilement remplaçable) : tu négocies pour obtenir plus de contrôle sur le projet (contributions externes, indépendance par rapport à ta boite etc…).
• Tu montes ta propre boite et tu fais vivre ton fork ; en tant que créateur d'entreprise, je ne peux que te prévenir que ça sera beaucoup moins pépère que ta vie de salarié ! Même si j'aimerais que plus de libristes franchissent le pas, il faut bien avouer que ce n'est pas fait pour tout le monde.

En espérant t'avoir aidé.

J'ai un Toshiba Satellite depuis plus de 3 ans, à la base acheté pour sa carte graphique Intel (pour n'avoir que des drivers libres), et finalement pour bosser sur de l'appli web et jouer à des petits jeux et bien il tient encore la route.

Tout ça pour dire que j'ai eu des problèmes au bout de 2 ans environ, à cause de la poussière dans le ventilateur/radiateur (mais ça le faisait s'éteindre, pas rebooter, donc peut être que je suis à coté de la plaque). Je suis allé jusqu'à l'ouvrir, et ce n'est pas forcément évident de le faire proprement. Au final j'ai constaté que la poussière est piégée sur le radiateur (une longue plaque de métal qui relie le ventilateur au processeur) et empêche la bonne évacuation de la chaleur. Un bon coup de bombe dépoussiérante a réglé le problème ; j'aurai pu le faire sans même ouvrir l'ordinateur, et je l'ai d'ailleurs fait depuis par prévention.

Voilà j'espère que ça pourra t'aider (au pire ça te coûtera le prix d'une bombe).

Le problème avec a=1 c'est que '1' est un int donc 'immutable'. Si tu passais une liste par exemple, tu pourrais la modifier à posteriori, même si je ne suis pas sûr que ce soit une bonne idée de structurer ton code comme ça.
Comme suggéré juste au dessus, tu devrais peut être envisager une approche plus objet. Je tape du python toute la journée et je n'utilise jamais 'global' ; je ne dis pas que c'est inutile, mais si on en vient à en utiliser beaucoup c'est qu'il y a sûrement un problème de design.

Le module functools de la lib standard permet, comme son nom l'indique, de faire de la programmation orientée fonctionnelle ; regarde du coté de partial, peut-être que ça t'ira :

from functools import partial

def foo(a, b):
    print a, b

bar = partial(foo, a=1)

bar(b=5) #> 1, 5

Limbo est une petite merveille qui a reçu de nombreuses récompenses (méritées). C'est un jeu de plateforme réflexion à la jouabilité 2D où un petit garçon erre dans le limbes ; il s'agit de résoudre des énigmes basées sur un moteur physique. Il est graphiquement superbe, tout en noir et blanc, et l'ambiance est très glauque (des enfants se font embrocher par des araignées géantes ou découper par des scies circulaires par exemple) ; il est assez court mais les quelques heures qu'il vous occupera seront du bonheur !

Sword & sworcery est lui aussi vraiment excellent. C'est un jeu d'aventure assez contemplatif dans un monde d'heroic fantasy. Graphiquement c'est du pixel art sublime, et les musiques sont fantastiques. C'est un OVNI vidéo-ludique, mais pourvu qu'on accroche c'est envoutant.

À noter qu'un Psychonauts 2 devrait sortir, puisque son créateur a réussi à faire financer son développement grâce à une campagne KickStarter.

J'espère juste que les portages Linux sont de qualité après les éloges que j'ai pu faire !

Le pire c'est que ton commentaire est drôle au second degré, et pertinent au premier.

On s'est mal compris : mon itérateur en python ne peut pas non plus en l'état être utilisé par 2 threads qui appelleraient ses méthodes de manière concurrente (il faudrait utiliser un mutex). En revanche chaque thread peut instancier un itérateur et l'utiliser dans son coin pour aller de 1 à 3. Ce n'est pas le cas de ta fonction avec la variable statique.

Le problème du static c'est que le code ne va pas être réentrant. Il vaudrait mieux faire un vrai itérateur. En l’occurrence en Python à la main ça aurait pu donner un truc comme ça (facile à convertir en C++) :

class Foo:
    def __init__(self):
        self._count = 1

    def __iter__(self): #pour pouvoir faire "for i in Foo():"
        return self

    def next(self):
        count = self._count

        if count > 3:
            raise StopIteration

        self._count += 1

        return count

On voit que le code avec les 'yield' est bien plus simple. On n'a pas par exemple à se soucier de mettre dans 'self' les valeurs qu'on veut garder dans le contexte, mais surtout la structure même du code est plus simple.

(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 ?