Les aventures de Mokona au pays des chonchons

Avant-hier, je lisais un vieux livre sur l'art et la manière d'utiliser son Commodore 64. « Utiliser », à l'époque des ordinateurs familiaux, cela incluait pratiquement tout le temps la programmation en Basic. Arrivé à cette partie, je tombe sur un passage qui me fait rire, d'autant plus que, en effet, je me souviens tout à coup que cela fonctionnait comme ça.

Alors, attention, si vous n'êtes pas informaticien, si vous n'avez jamais fait de Basic à l'époque des ordinateurs familiaux, je vous préviens, le rire ne vient pas facilement.

Le passage indique que lorsque l'on utilise pour la première fois un tableau, on peut se passer d'un DIM (allocation du tableau) si l'indice est inférieur ou égal à 10. Dans ce cas, un DIM de taille 10 est implicitement fait, entraînant par là la création d'un tableau de onze cellules.

Du coup, hier, j'ai fait une petite recherche dans d'autres vieux livres. Effectivement, sur Oric, Amstrad CPC, Basic Omikron (je n'ai pas retrouvé pour le GFA Basic), on retrouve cette même règles. Cela n'est pas précisé dans le livre sur le ZX Spectrum que j'avais sous la main. Une petite recherche (entre autre sur Wikipedia, où j'ai découvert un OVNI) ne m'a pas permi de savoir si ce comportement était une norme ou juste une convention de l'époque. Les Basic actuels (comme Pure Basic, Dark Basic) ne me semblent pas fonctionner comme cela, mais je ne suis pas non plus un spécialiste.

Pourquoi ce rire ? Il y a deux choses qui chiffonnent dans cette allocation automatique.

Tout d'abord, pourquoi ce cas particulier ? Peut-être parce qu'on parle ici du Basic, le langage que tout le monde pouvait apprendre, que les variables n'avaient pas besoin d'y être définies mais que néanmoins, dans le cas d'un tableau, il est plus facile de fixer une taille d'un point de vue implémentation (à l'époque, le REDIM, permettant de redimensionner un tableau sans destruction des données des cellules qui restent est un luxe). Un mélange de contraintes techniques et d'offre de facilité donc.

Ensuite, pourquoi 11 ? Pourquoi pas 8, qui est naturellement plus informaticien, ou 42 (The Hitchhiker's Guide to the Galaxy date de 1979, mais ici, la réponse est évidente, 42, c'est trop gros). Je suppose que 11 parceque 10. DIM A(10) créé sur la plupars des BASIC un tableau de taille 11, car l'argument passé n'est pas la taille du tableau, mais le plus grand index utilisable, les index commençant à zéro. Ça encore, c'est un point qui m'a fait rire, surtout en me souvenant que ces histoires d'index me posaient de réels soucis à l'époque.

Cela devait choquer d'autres personnes d'ailleurs car j'ai relevé dans ma recherche d'hier que certains Basic indexaient à partir de 1 jusqu'à l'indice passé, que d'autres demandaient de préciser les bornes inférieures et supérieures, et que d'autres indexaient de zéro à l'index maximum moins un.

Je n'ai donc pas d'autre explication, mais je suis preneur ; taille 11 car DIM A(10) et que 10 est un chiffre rond (pas pour un informaticien, mais c'est une autre histoire).

Plus de vingt ans après, ce manque de rigueur me fait rire. Mais cela me rappelle aussi que cette attitude (utilisation d'un nombre arbitraire, comportement automatique ou pas suivant l'utilisation) n'a pas disparu des habitudes de certains programmeurs.

C'est à cette époque de l'année que, les beaux jours revenant, les salons se remettent à fleurir. Ces deux dernière semaines, j'ai choisi d'aller voir du côté du dinosauresque Salon International de la Maquette [1] et de la GenCon nouvelle venue en France.

Le salon de la maquette, c'est une habitude, j'y vais depuis longtemps. Mais cette année, j'ai été pris d'un doute : salon toujours plus cher que les autres (ceux auxquels je me rends en tout cas) et contenu à peu près toujours identique. Je ne dis pas que je ne m'y suis pas amusé. mais je n'y suis pas resté longtemps non plus. J'ai même eu l'impression qu'il était plus petit que d'habitude. Le regroupement des aires pour voiture et avion ainsi que l'absence des trains à vapeur sur lesquels ont peu monter est peut être ce qui donnait cette impression. Irai-je l'année prochaine ? Pour le moment, j'en doute. Mais je ne jure de rien.

La GenCon est un nouveau venu, dans un espace que je ne connaissais pas. C'est en fait un salon américain dont le nom ne m'était pas inconnu. Après quelques hésitation, nous y voilà parti en couple. Bonheur ! Voilà un salon de jeux avec des jeux et des joueurs ! L'espace majoritairement utilisé pour les tables de jeux, des présentations de jeux, des jeux libres sur des nouveautés, des classiques ou des vénérables. Des vigiles avec le sourire, une buvette aux prix acceptables et des points d'eau ne font qu'ajouter à la qualité induite par l'ambiance qui y règne.

Après le très décevant Monde du Jeu de l'automne dernier, voici un salon qui montre qu'il a compris quelque chose de très important : les joueurs aiment jouer ! Pourvu que ce nouveau salon garde cet esprit.

[1] C'est moi qui n'ai pas de mémoire, ou bien il s'appelait le Mondial de la Maquette et du Modèle Réduit l'année dernière ?

Google a sorti un nouvel outil, encore un beta : un calendrier . Et encore une fois, c'est bien réalisé, c'est pratique, ça peut être collaboratif, ça peut se partager ou être secret, ça s'exporte suivant les normes actuelles. Bref, c'est du bon.

Oui mais il y a un hic : je n'ai pas envie de mettre mes rendez-vous chez Google. Google a déjà une (toute petite) partie de mes mails avec GMail, peut enregistrer mes conversations avec GTalk, me connait à travers mes recherches sur le web. Que fait Google de toute cela ? Pour le moment, m'envoyer quelques publicités ciblées bien moins intrusives que tout ce qui m'agresse sur le chemin du boulot le matin et de chez moi le soir. Mais rien ne garanti que cela restera comme ça.

On envoie déjà beaucoup de données personelles sur Internet, probablement plus que la plupart des utilisateurs le pense. Mais mettre sur un serveur d'une compagnie privée son calendrier de rendez-vous me semble une étape dangereuse.

Ce n'est pas comme ça que je vois le réseau idéal. Dans le réseau idéal, je conserve sur moi, ou chez moi, sur mon ordinateur personnel, mon PDA, mon téléphone ou n'importe quel appareil destiné à garder des informations les données qui me sont personnelles. L'appareil se connecte alors au réseau pour mettre à jour ou diffuser les informations.

La différence est de taille. Dans le cas du calendrier, si j'utilise Google, toutes les informations sont sur leurs serveurs, même si je le configure pour qu'il soit complètement privé. Sur le réseau idéal, mon calendrier est avec moi et je décide de la publicité des informations que je choisi. Ce que je décide non public n'est pas atteignable.

Ce réseau idéal, décentralisé et crypté [1] nécessite plusieurs choses. Un accès facile et mobile, ce vers quoi nous tendons avec les trop chers téléphones mobiles et l'arrivée prométeuse du wimax. Des appareils associés : les PDAs, Tablet PC ou simplement PC portables. Mais surtout une conscience de l'utilisateur qu'Internet lui offre un modèle nouveau dans lequel il n'est pas simplement consommateur de service et d'information, mais aussi diffuseur, éditeur. C'est ce dernier point pour lequel il reste beaucoup de choses à faire. La technique, elle, est là où quasi là.

Pour revenir au calendrier de Google, il reste tout de même un très bon produit (gratuit qui plus est) et qui peut rendre des services : concentrateur de calendriers publics par exemple. Ou encore organisation des scéances publiques d'une association. Pour tout ce qui est donnée publique, l'outil devrait se révéler très pratique à l'usage.

[1] Beaucoup y ajouteraient « anonyme », je préfère : possibilité d'anonymat.