jeudi 12 avril 2012

L'origine de la fragmentation des formats

La fragmentation des supports, et la nécessité de publier vers toutes les plateformes, induit à toute personne intervenant dans le codage ou la conception d'une quelconque interactivité, de comprendre ce qu'est finalement un programme et sur quoi se base en fin de compte chacune des plateformes.

Les techniques fragmentées que nous utilisons sont-elles si disparates ? La logique informatique ne trouve-t-elle pas une corrélation quelque part entre toutes les formes de publication ? Nous traitons pourtant toujours des images, des textes, des sons, des chiffres ? Alors, où est la vraie différence ? J'ai trouvé une réponse en m'initiant à la programmation en C. Voici quelques observations pour aider tous les codeurs qui se torturent sans jamais comprendre ce qu'ils font :

Au fond, la machine est la même partout et la gestion des données diffère assez peu si l'on observe l'informatique à un "bas niveau", c'est-à-dire à un niveau de programmation qui affecte directement les allocations mémoires du système d'exploitation, comme en langage C par exemple. En C, on déclare des variables qui allouent de la mémoire. On remplie ces variables. Puis, on gère des calculs entre les valeurs stockées dans les variables tout en vérifiant au passage que la mémoire sollicitée et l'environnement le permettent, en plus élaboré bien sûr. Mais fondamentalement, c'est ce principe

Qu'est-ce qui fait alors que nous devons publier dans un format ou dans un autre, selon l'environnement ?

Le langage C est puissant, mais limité d'un point de vue sémiotique. Pour simplifier la programmation, les ingénieurs de l'informatique (dont Bjarne Stroustrup en premier en 1983), ont amélioré le langage des années 70 en y apportant un dictionnaire plus étoffé, le C++ pour ne citer que lui, qui automatise sous la forme d'expressions pré-machées, tout un tas de processus.

Le plus parlant d'entre eux est le principe même de la chaîne de caractère. En mémoire informatique, les données stockées ne sont que des chiffres. Les lettres n'existent pas. Lorsque l'on programme en C, on doit donc coder chaque lettre (à l'aide de librairies heureusement) en chiffre. Ce qui reste tout de même très fastidieux. Alors qu'en C++, par exemple, on utilisera un objet particulier appelé String pour ce faire qui fait référence à une série d'instructions chargées de recomposer une suite de lettres en série de tableaux comportant des chiffres. L'appel à un objet qui automatise un process s'appelle la programmation orientée objet (POO). C'est une des grandes caractéristiques de C++ par rapport à C.

Il en est ainsi pour de nombreux langages inspirés du C mais dont la mission respective a été de s'adapter plus ou moins à son environnement de développement. chaque version apporte ainsi son lot d'amélioration rendant toujours la finalité compatible avec la plateforme d'exécution du fait qu'elle repose sur le même vocabulaire initial, mais sans rétrocompatibilité du fait que l'initial ne dispose pas de ce nouveau vocable.

A ces langages, des interfaces ont permis de simplifier plus encore le travail en évitant même parfois de coder. C'est le rôle du logiciel. Qu'il soit libre ou propriétaire, plus le logiciel code à bas niveau (proche des numéros stockés dans la mémoire de l'ordinateur) et plus l'interface est de haut niveau (sans programmer), plus il y a un grand écart en somme entre ce que l'on code et ce que l'on obtient, plus le logiciel apparaît comme performant.

Inversement, un logiciel qui oblige à programmer dans un dictionnaire farfelu et illogique pour obtenir au final un objet même pas compilé dans un format natif de bas niveau, c'est assez limite d'un point de vue éthique. C'est la distinction que l'on peut faire par exemple aujourd'hui entre une application iOS codée depuis Flash Pro (via SWF, puis Air) qui utilise de nombreuses couches logicielles d'interprétation tout en atreignant l'utilisateur à coder pourtant beaucoup, et une application native et stable pour iOS réalisée depuis une solution Aquafadas, sans programmer. La première n'est pas performante et reste complexe à mettre en oeuvre tandis que la seconde est facile à déployer, très fluide et stable.

Mais, à chaque couche supplémentaire de conversion, l'auteur de l'interface ou de l'environnement, ajoute aussi ses propres contraintes : licences, limites des fonctionnalités, limites de publication. C'est la raison pour laquelle aujourd'hui le Web est devenu une sorte de chienlit de formats standards non interprétés et de formats propriétaires non disponibles sur certaines machines. Les intérêts des éditeurs ne vont pas dans le sens d'un Web ou de formats homogènes. Cela n'est pas sans nous rappeler l'adage bien connu qu'il faut en effet diviser pour mieux régner.

Pour en savoir plus sur cette logique complexité de l'informatique, et pour mieux comprendre l'enjeu trouver la bonne solution logicielle la mieux adaptée à ses besoins, je vous recommande vivement la lecture du cours de programmation en C de M@téo sur le site du zéro : http://www.siteduzero.com/tutoriel-3-14189-apprenez-a-programmer-en-c.html

Plus qu'un cours d'histoire très accessible et rapide, vous y apprendrez les rudiments de la vraie programmation. Ce qui vous aidera à appréhender ensuite tous les autres langages : Objective-c, C#, Java, et même PHP, ActionScript, Javascript et même encore pourquoi pas HTML5. Réalisez les exercices de l'étape I de la programmation en C, puis lisez l'étape II, au moins. Parcourez ensuite les autres langages.

Chaque langage, finalement aussi simple soit-il, utilise un dictionnaire qui fait référence au vocabulaire d'un autre dictionnaire plus ancien, et ainsi de suite jusqu'à atteindre la couche de programmation de bas niveau. Rien n'est inventé. Tout n'est qu'adapté et étiqueté iOS ou Android, Flash ou HTML, bitmap ou vectoriel...

Aucun commentaire:

Enregistrer un commentaire