lasher a écrit 2738 commentaires

Je trouve qu'il y a une sacré différence entre une implication dans une association pendant un temps limité parce que ça fait partie du cursus (il y a un côté un peu virtuel), et une vraie implication dans une asso volontairement sur son temps libre et dans la durée.

Il n'est absolument pas obligé de participer à des associations. Ça ne fait pas « partie du cursus ». Évidemment, ce que je raconte est à prendre au cas par cas (càd établissement par établissement), mais autant en IUT personne ne m'avait jamais vraiment poussé vers une association (et le BDE était principalement un bocal pour gens qui fumaient de l'herbe), autant en école d'ingé, l'administration incitait fortement les étudiants à participer activement aux associations.

Mon expérience est que les élèves d'école d'ingé restent souvent dans la même association plusieurs années de suite. Comme le turnover est relativement grand (1 an de cours, 6 mois de stage, puis 4-6 mois de cours, puis fin d'année scolaire, puis re-6 mois de cours, puis projet de fin d'étude/stage de 6 mois ou plus), les élèves de 1ère année commencent « grouillots », et à mesure qu'ils deviennent « ancien », on leur propose de prendre plus de responsabilités.

Dans tous les cas, les élèves sont confrontés (à une échelle réduite bien entendu—c'est un peu le but, quelque part) à des contraintes réelles. Par exemple, que tu sois président de l'asso qui organise chaque année le forum de rencontres étudiants-entreprises, ou bien celui du bar étudiant, dans les deux cas il y a de vrais problèmes de logistique à traiter¹, d'une nature différente : dans un cas, c'est un événement ponctuel qui arrive une ou deux fois par an, mais avec de « gros » moyens pour réserver un espace, gérer les inscriptions des entreprises, les paiements, etc.; dans l'autre, c'est une logistique « au jour le jour », où on fait attention au nombre de fûts qui restent pour telle ou telle bière, combien de bouteilles de rouge/blanc, la quantité de café qu'il faut commander à nouveau, etc. Ça veut aussi dire que les sommes mises en jeu sont suffisamment importantes pour que le trésorier ait une vraie responsabilité, et que les banques essaient de leur vendre les produits qu'elles peuvent (étant donné qu'on parle d'assos à but non-lucratif, presqu'aucun produit bancaire ne peut être vendu à une asso). Dans le cas du forum, tu as besoin d'organiser les volontaires le jour J, et t'assurer qu'ils répondent tous bien à l'appel en avance, mais aussi il y a tout un tas de trucs du genre traiteur, etc., à penser. Dans le cas du bar étudiant, tu dois faire attention à ce que ceux qui ont promis d'assurer un créneau remplissent bien leurs responsabilités (et si ce sont les derniers de la journée, qu'ils ont bien nettoyé le foyer étudiant avant de se rentrer—l'administration ne sera pas très contente si ça pue trop la bière à 8h du mat).

Il y a aussi tout un tas d'assos du type ingénieurs sans frontière, etc., qui ont un but humanitaire. Dans tous les cas, il y a de vrais problèmes liés à ce qui tourne autour de la technique et auxquels les élèves sont confrontés. C'est à ça que sert l'implication associative.

L'expérience de qui ? Dans les années 90, des tonnes de gens sortaient d'IUT ou BTS et il n'y avait quasiment pas de passerelle pour tenter d'intégrer une école d'ingénieur (en tout cas, le nombre de places réservées aux gens venant de sections techniques ou technologiques était bien plus restreint). Au moins en informatique, ce qui fait qu'on demande des ingénieurs pour presque tout et n'importe quoi, c'est à mon avis le boum du dév web (et des besoins de net/sys admin résultants aussi) de la fin des années 90 / début 2000. Je n'ai pas de chiffres pour appuyer mon hypothèse, mais il me semble qu'avec la demande qui grandissait quasiment exponentiellement à ce moment-là, trois choses sont arrivées :

1. On embauchait n'importe qui semblant savoir faire du PHP et interroger une base MySQL, y compris des gens sans diplômes ou en reconversion (je connais des gens qui n'avaient absolument aucun background scientifique pour les études supérieures et qui ont fini par devenir devs et responsables techniques très demandés, car ils avaient les années d'expérience pour contrebalancer l'absence de diplômes)
2. On embauchait n'importe qui semblant savoir configurer un Linux ou un FreeBSD avec les serveurs de base : Apache, potentiellement Bind ou Sendmail en fonction des besoins, etc. Idem qu'avec le point précédent : tout plein de geeks et nerds qui avaient appris sur le tas ont trouvé leurs premiers jobs (très) bien payés à cette époque.
3. Il n'y avait tout simplement pas assez de gens certifiés (BTS, DUT) pour savoir faire le minimum de ce qui précède. Et du coup, dans ce cas, si on a vraiment besoin de pouvoir dire qu'on a des professionnels certifiés, on se tourne vers les ingés et bac+5, qui sont censés être plus versatiles et capables de mieux s'adapter (et pour une définition « classique » d'ingénieur à la française, cette attente est peut-être méritée).

De nos jours, on a des IUT et BTS pour « tout », càd, tout un tas de sous-spécialités (réseaux/comms, élec & info indus, info de gestion, etc. — et en particulier pour les BTS, les formations sont vraiment ultra-spécialisées), mais aussi, le nombre d'écoles d'ingénieur (reconnues par la CTI ou pas) a explosé en ~20-30 ans en France. Mécaniquement, à ne demander que des ingés pour des postes qui pourraient se contenter de techniciens, on fait baisser la valeur du travail en question, ainsi que les attentes vis à vis de ce que les techniciens savent faire. Mais aussi, du coup on demande à des ingés de faire un travail que des techniciens fraîchement diplômés pourraient sans doute faire plus vite et mieux (et en tout cas, pas moins bien) car ils ont été formés pour.

Disons que si tu embauches un bac +5 tu as une quasi-garantie : il peut ne rien apporter, mais on espère qu'il ne cassera rien non plus. En IUT, un de nos profs nous avait dit la chose suivante :

Vous savez quelle est la différence entre vous et un ingénieur ? Le salaire.

… puis de rajouter en gros (parce qu'évidemment il exagérait un chouïa) :

… Bon, et aussi, si quelque chose casse qui n'est pas directement lié à son boulot, on attend d'un ingénieur de se débrouiller pour que ça marche à nouveau.

Au moins en informatique (en micro-électronique je ne connais pas assez pour dire quoi que ce soit), au début on peut accepter qu'un dev web ne sache pas installer Apache, etc., mais clairement on attend d'un ingé qu'il sache faire une installation et configuration basiques chez le client si nécessaire (un « vrai » admin pourra ensuite reconfigurer/réinstaller pour la « vraie » version de prod). En pratique, un technicien devra aussi savoir faire une install « de base » sur son poste, à moins que l'infrastructure ait déjà été déployée.

Voici les choses que j'ai « bien » apprises en IUT (et pas forcément bien en école)¹ :

• Analyse & conception de systèmes d'information (ACSI), plus ou moins équivalent au génie logiciel. Mes souvenirs de Merise et UML sont loin, mais les principes fondamentaux sont restés.
• Programmation et algorithmique : bases des algorithmes sur les graphes et les structures de données en général, bonnes pratiques de programmation.
• Programmation sur plusieurs langages : en 2 ans d'IUT, j'ai fait du C, du C++ (la partie objet), du Visual Basic (pour le côté programmation événementielle), de l'ASP (pour cause de chaîne de développement déjà installée avec du tout Microsoft à l'IUT), du XML, du XSL (traitement avec XLS/T), du Java, une pointe d'assembleur (2 TP x86, rien de mémorable, mais suffisamment pour avoir une idée de comment ça marche), et j'en oublie sans doute encore un ou deux. Au final, j'ai vu au moins 6 ou 7 langages (on peut raisonnablement considérer ASP et Visual Basic comme un seul langage, vu qu'on utilisait une sorte de VBScript).
• Bases de données : approche très « pragmatique ». Un cours unique avec un TD sur l'algèbre relationnelle derrière SQL, et des tonnes de cours/TD/TP sur la modélisation de l'information, la création de BDDs qui préservent l'intégrité relationnelle des données, etc. On ne nous l'avait pas dit en IUT, mais en gros on nous a appris à faire des tables et BDD correctement normalisées (on n'avait pas le vocabulaire formel, mais on avait clairement acquis la bonne méthodologie).
• Une approche relativement approfondie de l'architecture des ordinateurs (que 90% de mes camarades ont depuis oubliée, sans doute. :-)).
• J'ai découvert les rudiments de l'administration système pour Linux et Windows (NT).

Dans les matières non-informatiques, on peut aussi noter :

• En cours de communication: une réflexion sur la logique formelle, sa capacité à modéliser le monde, ses limitations sur les nuances dans le langage, etc. À ça, on peut ajouter tout un tas de cours sur la communication en entreprise et inter-personnelle, etc., une certaine approche « psychologique » sur comment la communication se fait entre les personnes en passant par des exercices en classe qui nous mettaient « en situation », etc.
• En cours d'expression : c'est con, mais on m'a appris à correctement rédiger une lettre de motivation, à simuler des entretiens d'embauche, etc. On a continué des exercices de rédaction pour rédiger des résumés, parler en public et si ce n'est le maîtriser, au moins prendre conscience de son langage corporel, etc., qui sont des compétences finalement assez importantes aussi…
• J'ai presque tout oublié de mes cours de compta, mais les cours de gestion en entreprise et son organisation me sont restés, et dans mon expérience, pas mal de choses qui nous avaient été dites se sont réalisées une fois arrivé en entreprise.

Enfin, et c'est très important, au moins dans mon IUT, les profs avaient une succession de cours avec une machine très bien huilée : les profs avaient réglés leurs sujets dans les cours de façon à ce que les matières correspondent. Ainsi, si en maths on apprenait la logique formelle, en communication on abordait cela du point de vue inter-personnel. Si en algo/programmation on voyait les pointeurs, c'est parce qu'en archi on avait fini d'apprendre le fonctionnement de la mémoire dans un ordinateur et l'utilisation des registres; etc.

Du côté de l'école d'ingénieur ou de la fac, une telle communication est au mieux partielle, au pire inexistante. Il y a un projet pédagogique, et ensuite chaque prof enseigne comme il veut, au rythme qu'il veut (dans les sujets sur lesquelles les profs se sont mis d'accord bien sûr). Cependant en école d'ingénieur, j'ai appris quelques trucs aussi :

• Les cours d'algorithmique (recherche opérationnelle) étaient plus formels, et j'ai découvert les notions de complexité en école (en IUT, on nous disait en gros « z'avez vu ? une recherche dichotomique va bien plus vite qu'une recherche linéaire dans un tableau trié ! »)².
• J'ai découvert l'algorithmique et les systèmes distribués.
• Les cours de programmation système étaient plus poussés et rigoureux (enfin, j'ai suivi 2 UV de prog système & distribuée : le premier était équivalent à ce que j'avais fait en IUT, alors que le deuxième allait beaucoup plus loin : programmation C avec threads et RPC, Java et C++ avec CORBA, Java RMI)
• J'ai découvert les rudiments de programmation fonctionnelle en intro à l'intelligence artificielle (LISP), puis plus tard les rudiments de programmation déclarative et « logique », toujours en IA, avec Prolog.
• Lors de mon premier semestre en école, j'avais suivi une UV qui avait poussé à prendre contact avec un/des ingénieurs expérimentés pour discuter de certaines technologies, de la faisabilité de les intégrer pour d'autres projets ou utilisations, etc.
• Les autres matières techniques étaient des redites de l'IUT, souvent en moins bien enseignées.

Du point de vue des matières non info:

• J'ai vaguement rattrapé mon retard en maths vis à vis des prépas/DEUG (presque tout oublié depuis, et clairement pas aussi approfondi que quelqu'un qui a fait un vrai premier cycle en maths/physique).
• J'ai fait pas mal de sciences cognitives (et c'était très bien)
• J'ai fait de la philo (et c'était très bien aussi)
• L'enseignement des langues vivantes était mieux fichu qu'en IUT (c'était pas trop mal en IUT, mais malgré tout trop « scolaire » : pas assez d'opportunités de pratiquer l'oral, etc.)
• Les camarades qui avaient choisi des options différentes étaient assez contents des cours de gestion de projet et d'économie qu'ils avaient suivis.

En règle générale, il me semble que les écoles d'ingénieur poussent beaucoup leurs élèves à prendre des initiatives, que ce soit par l'intermédiaire de la participation à diverses associations, ou via les UV (les élèves qui suivaient l'UV de gestion de projet devaient réaliser un projet dans la « vie réelle », et prendre contact avec de vraies boites/fournisseurs, potentiellement lever des fonds, etc.).

En IUT on m'a donné une excellente méthodologie, et on m'a clairement indiqué qu'il y avait beaucoup plus de choses à apprendre (d'ailleurs, le « on vous apprend à apprendre » si cher aux formations de 2nd / 3è cycle nous a aussi été dit en IUT), mais on ne nous poussait pas forcément à prendre des initiatives (ceci dit, avec ~35 heures de cours par semaine, et en moyenne 2 à 3 projets à livrer en parallèle dès le 2è trimestre de la première année, il n'y avait pas forcément beaucoup de temps pour faire quelque chose en plus que faire la fête à l'époque. Et puis, il y a aussi sans doute une question de maturité.

Du coup, pour avoir suivi deux formations professionalisantes, je peux dire que (1) les gens qui viennent d'IUT ont en général été bien formés et sont parfaitement capables d'occuper des postes de développeur souvent réservés à des ingés en pratique, et (2) malgré tout dans les formations de 2nd cycle, il me semble qu'on pousse plus les élèves à être indépendants et à prendre des initiatives, car on les destine à devenir chefs au final (alors que les techniciens, pas forcément).

Pour info, mon IUT avait reçu 3000 dossiers de candidatures pour 190 places en 1è année (j'ai ensuite appris que l'année suivante ils avaient reçu 4000 dossiers). Autant dire que les gens qui étaient acceptés étaient tous capables d'apprendre, même s'ils ne savaient pas forcément ce qu'était l'informatique au sortir du lycée.

Je ne vois pas où est le problème. Qu'il s'agisse de journaux ou de commentaires, je navigue à -42. Du coup, même si l'un ou l'autre a potentiellement une note négative, ça ne veut pas dire que je ne vais pas lire (ou au moins lire les réponses si le journal/commentaire m'ennuie).

Bref. Sauf si une/des personnes abusent des ressources (dans le sens : elles floodent avec leurs posts de merde, et du coup il y a plus de bruit que de signal), je suis pour les laisser poster : au pire elles se ramassent une note (très) négative, qui m'incitera (ou pas, la preuve, je commente ici, et toi aussi !) à passer mon chemin, ou bien je vais quand même lire, et participer au troll qui s'en suivra.

Le Patriot Act n'empêche pas la liberté d'expression (qui est sacro-sainte aux USA), mais permet de ficher et surveiller ceux qui ont une activité intellectuelle « à risque ». Ils restent libres de dire ce qu'ils veulent (dans la limite des lois sur la calomnie, etc. bien sûr).

Comment est défini la peine à trouver?

Les formations professionalisantes collectent toutes des stats vis à vis du temps entre l'obtention du diplôme et le premier emploi (tout le monde ne répond pas, mais la portion qui répond au sondage est statistiquement significative de ce que je peux voir).

Et je sais que beaucoup de facs font de même en règle générale. Le questionnaire qui est envoyé demande quel est l'intitulé du poste, ce qui permet d'inférer si le diplôme correspond au boulot (certains sondages demandent même explicitement si c'est le cas).

Donc c'est une façon d'établir un critère : la plupart des diplômés d'écoles d'ingé en spécialité informatique trouvent un emploi en moins de 6 mois (je crois que la moyenne est moins de 3 mois). Si on en croit ce site,

• 88 % des titulaires d’un DUT ont un emploi 2 ans après leur diplôme.
• 59 % des diplômés en emploi occupent des postes de niveau cadre ou professions intermédiaires.

Bon, la statistique reste vague (2 ans ça reste long), mais je suis prêt à parier que la majeure partie de 88% a obtenu le boulot suite à un stage de pré-embauche et en tout cas en moins d'un an (mais c'est complètement du pifomètre).

Note: Je ne suis pas complètement d'accord avec Briaeros, mais grosso-modo, je pense être sur la même longueur d'onde.

Concernant les jobs en info qui ne demandent pas 5 ans en informatique : je dirais qu'un technicien avec un DUT (ou un BTS, ça dépend des contextes) est largement capable d'assurer une grande (la majeure ?) partie du développement informatique demandé par les boites. J'ai acquis plus de bonnes habitudes en 1 and d'IUT concernant le développement logiciel (et confirmé en 2è année) qu'en 3 ans d'école d'ingénieur. Et surtout, ce qui m'a fait grandir en tant que développeur, c'est la pratique lors des stages, en plus des projets parfois un peu trop « scolaires ».

Ce qu'on m'a demandé de faire en projet de fin d'étude en école d'ingénieur, j'étais franchement capable de le faire en fin d'IUT (disons que ça m'aurait sans doute demandé 1 mois de plus, vu que j'ai principalement fait de l'auto-formation aux différents frameworks Java que je devais utiliser à l'époque).

Il y a aussi beaucoup de choses qu'on sait (soit théoriquement, soit en pratique) une fois arrivé en fin de second cycle, mais qu'on devrait pouvoir savoir faire aussi après un certain temps à bosser en tant que professionnel. Et donc la seule différence, c'est que dans un cas, il faudra former le technicien en interne (mais ce sera a priori spécialisé et une formation courte, voire appris « sur le tas » grâce à un collègue), là où dans l'autre cas, l'état paye (via le master ou l'école d'ingé).

Ceci dit, ce que je raconte est spécifique à l'informatique, ça ne veut pas dire que c'est vrai pour toutes les formations (la formation des médecins dont tu parlais est un bon contre-exemple).

Les deux syllabaires, les ~10000 idéogrammes du chinois simplifié, etc., n'entrent en compte que pour le nombre de combinaisons possibles (sans tenir compte de la grammaire ou de la logique inhérentes à ces langues). Oui, les deux syllabaires du japonais peuvent (et sont) être mélangés dans une même phrase, mais au final, ça ne fait que 2×46 symboles avec la ponctuation et le chiffres en plus. Et tout ne sera pas utilisé en même temps.

Au final, si j'écris « わたしはラシャーと私はのフランスアム » (mélange d'hiragana et katakana, avec un idéogramme, car j'ai oublié tout mon japonais et j'ai laissé google traduire), je me retrouve avec 18 caractères, donc la plupart sont sans doute codés sur deux octets, et un peut-être sur plus, soit ~40 octets pour une phrase simple, mais comme on parle de noms de fichiers, ça devrait aller. :-)

C'est "l'esprit" des gens conseillant. Si pour une personne qui a un problème avec des espaces dans un nom de fichier, on lui sort "tu as tort, remplace par des underscores, comme moi", ça ne donne franchement pas envie de rester sur cet OS. C'est un "détail", mais détail+détail+…

Pour le coup je suis assez d'accord. Gamin, j'utilisais DOS, puis quand Windows 95 est arrivé, j'ai usé et abusé des noms avec espaces (malgré l'abstraction un peu ratée, vu qu'utiliser un terminal DOS pouvait parfois toujours être nécessaire, et du coup on se retrouvait avec monfic~1.txt au lieu de monfichieràmoiquejaime.txt). Avec bash_completion je peux facilement utiliser des espaces en ligne de commande (il rajoute les guillemets tout seul, et je suis sûr que zsh peut faire pareil), mais c'est vrai que mon réflexe est d'utiliser des underscores, et c'est vrai que je peste un peu contre les espaces dans les noms de fichiers, mais je me rends bien compte que c'est un réflexe de vieuxcon™®©.

En règle générale, les espaces dans les noms de fichiers ne gênent absolument pas lorsqu'on utilise une GUI (je n'ai pas trouvé d'exemple gênant en tout cas), mais en ligne de commande ça force juste à rajouter quelques symboles (guillemets), mais bon, on s'y fait. :-)

En préambule, notons que je ne suis pas la personne à qui tu répondais au début. Je ne cherche pas à « avoir raison » à tout prix, mais simplement il y a tout un tas de gens qui utilisent des langages non déclaratifs, non fonctionnels, et qui ont un réel intérêt à utiliser des globales dans ce contexte.

J'ai un peu de mal à comprendre ce que tu veux dire, mais j'ai l'impression que tu te compliques la vie : une variable en Erlang est comme une variable en C/Java, à quelques différences près :
- tu ne peux pas déclarer de variable en dehors d'une fonction
- tu ne peux affecter qu'une seule valeur à une variable.

Ben, « valeur » = variable à affectation unique. C'est peut-être un peu pédant comme terminologie, mais c'est celle qui est utilisée par une bonne partie des gens qui font des langages et de la compilation (« single assignment »). Le fait que tes variables soient aussi confinées à l'intérieur d'une fonction fait aussi que tes fonctions semblent devenir pures. Du coup, j'aimerais savoir ce qui te fait dire qu'Erlang n'est pas un langage fonctionnel pur¹.

J'ai l'impression que tu cherches à tout prix à avoir raison. Tu peux tourner les choses dans le sens que tu veux, il n'y a pas de variable globale en Erlang.

Absolument pas. Je suis intervenu dans la discussion parce que s'il n'y a pas de variable globale, je me demande comment on fait pour passer un (ensemble d')état(s) entre différents processus. Internet me dit « passage de message », ce qui implicitement indique une sérialisation des valeurs en cas de « conflit » (si 2 processus veulent modifier la même valeur qui est rendue accessible/visible par un processus Erlang).

Je n'ai jamais dit le contraire, je suis seulement d'avis qu'utiliser une variable pour ça est une mauvaise idée. La Lisibilité du code est une raison (qui pour moi est suffisante à elle seule).

Et comme d'habitude, tout dépend du contexte. :-) _kaos_ donnait l'exemple d'un mutex globalement accessible. Bon, perso, je créerais quand même une structure de données pour encapsuler le machin, mais c'est parce que j'aime pas les gros verrous qui deviennent potentiellement de gros points de contention dans une appli. Mais son exemple est parfaitement sûr : la sémantique-même d'une variable d'exclusion mutuelle impose de passer par des fonctions qui garantissent l'accès exclusif. Donc un mutex déclaré globalement, à défaut d'être performant, est sûr.

En général je pense que nous sommes d'accord : une variable globale non contrôlée, c'est mal. L'utilisation d'agents ou d'objets pour encapsuler la variable, ou bien limiter sa portée est évidemment une bonne pratique.

Plus spécifiquement, concernant errno, j'ai pas de doc sous la main (et la flemme, il est près de 5h du mat ici, et au lieu d'aller pioncer je te réponds… :-P) mais il me semble que dans les systèmes POSIX modernes, il y a une transformation de errno en mode TLS (thread-local storage), histoire que chaque thread ait sa copie. Évidemment, c'est pas standard pour le langage C (et pas sûr que C11 ait adopté la pratique), mais ça permet quand même d'éviter tout plein de trucs chiants.

L'important c'est donc de bien spécifier les modes d'accès aux variables globales : soit complètement globales « lexicalement », soit globales sous un espace de nom, de classe, etc., mais qui peuvent quand même risquer un accès concurrent. Dans un soft que je maintiens vaguement, j'ai rajouté tout un ensemble de variables globales qui servent principalement à l'initialisation au tout début du programme. Certes, ces variables se trouvent dans un espace de nom, mais bon, si tu utilises mon truc, tu vas vite arriver à faire un using namespace tartempion; parce que sinon ça devient vite relou : ces variables sont souvent lues (et uniquement lues) par les threads générés ensuite. Bref. Oui, il faudrait que je prenne le temps d'écrire des fonctions qui vont se charger d'accéder à la variable, et au minimum garantir qu'elle sera mise à jour « atomiquement ». Mais en pratique, le main vérifie quelle valeur donner à ces variables une fois pour toutes et tous les threads vont ensuite simplement les lire, et si par malheur un utilisateur les modifiait, ben, ça ne changerait sans doute pas grand chose (oui, ça pourrait provoquer des bugs, mais ce serait quelque chose d'assez aisé à traquer).

… Et oui, je m'invente des excuses pour ne pas mieux encapsuler mes variables globales (parce que c'est du code de recherche avec grosso-modo 5 utilisateurs qui savent ce qu'ils font).

Je n'ai jamais fait d'Erlang, donc je dis sans doute une connerie. En supposant qu'on parle de langage fonctionnel pur (ce qu'est censé être Erlang si je me souviens bien), il n'y a généralement pas de « vraie » variable, et uniquement des « valeurs ». Du coup, il y a uniquement des affectations uniques, et si l'on « modifie » la valeur, alors en réalité on crée une nouvelle valeur qui est visible pour l'appelant ou bien pour la portée lexicale « inférieure ». Du coup une valeur créée « tout en haut » de l'arbre de visibilité syntaxique sera visible de tous, mais ne pourra être modifiée (puisqu'il s'agit d'une valeur et pas d'une variable).

Il n'y a donc peut-être pas de variable globale à proprement parler en Erlang, mais il y a des valeurs globales (et en demandant à un moteur de recherche comment créer des variables globales en Erlang, on tombe sur différentes réponses qui proposent de créer un process/serveur pour gérer l'état de la/des variables, ou bien de passer par un équivalent de table associative, ou bien…).

Plus généralement, j'essaie d'éviter les globales comme la peste (parce que je code des logiciels très bas niveau et lourdement parallèles, mais aussi que d'un point de vue génie logiciel, c'est pas top), mais pouvoir créer/modifier un état global à tous les threads, à certains niveaux du programme, oui, c'est utile. À noter que je compte une variable de classe comme une globale, et idem pour une variable déclarée dans un namespace en C++ par exemple. mes variables « totalement » globales sont généralement en lecture seule.

Les licences sans copyleft fonctionnent très bien : […]

J'irai même plus loin : Nessus a changé de licence pour passer de GPL à un truc propriétaire en grande partie parce que des entreprises qui font du « consulting sécurité », n'avaient aucun scrupule à virer les copyrights/crédits, modifier/corriger les bugs, et utiliser Nessus en disant qu'ils étaient à l'origine du produit. Et comme les « consultants » ne laissaient pas leur soft derrière eux (ils faisaient juste le scan des réseaux, etc.), il n'y a aucune preuve matérielle de la manipulation.

Plus prosaïquement : même si les boites avaient été honnêtes et avaient dit qu'elles utilisaient Nessus, puisqu'elles ne distribuaient pas le soft aux clients, rien ne les obligeait à distribuer le code source modifié avec leurs patches.

GPL ou BSD/MIT, dans ce cas, n'a rien changé.

En droit français (et européen si je ne m'abuse), si le code a été publié, à moins d'avoir déposé le brevet avant de publier le code, tu ne peux plus breveter quoi que ce soit (car la publication fait automatiquement rentrer le procédé en état de l'art). En droit US, tu as un an à partir de la publication pour breveter ton invention (que la publication soit sous forme de journal, code source, présentation, etc., n'importe pas). Au-delà, la publication devient de nouveau du « prior art ».

Pour moi, un très gros contributeur, c'est juste un contributeur qui publie régulièrement des patch. Ça n'a, contrairement à ce que j'ai pu laisser ressentir (mea culpa d'ailleurs) rien à voir avec la quantité de lignes de code. Ceci dit, je crois (et je ne vais pas vérifier, pour deux raisons: 1) perte de temps 2) remise en question difficile) que les plus gros contributeurs au LL sont des gens non affiliés. Un logiciel libre qui aurait une personne (physique ou morale) comme contributeur majeur, c'est typiquement le genre de logiciel libre que j'essaierai d'éviter en milieu professionnel, car il aurait peu de potentiel de pérennité.

Alors euh, en 2007, d'après Andrew Morton, 80% des contributeurs réguliers au noyau le faisaient parce que c'était leur job. Les 20% restants sont bien des amateurs (dans le sens « noble » du terme). Tout ça pour dire que si, dire qu'une boite X est bien un gros contributeur a du sens : et ce qui fait la pérennité du code n'est pas qu'une boite y ajoute beaucoup et régulièrement ou pas, ou bien au contraire que ce soit un individu. Tant que le patch peut être testé/qualifié par les gens qui sont responsables de leurs branches respectives (avec L.Torvald tout en haut et un droit de véto si nécessaire), je ne vois pas où est le risque. Au contraire : les gens qui sont responsables de diverses branches du noyau appartiennent à des boites différentes (Red Hat, Google, etc.) : il n'y a aucun intérêt à laisser l'autre boite être seule responsable de certains aspects du noyau.

Parce que (comme souvent :-P) tu apportes une info intéressante et factuelle (LO 4.4 qui vire les commentaires en Allemand) et juste après tu fais une remarque pleine de condescendance en disant que tu toi tu as la vision d'être le roi du monde du code alors que les autres se contentent d'être maires ou chefs de collectivités locales (comment ça, j'exagère ?)¹.

Ceci étant dit, je reste sur mon avis précédent : le contexte joue énormément. Le logiciel (libre) utilisé pour implémenter le serveur des impôts, etc., aura certes des parties qui pourraient, peut-être, à terme, être réutilisées dans un autre logiciel pour implémenter un autre type de logiciel qui soit servira à la déclaration d'impôts d'autres gens, ou bien à implémenter un autre type de logiciel côté serveur qui s'interfacerait avec les serveurs de l'État français. Mais en règle générale, le contexte est franco-français, payé par et pour les Français, et je ne vois pas vraiment en quoi commenter en Anglais servira à qui que ce soit au final (au contraire, si jamais des formules, hypothèses, etc., sont exprimées dans les commentaires, on pourra ainsi plus facilement les copier-coller à un non-informaticien spécialiste des impôts et qui sans doute a un niveau limite en Anglais²).

A contrario, le soft que tu développes a clairement un contexte transnational : il est logique que tu commentes en Anglais, car ça encourage les contributions/corrections de bugs, tout en permettant de distribuer le tout à des clients non-francophones ou germanophones. Maintenant, je me dis que si une équipe chinoise développait un soft pour le marché chinois, elle n'en aurait absolument rien à faire (au moins au début) de développer en Anglais : (1) Le niveau en anglais de la plupart des chinois n'est franchement pas top, et (2) leur marché est déjà potentiellement composé de 1,3 milliard de client (et plus raisonnablement/de façon plus réaliste, sans doute ~300—500 millions). C'est à peu près ce qui se passe avec les clones de Facebook & co en Chine.

Mince, tu as raison. Je voulais trop que ce soit Joy. :)

Oui, parce que l'équipe voulait pouvoir élargir son nombre de contributeurs. Du coup, le seul moyen de faire ainsi est de choisir une langue qui est comprise par le plus grand nombre de développeurs potentiels.

Cependant, j'ai des anecdotes, comme par exemple une connaissance qui bossait (en Europe) pour une boite japonaise. Il préférait quand les dév japonais commentaient en Japonais, vu que leurs tentatives d'écrire en Anglais rendaient souvent le code incompréhensible.

Mais tu vois ce que je veux dire ? Pour moi, les commentaires sur les structures de données, ou bien qui précèdent la définition d'une fonction sont une pratique saine. Idem pour un point de code qui risque d'être idiomatique plus loin dans le code, ou pour quelqu'un qui connaît le domaine que le code modèle. Par exemple, il m'est déjà arrivé d'écrire un truc du genre (en Perl) :

open my $fh, '<', $filename or die "Couldn't open $filename: $!";
# this is idiomatic. More info: <url>
my $raw;
{
    local $/;
    $raw = <$fh>;
}

# do something with full-text-as-string in $raw

Le "slurp" est un idiome qu'on retrouve dans plein de bouquins / articles qui parlent de Perl. Du coup, plein de gens ont même créé une fonction pour « généraliser » le procédé, mais c'est tellement rapide à écrire que la plupart du temps personne ne s'emmerde à faire ça. Comme je savais que des stagiaires auraient peut-être à relire cette partie du code, j'ai rajouté une URL qui explique ce que ça fait, mais c'est vraiment uniquement pour eux que j'ai fait ça. Et je ne le fais que dans le fichier qui sera le plus vraisemblablement ouvert en premier. Dans les autres je ne m'embête pas.

Super, je vais pouvoir renommer mes noms de politiques d'ordonnancement de threads en

typedef enum {
  ROUND_ROBIN, 
  ROUND_ROBIN_RANDOM_STEAL, 
  ROUND_ROBIN_RNDROB_STEAL,
  PUSH_THREADS_UNTIL_QUEUE_IS_FULL_THEN_GO_TO_NEXT_QUEUE,
  PUSH_THREADS_UNTIL_QUEUE_IS_FULL_THEN_GO_TO_NEXT_QUEUE_RANDOM_STEAL,
  PUSH_THREADS_UNTIL_QUEUE_IS_FULL_THEN_GO_TO_NEXT_QUEUE_RNDROB_STEAL,
} Policies;

… Ou alors, j'écris un truc du genre

typedef enum {
   RNDROB,               // Round-robin policy: push thread in scheduler, then move on to next queue
   RNDROB_RDMSTEAL,      // RNDROB + random stealing of tasks if idle
   RNDROB_RNDROBSTEAL,   // RNDROB + steal in a specific order
   PUSHFULL,             // Fill a thread queue until it's full, then move on to next thread queue
   PUSHFULL_RDMSTEAL,    // PUSHFULL + random stealing
   PUSHFULL_RNDROBSTEAL, // PUSHFULL + ordered stealing
} Policies;

Je trouve qu'utiliser l'anglais pour les noms des variables, fonctions, etc., dans le code, c'est une pratique saine (mais comme tu le fais remarquer, du « vrai » anglais, et donc il faut éviter les faux amis, etc.). Par contre, des commentaires dans la langue de l'équipe qui programme, ça ne me choque pas (et c'est même mieux que de tenter de parler anglais si on n'a pas un niveau assez bon).

Perdu. Microsoft (ainsi que d'autres boites) a tenté d'imposer sa définition du terme « open source » en disant qu'ils proposaient des licences « open source » de Windows à certain de leurs clients, ce qui effectivement donnait accès au code source de l'OS mais ne donnait en rien le droit de redistribuer, et je ne sais même pas s'il y avait droit de modification, même en interne (je suis sûr qu'au moins pour certains contrats/clients c'est possible).

En résumé, un « logiciel libre » satisfait aux 4 libertés exprimées par Stallman et la FSF : liberté d'exécuter le programme comme tu le désires, de l'étudier et le modifier, de le distribuer pour aider ton voisin, et même de distribuer des versions modifiées. Mais un logiciel dit « open source » fait de même. La différence entre « libre » et « ouvert » est philosophique : un logiciel libre respecte les 4 libertés pour une raison morale, alors qu'un logiciel ouvert le fait pour des raisons techniques. Je détaille plus bas.

Le point de vue « open source » dit en gros qu'un logiciel devrait être redistribuable, modifiable, etc., car d'un point de vue pragmatique et technique c'est comme ça qu'on obtiendra les meilleures versions d'un logiciel donné. Il y a un côté très « darwiniste » de ce point de vue : seuls les meilleurs logiciels libres survivront.

Dire qu'un logiciel est « libre » c'est dire qu'il satisfait les 4 libertés énoncées par Stallman et la FSF, exactement comme pour les logiciels open source. Cependant, dans le cas des logiciels libres, la raison de soutenir cette façon de faire du logiciel est que la connaissance ne devrait pas être enfermée derrière des barrières propriétaires. Entre autres choses, il y a l'idée qu'une fois que le logiciel fait fonctionner une machine que tu as achetée, tu devrais pouvoir faire ce que tu veux de la machine, et donc par transition, tu devrais pouvoir modifier le logiciel qui la contrôle, et distribuer tes modifications à qui tu veux. La liberté qui est visée est celle de l'utilisateur final, plus que celle du développeur qui a développé le logiciel.

Zut, j'oubliais :

Google se sert effectivement des produits open source pour faire fructifier son business. Les licences open source n'interdit en aucun cas des pratiques commerciales. Mais contrairement à Microsoft, Google contribue énormément au noyau Linux et à Android, les produits Google sont bien basés sur ces mêmes logiciels open sources.

À un moment les mainteneurs du noyau ont dû menacer de séparer les modifications faites pour faire marcher Android, tellement ils ne faisaient aucun effort pour que tout soit homogène. Et en pratique, sans être aussi mauvais, la gestion du source d'Android ressemble quand même pas mal à une quasi-tivoïsation : lorsque des gens essaient de faire une distribution Android indépendante, s'ils cherchent à ajouter leurs propres modifs qui ne correspondent pas aux critères qualité de Google (perte en autonomie, etc.), ils se font menacer d'être ± coupés du play store… Je comprends que c'est parce que Google ne veut pas perdre en image de marque, et que du coup une fonctionnalité utile mais qui fait perdre trop de batterie, trop vite (par exemple, dans le cas des applications qui s'exécutent en parallèle sur le même écran) est mauvais pour la réputation du système, mais c'est quand même abuser. Alors que lorsque c'est Samsung qui l'a fait malgré les menaces de Google, ben comme ils ont les reins solides, ils peuvent se permettre.

Sauf erreur de ma part je ne connais aucune autre société, à part Microsoft, qui se sert de brevets logiciels bidons pour rançonner des sociétés utilisant des produits open source comme Linux et Android. Mais si tu as des exemples, je suis intéressé.

Je n'arrive pas à retrouver son post de blog, mais Bill Joy (fondateur de Sun Microsystems) a parlé de sa guerre de brevets avec Bill Gates (MS) à propos de StarOffice, mais aussi Steve Jobs à propos de CDE. En substance, chacun est venu le voir et le menacer de poursuites, et à chaque fois il a répondu qu'eux-mêmes utilisaient des technos dont Sun possédait les brevets. Donc tu as au moins Microsoft (œuf corse) mais aussi Apple.

Et en pratique, IBM aussi — contrairement à ce que beaucoup de (grosses) boites US aimeraient faire croire, une fois qu'elles sont un chouïa fossilisées et ont plus de mal à grossir/grandir/innover, elles ne se gênent pas pour utiliser leurs brevets pour intimider les plus petits.

En même temps, xbill, c'est toujours un jeu rigolo. :-)