Je pense depuis longtemps que vendre des jeux vidéos dont le code (moteur) serait libre, et les données propriétaires, serait tout à fait viable. Le succès des Indie Bundles, dépourvu de DRM le prouve : ils sont facilement piratables (puisque pas de protection), pourtant dans l'ensemble les gens sont prêts à payer pour de bons jeux. Que le moteur 'nu' soit libre n'y changerait donc rien.
Autant sur des logiciels classiques, à la durée de vie longue, la liberté du code a prouvé ses avantages du point de vue technique, autant sur les jeux tout reste à faire pour convaincre les créateurs. Les joueurs se tapent de la liberté du code et ne vont donc pas boycotter les jeux propriétaires. Il faut donc compter sur de rares créateurs de jeux sensibles au libre pour essayer de démonter que ça apporte quelque chose financièrement (si c'est le cas), car le fait que ça ne coûte rien de libérer ne suffit pas à motiver il faut croire (mais les mentalités peuvent évoluer).
C'est donc vraiment enthousiaste que j'ai accueilli Nikki and the Robots. Le business model me semblait proche de la perfection : un jeu libre complet (code et données), et des données payantes supplémentaires (pour moi la perfection serait de libérer toutes les données à un certain moment, mais je chipote). Mais voilà, c'est là que le bât blesse : le jeu me parait très faible. Je n'ai testé que les niveaux libres, mais ils sont censés me donner envie d'acheter le reste, et ce n'est vraiment pas le cas (malheureusement) : je ne me suis pas amusé, le principe de base n'est pas bien folichon, et le game design, qui aurait pu rattraper cet état de fait, n'est pas du tout inspiré . Peut être que ce n'est pas le cas des niveaux payants, non faits par les joueurs, mais dans ce cas il aurait fallu en libérer quelques uns pour montrer ce que le jeu a dans le ventre.
Donc je suis le premier à le déplorer, parce que l'intention derrière ce jeu est très sympathique, mais dire qu'un jeu très médiocre ne s'est pas bien vendu ne permet pas de dire que c'est la faute du business model. Notez bien que des jeux médiocres peuvent très bien se vendre (pub toussa), et de très bons ne pas trouver leur public ; mais rien à voir avec la licence.
Aux alentours de 2004 (oui c'est loin), dans ma boite on s'est beaucoup intéressé aux moteurs 3D libres. On a du passé la plupart en revue ; aucun d'eux n'étaient parfait évidemment, mais en gros seul Ogre était dénué de grosse lacune rédhibitoire, notamment grâce à son approche généraliste très versatile. Presque 10 ans après, la plupart de ces moteurs ont périclité et ont fini dans l'oubli, alors que de son côté le développement de Ogre est très actif.
Il est notamment utilisé dans le très bon TorchLignt (qu'on retrouve dans le dernier Indie Bundle) et TorchLight2 qui vient de sortir (et recueille lui aussi de très bonnes critiques). Je ne sais pas si d'autres moteurs 3D libres sont utilisés dans des jeux commerciaux à succès (j'exclue les moteurs de Id Software, qui deviennent libres bien après leur succès).
Une autre chose appréciable est que Ogre a toujours eu un script d'export pour Blender de qualité ; mais je ne sais pas si c'est vrai depuis Blender 2.50+.
Je pense que Ogre est très populaire, et ça explique sûrement aussi beaucoup le nombre de critiques qu'on va trouver sur lui (parce il est utilisé par plein de monde ; les moteurs inconnus au bataillon, personne ne va les critiquer). Ce qui ne veut pas dire qu'il est exempt de défaut, ou que les critiques sont infondées. J'imagine que son approche généraliste fait qu'il est surement bien moins bon qu'un moteur spécial FPS si on veut faire un FPS par exemple.
PS: je serai vraiment curieux de voir émerger un moteur 3D (libre) en Go, ça serait intéressant je pense.
Resident Evil (une femme, dans le jeu vidéo ce n'était pas le cas)
Pas du tout ; rien que dans le 1er épisode du jeu tu peux jouer une femme (Jill Valentine) ou un homme (Chris Redfield), et avoir 2 aventures un peu différentes. Et puis les films Resident Evil c'est de la bonne grosse merde, tu aurais pu prendre un autre exemple :) (y a plein d'héroïnes mémorables dans les films de Ghibli)
Wikipedia indique sur la page du jeu que le code source a été libéré en 2011 ; la révision relative à cette annonce date du 23 Mars 2012. Donc ça date un peu, mais ça n'est pas un preuve très solide non plus. De son côté le site de Pandemic est fermé depuis 2009, et celui d'Activision pas bien intéressant.
C'est toi qui as des doutes ou tu as lu des trucs là dessus (c'est une vraie question) ?
Sierra et/ou Valve libére le code de Won (même si c'est obselete maintenant) ? Douteux
Si j'ai bien compris, ce qui as été libéré c'est juste le client, c'est pour ça que le multijoueur ne fonctionne pas.
les fichiers commencent toujours par un header proprio (Copyright 1997-1999 Pandemic Studios, Dark Reign II)
Ce n'est pas spécialement un header proprio ; même dans un code libre les différents fichiers peuvent avoir un copyright différent, mais tous placés sous une même licence (pas forcément répétée dans tous les headers).
les assets sous forme d'archive compressé
aucune modification depuis 2011
En effet l'effort pour rendre la libération propre n'a peut être pas été suffisant.
Bon j'ai vu la news passer sur slashdot (et j'ai un peu regardé histoire de faire un eu plus qu'un journal bookmark), donc Activision l'a surement vu passer. Ce ne sont pas des tendres et les choses devraient être mise au clair rapidement. J'espère que cette libération n'était pas du flan.
Je n'ai jamais dit que ça me dérangeait d'ajouter des mots clés ; j'ai juste dit qu'en Python il y avait une alternative sympa à if !('id' in plop), et qui ne nécessite pas de mots clés supplémentaire ; c'est tout.
Ça doit même être dans le tutoriel de Guido Van Rossum (je regarderai). C'est pourquoi il est conseillé de toujours utiliser des objets "immutable" en tant que valeur par défaut. Quand je forme des débutants, je présente ça comme un écueil classique.
Personnellement, je dirais que le management ne l'a probablement pas entendu de cette oreille
Oui c'est exactement ce que je pense ; tout Michel Ancel qu'il est, il ne fait pas tout ce qu'il veut (et puis à quel point était-il à fond derrière cette libération, difficile a savoir). Dommage, vraiment dommage.
D'ailleurs à propos de Rayman Origins, Michel Ancel (son créateur) avait dit dans une interview l'année dernière qu'il envisageait de libérer le moteur du jeu (et les outils associés me semble-t-il). Ça me ferait bien fait plaisir (c'est un moteur 2D utilisant efficacement les cartes graphiques modernes), et c'était très étonnant de la part d'Ubisoft. Malheureusement pour le moment j'ai eu raison de ne pas m'emballer parce que rien à l'horizon à ma connaissance.
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.
# Pas la faute du business model
Posté par GuieA_7 (site web personnel) . En réponse au journal Vendre du jeu-vidéo libre. Évalué à 4.
Je pense depuis longtemps que vendre des jeux vidéos dont le code (moteur) serait libre, et les données propriétaires, serait tout à fait viable. Le succès des Indie Bundles, dépourvu de DRM le prouve : ils sont facilement piratables (puisque pas de protection), pourtant dans l'ensemble les gens sont prêts à payer pour de bons jeux. Que le moteur 'nu' soit libre n'y changerait donc rien.
Autant sur des logiciels classiques, à la durée de vie longue, la liberté du code a prouvé ses avantages du point de vue technique, autant sur les jeux tout reste à faire pour convaincre les créateurs. Les joueurs se tapent de la liberté du code et ne vont donc pas boycotter les jeux propriétaires. Il faut donc compter sur de rares créateurs de jeux sensibles au libre pour essayer de démonter que ça apporte quelque chose financièrement (si c'est le cas), car le fait que ça ne coûte rien de libérer ne suffit pas à motiver il faut croire (mais les mentalités peuvent évoluer).
C'est donc vraiment enthousiaste que j'ai accueilli Nikki and the Robots. Le business model me semblait proche de la perfection : un jeu libre complet (code et données), et des données payantes supplémentaires (pour moi la perfection serait de libérer toutes les données à un certain moment, mais je chipote). Mais voilà, c'est là que le bât blesse : le jeu me parait très faible. Je n'ai testé que les niveaux libres, mais ils sont censés me donner envie d'acheter le reste, et ce n'est vraiment pas le cas (malheureusement) : je ne me suis pas amusé, le principe de base n'est pas bien folichon, et le game design, qui aurait pu rattraper cet état de fait, n'est pas du tout inspiré . Peut être que ce n'est pas le cas des niveaux payants, non faits par les joueurs, mais dans ce cas il aurait fallu en libérer quelques uns pour montrer ce que le jeu a dans le ventre.
Donc je suis le premier à le déplorer, parce que l'intention derrière ce jeu est très sympathique, mais dire qu'un jeu très médiocre ne s'est pas bien vendu ne permet pas de dire que c'est la faute du business model. Notez bien que des jeux médiocres peuvent très bien se vendre (pub toussa), et de très bons ne pas trouver leur public ; mais rien à voir avec la licence.
[^] # Re: Moteurs 3D (pour les jeux) libres
Posté par GuieA_7 (site web personnel) . En réponse au journal Torque passe open source. Évalué à 2.
Aux alentours de 2004 (oui c'est loin), dans ma boite on s'est beaucoup intéressé aux moteurs 3D libres. On a du passé la plupart en revue ; aucun d'eux n'étaient parfait évidemment, mais en gros seul Ogre était dénué de grosse lacune rédhibitoire, notamment grâce à son approche généraliste très versatile. Presque 10 ans après, la plupart de ces moteurs ont périclité et ont fini dans l'oubli, alors que de son côté le développement de Ogre est très actif.
Il est notamment utilisé dans le très bon TorchLignt (qu'on retrouve dans le dernier Indie Bundle) et TorchLight2 qui vient de sortir (et recueille lui aussi de très bonnes critiques). Je ne sais pas si d'autres moteurs 3D libres sont utilisés dans des jeux commerciaux à succès (j'exclue les moteurs de Id Software, qui deviennent libres bien après leur succès).
Une autre chose appréciable est que Ogre a toujours eu un script d'export pour Blender de qualité ; mais je ne sais pas si c'est vrai depuis Blender 2.50+.
Je pense que Ogre est très populaire, et ça explique sûrement aussi beaucoup le nombre de critiques qu'on va trouver sur lui (parce il est utilisé par plein de monde ; les moteurs inconnus au bataillon, personne ne va les critiquer). Ce qui ne veut pas dire qu'il est exempt de défaut, ou que les critiques sont infondées. J'imagine que son approche généraliste fait qu'il est surement bien moins bon qu'un moteur spécial FPS si on veut faire un FPS par exemple.
PS: je serai vraiment curieux de voir émerger un moteur 3D (libre) en Go, ça serait intéressant je pense.
[^] # Re: Tropes vs Women
Posté par GuieA_7 (site web personnel) . En réponse au journal Actualité geek-féministe de l'été . Évalué à 2.
Pas du tout ; rien que dans le 1er épisode du jeu tu peux jouer une femme (Jill Valentine) ou un homme (Chris Redfield), et avoir 2 aventures un peu différentes. Et puis les films Resident Evil c'est de la bonne grosse merde, tu aurais pu prendre un autre exemple :) (y a plein d'héroïnes mémorables dans les films de Ghibli)
[^] # Re: Il y a des doutes sur la légalité de cette libération
Posté par GuieA_7 (site web personnel) . En réponse au journal Libération du Jeu Dark Reign 2. Évalué à 1.
Wikipedia indique sur la page du jeu que le code source a été libéré en 2011 ; la révision relative à cette annonce date du 23 Mars 2012. Donc ça date un peu, mais ça n'est pas un preuve très solide non plus. De son côté le site de Pandemic est fermé depuis 2009, et celui d'Activision pas bien intéressant.
[^] # Re: Il y a des doutes sur la légalité de cette libération
Posté par GuieA_7 (site web personnel) . En réponse au journal Libération du Jeu Dark Reign 2. Évalué à 1.
Ok merci pour ta réponse.
Wait and see…
[^] # Re: Il y a des doutes sur la légalité de cette libération
Posté par GuieA_7 (site web personnel) . En réponse au journal Libération du Jeu Dark Reign 2. Évalué à 3.
C'est toi qui as des doutes ou tu as lu des trucs là dessus (c'est une vraie question) ?
Si j'ai bien compris, ce qui as été libéré c'est juste le client, c'est pour ça que le multijoueur ne fonctionne pas.
Ce n'est pas spécialement un header proprio ; même dans un code libre les différents fichiers peuvent avoir un copyright différent, mais tous placés sous une même licence (pas forcément répétée dans tous les headers).
En effet l'effort pour rendre la libération propre n'a peut être pas été suffisant.
Bon j'ai vu la news passer sur slashdot (et j'ai un peu regardé histoire de faire un eu plus qu'un journal bookmark), donc Activision l'a surement vu passer. Ce ne sont pas des tendres et les choses devraient être mise au clair rapidement. J'espère que cette libération n'était pas du flan.
# Typo
Posté par GuieA_7 (site web personnel) . En réponse au journal Libération du Jeu Dark Reign 2. Évalué à 3.
Rah mais quel boulet je n'ai pas relu mon titre : s/Drak/Dark
Si un gentil modo pouvait corriger. Merci d'avance.
[^] # Re: Bof du sucre syntaxique sans grand intéret
Posté par GuieA_7 (site web personnel) . En réponse au journal De tout, de rien, des bookmarks, du bla bla. Évalué à 2.
Je n'ai jamais dit que ça me dérangeait d'ajouter des mots clés ; j'ai juste dit qu'en Python il y avait une alternative sympa à
if !('id' in plop), et qui ne nécessite pas de mots clés supplémentaire ; c'est tout.[^] # Re: Bof du sucre syntaxique sans grand intéret
Posté par GuieA_7 (site web personnel) . En réponse au journal De tout, de rien, des bookmarks, du bla bla. Évalué à 2.
En python on pourra certes l'écrire comme ça :
mais aussi comme ça :
qui me semble assez proche de ton envie d'expressivité, et sans ajouter de mot clé.
[^] # Re: C'est très connu
Posté par GuieA_7 (site web personnel) . En réponse au journal Python et valeurs par défaut des paramètres. Évalué à 2.
s/immuable/immuables/ :)
J'ai fait mon Jean-Claude Van Damme, mais j'ai préféré utiliser le terme anglais pour éviter les confusions (d'où les guillemets et le non accord).
# C'est très connu
Posté par GuieA_7 (site web personnel) . En réponse au journal Python et valeurs par défaut des paramètres. Évalué à 5.
Ça doit même être dans le tutoriel de Guido Van Rossum (je regarderai). C'est pourquoi il est conseillé de toujours utiliser des objets "immutable" en tant que valeur par défaut. Quand je forme des débutants, je présente ça comme un écueil classique.
[^] # Re: Quasiment tous les jeux Ubi sauf...
Posté par GuieA_7 (site web personnel) . En réponse au journal Ubisoft fait mieux que Sony. Évalué à 2.
Merci de sourcer à ma place ! :)
Oui c'est exactement ce que je pense ; tout Michel Ancel qu'il est, il ne fait pas tout ce qu'il veut (et puis à quel point était-il à fond derrière cette libération, difficile a savoir). Dommage, vraiment dommage.
[^] # Re: Quasiment tous les jeux Ubi sauf...
Posté par GuieA_7 (site web personnel) . En réponse au journal Ubisoft fait mieux que Sony. Évalué à 3.
D'ailleurs à propos de Rayman Origins, Michel Ancel (son créateur) avait dit dans une interview l'année dernière qu'il envisageait de libérer le moteur du jeu (et les outils associés me semble-t-il). Ça me ferait bien fait plaisir (c'est un moteur 2D utilisant efficacement les cartes graphiques modernes), et c'était très étonnant de la part d'Ubisoft. Malheureusement pour le moment j'ai eu raison de ne pas m'emballer parce que rien à l'horizon à ma connaissance.
[^] # Re: Pilote graphique AMD
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Sortie du noyau Linux 3.5. Évalué à 3.
En plus il y a une petite typo :
tampon de buffer hiérarchique -> tampon de profondeur hiérarchique
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 2.
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.
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 2.
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 :
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.
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 2.
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) ?
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 2.
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.
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 0.
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. :)
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 2.
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…
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 6.
Malheureusement, je confirme, c'est un business model courant.
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é.
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…).
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 0.
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.
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).
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 1.
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.
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 0.
Ç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.
[^] # Re: Utilisation d'OCaml dans l'industrie
Posté par GuieA_7 (site web personnel) . En réponse à la dépêche Ocsigen : repenser le développement des applications HTML5. Évalué à 3.
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.