Pascal L

@Fergus
Il ne me reviens pas de juger de mes moyens intellectuels, mais je n’ai pas à rougir des logiciels que j’ai créé avec d’autres lors des 15 premières années de ma carrière. J’ai été reconnu comme un spécialiste du traitement massivement multi-processeurs en environnement temps réel critique. Je développai également les extensions de l’OS nécessaires à ces conditions de fonctionnement. J’ai vite abandonné le Fortran et le Cobol pour me rapprocher de la machine : Assembleur, puis C puis C++. Par la suite, je me suis intéressé au développement de projets dans des conditions semblables de parallélisme massif (systèmes complexes avec jusqu’à 150 partenaires). Parmi mes collègues, certains étaient capables de faire aussi bien ou mieux que moi, parfois avec d’autres méthodes et d’autres pas, cela dépend de notre capacité à schématiser le réel. C’est cette capacité qui fait le bon informaticien et non la pratique avancée d’un langage. Lorsque l’on sait ce que l’on cherche, on peut toujours le trouver, même lorsque cela n’a pas été appris. Un bon informaticien sait réunir tous les cas particuliers dans un cas général pour produire moins de code et les méthodes objets ne sont pas une peine supplémentaire, mais une facilité. Un bon informaticien doit pouvoir créer des méthodes nouvelles et non encore documentées lorsque le besoin l’exige. Je suis allé jusqu’à écrire dans les registres du processeur et bousculer l’organisation des données pour avoir un adressage performant. L’essentiel est que la méthode soit documentée pour ceux qui viennent après. Rien de cela n’est écrit dans les livres, il faut donc des qualités spécifiques pour faire un bon informaticien et le langage utilisé n’est qu’un détail de la solution. Je n’ai jamais enseigné un catalogue de solutions à mes élèves en JAVA, mais des concepts et les méthodes pour trouver la bonne solution. Ce n’est pas pour autant que le bon informaticien est bon partout. Un bon chaudronnier ne mettra pas beaucoup de temps à maîtriser son marteau alors que d’autres n’y arriveront jamais (moi en particulier). Le chaudronnier doit également posséder des qualités spécifiques s’il veut percer dans son métier et j’admire ceux qui peuvent ainsi maîtriser leurs gestes.

Il n’y a rien de nouveau sous le soleil. Il s’agit ici du comportement de toutes les armées depuis que l’humanité à inventé la guerre. Les conflits actuels ne dérogent pas. Et encore, depuis que les soldats sont payés, la situation s’est un peu améliorée. Il suffit de distribuer des armes pour que certains se sentent invincibles. Autrefois, la soldatesque se payait sur les terres conquises. Et quand cela tournait beaucoup comme pendant la guerre de 30 ans où trois armées dont les Français se sont disputé la Lorraine, il ne restait plus rien à la fin du conflit. Si le Coran a légalisé le partage du butin (sourate 8, le Butin) et le viol des esclaves (sourate 4, les Femmes), c’est que c’était une pratique courante au 7ème siècle et les califes avaient juste besoin d’en encadrer la pratique pour éviter les conflits internes et toucher sa part.

@Fergus
Je ne pense pas avoir pris plus de deux jours pour commencer à utiliser Fortran dans un cadre professionnel. Le plus compliqué, c’était de gérer la perforatrice quand on a aucune expérience de machine à écrire. Deux semaines c’est ce qu’il me fallait pour enseigner java avec les travaux pratiques à des étudiants en master 2. Et Java est un langage objet avec une bibliothèque phénoménale ; c’est un peu plus long à apprendre. En fait, je n’ai jamais prétendu que mes élèves étaient devenus des maîtres, mais qu’ils en savaient assez pour se débrouiller et progresser s’ils avaient du talent pour cela. 
De toutes façons, on ne peut pas mesurer la différence entre un débutant et un cador en programmation. Il vont créer le même nombre d’objets/lignes de codes par jour, mais l’expert va créer beaucoup moins d’objets/lignes de code pour faire le même travail. Mais comme personne ne peut estimer le nombre de lignes nécessaires en dehors du doigt mouillé (et pour cause) pour faire un travail, seul un autre expert peut estimer la qualité d’un programme lors d’une inspection. Mais alors, qui est expert et peut juger ? Tout cela ne facilite pas la progression de carrière dans les grands groupes en informatique et il est important d’en sortir. Si les progressions de carrières étaient fulgurantes dans les années 70/80, c’est juste qu’il n’y avait pas de concurrence.

@Alexis
« Il suffit de disposer de 8 m^3 pour le loger »
Je confirme la surface, mais pas le poids. Il y en avait un dans mon école d’ingénieur dans les années 70 et l’immeuble était ancien avec des planchers en bois. On est pas obligé de mettre la clim et la perforatrice juste à côté. En fait, à l’époque, il y avait aussi des opératrices de saisie (métier plutôt féminin à l’époque) et des coursiers (métier plutôt masculin) qui venaient prendre les bacs de cartes le soir au cas où la machine était un peu éloignée. Une seule machine faisait vivre beaucoup de monde...

@Alexis
« cela n’avait rien à voir avec l’écriture de petits programmes en Basic sur PC »
Oui, c’est beaucoup plus simple sur IBM 360. On écrit un petit bout de programme et quelques données sur des cartes perforées que l’on confie à un opérateur qui nous retourne le lendemain un bout de papier avec la liste des erreurs ou le résultat lorsque le programme fonctionnait. Le programme est écrit en Fortran ou un Cobol, deux langages qui avaient à l’époque moins d’instructions encore que le Basic. On peut maîtriser ces langages en une demi-journée d’apprentissage. Ce qui était difficile, c’était de programmer des algorithmes complexes sur une machine qui avait moins de puissance qu’une montre numérique même pas connectée. Le préfixe Mega n’était pas encore connu à cette époque, que ce soit pour les bits/s, les octets ou les Hertz et on pouvait encore prendre son temps.