Ein wenig darĂŒber, wie der Informatikunterricht in den 90er Jahren war und warum damals alle Programmierer Selbstlerner waren.
Woran man Kinder das Programmieren beigebracht hat
Zu Beginn der 90er Jahre begannen die Moskauer Schulen, selektiv Computerklassen auszustatten. In den RĂ€umen wurden sofort Gitter an den Fenstern und eine schwere, mit Eisen ausgekleidete TĂŒr installiert. Irgendwoher tauchte ein Informatiklehrer auf (er sah aus wie der wichtigeste Genosse nach dem Direktor), dessen Hauptaufgabe es war, darauf zu achten, dass niemand irgendetwas berĂŒhrte. Absolut nichts. Sogar die EingangstĂŒr nicht.
In den Klassen traf man hÀufig auf die Systeme BK-0010 (in seinen Varianten) und BK-0011M.
Das Foto wurde entnommen
Den Kindern wurde das allgemeine GerĂ€t erklĂ€rt und ein Dutzend Befehle von âBasiskâ, damit sie Linien und Kreise auf dem Bildschirm zeichnen konnten. FĂŒr die unteren und mittleren Klassen war das vermutlich ausreichend.
Das Speichern der eigenen Kreationen (Programme) war damals ein eigenes Problem. Die Computer wurden hĂ€ufig mit Hilfe von Monokanalcontrollern zu einem Netzwerk mit der Topologie âgemeinsame Busâ und einer Ăbertragungsgeschwindigkeit von 57600 Baud verbunden. Normalerweise gab es nur ein Laufwerk, und oft funktionierte es nicht richtig. Mal ging es, mal ging es nicht, mal hing das Netzwerk, mal wurde die Diskette nicht gelesen.
Ich hatte damals dieses Werk mit einer KapazitÀt von 360 KB dabei.
Die Chancen, dass ich erneut mein Programm von dort abziehen konnte, lagen bei etwa 50-70 Prozent.
Das gröĂte Problem dieser ganzen Geschichten mit den âBKâ-Computern waren die endlosen AbstĂŒrze.
Das konnte jederzeit passieren, egal ob beim Eintippen von Code oder beim AusfĂŒhren eines Programms. Ein abgestĂŒrztes System bedeutete, dass du 45 Minuten Zeit verschwendet hattest, weil du alles von vorne machen musstest, aber die verbleibende Zeit des Unterrichts dafĂŒr schon nicht mehr ausreichte.
Gegen 1993 tauchten in einzelnen Schulen und Lyzeen normale Klassen mit 286-Maschinen auf, und an manchen Orten standen sogar âDreiĂ€ugigeâ. Was die Programmiersprachen angeht, gab es zwei Optionen: dort, wo âBasiskâ endete, begann âTurbo Pascalâ.
Programmieren in âTurbo Pascalâ am Beispiel von âPanzer-Spielenâ
In Pascal lernten Kinder, Schleifen zu erstellen, verschiedene Funktionen zu zeichnen und mit Arrays zu arbeiten. Am Physik-Mathematik-Gymnasium, wo ich eine Zeit lang âlebteâ, wurde der Informatik nur eine Stunde pro Woche gewidmet. Und zwei Jahre lang war das hier eine regelrechte Langeweile. NatĂŒrlich wollte ich etwas Seriöseres machen als nur die Werte eines Arrays oder eine Sinuskurve auf dem Bildschirm auszugeben.
Tankspiele
Battle City war eines der beliebtesten Spiele auf NES-Klonen (Dendy u.a.).
1996 war die PopularitĂ€t der 8-Bit-Konsolen vorbei, sie verstaubten schon lange in den SchrĂ€nken, und ich fand es cool, als etwas GroĂes einen Klon von âTankspielenâ fĂŒr den PC zu machen. Weiter unten geht es genau darum, wie man damals Tricks anwenden musste, um in Pascal etwas mit Grafik, Maus und Ton zu programmieren.
Man kann nur Striche und Kreise zeichnen
Lass uns mit der Grafik beginnen.
In der Grundversion erlaubte Pascal das Zeichnen bestimmter Figuren, das Ausmalen und das Bestimmen von Farben von Punkten. Die fortschrittlichsten Prozeduren im Graph-Modul, die uns den Sprites nĂ€her brachten, sind GetImage und PutImage. Mit ihnen konnte man einen Bereich des Bildschirms in einem zuvor reservierten Speicherbereich erfassen und dann dieses StĂŒck als Rasterbild verwenden. Mit anderen Worten, wenn Sie bestimmte Elemente oder Bilder mehrfach auf dem Bildschirm verwenden möchten, zeichnen Sie sie zuerst, kopieren sie in den Speicher, löschen den Bildschirm, zeichnen das nĂ€chste und so weiter, bis Sie die benötigte Bibliothek im Speicher erstellt haben. Da alles schnell geschieht, bemerkt der Benutzer diese Tricks nicht.
Das erste Modul, in dem Sprites verwendet wurden â der Karteneditor.
Es gab ein markiertes Spielfeld. Ein Mausklick öffnete ein MenĂŒ, in dem man eine von vier Arten von Hindernissen auswĂ€hlen konnte. Apropos Maus...
Die Maus â das war schon Ende der 90er Jahre
MĂ€use hatten natĂŒrlich alle, aber bis zur Mitte der 90er Jahre wurden sie nur in Windows 3.11, grafischen Paketen und wenigen Spielen verwendet. In Wolf und Doom spielte man nur mit der Tastatur. Und in der DOS-Umgebung war die Maus nicht wirklich notwendig. Daher wurde das Modul fĂŒr die Maus in der Standardinstallation von Borland nicht einmal enthalten. Man musste es bei Bekannten suchen, die mit den Schultern zuckten und erstaunt fragten: âWozu brauchst du das?â
Die Suche nach einem Modul fĂŒr die Umfrage mit der Maus ist jedoch nur die halbe Miete. Damit die Maus auf die SchaltflĂ€chen auf dem Bildschirm klicken kann, mĂŒssen diese gezeichnet werden. Und zwar in zwei Varianten (gedrĂŒckt und nicht gedrĂŒckt). Bei der nicht gedrĂŒckten SchaltflĂ€che ist die Oberseite hell, und darunter gibt es einen Schatten. Bei der gedrĂŒckten ist es umgekehrt. Und man muss sie dann dreimal auf dem Bildschirm darstellen (nicht gedrĂŒckt, gedrĂŒckt, dann wieder nicht gedrĂŒckt). AuĂerdem darf man die Verzögerungen fĂŒr die Anzeige nicht vergessen und muss den Mauszeiger verstecken.
Beispielsweise sah die Verarbeitung des HauptmenĂŒs im Code so aus:
Ton â nur der PC-Lautsprecher
Eine eigene Geschichte ist der Ton. Zu Beginn der neunziger Jahre bereiteten sich die Sound-Blaster-Klone gerade auf ihren triumphalen Siegeszug vor, und die meisten Anwendungen arbeiteten nur mit dem eingebauten Lautsprecher. Das Maximum seiner Möglichkeiten ist die gleichzeitige Wiedergabe nur eines Tones. Genau das ermöglichte Turbo Pascal. Ăber die Prozedur sound konnte man mit verschiedenen Frequenzen "pfeifen", was fĂŒr die GerĂ€usche von SchĂŒssen und Explosionen ausreichend war, aber fĂŒr eine musikalische Einlage, die damals in Mode war, war das nicht geeignet. Am Ende fand sich eine ziemlich clevere Lösung: In meinem Software-Archiv entdeckte ich ein "Exekutivprogramm", das irgendwann von einer BBS heruntergeladen wurde. Es konnte Wunder wirken - unkomprimierte wav-Dateien ĂŒber den PC-Speaker wiedergeben, und das sogar von der Kommandozeile aus, ohne eine eigene BenutzeroberflĂ€che zu haben. Alles, was nötig war, war, es ĂŒber die Pascal-Prozedur exec aufzurufen und sicherzustellen, dass diese Konstruktion nicht abstĂŒrzt.
Am Ende gab es einen beeindruckenden Soundtrack im Intro, aber damit kam eine amĂŒsante Sache heraus. 1996 hatte ich ein System mit einem Pentium 75, der auf 90 ĂŒbertaktet war. Darauf funktionierte alles einwandfrei. In der UniversitĂ€t jedoch, wo wir im zweiten Semester Pascal hatten, standen im Unterrichtsraum alte "Dreier". Nach Vereinbarung mit dem Dozenten brachte ich zu der zweiten Sitzung diese kleinen Panzer mit, um die Note zu bekommen und nicht mehr dorthin zu mĂŒssen. Und so kam, nachdem ich sie gestartet hatte, ein lautes BrĂŒllen aus dem Lautsprecher, gemischt mit hustenartigen GerĂ€uschen heraus. Kurz gesagt, der 33-MHz "Dreier" konnte es nicht schaffen, dieses "Exekutivprogramm" normal auszufĂŒhren. Aber ansonsten lief alles gut. NatĂŒrlich abgesehen von der trĂ€ge umgesetzten Tasteneingaben, die das gesamte Gameplay unabhĂ€ngig von der PC-Leistung ruinierte.
Aber das Hauptproblem liegt nicht bei "Pascal".
Meiner Meinung nach ist "Tanks" das Maximum, was man aus Turbo Pascal ohne Assembly-EinfĂŒgungen herausholen konnte. Zu den offensichtlichsten Nachteilen des Endprodukts gehören die langsame Abfrage der Tastatur und die langsame grafische Darstellung. Die Situation wurde durch die extrem geringe Anzahl an externen Bibliotheken und Modulen verschĂ€rft. Diese lieĂen sich an einer Hand abzĂ€hlen.
Aber was mich am meisten frustrierte, war der Ansatz in der schulischen Ausbildung. Kindern wurde damals niemand die Vorteile und Möglichkeiten anderer Sprachen erklĂ€rt. Im Unterricht ging es praktisch sofort um begin, println und if, was die SchĂŒler in der Basic-Pascal-Paradigmen einsperrte. Beide Sprachen können ausschlieĂlich als Lehrsprachen betrachtet werden. Ihre "eigenstĂ€ndige" Anwendung ist ein seltenes PhĂ€nomen.
Warum man Kindern gefĂ€lschte Sprachen beibringen sollte, bleibt fĂŒr mich ein RĂ€tsel. Sicher, sie sind anschaulicher. Sicher, Variationen von "Basic" werden hier und da verwendet. Aber in jedem Fall, wenn eine Person beschlieĂt, ihre Zukunft mit Programmierung zu verbinden, muss sie andere Sprachen von Grund auf lernen. Warum also nicht denselben pĂ€dagogischen Ansatz wĂ€hlen, aber auf einer normalen Plattform (Sprache), in deren Rahmen sie sich weiterentwickeln können?
Apropos Aufgaben. In der Schule und an der UniversitĂ€t waren sie immer abstrakt: ZĂ€hle das, baue eine Funktion, zeichne etwas. Ich besuchte drei verschiedene Schulen, plus wir hatten "Pascal" im ersten Studienjahr, und kein einziges Mal stellten die Lehrer eine einigermaĂen realistische praktische Aufgabe. Zum Beispiel ein Notizbuch erstellen oder etwas NĂŒtzliches. Alles war erfunden. Und wenn jemand monatelang leere Aufgaben löst, die dann in den MĂŒll wandern... Insgesamt verlassen die Leute die UniversitĂ€t bereits ausgebrannt.
Ăbrigens, im dritten Jahr an derselben UniversitĂ€t wurde uns "C++" ins Programm gesetzt. Es schien eine gute Sache zu sein, aber die Leute waren mĂŒde, hatten genug von FĂ€lschungen und "Lehraufgaben". Der Enthusiasmus, wie beim ersten Mal, war bei niemandem zu sehen.
P.S. Ich habe gegoogelt, welche Sprachen derzeit in den Schulen im Informatikunterricht unterrichtet werden. Alles wie vor 25 Jahren: Basic, Pascal. Einzelne Einsprengsel von Python erscheinen hier und da.
Quelle: habr.com
