Poutine/Vegeta

Une petite analogie m'est venue à l'esprit en lisant l'article Friction With Russia May Spell Trouble for U.S..
Dans Dragon Ball, au début, Vegeta est méchant, il est aussi très fort, et il veut conquérir l'univers. Heureusement, le bon et valeureux (et naïf) Son Goku est encore plus fort, il lutte pour la paix et la liberté dans le monde, et vainc Vegeta. Après s'être bien fait calmer, Vegeta devient un allié, pas vraiment un ami, il est frustré, il sait qu'il est moins fort que Son Goku, il se sent humilié en permanence, mais il vit quand même en relative bonne entente avec Son Goku et sa bande. Et puis un jour arrive Babidi, qui lui aussi veut être le grand maître. Il offre un moyen à Vegeta, une superpuissance maléfique, de venir à bout de Sangoku, d'être le plus fort, bref de prendre sa revanche. Vegeta saute sur l'occasion, tabasse Sangoku, montrant ainsi son vrai visage au monde, et amène le chaos sur Terre.
Donc Vladimir Poutine n'a rien inventé, il a tout pompé sur Akira Toriyama, le petit malin...

Vision stratégique

Il y a quelques années, alors que j'étais étudiant en école d'ingénieur, un prof de génie logiciel nous dit, avec son accent du sud (pour bien visualiser, il faut penser à Galabru avec un air goguenard): "un jour mes cocos vous ferez du Cobol". Evidemment on a rigolé en disant que jamais de la vie on ferait des trucs pourris comme ça, que c'était pour les vieux informaticiens qui vivent cachés dans les sous-sols des banques à entretenir leurs vieilles applications des années 70. Malheureusement pour moi, cette vision prophétique s'est réalisée il y a quelques semaines sous la forme d'une mission chez un éditeur de logiciels de finance. En l'espace d'une semaine, je suis passé du C++ et des design patterns à l'ADL (un langage propriétaire proche du Pascal et du COBOL et intégrant en natif l'accès à la base de données) et à OpenVMS. Mon monde s'est écroulé. Durant les jours suivants, j'ai essayé de comprendre comment une entreprise avait pu s'enfermer dans des technologies pareilles, qui n'ont plus aucun avenir, et qui à terme vont poser de gros problèmes de maintenance et de pérennité. La réponse évidente et classique fut: ça marche très bien et ce serait suicidaire de vouloir tout réécrire. Ca marche très bien avec OpenVMS, ok, mais il devient difficile de trouver des VAX et les clients veulent de l'Unix. D'où la nécessité de trouver des solutions, au risque de se trouver dans une impasse, de perdre des clients, ce qui serait dommage car le produit est très riche et bénéficie de dizaines d'années de développements et d'expérience. Première solution: développer un interpréteur pour faire tourner l'exécutable VAX sur des machines Unix. D'où de sérieuses baisses de performances et de sérieux bugs ayant entre autres des impacts sur la manière de développer (ne pas écrires certains types de requêtes SQL, ne pas imbriquer de blocs conditionnels, ...). J'ai été surpris d'apprendre que cet interpréteur était développé en Python, mais apparemment ça marche quand même pas mal et les développeurs ont mis au point plusieurs techniques pour amélirer les performances (au début 100 fois moins rapide, le facteur n'est plus que de 10). Deuxième idée, en cours: développer un compilateur ADL pour Unix, ce qui semble une bien meilleure idée. Projet en cours, qui doit être super intéressant.
A noter qu'à une époque un "développeur fou" avec écrit un programme qui traduisait le code ADL en code C pouvant être compilé sous Unix.
Tout ça pour dire qu'il faut prendre ses aînés au sérieux et que même s'il n'est pas toujours possible de tout refaire de zéro, ce n'est pas une raison pour ne pas prendre le temps de considérer son projet, la direction dans laquelle on veut l'emmener, et mettre en place des solutions visant à en assurer la pérennité.

Mesquinerie

Yahoo Mail propose un outil pour bloquer les emails provenant de certaines adresses et fournit un petit tutorial pour l'utiliser. On gère donc une liste à laquelle on peut ajouter ou retirer les adresses des indésirables. Ce qui est drôle, c'est que dans les exemples, les adresses à bloquer proviennent de Hotmail et celles à débloquer de Yahoo...




Savoir si ça date d'avant ou après l'offre de rachat de Yahoo par Microsoft...

Petits secrets du démineur

Un billet très intéressant par un des programmeurs de Windows Vista à propos de la nouvelle version du démineur.

WTF (suite)

Je continue sur les mauvais développeurs. Après un peu de réflexion, je me dis que ce n'est pas leur faute. J'en étais peut-être déjà arrivé à cette conclusion auparavant, mais en tant que mauvais développeur, c'est mon droit de réinventer la roue. Bref. S'il y a tant de mauvais programmeurs, depuis si longtemps, et que les choses ne changent pas, c'est un simple problème d'offre et de demande. Les entreprises se contentent de ce qu'elles ont, et ne demandent pas mieux. Elles ne sont pas prêtes non plus à mettre le prix pour de bons développeurs. Le marché de l'informatique applicative se compose de fournisseurs, les éditeurs, les entreprises de conseil, et les clients, chez lesquels tournent les applications. En général, les éditeurs cherchent de bonnes compétences, en tout cas on l'espère. En effet, le coût du produit et sa réputation, dépendent beaucoup de sa qualité. Malheureusement aussi, du talent des commerciaux et de sa capacité à verrouiller un marché. Et quand on monopolise un marché, on a moins d'efforts à fournir du point de vue qualitatif. Mais d'une manière générale, les développeurs sont bons, et sont payés en conséquence. Voir Google et Microsoft entre autres, dont la politique est de recruter les meilleurs éléments et de les motiver par de bons salaires et des avantages en nature. Côté utilisateurs, clients, la logique est différente. Si on n'achète pas une application, on la fait développer en interne, soit par des développeurs maisons, soit par des consultants. En général, le client ne connaît à l'informatique, la considère comme un simple moyen, et ne comprend pas un certain nombre de problématiques de qualité, d'architecture, ...qui influent grandement sur le prix et la qualité du logiciel. Le client veut son logiciel rapidement et pour pas cher. Donc on développe vite, en rognant sur les étapes de conception et de test, et on n'est pas trop exigeant sur le niveau des intervenants, qu'on ne sait pas trop évaluer de toute façon. Et après on paye des gens pour maintenir l'application. Ces pauvres damnés passeront alors des moments misérables à s'arracher les cheveux en criant WTF?!?!!, à essayer tant bien que mal à ajouter de nouvelles fonctionnalités à l'application, et seront frustrés à mort parce qu'ils ne pourront mettre en oeuvre quasiment aucune de leurs idées d'amélioration, parce qu'on ne touche pas impunément une application qui est en production et qui fonctionne à peu près correctement. Mes conclusions sont donc que, d'une part, les entreprises dans leur grande majorité n'ont pas intérêt à ce que les développeurs aient un excellent niveau, et que par conséquent les écoles n'ont aucun intérêt à améliorer la formation des ingénieurs de développement, qui en réalité ne seront pas vraiment des ingénieurs mais des techniciens améliorés, et enfin, heureusement que peu de développeurs sont très bons et que la majorité est se capable de se contenter de son niveau de compétence et de salaire, car vu les tâches et les moyens qui leurs sont en général proposés, ils se tireraient rapidement une balle ou reconvertiraient en gardiens de chèvres.

WTF?!?

Je vois dans beaucoup de blogs américains des acronymes que j'arrive en général à déchiffrer. J'ai découvert cette manie aux Etats-Unis, il m'a fallu des mois pour comprendre ce que signifaient ASAP et FYI. Depuis, j'ai appris, entre autres, OMG, WTFIGO, et WTF. WTF = What the fuck!?!!! C'est ce que je me dis des fois en lisant des bouts de codes qui traînent dans mon projet. Ou des fois quand je relis mon propre code. Et la question que je me pose souvent est: combien de développeurs réalisent-ils qu'ils sont médiocres et qu'ils sont uné menace pour la société (héhéhé...)??? Moi je l'ai compris depuis longtemps. Je le dis à tout le monde que je suis nul, et le malheur c'est que personne ne me croit. On me traîte de pessimiste, on me dit que je suis négatif, que de toute façon je ne suis jamais content, que je me dévalorise trop. Ces gens-là n'ont rien compris. Je suis simplement objectif. Evidemment, je continue à exercer mon métier parce que c'est tout ce que je "sais" faire, en attendant de trouver ma voie. Et nous sommes des millions comme ça. Certains sont de pauvres aveugles, qui pensent que sortis de leur école d'ingénieur, ou peut-être avec quelques années d'expérience, ils sont de bons développeurs. Non! Ce sont des nuls, ils devraient simplement le reconnaître, soit leur formation a été très insuffisante, c'est le gros problème de la filière informatique, voire même ingénieur dans son ensemble, soit ils n'ont tout simplement pas ce qu'il faut pour être de bons développeurs. Pour moi, le développement, c'est comme de l'artisanat, il faut une formation solide, de l'apprentissage avec des gens d'expérience. Le problème en informatique, c'est la formation, je l'ai dit, et le fait que les fameux gens d'expérience...sont soit nuls eux mêmes, soit il n'y en a pas, car on ne fait pas de vieux os dans l'informatique. Partout où j'ai travaillé, je n'ai rencontré que très peu de bons, de pros, qui ont des outils et des méthodes, et j'ai beaucoup appris à leur contact. Le reste de mes rencontres n'a fait que renforcer mon pessimisme à propos de la profession. C'est dommage, car le développement, c'est autre chose que les pauvres informaticiens vendus comme consultants qui doivent traîner des costards minables sur des missions merdiques. Ca sent le vécu...
Tout ça pour dire que je consulte depuis peu le blog WTF, ce qui signifie Worse than failure, et qui publie des horreurs trouvées par des ninfomanes sur leurs projets. Entre autres, cet article m'a remotivé pour écrire un petit quelque chose après 1 mois de silence. Il y a aussi celui-là, une vraie perle...

Le père de FORTRAN est mort

FORTRAN, ça a été pour la plupart de mes "camarades" d'école et moi-même le premier langage de programmation véritablement appris et une source constante d'interrogation: "mais putain pourquoi on nous fait faire du FORTRAN, c'est nul, plus personne utilise cette vieille merde?!?!" Et encore, je n'avais pas idée que c'était si vieux (50 ans!)... Au final, on s'en est tous sortis, et on a même appris d'autres langages de programmation. J'aurais quand même eu plus de respect pour FORTRAN et son créateur, John W. Backus, si j'avais eu la curiosité de m'intéresser à son histoire. J'aurais alors compris que nous devons une bonne partie des technologies actuelles de programmation à FORTRAN.

Je reproduis l'article du NYT suivant à propos de FORTRAN et de John W. Backus.

John W. Backus, 82, Fortran Developer, Dies

by STEVE LOHR

Published: March 20, 2007

John W. Backus, who assembled and led the I.B.M. team that created Fortran, the first widely used programming language, which helped open the door to modern computing, died on Saturday at his home in Ashland, Ore. He was 82.

I.B.M.

John W. Backus in the late 1990s. Fortran was released in 1957.

His daughter Karen Backus announced the death, saying the family did not know the cause, other than age.

Fortran, released in 1957, was “the turning point” in computer software, much as the microprocessor was a giant step forward in hardware, according to J.A.N. Lee, a leading computer historian.

Fortran changed the terms of communication between humans and computers, moving up a level to a language that was more comprehensible by humans. So Fortran, in computing vernacular, is considered the first successful higher-level language.

Mr. Backus and his youthful team, then all in their 20s and 30s, devised a programming language that resembled a combination of English shorthand and algebra. Fortran, short for Formula Translator, was very similar to the algebraic formulas that scientists and engineers used in their daily work. With some training, they were no longer dependent on a programming priesthood to translate their science and engineering problems into a language a computer would understand.

In an interview several years ago, Ken Thompson, who developed the Unix operating system at Bell Labs in 1969, observed that “95 percent of the people who programmed in the early years would never have done it without Fortran.”

He added: “It was a massive step.”

Fortran was also extremely efficient, running as fast as programs painstakingly hand-coded by the programming elite, who worked in arcane machine languages. This was a feat considered impossible before Fortran. It was achieved by the masterful design of the Fortran compiler, a program that captures the human intent of a program and recasts it in a way that a computer can process.

In the Fortran project, Mr. Backus tackled two fundamental problems in computing — how to make programming easier for humans, and how to structure the underlying code to make that possible. Mr. Backus continued to work on those challenges for much of his career, and he encouraged others as well.

“His contribution was immense, and it influenced the work of many, including me,” Frances Allen, a retired research fellow at I.B.M., said yesterday.

Mr. Backus was a bit of a maverick even as a teenager. He grew up in an affluent family in Wilmington, Del., the son of a stockbroker. He had a complicated, difficult relationship with his family, and he was a wayward student.

In a series of interviews in 2000 and 2001 in San Francisco, where he lived at the time, Mr. Backus recalled that his family had sent him to an exclusive private high school, the Hill School in Pennsylvania.

“The delight of that place was all the rules you could break,” he recalled.

After flunking out of the University of Virginia, Mr. Backus was drafted in 1943. But his scores on Army aptitude tests were so high that he was dispatched on government-financed programs to three universities, with his studies ranging from engineering to medicine.

After the war, Mr. Backus found his footing as a student at Columbia University and pursued an interest in mathematics, receiving his master’s degree in 1950. Shortly before he graduated, Mr. Backus wandered by the I.B.M. headquarters on Madison Avenue in New York, where one of its room-size electronic calculators was on display.

When a tour guide inquired, Mr. Backus mentioned that he was a graduate student in math; he was whisked upstairs and asked a series of questions Mr. Backus described as math “brain teasers.” It was an informal oral exam, with no recorded score.

He was hired on the spot. As what? “As a programmer,” Mr. Backus replied, shrugging. “That was the way it was done in those days.”

Back then, there was no field of computer science, no courses or schools. The first written reference to “software” as a computer term, as something distinct from hardware, did not come until 1958.

In 1953, frustrated by his experience of “hand-to-hand combat with the machine,” Mr. Backus was eager to somehow simplify programming. He wrote a brief note to his superior, asking to be allowed to head a research project with that goal. “I figured there had to be a better way,” he said.

Mr. Backus got approval and began hiring, one by one, until the team reached 10. It was an eclectic bunch that included a crystallographer, a cryptographer, a chess wizard, an employee on loan from United Aircraft, a researcher from the Massachusetts Institute of Technology and a young woman who joined the project straight out of Vassar College.

“They took anyone who seemed to have an aptitude for problem-solving skills — bridge players, chess players, even women,” Lois Haibt, the Vassar graduate, recalled in an interview in 2000.

Mr. Backus, colleagues said, managed the research team with a light hand. The hours were long but informal. Snowball fights relieved lengthy days of work in winter. I.B.M. had a system of rigid yearly performance reviews, which Mr. Backus deemed ill-suited for his programmers, so he ignored it. “We were the hackers of those days,” Richard Goldberg, a member of the Fortran team, recalled in an interview in 2000.

After Fortran, Mr. Backus developed, with Peter Naur, a Danish computer scientist, a notation for describing the structure of programming languages, much like grammar for natural languages. It became known as Backus-Naur form.

Later, Mr. Backus worked for years with a group at I.B.M. in an area called functional programming. The notion, Mr. Backus said, was to develop a system of programming that would focus more on describing the problem a person wanted the computer to solve and less on giving the computer step-by-step instructions.

“That field owes a lot to John Backus and his early efforts to promote it,” said Alex Aiken, a former researcher at I.B.M. who is now a professor at Stanford University.

In addition to his daughter Karen, of New York, Mr. Backus is survived by another daughter, Paula Backus, of Ashland, Ore.; and a brother, Cecil Backus, of Easton, Md.

His second wife, Barbara Stannard, died in 2004. His first marriage, to Marjorie Jamison, ended in divorce.

It was Mr. Backus who set the tone for the Fortran team. Yet if the style was informal, the work was intense, a four-year venture with no guarantee of success and many small setbacks along the way.

Innovation, Mr. Backus said, was a constant process of trial and error.

“You need the willingness to fail all the time,” he said. “You have to generate many ideas and then you have to work very hard only to discover that they don’t work. And you keep doing that over and over until you find one that does work.”