Stefan Ram
2017-05-05 14:32:12 UTC
Ich habe nun mal etwas in einem Buch mit BASIC-Listings
aus den 70er Jahren gelesen.
Zum einen fällt mir auf, daß wir doch inzwischen ein weites
Stück in bezug auf Lesbarkeit zurückgelegt haben.
In BASIC war es damals ganz normal zu schreiben:
430 K=1
440 A$(K)="Q/"+N$
450 GOSUB 3900
, und man hat keine Idee, worum es geht. Man konnte dann
sehr froh sein, wenn das Unterprogramm in Zeile 3900 mit
einem REM beginnt, das ein paar erklärende Wörter enthält.
Andererseits ist es interessant zu sehen, wie man auch schon
in BASIC alle möglichen Datenstrukturen implementieren kann.
Ein Baum besteht dann nicht aus einzelnen speziell dafür
deklarierten Strukturen, sondern ist einfach ein
100 DIM A$(200)
wobei die Allokation eines neuen (Teil-)baumes durch
»N=N+1« erfolgt (N ist das Maximum des bisher genutzten
Teils der Reihung). Statt Zeigern auf die Unterbäume findet
man dann eben in den Strings am Ende enthaltene Numeralia
mit Positionen in der Reihung A$. Statt Polymorphie zur
Realisierung des Unterschiedes zwischen Bäumen und Blättern
gibt es in den Strings eben einen Buchstaben als Typkennzeichen.
Das ist schon fast Maschinensprache, aber man hat als
große Hilfe einen Garbage Collector für Strings.
Faszinierend fand ich immer schon READ und DATA. Vielleicht,
weil es so etwas AFAIK in keiner anderen Programmiersprache gibt.
Man könnte sich einen BASIC-Dialekt vorstellen, der auch noch
»WRITE« enthält - um neue Daten oder Programmzeilen ins Programm
reinzuschreiben (was das Lesen und Verstehen ausgedruckter
Listings weiter erschweren sollte). Wenn man dann aber unter
einem System arbeitet, welches es einem erlaubt, ein Programm
abzuspeichern, kann man so einfache Formen von Datenbanken
realisieren. (Soll ich jetzt sagen: "Das ist objektorientiert:
Code und Daten als eine Einheit verschmolzen!"?)
PS: Und kein Mensch braucht mehr als 200 Daten, weswegen sich
Prüfungen der Art »IF N > 200 ...« erübrigen.
aus den 70er Jahren gelesen.
Zum einen fällt mir auf, daß wir doch inzwischen ein weites
Stück in bezug auf Lesbarkeit zurückgelegt haben.
In BASIC war es damals ganz normal zu schreiben:
430 K=1
440 A$(K)="Q/"+N$
450 GOSUB 3900
, und man hat keine Idee, worum es geht. Man konnte dann
sehr froh sein, wenn das Unterprogramm in Zeile 3900 mit
einem REM beginnt, das ein paar erklärende Wörter enthält.
Andererseits ist es interessant zu sehen, wie man auch schon
in BASIC alle möglichen Datenstrukturen implementieren kann.
Ein Baum besteht dann nicht aus einzelnen speziell dafür
deklarierten Strukturen, sondern ist einfach ein
100 DIM A$(200)
wobei die Allokation eines neuen (Teil-)baumes durch
»N=N+1« erfolgt (N ist das Maximum des bisher genutzten
Teils der Reihung). Statt Zeigern auf die Unterbäume findet
man dann eben in den Strings am Ende enthaltene Numeralia
mit Positionen in der Reihung A$. Statt Polymorphie zur
Realisierung des Unterschiedes zwischen Bäumen und Blättern
gibt es in den Strings eben einen Buchstaben als Typkennzeichen.
Das ist schon fast Maschinensprache, aber man hat als
große Hilfe einen Garbage Collector für Strings.
Faszinierend fand ich immer schon READ und DATA. Vielleicht,
weil es so etwas AFAIK in keiner anderen Programmiersprache gibt.
Man könnte sich einen BASIC-Dialekt vorstellen, der auch noch
»WRITE« enthält - um neue Daten oder Programmzeilen ins Programm
reinzuschreiben (was das Lesen und Verstehen ausgedruckter
Listings weiter erschweren sollte). Wenn man dann aber unter
einem System arbeitet, welches es einem erlaubt, ein Programm
abzuspeichern, kann man so einfache Formen von Datenbanken
realisieren. (Soll ich jetzt sagen: "Das ist objektorientiert:
Code und Daten als eine Einheit verschmolzen!"?)
PS: Und kein Mensch braucht mehr als 200 Daten, weswegen sich
Prüfungen der Art »IF N > 200 ...« erübrigen.