050716 7 min

codescript

Dans le code script pour créer un applicatif il y a toutes les embûches, en physique, de la réflexion sur la topologie, la structure, les règles, les contradictions formées par les choses à dissocier, et aussi l'émergence puisqu'il s'agit du produit fini : l'effet.

Pour produire l'effet, qui en soit est une fonctionnalité, accompagnée d'un sous-ensemble de fonctionnalités utiles à la gestion de la raison de l'application, il y a le même saut infranchissable pour une personne rationnelle.

Ce saut, celui de l'émergence, est pratiquement imprévisible, si par exemple on travaillait "aveuglément", c'est à dire sans tester le code, les emplacements, la présentation du résultat de l'opération de l'application, eh ! bien l'effet sera sûrement une surprise.
Or l'effet est partie intégrante du résultat, il doit faciliter la toute dernière et apparemment la plus simple des étapes de l'acheminement de l'information, assurer sa lisibilité.

En réalité, c'est impossible de travailler aveuglément, le test produit toujours un quantité exponentielle mais maîtrisée d'erreurs logiques en raison du fonctionnement de l'ensemble.

C'est assez rare en fait de produire un code et qu'il marche du premier coup, par contre c'est fréquent qu'on fasse dix mille tests pour choisir un effet véritablement minuscule en comparaison de la chaîne logicielle déclenchée à chaque fois pour y accéder.
c'est toute la joie du "développement" = "la dev" = principe évolutionniste évident.

Parfois par exemple il se peut qu'on ait à lutter contre une entropie, si par exemple pour résoudre la distinction entre deux conditions lors d'un effet,
qui donc produisent chacun des effets différents alors que je les veux identiques, (par exemple : l'utilisateur est inscrit ou non, sur telle page spécialement "ceci" s'affiche, mais "ceci" est soumis à la condition de l'inscription) et à ce qui se produit habituellement dur les autres pages.
dans ce cas résoudre ceci provoque le reconditionnement de toutes les conditions antécédentes qui mènent aux deux qui sont en contradiction.
En réalité au final, c'est dans la structure des conditions, des "IF" dans dans "IF", (=des fonctions dans elles-mêmes =récursivité).

D'ailleurs c'est marrant, entre la fonction et les if, qui est "une" fonction, étudier la structure des "if" c'est comme étudier en miniature, en pièces détachées, des dispositifs qui font partie des "fonctions".
On peut dès lors s'amuser à décomposer une fonction pour trifouiller dedans et voir comment ça marche, ce qui est très profitable car parlant sur la façon idéale de structurer l'ensemble du logiciel.

en réalité, on ne résout jamais, au grand jamais, un problème frontalement, par exemple en "s'abaissant" à rajouter un interrupteur de plus, quelques variables de plus. Si on faisait comme ça à chaque fois le script serait très lent, complexe et très difficile à faire évoluer. c'est une contre-production (que d'agir à la va-vite).

Imaginez seulement que "les lois" c'est pourtant exactement comme ça que ça procède, ça rajoute incessamment des nouvelles conditions, de sorte qu'inéluctablement, certaines se chevauchent, d'autres se dévorent littéralement.

Or je suis certain que les professionnels du domaine, n'ont à écrire que quelques ligne de code par jour, après une réflexion qui aura certainement duré toute la journée, et la nuit.

Lorsqu'on envisage une fonction, on doit entrer progressivement à l'intérieur des fils de la couture qui fait l'application, et apparaissent immédiatement les conditions nécessaires pour faire émerger" cette fonction, depuis l'existant. Bref comment utiliser/reformuler l'application pour qu'en plus elle ait cette nouvelle fonctionnalité.
ensuite il faut longtemps pour s'apercevoir de tout ce que ce changement suscite.

Parfois on fait des changements qui en suscitent d'autres, dont on s'aperçoit après coup que cette évolution était inéluctable.

Par exemple je crée un forum;
en premier une table dans une base avec à chaque entrée, nom, mail, message.

Je n'ai pas besoin de date si ils sont enregistrés dans l'ordre... mais soudain j'ai besoin de la date parce qu'avec l'effet produit par les vieux messages j'ai envie de savoir de quand ils datent. Ok pas de problème, je rajoute une entrée "date", (à partir d'un certain temps on ne se fait plus avoir par le bon ou mauvais choix de format, car là aussi il y a moyen d'être spécialement stupide ou intelligent et savant).

Une fois ceci fait, je me rend compte de la potentialité de cette date, qui permet de classer, mais aussi de comptabiliser les mails par période de temps, ce qui est une émergence de la fonction "date" rajoutée pour une raison futile au départ.

Puis finalement quand on a compris cela, c'est l'inverse comme je le disais, à chaque fois qu'on rajoute une fonctionnalité, c'est indépendamment des conséquences sur la physionomie du logiciel.
il peut très bien être entièrement transformé, si par exemple après un certain nombre de fonctions il est plus malin de les regrouper en un seul tableau initialisé dès le départ et dans lequel il n'y aura plus qu'à piocher.

Cette fonction puissante peut s'avérer utile pour une raison très anecdotique. Ceci constitue un complexe du programmeur, qui refuse de rajouter des conditions alors qu'il le peut, qui doit mettre longtemps avant de l'envisager car c'est complexe en réalité, car c'est le résultat d'une discipline qui permet rien moins de faire que l'ensemble fonctionne correctement.

A un moment, il fallait transformer un site en portail, donc en faire une variable à l'intérieur d'un système plus vaste.
Ce système plus vaste est lui-même bien entendu, mais sa façon de se cloner va inciter, d'une part, à ce que les améliorations faites sur l'application agisse sur tous les sites, et d'autre part, utiliser des bases communes, car à un moment il faut attribuer les distinctions, là où avant il n'y en avait pas.

Le mot fixe (chaîne) qui désignait une base devient une variable,
et c'est uniquement pour cette raison qu'on est autorisé à dire que "tout le site ne devient plus qu'une variable d'un système plus vaste".

Aussi, parce qu'il aura fallu créer des bases parallèles, et au-dessus ou au milieu, une base qui porte un nom distinctif des autres et qui est en référence de façon "solide" (chaîne de caractère).
ça veut dire évidemment que ce "portail" peut du coup très bien lui même devenir un sous-ensemble d'un réseau plus vaste,
et cette fois ci, au lieu d'avoir dix mille entrées solides à rendre variables, il n'y en aura qu'une ; alors que faire ceci démultiplierait incroyablement l'activité de l'application.

C'est dans cet esprit qu'à été développé "RSS", le flux d'infos où il n'y a plus qu'à piocher : chacun fait sa ligne éditoriale, et l'information est seulement "choisie" pour constituer le corps du message que constitue ce choix, "l'effet".

quand je dis "chacun", si chacun est tout le monde, cette disposition décorative du monde serait pénible finalement ; il s'agit en réalité de la possibilité de créer des entités pensantes ou identitaires, des webzines, qui profitent de la technologie "RSS" (= les variables sont dans un tableau à une autre adresse que celle du serveur personnel, ce qui ne pose aucune distinction pour le logiciel, lequel va piocher l'information mise en forme par les structures logicielles distantes, et unificatrices.

Dans un sens l'évolution de la société, comme celle d'un logiciel, tend à faire devenir plus vaste le terrain de jeu du réel, et du coup, de moins en moins compréhensible si on cherche à deviner à quoi correspondent les variables alors que ce serait plus simple si tout était écrit "en dur".

Mais pour un programmeur ce ne serait pas même soutenable de voir un tel étalement d'informations non organisées.