Ein wenig ĂŒber das, was der Schulunterricht in 'Informatik' in den 90ern war, und warum alle Programmierer damals Selbstlerner waren.
Womit Kindern das Programmieren beigebracht wurde
Zu Beginn der 90er Jahre begannen die Moskauer Schulen, ausgewĂ€hlt Computerklassen auszurĂŒsten. In diesen RĂ€umen wurden sofort Gitter an den Fenstern und massive, mit Eisen beschlagene TĂŒren installiert. Irgendwoher tauchte ein Informatiklehrer auf (er sah aus wie der wichtigste Mensch nach dem Direktor), dessen Hauptaufgabe es war, darauf zu achten, dass niemand etwas anfasste. Wirklich nichts. Sogar die EingangstĂŒr nicht.
In den Klassen traf man am hÀufigsten auf die Systeme BK-0010 (in seinen Varianten) und BK-0011M.
Foto entnommen
Den Kindern wurde das allgemeine GerĂ€t erklĂ€rt, sowie ein Dutzend Befehle aus 'BASIC', damit sie Linien und Kreise auf dem Bildschirm zeichnen konnten. FĂŒr die unteren und mittleren Klassen war das wahrscheinlich ausreichend.
Bei der Bewahrung ihrer Programme gab es damals separate Probleme. HĂ€ufig wurden Computer durch Monocontroller in einem "Shared Bus"-Netzwerk mit einer Ăbertragungsrate von 57600 Baud verbunden. In der Regel gab es nur ein Diskettenlaufwerk, das oft Schwierigkeiten bereitete. Mal funktionierte es, mal nicht, die Netzwerkverbindung hing, oder die Diskette wurde nicht gelesen.
Damals hatte ich dieses 360 kB groĂe GerĂ€t immer dabei.
Die Chancen, dass ich erneut mein Programm von dort abrufen konnte, lagen bei etwa 50-70 %.
Jedoch war das Hauptproblem bei all diesen Geschichten mit den "BK"-Computern die endlosen SystemabstĂŒrze.
Das konnte jederzeit passieren, sei es beim Codieren oder bei der AusfĂŒhrung eines Programms. Ein gefrorenes System bedeutete, dass die 45 Minuten, die man investiert hatte, umsonst waren, da man alles von vorne beginnen musste, und die verbleibende Zeit fĂŒr die Lektion dafĂŒr bereits nicht mehr ausreichte.
Gegen 1993 begannen in einzelnen Schulen und Gymnasien normale Klassen mit 286-Rechnern zu erscheinen, und an manchen Orten standen sogar "386er"-Maschinen. Im Bereich der Programmiersprachen gab es zwei Optionen: Dort, wo "BASIC" endete, begann "Turbo Pascal".
Programmierung in âTurbo Pascalâ am Beispiel von âTankspielenâ
In âPascalâ lernten die Kinder, Schleifen zu erstellen, verschiedene Funktionen zu zeichnen und mit Arrays zu arbeiten. An dem Mathematik- und Naturwissenschaftslyzeum, wo ich eine Zeit lang war, gab es nur eine Stunde Informatik pro Woche. Zwei Jahre lang war das eine ziemliche langweilige Zeit. NatĂŒrlich wollte ich etwas Seriöseres machen als nur Werte aus einem Array oder eine Sinusfunktion auf dem Bildschirm auszugeben.
Tankspiele
Battle City war eines der beliebtesten Spiele auf NES-Klonkonsolen (wie Dendy usw.).
Im Jahr 1996 war die PopularitĂ€t der 8-Bit-Konsolen vorbei, sie lagen seit Langem verstaubt im Schrank, und ich fand es spannend, etwas GroĂes zu machen, nĂ€mlich einen Klon von âTankspielenâ fĂŒr den PC. Im Folgenden erklĂ€re ich, wie man damals kreativ werden musste, um in âPascalâ etwas mit Grafik, Maus und Ton zu entwickeln.
Zeichnen kann man nur mit Linien und Kreisen
Beginnen wir mit der Grafik.
Im Basisversion "Pascal" konnten einige Figuren gezeichnet, gefĂŒllt und Punktfarben festgelegt werden. Die fortschrittlichsten Verfahren im Graph-Modul, die uns den Sprites nĂ€her bringen, sind GetImage und PutImage. Mit deren Hilfe konnte ein Bereich des Bildschirms in einen zuvor reservierten Speicherbereich erfasst und anschlieĂend als Rasterbild verwendet werden. Mit anderen Worten, wenn Sie bestimmte Elemente oder Bilder mehrfach auf dem Bildschirm verwenden möchten, zeichnen Sie sie zunĂ€chst, kopieren sie in den Speicher, löschen den Bildschirm, zeichnen das NĂ€chste und so weiter, bis Sie die gewĂŒnschte Bibliothek im Speicher erstellt haben. Da alles schnell geschieht, bemerkt der Nutzer diese Tricks nicht.
Das erste Modul, in dem Sprites verwendet wurden, war der Karteneditor.
Es gab ein markiertes Spielfeld. Ein Mausklick öffnete ein MenĂŒ, in dem man eine der vier Varianten von Hindernissen auswĂ€hlen konnte. Ăbrigens zur MausâŠ
Die Maus war bereits Ende der 90er Jahre.
Jedermann hatte natĂŒrlich eine Maus, aber bis Mitte der 90er Jahre wurde sie hauptsĂ€chlich nur unter Windows 3.11, in Grafikpaketen und einigen wenigen Spielen verwendet. In Wolf und Doom kĂ€mpfte man ausschlieĂlich mit der Tastatur. In der DOS-Umgebung war eine Maus auch nicht besonders nötig. Daher wurde das Modul zur Mausbearbeitung bei Borland nicht einmal standardmĂ€Ăig mitgeliefert. Man musste es suchen und die Bekannten fragten dann oft: âWozu brauchst du das?â
Ein Modul zur Abfrage der Maus zu finden, ist jedoch nur die halbe Miete. Um mit der Maus auf den SchaltflĂ€chen auf dem Bildschirm zu klicken, mussten diese gezeichnet werden. Und zwar in zwei Varianten (gedrĂŒckt und nicht gedrĂŒckt). Bei einer nicht gedrĂŒckten Taste ist die Oberseite hell und darunter befindet sich ein Schatten. Umgekehrt bei der gedrĂŒckten Taste. AuĂerdem musste man sie dann dreimal auf dem Bildschirm zeichnen (nicht gedrĂŒckt, gedrĂŒckt, dann wieder nicht gedrĂŒckt). Plus nicht vergessen, Verzögerungen bei der Anzeige einzufĂŒhren und den Mauszeiger zu verbergen.
Die Verarbeitung des HauptmenĂŒs sah im Code so aus:
Der Ton â nur ein PC-Lautsprecher-Piepton
Eine eigene Geschichte war der Sound. Anfang der neunziger Jahre standen die Klone von Sound Blaster kurz vor ihrem Durchbruch, und die meisten Anwendungen arbeiteten nur mit dem eingebauten Lautsprecher. Seine maximalen Möglichkeiten beschrĂ€nkten sich auf die gleichzeitige Wiedergabe eines einzigen Tons. Genau das ermöglichte Turbo Pascal. Ăber die Prozedur "sound" konnte man Töne in verschiedenen Frequenzen erzeugen, was fĂŒr Schuss- und ExplosionsgerĂ€usche ausreichend war, aber fĂŒr das damals beliebte Musik-Intro nicht geeignet war. Am Ende fand sich eine ziemlich clevere Lösung: In unserem Software-Archiv entdeckten wir ein kleines "Executable", das einst von einem BBS heruntergeladen worden war. Es konnte Wunder wirken â unkomprimierte WAV-Dateien ĂŒber den PC-Lautsprecher wiedergeben, und das alles aus der Kommandozeile ohne eine eigene BenutzeroberflĂ€che. Alles, was man tun musste, war, es ĂŒber die Pascal-Prozedur "exec" aufzurufen und darauf zu achten, dass diese Konstruktion nicht zusammenbrach.
Am Ende erschien der geniale Soundtrack im Intro, doch dann gab es eine lustige Sache. 1996 hatte ich ein System mit einem Pentium 75, der auf 90 ĂŒbertaktet war. Darauf lief alles wunderbar. An der Hochschule, wo wir im zweiten Semester Pascal hatten, standen jedoch alte âDreierâ im Unterrichtsraum. Nach Absprache mit dem Dozenten brachte ich zu unserer zweiten Stunde diese Tanks mit, um die PrĂŒfung zu bestehen und nicht mehr zu kommen. Und so, nach dem Start, ertönte aus den Lautsprechern ein lautes BrĂŒllen, vermischt mit schmatzenden, kehlig klingenden GerĂ€uschen. Kurz gesagt, der 33-MHz âDreierâ konnte dieses bestimmte âExecutableâ einfach nicht richtig abspielen. Aber sonst war alles in Ordnung. NatĂŒrlich abgesehen von der verzögerten Tasteneingabe, die das gesamte Gameplay beeintrĂ€chtigte, unabhĂ€ngig von der Leistung des PCs.
Doch das Hauptproblem liegt nicht im âPascalâ.
In meiner Sichtweise sind "Tanks" das Maximum, was man aus Turbo Pascal ohne Assembler-EinfĂŒgungen herausholen konnte. Zu den offensichtlichen MĂ€ngeln des Endprodukts gehören die langsame Tastatureingabe und die langsame Grafikdarstellung. Die Situation wurde zudem durch die extrem geringe Anzahl an externen Bibliotheken und Modulen verschĂ€rft. Man konnte sie an einer Hand abzĂ€hlen.
Am meisten frustrierte mich jedoch der Ansatz in der schulischen Bildung. Den Kindern wurde damals niemand die Vorteile und Möglichkeiten anderer Sprachen erklĂ€rt. Im Unterricht begann man praktisch sofort mit Begriffen wie begin, println und if, was die SchĂŒler in der Basic-Pascal-Paradigmen gefangen hielt. Beide diese Sprachen können als rein lehrmĂ€Ăig betrachtet werden. Ihre "operative" Anwendung ist eine seltene Ausnahme.
Warum es wichtig ist, Kinder mit fiktiven Programmiersprachen zu lehren, bleibt mir ein RĂ€tsel. Sicher, sie sind anschaulicher. Zwar werden einige Varianten von "Basic" hier und da verwendet. Dennoch, wenn jemand darĂŒber nachdenkt, seine Zukunft im Programmieren zu sehen, wird er gezwungen sein, im Grunde genommen andere Sprachen von Grund auf zu lernen. Warum also nicht die gleichen Lernaufgaben fĂŒr Kinder formulieren, jedoch auf einer richtigen Plattform (Sprache), auf der sie sich eigenstĂ€ndig weiterentwickeln können?
Apropos Aufgaben. In der Schule und im Studium waren sie stets abstrakt: berechne das, schreibe eine Funktion, zeichne etwas. Ich habe in drei verschiedenen Schulen gelernt, und wĂ€hrend des ersten Studienjahres hatten wir "Pascal", aber nie stellten die Dozenten eine realitĂ€tsnahe, praktische Aufgabe. Zum Beispiel ein Notizbuch zu erstellen oder etwas NĂŒtzliches. Alles war erfunden. Und wenn jemand monatelang leere Aufgaben löst, die dann vergessen werden⊠Kurz gesagt, die Leute kommen ausgebrannt aus der UniversitĂ€t.
Ăbrigens wurde uns im dritten Jahr an derselben Hochschule Programmierung mit 'Plusplus' beigebracht. Es schien eine gute Sache zu sein, aber die Leute waren mĂŒde und ĂŒbersĂ€ttigt von Fake-Inhalten und 'Lern'-Aufgaben. Die Begeisterung wie beim ersten Mal war bei niemandem zu beobachten.
P.S. Ich habe gegoogelt, welche Programmiersprachen momentan im Informatikunterricht an Schulen gelehrt werden. Alles wie vor 25 Jahren: Basic, Pascal. Ein paar vereinzelte Ausnahmen sind Python.
Quelle: habr.com
