Philippe F a écrit 2214 commentaires

Ca ressemble un peu a topcoder aussi, sauf que le niveau des solutions de topcoder est autrement plus eleve que les solutions que j'ai pu voir jusqu'a present...

Moi je connais l'intérêt de coder en php. Ça permet de garantir ton boulot de webmestre à vie. Ou ça permet aux SSII qui repassent derrière de se faire un max de pognon. Ça permet aussi à tous les neuneux qui débarquent sur le marché du travail d'en trouver facilement et de créer plein de nouveaux emplois.

Vraiment en ces périodes de crises, PHP, c'est le langage qui va vous permettre de passer à côté de la charrette.

C'est un peu naïf comme vision. Je fais un logiciel libre et une foule de développeurs va se ruer dessus pour contribuer du code, des correctifs, le porter sur 23 plate-formes !

C'est pas du tout comme ça que ça se passe et on retrouve régulièrement des auteurs de logiciel libre très très déçu par le niveau de contribution extérieur.

Avec un résumé pareil, ça ne me donne pas envie de lire. J'espère que ce n'est pas une thèse bourrée de raccourcis à deux balles comme celui-là.

Donc, si on résume, Linux est sensé aller beaucoup plus vite avec toutes ces modifications !

Il accélère aussi l'internet ?

Genre porter du code écrit pour Windows 3.1 et Borland C++ vers Vista / Visual Studio la dernière version qui va bien ?

Gérer des incompatbilités de machines parce que le client fait toujours tourner Windows 95 (ou Linux 2.2.12) et que pas de bol, ta lib sur laquelle tout ton programme repose est super récente ?

Corriger les bugs dans une lib OpenSource que ton projet utlise, lib qui n'est plus maintenue depuis 5 ans ?

Faire une vrai programme ou tu jongles avec une 10aine de lib extérieures et ou il y a des conflits à la con, qui doit marcher dans une environnement hétérogène ?

Depuis quelques années, on voit décroitre peu à peu la popularité de Perl au profits d'autres langages, tels que Ruby et Python :

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.(...)
https://www.ohloh.net/languages/compare?commit=Update&l0(...)


Je suis curieux de savoir si cette constatation est vérifiée sur le terrain par les perleux. Est-ce que à des évènements comme les journées perl, il y a moins de monde qu'il y a 10 ans où est-ce que la population des perleux s'est stabilisée , voire augmente encore ?

Ce qu'on peut aussi interpréter comme un autre type de question : est-ce que les nouveaux pythoneux et rubyeux "volent" à la population des "perleux" ou est-ce que ces populations viennent d'une source différente ?

Un copain qui bosse dans les télécoms m'avait expliqué ça. En effet, Linux renégocie tout ce qu'il peut pour profiter de la liaison au maximum, tel que c'est proposé par le protocole TCP. Commes les autres OS ne le font pas, il se retrouvent vite de côté niveau débit.

Pour les avantages par rapport à Swing, je pense que tu as cité le principal : c'est beaucoup moins complexe.

Il y a besoin de beaucoup beaucoup moins de code pour faire la même chose. D'où gain de temps phénoménal en développement. Pas besoin d'une classe anonyme pour mettre en relation deux objets.

En ce qui me concerne, à chaque fois que je fais du java, c'est là que je souffre : c'est verbeux, verbeux, verbeux. Et que je te crée 10 classes pour faire un truc super simple.

Il me semble aussi que les interfaces Swing sont poussives (pour rester poli) alors que Qt est en général plutôt très réactif.

Après, si tu es super à l'aise dans Swing et que tu trouves que c'est extraordinaire, Qt ne te fera surement pas changer d'avis car c'est différent.

Pour les signature signal/slot vérifiés au runtime, c'est un compromis qui permet de garder pas mal de souplesse dans Qt. D'autres lib comme boost ont fait un compromis différent et connectent des signaux et des slots avec verif à la compilation, au prix de moins de flexbilité au runtime.

Je suis tout à fait d'accord sur le problème de fond, ça fait très peu crédible.

Il reste un gros travail de définition de suite de test pour valider l'interopérabilité des formats et leur utilisation correcte dans du code.

Pour participer à certains comités ISO ou à regarder d'autres efforts d'unification (xdg, browser et html, ...), la situation est pourtant assez courante et semble être un chemin naturel quoique désagréable de tout effort de coopération et de standardisation.

Ca commence toujours par merder avant de converger. C'est bien pour ça qu'on parle d'effort de standardisation parce que ce n'est pas du tout du tout naturel.

Cela dit, il semble que ODF aie suffisamment de monde derrière pour devenir un vrai standard, contrairement à OOXml qui n'a que Microsoft (ce que fait beaucoup de monde certe) et ne peut prétendre à ce type d'interopérabilité.

Il me semble qu'il y a quelques années, on percevait un essoufflement net dans le développement de gcc et on avait l'impression qu'il était plutôt à la ramasse sur pas mal de sujets (vitesse de compilation, temps d'exécution, ...).

Depuis le 4.0 et ces derniers temps en particuliers, le compilateur a repris du poil de la bête. En plus, ca le fait trop d'avoir une optimisation unique au monde à la pointe de la recherche, qui explose de 30% des benchmarks !

Longue vie à gcc alors. Et sinon, le code interne est toujours aussi atroce ? Des dires de ce qui avaient regardé, ca faisait plutôt peur.

Ca m'épate ce trait de personnalité qu'ont certaines personnes, où toute action qui se produit autour d'eux est convertie en "le monde est maiiichant, regardez comme on me fait du mal". Souvent d'ailleurs, elles appelle à ce qu'on pleure sur leur sort. C'est la seule réponse acceptable. Si on ne le fait pas, soit on est méchant, soit on ne comprend pas à quel point ils souffrent ou leur situation est désespérée.

Personellement, ce comportement m'exaspère.

Je ne supporte pas les gens qui appellent comme cela à la plainte. La vraie détresse, elle est beaucoup plus violente et tord le bide. Elle n'a rien à voir avec leur pauvre parodie de malheur.

C'est bien la preuve que c'est devenu un libriste de droite. D'ailleurs, il s'est inscrit à l'epita cette année.

Moi, je dirai que celui de gauche voudrait bien emmerder celui de droite, mais dans les faits, c'est ce dernier qui enc*** le premier.

Si je résume ton point de vue :

- si on clique sur "inutile", ça veut dire que ton post nous déplaît et "on a que ça comme réponse". Sous-entendu, on est demeuré ? on a aucun esprit critique ? On est pas capable de s'élever à la hauteur de ta pensée ?

- tu nous fais la description d'un personnage qui est "très représentative de l'idéologie d'une grande majorité des utilisateurs de ce site". Ouah. T'es fort, t'a réussi sans même faire un sondage à résumer l'état d'esprit des 36801 personnes qui ont un compte ici (cf https://linuxfr.org/stats/utilisateurs.html ).

- si on te montres un contre-exemple de caricature, tu ne regarderas que la note du journal pour l'analyser. Je cite "Comme ça, cela me confortera dans mon idée lorsque je verrai la note du journal".

- "je me suis quand même inspiré de ce que je vois au quotidien". Bon, donc tu as rencontré une grande majorité des 36 000 utilisateurs de linuxfr et tu as analysé leur couleur politique et leurs études. Est-ce que tu n'aurais pas plutôt fait une généralisation à deux balles ?

- "Mais la note montre que les gens qui se reconnaissent dans cette caricature sont nombreux ici et n'apprécie guère que l'on se moque d'eux." Donc en fait, toutes les personnes qui ont voté "inutile" se sont forcément reconnues et ont été vexée. Merde, il est temps pour moi de courir à l'Epita pour m'acheter un diplôme !

En tout cas, ca distrait mon mardi après-midi.

Tu es sur de ton coup ? Ils n'utilisent peut-être plus le JIT de llvm, mais ils continuent à emettre de l'IR llvm non ? Ils utilisent bien llvm comme backend C, JVM ou CLR ?

Il y a une mailing list dédiée au sujet. Il suffit d'aller lire les archives :

http://mail.kde.org/pipermail/kde-scm-interest/

Quand les gens parlent de closure, on a toujours l'impression qu'on parle d'un concept révolutionnaire. Je suis déçu de constater que on peut émuler ça trivialement avec des objets, alors que c'est en général un des premiers avantages mentionnés par les afficionados de Ruby.

Il y a pas mal de fonctionnalités de python me font beaucoup plus triper que ça, et qu'on ne peut pas émuer avec 3 autres lignes de code. Au hasard, le typage dynamique, le changement dynamique de classes d'une instance à la volée.

J'ai beau lire et relire la littérature sur les closure, je comprends vraimant pas ce que ça apporte de miraculeux.

C'est une fonction qui peut être exécutée dans un contexte. Ouai, cool, mais je vois pas la différence avec une fonction qui prend un argument. Ah oui, on peut stoker la fonction. Mais en dehors du pascal, vous connaissez beaucoup de langages où on ne peut pas stocker une fonction ?

En lisant toujours, il semblerait que la force des "closure" soit de les associer avec un contexte persistent, et que l'ensemble fasse un objet plutôt intelligent. Bon, je peux imaginer que c'est pratique.

Si j'essaye de formaliser ça à ma façon, ça donnerait :

# on fait une closure en python
def get_threshold_tester( threshold ):
....def threshold_tester( a ):
........return a >= threshold
....return threshold_tester

f = get_threshold_tester( 10 )
f( 11 ) -> True
f( 9 ) -> False


Et ça, ça remplacerait avantageusement :

# on fait une closure en python mais on oublie que python sait faire des closure simplement

class ThresholdTester:
....def __init__( self, threshold ):
........self.threshold = threshold

....def test_threshold( a ):
........return a >= self.threshold

v = ThresholdTester( 10 )
v.test_threshold( 11 ) -> True
v.test_threshold( 9 ) -> False


Bon, je ressens pas un gain énorme. C'est certes plus concis avec une closure, mais je sens que le miracle de la programmation avec closure va continuer à m'échapper.

C'est fou ce que ca fait du bien d'entendre quelqu'un qui est pragmatique concret, clair. "IsNotGood, dans mes bras!" (bien que ça fasse plutôt référence à une autre BD).

Et oui, faire du libre, c'est sympa, gagner de l'argent avec, c'est très difficile et ca demande d'être autrement plus pragmatique que la majorité des défenseurs du logiciel libre.

KDE va migrer vers git un de ces quatre. L'argument le plus déterminant semble être les fonctionnalités avancées de git, comme le cherry picking, les annotations, ou des histoires de conversion de repository beaucoup mieux supportées par git que par mercurial.

KDE a un historique de décisions basés sur des arguments techniques vraiment travaillés. Il y a eu plusieurs propositions pour tenter de faire avec mercurial ce qui est fait avec git mais sans succès. Il semble que KDE a des besoins vraiment spécifiques en terme de repository.

Et clairement, git est beaucoup plus populaire chez les développeurs. Dommage (de mon point de vue).

Guido souligne d'ailleurs dans son post que tout choix est subjectif. De même que l'ajout ou non d'une fonctionnalité donnée à Python. Il lui arrive de prendre des décisions qui vont à l'encontre de la majorité, en se fiant à son instinct. Vu que ca a mené python à un endroit pas trop mal aujourd'hui, je continue à lui faire confiance.

En plus, j'adore mercurial.

Ca m'agace ces news où on parle d'un logiciel avec des caractéristiques très intéressantes sans pour autant préciser que celui-ci ne fonctionne qu'avec un langage bien précis. Genre c'est évident pour tout le monde !

Ce qui est intéressant, c'est que TomTom reconnait par ce geste implicitement la force de l'OIN et en même temps, le renforce encore.

J'ai l'impression qu'on va se diriger côté brevet vers un cessez-le-feu à coup d'accord de ce type dans tous les sens.

Même si PyQt ne passe pas en GPL, la licence ne coûte que 300 livres. C'est dans le budget d'une PME.

Quand même, je pense que globalement, les exemples et le logiciel même feraient plus professionnels si tu incluais la sécurisation des clés locales de façon automatique. Rajouter les quelques commandes pour gérer un fichier crypté truecrypt pour stocker tes « ordres » et les exécuter, c'est un poil plus compliqué certes, mais ça fait tellement plus sérieux.