L’invention du mot « ordinateur »

C’est Jacques Perret qui, le 16 Avril 1955 inventa le mot « ordinateur », suite à une sollicitation d’IBM pour trouver une traduction Française au mot anglo-saxon (« computer » pour les machines scientifiques et EDS soit « electronic data system » pour les systèmes de gestion) ! Il faut en effet savoir qu’IBM a l’habitude de traduire l’intégralité de ses notices techniques sans y laisser traîner d’anglicisme.

Alors professeur à la faculté des lettres de Paris, il fut sollicité par un de ses anciens élèves pour cette traduction. Comme on le voit il proposa plusieurs termes, « ordinateur », ou plus exactement son pendant féminin « ordonnatrice » ayant sa préférence.

IBM a tout d’abord protégé le nom. Puis, rapidement adopté par les utilisateurs, la société a finalement décidé de le laisser dans le domaine public, quelques mois plus tard seulement.

Cette anecdote nous montre aussi que notre langue, que nous jugeons souvent inapte à capturer des termes liés à la technologie peut aussi faire naître des mots qui s’avèrent supérieurs à leur pendant anglo-saxon ! Il en va de même pour moi du mot « tableur », bien plus parlant que « spreadsheet »…

Cher Monsieur,

Que diriez vous d’ « ordinateur » ? C’est un mot correctement formé, qui se trouve meme dans le Littré comme adjectif désignant Dieu qui met de l’ordre dans le monde. Un mot de ce genre a l’avantage de donner aisément un verbe « ordiner », un nom d’action « ordination ».

L’inconvénient est que « ordination » désigne une cérémonie religieuse ; mais les deux champs de signification (religion et comptabilité) sont si éloignes et la cérémonie d’ordination connue, je crois, de si peu de personnes que l’inconvénient est peut-être mineur. D’ailleurs votre machine serait « ordinateur » (et non ordination) et ce mot est tout a fait sorti de l’usage théologique. « Systemateur » serait un néologisme, mais qui ne me parait pas offensant ; il permet « systémation » ; mais systemer ne me semble guère utilisable ; « Combinateur » a l’inconvénient du sens péjoratif de « combine » ; « combiner » est usuel donc peu capable de devenir technique ; « combination » ne me parait guère viable a cause de la proximité de « combinaison ». Mais les Allemands ont bien leurs « combinats » (sorte de trusts, je crois), si bien que le mot aurait peut-être des possibilités autres que celles qu’évoque « combine ». « Congesteur », « digesteur » évoquent trop « congestion » et « digestion » ; « Synthétiseur » ne me parait pas un mot assez neuf pour designer un objet spécifique, déterminé comme votre machine.

En relisant les brochures que vous m’avez données, je vois que plusieurs
de vos appareils sont désignés par des noms d’agent féminins (trieuse,
tabulatrice). « Ordinatrice » serait parfaitement possible et aurait même
l’avantage de séparer plus encore votre machine du vocabulaire de la
théologie.

Il y a possibilité aussi d’ajouter a un nom d’agent un complément :
« ordinatrice d’éléments complexes » ou un élément de composition, par ex. : « selecto-systemateur ». « Selecto-ordinateur » a l’inconvénient de 2 “o" en hiatus, comme « électro-ordinatrice ».

Il me semble que je pencherais pour « ordinatrice électronique ». Je souhaite que ces suggestions stimulent, orientent vos propres facultés d’invention. N’hésitez pas a me donner un coup de telephone si vous avez une idée qui vous paraisse requérir l’avis d’un philologue.

Votre

J. Perret

Note de lecture : Programmer sous Windows 95 (4ème édition), par Charles Petzold et Paul Yao

Note : 9 ; Plus qu’un livre : une institution

10 ans après la 1ère édition, cette 4ème (qui ne fut pas la dernière) a encore pris de l’embonpoint pour atteindre 1200 pages. Malgré l’entrée dans le monde 32 bits, cette institution qu’est « le Petzold » reste fidèle à la programmation via les API héritées de Win16. Donc la part belle est faite aux applications fenêtrées : fenêtres, menus, tracés graphiques, impression, boites de dialogue, presse-papiers, etc… Il traite plus succinctement des aspects systèmes et des aspects spécifiques à Win32. Il est temps d’entrée dans le cœur du sujet. On parle de 20 chapitres regroupés en 5 parties.

La première partie comporte 4 chapitres totalisant 270 pages. Le livre ne commence réellement qu’au chapitre 2, qui s’articule autour du redoutable HelloWin.c ! Il faut tout le talent pédagogique de Charles Petzold pour démystifier les arcanes de la boucle d’événement et des handles de fenêtre, afin de donner une logique à l’ensemble. Utiliser le Canvas de fenêtre, l’événement WM_PAINT et autres invalidation de surfaces (sans parler des scroll barres) n’est pas non plus une sinécure, mais le chapitre 3 y vient à bout de manière méthodique. Une bonne base pour aborder la terrible complexité de la GDI au chapitre 4 ! Toutefois, le sujet mérite un livre (au moins) à lui tout seul et celui-ci ne saurait couvrir complètement le sujet…

La seconde partie est consacrée à la saisie. On parle de saisie au sens large : comptez 4 chapitres et 200 pages pour des sujets couvrant bien sûr le clavier et la souris, mais aussi l’horloge et les fenêtres enfant ! On ne se douterai pas au premier abord que la gestion du clavier puisse être si complexe, impliquant des messages clavier, mais aussi de focus de fenêtre, sans compter la prise en compte de paramètres OEM ! Un sujet parfaitement traité en profondeur ici. Heureusement, la gestion de la souris traitée au chapitre 6 génère moins de tracas, même quand on essaie de pousser le sujet dans ses retranchements : souris gérée au clavier, capture de la souris (si, si), etc.. La gestion de l’horloge abordée au chapitre 7 est pour une fois réellement simple sous Windows, peut-être est-ce pour cela que l’auteur a choisi un exemple complexifiant inutilement le sujet en y mettant de la GDI ? Par fenêtre enfants, il faut entendre les contrôles, essentiellement les boutons et la façon dont ils communiquent avec la fenêtre encadrante. Ce chapitre conclue cette partie.

C’est à la gestion des ressources qu’est consacrée la 3ème partie. 4 chapitres et pas loin de 450 pages sont nécessaires pour couvrir ce sujet hélas beaucoup plus compliqué qu’il ne devrait ! Icônes, curseurs et bitmaps que l’on fait figurer dans le fichier .res sont vite balayés au chapitre 9. La gestion des menus est menée de façon plus poussée au chapitre 10, avec quelque cas d’usage non orthodoxes ! Les boites de dialogues sont un sujet très large, allant des boites de messages et des CommonDlg aux boites de dialogues non modales. 90 pages pour couvrir cela de manière progressive et pédagogique ne sont pas de trop. Un sujet qui s’entend sur les 110 pages du chapitre suivant pour couvrir des aspects avancés qui sont une spécificité de cette édition « Windows 95 ». Hélas le sujet est traité avec beaucoup moins de pédagogie, c’est même un peu confus.

La 4ème partie pèse 150 pages et 3 chapitre et est entièrement dévolue aux fonction système. Le chapitre 13, très court donne une impression de bâclé pour traiter la gestion mémoire et des entrées sortie. Le chapitre consacré au multitâche l’est moins, mais on ne peut toutefois le considérer que comme une introduction au sujet. Il ne saurait faire concurrence au texte de Jeffrey Richter. On finit avec la gestion de l’imprimante, un sujet ridiculement compliqué, mais que la prose de l’auteur, encore perfectionnée depuis l’édition précédente, rend abordable.

La dernière partie de l’ouvrage est consacrée aux différents modes d’échange de données. 250 pages sur 5 chapitres leur sont consacrés. 2 chapitres sont consacrés respectivement au presse-papier et au très malcommode DDE. Je m’étonne de le trouver encore là, car son remplaçant (OLE) point le bout de son nez un peu plus loin… L’interface MDI, dont c’était le chant du cygne a encore doit à son chapitre également. Pas de changement non plus pour le chapitre consacré aux DLL, je continue à trouver que la gestion « sans import » n’est pas sérieusement traitée, alors que c’est la seule réellement utile ! Enfin le chapitre 20 nous fait découvrir OLE, nouveauté de cette version. Disons que c’est un chapitre introductif à la question, mais il est plutôt bien fait, eut égard au sujet dont la courbe d’apprentissage est plutôt raide ! Notons aussi que c’est le seul chapitre dont les exemples sont en C++. Bien sûr la couverture du sujet est très loin d’être à la hauteur du Brockschmidt, mais celui-ci n’est pas non plus extraordinairement pédagogique…

Bien sûr, cela semble dépassé de s’intéresser à la programmation Windows aujourd’hui, surtout à aussi bas niveau. Néanmoins, comprendre le fonctionnement d’une interface fenêtrée au niveau de ses fondamentaux n’est pas ridicule. A l’époque où le développement Windows battait son plein, je considère que la connaissance du développement au niveau des API était un savoir fondamental, même à une époque où l’on développe confortablement avec les MFC et des assistants (beurk !). Le Petzold est un modèle de pédagogie, c’est pourquoi j’avais élu l’édition précédente (celle de 1992) « book of the year ».

image

Référence complète : Programmer sous Windows 95, 4ème édition – Charles Petzold & Paul Yao – Microsoft Press 1996 – ISBN : 2-84082-195-8 (VO : ISBN 1-55615-676-6)

Programmer sous Windows 95

https://www.goodreads.com/book/add_to_books_widget_frame/2840821958?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Personal Maps, un Management Workout par Jurgen Appelo

Quelle maîtrise un manager enfermé dans son bureau a-t-il de son équipe ? Probablement pas grand chose ! L’espect prépondérant d’un manager est l’information. Or nous « irradions » de l’information. Or, comme pour tout rayonnement, plus grande est la distance, plus faible est ce rayonnement. Le manager doit donc chercher à être proche du travail qui est important pour lui. Ce n’est d’ailleurs pas seulement vrai des managers !

3 approches à essayer

Bougez vos pieds

C’est le Gemba du Lean, ou le Management by Walking Around, si vous préférez. Pas seulement déambuler, bien sûr, mais se connecter et être en prise avec le terrain. Et évidemment pas contrôler ce qui se passe ! Maintenant, on peut aussi trouver l’idée de devoir se déplacer pour se rendre compte pas très naturelle. Ce qui nous amène à l’option 2

Bougez votre bureau

Ce n’est plus se déplacer, mais être au centre de l’action, quoi qu’il se passe ! C’est aussi être impliqué dans ce qui se passe. Un « management by sitting around » en quelque sorte…

Bougez votre micro

Si la collaboration est améliorée avec la productivité, ce n’est pas nécessairement le cas de la productivité. Permettre de mixer télétravail et présentiel peut permettre d’avoir le meilleur des deux. Bien entendu, cela signifié mettre à disposition l’outillage de travail à distance adéquat !

Effet d’Hawthorne et principes de proximité

Que ce soit en bougeant le bureau ou en déambulant, la présence du manager n’est pas neutre : elle irradie elle-même une information, que le manager se soucie de ce qui se passe.

  • La distance aux personnes doit être proportionnelle à l’importance de leur travail
  • Rendre la question de la proximité variable et non prédictible

Il n’y a pas 1 « sweet spot » de distance, mais deux ! La communication nécessite de la proximité tandis que la créativité nécessite de s’isoler. Ainsi la proximité doit être ajusté en permanence.

Personal map

La distance géographique a une importance, mais elle tend à s’estomper. Ce qui est prépondérant, c’est la « distance mentale ». Jurgen Appelo nous invite à tracer notre mind-map de relation aux autres, dans nos cercles privés, professionnels, éthiques, etc..

Comment commencer ? En suivant les indications de Jurgen, en page 18 de cet article !

Note de lecture : Analyse orientée objets, par Peter Coad et Edward Yourdon

Note : 4 ; Typique de l’approche objet des années 80

Il s’agit ici de l’approche objet typique des années 80. L’emphase est mise sur l’identification “à priori” des objets, ainsi que des attributs et des services attenants, en ne prenant que faiblement en compte le contexte de leur utilisation. Avec 180 pages pour 10 chapitres, ce n’est pas un gros volume. Un second tome, dédié à la conception le complète.

Le premier chapitre est un très classique argumentaire de l’intérêt de l’objet par rapport à la décomposition fonctionnelle en rappelant les grands traits de l’objet : héritage et encapsulation principalement.

Les chapitres 2 et 3 s’articulent autour de l’identification des objets. On notera aussi passage l’évocation de Smalltalk par les auteurs. Les méthodes suggérées sont plutôt empiriques, et surtout on reste sur l’idée d’identifier les objets « à priori », symptomatique du courant de pensée de cette époque.

Le chapitre 4 consacré à l’identification des structures est en fait consacré à l’héritage. Il répond à la question : qu’est-ce qui est et qu’est-ce qui n’est pas un héritage. Question dont la réponse est : ce qui obéit à la relation « est un ». On n’avait pas besoin de 30 pages pour cela ! La notion de « sujet » qui est l’objet du chapitre 5 correspond plus ou moins à celle de package. Elle est curieusement mêlée avec l’idée d’une classe parent qui porterai le même nom… On est décidément dans la mouvance « montrez-moi votre arbre d’héritage !

Attributs et relations sont abordés au chapitre 6. J’ai trouvé que c’était le plus intéressant arrivé à ce point de la lecture, car il répond au moins à des questions de structuration concrètes.

La notion de « service » abordée au chapitre 7 correspond au volet dynamique de la modélisation. Son focus n’est pas très clair car assemble plusieurs concepts, y compris des notions d’architecture et de diagramme d’état. Bref, je n’ai pas accroché.

Le chapitre 8 consacre quelques pages futiles aux outils de modélisation. De même le chapitre 9 est succinct et prétend traiter le passage à la conception orientée objet. Si l’auteur disent bien qu’il s’agit d’un continuum, on ne voit rien de tangible. Le livre se conclut sur un chapitre 10 qui traite de considérations générales sur la mise en œuvre de l’analyse orientée objets.

Ce livre est symptomatique de l’approche objet de la fin des années 80 : une emphase sur les aspects objet liés à l’héritage, plus encore qu’à l’encapsulation (évoquée, mais pas vraiment mise en œuvre). On y voit beaucoup de formalisme et une grande rigidité dans la démarche, ce qui rend cette démarche (comme les autres) bien peu opérationnelle.

L’ouvrage, aujourd’hui ne présente plus qu’un intérêt historique, mais sa lecture ne présente plus d’intérêt pour lui-même. Qui plus est, la prose, du moins dans sa traduction est plutôt aride.

image

Référence complète : Analyse orientée objets – Peter Coad & Edward Yourdon – Masson 1993 (V.O.: Object Oriented Analysis, 2nd edition – Prentice Hall 1991) – ISBN: 2-225-82562-9

Analyse orientée objets

https://www.goodreads.com/book/add_to_books_widget_frame/2225825629?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on

Note de lecture : The C++ Answer Book, par Tony L. Hansen

Note : 6 ; Un compagnon de route au Stroustrup.

Il s’agit, comme son titre l’annonce d’un livre d’exercices corrigés. Aujourd’hui c’est un texte fort ancien. Ancien peut-être, mais volumineux, certainement. On en prend pour 520 pages sur 8 chapitres seulement, sans compter les annexes ! Voyons ce qu’il a dans le ventre.
On passera rapidement sur le 1er chapitre qui est introductif (5 pages) pour nous tourner vers le 2nd qui traite des déclarations et des constantes. Les exercices sont tous très simples, c’est aussi l’occasion d’évoquer des éléments connexes à la questions en plus de répondre à celle-ci.

Si le chapitre 2 ne comptait qu’une trentaine de pages, c’est près de cinquante que nous offre le chapitre 3 dédié aux expressions. On y a droit inévitablement aux ordres d’évaluation de expressions, mais aussi aux comportements « limite » du langage, y compris à ceux causant des problèmes de portabilité. Une partie significative du chapitre est dédié à la manipulation de chaine de caractères, à l’ancienne façon « C ». Le niveau de difficulté augmente significativement, il était au maximum à 1.5 au chapitre 1, il monte ici à 2.5 selon l’échelle exponentielle de l’auteur ! La dimension algorithmique des exercices n’est pas triviale. De quoi se rafraichir les neurones !

Au chapitre 4, on évoque les fonctions et les fichiers. Du moins c’est ce que dit le titre. 60 pages sont consacrées à cette partie qui, en fait a surtout trait à la manipulation de structures : listes, graphes ou tableaux bi-dimensionnels avec les inévitables tris et manipulation. On parle en fait assez peu de fichiers et si on évoque les différences entre C et C++, cela reste du code à affinité C. Bien sûr, le niveau de difficulté augmente sensiblement et culmine à 3.

Le chapitre 5 marque notre véritable entrée dans le C++ car il y est question de classes ! Transition en douceur, car les premiers exercices font suite au chapitre précédent et l’on commence par faire des classes avec des struct ! D’un point de vue utilisation du langage, les 80 pages de ce chapitre restent dans la simplicité. Finalement on travaille surtout à encapsuler la complexité algorithmique dans des classes, ce qui n’est pas si mal. D’un point de vue conception, l’exercice le plus complexe est l’implémentation d’un interpréteur d’expressions à l’aide d’un pattern composite (l’un de mes exercices préféré).

Il me semble assez curieux que le chapitre suivant soit consacrée à la surcharge d’opérateur, car il ne m’a jamais semblé que ce soit une fonctionnalité fondamentale. On trouve quand même 125 pages à lui consacrer ! On commence à rentrer dans le dur du comportement du langage. Il est d’ailleurs troublant de constater que la notion de référence est abordée ici chemin faisant… La classe LINT (large int) nous occupe pas mal de temps, notamment pour comprendre les comportements au limite du langage. Après avoir plafonné à 3 au chapitre précédent, le niveau de difficulté culmine à 4.

Ce sont 90 pages qui sont dédiés à la question des classes dérivées dans cet avant-dernier chapitre. L’exercice sur la classe process nous vaut le niveau de difficulté maximum, mais le chapitre me semble globalement simple. Si on y trouve de l’héritage privé (une fonctionnalité dont l’usage est rare), ainsi que des enum et des classes « friend », nulle trace d’héritage multiple et d’héritage virtuel ! Mais je ne dois pas oublier que le livre date de 1990…

Le dernier chapitre est consacré aux streams. Un sujet souvent bien mal traité. Ici ce sont 90 pages qui lui sont consacrées. Après un démarrage en douceur on aborde vite des exercices compliqués comme l’implémentation de la librairie IO C en C++ et vice-versa !

Les exercices traitant des parties cœur du langage sont toujours valables, ils mériteraient une réactualisation par rapport à la librairie standard, bien sûr. C’est donc un bon bouquin pour solidifier les bases.

Les exercices sont souvent courts et les explications précises. Les plus complexes nécessitent qu’on leur consacre beaucoup, beaucoup de temps ! Par bien des côtés, je retrouve là l’approche du Kernighan & Ritchie. Avec 550 pages il est quand même moins digeste que son aîné. De fait, c’est plutôt un texte dans lequel aller picorer des exercices, plus qu’à être lu de bout en bout ! Le texte fait référence au Stroustrup orignal (1er édition) que je ne possède pas, ayant débuté avec la seconde édition en français.

image

Référence complète : The C++ Answer Book – Tony L. Hansen – Addison Wesley 1990 – ISBN : 0-201-11497-6

The C++ Answer Book

https://www.goodreads.com/book/add_to_books_widget_frame/0201114976?atmb_widget%5Bbutton%5D=atmb_widget_1.png&atmb_widget%5Bhide_friends%5D=on