lasher a écrit 2738 commentaires

Oui, le fait que tout soit référence est embêtant de ce côté (d'ailleurs, tout habitué que je suis à C++, j'avais oublié de faire new au début, oubliant la référence nulle de départ), et effectivement la copie est ce qui pose problème.

Pour reprendre mon exemple :

public class Toto {
    public int a;
    public char [] str = new char[MAX];
    public Titi t = new Titi();
}

Dans ce cas précis, tout est connu à la compilation, et donc le compilateur pourrait allouer sur le tas un sizeof(int)+sizeof(char)*MAX+sizeof(Titi). Par contre, si j'instancie une "struct" toto, puis que je la passe en paramètre, ou que je l'utilise pour initialiser l'attribut d'un objet, etc., je me retrouve à passer sa référence. Donc il faut explicitement fournir une méthode/une fonction de clonage.

En ce qui concerne le ==, je ne vois pas trop le problème en Java. On n'utilise plus .equals de nos jours ?

Comme j'ai pas fait de Java depuis un bail, j'avais du mal à piger où se situait le problème. De ce que j'ai pu comprendre, le problème d'une « struct » Java serait le suivant :

public class Toto {
    public int a;
    public char [] str = new char[MAX];
    public Titi t = new Titi();
}

Alors qu'en C on écrirait tout bêtement :

struct toto_s {
    int a;
    char str[MAX];
    struct titi t;
};

Du coup j'en déduis que lorsqu'on parle des « structs à la C », on veut parler de la façon d'allouer de façon contiguë la mémoire (et ce, de façon garantie). J'ai bon ? Si oui, j'ai du coup j'ai une question subsidiaire : il me semble relativement trivial pour un compilateur d'estimer l'espace pris par un objet uniquement composé de données. Même "Titi.class" pourrait être annoté directement par le compilateur pour indiquer qu'il n'y a pas de méthodes définies.

Du coup, a-t-on réellement besoin d'un « type » qui soit explicitement des structs « à la C » ?

Et là, tout un tas de profs qui enseignent le lambda calcul saignent des yeux… :-)

Lorsqu'on est célibataire sans enfant, être ingénieur aux US est effectivement une excellent opportunité. Il faut cependant rappeler quelques trucs :

1. La plupart des ingénieurs ne touchent pas 200K$/an, mais plutôt entre 100 et 150K$.
2. Suivant l'état où on bosse, gagner 120K$ peut se révéler beaucoup moins intéressant financièrement que gagner 90K$ dans un autre état (je donne des exemples plus bas).

Oui enfin, il faut compter ~20 à 30K$ par enfant qui va à la fac par an quand même. En supposant que les enfants bossent à côté pour payer le loyer etc. (ce qui est courant aux US). Certes, tu as le temps d'économiser pendant ~18 ans pour ça, mais si tu as déjà 2 gosses, disons avec 3 ans d'écart, il faut quand même économiser pas mal chaque année pour accumuler ~80—120K$ par enfant en vue de leurs études, soit l'équivalent d'une année entière de salaire si on a deux enfants et qu'on gagne environ 200K$/an.

Ensuite, en supposant que tu cherches à vivre dans un coin un peu sympa qui t'évite de prendre trop la voiture, qui soit bien situé niveau commerces, voisinage, etc., tu vas facilement payer ~1500-1800$/mois de loyer (en étant gentil) pour un ~40 à 60m² en fonction de là où tu vis. Évidemment, tu peux aller en coloc, tu peux aussi prendre moins grand, mais quand même, il faut compter 1000$ minimum dans ces coins-là. Donc tu peux soustraire ~10% de ton salaire annuel.

Pour en revenir à ce que je disais sur le salaire annuel vs. la qualité de vie/le pouvoir d'achat : un de mes potes était parti de son poste dans l'état du Delaware, où il touchait ~90K$, pour aller bosser à New-York City, où son salaire était de 120K$. Comme il habitait Manhattan (ce qui, bien sûr est un choix, et il aurait pu décider d'habiter plus loin et passer ~1h dans les transports tous les jours), il payait ~2000$/mois en loyer pour un 30m². Les restaurants étaient relativement moins chers que là où il bossait dans le Delaware, mais pour tout le reste, c'était plus cher : le Delaware n'a pas de TVA.

Enfin, du point de vue de la santé : oui, quand on est ingé dans une boite qui a les sous, on est généralement bien couvert. Ça n'est pas suffisant cependant. On est bien couvert jusqu'à un certain point. Le gamin d'un couple vivant dans l'état du Washington et bossant pour un gros labo national (l'équivalent du CEA) s'est cassé le nez. Entre la chirurgie, les visites chez le médecin (et aux urgences avant cela), etc., ils ont plus ou moins grillé les sous « alloués » par leur police d'assurance pour cette année. On était en Janvier quand ça s'est passé.

Un autre pote, français, vivant aussi dans l'état de Washington était employé en tant qu'ingé dans une grosse boite. Il a contracté une leucémie. Là, deux choses l'ont « sauvé » : d'une part, comme il était employé par une grosse boite qui le payait bien, il avait aussi une super assurance maladie. D'autre part, sa femme est médecin dans un des hôpitaux les plus réputés pour traiter son type de cancer. Au bout d'un an (peut-être un peu plus), sa boite l'a licencié, ce qui est la procédure standard, lorsqu'un employé ne revient pas après cette durée. Du coup, heureusement que sa femme pouvait le couvrir avec son assurance.

À côté de ça, un de mes collègues, postdoc dans mon université, touche un peu moins de la moitié de ce que touche un ingé avec un peu d'expérience (~40K$) dans le Delaware, avec une femme et un gamin. La femme ne bosse pas (elle était ingénieur info en Chine, mais son niveau en Anglais est un peu court pour faire des entretiens pour les US), et comme elle a accouché aux US (pour permettre à leur fils d'avoir la nationalité US), ils ont dû payer des sommes importantes (et continuent de payer), avec un système de santé débile basé sur des « réseaux » (une assurance donnée ne fonctionne que pour un certain nombre d'établissements), ce qui a fait que lorsque le médecin traitant a changé de réseau, il leur a fallu négocier avec le médecin et l'assurance pour continuer à être remboursés. Ah oui, aussi, à moins de payer ~350$/mois, la plupart des assurances ne remboursent pas du tout la même chose que la sécu+mutuelle en France. De plus, il y a toujours une franchise à payer (très souvent autour de ~100$) pour les actes médicaux, et donc lorsqu'on va voir un médecin pour une visite de routine, il faut mettre la main à la poche (et un jour je vous parlerai d'à quoi ressemble un cabinet de médecine aux US).

Maintenant, pour être parfaitement honnête, si la femme de mon collègue arrive à trouver du boulot, elle va sans doute toucher dans les ~50K$/an, ce qui devrait être suffisant pour régler les frais médicaux divers et variés… enfin si son niveau d'Anglais s'améliore.

Ce qui m'amène à ma dernière réflexion, celle qui révèle le socialiss' en moi : certes, à titre individuel, être ingénieur aux USA est (globalement) avantageux. Mais c'est oublier comment le système fonctionne en France : les gens gens qui ont une situation plus aisée que la moyenne aident, grâce aux prélèvements sur salaires, les couches les moins aisées de la population. Aux États-Unis, ce n'est que très peu le cas (sauf à être très pauvre). Je trouve donc qu'aller aux US parce qu'on y est mieux payé, est quelque part un peu hypocrite, car on peut toujours revenir en France et se faire soigner (même si on ne cotise plus à la sécu, même s'il faudra mettre un peu la main à la poche). Mais c'est légal, donc je ne grogne pas trop.

Ce qui m'a personnellement donné envie d'aller aux US n'était pas le fric — un postdoc aux États-Unis gagne mieux qu'un postdoc français la plupart du temps, mais franchement pas grand chose par rapport à un ingé. C'était surtout la possibilité de bosser sur des technologies difficilement atteignables en France. Et oui, si d'aventure je décidais d'aller en Californie et bosser là-bas, je pourrais sans doute prétendre à un salaire >120K$/an, mais ce ne serait honnêtement pas la raison première (même si, il faut bien l'avouer, ça ne gâcherait rien).

Mais il n'est pas cité en tant que contributeur au libre (même en étant cité « depuis » le rapport).

C'est pas une histoire d'Anglais. Par exemple, le champ "Documentation" est juste la a titre informatif? Ou bien est-il possible d'effectuer une action en utilisant un truc du genre "systemd-doc " et ça va appeler la commande man kivabien ?

C'est pour ça que je dis que je comprends l'intention (et oui c'est relativement clair), mais qu'expliquer en détails ce que ça fait, c'est une autre chose.

Ben écoute, perso j'ai rien contre systemd, mais si j'ai compris l'intention derrière le truc (tout comme je comprends celle derrière la plupart des scripts d'init), effectivement, j'aurais ete bien incapable de correctement décrire les étapes de cette unité.

Je suis globalement d'accord avec toi. Cependant, autant je ne demande pas à un admin de savoir écrire du code C++ utilisant la méta-programmation, les lambda fonctions, le tout couplé à un runtime écrit en OCaml, autant qu'il sache ce qu'est la programmation structurée, et qu'il sache lire des scripts, ça me semble la moindre des choses.

Bon, je voulais éviter de tomber dedans, mais je vais le faire (un ch'tit peu). Perso j'ai absolument rien contre l’idée d'un système d'init plus moderne/modulaire/configurable/. Et oui, un système d'init qui se concentre sur l'OS pour lequel il est fait, ça me semble raisonnable.

Ceci étant dit, le problème n'est pas tant que systemd existe, mais que d'autres softs de plus haut niveau se basent uniquement dessus, rompant donc avec la portabilité POSIX/UNIX. Donc par exemple si GNOME décide de se baser sur systemd, mais sans offrir une couche de compatibilité "dégradée", je trouve ça extrêmement gênant, et ce, même si personnellement je n'ai plus touché de BSD depuis quelques années.

Quelle norme de Fortran ? Parce que Fortan > 77 est moderne, propose de la programmation structurée… ;)

Je ne vois pas de quoi tu parles. Dans LOo 4.1.3.2, si je clique sur la liste déroulante des styles, et ensuite que je clique sur « more », j'ai bien la fenêtre de styles indépendante qui apparaît.

En préambule : j'utilise Latex à 80%, et les derniers 20% se partagent entre MS-Word et LO-Writer plus ou moins indifféremment. Et oui, je suis d'accord avec toi Zenitram sur certains avantages de Word sur Writer:

• Les styles et templates par défaut ont réellement fait beaucoup de progrès (mais selon moi, c'est uniquement depuis Word 2010, avant, franchement, c'était pas tellement mieux)
• La hiérarchisation des styles dans Word (2010 au minimum) est réellement mieux fichue : on a les styles les plus utilisés en haut de la liste, là où dans LOo/OOo, il faut plus ou moins afficher la liste complète pour retrouver ses petits¹.
• Au moins sur Ubuntu, la création automatique de listes et puces a été désactivée par défaut, et c'est franchement relou, surtout que je n'ai vu aucun raccourci qui me permettrait d'éviter d'utiliser la souris.
• À moins d'avoir raté quelque chose, oui, Word a un correcteur grammatical et pas Writer. Je conçois que ça soit gênant pour une certaine partie des utilisateurs (étant un grammar nazi, et même si je continue de faire des fautes, la plupart du temps je les capte à la relecture).

Maintenant, la capacité d'insérer facilement une table des matières dans Word (via clic droit) il y a ~10 ans a été enlevée à ma connaissance, et que ce soit sous Writer ou sous Word, je trouve que c'est assez relou (sous LOo: insert → indexes & tables → indexes & tables). Je me souviens avoir BEAUCOUP cherché sous Word 2010 avant d'avoir trouvé comment faire².

Ceci étant dit, au moins sous LOo, toutes les tables générées automatiquement sont dans le même menu (table des matières, liste des tables et liste des figures, etc.). Je suis certain que Word a quelque chose d'équivalent, mais je n'ai pas eu à chercher pour le moment (la plupart du temps pour ce genre de choses j'utilise Latex).

Il y a sans doute d'autres trucs que j'ai ratés, mais ce sont les plus importants pour mon utilisation: écriture de rapports, avec insertion de figures et de tableaux, et utilisation cohérente de styles. Je n'ai aucun besoin de publipostage, de fusion de documents, etc. Lorsqu'il faut que je bosse avec un modèle de document, celui-ci est généralement déjà fourni (modèle de rapport pour un projet spécifique, ou bien lettre à entête, ou …), donc je n'ai pas à m'en occuper.

Bref, je suis d'accord avec pas mal de points soulevés ici « contre » Writer. Cependant, tu nous dis :

Le hic est que la réalité montre qu'en fait tu ne gagne pas de temps après (au pire, c'est pareil), tu as juste souffert pour rien au début.

Foutaises. Si si. Ta « réalité » tient principalement au fait que MS Word/Office est largement distribué. Ça ne lui enlève pas ses qualités (qui sont indéniables, tout comme certains défauts de la suite au sens global), mais si on parle réellement d'une utilisation productive d'Office ou de LOo, alors selon mon avis (bien perso hein, tout comme la réalité que tu clames être sortie du champ de ton expérience personnelle), pour les besoins de la majorité de la population, elles sont équivalentes.

Ton opinion me fait penser à ceux qui affirment dur comme fer que manipuler la souris est facile, et qui oublient un peu trop facilement justement les dizaines voire centaines d'heures passées en tant que gamin/ado/adulte à manipuler la souris pour comprendre comment efficacement l'utiliser. Alors qu'au contraire, passer par le clavier est (ou en tout cas était pendant de nombreuses années) en réalité la première chose que beaucoup de gens essayaient, car comme ça ils pouvaient tenter de « parler » au PC (et bien entendu ils échouaient, puisque ce dernier parlait un Anglais en mode SMS: cd, dir, ls etc.).

Il y a clairement une différence d'ergonomie entre Word et Writer. Ça ne veut pas dire que l'un est meilleur que l'autre si on se base sur cette seule différence — le côté « avoir de jolis documents tout de suite » est selon moi un bien meilleur argument.

[1] Note: sur une version récente d'Ubuntu (13.10) en créant un nouveau document, j'ai bien une hiérarchisation des styles aussi (« Default », « text body », « quotation », puis « Title », « Subtitle », « Heading 1 », suivi de 2 et 3). Ce n'était pas le cas pour LOo dans Ubuntu 13.04.
[2] Pour être honnête, vu qu'on ne génère ces tables qu'une fois, tant que les trouver reste logique (sous LOo en tout cas j'ai trouvé que ça l'était parfaitement), c'est un moindre mal.

Concernant l'utilisation de la POO dans ce contexte:

1. Dans le cadre de ton test, effectivement, le procédural convient parfaitement, et faire plus juste parce que l'objet c'est bôôôôôô, c'est ridicule
2. En règle générale, dans les langages interprétés (Perl, Ruby, PHP, etc.), l'utilisation d'objets a réellement un impact négatif sur les performances

De plus, et ça ce n'est que mon opinion, critiquer la façon de coder (objet, procédural, fonctionnel, blah) à tout prix est ridicule, surtout si on n'est pas impliqué dans le développement en lui-même. L'important c'est que le boulot soit fait. C'est la première règle. Une règle optionnelle, c'est que le boulot soit bien fait, et donc qu'on puisse le reprendre facilement. La POO peut aider, mais ce n'est pas toujours le cas, car écrire correctement un programme orienté objet nécessite de ne pas perdre la boule et ajouter 2000 classes juste parce qu'on suit un dogme « POO partout » (et potentiellement, performance nulle part…).

Bref.

Déjà, sur ton smartphone, tu dois penser à tout désactiver. Le GPS. Le bluetooth. Le wifi. La 3G. Tu dois aussi faire gaffe aux applis sur ton mobile qui pourraient consommer du CPU dans ton dos.

Bon, le seul truc vaguement chiant à configurer, c'est désactiver la 4g sur mon téléphone (faut aller dans le menu de config). Le reste (GPS, bluetooth, wifi) est vraiment facilement accessible et désactivable (et en fait, par défaut je désactive tout par exemple).

Concernant les trucs « cachés » : sur mon spyphone (Samsung Galaxy II), mis à part lorsque j'active l'écran physiquement (en utilisant le bouton qui va bien), l'écran reste éteint. Et oui, il se rallume à la fin d'une conversation téléphonique, soit à peu près ~10 secondes grand max.

Lorsque je reviens en France, j'utilise le même téléphone mais sans tous les bidules data/3-4g, du coup, sauf lorsque j'active le wifi, aucun des softs qui réagissent à des événements de type « push » ne me bouffent la batterie (que ce soit des trucs genre gmail, facebook, ou autres). Et j'ai bien grande autonomie dans ce cas.

On se prend un Nokia d'il y a 4/5 ans, de base (type flotte), et je te le fais tenir 2 semaines SANS RIEN TOUCHER.

Bah moi il faut que je touche le smartphone, que je le transforme en « dumbphone », et ça marchera aussi. Et ce n'est pas tricher : tu es en train de dire « si j'utilise un téléphone qui a 1/10 des fonctionnalités d'un smartphone [en étant généreux], je tiens facile 2 semaines ». Moi je dis que pour tenir autant de temps, il faut effectivement que fasse quelques manips pour réduire les fonctionnalités en question. Mais lorsque la durée de vie de la batterie ne sera pas un enjeu majeur, je pourrai réactiver le tout. Essaie de faire ça avec un mobile d'il y a 4/5 ans.

Pour le coup, je croyais que de nombreuses études montraient que (par exemple) dues aux conditions de vie épouvantables des mineurs jusqu'au début du XXè siècle, les personnes pratiquant ce genre de métier avaient tendance à être moins grandes. c'était en partie à cause du fait qu'on utilisait des enfants pour servir d'éclaireurs, ou pour aller dans les galeries difficiles d'accès.

Donc il me semblait établi que les gens dont les métiers imposaient de fortes contraintes sur le corps, et qui pratiquaient ce métier depuis tout jeune avaient des problèmes de croissance. Un peu comme lorsqu'on dit aux ados d'y aller mollo sur la muscu.

J'ai peut-être rêvé tout ça, cela dit. :-)

Quels sont les ports de Python qui sont des implémentations qui continuent d'évoluer ? C'est une vraie question. J'ai en tête les distributions suivantes:

• Python / POSIX
• IronPython (.Net)
• Active Python
• Pypy?

J'ai entendu parler d'autres implémentations, mais qui semblent évoluer peu ou pas du tout :

• CPython
• Jython
• Cython
• D'autres que j'ai ratés, sans doute.

Je me plante complètement ?

De l'autre côté, niveau front-ends pour C++, je dénombre (sans trop me prendre la tête):

• GNU C++
• MS Visual C++
• Intel C++
• Sun/Oracle Studio
• Digital Mars C++
• IBM C++
• Clang++
• HP C++

(Note qu'à part g++, clang++, et peut-être icc, je ne crois pas que la plupart de ces compilos gèrent correctement C++11)

La différence c'est que C++ c'est une norme, et pas seulement un standard. Donc il faut que tous les membres du comité de normalisation soient d'accord, et donc on se retrouve avec des gens de Microsoft par exemple qui ont certains usages courants et des extensions qu'ils voudraient voir normalisés; idem pour les autres participants. Python, Perl, Ruby, Java, etc., même s'ils demandent leur avis aux utilisateurs, restent principalement une implémentation « unique ». Oui je sais, il existe plusieurs implém de Ruby, Python, Java, etc. La différence (selon moi), c'est que globalement il y a une version qui continue d'évoluer en permanence, là où en C ou C++, on se retrouve avec 12000 compilateurs (Sun CC, Intel CC, Gnu CC, Clang+LLVM, etc.). Bien qu'il existe des trucs du genre « Iron{Python,Ruby} » ou même des implémentations alternatives de Java, c'est ultra minoritaire en pratique.

On n'a clairement pas bossé dans les mêmes boites. :-) En stage de fin d'étude vers 2005, ma machine de développement c'était un Céléron ou un Duron à 600MHz, et 512Mio de RAM. En milieu de stage, on nous a royalement doublé la RAM (1Gio, WOUHOU!). Mon environnement de travail c'était à l'époque : Eclipse, Hibernate, JBoss, SVN. Le tout sous Windows 2000. Alors certes je bossais pour une startup, etc., et certes je parle d'il y a 8 ans et des cacahuètes et pas 7 ans, mais c'est pour dire que 4Gio il y a 7 ans, c'était clairement pas une config. standard dans beaucoup de boites.

Tout comme Linux et sa cryptographie à base de GPG ultra-dangereuse. Si ça sonne exagéré, c'est parce que ça l'est. Cependant, ce genre de discours était plus ou moins suivi par un certain nombre de personnes qui n'aimaient pas l'idée que la crypto soit utilisée ailleurs que chez les militaires ou les banques.

Je n'ai aucun avis sur bitcoin en lui-même (j'ai pas investi, et je ne suis que vaguement entre autres grâce à LinuxFR), mais dire qu'une technologie ou un concept peut servir à faire le mal n'invalide pas le bien (potentiel) qui peut aussi en résulter. Par exemple : une tronçonneuse peut couper des arbres, mais aussi des ch'tits n'enfants; libpcap peut servir à diagnostiquer des problèmes réseau mais aussi à écouter sur un hub et récupérer des couples {login, mots de passe}¹; bitcoin peut servir à transférer de l'argent sans frais d'un bout à l'autre de la planète, mais aussi à blanchir de l'argent issu du crime organiser; etc.

[1] Oui je sais mon exemple est daté.

Par contre existe-t-il des « frais de change » pour convertir des €/$/£/blah en bitcoins?

J'ai renoncé à utiliser gViM sous Windows à cause d'une gestion extrêmement bizarre de la sélection à la souris (et du copier-coller), et du fait qu'involontairement je pouvais effacer du texte sélectionné là où sous Linux/UNIX ça ne m'arrivait jamais. Du coup lorsque je dois bosser sous Windows, j'utilise Notepad++.

66K BR ~ 28KS. Je ne connais pas le salaire moyen d'un (bon) développeur au Brésil, et c'est l'information qui manque pour savoir si c'est complètement disproportionné ou pas.

Je ne connais absolument pas les GPU Intel, et je suppose que ce que tu me dis s'y applique aussi. Pour le MIC, il s'agit de « bêtes » x86 avec AVX + 4 hyperthreads, le tout avec un système de caches cohérents (c'est l'ancien Larrabee). Donc ma question sur le MIC était sans doute hors sujet vu que c'est surtout censé servir d'accélérateur pour le calcul (mais après tout, si l'accélérateur se retrouve sur le même die, ça peut p'tet servir à faire du « rendu via CPU » ;-) ), et il aurait fallu plutôt la poser à proposer des GPU intégrés sur Ivy Bridge/Sandy Bridge…

(Par exemple, meme si tu utilises une memoire partage entre CPU et GPU, il n'est pas possible pour le GPU d'utiliser directement la memoire d'une tache utilisateur et reciproquement en fait).

C'est vrai aussi sur les archis de type Fusion d'AMD? Ou bien sur les prochains processeurs d'Intel qui auront le MIC/Xeon Phi et les multicœurs sur le même die ?

Malgré tout, Intel a libéré TBB (Threading Building Blocks), et récemment ils ont aussi libéré leur bibliothèque pour OpenMP. Et au moins pour ce qui est du boulot que je fais avec eux en termes de recherche, notre boulot sera libéré sous GPL.

Je trouve qu'ils ne sont pas si mal. Après, il est évident qu'il est dans leur intérêt de garder le matos relativement fermé, étant donné la position qu'ils occupent sur le marché des processeurs.

La seule chose qui m'énerve pas mal chez Intel, c'est la concurrence déloyale faite aux autres fabricants de x86 quand il s'agit de compiler avec icc ou d'utiliser la MKL (ils sous-optimisent volontairement lorsque le code ne tourne pas sur un processeur Intel).