lasher a écrit 2738 commentaires

Grosso modo, voici ce qui t'attends : * La syntaxe est cryptique pour un débutant, il y a les ";" les "*", les "{}", les "[]" et les "()"

Oui, carrément.

• Le langage est fortement typé, encore une notion de plus à aborder

Non, C n'est carrément pas typé, et tu n'as carrément pas besoin d'expliquer ce qu'est un type [1] aux étudiants pour qu'ils comprennent à quoi ils servent.

• Il faut expliquer comment fonctionne la mémoire, hello malloc
• les trois quarts de tes étudiants se casseront les dents sur les pointeurs, tu viens de leur expliquer le principe de la variable que déjà tu introduis le concept d'une variable qui en référence une autre

Ça par contre, ça dépend vraiment de comment est abordé le langage. Tu peux parfaitement utiliser un sous-ensemble du C et apprendre aux étudiants à manipuler des tableaux (en omettant de leur expliquer ce qu'est un pointeur, et en passant par l'utilisation de typedef). Là où j'ai fini mes études, ils utilisent C+SDL en cours de prog de première année, et les étudiants ne voient jamais de malloc ou autres pendant le premier semestre. Ils découvrent le principe de la programmation structurée et impérativement tranquillement, en « voyant » ce que leurs algos produisent, graphiquement. Les makefiles sont déjà écrits pour eux, et il suffit qu'ils utilisent Geany (par exemple) pour pouvoir compiler leurs trucs. Et ils sont quand même suffisamment futés pour piger la surface de ce qu'est la compilation : la transformation d'un programme écrit dans un certain langage vers un autre langage (le binaire dans le cas de la compilation C).

• Créer un concept abstrait aussi simple qu'une liste requiert l'apprentissage de quasiment tout le langage : structures, pointeurs, allocation mémoire, ...

Oui, mais j'insiste sur le fait qu'il y a déja beaucoup d'algos que tu peux apprendre à des élèves juste avec des tableaux.

Ceci étant dit, et ayant fini de jouer à l'avocat du diable, je suis d'accord avec toi. :-P C n'est sans doute pas le meilleur premier langage (sauf si tu as une formation « complète » en informatique pour accompagner son enseignement : c'est ce qui se passe dans pas mal d'IUT).

[1] Bon, pas tout à fait : il faut quand même expliquer les règles de conversion des types primitifs (int->float, float->int, etc), mais sinon normalement le compilateur est censé gueuler à chaque fois que tu essaies de mettre le contenu d'une variable là où ça n'a pas de sens.

Je ne pouvais pas paralléliser chacune des boucles vectorisées, car la parallélisation a un sur-coût trop important.

Attention à ne pas confondre architectures vectorielles et instructions SIMD (type SSE ou AltiVec). C'est vraiment pas pareil [1]. :-) Un processeur vectoriel des familles implémente une certaine forme de parallélisme de données (donc SIMD), mais fonctionne vraiment différemment d'une instruction SIMD. Mais ce n'est pas très important.

Dans ton exemple de boucle, les instructions SIMD que tu utilises permettent d'obtenir du parallélisme d'instruction (ILP). Il s'agit de parallélisme à grain fin, et oui dans ce cas, on va choisir les boucles les plus internes, car l'overhead (le surcoût) est minimal [2]. C'est aussi quelque chose de possible uniquement parce que tu as un jeu de données extrêmement régulier (mêmes bornes pour tous tes vecteurs, ou bien il est possible de s'arranger pour que la boucle ait les bonnes propriétés). Lorsque tu veux paralléliser un ensemble d'instructions par contre (et pas l'instruction elle-même), tu dois passer par des mécanismes à grain plus gros (pthread, tâche OpenMP, processus MPI, etc.). Et dès lors, oui, bien sûr, il y a un coût pour initialiser les constructions parallèles, l'initialisation de la liste des tâches de ton programme, etc. Que ce soit écrit avec des pthread_create() ou via une construction Cuda, je ne vois pas ce que ça change: ça reste du bête parallélisme de données. Il faudra donc avoir suffisamment de données à fournir à une des tâches créées pour cacher le coût de création de la tâche elle-même, mais je ne vois pas ce qu'il y a de nouveau là-dedans.

Du coup, tu as quand même titillé ma curiosité : quel langage as-tu utilisé pour paralléliser ta boucle ? S'il s'agit d'OpenMP, quel compilateur ? (Par exemple, l'implémentation d'Intel dans leur compilateur est notoirement meilleure que celle de gcc...) Et surtout, surtout, quelle était la taille de tes vecteurs ?

Quant à la vectorisation en règle générale, j'estime qu'un compilateur suffisamment évolué devrait savoir gérer les cas relativement simples sans passer par un humain (de la même manière qu'un bon compilateur C devrait savoir reconnaître for (i=0;i<N;++i) a[i] = 0; et remplacer le tout par un appel à memset(a,0,N*sizeof(type_de_a))). Le compilateur d'Intel le fait, gcc sait le faire dans une certaine mesure, si je ne me trompe pas le compilateur d'IBM le fait pour POWER, etc.

Ici c’est trivial, mais sur un algo. un poil complexe, je ne vois pas comment : par exemple le parcours d’un arbre, je vois bien comment le paralléliser en donnant un sous-arbre à chaque process, par contre je ne sais pas comment le vectoriser.

C'est vrai, mais je ne vois pas le rapport avec les GPU. En fait c'est même pire, les GPU sont notoirement mauvais pour traiter d'opérations sur les graphes en parallèle. Par contre, si tu as les bons outils (et là, je vais ressortir Cilk, que j'ai cité plus haut), tu utilises ... Cilk, qui est parfait pour ça (enfin dans certaines limites quand même), propose une approche divide-and-conquer de la parallélisation, et a même permis d'obtenir des programmes de d'IA pour échecs parmi les plus performants (ça commence à dater, mais Socrates a, à plusieurs reprises, fini dans le top 5 de grosses compèt' d'IA d'échecs vers la fin des années 90).

Cela dit, tu as raison de faire remarquer que le plus gros des applications gourmandes en ressources et tournant sur des gros calculateurs étaient en majorité des applications très régulières en termes structures de contrôle (if, while, etc.). D'où l'importance de trucs genre TOP500, avec comme seule métrique le nombre d'opérations flottantes par seconde (FLOPS).

Mais avec l'apparition des réseaux sociaux, etc., on s'aperçoit enfin dans les sphères du HPC que la métrique est peut-être un peu désuète (ou en tout cas incomplète). D'où la création fin 2010 du challenge Graph500 (patrick_g avait fait une news sur le sujet à l'époque). Ici la métrique est plutôt le nombre de nœuds traversés à la seconde si je me souviens bien, dans un parcours en largeur.

Donc si tu me dis que la parallélisation d'un programme dépend fortement des structures de données utilisées pour traiter un problème donné, je suis d'accord, mais je ne vois pas ce que ça change par rapport à la programmation séquentielle : en fait, si tu veux vraiment passer par une boucle for parallèle pour traverser une arbre par exemple, tu peux parfaitement recourir aux mêmes stratagèmes et algos utilisés pour parcourir un arbre de façon itérative et pas récursive. Il suffit d'utiliser une pile pour simuler les niveaux de récursion. Comme en plus il s'agit d'un arbre, tu sais que les nœuds ne peuvent pas être partagés (les données qu'ils contiennent par contre, c'est une autre histoire). Évidemment, un arbre n'est pas forcément équilibré, et dès lors on se retrouve avec un problème d'équilibrage de charge (mais là encore, Cilk avait fait fort et avait montré qu'ils pouvaient avoir un ordonnancement proche de l'optimal — mais, ironiquement, pas forcément le plus efficace).

Mais je digresse. Tout ça pour dire que je ne suis pas sûr de voir le rapport entre ce que je disais à propos des GPU (et surtout il faut faire bien attention : les GPU Nvidia n'ont rien à voir avec ceux d'AMD du point de vue architectural), et du fait qu'ils ne réinventaient pas vraiment grand chose pour quelqu'un qui a du bagage en prog parallèle, et ce que tu racontes à propos de la vectorisation — qui est vrai hein, c'est juste que j'appelle pas ça de la parallélisation au sens où la plupart des gens l'entendent. :)

[1] Même si par ailleurs, les instructions SIMD sont clairement inspirées par les machines vectorielles.
[2] Dans ce cas précis on peut carrément le considérer comme nul.

Juste un petit mot : il n’est pas dit que les architectures multi-cœurs restent importantes dans le calcul. Entre les deux les algorithmes ne doivent pas du tout être pensés de la même manière.

Les GPU n'utilisent absolument pas une autre forme de parallélisation. Ils imposent l'utilisation d'API ou d'extensions de langages spécifiques (Cuda/Stream/OpenCL), mais au final ça ne change pas grand chose (ce qui ne veut pas dire que certains codes ne devront pas être totalement récrits). Les concepts dont je parle (faire des algos « modulaires » et « parallel-friendly ») restent valable, qu'on parle de machines « many-core » façon GPU ou de vrais nœuds de calculs « many-cores » (avec 16 cœurs/32 threads ou plus sur un nœud). Alors oui les détails changent; oui, quand on utilise Cuda ou OpenCL, il faut déclarer explicitement les entrées et les sorties (par exemple); mais quelqu'un qui a eu à programmer avec MPI ou MPI+OpenMP a eu le même genre de problèmes auparavant. En fait si tu demandes aux chercheurs qui font du parallélisme ou de l'architecture et qui sont dans le coin depuis un moment, les GPU ne font finalement que remettre au goût du jour les architectures vectorielles des années 80-90.

De plus, on a un rapprochement GPU/CPU plus qu'évident depuis ces deux-trois dernières années entre AMD/ATI qui va produire un machin (Fusion) qui allie CPU et GPU, Intel et Knight's {Ferry|Corner|blah}, et Nvidia qui va produire des chips ARM pour accompagner ses GPU. Et je ne parle même pas des projets d'architectures et langages parallèles (genre les langages PGAS) financés par la DARPA...

on devrait apprendre l’ensemble des méthodes, et commencer par accorder plus de place à l’enseignement de la parallélisation tant d’un point de vue théorique que pratique

C'est vrai pour les informaticiens, beaucoup moins pour les physiciens/mathématiciens/biologistes/etc. Plus exactement, pour reprendre l'objectif de Rice avec CnC utilisé en première année de prog ou presque, il s'agit vraiment d'apprendre aux étudiants à correctement structurer leurs programmes, mais il n'est fait nulle part allusion au parallélisme à ce stade. Par contre les étudiants en info en fin de cycle de license/début de master (fin de cycle undergraduate) vont sans doute apprendre un peu plus d'algo/prog parallèle (là où d'habitude il s'agit de cours réservés aux grad students, donc master et plus).

Si tu me demandes de dériver ou intégrer dans les cas simples (polynômes) je sais faire. Si je dois passer par les cas spéciaux (genre lim ±oo / lim ±oo), j'ai totalement oublié comment on gère le cas. Parce que je n'ai plus eu besoin de faire d'analyse depuis bientôt 8 ans. Idem pour le calcul différentiel (pire en fait : je ne pense plus savoir comment résoudre une équa diff du 2nd ordre).

Si tu me donnes un peu de temps pour réapprendre (pas réviser hein, réapprendre) mes cours de lycée/école d'ingé en analyse, je pourrai bien entendu de nouveau faire tout ça (et comme je connais déjà les principes, ça me prendra moins de temps que la première fois). Mais en attendant, j'en suis incapable.

Quant aux histoires de 80% d'une classe d'âge arrivée au bac, tout ça : oui, à partir du moment où on passe de quelques centaines/milliers d'étudiants dans le supérieur, à plusieurs dizaines/centaines de milliers, ô surprise, on a plus de « déchets ». Mais dans l'absolu, on a toujours plus de bacheliers capables qu'avant. Si tu veux vraiment parler des 80% d'une classe d'âge tout ça, on devrait aussi faire comme on faisait dans les années 50-60 : concours d'entrée au collège, concours d'entrée au lycée, et baccalauréat en 2 ans (première ET terminale). Ça coco, c'était de la sélection.

J'en profite pour remarquer que tu n'as pas réagi au fait que les connaissances d'un élève de TS qui sort de nos jours du lycée pourrait plus facilement prétendre intégrer l'X au XIXè siècle que maintenant. Comme ça resterait un concours, on aurait toujours autant de gens qui intégreraient Polytechnique au final, mais on aurait aussi bien plus de candidats qu'à l'époque...

Maintenant, si tu me dis qu'il faudrait revaloriser les études réellement courtes (bacs pro,bacs techno), les formations liées à l'artisanat, etc., là oui je tombe d'accord avec toi, et mécaniquement, ça signifie que moins de gens échoueront dans les autres filières (enfin on peut le supposer). Mais si on forme des étudiants à des métiers dont l'avenir est bouché (genre électro-technique), on fabrique toujours tout plein de chômeurs. Qualifiés, certes, mais chômeurs malgré tout.

La différence entre la fac et les IUT/IUP/STS/Écoles d'ingénieur, c'est que la fac n'a pas le droit de sélectionner à l'entrée. C'est un peu facile de dire que (par exemple) mon ancien IUT a 95-100% de réussite en 2è année quand

• 25% n'ont jamais atteint ladite deuxième année
• Sur 3500-4000 dossiers examinés, seuls 190 sont retenus (soit environ 5-6%)

Une fac de sciences (hors facs de médecine et formations paramédicales) récupère tous les mecs qui n'ont pas réussi à entrer dans les filières sélectives d'une part, et les mecs qui veulent/ont une approche plus théorique ou qui ne veulent pas de la pression imposée par les prépas d'autre part. Donc oui, au bout d'une à trois années de fac, seuls environ 30% des étudiants obtiennent une licence. Ça reste toujours plus important que les 6-10% qui entrent en IUT (dont une partie ne va pas atteindre la 2è année), tu ne trouves pas ?

D'autre part, une bonne partie des enseignements que l'Université (en général, donc) fournit n'a pas vocation à être « professionnalisante » en soit (je pense aux sciences humaines, entre autres, mais aussi aux parties « fondamentales » des sciences dures, genre maths, physique, etc.). Et comme aucun institut professionnalisant (IUT/IUP/etc) ne va proposer de formation allant dans ce sens (enfin, pas la plupart, car heureusement certains comprennent l'importance d'être un chouïa plus pluridisciplinaire dans leurs formations).

En fait je serais bien plus d'accord avec toi si on avait de vrais cours d'algo/prog à partir du lycée, par exemple. Dans ce cas, oui, arrivé à la fac, on utilise simplement un langage que la profession utilise. Mais en attendant, les facs qui utilisent des langages « vraiment utilisés » n'utilisent pas Python (qui est libre et a des qualités certaines, tels qu'un typage fort). Elles utilisent Matlab (qui a des bugs tout partout, et un typage faible tout pourri).

Quelle version de Fortran ? Pas F77. Et je ne l'ai pas vu en F90 non plus.

En attendant, des cours d'architecture avancée des (micro)processeurs, d'optimisation de code dans le cadre de la compilation, d'optimisation dans les bases de données, etc., tout ça, je ne l'ai fait qu'en Master 2 recherche. Pas en école d'ingé.

Pire, la programmation parallèle (qui m'est très chère, parce qu'elle va sans doute me permettre de vivre pendant au moins les 10 prochaines années à venir) reste enseignée au niveau Master 1 ou 2 au mieux. La programmation multithreadée est souvent abordée début/milieu de licence informatique — L3 —, mais très succinctement, et souvent sans prendre en compte les différents types de parallélisme, alors que justement, c'est le genre de trucs dont les physiciens, chimistes, biologistes et mathématiciens appliqués risquent d'avoir besoin lors de la simulation de phénomènes plus ou moins complexes !

Tiens, je ne connaissais pas. Je savais pour les IUT/ingés, mais je ne pensais pas que c'était si courant pour les écoles doctorales d'avoir des diplômés d'IUT... Mmmmf. Je ne sais pas si je dois me sentir moins seul ou si je dois me rappeler que je ne suis pas un unique flocon de neige ... :-/

La mission des universites a "tres" legerement change depuis que l'on donne le bac ou du moins l'aurait du.

Le bac qu'on m'a donné en 2000 te dit merde. Je trouve ça insupportable ce côté « le niveau baisse ». Les connaissances transmises au collège ou au lycée sont globalement les mêmes; elles sont juste « mélangées » entre deux pseudo-réformes et ne sont plus enseignées au même niveau (Par exemple: j'ai fait de l'arithmétique « sérieuse » en option maths de Terminale Scientifique, et maintenant une partie de ce que j'y ai fait est enseigné en fin de Troisième ou Seconde, si je ne m'abuse). Je t'invite à regarder les examens d'entrée pour Polytechnique vers le milieu du XIXè siècle (ça se trouve sur le net, mais j'ai perdu mon signet...), et de le comparer à ce qu'on demande désormais pour entrer dans la même école. Un indice : avec mes connaissances au sortir de ma TS, j'aurais eu une chance d'entrer à l'X aux XIXè siècle; pas à l'aube du XXIè.

En fait, j'aimerais que tu me dises comment tu évalues la « perte de niveau » que tu constates. Il y a d'excellentes vidéos sur ted.com à propos de l'éducation, et de l'évaluation des élèves, et d'à quel point la façon dont c'est effectué (notamment aux USA) est totalement ridicule (exemple : j'ai toujours été nul en examen, notamment parce que la plupart du temps il s'agissait de répéter stupidement ce que racontait le cours, sans réellement avoir besoin de comprendre -- et je sais que je ne suis pas le seul dans ce cas).

Tu te plaints d'avoir du faire de la physique meca, chimie et astrophysique. Tu as mal lu ce qu'il a dit. Il ne se plaint pas du tout. Il dit au contraire que ça fait partie de sa culture générale.

Dans un cursus a la fac la chimie n'est absolument pas obligatoire et tu peux faire la fac de science sans avoir une seule heure de cours de chimie de meme pour l'astrophysique qui est une option que TU choisis.

Ah ben, sauf que si tu vas dans une école d'ingé généraliste par exemple (qui dont est censée être appliquée, orientée pro, tout ça, pas comme la fac quoi), la vérité, c'est que tu auras besoin de toucher à tout (même une école cotée hein, genre une École Centrale). Tu peux bien sûr te spécialiser dans un cursus plutôt info en dernière année, mais en attendant, tu vas bouffer de la méca, de la chimie, des maths, de la RdM, etc. pendant au moins un an, sans doute deux. À côté de ça, les connaissances autour de moi qui sont allées dans ce genre d'école m'ont toutes plus ou moins dit que l'info, ça a été appris sur le tas (en devenant sysadmin pour la résidence étudiante du coin, en écrivant un petit programme pour faire un moteur de recherche et faire du partage p2p en interne, etc.) et pendant les stages, et certainement pas grâce aux dites écoles.

Mmmh, dans l'absolu je serais d'accord avec toi, sauf que euh ...

1. Les écoles d'ingé ont un nombre de places limitées
2. Les IUT, STS, IUP itou (dans ma promo d'IUT, nous étions 190 de pris, pour plus de 3000 dossiers de candidature)
3. Même les Masters en fait !
4. Beaucoup des gens qui n'ont pas été retenus dans les filières sélectives atterrissent à la fac... À défaut d'avoir trouvé une place ailleurs. Et s'aperçoivent qu'ils subissent un tout autre genre de sélection : qui saura être suffisamment autonome pour travailler dans son coin, sans l'impulsion de profs ? (cela dit cela change petit à petit parce que les profs sont bien conscients du problème, mais n'ont absolument pas les moyens en termes de personnels pour remédier efficacement à la situation)

Donc, oui, mille fois oui, l'université doit rester un lieu où l'on peut apprendre sans se soucier de « l'utilitaire », mais cela ne devrait pas l'empêcher de proposer une formation professionnalisante. Par cela, je veux dire que les aspects théoriques, etc., peuvent rester, mais que rien n'empêche d'utiliser des technologies plus ou moins « populaires » pour donner un aspect pratique et immédiatement « rentable » quand un étudiant cherche un stage, par exemple. C'est déjà en partie le cas avec les Licences et Masters Pro. Manque de bol, au moins pour les licences pro, j'ai l'impression qu'elles sont principalement empruntées par des gens qui ont déjà un BTS ou un DUT, et que peu de gens venant de Licence généraliste y vont (cela dit, je n'ai pas de chiffres, et c'est possible que mon appréciation pifométrique se plante).

Les langages fonctionnelles devaient remplacer tout mais bon aujourd'hui encore c'est le C, C++, java, C#, fortran, python, perl, ruby qui dominent et tres tres largement

Alors d'une part, ça a déjà été dit, mais si on regarde Java et C#, de plus en plus de constructions venant des langages fonctionnels s'incrustent. La construction « foreach » (et ses variantes) vient directement des constructions type « mapcar » en Lisp par ex. Ensuite, Perl par exemple a, dès le début [1], proposé des constructions initialement inventées dans les langages fonctionnels (« mapcar » donc, mais aussi les fermetures transitives, etc.).

Mieux encore: il existe des langages dérivés du C (je pense notamment à Cilk et sa « suite » Cilk++) qui permettent la programmation parallèle en rajoutant un minimum de constructions au langage. Et devine quoi ? Ça passe principalement par la construction d'algos « divide-and-conquer » [2]. La notion de récursivité en algorithmique est essentielle, et même naturelle pour tout un tas de structures de données (je pense notamment aux arbres). Lisp, par exemple, permet (tout comme OCaml) de construire aussi bien des boucles que de faire de la récursion (Scheme est purement fonctionnel si je ne me trompe pas, donc le cas est un peu à part). L'important est de piger comment structurer sa pensée, décomposer une action complexe en actions élémentaires simples. Le langage ne changera rien à ça.

[1] Bon en fait non, mais au moins depuis Perl 5.x, et peut-être 4.x, si quelqu'un peut m'aider à retrouver les dates...
[2] désolé, je ne connais pas la formule adéquate en français — « diviser et conquérir » ? « dichotomique » ?

Je suis partagé en ce qui concerne le langage à utiliser pour un premier cours d'algo/programmation. Il y a quelques années, j'aurais sans doute dit comme toi: Python, Perl (oui je sais, plein de gens trouvent ça caca, mais moi j'aime), ou Ruby me semblaient de bons candidats. Et puis à partir de 2004-2005 y'a eu la petite révolution des architectures multicœur. Et depuis je me dis que l'important, ce serait plutôt, quel que soit le langage, de donner de bonnes bases d'algorithmique à tout le monde (au moins pour les algos « fondateurs »), de façon à ce que le programme soit relativement facilement parallélisable. Selon moi cela signifie aborder les algorithmes un peu différemment, et ça passe par des langages différents. Par exemple, à l'université de Rice (Houston, TX), ils utilisent un langage appelé CnC (Concurrent Collection), qui « découple » la description de l'algorithme (les étapes de calcul) et la programmation proprement dite de chaque étape. CnC est juste un langage de description qui rend explicite les dépendances de données entre les étapes d'un algorithme. Suivant l'implémentation faite de CnC (Intel a l'implémentation de référence, écrite en C++, et qui repose sur Threading Building Blocks; Rice a une implémentation en Java de CnC; il existe une implémentation pour Haskell; etc.), on doit écrire l'étape dans un langage impératif, de façon séquentielle. L'idée est de rendre correctement modulaire ses algorithmes, mais de ne pas utiliser de constructions parallèles explicites (seules les dépendances de données, de type producteur-consommateur, sont exprimées).

Du coup, l'expert dans un domaine (physique, bio, méca...) exprime son algo sous forme d'étapes, programme lesdites étapes dans un langage « séquentiel » (C/C++, Java, Haskell, ...), et plus tard, un expert en optimisation (un infoteux donc) pourra, s'il le faut, optimiser chaque étape, forcer un ordonnancement spécifique entre les étapes pour rendre l'application plus rapide, etc.

Évidemment, ça ne résout pas le problème de « quel langage séquentiel choisir », mais ça force à repenser l'enseignement-même de l'algorithmie. Concernant Scheme, LISP, etc., j'ai vu des linguistes aller de la linguistique pure vers la reconnaissance vocale (donc au départ, pas de formation informatique à proprement parler), etc., et user de combinaisons entre Java et LISP assez étranges, et ils ne s'en portaient pas plus mal. Je pense que le problème de LISP ou Scheme n'est pas le langage (et il faudrait arrêter un peu de se focaliser là-dessus); il s'agit plus de la manière dont le langage est enseigné. Quand j'ai lu que le bouquin dont il est question ici a été écrit par un agrégé de maths, je me suis dit « encore un bouquin qui ne servira qu'aux informaticiens/théoriciens ». Je pense que ça me plairait beaucoup comme bouquin hein, c'est juste que je pense que beaucoup de gens (infoteux compris) détestent la programmation fonctionnelle parce qu'elle est enseignée par des gens un chouïa trop matheux. Bien sûr, les langages fonctionnels ont une origine qui s'y prêtent, mais quand on y pense, Fortran aussi, et pourtant ...

Bref. L'auteur de ce journal n'avait visiblement pas l'étudiant moyen en tête lorsqu'il a écrit sa bafouille, et pensait clairement à un futur informaticien. Et dans ce cadre-là, je pense que ce genre de bouquin passe parfaitement.

De plus j'ai bien dit qu'il devait savoir se servir d'un langage et que le scheme est absolument inexistant dans la physique, les maths et les autres matieres scientifiques que l'informatique.

Oui ben à ce propos. Justement, comme LISP, OCaml, et tout un tas de langages fonctionnels ne font pas partie des canons de l'industrie, on se retrouve avec des physiciens qui ne connaissent QUE Fortran et C++ et qui implémentent (avec moultes difficultés) des analyseurs syntaxiques et préprocesseurs pour des langages pour domaines spécialisés/spécifiques (DSL) plutôt que d'écouter un de mes anciens collègues qui se proposait de leur montrer comment implémenter simplement [1] les mêmes DSL en OCaml (qui pourtant est un langage qui s'y prêterait bien plus, tout comme LISP ou Scheme).

[1] Attention, « simplement » ne signifie pas que ça ne prend pas de temps à tester, valider, etc.

Désolé, côte Est. Nous recherchons des stagiaires en compilation ou écriture de « runtime systems » (si quelqu'un a une bonne traduction à proposer, je suis preneur). Si tu penses que c'est dans tes cordes et que ça t'intéresse, tu peux me contacter en message privé.

Yopla,

Je viens de tenter de poster un message (prévisualisation passée), et j'ai récupéré un code 500 en retour. :-/

Oui enfin, là il me semble évident que le monsieur se permet d'être plus cool que pour une « vraie lettre de motivation qui lèche bien tout partout », car il sait qu'on est « entre nous ». Et je trouve ça très bien : si j'étais intéressé par ce genre de profil, je demanderais sans doute via message privé quelque chose de plus formel (pour pouvoir montrer à mes collègues non-geeks qui ont un pouvoir de décision pour ce genre de trucs).

Manque de bol, j'ai bien besoin de stagiaires pour cet été, mais je suis aux USA, et ce n'est absolument pas le profil que je recherche. :-/

Honnêtement je ne me souviens plus. Mais Wikipedia (EN) a une jolie entrée sur le sujet : Productivity paradox.

Je ne suis pas d'accord. Enfin, plus exactement, la notion de valeur ajoutée a parfaitement sa place. Je n'ai pas les études en tête, mais certains de mes profs de génie logiciel nous rappelaient en permanence 2 choses :

1. Facilement 50% des projets informatiques échouent et sont annulés au cours de leur mise en œuvre (parfois juste à la fin, une fois qu'ils ont été vérifiés, mais finalement ne passent pas à cause de la validation, qui aurait dû marcher, sauf que les syndicats n'avaient pas été mis au courant qu'une nouvelle pointeuse allait être mise en place et ... PAF, aplu système de pointage révolutionnaire).
2. Au moins jusqu'au milieu des années 90, les gains en productivité offerts par l'outil informatique par rapport aux méthodes manuelles plus classiques étaient marginaux, voire provoquaient une perte de productivité¹.

Maintenant je ne veux pas dire que l'informatique ne rend pas la vie plus pratique dans de nombreux domaines : certains problèmes ne peuvent être résolus dans un temps raisonnable qu'à l'aide d'outils informatique (je pense aux problèmes liés à l'ingénierie mécanique par exemple). Les réseaux sociaux (et parmi eux, je me permets d'inclure IRC comme étant le précurseur) ont développé tout un tas de possibilités d'interactions entre les gens (il suffit de bien choisir quel réseau nous convient, en fonction de ce que l'on cherche).

En fait je pense que là où l'informatique permet des « gains de productivité », c'est justement dans les domaines où l'on ne pouvait virtuellement rien faire avant que l'informatique existe (et où donc le gain de productivité est proche de l'infini).

¹ D'ailleurs, je crois bien qu'un journal sur linuxfr avait fini par déboucher sur un fil de discussion où il était question des gains illusoires en productivité apportés par l'informatique.

Mon collègue passe son temps à faire des schémas pour expliquer les idées qu'il a sur sa tablette. On peut difficilement faire moins actif. Autant je doute fortement que la prise de note soit un jour aisé sur ce genre de trucs (mais bon, je peux me tromper), autant pour tout ce qui est dessin fait à la va-vite, c'est génial : si j'avais ce genre de trucs je pense que je ne passerais plus un temps fou à chercher où j'ai bien pu foutre ce !@#$ de schéma que j'avais fait sur un bloc-note (sauf qu'entre temps, j'ai rempli ledit bloc-notes, que mes dessins se mélangent avec d'autres notes de choses qui n'ont rien à voir, tout ça).

Bref, j'ai vu l'utilisation que certains en font, celle que moi j'en ai fait aussi, et je trouve ça plutôt cool. Couple ça avec le fait que nous passons notre temps à lire des PDF d'articles de recherche: entre 5 et 20 pages en moyenne (donc pas trop trop long, et supportable pour ce genre d'écrans), c'est vraiment pratique.

Maintenant, ça reste ce que j'appelle un « beau jouet » : c'est cool, c'est pratique, mais clairement pas indispensable.

CentOS ne fait absolument pas d'ombre à Red Hat. J'ai eu à installer certains softs pour mon ancien labo (softs proprios), qui, s'ils ne détectaient pas une Red Hat, refusaient purement et simplement de s'installer. Par paresse (j'aurais pu regarder dans les nombreux scripts d'install et tenter de changer certains trucs), j'ai préféré installer une CentOS. Après tout, j'allais avoir d'autres softs du même éditeur à installer, donc bon.

Maintenant, nous n'avions pas besoin de support. Ça tombe bien, CentOS n'en fournit pas. Si nous en avions eu besoin, nous aurions évidemment regardé du côté de Red Hat. Je vois vraiment CentOS comme une version stable (au sens de Debian) de Fedora. Puisque Red Hat ne la fournit plus, on la cherche ailleurs. :)

Salut,

Je me servais régulièrement de « lastseen » aussi, même avec mes visites quotidiennes, pour une seule raison : couplé avec le fait que je pouvais voir quels journaux avaient de nouveaux commentaires, je pouvais faire du suivi sur les journaux/dépêches déjà visités, le tout regroupé en un même endroit.

Je suis assez d'accord. Maintenant, j'estime que contrairement au lycée (où il faut être neutre à tout prix pour des raisons évidentes — même si c'est jamais totalement le cas, voire pas du tout parfois), à la fac un prof peut avoir un avis ouvertement « biaisé », tant que c'est clair qu'il ne s'agit que de son avis, et dans ce cas, orienter son discours en faveur des LL et donner les « bons » arguments. :)

Après bien sûr, il ne s'agirait pas de faire un cours de rhétorique sur comment convaincre son chef d'utiliser les LL, mais au final ça reviendrait au même.

« La seule chose que l'ingenieur a besoin c'est de comprendre la GPL. » Ça dépend. Par exemple, s'il s'agit seulement d'utilisation de logiciels, GPL/BSD/LGPL/CeCILL/whatever, du moment que ça garantit le droit d'utiliser le logiciel dans un contexte commercial, on s'en fout.

S'il s'agit de développement fait à partir d'une base logicielle libre sous GPL (ou LGPL), alors il vaut mieux en connaître les tenants et aboutissants dès le départ. Bref, l'important du point de vue ingénierie dans ce cas est la partie « légale ». Et c'est là que le côté « idéologique » (et « ethique ») peut faire surface, car du coup tu te retrouves à devoir expliquer que le soft, t'as les sources et tout, tu peux le modifier, ce qui te permet de le tailler comme il faut pour tes besoins, mais que si jamais tu le diffuses, tu dois fournir les sources à ceux à qui tu l'as diffusé.

Et ça, même si quelque part, je trouve ça parfaitement normal (dans le cas de LGPL/GPL), ben pas mal de gens en entreprise trouvent que ça l'est pas (normal). Après tout, OK, ils ont eu la base de code pour rien, ils ont « juste » eu à l'améliorer/la packager/rajouter un gros logo et ne rien toucher d'autre, alors pourquoi ils devraient rediffuser le fruit de leur dur labeur [1] à tout un chacun hein ? [2]

Je ne suis pas certain que faire une formation « pour » les logiciels libres en université soit le bon endroit, mais parler des différents modèles logiciels et de la façon dont les licences fonctionnent, etc., dans des cours de droit liés aux logiciels, oui, je pense que c'est une bonne idée.

Après, les modèles basés sur l'exploitation de logiciels libres ont suffisamment de différences avec les modèles traditionnels pour que là encore, quelques heures de cours pour expliquer les spécificités de chacun soient un plus. Expliquer en quoi la publication des modifications d'un soft libre peut aider tout le monde à mutualiser les coûts, par exemple, c'est quelque chose d'important. Expliquer que dans ce cas, si une boite veut faire de l'argent sur la solution logicielle qu'elle vend, il faudra faire dans le multi-licence, mais que ça a aussi ses pièges, c'est important aussi.


[1] Un consultant en pub/comm' payé 40 000€/mois, mais ça va, parce qu'il n'a travaillé qu'une semaine officiellement, donc on lui doit juste 10 000€.
[2] Et là aussi, il faut rappeler que ben non, le logo ils ont le copyright, et qu'il n'est pas sous (L)GPL...

Que dire alors des rushes d'un concert de Nine Inch Nails que Trent Reznor a diffusés sur le net ? 450Gio de données librement téléchargeables. Je suis un fan de NiN, et pour une fois dans ma vie, je peux avoir accès à tout ces trucs : il faut que je paie un machin pro ?

Euh, sous Win comme sous Linux, j'utiliserais Perl pour ça ...