GuieA_7 a écrit 675 commentaires

Tu parles de quoi?

Cette remarque ne t'était pas forcément destinée. Mais un certain nombre de techos affirment qu'ils pourraient très bien faire des logiciels qui poutrent, être 10 fois plus productifs, si seulement les imbéciles de décideurs prenaient le risque de leur faire confiance (et je suis d'accord hein, les dirigeants n'y connaissent souvent pas grand chose en technique, ils savent juste ce qu'est la vente). Sauf que parmi ces techos justement, très peu iront se mettre en danger justement, et continueront à faire ce que les décideurs leur disent de faire ; comme quoi il n'y a pas que les décideurs qui n'aiment pas les risques, c'est assez naturel en fait.

Pou caricaturer, je dirais qu'aux USA des techos montent leur boite, en France ce sont les commerciaux qui le font.

je n'ai jamais entendu personne faire ce reproche à Python sur un forum, en dehors de la communauté Python.

Peut-être que tu bosses beaucoup au lieu de mouler :) , mais si, le GIL est un défaut de Python souvent cité (sur LinuxFR par exemple). Même pour les gens qui aiment Python, comme moi, oui c'est clairement un défaut. Ce n'est pas pour rien qu'il y a :

• Stackless un fork de CPython qui propose un système sans GIL (je crois) avec envoi de messages.
• multiprocessing, un module de la lib standard qui pallie vaguement ce problème en simplifiant les apps avec plusieurs processus.
• plein de gens déçus que pypy (la nouvelle vm avec JIT) ait gardé le GIL ; il y a cependant un groupe de travail qui bosse sur la Software Transactionnal Memory.

Aujourd'hui, je pense que le problème principal est d'améliorer l'accessibilité d'OCaml, en faisant des livres pour débutants, des tutoriaux en ligne (voir http://try.ocamlpro.com/), en améliorant les outils de développement (un bon mode Eclipse) et le support Windows (la version 4.00 imminente devrait avoir deux installeurs pour Windows concurrents, alors que la version précédente en avait zéro !).

Oui entièrement d'accord. Ce n'est surement pas le genre de trucs qui motive les gens de l'INRIA, mais il faudra en passer par là pour populariser Ocaml.
En fait ma question sur les performances, notamment ce qu'il faudrait améliorer, était plus de la curiosité technique qu'autre chose. Tu ne réponds pas à cette partie, mais si tu ne sais pas trop ce n'est pas grave (alors que pour Python c'est assez facile de comprendre ce qui est lent), je profitais juste de la chance de parler à quelqu'un qui met les mains dans le cœur d'Ocaml.

OCaml ne fait pas beaucoup d'optimisations en comparaison, et a donc pas mal de marge de progression.

Est-ce que des optimisations sont prévues, ou est-ce qu'au vue des ressources humaines ce n'est pas une priorité ?
Est-ce qu'utiliser LLVM pourrait améliorer les performances ? Ou est-ce que la majorité des optimisations devraient de toutes les façons avoir lieu au niveau du frontend (en évitant des copies par exemple) ?

Depuis quelques années (mais c'est pas hyper vieux non plus), la VM Erlang gère le SMP ; je ne connais pas la politique exacte des threads, mais j'imagine que c'est un pool de threads, avec un thread par core, et comme tu dis des threads légers par dessus (vu qu'Erlang encourage la création de dizaines de 'processus erlang', ça serait bête de créer un thread système pour chacun). J'imagine qu'avant il fallait lancer une VM par core 'à la main' pour exploiter son hard au maximum.

OK, merci pour les précisions. En tout cas je serais ravi de lire une dépêche présentant ces softs libres (et je ne pense pas être le seul), ça éduquerait les geeks incultes que nous sommes. :)

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 !