Jul a écrit 794 commentaires

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

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.)

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.

PPS
Au moins il me semble que mysql implémente IEEE Std 754-1985

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

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.

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

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

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.

Si c'est immoral. La morale est un sens personnel de ce qui est juste.

Et si le développeur n'a pas apprécié, on peut au moins considéré que cela n'est pas moral de son point de vue

justice != morale != justice.

Quand on prend le code de quelqu'un d'autre, on peut faire primer la moralité sur le droit :
http://www.libroscope.org/+Linux-droit-et-moralite+?var_rech(...)

C'est ce que fit linus avec le développeur webcam philips.

Ce n'est pas parce qu'il est nécessaire de s'emmerder avec le droit et les licences, que nous devons concevoir les relations entre communautés/développeurs du strict point de vue de ce qui est faisable juridiquement.

Le logiciel libre vaut surtout par sa communauté, et une communauté puise sa force dans ses relations.

A titre perso, le droit, les licences me gavent, par contre j'aime bien les personnes, alors je trouve plus intelligent la résolution humaine des problèmes.

Juste pour voir ces derniers temps je fais du c#. Et au vu de ce qu'annonce l'article il n'y a pas de doute : microsoft ne va pas se faire des amis chez ses propres clients.

Au monde du chapelier fou, les dév, et les admins rigolent déjà pas mal :

Vulnerability in Vector Markup Language Could Allow Remote Code Execution (938127)
Vulnerability in Microsoft Excel Could Allow Remote Code Execution (940965)
http://www.securityfocus.com/brief/569

Et oui, n'ouvrez pas une feuille de calcul ou un dessin vous risquez d'être infectés :)

Ici un problème en soap :
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=179808(...)
Celle ci est pas mal :

.NET Serialization traps and flaws
SOAP Formatter
• When string values contain non-displayable symbols with certain numbers, receiver crashes on attempt to deserialize data
• DateTime objects serialization behaves wrongly, when sender and receiver are in different time zones

La date comme indiquée dans l'article est une plaie sur MS.
Et un dev se pose la question légitime :

So, XML string escaping is not implemented properly yet, am I right?

Pour développer en C#, je peux vous affirmer que c# est :
- sous doué pour les maths (non vous ne pourrez pas trouver de bibliothèques de coeur pour les entiers de tailles arbitraires),
- sous doué pour les dates (le système gérant la représentation en fonction des locales) ;
- sous doué pour les encodages MIME ;
- assez versatile : par exemple en .Net 1.1 (je prends pas de risque en 2.0), quand on passe à une fonction prenant des argument variables plus de 3 arguments, on est pas sur qu'ils soient tous passés.


Au rang des joyeuses loufoquerie, je travaille sur leur CRM, si il est installée sur un serveur en français, toute l'API d'interrogation SOAP change. Un peu comme si installer un serveur SQL en français vous obligeait à modifier votre code pour écrire
Selectionner * de table où nom COMME 'bill%'

Pour les dévs c'est déja le calvaire, j'ai du mal à imaginer qu'ils vont garder leurs clients avec OOXML


Par contre, malgré tout ça, les clients ont peur que le monde soit vachement compliqué si il quittent MS. Là je suis surpris quand même. Ils ont jamais osé essayé les trucs libres, mais ils se disent que MS qui est vachement bon, c'est tellement compliqué, que forcément ailleurs, ça doit être pire. Au point que j'ai un client qui préfère perdre 10 minutes par jour à rouvrir fermer le même fichier de log avec notepad plutôt que d'utiliser le tail installé sur sa machine.

http://l.cligny.free.fr/prumpleffer.html
Je penche pour le niveau fcold

whois :

Domain Name:NOVAFORGE.ORG
Created On:01-Sep-2005 11:44:34 UTC
Last Updated On:26-Apr-2007 14:22:12 UTC
Expiration Date:01-Sep-2008 11:44:34 UTC
Sponsoring Registrar:Melbourne IT, Ltd. dba Internet Names Worldwide (R52-LROR)
Status:CLIENT TRANSFER PROHIBITED
Registrant ID:B112532777147265
Registrant Name:BULL SA
Registrant Street1:Comptabilite Fournisseurs
Registrant Street2:26 rue du Nid de Pie
Registrant Street3:
Registrant City:ANGERS CEDEX 01
Registrant State/Province:-
Registrant Postal Code:49008
Registrant Country:FR
Registrant Phone:+33.130807890
Registrant Phone Ext.:
Registrant FAX:
Registrant FAX Ext.:
Registrant Email:philippe.elbaz@bull.net
Admin ID:B112532777147262
Admin Name:Philippe Elbaz
Admin Street1:Comptabilite Fournisseurs
Admin Street2:26 rue du Nid de Pie
Admin Street3:
Admin City:ANGERS CEDEX 01
Admin State/Province:null
Admin Postal Code:49008
Admin Country:FR
Admin Phone:+33.130807890
Admin Phone Ext.:
Admin FAX:+33.130807109
Admin FAX Ext.:

Ceci explique peut être cela.

J'aime bien, yet another freshmeat :) avec auto promotion inside.

et le compte du posteur ouvert de la news :) sur linked in
http://www.linkedin.com/in/jeanchristophespilmont

Jean-Christophe Spilmont
Marcom Manager at Bull
France
Current
* Marketing Communication Manager at Bull

Je me demande si parfois les industriels ne prennent pas les gens du logiciel libre pour des espèces de pigeons.

Leur truc c'est un peu comme si un industriel rachetait un journal, et qu'il ne comprenne pas pourquoi on doute que le journal va dire du mal de lui.

Indépendance 0
crédibilité 0

C'est pas pire que les entreprises du libre qui décernent régulièrement dans leur manif joujoue des prix à leur clients (ne regardez pas dans une direction, j'ai vu faire ça si souvent ces dernières années que ce sera pas fair play d'en citer un plus que l'autre)

aux us où les portables sont implantés depuis 2 ans on tire le constat suivant :

[...] a study in March by the U.S. Department of Education found no demonstrable link between educational software and higher test scores, putting laptop advocates on the defensive. A stream of news articles focused on school districts in New York and Florida that dumped laptop programs, citing high costs, misuse by students and the unfavorable results raised in the federal study.

http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2007/06/07/(...)

Gageons que ce constat est extensible au de l'informatique

et matrox (G200/G400) ?Du vrai multihead propre !

Leurs specif étaient dispo du coup le driver framebuffer étaient pas un blob sans nom lui au moins ^_^

(ça date de 1999 quand même)