Un peu sur ce que représentait l'informatique scolaire dans les années 90 et pourquoi tous les programmeurs étaient alors exclusivement des autodidactes.
Sur quoi on apprenait à programmer pour les enfants
Au début des années 90, les écoles de Moscou ont commencé à équiper sélectivement des classes d'ordinateurs. Les salles étaient immédiatement dotées de grilles aux fenêtres et d'une lourde porte en métal recouverte. Un enseignant d'informatique apparaissait de quelque part (il semblait être la personne la plus importante après le directeur), sa principale tâche étant de s'assurer que personne ne touche à quoi que ce soit. Rien du tout. Même pas la porte d'entrée.
Dans les classes, on pouvait le plus souvent rencontrer des systèmes BK-0010 (dans ses variations) et BK-0011M.
Photo prise
On parlait aux enfants de l'architecture générale, ainsi que d'une dizaine de commandes BASIC, pour qu'ils puissent dessiner des lignes et des cercles sur l'écran. Pour les classes élémentaires et intermédiaires, c'était probablement suffisant.
Il y avait alors des problèmes particuliers concernant la sauvegarde de ses créations (programmes). Le plus souvent, les ordinateurs étaient reliés en réseau avec des contrôleurs monocanaux dans une topologie à « bus commun » et une vitesse de transfert de 57600 bauds. En général, il n'y avait qu'un seul lecteur de disquettes, et il ne fonctionnait pas toujours bien. Parfois ça marchait, parfois ça ne marchait pas, parfois le réseau se bloquait, parfois la disquette était illisible.
À l'époque, j'emportais avec moi cette création d'une capacité de 360 Ko.
Les chances que je puisse récupérer mon programme d'une nouvelle fois étaient de 50 à 70 pour cent.
Cependant, le principal problème de toutes ces histoires avec les ordinateurs BK était les blocages infinis.
Cela pouvait se produire à tout moment, que ce soit lors de la saisie de code ou de l'exécution d'un programme. Une système bloqué signifiait que les 45 minutes passées n'avaient servi à rien, car il fallait tout recommencer, mais le temps de cours restant était déjà insuffisant.
Vers 1993, certaines écoles et lycées ont commencé à avoir de vraies classes avec des machines 286, et parfois il y avait même des « 386 ». En ce qui concerne les langages de programmation, il y avait deux options : là où BASIC se terminait, Turbo Pascal commençait.
Programmation en Turbo Pascal sur l'exemple des « tanks »
À l'époque de Pascal, les enfants apprenaient à construire des boucles, à dessiner diverses fonctions, à travailler avec des tableaux. Dans le lycée de mathématiques et de sciences où je passais un certain temps, il n'y avait qu'un cours d'informatique par semaine. Pendant deux ans, c'était vraiment ennuyeux. Bien sûr, je voulais faire quelque chose de plus sérieux que d'afficher les valeurs d'un tableau ou d'une sinusoïde.
Tank Battle
Battle City était l'un des jeux les plus populaires sur les consoles clonées de la NES (Dendy et autres).
En 1996, la popularité des consoles 8 bits était retombée, elles prenaient la poussière depuis longtemps dans les placards, et il m'a semblé amusant de créer un clone de « Tank Battle » pour PC. Voici comment il fallait alors faire preuve de créativité pour réaliser quelque chose avec des graphismes, une souris et du son en Pascal.
On peut dessiner seulement des bâtons et des cercles
Commençons par les graphismes.
Dans sa version de base, Pascal permettait de dessiner certaines figures, de remplir des zones et de définir des couleurs de points. Les procédures les plus avancées dans le module Graph, qui nous rapprochaient des sprites, étaient GetImage et PutImage. Grâce à elles, il était possible de capturer une section de l'écran dans une zone de mémoire préalablement réservée, puis d'utiliser ce morceau comme une image bitmap. En d'autres termes, si vous souhaitez réutiliser plusieurs fois des éléments ou des images à l'écran, vous les dessinez d'abord, les copiez en mémoire, effacez l'écran, dessinez le suivant, et ce jusqu'à ce que vous ayez créé la bibliothèque souhaitée en mémoire. Comme tout cela se déroule rapidement, l'utilisateur ne remarque pas ces techniques.
Le premier module où les sprites ont été utilisés était l'éditeur de cartes.
Il comportait un terrain de jeu délimité. Un clic de souris ouvrait un menu où l'on pouvait choisir l'un des quatre types d'obstacles. À propos de la souris...
La souris – c'est déjà la fin des années 90
Bien sûr, tout le monde avait des souris, mais jusqu'au milieu des années 90, on les utilisait seulement sous Windows 3.11, dans des packages graphiques et dans un petit nombre de jeux. Dans Wolf et Doom, on jouait uniquement au clavier. Et même dans l'environnement DOS, une souris n'était pas vraiment nécessaire. C'est pourquoi chez Borland, le module de gestion de la souris n'était même pas inclus dans la version standard. Il fallait le chercher par des connaissances, qui levaient les bras et s'exclamaient : « à quoi ça te sert ? ».
Cependant, trouver un module pour interroger la souris n'est que la moitié du travail. Pour que la souris puisse cliquer sur les boutons à l'écran, il fallait les dessiner. Et cela en deux variantes (enfoncée et non enfoncée). Pour le bouton non enfoncé, le dessus est clair, et en dessous se trouve l'ombre. Pour le bouton enfoncé, c'est l'inverse. Il fallait ensuite les afficher trois fois à l'écran (non enfoncé, enfoncé, puis à nouveau non enfoncé). Sans oublier de mettre des délais d'affichage et de cacher le curseur.
Par exemple, le traitement du menu principal dans le code ressemblait à ceci :
Son – seulement un buzzer PC Speaker
L'histoire du son est différente. Au début des années 90, les clones de Sound Blaster commençaient à peine leur fantastique ascension, et la plupart des applications ne fonctionnaient qu'avec le haut-parleur intégré. Le maximum de ses capacités était la reproduction simultanée d'un seul ton. Et c'est précisément ce que permettait de faire Turbo Pascal. Grâce à la procédure sound, on pouvait « bipper » avec différentes fréquences, ce qui était suffisant pour les sons de tirs et d'explosions, mais pas pour les jingles musicaux qui étaient à la mode à l'époque. Finalement, une solution astucieuse a été trouvée : dans mon propre archive de logiciels, un « petit exécutable » a été découvert, téléchargé un jour depuis un forum BBS. Il savait réaliser des merveilles – jouer des fichiers wav non compressés via le PC Speaker, et cela se faisait depuis la ligne de commande sans interface propre. Tout ce qu'il fallait faire, c'était l'appeler via la procédure exec de Pascal et veiller à ce que cette construction ne s'effondre pas.
Au final, une musique percutante est apparue à l'écran, mais quelque chose de drôle s'est produit. En 1996, j'avais un système sur Pentium 75, overclocké à 90. Tout fonctionnait à merveille. À l'université, cependant, où nous avions Pascal au deuxième semestre, dans la salle de classe se trouvaient de vieux « trios ». Par accord avec l'enseignant, j'ai emporté ces tanks à la deuxième séance pour obtenir mon crédit et ne plus avoir à y retourner. Et voilà, après le lancement, un rugissement fort est sorti du haut-parleur, mêlé à des sons gutturaux. En gros, le « trio » à 33 MHz n'a pas réussi à faire tourner ce « petit exécutable » correctement. Mais à part cela, tout allait bien. Bien sûr, à l'exception de l'interrogation de clavier lente, qui gâchait tout le gameplay, peu importe la performance du PC.
Mais le problème principal ne vient pas de Pascal.
À mon avis, «Tančiki» est le maximum qu'on pouvait tirer de Turbo Pascal sans insertions en assembleur. Parmi les défauts évidents du produit final, on trouve un sondage lent du clavier et un rendu graphique lent. La situation était aggravée par le nombre extrêmement limité de bibliothèques et de modules tiers. On pouvait les compter sur les doigts d'une main.
Mais ce qui me dérangeait le plus, c'était l'approche dans l'éducation scolaire. Personne ne parlait alors des avantages et des possibilités des autres langages. En cours, on commençait presque immédiatement à parler de begin, println et if, ce qui enfermait les élèves dans une paradigme de basic-pascal. Ces deux langages peuvent être considérés comme purement éducatifs. Leur application «réelle» est un phénomène rare.
Pourquoi enseigner aux enfants des langages fictifs – c'est un mystère pour moi. Certes, ils sont plus visuels. Certes, certaines variantes de «Basic» sont utilisées ici et là. Mais, de toute façon, si une personne envisage de lier son avenir à la programmation, elle devra apprendre d'autres langages à partir de zéro. Alors pourquoi ne pas fixer aux enfants les mêmes tâches éducatives, mais sur une plateforme (langage) normale, à partir de laquelle ils pourraient évoluer de manière autonome par la suite?
À propos des tâches. À l'école et à l'université, elles étaient toujours abstraites : calculer ceci, construire une fonction, dessiner quelque chose. J'ai étudié dans trois écoles différentes, de plus, nous avions «Pascal» au premier cours de l'université, et jamais les enseignants n'ont fixé une tâche d'application réaliste. Par exemple, créer un carnet d'adresses ou autre chose d'utile. Tout était fabriqué. Et quand une personne passe des mois à résoudre des tâches vides, qui finissent ensuite à la poubelle… En gros, les gens sortent de l'université déjà épuisés.
D'ailleurs, au troisième cours de la même université, on a introduit les «plus». Cela semblait être une bonne chose, mais les gens étaient fatigués, saturés de faux et de «tâches éducatives». Il n'y avait plus l'enthousiasme du premier coup.
P.S. J'ai cherché des informations sur les langages enseignés dans les écoles lors des cours d'informatique. Tout est comme il y a 25 ans : Basic, Pascal. Avec quelques incursions de Python.
Source : habr.com
