J’ai toujours trouvé l’anglais supérieur au français dans sa logique générale, pour plein de raisons, ce « problème » de genre en français en est une de plus…
Ah ben justement, l'Anglais n'est pas spécialement meilleur que le français pour le coup. D'ailleurs, les notations de type « s/he » sont courantes justement parce qu'adresser le genre est aussi un problème en langue anglaise. Il existe une forme grammaticalement correcte, mais apparemment peu usitée, qui est d'utiliser « they » comme forme neutre, mais pas mal de profs anglophones la considèrent comme incorrecte (soit parce qu'ils n'ont jamais appris cette règle de grammaire, soit qu'ils la considèrent désuète). Du coup, ça donne des bouquins, par exemple le jeu de rôle « Vampire: The Mascarade » qui en v.o. (et peut-être aussi en v.f. ?) ont pris le parti de tout accorder au féminin — « When the vampire rises, she … », etc.
Quant à la « logique en général » de l'anglais, si la langue me semble au départ plus simple à apprendre que le français, elle montre son manque de cohérence dès qu'on désire parler de façon un peu subtile/avec des constructions un peu complexes. C'est valable tant pour la prononciation que pour l'orthographe ou la grammaire. Ça n'en excuse pas les défauts du français1 en terme de constance et de cohérence bien entendu.
Si j'ai bien compris, avant que Richelieu ne s'en mêle, la règle était d'accorder les phrases en fonction de la proximité avec la dernière composante du sujet. Exemple : « Le camion et la voiture sont vertes. » vs. « La voiture et le camion sont verts. » Personnellement ça ne me dérangerait pas qu'on revienne à cette règle, même si ça me demanderait un peu de temps pour m'adapter. ↩
Tu as bien entendu conscience que du Fortran 77 ça se trouve encore dans des codes relativement modernes dans l'industrie hein ? :-)
Pendant ma thèse (entre 2006 et 2010) j'ai bossé sur des codes en Fortran. TOUS étaient écrits au mieux en Fortran 90. Sur quatre codes industriels, deux étaient écrits en F77. Et il s'agissait d'ISV, donc leurs clients faisaient aussi du code qui se servaient du leur. Certains réclamaient de se conformer à la norme IEEE 754 strictement, même si les nouvelles archis/les nouveaux compilos sont capables d'aller jusqu'à 80 bits de précision (parce que ça passe pas les tests unitaires du client sinon).
Autre exemple con : dans les cours d'info, lorsqu'on enseigne le C aux étudiants, beaucoup, beaucoup de profs continuent d'enseigner C89. Alors que depuis on a eu 2 normes qui sont sorties. Donc ils continuent de forcer les élèves à déclarer toutes leurs variables en haut d'un bloc alors que ça fait 20 ans ou presque que la norme permet de déclarer des variables n'importe où dans un bloc de code.
Je suis à fond pour utiliser F2008 (car en plus y'a Co-Array Fortran et que c'est un sous-langage rigolo :-)), mais ton affirmation selon laquelle un thésard peut dire non à son directeur de thèse n'est que partiellement vraie. Je dis aux élèves de Master/thèse qu'il y a forcément un moment pendant la thèse où il faut apprendre à dire non. Cependant, je dis aussi que généralement, la première année on se contente de fermer sa gueule et d'appliquer les méthodes. On peut (et on doit !) les questionner, mais au final, à de très rares exceptions près, le directeur de thèse en 1ère année reste le patron. Perso F77 m'emmerde, donc j'ai fourni mes codes optimisés aux boites avec qui on bossait en leur disant que je savais pas me satisfaire des contraintes désormais artificielles de F77 et que du coup j'avais codé le tout en F90 (ce qui est globalement vrai). Leur réaction a été soit « t'as accéléré mon code de 30%, et mon compilateur sait mélanger les deux, t'inquiète on gère », soit « pas de problème on réécrira le code en F77 ».
C'est un film culte, car il a plus ou moins été l'un des premiers à montrer les hackers sous un jour relativement positif, mais aussi à utiliser de métaphores complètement débiles pour représenter l'activité de programmation et/ou piratage. Je pensais que ma citation sur le RISC montrait bien que je connais bien la nature du film… et malgré tout, un film qui m'apprend que les gentils hackers sont en Rollerblade alors que les méchants sont en skateboard ne peut être, je le répète, qu'un très grand film. :-)
Si tu parles juste de la « Sprawl Trilogy » je suis assez d'accord. Par contre, si on parle des autres trilogies que Gibson a écrites, je ne suis pas d'accord. Neuromancien en français est pas mal (et c'était un gros tour de force de l'adapter en français à l'époque), et en anglais il est encore plus spectaculaire (le style est encore plus nerveux/incisif). Comte Zéro / Mona-Lisa s'éclate sont aussi très bien, quoi qu'un cran en-dessous de Neuromancien (surtout Comte Zéro, que je trouve bien dans le contexte cyberpunk, mais sans plus)1.
Par contre, la trilogie suivante est aussi très très bonne : la « Bridge Trilogy » se situe dans un futur moins lointain, où le « big one » (gros tremblement de terre attendu en Californie) est arrivé. « Lumière virtuelle » amorce bien la trilogie, « Idoru » la continue tout aussi bien, mais c'est surtout « Tomorrow's Parties » qui est vraiment excellent et fourni une conclusion super satisfaisante.
En fait, plus le temps passe, et moins Gibson va dans le futur, car, de ce que j'ai compris, ça y est, le futur est là, et donc ce qui est intéressant c'est de s'intéresser aux usages de la technologie et de leur impact sur les hommes. En particulier, « Identification des schémas » est pour moi un chef d'œuvre, au moins aussi intéressant à lire que « Neuromancien » (mais dans un style très différent, plus calme/lent). Les romans qui suivent sont légèrement moins bien (pas encore lu « The Peripheral », qui m'attend sagement sur une étagère), mais malgré tout passionnants.
Voilà voilà, c'étaient mes deux cents.
À noter que Masamune Shirou avait publié « The Ghost in the Shell » autour de 1988-1990, et que même si c'est un manga, il avait clairement fait beaucoup de recherches à l'époque, et que le monde cyberpunk qu'il décrit aborde des thèmes très proches de ceux de Neuromancien (nature de ce qui rend quelque chose « vivant », etc.). ↩
Dans ce que tu cites je ne pense pas que l'OP nie que le script pourrait faire une vérification, juste que comme chaque script fait ce qu'il veut, à moins d'examiner chacun à la main, on ne sait pas. Alors que RPM/DEB/etc. on un protocole qu'on sait être suivi pour ce genre de choses (et qui vont t'avertir si quelque chose cloche).
Certes, mais j'allais demander outre le hype, pourquoi une instance Mastodon et pas XMPP ou Diaspora?
Pour paraphraser un autre article (dont je ne retrouve pas le lien, désolé) : parce que si GNU Social existe depuis un bail, Mastodon est le premier système qui soit raisonnablement facile à utiliser, et qui propose une interface moderne, ergonomique, et suffisamment réactive. Bref, un truc qui a un look « pro » tout en assurant les fonctionnalités que tout le monde attend de Twitt^W d'un service de micro-blogging.
À noter que les gens qui aident au développement de Mastodon se posent la question de la migration transparente — voir ici. Ils séparent le problème en deux :
Comment migrer de façon transparente un compte d'une instance à l'autre ? Il y a une partie facile (migrer ceux que « je » suis ou ai bloqués), et une partie plus complexe (faire en sorte que ceux qui me suivent n'aient rien à faire).
Comment migrer les données liées (les messages) émis depuis une instance donnée. C'est plus compliqué, et à mon avis, le seul moyen de le faire est de permettre l'export de ces données. Cependant, dans le fil que j'ai lié, quelqu'un donnait le cas d'un hypothétique robot spammeur qui en profiterait pour flooder plusieurs serveurs grâce à cela pour aller plus vite…
Bref. La migration de l'identité est quelque chose de faisable (mais apparemment le protocole initial, OSocial) pourrait avoir besoin d'une extension pour permettre une telle chose. La migration des messages, c'est plus dur, sauf si c'est « ton » instance.
Si je réponds à quelqu'un, dans 90% des cas, j'estime que c'est suffisamment pertinent pour le fil donné (pas forcément le thème du journal…) pour que je m'embête à rédiger un truc. Du coup je ne moinsse jamais les gens auxquels je réponds (mais je plussoie parfois). Par contre, si je trouve que c'est pas pertinent/très mal argumenté (donc techniquement c'est pertinent, mais j'ai franchement pas le courage ou l'envie d'expliquer pourquoi) alors je moinsse. Il y a aussi sans doute des fois où je moinsse pour dire « pas d'accord » (nul n'est parfait) mais j'essaie de limiter ça autant que possible.
La différence entre Unity et Window Maker est plus ou moins la même qu'entre GNOME et Window Maker: GNOME/KDE/Unity sont des environnements de bureau, là où Window Maker n'est « que » un gestionnaire de fenêtre globalement.
À noter que j'aime beaucoup Window Maker et qu'à l'époque où KDE/Gnome étaient encore balbutiants, c'était mon WM favori, et que même avec Gnome 1, j'utilisais souvent Window Maker en sous-main (j'ai arrêté de le faire à mesure que le WM de GNOME devenait plus intégré et qu'en conséquence les autres WM détonnaient de plus en plus).
Bref. XFCE est lui aussi plus un environnement de bureau qu'un simple gestionnaire de fenêtres. Il intègre tout un tas de fonctions que Window Maker ne gère pas du tout, malheureusement. Mais ce serait un chouette projet d'avoir un environnement de bureau basé sur Window Maker… :)
C'est quand même un peu différent, dans le sens où avant elle était imposée par défaut (et il fallait ensuite volontairement basculer en mode « classique »), là où maintenant on est par défaut en mode « classique » mais maintenant on a aussi une « mini » version de l'interface de Win8.
À noter que je trouve que ça marche effectivement mieux pour un laptop/desktop, car le côté « cache d'icones » sous forme « tuilée » fonctionne bien dans ce cas, et devient vraiment utile.
J'ai dû installer des CentOS ou Red Hat plus d'une fois sur des serveurs Bull dans des facs tout simplement parce que certains drivers/firmwares ne fonctionnaient correctement que sur les versions patchées par RH.
Et aussi parce qu'à un moment donné, il faut essayer d'être rentable. Ils continuent l'effort pour le desktop, qui constitue une « vitrine », mais qui ne rapporte pas grand chose, alors que ce qui rapporte les sous en vrai, ce sont les solutions à base de cloud (enfin, de ce que j'ai compris).
150k USD c'est ta base. A ca, tu rajoute grosso modo 100k de stock et/ou bonus (qui vest généralement sur 3-4 ans).
C'est la base pour certains mais pas tous, hé. :) Après c'est une histoire de savoir ce qu'on peut espérer, ce qu'on croit pouvoir négocier, etc., mais je connais tout un tas d'ingés info (et assimilés) qui touchent ~130K USD (avec un peu de stocks et autres bénéfices), mais sans plus. Je connais des ingés qui se sont fait « avoir » aussi parce qu'ils avaient mal estimé leur marge de négociation, et du coup ont touché ~130K USD (en y incluant la prime « Californie-ça-coûte-cher-sa-race »). Enfin, oui, évidemment, si tu es plus que junior tu peux espérer plus/mieux, mais tout le monde te file pas un deuxième salaire annuel en bonus divers, loin de là.
Et aussi parce qu'à un moment donné, les grandes boites étaient soupçonnées de s'entendre sur les salaires (au moins Yahoo, Google, et Apple).
Et puis bon, disons que t'es payé 150K USD annuels. Vivre pas trop loin de San Francisco, c'est déjà accepter de payer un gros loyer (je ne parle même pas de vivre dans SF-même—une amie vit là-bas, et paie son studio plus de 2000 USD chaque mois; mes amis vivant dans une maison en « banlieue lointaine » paient dans les 3000 USD si je me souviens bien). Alors oui, les salaires sont très élevés, mais le coût de la vie aussi. À comparer à mon « petit » salaire d'enseignant-chercheur dans le Nord des USA, mais où je ne dépense quasiment rien… Au final ils économisent sans doute plus que moi malgré tout, mais pas tant que ça.
Je pense que, comme beaucoup de gens, le monsieur fait une différence entre la technique (matériel, logiciel, documentation, etc.), et ce qui relève de l'opinion (ce qui est le cas ici, non ?).
Il existe des environnements pour faire du développement orienté modèles, etc. qui marchent, mais ils ont tendance à se spécialiser sur des domaines précis.
Après, le problème du génie logiciel, c'est que certains veulent faire croire que c'est une science, alors que ça commence tout juste à enfin trouver ses marques et effectivement proposer un certain formalisme. Les gens oublient juste qu'il a fallu ~200-300 ans pour formaliser les méthodes du génie mécanique une fois qu'on avait enfin des outils mathématiques efficaces pour aider à la conception de systèmes mécaniques (merci Newton, merci Leibnitz).
Je ne me souviens plus du nom, mais après googling, je crois que j'utilisais dh-make-perl (je peux me tromper). Lorsque ça ne marchait pas, c'était généralement que la compilation au niveau de Makefile.PL se passait mal (donc le paquetage était mal formé de toute manière).
C'est intéressant, tu sous-entend au début (mais ta conclusion dit l'inverse) qu'aucun système ne peut prétendre tout résoudre à la fois. Partant de là on peut se demander comment faire efficacement cohabiter les trois outils : celui du sysadmin et de la distribution, celui du développeur et celui de l'utilisateur "bureau". Sans oublier le mainteneur de logiciels à qui on demande des paquets pour tous les systèmes possibles…
Alors j'arrive après la bataille, mais par exemple pour Perl, il existe des outils dans Debian qui permettent d'utiliser cpan/CPAM.pm (l'outil de gestion de paquetages de Perl), de les télécharger, lancer les scripts kivonbien, puis de convertir le tout sous forme de paquet .deb en modifiant les chemins pour les bibliothèques, etc. Les fois où je m'en étais servi, cet outil faisait le boulot comme je voulais, et du coup j'avais un workflow relativement fluide.
Qu'est-ce qui empêcherait les gens de faire de même avec les gem/pip/etc. ? (je suis sûr qu'il y a de bonnes raisons, je ne sais juste pas lesquelles).
Les cas pathologiques pour la complexité exponentielle, on les rencontres dans du « vrai » code ?
Ce ne sont pas des cas pathologiques, c'est bien le problème. La boucle en elle-même est peut-être « simplement » 2D ou 3D. Mais tout un tas d'applications scientifiques qui simulent des phénomènes naturels (différents aspects météo, dynamique moléculaire, etc., dont je ne maîtrise absolument pas la théorie derrière) utilisent des dizaines de variables, tableaux, etc., pour représenter divers paramètres et aspects du modèle. La complexité ne vient pas uniquement du nid de boucle, mais aussi de l'explosion du nombre de variables dans les systèmes d'(in)équations linéaires qui en résultent. Beaucoup de ces applications utilisent des tableaux à une, deux, ou trois dimensions, ce qui fait exploser le nombre d'états (car le problème des dépendances inter-itérations est qu'il faut maintenir un vecteur d'itération par tableau, plus ou moins, pour tracer les dépendances qui doivent être résolues, et celles qui peuvent être potentiellement « dynamiques » et malgré tout « calculables » par le compilateur pour déterminer si la forme de l'espace d'itération ET du réseau de dépendances constituent toujours un polyèdre convexe).
Enfin, pour paraphraser Feautrier lors d'une keynote sur le sujet, « le modèle polyédrique n'est que polyédrique ». Beaucoup de codes de la vie réelle font appel à des tableaux d'indirection (algèbre linéaire creux, méthodes par éléments finis, et en général pas mal d'algorithmes fonctionnant à partir de représentations par graphes). Le résultat est que dans le cas général le modèle polyédrique ne peut rien car il est impossible de savoir si on a bien un polyèdre convexe pour les dépendances de données1.
Cependant j'ai vu des gens montrer au cas par cas comment dépasser le problème de la convexité, au moins partiellement. Du coup peut-être que dans vingt ans on aura une théorie et des outils pour aller au-delà des limites actuelles du modèle. :)
EDIT: j'oubliais aussi un cas important : si on commence à avoir l'analyse polyédrique activable (genre Polly dans LLVM, qui est dans la branche principale je crois), il faut accepter que l'analyse va sans doute s'appliquer à TOUTES les boucles du programme. Ça risque de sérieusement rallonger le temps de compilation (du coup il faudra passer par des méthodes de ségrégation de certaines fonctions pour qu'elles soient isolées dans des fichiers spécifiques avec des options de compilation spécifiques). C'est déjà plus ou moins le cas dans pas mal de codes scientifiques optimisés, mais ça rajoute des contraintes sur le programmeur.
En pratique je connais des gens capables de faire tout un tas de trucs très cool malgré tout. Par exemple, si tu sais que malgré une indirection de type a[b[i]] par construction les valeurs de b sont monotones (croissantes ou décroissantes) tu peux quand même utiliser l'analyse polyédrique pour permettre la parallélisation. Mais du coup ça demande d'avoir un utilisateur qui le dit au compilateur. ↩
Si je prends un exemple pour illustrer la chose. Dans la vidéo de la conférence sur JML (dont le lien était erroné, le voici), l'orateur expose sur un cas particulier une méthode d'analyse statique dite analyse polyédrique (vers la 40ème minute). Il conclue l'étude de cette exemple avec une diapo qui contient ce passage :
Juste un mot là-dessus : premièrement je n'ai pas encore vu la vidéo1.
L'analyse polyédrique a été proposée pour l'optimisation et la parallélisation en compilation depuis la fin des années 80 (voir ici par exemple pour un résumé du modèle). Lorsque j'ai décrit la technique à un pote bien plus avancé en maths que moi (faire une analyse de formes convexes dans un domaine discret), il a tout de suite pigé la difficulté (dans le domaine continu, c'est « trivial », mais dans le domaine discret, pas du tout), et a proposé de suite la première solution utilisée dans ce cas : utiliser un solveur de programmation linéaire entière (pas sûr de la traduction de integer linear programming solver). Et c'est ce qu'a fait Feautrier à l'époque (il a écrit PIP rien que pour ça).
Mais utiliser un solveur ILP mène à de sérieuses contraintes, entre autres que le temps de résolution des (in)équations augmente exponentiellement avec la complexité du nid de boucle à paralléliser/optimiser. De nos jours il y a enfin quelques compilateurs/transpilers qui sont relativement efficaces pour correctement compiler tout ça dans un temps raisonnable, et qui ne passent pas nécessairement par un solveur ILP (et donc le temps d'exploration des espaces d'itération est bien moins grand), mais même dans GCC qui a (avait?) une branche pour les optimisations suivant le modèle polyédrique, ce ne serait jamais activé par défaut.
Bref. Pour passer d'un modèle mathématique correct, et qui fonctionne sur des programmes/boucles jouet, à un compilateur qui peut compiler du « vrai » code (principalement scientifique), il a fallu attendre environ 20 ans (et sacrifier pas mal de thésards à l'autel du modèle polyédrique). Et malgré tout, ce n'est toujours pas intégré dans les compilateurs « mainstream » (tout au plus est-ce une option qu'il faut activer volontairement), car les résultats mathématiques ne se réduisent pas nécessairement en possibilité d'implémentation efficace.
Je suis en train de la télécharger, mais apparemment depuis les US ça prend 300 ans. ↩
Je réponds alors : le type checking (tache qui incombe au compilateur) c'est de l'analyse statique; et dans l'exemple donné il y a clairement un problème de typage qui peut être détecté statiquement, c'est-à-dire à la compilation. Puis j'illustre mon propos sur un exemple pour montrer en quoi cela peut être utile : réduire l'overhead à l'exécution. Comme la chose est vérifiée une
Deux choses:
La vérification de types peut se faire tout bêtement de façon sûre, mais à l'exécution. Voir par exemple Java (si on excepte les types primitifs): on a une garantie de ne pas se retrouver dans un état indéfini lorsqu'on passe par les classes et objets du langage, mais la plupart du temps ce sera détecté à l'exécution. Et pourtant, on peut parfaitement utiliser du lambda calcul pour définir le système de types de Java (voir par exemple le bouquin de Benjamin Pierce, « Types and Programming Languages »).
Il ne faut pas oublier que les spécifications des langages mais aussi les techniques d'analyse (sémantique, entre autres) évoluent avec le temps. ADA existe depuis un bout de temps (plus de 30 ans); C aussi. Mais on doit aussi faire face à ce qui n'est pas (et ne sera peut-être jamais) déprécié dans le langage, et qui du coup doit « passer » à la compilation, parce qu'à l'époque, on ne savait pas faire de détection efficace (parce que bon, si ton compilateur prend 3 heures pour te vérifier les types, personne ne l'utilisera sauf application ultra-critique et dont le code bougera peu). Idem avec C: n'importe quel compilateur moderne (Clang, GCC, ICC, XL/C, etc.) sait faire une analyse statique poussée du langage, malgré toutes les ambiguïtés qu'il embarque. Ces analyses vont bien plus loin que la norme, mais comme il y a des obligations de compatibilité ascendante, le compilateur ne peut émettre que des warnings. Ceci étant dit, si tu demandes à des développeurs expérimentés ce qu'il en est, ils te diront qu'il faut utiliser -Werror pour du code nouveau. Si ton code a un comportement particulier qui peut générer des avertissements du compilateur, mieux vaut le montrer explicitement sur la ligne de compilation avec des options de type -Wno-…. Si ton code est lié à des bibliothèques qui désormais génèrent des avertissements (qui n'étaient pas générés il y a 10 ans), alors évidemment il faut faire des exceptions.
Bref, ne pas oublier « l'existant », qui explique beaucoup de fois pourquoi un compilateur de « vieux » langage dit des choses qu'il faut « écouter » mais ne les force pas.
Tu as évidemment raison pour la règle grammaticale, mais le côté « rude » c'est peut-être vrai en anglais britannique, mais pas tellement en anglais américain (ça fait surtout pas très doué niveau grammaire quoi). Par contre, étant donné la façon dont les gens écrivent leurs blogs et leurs commentaires en anglais sur le net, je ne m'étonne pas de ne pas voir « English » avec une majuscule dans des forums.
Perso j'ai été bien plus choqué par son « Somes says » ! :-)
[^] # Re: Singulier, pluriel, faut savoir !
Posté par lasher . En réponse au journal [Jeu] Parser de l'écriture inclusive.. Évalué à 7.
Ah ben justement, l'Anglais n'est pas spécialement meilleur que le français pour le coup. D'ailleurs, les notations de type « s/he » sont courantes justement parce qu'adresser le genre est aussi un problème en langue anglaise. Il existe une forme grammaticalement correcte, mais apparemment peu usitée, qui est d'utiliser « they » comme forme neutre, mais pas mal de profs anglophones la considèrent comme incorrecte (soit parce qu'ils n'ont jamais appris cette règle de grammaire, soit qu'ils la considèrent désuète). Du coup, ça donne des bouquins, par exemple le jeu de rôle « Vampire: The Mascarade » qui en v.o. (et peut-être aussi en v.f. ?) ont pris le parti de tout accorder au féminin — « When the vampire rises, she … », etc.
Quant à la « logique en général » de l'anglais, si la langue me semble au départ plus simple à apprendre que le français, elle montre son manque de cohérence dès qu'on désire parler de façon un peu subtile/avec des constructions un peu complexes. C'est valable tant pour la prononciation que pour l'orthographe ou la grammaire. Ça n'en excuse pas les défauts du français1 en terme de constance et de cohérence bien entendu.
Si j'ai bien compris, avant que Richelieu ne s'en mêle, la règle était d'accorder les phrases en fonction de la proximité avec la dernière composante du sujet. Exemple : « Le camion et la voiture sont vertes. » vs. « La voiture et le camion sont verts. » Personnellement ça ne me dérangerait pas qu'on revienne à cette règle, même si ça me demanderait un peu de temps pour m'adapter. ↩
[^] # Re: AH ah ah ...
Posté par lasher . En réponse au journal Java 9 est dehors. Évalué à 2.
Je dis peut-être une connerie, mais si tu tapes
[ -d "$REP" ] || mkdir "$REP"… Les espaces sont gérés non ?
[^] # Re: Python pour scripter, C/C++ sous la capot.
Posté par lasher . En réponse au journal Un Python qui rivalise avec du C++. Évalué à 3.
Tu as bien entendu conscience que du Fortran 77 ça se trouve encore dans des codes relativement modernes dans l'industrie hein ? :-)
Pendant ma thèse (entre 2006 et 2010) j'ai bossé sur des codes en Fortran. TOUS étaient écrits au mieux en Fortran 90. Sur quatre codes industriels, deux étaient écrits en F77. Et il s'agissait d'ISV, donc leurs clients faisaient aussi du code qui se servaient du leur. Certains réclamaient de se conformer à la norme IEEE 754 strictement, même si les nouvelles archis/les nouveaux compilos sont capables d'aller jusqu'à 80 bits de précision (parce que ça passe pas les tests unitaires du client sinon).
Autre exemple con : dans les cours d'info, lorsqu'on enseigne le C aux étudiants, beaucoup, beaucoup de profs continuent d'enseigner C89. Alors que depuis on a eu 2 normes qui sont sorties. Donc ils continuent de forcer les élèves à déclarer toutes leurs variables en haut d'un bloc alors que ça fait 20 ans ou presque que la norme permet de déclarer des variables n'importe où dans un bloc de code.
Je suis à fond pour utiliser F2008 (car en plus y'a Co-Array Fortran et que c'est un sous-langage rigolo :-)), mais ton affirmation selon laquelle un thésard peut dire non à son directeur de thèse n'est que partiellement vraie. Je dis aux élèves de Master/thèse qu'il y a forcément un moment pendant la thèse où il faut apprendre à dire non. Cependant, je dis aussi que généralement, la première année on se contente de fermer sa gueule et d'appliquer les méthodes. On peut (et on doit !) les questionner, mais au final, à de très rares exceptions près, le directeur de thèse en 1ère année reste le patron. Perso F77 m'emmerde, donc j'ai fourni mes codes optimisés aux boites avec qui on bossait en leur disant que je savais pas me satisfaire des contraintes désormais artificielles de F77 et que du coup j'avais codé le tout en F90 (ce qui est globalement vrai). Leur réaction a été soit « t'as accéléré mon code de 30%, et mon compilateur sait mélanger les deux, t'inquiète on gère », soit « pas de problème on réécrira le code en F77 ».
[^] # Re: Performances SPARC ?
Posté par lasher . En réponse au journal La mort de Solaris et de SPARC. Évalué à 3.
Non non, tu as bien compris. :-)
[^] # Re: Merci
Posté par lasher . En réponse à la dépêche Revue de livre : La face cachée d’Internet, de Rayna Stamboliyska. Évalué à 8.
J'attendais la remarque sur "Hackers". :-)
C'est un film culte, car il a plus ou moins été l'un des premiers à montrer les hackers sous un jour relativement positif, mais aussi à utiliser de métaphores complètement débiles pour représenter l'activité de programmation et/ou piratage. Je pensais que ma citation sur le RISC montrait bien que je connais bien la nature du film… et malgré tout, un film qui m'apprend que les gentils hackers sont en Rollerblade alors que les méchants sont en skateboard ne peut être, je le répète, qu'un très grand film. :-)
[^] # Re: Rien à voir : Neuromancien
Posté par lasher . En réponse au journal Jouer sous GNU/Linux : la série des Shadowrun. Évalué à 5.
Si tu parles juste de la « Sprawl Trilogy » je suis assez d'accord. Par contre, si on parle des autres trilogies que Gibson a écrites, je ne suis pas d'accord. Neuromancien en français est pas mal (et c'était un gros tour de force de l'adapter en français à l'époque), et en anglais il est encore plus spectaculaire (le style est encore plus nerveux/incisif). Comte Zéro / Mona-Lisa s'éclate sont aussi très bien, quoi qu'un cran en-dessous de Neuromancien (surtout Comte Zéro, que je trouve bien dans le contexte cyberpunk, mais sans plus)1.
Par contre, la trilogie suivante est aussi très très bonne : la « Bridge Trilogy » se situe dans un futur moins lointain, où le « big one » (gros tremblement de terre attendu en Californie) est arrivé. « Lumière virtuelle » amorce bien la trilogie, « Idoru » la continue tout aussi bien, mais c'est surtout « Tomorrow's Parties » qui est vraiment excellent et fourni une conclusion super satisfaisante.
En fait, plus le temps passe, et moins Gibson va dans le futur, car, de ce que j'ai compris, ça y est, le futur est là, et donc ce qui est intéressant c'est de s'intéresser aux usages de la technologie et de leur impact sur les hommes. En particulier, « Identification des schémas » est pour moi un chef d'œuvre, au moins aussi intéressant à lire que « Neuromancien » (mais dans un style très différent, plus calme/lent). Les romans qui suivent sont légèrement moins bien (pas encore lu « The Peripheral », qui m'attend sagement sur une étagère), mais malgré tout passionnants.
Voilà voilà, c'étaient mes deux cents.
À noter que Masamune Shirou avait publié « The Ghost in the Shell » autour de 1988-1990, et que même si c'est un manga, il avait clairement fait beaucoup de recherches à l'époque, et que le monde cyberpunk qu'il décrit aborde des thèmes très proches de ceux de Neuromancien (nature de ce qui rend quelque chose « vivant », etc.). ↩
[^] # Re: Je ne comprends pas
Posté par lasher . En réponse au journal Mark Shuttleworth annonce l’abandon d’Unity. Évalué à 4.
Dans ce que tu cites je ne pense pas que l'OP nie que le script pourrait faire une vérification, juste que comme chaque script fait ce qu'il veut, à moins d'examiner chacun à la main, on ne sait pas. Alors que RPM/DEB/etc. on un protocole qu'on sait être suivi pour ce genre de choses (et qui vont t'avertir si quelque chose cloche).
[^] # Re: Numerama : Pourquoi nous avons créé notre instance Mastodon
Posté par lasher . En réponse au journal Mastodon, le réseau social qui monte ?. Évalué à 1.
Pour paraphraser un autre article (dont je ne retrouve pas le lien, désolé) : parce que si GNU Social existe depuis un bail, Mastodon est le premier système qui soit raisonnablement facile à utiliser, et qui propose une interface moderne, ergonomique, et suffisamment réactive. Bref, un truc qui a un look « pro » tout en assurant les fonctionnalités que tout le monde attend de Twitt^W d'un service de micro-blogging.
[^] # Re: Ça ne scalera pas
Posté par lasher . En réponse au journal Mastodon, le réseau social qui monte ?. Évalué à 3.
À noter que les gens qui aident au développement de Mastodon se posent la question de la migration transparente — voir ici. Ils séparent le problème en deux :
Bref. La migration de l'identité est quelque chose de faisable (mais apparemment le protocole initial, OSocial) pourrait avoir besoin d'une extension pour permettre une telle chose. La migration des messages, c'est plus dur, sauf si c'est « ton » instance.
[^] # Re: Diversité
Posté par lasher . En réponse au journal Mark Shuttleworth annonce l’abandon d’Unity. Évalué à 4.
Bon, c'est une méta-discussion, mais…
Si je réponds à quelqu'un, dans 90% des cas, j'estime que c'est suffisamment pertinent pour le fil donné (pas forcément le thème du journal…) pour que je m'embête à rédiger un truc. Du coup je ne moinsse jamais les gens auxquels je réponds (mais je plussoie parfois). Par contre, si je trouve que c'est pas pertinent/très mal argumenté (donc techniquement c'est pertinent, mais j'ai franchement pas le courage ou l'envie d'expliquer pourquoi) alors je moinsse. Il y a aussi sans doute des fois où je moinsse pour dire « pas d'accord » (nul n'est parfait) mais j'essaie de limiter ça autant que possible.
[^] # Re: Pourquoi pas XFCE?
Posté par lasher . En réponse au journal Mark Shuttleworth annonce l’abandon d’Unity. Évalué à 3.
La différence entre Unity et Window Maker est plus ou moins la même qu'entre GNOME et Window Maker: GNOME/KDE/Unity sont des environnements de bureau, là où Window Maker n'est « que » un gestionnaire de fenêtre globalement.
À noter que j'aime beaucoup Window Maker et qu'à l'époque où KDE/Gnome étaient encore balbutiants, c'était mon WM favori, et que même avec Gnome 1, j'utilisais souvent Window Maker en sous-main (j'ai arrêté de le faire à mesure que le WM de GNOME devenait plus intégré et qu'en conséquence les autres WM détonnaient de plus en plus).
Bref. XFCE est lui aussi plus un environnement de bureau qu'un simple gestionnaire de fenêtres. Il intègre tout un tas de fonctions que Window Maker ne gère pas du tout, malheureusement. Mais ce serait un chouette projet d'avoir un environnement de bureau basé sur Window Maker… :)
[^] # Re: Je ne comprends pas
Posté par lasher . En réponse au journal Mark Shuttleworth annonce l’abandon d’Unity. Évalué à 2.
C'est quand même un peu différent, dans le sens où avant elle était imposée par défaut (et il fallait ensuite volontairement basculer en mode « classique »), là où maintenant on est par défaut en mode « classique » mais maintenant on a aussi une « mini » version de l'interface de Win8.
À noter que je trouve que ça marche effectivement mieux pour un laptop/desktop, car le côté « cache d'icones » sous forme « tuilée » fonctionne bien dans ce cas, et devient vraiment utile.
[^] # Re: Un recentrage des activités vers les entreprises ?
Posté par lasher . En réponse au journal Mark Shuttleworth annonce l’abandon d’Unity. Évalué à 4.
J'ai dû installer des CentOS ou Red Hat plus d'une fois sur des serveurs Bull dans des facs tout simplement parce que certains drivers/firmwares ne fonctionnaient correctement que sur les versions patchées par RH.
[^] # Re: Je ne comprends pas
Posté par lasher . En réponse au journal Mark Shuttleworth annonce l’abandon d’Unity. Évalué à 3.
Et aussi parce qu'à un moment donné, il faut essayer d'être rentable. Ils continuent l'effort pour le desktop, qui constitue une « vitrine », mais qui ne rapporte pas grand chose, alors que ce qui rapporte les sous en vrai, ce sont les solutions à base de cloud (enfin, de ce que j'ai compris).
[^] # Re: Il y a déjà d'autres projets en France
Posté par lasher . En réponse à la dépêche La voiture en open source. Évalué à 4.
Bof, je code pour du calcul haute performance, et je suis ultra-nul en développement Web. Ce sont deux choses complètement différentes.
[^] # Re: Télétravail
Posté par lasher . En réponse au journal Réduire les salaires sans sacrifier la qualité. Évalué à 2.
C'est la base pour certains mais pas tous, hé. :) Après c'est une histoire de savoir ce qu'on peut espérer, ce qu'on croit pouvoir négocier, etc., mais je connais tout un tas d'ingés info (et assimilés) qui touchent ~130K USD (avec un peu de stocks et autres bénéfices), mais sans plus. Je connais des ingés qui se sont fait « avoir » aussi parce qu'ils avaient mal estimé leur marge de négociation, et du coup ont touché ~130K USD (en y incluant la prime « Californie-ça-coûte-cher-sa-race »). Enfin, oui, évidemment, si tu es plus que junior tu peux espérer plus/mieux, mais tout le monde te file pas un deuxième salaire annuel en bonus divers, loin de là.
[^] # Re: Télétravail
Posté par lasher . En réponse au journal Réduire les salaires sans sacrifier la qualité. Évalué à 3.
Et aussi parce qu'à un moment donné, les grandes boites étaient soupçonnées de s'entendre sur les salaires (au moins Yahoo, Google, et Apple).
Et puis bon, disons que t'es payé 150K USD annuels. Vivre pas trop loin de San Francisco, c'est déjà accepter de payer un gros loyer (je ne parle même pas de vivre dans SF-même—une amie vit là-bas, et paie son studio plus de 2000 USD chaque mois; mes amis vivant dans une maison en « banlieue lointaine » paient dans les 3000 USD si je me souviens bien). Alors oui, les salaires sont très élevés, mais le coût de la vie aussi. À comparer à mon « petit » salaire d'enseignant-chercheur dans le Nord des USA, mais où je ne dépense quasiment rien… Au final ils économisent sans doute plus que moi malgré tout, mais pas tant que ça.
Mais je diverge1.
Et diverge, c'est énorme ©®™ Desproges. ↩
[^] # Re: Ha la licence pas logique...
Posté par lasher . En réponse à la dépêche Matériel libre : état des lieux après l’échec de la campagne de financement Talos. Évalué à 2.
Je pense que, comme beaucoup de gens, le monsieur fait une différence entre la technique (matériel, logiciel, documentation, etc.), et ce qui relève de l'opinion (ce qui est le cas ici, non ?).
[^] # Re: "Génie" logiciel
Posté par lasher . En réponse au journal Réduire les temps de développement sans sacrifier la qualité. Évalué à 3.
Il existe des environnements pour faire du développement orienté modèles, etc. qui marchent, mais ils ont tendance à se spécialiser sur des domaines précis.
Après, le problème du génie logiciel, c'est que certains veulent faire croire que c'est une science, alors que ça commence tout juste à enfin trouver ses marques et effectivement proposer un certain formalisme. Les gens oublient juste qu'il a fallu ~200-300 ans pour formaliser les méthodes du génie mécanique une fois qu'on avait enfin des outils mathématiques efficaces pour aider à la conception de systèmes mécaniques (merci Newton, merci Leibnitz).
[^] # Re: A chaque clou son marteau
Posté par lasher . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 2.
Je ne me souviens plus du nom, mais après googling, je crois que j'utilisais
dh-make-perl(je peux me tromper). Lorsque ça ne marchait pas, c'était généralement que la compilation au niveau deMakefile.PLse passait mal (donc le paquetage était mal formé de toute manière).Y'a un topic sur PerlMonks à ce sujet.
[^] # Re: A chaque clou son marteau
Posté par lasher . En réponse au journal La multiplicité des gestionnaires de paquets. Évalué à 3.
Alors j'arrive après la bataille, mais par exemple pour Perl, il existe des outils dans Debian qui permettent d'utiliser cpan/CPAM.pm (l'outil de gestion de paquetages de Perl), de les télécharger, lancer les scripts kivonbien, puis de convertir le tout sous forme de paquet
.deben modifiant les chemins pour les bibliothèques, etc. Les fois où je m'en étais servi, cet outil faisait le boulot comme je voulais, et du coup j'avais un workflow relativement fluide.Qu'est-ce qui empêcherait les gens de faire de même avec les gem/pip/etc. ? (je suis sûr qu'il y a de bonnes raisons, je ne sais juste pas lesquelles).
[^] # Re: Solution à base de types variants en ADA
Posté par lasher . En réponse à la dépêche Sortie de GHC 8.0.2 et une petite histoire de typage statique. Évalué à 3. Dernière modification le 02 février 2017 à 17:59.
Ce ne sont pas des cas pathologiques, c'est bien le problème. La boucle en elle-même est peut-être « simplement » 2D ou 3D. Mais tout un tas d'applications scientifiques qui simulent des phénomènes naturels (différents aspects météo, dynamique moléculaire, etc., dont je ne maîtrise absolument pas la théorie derrière) utilisent des dizaines de variables, tableaux, etc., pour représenter divers paramètres et aspects du modèle. La complexité ne vient pas uniquement du nid de boucle, mais aussi de l'explosion du nombre de variables dans les systèmes d'(in)équations linéaires qui en résultent. Beaucoup de ces applications utilisent des tableaux à une, deux, ou trois dimensions, ce qui fait exploser le nombre d'états (car le problème des dépendances inter-itérations est qu'il faut maintenir un vecteur d'itération par tableau, plus ou moins, pour tracer les dépendances qui doivent être résolues, et celles qui peuvent être potentiellement « dynamiques » et malgré tout « calculables » par le compilateur pour déterminer si la forme de l'espace d'itération ET du réseau de dépendances constituent toujours un polyèdre convexe).
Enfin, pour paraphraser Feautrier lors d'une keynote sur le sujet, « le modèle polyédrique n'est que polyédrique ». Beaucoup de codes de la vie réelle font appel à des tableaux d'indirection (algèbre linéaire creux, méthodes par éléments finis, et en général pas mal d'algorithmes fonctionnant à partir de représentations par graphes). Le résultat est que dans le cas général le modèle polyédrique ne peut rien car il est impossible de savoir si on a bien un polyèdre convexe pour les dépendances de données1.
Cependant j'ai vu des gens montrer au cas par cas comment dépasser le problème de la convexité, au moins partiellement. Du coup peut-être que dans vingt ans on aura une théorie et des outils pour aller au-delà des limites actuelles du modèle. :)
EDIT: j'oubliais aussi un cas important : si on commence à avoir l'analyse polyédrique activable (genre Polly dans LLVM, qui est dans la branche principale je crois), il faut accepter que l'analyse va sans doute s'appliquer à TOUTES les boucles du programme. Ça risque de sérieusement rallonger le temps de compilation (du coup il faudra passer par des méthodes de ségrégation de certaines fonctions pour qu'elles soient isolées dans des fichiers spécifiques avec des options de compilation spécifiques). C'est déjà plus ou moins le cas dans pas mal de codes scientifiques optimisés, mais ça rajoute des contraintes sur le programmeur.
En pratique je connais des gens capables de faire tout un tas de trucs très cool malgré tout. Par exemple, si tu sais que malgré une indirection de type
a[b[i]]par construction les valeurs debsont monotones (croissantes ou décroissantes) tu peux quand même utiliser l'analyse polyédrique pour permettre la parallélisation. Mais du coup ça demande d'avoir un utilisateur qui le dit au compilateur. ↩[^] # Re: Solution à base de types variants en ADA
Posté par lasher . En réponse à la dépêche Sortie de GHC 8.0.2 et une petite histoire de typage statique. Évalué à 3.
Juste un mot là-dessus : premièrement je n'ai pas encore vu la vidéo1.
L'analyse polyédrique a été proposée pour l'optimisation et la parallélisation en compilation depuis la fin des années 80 (voir ici par exemple pour un résumé du modèle). Lorsque j'ai décrit la technique à un pote bien plus avancé en maths que moi (faire une analyse de formes convexes dans un domaine discret), il a tout de suite pigé la difficulté (dans le domaine continu, c'est « trivial », mais dans le domaine discret, pas du tout), et a proposé de suite la première solution utilisée dans ce cas : utiliser un solveur de programmation linéaire entière (pas sûr de la traduction de integer linear programming solver). Et c'est ce qu'a fait Feautrier à l'époque (il a écrit PIP rien que pour ça).
Mais utiliser un solveur ILP mène à de sérieuses contraintes, entre autres que le temps de résolution des (in)équations augmente exponentiellement avec la complexité du nid de boucle à paralléliser/optimiser. De nos jours il y a enfin quelques compilateurs/transpilers qui sont relativement efficaces pour correctement compiler tout ça dans un temps raisonnable, et qui ne passent pas nécessairement par un solveur ILP (et donc le temps d'exploration des espaces d'itération est bien moins grand), mais même dans GCC qui a (avait?) une branche pour les optimisations suivant le modèle polyédrique, ce ne serait jamais activé par défaut.
Bref. Pour passer d'un modèle mathématique correct, et qui fonctionne sur des programmes/boucles jouet, à un compilateur qui peut compiler du « vrai » code (principalement scientifique), il a fallu attendre environ 20 ans (et sacrifier pas mal de thésards à l'autel du modèle polyédrique). Et malgré tout, ce n'est toujours pas intégré dans les compilateurs « mainstream » (tout au plus est-ce une option qu'il faut activer volontairement), car les résultats mathématiques ne se réduisent pas nécessairement en possibilité d'implémentation efficace.
Je suis en train de la télécharger, mais apparemment depuis les US ça prend 300 ans. ↩
[^] # Re: Solution à base de types variants en ADA
Posté par lasher . En réponse à la dépêche Sortie de GHC 8.0.2 et une petite histoire de typage statique. Évalué à 3.
Deux choses:
-Werrorpour du code nouveau. Si ton code a un comportement particulier qui peut générer des avertissements du compilateur, mieux vaut le montrer explicitement sur la ligne de compilation avec des options de type-Wno-…. Si ton code est lié à des bibliothèques qui désormais génèrent des avertissements (qui n'étaient pas générés il y a 10 ans), alors évidemment il faut faire des exceptions.Bref, ne pas oublier « l'existant », qui explique beaucoup de fois pourquoi un compilateur de « vieux » langage dit des choses qu'il faut « écouter » mais ne les force pas.
[^] # Re: Magazine papier ou magazine informatique papier ?
Posté par lasher . En réponse au sondage Quel est votre magazine papier préféré ?. Évalué à 3.
Tu as évidemment raison pour la règle grammaticale, mais le côté « rude » c'est peut-être vrai en anglais britannique, mais pas tellement en anglais américain (ça fait surtout pas très doué niveau grammaire quoi). Par contre, étant donné la façon dont les gens écrivent leurs blogs et leurs commentaires en anglais sur le net, je ne m'étonne pas de ne pas voir « English » avec une majuscule dans des forums.
Perso j'ai été bien plus choqué par son « Somes says » ! :-)