Blog éclectique & sans sujet précis

Plongée du ciel dans les profondeurs

Pour manger, j’écris des programmes en SQL pour modifier le comportement interne d’un outil qui génère du SQL. Le SQL est lui-même un langage de quatrième génération destiné à masquer à l’utilisateur l’organisation interne d’une base de données et à lui faire croire que tout est soigneusement rangé dans de jolies tables bien ordonnées.

Cette base de donneés s’appuie sur un système d’exploitation (OS) qui ne lui présente que de la mémoire et du disque, la place exacte en mémoire ou sur disque n’étant connue que de l’OS. D’ailleurs, une partie de la mémoire est en fait sur le disque, et une partie du disque est chargée en mémoire.

Le système d’exploitation fonctionne à partir d’un disque dur qui a un cache mémoire, et ment à l’OS sur sa structure interne (cylindres, secteurs...) en faisant sa propre petite sauce, histoire d’obtenir de bons benchmarks et de bien se vendre, et accessoirement de ne pas corrompre les données qu’on lui confie.

Stratosphère

Remontons. Le SQL, qui était à l’origine conçu pour une communication facile entre l’être humain non spécialisé et la machine, n’est plus considéré que bon que pour des développeurs. (On pensait pourtant autrefois donner directement à l’utilisateur final le droit d’attaquer les bases de données en SQL, mais l’expérience montre qu’il vaut mieux y avoir toujours un informaticien, de formation ou de tournure d’esprit adéquate, pour parler à un ordinateur, même avec un langage prétendument naturel mais forcément impitoyablement strict et logique.)

La structure réelle des tables et leur agencement, et le SQL, sont alors masqués par un logiciel de type Business Objects ^[1], qui n’offre plus au non-informaticien que des « Dimensions » et « Indicateurs » qu’il copie-déplace au sein de tableaux évoquant un Excel gavé d’anabolisants. Là, l’informaticien s’est éclipsé après avoir créé l’« univers », qui consiste surtout à donner un sens au fatras de tables, liaisons et clés étrangères de la base de données.

Ces dimensions et indicateurs servent à l’élaboration de « tableaux de bord », rassemblant sous forme synthétique (c’est-à-dire avec des carrés verts et des clignotants rouges disposés avec un goût très sûr de gamin de maternelle) les informations précédemment remontées.

On plane pas un peu haut ?

Je n’ose pas compter le nombre de cycles CPU destinés à simplement interpréter la manière dont les données sont organisées au sein de toutes ces strates, et à faire communiquer toutes ces entités (chacune avec ses structures de données, ses contraintes de sécurité...) et le comparer à celui nécessaire à la récupération et à l’affichage.

Quand M. Durand de la comptabilité mitonne son rapport, Business Objects le réexprime en SQL, traduit par la base en requête d’accès à des tables, donc à des blocs de sa mémoire, que l’OS va aller chercher un peu partout, notamment sur le disque dur, lequel traduira les requêtes en lectures physiques. Et encore, j’oublie toute la circuiterie, je ne connais rien au Northbridge ni au fonctionnement interne du processeur (lui-même segmenté en unités logiques).

Évidemment, simplifier radicalement le système reviendrait à enseigner à Business Objects, sinon à la couche affichage de Windows, voire à la carte graphique, à récupérer les données directement sur les secteurs du disque dur. Cela va totalement à l’encontre des approches « diviser pour régner », « chacun son métier », “best of breeds”, « à chaque type de tâche son programme dédié », etc... qui ont fait le succès de l’informatique depuis cinq ou six décennies. Rien que creuser et optimiser les relations entre chaque composant pour en tirer le meilleur parti à chaque étage rendrait fou un docteur en informatique.

Ce genre de délire n’est plus guère valable, et encore, que pour les projets fonctionnellement archi-limités aux contraintes de performance très fortes, du genre qu’on ne fait plus guère (à présent, même un téléphone a un système d’exploitation complet). L’esprit humain a ses limites quand à la manipulation de la complexité, et les entreprises quant aux temps de développement : on empile donc les briques de composants testables unitairement et à peu près éprouvés, au moins testables.

Cette accumulation de strates quasi-géologiques n’est pas qu’une nécessité de construction, c’est aussi une conséquence de l’évolution historique des besoins : le SQL permettait enfin d’accéder aux données de manière relativement standard et de les manipuler ; Business Objects les présentait enfin sous une forme exploitable autrement que par des tableaux statiques et des graphiques figés ; les datawarehouses (entrepôts de données) agrégeaient enfin à un niveau humain l’accumulation indécente de ces données ; le data mining permet enfin de trouver les corrélations cachées, etc.

Post-combustion

À raison d’un nouveau niveau d’abstraction tous les dix ans, je me demande à quoi ressemblera le suivant : le regroupement des tableaux de bord de manière dynamique sous forme de « vision de monde », interconnectée avec le fameux web sémantique 3.0 qui n’en finit pas d’imminer ?

Accessoirement, les transformations que j’inflige aux données pour alimenter mon datawarehouse ne sont pas réellement du code, mais des données elles-mêmes stockées dans des tables accessibles par SQL (un fichier aurait été beaucoup moins souple). Ce qui me permet de les manipuler comme des données (d’où la notion de métaprogrammation). À la limite, l’alimentation pourrait s’auto-modifier. Je ne pense pas créer Skynet par inadvertance^[2], mais je m’interroge : où cela s’arrêtera-t-il ? Une piste :

Cinquième et Septième Loi de la Programmation informatique (Lois de Croissance) :

La taille d’un programme grandira jusqu’à occuper tout l’espace mémoire disponible.

La complexité d’un programme grandit jusqu’à ce que son concepteur n’y comprenne plus rien.