Jul a écrit 783 commentaires

oui je suis d'accord, il y avait dans les 2 premiers cas une erreur de syntaxe, mais bon, à mon goût un bon programme crash sur une erreur.

Pour les options de compilations j'ai pas regardé. C'étaient 2 debian, mais je soupçonne que les sources apt étaient pas les même. Le projet étant charrette, et devant gérer des merdouilles sièges clavier (mienne comprises) tout le temps, le sysadmin qui sommeille au fond de moi n'a pas pu investiguer.

Néanmoins, même si j'aurais bien aimé comprendre, après m'en être ouvert à d'autres anciens collègues qui ont quitté le PHP j'ai eu des échos de soucis similaires.

Bien qu'en tant que mercenaire je fais du PHP avec plus de plaisir que du C#, cependant il faut reconnaître que PHP est chiant à cause de ses changements de comportements aléatoire :
ex :
sur deux PHP 5.3.2 j'ai eu les changements de comportements différents sur le même code :

cas 1 trim change de comportement :
$a=array ("a " => array ( "b" => " c ") );
v1 : trim ($a) => array ("a" => array ("b" => "c" ))
v2 : trim ($a) => array

cas 2 implicit explicite :
avec mes php.ini identiques j'ai eu le code suivant qui a marché un cas sur deux
class log {
private $cfg;
private function w($msg) { $cfg["insource"] && echo "<!-- $msg -->" }
}
Dans un cas php a pardonné que j'oublie $this->cfg
dans l'autre il a fait un warning sans crasher :/ J'aurais mis du temps à trouver le bug si j'avais pas regardé les logs

Et j'ai un 3 éme bug sur le changement de comportement des fonctions de localisation que je ne détaillerais pas.

Et ceci sur deux versions de PHP identiques sauf au niveau du patchlevel :/



Donc même si il y a des frameworks (cake/symfony) en php je pourrais pas faire entièrement faire confiance à un framework aussi bon soit-il quand l'interpréteur est aussi versatile.

PS ce n'est pas parce qu'en logiciel libre on utilisait pas le jargon de framework au début que
1) il n'existait pas (leur existence remonte à 1990 notamment dans les GUI notamment propriétaire, et dans la littérature dans les années 1986),
2) le MVC est un design pattern : une façon de concevoir son code en séparant la vue des données. Un DP ne nécessite pas de code normalement, juste de bien concevoir son code. Mais bon quand il y a un "cadriciel ou framework" faut être maso pour s'en priver.

ben oui, mais regarde les premières pages d'il y a 8 ans, ça sentait pas autant la pub et le coté pravda linuxfr, et comme c'est nous qui faisons les news .... :(

C'est nous qui changeons.

sauf peut être moi :)
Je ne veux pas devenir un consommateur, et je pense toujours pas que le libre c'est la panacée, juste que ça me plait

Maintenant qu'on est est devenu riche et prescripteur c'est fou toutes les pubs et communiqués de presse que l'on prend sur linuxfr.

Libre 2.0 = 01 informatique.

Je dis ça mais comme c'est libre c'est bon, hein ?

Et quand France Telecom paie les yeux de la tête pour avoir du coaching fait par des sectes, c'est pas mal non plus ?
http://www.lemonde.fr/web/article/0,1-0@2-3208,36-850077,0.h(...)

Aucun rapport (pas l'entreprise dont il est question ci dessus) mais c'est juste pour que vous puissiez jugés des prix et contenus <:o)
http://www.verteam.fr/img/cat-coaching.pdf : 2000€ / jour

Le coaching c'est 22Milliards d'euros de flux financier annuel. Le prix au kilo est encore meilleur il avoisine l'infini.

Si Stallman faisait payer ses conf à 30k$ ça prouverait que dans le libre on sait être compétitif

ces deux sont évidemment mal placés et devrait être ici
http://linuxfr.org/2008/01/16/23575.html#896656

oui, mais bon, je préfère les retours discrets des utilisateurs de freebsd/openbsd tel que altéon. Altéon dont les rares sysadmin pros que j'ai rencontré trouve qu'il est une excellente alternative au "je fais tout moi même" pour le loadbalancing web, et qui contribue en retour.

De l'autre en linux/GPL je trouve qu'il y a beaucoup de posture dans la contribution :
- intel/SUN qui prétendent faire le jeu du libre, et qui oublient d'ouvrir les specs matériel importantes ;
- parlons pas du pitoyable spip agora fork hostile, et contre productif d'un projet libre ;
- pour ceux qui ont du utiliser l'outil samba ldap d'idealix qui par le passé (je l'ai pas regardé depuis 2 ans) était en shell script imbitable, non utilisable, ni réutilisable .... c'est sous GPL, mais qu'est ce que ça vaut ?

Quand je vois tout ça, j'appelle pas faire ça du libre tellement le coût pour s'approprier (utiliser, modifier, étudier) les technologies/codes soit disant "libérés" sont élevés.

Je parle de ce que j'ai vu... hein.

Tout ça pour dire que c'est pas parce que la communauté BSD a pas autant de contributions tapageuses éditées sur linuxfr qu'il n'y a pas de retour. Et d'autre part, mieux vaut une petite communauté concernée et active sur un projet pas trop visible pour avancer. Parce que quand un truc libre devient à la mode, c'est parfois dur d'avancer dans la marée de pipotron à la 01 informatique qui se met à apparaître.

Donc oui BSD permet de faire du propriétaire, et c'est pas plus mal car toute l'informatique en profite (windows s'améliore en prenant du code BSD) http://www.pcinpact.com/actu/news/29117-ALSR-une-securite-de(...)
et non rien n'empêche de faire du propriétaire sous licence libre.

PS je suis linuxien certes, mais je vais pas taper sur BSD pour de mauvais arguments : ils ont juste pas urbanterror qui tourne à une cadence convenable avec leur OS.

c'est un troll de licence.

Ce qui gêne la capacité d'une entreprise à gagner de l'argent, c'est uniquement le manque d'intelligence de son patron.

Les français sont bien capables de vendre de 1l d'eau de source plus cher que le galon de pétrole aux américains, et en plus ça marche.

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.

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

bref le monsieur avait raison:
c'est libre c'est beau, alors pas de polémiques siouplait quoi

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

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 ?

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.

pour sortir une remarque pareil ....

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.

en terme de ce qui importe en informatique, c'est à dire la concision, oui. Le reste c'est une question de goût.

J'assume préféré des langages, mais je ferais jamais croire que des critères subjectifs valent pour tout le monde.

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.

ah vi ^^
Excellent film quand même : )

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.

Regardez les démos :) le plugin marche toujours

http://www.tcl.tk/software/plugin/applets.html