D'autre part, il ne faut pas soutenir n'importe quel truc "parce que ca ressemble à du libre". Un des dangers pour le monde du LL qui se démocratise, c'est qu'on est de plus en plus de projets qui s'écartent de la philosophie du libre : des projets qui profitent de l'engouement autour du LL mais qui n'en adoptent pas vraiment la philosophie. On le voit aussi chez certains nouveaux utilisateurs.
- plus de ligne de code != plus de bugs dans un code généré.
Si si plus de bug, mais avec de grandes différences dans les écarts types. On peut traduire comme ceci, les meilleures équipes n'ont pas forcément plus de bugs, par contre, le temps de résolution est mécaniquement plus long (particulièrement si on a un bug dans le coeur d'une classe de base) et le risque de bug généré par la correction de bug augmente avec l'intrication du code. (on considère qu'une correction de bug à une chance sur deux de généré un nouveau bug par effet de bord).
Il y a les données dans complete coding de Steve Mc Connell.
c'est quoi le rapport ?
La productivité en informatique par développeur est :
0) indépendante du diplôme ;
1) indépendante de l'expérience au delà de 2 ans;
2) varie d'un facteur 1 à 10 par individu.
(Sackmann Grant et al)
L'informatique n'est pas une question de diplôme mais de créativité. Vu comment l'enseignement est dogmatique, particulièrement en école, j'imagine pas vraiment en quoi étudier résout les problèmes de facteur humain.
Ensuite d'organisation à organisation les variabilités de productivité sont encore d'un facteur 1 à 10.
La conclusion (Peopleware de Di Marco, Myhtical Man Month de F. Brooks, Complete Coding Steve Mc Connell) est que pour améliorer la productivité en informatique,
1) il faut recruter et bien recruter non sur les diplômes, mais miser sur des équipes, et
2) s'organiser non à la française (modèle héirarchique de base), mais dans des modèles plus organiques (par "atelier" par exemple)
Pour tout ce qui est technologie le meilleur gain de productivité hors concision du langage (qui peut faire gagner un facteur 6 par rapport au C en prenant un langage à typage dynamique (php/perl/ruby/python)) est au mieux de 10%.
Tu m'expliques en quoi se focaliser sur un gain de 10% est plus intelligent qu'un que s'intéresser à un gain de 1000% x 1000% ?
Aller, je t'aide combien de fois 0,1 faut il pour faire 100 ? Question subsidiaire, à quel point significatif est 0,1 / 100 si on garde les décimales ?
Après on peut faire des trucs propres en PHP, oui, et on peut même s'y amuser relativement (l'autre jour j'ai dû écrire un bout d'ORM dans ce merveilleux langage).
Oui, mais passer de c# ou de MS C++ à php ça reste la fête au village.
Et bizarrement, ce qui joue le plus est autant le typage dynamique, que la doc. Autant j'ai pu me battre avec php et ses problèmes énormes en encodage de chaine multi octet alors que c# se débrouille mieux, autant les man pages de c# sont inutilisables tant elles sont verbeuses et le code d'exemple digne d'un stagiaire. Php.net est quand même un bon référentiel documentaire.
Pour en revenir au facteur humain, mon plus gros problème en c# était que les fanas su langage pensait que "parce qu'ils avaient le meilleur langage" tout était résolu. Quand on vous présente les "dataset*" comme un ORM, vous avez peur. Le plus gros problème que j'ai pu rencontré en environnement windows est le manque de culture informatique. Et ça c'est pire que le mauvais langage.
Anecdote :
Chez un client : tout dans les pages asp était présenté en mettant les attributs de présentation en dur dans le code asp, (border=1px; color=blue...). Le truc casse couille pour modifier l'apparence, on agrééra. Client qui me parlait fort des bonnes pratiques, de la séparation du code et de la présentation etc ... Donc, j'ai utilisé les CSS. Et 3 jours plus tard je reçois un mail du directeur technique, pro de l'informatique qui m'enjoint d'arrêter en mettant en référence un lien sur un article de security focus "The danger of CSS". Evidemment, CSS ici voulait dire cross site scripting, mais lui a pensé Cascading Stylesheet : je lui cassais les couilles avec un truc qu'il connaissait pas, un petit tour de google, il lit pas l'article et me renvoie directement la référence. J'ai jamais pu lui faire valoir qu'il parlait pas de la même chose : si security focus a dit non aux CSS, alors pas de css.
Par contre quand je lui ai montré que l'on pouvait injecter du html arbitraire dans ses pages webs grace à textarea compréhensifs, il a pas vu le problème.
J'ai moults anecdotes de ce style qui me font penser que la culture informatique en entreprise est quand même faible, et que c'est bien le frein le plus important, plus important que le choix du langage.
Je vous raconte même pas php et l'utf8 sur un windows IIS mysql PHP.
Bref le choix du langage est pour moi un problème d'optimisation alors qu'en entreprise --souvent**-- tout est à faire. On chipote sur le langage alors que le facteur humain est largement plus bloquant
* http://en.wikipedia.org/wiki/Data_set
** oui il y a aussi de très bons professionnels, mais je suis souvent surpris de l'endroit où je les trouve.
Dis moi, tu colles un langage vachement bien à un manager tu crois qu'il va faire du bon code ?
Que coder en ruby ou en python ou en java empêche les développeurs de mettre les réglages en dur dans le code et les oblige à faire des fichiers de conf ?
Enfin, on a les croyances que l'on veut. Il me semblait pourtant que les informaticiens étaient des scientifiques et pas des religieux.
Remarque quand les idéologues décident de faire du code on voit ce que ça donne : GNU/Hurd, je te laisse l'utiliser en prod, je vais continuer à prendre ces vieux trucs obsolètes de linux ou BSD qui sont si vieux et mal conçus (c'est vrai pas de micro-noyaux, pas de driver user space, pas de marketeux pour dire comment c'est bien) .
Non le critère utilisé pour mesuré l'équivalence des langages est de mesurer empiriquement la concision par rapport à un langage (données de Harr à toi de les retrouver)
En fait, perl, php, ruby, pyhton sont équivalents en concision car ce sont des langages à typage dynamique. (cf complete coding / Steve Mc Connell)
La plus grande force d'un langage ne réside pas dans sa syntaxe ou ses structures de contrôles, mais dans les données. Plus les types de bases sont intéressants (comme la hashtable) plus leur manipulation est aisé (GC inclus) plus le langage est concis.
Et en plus tu réduis le développement au code or comme la doc de sloccount l'exprime si bien http://www.dwheeler.com/sloccount/sloccount.html#cocomo
qui reprend les données de Harr/boehm : coder est une part minimal du développement.
Le reste c'est du déboguage, de la conception, de la compréhension du problème, de la doc, de la négociation ... Et même dans le déboguage la partie facteur humain passe devant le code. Alors comme notre boulot est minoritairement de coder, je vois pas pourquoi le langage est si important.
Remarque même si j'ai plus de plaisir à prendre un langage que j'aime comme tout le monde, le plaisir, le goût sont quand même pas des critères objectifs et absolus, ou alors j'ai loupé un cours de français. Donc pourquoi imposer son langage préféré alors que pour le client ça change rien d'autre que des emmerdes à devoir gérer un langage en plus.
Mais bon ton analogie avec les maths est bonne, car je viens de la physique, et je te laisse imaginer que je conçois que les langages informatiques sont à l'informatique réel, ce que les maths sont à la physique. Utile, mais pas ma tasse de thé. Je trouve que les matheux sont nécessaires, mais qu'ils ont rarement la structure de pensée pour résoudre un cas pratique réel. Bref un matheux a pour moi autant d'intérêt en physique qu'un amoureux des langages en informatique de production : c'est un idéologue au milieu d'un environnement de travail, une gêne quoi. Exactement ce que tu prouves en prenant une analogie sur des maths : que t'es pas orienté résolution de problèmes, mais esthète des technologies créateur de discussions infinies sur des coupage de poils de fesse en 4.
Bref, à mon avis, je crois que t'a pas compris notre métier.
Aucun langage ne me satisfait pleinement. A chaque fois que je vois un langage je trouve qu'il y a de bonnes idées, et qu'on pourrait faire encore mieux, plus lisible, plus simple, plus concis, plus fiable ...
Au final, ma philosophie est que plus on me paie cher pour écrire dans un langage plus je suis volontaire pour le faire. C'est à mon avis le critère de choix pour utiliser un langage.
Ce qui fait que j'utilise presque tous les langages du marché et je ne les trouve pas foncièrement différents ; les erreurs dans les programmes sont plus souvent -à mon expérience- dans la conception d'une solution ou dans le choix de mauvais développeurs, que dans le choix, ou dans la syntaxe du langage.
Si vous préférez le langage est au développeur ce que le marteau est au menuisier. Rien qu'un truc, un machin, un outil. Sûrement pas le principal quoi. Donc un troll sur les langages qui n'est pas pour le fun, est un sujet de personne qui sont des esthètes de l'informatique, et entre nous un bon informaticien n'est pas là pour aimer l'informatique, il est là pour apporter des solutions. Et c'est pas avec le langage informatique, mais avec sa cervelle qu'on travaille.
Pour résumé : troll de langage = truc de geeks. Et je suis loin d'être convaincu qu'un geek ça fasse un bon développeur.
et pour surenchérir, il n'y a pas de mauvais langage, il n'y a que de mauvais programmeurs :
la variation en productivité et en qualité, liées aux développeurs est supérieure à celle liées aux techniques informatique et managériale ou autres.
Un bon développeur fera toujours du bon code quelque soit le langage.
mon message à la base c'était pour dire que php/perl/ruby/python c'était kif kif, mais que les trolls sur les langages me font bien marrer alors j'ai pas pu m'empêcher de relancer la machine à troll ^^
Il y a toujours des personnes pour se faire avoir <:o)
Python ruby php perl même combat mais TIMTOWTDI avant tout :
Les données de Harr disent :
- le nombre d'instruction par jour est le même par développeur quelque soit le langage utilisé ;
- certains langage sont plus concis que d'autres (à condition de coder dans le langage);
De mêmoire si le C est une base référence :
C++ => 1,5 x plus concis
java VB => 2
perl/php/ruby/python => 6
à coté de ça :
le nombre de bug augmente plus que linéairement avec la taille, ainsi que le temps de développement
Conclusion
tout langage suffisamment concis devrait être favorisé.
Après tous les langages se valent tant que on respecte l'esprit de concision pour son problème :
C'est une question de goût et de contexte. Après le one best way to do it, est une erreur car tous les problèmes ne sont pas isomorphes. Si vous préférez un même chapeau ne va pas à tout le monde : on va pas sur un chantier avec un stetson, et au soleil avec un casque de chantier ...
Je préfère le perl ^^ parce que c'est concis est que l'on peut écrire littérairement du code. Pour moi le code est une rédaction littéraire que j'ai besoin de comprendre pour le relire, le modifier. En plus je me sens à l'aise car comme en français, j'ai la possibilité de pouvoir développer un style. Un programme, est une dissertation qui répond à la question comment résoudre tel problème. Nos codes doivent répondre à la question de la manière la plus lisible selon le style de l'auteur.
Chacun sa manière de coder, moi je code pas, je raconte une histoire, avec un argot, des tournures littéraires, en empruntant les meilleurs mots des autres, et ça m'éclate.
Tant que je m'éclate je continuerais à faire ce boulot, et je conçois que comme certains préfèrent le français à l'italien ou l'anglais à l'allemand on puisse se taper dessus pour des langages. Et c'est pour ça que j'adore les trolls de langage, ça reste des discussions de personne qui aiment au delà des langages la littérature.
Bref python, et ruby sucent des ours, le perl les écrase. Pas de troll ni de mauvaise foi, juste une constatation objective.
Hé ! Il y a de bonnes adaptations, parce qu'elles donnent du sens.
Etoile au garde à vous (Heinlein auteur préféré des 68ards avec étranger en terre étrangère) par Verhoven qui devient starship trooper est une excellente adaptation.
C'est une critique velue de l'"allophobie" américaine (contexte : 1ere guerre d'Irak), ou même si le film prétend prendre le point de vue des gentils humains, verhoven leur colle des unifromes de nazis, tourne son film comme un film de propagande sauce deuxième guerre mondial, et sème le doute sur la méchanceté des aliens que l'on fait passer pour des insectes nuisibles. Un film fait pour vous rendre mal à l'aise, parce que vous vibrez pour des héros dont on vous fait deviner qu'ils sont peut être les salauds. Le message était : êtes vous sûrs que les aliens (étrangers) sont les méchants que l'on vous dépeints, et que nous sommes vraiment des héros ? )
Moi ce qui me casse les pieds c'est les auteurs qui ont pas de style, qui aplatissent le sens du film. En parlant de ça, Stephen king lui à eu le droit à de superbes adapatation de ses oeuvres dont le "shining" de kubrik qui est assez éloigné du bouquin. L'excellent "misery" de rob reiner (?)
Et toujours chez kubrick citons "blade runner" (tiré de est ce que les androïdes rêvent de moutons électriques de K Dick), et clockwork orange qui est aussi une adaptation d'un roman éponyme tronqué d'un chapître. Pourtant, la fin de K dick qui contredit le livre est bien plus intéressante.
Donc comme dans tous les domaines, pour qu'une adaptation soit bonne, il faut que l'adaptateur soit bon. Et le fait que le film soit commercial ou pas n'y change rien (argument fallacieux). Que les auteurs soient libres (argument fallacieux #2) de leur adaptations ne change rien au fait que leur film doivent être avant tout juger sur leur résultat. Parmi les exemples sus-cités il n'y a que des exemples commerciaux. ET (argument fallacieux #3) aucun film cité n'est une
adaptation parfaite.
Même total recall est une bonne adaptation de K Dick.
Donc tes arguments à la sauce zélote des creative commons, tu te les gardes. Car ce qui me casse les pieds encore plus que les mauvais oeuvres, c'est les gens qui réfléchissent non avec leur cerveau, mais à coup d'argument pré-formatés comme une propale de SSII.
j'ai aimé le bouquin, je me tatais pour voir le film... Je crois que j'en ai assez de voir des bouquins massacrés au cinéma. Allez je retourne lire les croisés galactique de Poul Anderson. C'est au moins aussi drôle que Terry Pratchett.
À moins que tu voulais dire que Tk était un précurseur dans ce domaine, GTK+ et Qt étant plus récents ?
Tout à fait mon bon monsieur, tel était l'esprit de ma phrase.
Malheureusement en Tk on ne peut pas "attacher" des données aux évènements, contrairement à GTK+ ou Qt qui intègrent le principe des signaux.
On peut mettre à jour des widgets (de manière limité) en fonction de la valeur de variables (option variable des widgets).
Il me semble aussi que comme le tie de perl on peut greffer des callbacks sur des valeurs.
Si mes souvenirs sont exacts, on peut donc simuler les signaux avec un variable ^^ surveillée.
Tcl Tk a bien changé :)
J'ai eu fait des scripts en Tcl TK + C qui marchaient toujours 10 ans plus tard.
Le coté moche venait des choix par défaut.
A coté de ça, philsophiquement, tcl/tk est dans ma faible expérience le langage de scriptage qui a apporté la manière de programmer les interfaces graphiques la plus propre :
- gestion des GUI comme un gestionnaire d'évènement qui boucle ou chacun des éléments réagi grâce à des callbacks (c'est sûrement pas innovant, mais le html utilisé en GUI revient à faire de la gestion d'UI en séquentiel);
- proposition de "gestionnaire de géométrie" variés, souples et puissant, dont le célèbre pack orienté mise en page relative (je n'ai jamais utilisé que pack).
Par contre contrairement à ce que l'on imagine, le plus dur ce n'est pas la syntaxe, qui en un sens est proche de perl matinée de fortran (pour les tournures vieillotes comme set), mais la philosophie quand on fait du GUI qui est orientée évènement.
Ce langage m'a appris beaucoup de chose, je l'utilise plus (sauf parfois avec perl::Tk) cependant, je continuerais à le défendre car même si le web remplace presque bien les GUI client lourd, dès que l'on veut faire de l'évènementiel (comme avec ajax), le niveau de complexité dépasse de loin le tcl/tk. À quand le retour de l'utilisation du plugin tck/tk en lieu et place d'ajax ? http://www.tcl.tk/software/plugin/
Par curiosité, essayez donc de faire une petite interface graphique vous verrez à quel point ce langage est puissant pour ce domaine.
Parrot n'est pas un langage de script mais une machine virtuelle dont l'objectif est de tourner sur un maximum de plateforme. Parrot, c'est la future couche basse d'un maximum de langage de script (dont Perl6), il me semble normal pour des questions de portabilités de linkage avec les bibliothèques de le mettre au plus proche du langage des OS d'aujourd'hui donc de l'écrire en C. Tu aurais voulu écrire Parrot dans quel langage ?
L'objectif de parrot 6 est d'être comme comme une jvm qui saurait faire du système ?
(non parce que java est le système c'est un peu léger si mes souvenirs sont exacts.)
Dans le cas des problèmes de décimal, je ne faisais que suivre les exemples de code tirés du manuel (pour faire bien) de microsoft dynamics CRM).
.net est fâché avec les nombres. Je me souviens de la classe utilisée pour récupérer les entiers retournés par les requêtes en bases en .net 1.1 avec visual c++ qui retournait un entier natif alors que le type en base était en entier compris entre 0 et 10^13 mes programmes plantaient. J'ai fin par passer à la regexp pour contourner le problèmes.
Leurs docs sont tellement illisibles que j'ai renoncé à :
1) comprendre pourquoi les objets int de taille arbitrairement long n'était pas facilement accessible dans le langage de base http://msdn2.microsoft.com/de-de/library/ms173104.aspx
C'est la base non ?
Comme tous les langages il est extensible, pourquoi il y a pas un cpan like ... un truc moderne de gestions d'extension quoi ?
<generalisation hâtive>
Le c# est pas mauvais en soi, mais c'est juste que je trouve qu'il y a un bon nombre de codeurs de ce langage qui ont tendance à réinventer la chaise dans leur coin, et à imaginer que parce qu'ils peuvent acheter des bibliothèques oops pardon ils disent des librairies, il doit forcément il y avoir une bibliothèque qui le fait.
</>
Là où je veux en venir, c'est que pour moi la force d'un langage vient aussi de sa communauté et de ses pratiques, et que comme tu viens de l'illustrer résoudre un problème d'informatique consiste parfois à réfléchir en dehors du langage.
Néanmoins sur le sujet du fortran et des NumericalRecipies qui ont quelques siècles*hommes derrières elles de dév et test, je crois pas qu'un langage jeune comme python/perl/php/ruby/java/c# peut les concurrencer. On ne construit pas une pyramide en un jour.
Donc je pense toujours que le fortran est aussi peu mort que le perl. Juste pas très utilisé. Comme perl le devient.
PS : arrête de montrer mes lacunes en développement c'est drôle quant tu reprends les autres, mais c'est vexant quand ça m'arrive.
me moquer de mes collègues qui font du php ou du c# en faisant en quelques lignes des choses qu'ils pensent inimaginables (des moulinettes, des remplacement en lignes, des parseurs de logs, des stats ....).
Des petits programmes qui font à ma place rapidement des choses d'informaticien ordonné qui m'ennuient : un rangeur de mp3 dans mon disque en fonction des infos, un chargeur de clés usb avec des fichiers pris aux hasards sur le disque, un bot web pour draguer, un surveilleur de logs proactifs ...
Ses points forts les modules CPAN, les perls mongueurs
Son point faible aujourd'hui : le rapport signal bruit dans les modules cpan
Ex il y a une demi douzaine de classe pour faire de l'objet propre, mais tous sont maintenus à des degrés divers, et c'est carrément l'enfer pour les trouver évaluer le plus stable tellement la logique de rangement me dépasse.
Exemple
Oui, et Fortran est resté archaïque et dépassé. Ce n'est peut-être pas la meilleure analogie possible pour défendre Perl6...
Je discutais avec des gars de labo physique et il disait qu'ils revenaient des python/perl/ruby ... pour les calculs. La numerical recipies (un livre de recette algorithmique pour les calculs sur ordinateur qui a donné lieu à une bibliothèque logicielle homonyme) et le parallelisme restent inégalés en fortran. Non tant par les fonctionnalités, que par la maturité autant dans ses usages que de son implémentation de la bibliothèque.
Mes derniers égarements en c# m'ont permis de voir que pour les calculs en virgule flottante, 10 000 * .196 (la TVA) donnait des chiffres non nuls après la 5éme décimale par exemple, je ne parle pas de PHP, et pour perl le cpan doit proposer 3 bibliothèques pôur faire ça. De plus, ils manquent des bonnes bibliothèques pour les matrices creuses, des algorithmes de réduction de matrice en forme LU par exemple mais aussi des moyens de renvoyer les marges d'erreurs.
Mon opinion partielle et partiale est la suivante
1) il n'y a pas de bon langage, il y a de plus ou moins bons programmeurs qui connaissent l'état de l'art (j'ai encore à bosser sur le sujet, je sais ^_^) ma préférence va à tous les langages concis à la base (perl/php/python/ruby)
2) il faut utiliser les langages les plus adaptés à chaque taches, car ruby pour faire du bas niveau est peut être pas adapté, et coder une application web en postscript est peut être pas efficace. Si pour une tâche plusieurs langages sont équivalents, alors choisir le plus concis.
3) parfois quand on voit comment les base de données sont douées en math on ferait mieux de les faire travailler à la place de nos langages de haut niveaux qui massacrent les décimales.
Donc en conclusion, antoine, je pense que ton amour de python te fait peut être un peu troller :-)
avec un tel galimatis on voit que l'on est bon pour avoir un chapître dans 01 informatique : chouette des consultants qui y savent tout sur rien vont bientôt nous expliquer comment faire du logiciel libre :)
Il semble que des malins ignorent que l'on peut faire du WIMP : Windows / IIS /mysql/php
A ce sujet, je viens de galérer une soirée entière à vouloir intégrer une base avec des fichiers (SQL/csv) qui ont foirés à cause de la limitation de la taille maximum d'une ligne dans un shell (et quand on importe un article spip, ça fait mal) ce qui fait foirer les mysql -utoto -ptoto toto < import.sql ou les INSERT ... avec data file. Ainsi je dis le phpmyadmin configuré par défaut c'est cool. (Phpmyadmin à configurer sur un WIMP c'est vraiment galère.
Pourquoi faire du wimp ? parce que c'est ça ou asp.net avec c#. Entre les deux, php est largement moins verbeux et plus efficace, même si je préfère encore perl. Seulement, autant il est facile de corriger un bug, autant les croyances c'est une autre affaire.
Donc comme je dois développer en PHP sous windows/IIS en ce moment, je vois vraiment l'intérêt d'un wampserver :) et je dis merci romain.
[^] # Re: merci
Posté par Jul (site web personnel) . En réponse à la dépêche Rétrospective du libre en 2007. Évalué à 2.
Tu penses à des dérives de société ?
http://www.libroscope.org/Benchmark-23-logiciels-libres
Ou l'éthique toc de nouveaux entrants d'une "certaine forme de libre allégée ?"
http://www.libroscope.org/Vers-une-liberte-definie-Creative
[^] # Re: merci
Posté par Jul (site web personnel) . En réponse à la dépêche Rétrospective du libre en 2007. Évalué à 2.
c'est libre c'est beau, alors pas de polémiques siouplait quoi
[^] # Re: Langages ne sont plus comparables en tant que tel
Posté par Jul (site web personnel) . En réponse à la dépêche Ruby 1.9.0 est sorti pour Noël. Évalué à 2.
Si si plus de bug, mais avec de grandes différences dans les écarts types. On peut traduire comme ceci, les meilleures équipes n'ont pas forcément plus de bugs, par contre, le temps de résolution est mécaniquement plus long (particulièrement si on a un bug dans le coeur d'une classe de base) et le risque de bug généré par la correction de bug augmente avec l'intrication du code. (on considère qu'une correction de bug à une chance sur deux de généré un nouveau bug par effet de bord).
Il y a les données dans complete coding de Steve Mc Connell.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Jul (site web personnel) . En réponse à la dépêche Ruby 1.9.0 est sorti pour Noël. Évalué à 0.
La productivité en informatique par développeur est :
0) indépendante du diplôme ;
1) indépendante de l'expérience au delà de 2 ans;
2) varie d'un facteur 1 à 10 par individu.
(Sackmann Grant et al)
L'informatique n'est pas une question de diplôme mais de créativité. Vu comment l'enseignement est dogmatique, particulièrement en école, j'imagine pas vraiment en quoi étudier résout les problèmes de facteur humain.
Ensuite d'organisation à organisation les variabilités de productivité sont encore d'un facteur 1 à 10.
La conclusion (Peopleware de Di Marco, Myhtical Man Month de F. Brooks, Complete Coding Steve Mc Connell) est que pour améliorer la productivité en informatique,
1) il faut recruter et bien recruter non sur les diplômes, mais miser sur des équipes, et
2) s'organiser non à la française (modèle héirarchique de base), mais dans des modèles plus organiques (par "atelier" par exemple)
Pour tout ce qui est technologie le meilleur gain de productivité hors concision du langage (qui peut faire gagner un facteur 6 par rapport au C en prenant un langage à typage dynamique (php/perl/ruby/python)) est au mieux de 10%.
Tu m'expliques en quoi se focaliser sur un gain de 10% est plus intelligent qu'un que s'intéresser à un gain de 1000% x 1000% ?
Aller, je t'aide combien de fois 0,1 faut il pour faire 100 ? Question subsidiaire, à quel point significatif est 0,1 / 100 si on garde les décimales ?
Pour les journaux, ça existe déjà :
http://www.codinghorror.com/blog/archives/000960.html
http://www.joelonsoftware.com/
C'est juste qu'aux états unis ils sont les leaders mondiaux de l'édition de logiciel, va savoir pourquoi ?
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Jul (site web personnel) . En réponse à la dépêche Ruby 1.9.0 est sorti pour Noël. Évalué à 1.
Oui, mais passer de c# ou de MS C++ à php ça reste la fête au village.
Et bizarrement, ce qui joue le plus est autant le typage dynamique, que la doc. Autant j'ai pu me battre avec php et ses problèmes énormes en encodage de chaine multi octet alors que c# se débrouille mieux, autant les man pages de c# sont inutilisables tant elles sont verbeuses et le code d'exemple digne d'un stagiaire. Php.net est quand même un bon référentiel documentaire.
Pour en revenir au facteur humain, mon plus gros problème en c# était que les fanas su langage pensait que "parce qu'ils avaient le meilleur langage" tout était résolu. Quand on vous présente les "dataset*" comme un ORM, vous avez peur. Le plus gros problème que j'ai pu rencontré en environnement windows est le manque de culture informatique. Et ça c'est pire que le mauvais langage.
Anecdote :
Chez un client : tout dans les pages asp était présenté en mettant les attributs de présentation en dur dans le code asp, (border=1px; color=blue...). Le truc casse couille pour modifier l'apparence, on agrééra. Client qui me parlait fort des bonnes pratiques, de la séparation du code et de la présentation etc ... Donc, j'ai utilisé les CSS. Et 3 jours plus tard je reçois un mail du directeur technique, pro de l'informatique qui m'enjoint d'arrêter en mettant en référence un lien sur un article de security focus "The danger of CSS". Evidemment, CSS ici voulait dire cross site scripting, mais lui a pensé Cascading Stylesheet : je lui cassais les couilles avec un truc qu'il connaissait pas, un petit tour de google, il lit pas l'article et me renvoie directement la référence. J'ai jamais pu lui faire valoir qu'il parlait pas de la même chose : si security focus a dit non aux CSS, alors pas de css.
Par contre quand je lui ai montré que l'on pouvait injecter du html arbitraire dans ses pages webs grace à textarea compréhensifs, il a pas vu le problème.
J'ai moults anecdotes de ce style qui me font penser que la culture informatique en entreprise est quand même faible, et que c'est bien le frein le plus important, plus important que le choix du langage.
Je vous raconte même pas php et l'utf8 sur un windows IIS mysql PHP.
Bref le choix du langage est pour moi un problème d'optimisation alors qu'en entreprise --souvent**-- tout est à faire. On chipote sur le langage alors que le facteur humain est largement plus bloquant
* http://en.wikipedia.org/wiki/Data_set
** oui il y a aussi de très bons professionnels, mais je suis souvent surpris de l'endroit où je les trouve.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Jul (site web personnel) . En réponse à la dépêche Ruby 1.9.0 est sorti pour Noël. Évalué à 0.
Dis moi, tu colles un langage vachement bien à un manager tu crois qu'il va faire du bon code ?
Que coder en ruby ou en python ou en java empêche les développeurs de mettre les réglages en dur dans le code et les oblige à faire des fichiers de conf ?
Enfin, on a les croyances que l'on veut. Il me semblait pourtant que les informaticiens étaient des scientifiques et pas des religieux.
Remarque quand les idéologues décident de faire du code on voit ce que ça donne : GNU/Hurd, je te laisse l'utiliser en prod, je vais continuer à prendre ces vieux trucs obsolètes de linux ou BSD qui sont si vieux et mal conçus (c'est vrai pas de micro-noyaux, pas de driver user space, pas de marketeux pour dire comment c'est bien) .
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Jul (site web personnel) . En réponse à la dépêche Ruby 1.9.0 est sorti pour Noël. Évalué à 1.
En fait, perl, php, ruby, pyhton sont équivalents en concision car ce sont des langages à typage dynamique. (cf complete coding / Steve Mc Connell)
La plus grande force d'un langage ne réside pas dans sa syntaxe ou ses structures de contrôles, mais dans les données. Plus les types de bases sont intéressants (comme la hashtable) plus leur manipulation est aisé (GC inclus) plus le langage est concis.
Et en plus tu réduis le développement au code or comme la doc de sloccount l'exprime si bien
http://www.dwheeler.com/sloccount/sloccount.html#cocomo
qui reprend les données de Harr/boehm : coder est une part minimal du développement.
Le reste c'est du déboguage, de la conception, de la compréhension du problème, de la doc, de la négociation ... Et même dans le déboguage la partie facteur humain passe devant le code. Alors comme notre boulot est minoritairement de coder, je vois pas pourquoi le langage est si important.
Remarque même si j'ai plus de plaisir à prendre un langage que j'aime comme tout le monde, le plaisir, le goût sont quand même pas des critères objectifs et absolus, ou alors j'ai loupé un cours de français. Donc pourquoi imposer son langage préféré alors que pour le client ça change rien d'autre que des emmerdes à devoir gérer un langage en plus.
Mais bon ton analogie avec les maths est bonne, car je viens de la physique, et je te laisse imaginer que je conçois que les langages informatiques sont à l'informatique réel, ce que les maths sont à la physique. Utile, mais pas ma tasse de thé. Je trouve que les matheux sont nécessaires, mais qu'ils ont rarement la structure de pensée pour résoudre un cas pratique réel. Bref un matheux a pour moi autant d'intérêt en physique qu'un amoureux des langages en informatique de production : c'est un idéologue au milieu d'un environnement de travail, une gêne quoi. Exactement ce que tu prouves en prenant une analogie sur des maths : que t'es pas orienté résolution de problèmes, mais esthète des technologies créateur de discussions infinies sur des coupage de poils de fesse en 4.
Bref, à mon avis, je crois que t'a pas compris notre métier.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Jul (site web personnel) . En réponse à la dépêche Ruby 1.9.0 est sorti pour Noël. Évalué à 0.
Au final, ma philosophie est que plus on me paie cher pour écrire dans un langage plus je suis volontaire pour le faire. C'est à mon avis le critère de choix pour utiliser un langage.
Ce qui fait que j'utilise presque tous les langages du marché et je ne les trouve pas foncièrement différents ; les erreurs dans les programmes sont plus souvent -à mon expérience- dans la conception d'une solution ou dans le choix de mauvais développeurs, que dans le choix, ou dans la syntaxe du langage.
Si vous préférez le langage est au développeur ce que le marteau est au menuisier. Rien qu'un truc, un machin, un outil. Sûrement pas le principal quoi. Donc un troll sur les langages qui n'est pas pour le fun, est un sujet de personne qui sont des esthètes de l'informatique, et entre nous un bon informaticien n'est pas là pour aimer l'informatique, il est là pour apporter des solutions. Et c'est pas avec le langage informatique, mais avec sa cervelle qu'on travaille.
Pour résumé : troll de langage = truc de geeks. Et je suis loin d'être convaincu qu'un geek ça fasse un bon développeur.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Jul (site web personnel) . En réponse à la dépêche Ruby 1.9.0 est sorti pour Noël. Évalué à 1.
la variation en productivité et en qualité, liées aux développeurs est supérieure à celle liées aux techniques informatique et managériale ou autres.
Un bon développeur fera toujours du bon code quelque soit le langage.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Jul (site web personnel) . En réponse à la dépêche Ruby 1.9.0 est sorti pour Noël. Évalué à 1.
J'assume préféré des langages, mais je ferais jamais croire que des critères subjectifs valent pour tout le monde.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Jul (site web personnel) . En réponse à la dépêche Ruby 1.9.0 est sorti pour Noël. Évalué à 0.
Il y a toujours des personnes pour se faire avoir <:o)
[^] # Python suce des ours, et ruby en tong dans le bac à sable
Posté par Jul (site web personnel) . En réponse à la dépêche Ruby 1.9.0 est sorti pour Noël. Évalué à 0.
Les données de Harr disent :
- le nombre d'instruction par jour est le même par développeur quelque soit le langage utilisé ;
- certains langage sont plus concis que d'autres (à condition de coder dans le langage);
De mêmoire si le C est une base référence :
C++ => 1,5 x plus concis
java VB => 2
perl/php/ruby/python => 6
à coté de ça :
le nombre de bug augmente plus que linéairement avec la taille, ainsi que le temps de développement
Conclusion
tout langage suffisamment concis devrait être favorisé.
Après tous les langages se valent tant que on respecte l'esprit de concision pour son problème :
C'est une question de goût et de contexte. Après le one best way to do it, est une erreur car tous les problèmes ne sont pas isomorphes. Si vous préférez un même chapeau ne va pas à tout le monde : on va pas sur un chantier avec un stetson, et au soleil avec un casque de chantier ...
Je préfère le perl ^^ parce que c'est concis est que l'on peut écrire littérairement du code. Pour moi le code est une rédaction littéraire que j'ai besoin de comprendre pour le relire, le modifier. En plus je me sens à l'aise car comme en français, j'ai la possibilité de pouvoir développer un style. Un programme, est une dissertation qui répond à la question comment résoudre tel problème. Nos codes doivent répondre à la question de la manière la plus lisible selon le style de l'auteur.
Chacun sa manière de coder, moi je code pas, je raconte une histoire, avec un argot, des tournures littéraires, en empruntant les meilleurs mots des autres, et ça m'éclate.
Tant que je m'éclate je continuerais à faire ce boulot, et je conçois que comme certains préfèrent le français à l'italien ou l'anglais à l'allemand on puisse se taper dessus pour des langages. Et c'est pour ça que j'adore les trolls de langage, ça reste des discussions de personne qui aiment au delà des langages la littérature.
Bref python, et ruby sucent des ours, le perl les écrase. Pas de troll ni de mauvaise foi, juste une constatation objective.
[^] # Re: Adaptation trahison
Posté par Jul (site web personnel) . En réponse à la dépêche Je suis une légende. Évalué à 1.
Excellent film quand même : )
[^] # Re: Adaptation trahison
Posté par Jul (site web personnel) . En réponse à la dépêche Je suis une légende. Évalué à 1.
Etoile au garde à vous (Heinlein auteur préféré des 68ards avec étranger en terre étrangère) par Verhoven qui devient starship trooper est une excellente adaptation.
C'est une critique velue de l'"allophobie" américaine (contexte : 1ere guerre d'Irak), ou même si le film prétend prendre le point de vue des gentils humains, verhoven leur colle des unifromes de nazis, tourne son film comme un film de propagande sauce deuxième guerre mondial, et sème le doute sur la méchanceté des aliens que l'on fait passer pour des insectes nuisibles. Un film fait pour vous rendre mal à l'aise, parce que vous vibrez pour des héros dont on vous fait deviner qu'ils sont peut être les salauds. Le message était : êtes vous sûrs que les aliens (étrangers) sont les méchants que l'on vous dépeints, et que nous sommes vraiment des héros ? )
Moi ce qui me casse les pieds c'est les auteurs qui ont pas de style, qui aplatissent le sens du film. En parlant de ça, Stephen king lui à eu le droit à de superbes adapatation de ses oeuvres dont le "shining" de kubrik qui est assez éloigné du bouquin. L'excellent "misery" de rob reiner (?)
Et toujours chez kubrick citons "blade runner" (tiré de est ce que les androïdes rêvent de moutons électriques de K Dick), et clockwork orange qui est aussi une adaptation d'un roman éponyme tronqué d'un chapître. Pourtant, la fin de K dick qui contredit le livre est bien plus intéressante.
Donc comme dans tous les domaines, pour qu'une adaptation soit bonne, il faut que l'adaptateur soit bon. Et le fait que le film soit commercial ou pas n'y change rien (argument fallacieux). Que les auteurs soient libres (argument fallacieux #2) de leur adaptations ne change rien au fait que leur film doivent être avant tout juger sur leur résultat. Parmi les exemples sus-cités il n'y a que des exemples commerciaux. ET (argument fallacieux #3) aucun film cité n'est une
adaptation parfaite.
Même total recall est une bonne adaptation de K Dick.
Donc tes arguments à la sauce zélote des creative commons, tu te les gardes. Car ce qui me casse les pieds encore plus que les mauvais oeuvres, c'est les gens qui réfléchissent non avec leur cerveau, mais à coup d'argument pré-formatés comme une propale de SSII.
[^] # Re: Adaptation trahison
Posté par Jul (site web personnel) . En réponse à la dépêche Je suis une légende. Évalué à 1.
[^] # Re: Et pour Python/Tkinter ? :)
Posté par Jul (site web personnel) . En réponse à la dépêche Sortie de Tcl/Tk 8.5.0. Évalué à 2.
Tout à fait mon bon monsieur, tel était l'esprit de ma phrase.
Malheureusement en Tk on ne peut pas "attacher" des données aux évènements, contrairement à GTK+ ou Qt qui intègrent le principe des signaux.
On peut mettre à jour des widgets (de manière limité) en fonction de la valeur de variables (option variable des widgets).
Il me semble aussi que comme le tie de perl on peut greffer des callbacks sur des valeurs.
Si mes souvenirs sont exacts, on peut donc simuler les signaux avec un variable ^^ surveillée.
[^] # Re: Warning : Commentaire superficiel
Posté par Jul (site web personnel) . En réponse à la dépêche Sortie de Tcl/Tk 8.5.0. Évalué à 2.
http://www.tcl.tk/software/plugin/applets.html
[^] # Re: Warning : Commentaire superficiel
Posté par Jul (site web personnel) . En réponse à la dépêche Sortie de Tcl/Tk 8.5.0. Évalué à 2.
J'ai eu fait des scripts en Tcl TK + C qui marchaient toujours 10 ans plus tard.
Le coté moche venait des choix par défaut.
A coté de ça, philsophiquement, tcl/tk est dans ma faible expérience le langage de scriptage qui a apporté la manière de programmer les interfaces graphiques la plus propre :
- gestion des GUI comme un gestionnaire d'évènement qui boucle ou chacun des éléments réagi grâce à des callbacks (c'est sûrement pas innovant, mais le html utilisé en GUI revient à faire de la gestion d'UI en séquentiel);
- proposition de "gestionnaire de géométrie" variés, souples et puissant, dont le célèbre pack orienté mise en page relative (je n'ai jamais utilisé que pack).
Par contre contrairement à ce que l'on imagine, le plus dur ce n'est pas la syntaxe, qui en un sens est proche de perl matinée de fortran (pour les tournures vieillotes comme set), mais la philosophie quand on fait du GUI qui est orientée évènement.
Ce langage m'a appris beaucoup de chose, je l'utilise plus (sauf parfois avec perl::Tk) cependant, je continuerais à le défendre car même si le web remplace presque bien les GUI client lourd, dès que l'on veut faire de l'évènementiel (comme avec ajax), le niveau de complexité dépasse de loin le tcl/tk. À quand le retour de l'utilisation du plugin tck/tk en lieu et place d'ajax ?
http://www.tcl.tk/software/plugin/
Par curiosité, essayez donc de faire une petite interface graphique vous verrez à quel point ce langage est puissant pour ce domaine.
[^] # Re: Perl, quel utilisation ?
Posté par Jul (site web personnel) . En réponse à la dépêche Sortie de Perl 5.10.0. Évalué à 2.
L'objectif de parrot 6 est d'être comme comme une jvm qui saurait faire du système ?
(non parce que java est le système c'est un peu léger si mes souvenirs sont exacts.)
Est ce que cela veut dire que perl va proposer de fait une abstraction du système avec des concepts évolués de threading, de droit ... ?
http://search.cpan.org/dist/Perl6-Bible/lib/Perl6/Bible/S17.(...)
qui seront portés de système à système. Mais cela sera pas dans parrot non ?
Juste curieux.
[^] # Re: Perl, quel utilisation ?
Posté par Jul (site web personnel) . En réponse à la dépêche Sortie de Perl 5.10.0. Évalué à 1.
Au moins il me semble que mysql implémente IEEE Std 754-1985
[^] # Re: Perl, quel utilisation ?
Posté par Jul (site web personnel) . En réponse à la dépêche Sortie de Perl 5.10.0. Évalué à 1.
.net est fâché avec les nombres. Je me souviens de la classe utilisée pour récupérer les entiers retournés par les requêtes en bases en .net 1.1 avec visual c++ qui retournait un entier natif alors que le type en base était en entier compris entre 0 et 10^13 mes programmes plantaient. J'ai fin par passer à la regexp pour contourner le problèmes.
Leurs docs sont tellement illisibles que j'ai renoncé à :
1) comprendre pourquoi les objets int de taille arbitrairement long n'était pas facilement accessible dans le langage de base
http://msdn2.microsoft.com/de-de/library/ms173104.aspx
2) pourquoi il y avait pas un lien vers ce genre de bibliothèque
http://search.cpan.org/~tels/Math-BigInt-1.87/lib/Math/BigIn(...)
ou un numerical recipies ?
C'est la base non ?
Comme tous les langages il est extensible, pourquoi il y a pas un cpan like ... un truc moderne de gestions d'extension quoi ?
<generalisation hâtive>
Le c# est pas mauvais en soi, mais c'est juste que je trouve qu'il y a un bon nombre de codeurs de ce langage qui ont tendance à réinventer la chaise dans leur coin, et à imaginer que parce qu'ils peuvent acheter des bibliothèques oops pardon ils disent des librairies, il doit forcément il y avoir une bibliothèque qui le fait.
</>
Là où je veux en venir, c'est que pour moi la force d'un langage vient aussi de sa communauté et de ses pratiques, et que comme tu viens de l'illustrer résoudre un problème d'informatique consiste parfois à réfléchir en dehors du langage.
Néanmoins sur le sujet du fortran et des NumericalRecipies qui ont quelques siècles*hommes derrières elles de dév et test, je crois pas qu'un langage jeune comme python/perl/php/ruby/java/c# peut les concurrencer. On ne construit pas une pyramide en un jour.
Donc je pense toujours que le fortran est aussi peu mort que le perl. Juste pas très utilisé. Comme perl le devient.
PS : arrête de montrer mes lacunes en développement c'est drôle quant tu reprends les autres, mais c'est vexant quand ça m'arrive.
[^] # Re: Perl, quel utilisation ?
Posté par Jul (site web personnel) . En réponse à la dépêche Sortie de Perl 5.10.0. Évalué à 1.
Des petits programmes qui font à ma place rapidement des choses d'informaticien ordonné qui m'ennuient : un rangeur de mp3 dans mon disque en fonction des infos, un chargeur de clés usb avec des fichiers pris aux hasards sur le disque, un bot web pour draguer, un surveilleur de logs proactifs ...
Ses points forts les modules CPAN, les perls mongueurs
Son point faible aujourd'hui : le rapport signal bruit dans les modules cpan
Ex il y a une demi douzaine de classe pour faire de l'objet propre, mais tous sont maintenus à des degrés divers, et c'est carrément l'enfer pour les trouver évaluer le plus stable tellement la logique de rangement me dépasse.
Exemple
http://search.cpan.org/~jdhedden/Object-InsideOut-3.35/lib/O(...)
http://search.cpan.org/~dconway/Class-Std-v0.0.8/lib/Class/S(...)
http://search.cpan.org/~swartik/Class-Generate-1.10/Generate(...)
http://search.cpan.org/~abw/Class-Base-0.03/lib/Class/Base.p(...)
Et aussi et surtout
http://search.cpan.org/~stevan/Moose-0.33/lib/Moose.pm
[^] # Re: Perl, quel utilisation ?
Posté par Jul (site web personnel) . En réponse à la dépêche Sortie de Perl 5.10.0. Évalué à 1.
Je discutais avec des gars de labo physique et il disait qu'ils revenaient des python/perl/ruby ... pour les calculs. La numerical recipies (un livre de recette algorithmique pour les calculs sur ordinateur qui a donné lieu à une bibliothèque logicielle homonyme) et le parallelisme restent inégalés en fortran. Non tant par les fonctionnalités, que par la maturité autant dans ses usages que de son implémentation de la bibliothèque.
Mes derniers égarements en c# m'ont permis de voir que pour les calculs en virgule flottante, 10 000 * .196 (la TVA) donnait des chiffres non nuls après la 5éme décimale par exemple, je ne parle pas de PHP, et pour perl le cpan doit proposer 3 bibliothèques pôur faire ça. De plus, ils manquent des bonnes bibliothèques pour les matrices creuses, des algorithmes de réduction de matrice en forme LU par exemple mais aussi des moyens de renvoyer les marges d'erreurs.
Mon opinion partielle et partiale est la suivante
1) il n'y a pas de bon langage, il y a de plus ou moins bons programmeurs qui connaissent l'état de l'art (j'ai encore à bosser sur le sujet, je sais ^_^) ma préférence va à tous les langages concis à la base (perl/php/python/ruby)
2) il faut utiliser les langages les plus adaptés à chaque taches, car ruby pour faire du bas niveau est peut être pas adapté, et coder une application web en postscript est peut être pas efficace. Si pour une tâche plusieurs langages sont équivalents, alors choisir le plus concis.
3) parfois quand on voit comment les base de données sont douées en math on ferait mieux de les faire travailler à la place de nos langages de haut niveaux qui massacrent les décimales.
Donc en conclusion, antoine, je pense que ton amour de python te fait peut être un peu troller :-)
[^] # Re: Vamos a bailar calypso mi amor
Posté par Jul (site web personnel) . En réponse à la dépêche Le consortium QualiPSo organise la première conférence internationale sur la qualité des Logiciels Libres. Évalué à 4.
[^] # Re: [^]Re: "reproduire fidèlement votre serveur de production en local"
Posté par Jul (site web personnel) . En réponse à la dépêche Forum PHP 2007 : Annonce de la sortie de WampServer 2. Évalué à 1.
A ce sujet, je viens de galérer une soirée entière à vouloir intégrer une base avec des fichiers (SQL/csv) qui ont foirés à cause de la limitation de la taille maximum d'une ligne dans un shell (et quand on importe un article spip, ça fait mal) ce qui fait foirer les mysql -utoto -ptoto toto < import.sql ou les INSERT ... avec data file. Ainsi je dis le phpmyadmin configuré par défaut c'est cool. (Phpmyadmin à configurer sur un WIMP c'est vraiment galère.
Pourquoi faire du wimp ? parce que c'est ça ou asp.net avec c#. Entre les deux, php est largement moins verbeux et plus efficace, même si je préfère encore perl. Seulement, autant il est facile de corriger un bug, autant les croyances c'est une autre affaire.
Donc comme je dois développer en PHP sous windows/IIS en ce moment, je vois vraiment l'intérêt d'un wampserver :) et je dis merci romain.