UCSD Pascal

[F. W.]

Hallo,

kennt jemand noch UCSD-Pascal?

UCSD steht bekanntlich für "University of California, San Diego". Diese
Uni hat eine Idee des Pascal-Vaters Prof. Dr. Niklaus Wirth
aufgegriffen, eine portable Maschine (damals eine CPU-Simulation namens
"P-Machine") zu bauen und so Pascal (beispielsweise) auf sehr viele
Computer transferieren zu können.

Wir wir sicher noch alle wissen, war der Computermarkt damals in der
Vor-PC-Zeit ein Wirrwarr aus Hunderten von Maschinen mit jeweils eigener
Systemsoftware. Lange vor Konzepten wie MSX bemühte sich Wirth um
Kompatibilität, auch wenn er die Homecomputer sicher nicht so auf dem
Schirm hatte.

UCSD-Pascal wurde 1979 von Steve Jobs aufgegriffen und für den Apple II
angeboten ("Apple Pascal"). Mit zwei Diskettenlaufwerken,
80-Zeichen-Karte und 48 k RAM lief das System auch recht flüssig.

Weshalb ich mich heute manchmal frage, warum mein 16 GB RAM-System so
langsam ist, aber das ein ein anderes Thema.

UCSD-Pascal war ein tolles Lernsystem. Ich habe es als schwierig, aber
leistungsfähig in Erinnerung. Hatte man das Konzept erstmal verstanden,
gab es prima Unterstützung beim Lernen von Pascal. Ein Compilerfehler
wurde beispielsweise im Editor an der richtigen Stelle angezeigt.

Das mag heute albern klingen, aber damals hatten nicht mal
Basic-Interpreter klare Fehlermeldungen. UCSD war da seiner Zeit voraus.

UCSD konnte aber keine eigenständigen Programme erstellen. Es gab also
keine Möglichkeit, in UCSD-Pascal erstelltes und kompiliertes Programm
auf einer Diskette zu verteilen. Das lag vor allem an der zitierten
P-Machine, die ja immer dabei sein musste.

Da war Oregon-Pascal auf dem C64 weiter ;-)

Nun ja, ich schwelge manchmal in Erinnerung. Wer UCSD-Pascal mal
ausprobieren möchte, dem empfehle ich das hier

https://www.scullinsteel.com/apple2/#pascal1|pascal2

Aus heutiger Sicht wirkt das System alt. Aber damals war es für uns
Pascal-Freaks di ganze Welt.

FW

[Andreas Bockelmann]

F. W. schrieb:

> UCSD-Pascal war ein tolles Lernsystem. Ich habe es als schwierig, aber
> leistungsfähig in Erinnerung. Hatte man das Konzept erstmal verstanden,
> gab es prima Unterstützung beim Lernen von Pascal. Ein Compilerfehler
> wurde beispielsweise im Editor an der richtigen Stelle angezeigt.

Ja, UCSD (genauer Apple) Pascal war die erste Entwicklungsumgebung, die ich
kennengelernt habe.

> Das mag heute albern klingen, aber damals hatten nicht mal
> Basic-Interpreter klare Fehlermeldungen. UCSD war da seiner Zeit voraus.
>
> UCSD konnte aber keine eigenständigen Programme erstellen. Es gab also
> keine Möglichkeit, in UCSD-Pascal erstelltes und kompiliertes Programm
> auf einer Diskette zu verteilen. Das lag vor allem an der zitierten
> P-Machine, die ja immer dabei sein musste.

Es ging schon. Man konnte auf einer Diskette eine Runtimeumgebung mitgeben,
die das Programm automatisch beim Booten startete. Aber ja, mit Apple-DOS
hatte das nichts mehr zu tun, es war ein eigenes Betriebssystem für den
Apple][, oder (der war mir lieber) Basis 108. Eine UCSD-Version für den C64
gab es zwar, habe ich aber nie besessen.

Schön war es auch, dass man bei UCSD Pascal mitten im Quelltext mit
Assembler arbeiten konnte. Das war dann zwar nicht mehr unbedingt auf andere
Maschinen portierbar, aber sobald spezielle Librabries eingebunden waren
(z.B. Turtlegraphics) war damit ohnehin Feierabend.

> Aus heutiger Sicht wirkt das System alt. Aber damals war es für uns
> Pascal-Freaks di ganze Welt.

1+

--
Mit freundlichen Grüßen
Andreas Bockelmann

[Arno Welzel]

F. W.:

[...]

> UCSD konnte aber keine eigenständigen Programme erstellen. Es gab also
> keine Möglichkeit, in UCSD-Pascal erstelltes und kompiliertes Programm
> auf einer Diskette zu verteilen. Das lag vor allem an der zitierten
> P-Machine, die ja immer dabei sein musste.

Und heute sind es halt mannigfaltige Bibliotheken, die in der
Laufzeitumgebung benötigt werden.

Aber UCSD war in der ein Vorreiter für Bytecode, wie er z.B. in Java
genutzt wird. Mittlerweile wird aber auch JavaScript und PHP vor der
Ausführung in einen Zwischencode übersetzt, der dann von der
Laufzeitumgebung ausgeführt wird. PHP hat auch einen eigenen Cache
dafür, damit neue Scripte nur einmal geladen werden müssen und danach
nur noch in binärer Form ohne erneute Interpretation laufen kännen.


--
Arno Welzel
https://arnowelzel.de

[F. W.]

Am 16.05.2022 um 11:12 schrieb Arno Welzel:

[allerlei schlaues]

Insofern könnte die P-Machine die Ur-Oma der JVM sein.

:-D

FW

[F. W.]

Am 16.05.2022 um 10:25 schrieb Andreas Bockelmann:

> Ja, UCSD (genauer Apple) Pascal war die erste Entwicklungsumgebung,
> die ich kennengelernt habe.

Hast Du meinen Link mal aufgerufen? Finde ich knusper, dass ich mal
wieder UCSD starten konnte.

> Es ging schon. Man konnte auf einer Diskette eine Runtimeumgebung
> mitgeben, die das Programm automatisch beim Booten startete.

Wie ging das denn?

FW

[Andreas Bockelmann]

F. W. schrieb:

> Am 16.05.2022 um 10:25 schrieb Andreas Bockelmann:
>
>> Ja, UCSD (genauer Apple) Pascal war die erste Entwicklungsumgebung,
>> die ich kennengelernt habe.
>
> Hast Du meinen Link mal aufgerufen? Finde ich knusper, dass ich mal
> wieder UCSD starten konnte.

Nein, habe ich nicht.

>
>> Es ging schon. Man konnte auf einer Diskette eine Runtimeumgebung
>> mitgeben, die das Programm automatisch beim Booten startete.
>
> Wie ging das denn?

Sorry, zuletzt hatte ich vor 35 Jahren damit zu tun, ich weiß es wirklich
nicht mehr.

[Josef Moellers]

On 16.05.22 09:52, F. W. wrote:
[...]
>
> FW

Ich habe sogar mal eine Hardware-Implementation davon besessen. Zwei
8"-Floppy-Laufwerke waren 'drin und, iirc, basierend auf AM2900
Bit-Slice-Prozessoren.
Den Rechner konnte man über irgendeine Konfig-Datei an den Bildschirm
anpassen (ESCape-Sequenzen für Cursor-Positionierung etc).

Das einzige, womit ich immer wieder Probleme hatte, war der Editor: Mit
ESC hat man die aktuelle Eingabe abgebrochen, alles was man aktuell
eingegeben hatte war wieder weg. Wieder iirc, mußte man mit Ctrl-C die
Eingabe bestätigen. Ich hatte mich gerade auf UN*X an "vi" gewöhnt ;-)

Ich wundere mich schon seit längerem, wo dieses Teil geblieben ist :-(

Josef

[Josef Moellers]

On 16.05.22 13:30, Ralf Kiefer wrote:

> Josef Moellers wrote:
>
>> Ich habe sogar mal eine Hardware-Implementation davon besessen.
>

>> Ich wundere mich schon seit längerem, wo dieses Teil geblieben ist :-(
>

> Solch ein Maschinchen würde ich gerne lauffähig bewahren. Es gibt in
> Mitteleuropa ein paar davon, aber weit verbreitet waren sie wirklich
> nicht.

Ja, sie ist eben leider verschwunden, ich habe KEINE Ahnung wann und
wohin. Vielleicht taucht sie wieder auf, wenn ich in Rente bin (1.8.22)
und meinen Bastelkeller einmal gut aufräume, ich zweifele aber eher daran.

Josef

[Josef Moellers]

Kleiner Nachtrag: Ich hatte sie mal dem Heinz Nixdorf Museumsforum
angeboten, die haben aber dankend abgewunken, es sei denn, ich hätte
eine typische Anwendung mit der man die Maschine ausstellen könne.

[F. W.]

Am 16.05.2022 um 13:25 schrieb Ralf Kiefer:

> No comment. "Er" ist ein Grund, weswegen die Liste beinahe tot ist.
> Wer möchte denn noch öffentlich beschreiben, was er mit dem p-System
> alles macht, oder welche Software er gerettet hat?

Fraglich, warum er so etwas macht. Entweder die Rechtslage ist nicht
ganz klar oder er versteht nicht, dass er sich schnell ein dauerhaftes
Denkmal in der Computergeschichte setzen könnte.

Geld verdienen wird er damit sicher nicht mehr. Ich kann mir auch nicht
vorstellen, dass jemand die P-Machine auf modernen OS installieren würde.

FW

[F. W.]

Am 16.05.2022 um 13:06 schrieb Josef Moellers:

> Das einzige, womit ich immer wieder Probleme hatte, war der Editor:
> Mit ESC hat man die aktuelle Eingabe abgebrochen, alles was man
> aktuell eingegeben hatte war wieder weg. Wieder iirc, mußte man mit
> Ctrl-C die Eingabe bestätigen. Ich hatte mich gerade auf UN*X an
> "vi" gewöhnt ;-)

Ja, der Editor war tückisch: ESC und weg.

Der Editor selbst gibt so etwas an wie "<esc> to exit, <etx> to save".
Ich dachte immer, <etx> wäre "End of Text", also CTRL-D. Da war der Text
schon weg. :-D

FW

[Kay Martinen]

Am 16.05.22 um 09:52 schrieb F. W.:

> UCSD steht bekanntlich für "University of California, San Diego". Diese
> Uni hat eine Idee des Pascal-Vaters Prof. Dr. Niklaus Wirth
> aufgegriffen, eine portable Maschine (damals eine CPU-Simulation namens
> "P-Machine") zu bauen und so Pascal (beispielsweise) auf sehr viele
> Computer transferieren zu können.

Ich hatte ein Pascal von Markt und Technik für den C-128 das auch mit
einer P-Machine oder P-Code arbeitete.

> UCSD-Pascal wurde 1979 von Steve Jobs aufgegriffen und für den Apple II
> angeboten ("Apple Pascal"). Mit zwei Diskettenlaufwerken,
> 80-Zeichen-Karte und 48 k RAM lief das System auch recht flüssig.

Hier (ungefähr zu der zeit): CBM C-128 mit 1571, 1541, REU und zwei
Monitoren...

> Weshalb ich mich heute manchmal frage, warum mein 16 GB RAM-System so
> langsam ist, aber das ein ein anderes Thema.

Weil die heutige Software nicht nur statt einem Byte, deren gleich 4
oder mehr in die "Breite" geht sondern vermutlich auch durch etliche
Zwischenschichten: zu-nicht-näher-erklärbaren-zwecken; von der Hardware
isoliert ist. Das ist wie die Mehrwertsteuer aber in Hardware. Jeder
bekommt ein Scheibchen rechenkraft abgezwackt.

> UCSD-Pascal war ein tolles Lernsystem. Ich habe es als schwierig, aber
> leistungsfähig in Erinnerung. Hatte man das Konzept erstmal verstanden,
> gab es prima Unterstützung beim Lernen von Pascal. Ein Compilerfehler
> wurde beispielsweise im Editor an der richtigen Stelle angezeigt.

Beim M&T Pascal erinnere ich nur an die umständlichkeit nach jedem
Testlauf wieder diskette wechseln zu müssen um die IDE zu laden. Und das
bei jedem dummen Fehler den man machte. Die REU und die 2. Disk konnte
es nicht sinnvoll oder überhaupt nicht verwenden.

> UCSD konnte aber keine eigenständigen Programme erstellen. Es gab also
> keine Möglichkeit, in UCSD-Pascal erstelltes und kompiliertes Programm
> auf einer Diskette zu verteilen. Das lag vor allem an der zitierten
> P-Machine, die ja immer dabei sein musste.
>
> Da war Oregon-Pascal auf dem C64 weiter ;-)

> Aus heutiger Sicht wirkt das System alt. Aber damals war es für uns
> Pascal-Freaks di ganze Welt.

Ich bin später auf COMAL-80 für den 128'er gekommen. Das Steckmodul! Das
konnte alles. Akustisch und Optisch genau auf den Fehler hinweisen.
Viele Strukturen und mittels USE einbindbare externe Bibliotheken und
IMHO (irgendwie) auch ausführbare Programme erzeugen - was man mit
gestecktem Modul aber nicht brauchte (Interpreter).

Oder ich verwechsele letzteres mit COMAL-80 für den PC. Das konnte
allein lauffähige Executables erzeugen. Dort waren auch Zeilennummern
m.W. optional. Beim 128'er nicht. Aber man konnte ein Programm auch auf
die Floppy "LIST"en oder mit/ohne Zeilennummern zum Drucker schicken.

Am PC hab ich dazwischen aber eher mit Turbo-Pascal 5.5 und 6.0 gespielt.


Ｂｙｅ／
／Ｋａｙ

--
"Kann ein Wurstbrot die Welt retten?" :-)

[Michael van Elst]

R.Kiefe...@gmx.de (Ralf Kiefer) writes:

>Josef Moellers wrote:

>> [...] die haben aber dankend abgewunken, es sei denn, ich hätte

>> eine typische Anwendung mit der man die Maschine ausstellen könne.

>Eigentlich(!) ist es naheliegend: die gute Benutzeroberfläche des ganzen
>Betriebssystems im Jahr 1979. So was erfordert offensichtlich ein
>bißchen Abstraktionsvermögen, denn es gibt keine auffälligen optischen
>Effekte auf dem Bildschirm oder spektakuläre Töne aus dem Lautsprecher.

Zu dem Thema fällt mir nur die Pascal Microengine ein.

https://en.wikipedia.org/wiki/Pascal_MicroEngine

Die spektakulären Töne gab es von den Floppy-Laufwerken. Die
Maschine, die auf einer Messe vorgeführt wurde, hatte Laufwerke
mit elektromagnetischen Kopfladern und bei jedem Befehl, den man
eingab, klackerten die los.

[Andreas Karrer]

* Andreas Bockelmann <xot...@gmx.de>:

> F. W. schrieb:
>
>> UCSD-Pascal war ein tolles Lernsystem. Ich habe es als schwierig, aber
>> leistungsfähig in Erinnerung. Hatte man das Konzept erstmal verstanden,
>> gab es prima Unterstützung beim Lernen von Pascal. Ein Compilerfehler
>> wurde beispielsweise im Editor an der richtigen Stelle angezeigt.
>
> Ja, UCSD (genauer Apple) Pascal war die erste Entwicklungsumgebung, die ich
> kennengelernt habe.

Dito hier. Nachdem ich Pascal auf Lochkarten auf der CDC 6000 gelernt
hatte :-(

UCSD-Pascal auf dem Apple ][ hatte Units (Module) mit korrekter
Separation von Interface, Implementation und Initialisierung, ausserdem
Segment Procedures (Nachladen von Code von Disk) und Program Chaining.
Das hatten viele "grössere" Systeme nicht.

Die Idee, den Compiler Zwischencode für eine virtuelle Maschine
generieren zu lassen, der nachher von einem Interpreter abgearbeitet
wird, war aber nicht soo neu. Ob Wirth das erfunden hat, weiss ich
nicht, aber jedenfalls hat er das in seinem Spielzeug-Compiler für
"PL/0" (https://en.wikipedia.org/wiki/PL/0) so gemacht, und es war eine
typische Übungsaufgabe, dieses einfache System so zu erweitern, dass
der Zwischencode in eine Datei ausgelesen werden konnte und so das
Compilat zusammen mit dem separaten Interpreter lauffähig gemacht
wurde.

Der Mann müsste aber sicher retrospektiv dafür bestraft werden, dass
er sich nicht mit den UCSD-Leuten zusammengetan hat. Mit seinem Namen
hätte er dem UCSD-System enormen Auftrieb verleihen können, und
vielleicht hätte er Millionen damit machen können. Offenbar verdiente
er an der ETH genug, so dass er das nicht nötig hatte :-)

Gosling hat als Student einen p-Code-Interpreter geschrieben bzw.
portiert, er bezeichnet das als wesentliche Inspiration für die JVM.

> Schön war es auch, dass man bei UCSD Pascal mitten im Quelltext mit
> Assembler arbeiten konnte. Das war dann zwar nicht mehr unbedingt auf andere
> Maschinen portierbar, aber sobald spezielle Librabries eingebunden waren
> (z.B. Turtlegraphics) war damit ohnehin Feierabend.

Turtlegraphics war nett, aber sehr langsam, eigentlich bloss für
Schulungszwecke brauchbar. Man hat dann halt die öfter benötigten
Blit-Funktionen in Assembler gemacht statt mit drawblock().

- Andi

[F. W.]

Am 16.05.2022 um 21:04 schrieb Andreas Karrer:

> Die Idee, den Compiler Zwischencode für eine virtuelle Maschine
> generieren zu lassen, der nachher von einem Interpreter abgearbeitet
> wird, war aber nicht soo neu. Ob Wirth das erfunden hat, weiss ich
> nicht, aber jedenfalls hat er das in seinem Spielzeug-Compiler für
> "PL/0" (https://en.wikipedia.org/wiki/PL/0) so gemacht, und es war
> eine typische Übungsaufgabe, dieses einfache System so zu erweitern,
> dass der Zwischencode in eine Datei ausgelesen werden konnte und so
> das Compilat zusammen mit dem separaten Interpreter lauffähig
> gemacht wurde.

Ist PL/0 nicht das System, das in Wirths "Compilerbau" gebaut wird? Muss
ich mal nachlesen.

> Der Mann müsste aber sicher retrospektiv dafür bestraft werden, dass
> er sich nicht mit den UCSD-Leuten zusammengetan hat. Mit seinem Namen
> hätte er dem UCSD-System enormen Auftrieb verleihen können, und
> vielleicht hätte er Millionen damit machen können. Offenbar verdiente
> er an der ETH genug, so dass er das nicht nötig hatte :-)

Er wollte doch die Lilith bauen.

>> Schön war es auch, dass man bei UCSD Pascal mitten im Quelltext
>> mit Assembler arbeiten konnte. Das war dann zwar nicht mehr
>> unbedingt auf andere Maschinen portierbar, aber sobald spezielle
>> Librabries eingebunden waren (z.B. Turtlegraphics) war damit
>> ohnehin Feierabend.

> Turtlegraphics war nett, aber sehr langsam, eigentlich bloss für
> Schulungszwecke brauchbar. Man hat dann halt die öfter benötigten
> Blit-Funktionen in Assembler gemacht statt mit drawblock().

Ich habe damals kleinere Programme für Geschäfte in der Umgebung
geschrieben, aber tatsächlich (widerwillig) Basic-Compiler benutzt.
UCSD-Pascal war mit meinem ersten PC (Commodore) sowieso kein Thema
mehr. Ich hatte auch schnell Turbo-Pascal. Schon auf CP/M auf dem C128.

FW

[Bernd Laengerich]

Am 16.05.2022 um 09:52 schrieb F. W.:

> kennt jemand noch UCSD-Pascal?

Ich erinnere mich an Swap-Orgien auf dem Diskettenlaufwerk und der klassischen
Fehlermeldung:
"Workfile lost"

Bernd

[Josef Moellers]

Klingt bekannt ... aber meine Kiste war iirc beige und die beiden
Disketten-Laufwerke waren vorne mit dem Reset-Knopf dazwischen.

Josef

[Josef Moellers]

On 16.05.22 15:42, F. W. wrote:
> Am 16.05.2022 um 13:06 schrieb Josef Moellers:
>
>> Das einzige, womit ich immer wieder Probleme hatte, war der Editor:
>> Mit ESC hat man die aktuelle Eingabe abgebrochen, alles was man
>> aktuell eingegeben hatte war wieder weg. Wieder iirc, mußte man mit
>> Ctrl-C die Eingabe bestätigen. Ich hatte mich gerade auf UN*X an
>> "vi" gewöhnt ;-)
>
> Ja, der Editor war tückisch: ESC und weg.

Seltsamerweise mußte ich immer zweimal ESC drücken, damit die Eingabe
wirklich weg war, vermutlich weil das erste ESC ja zu einer
Escape-Sequenz (Cursor-Taste) hätte gehören können. Da blieb dann noch
eine Gelegenheit, wenigstens den Bildschirminhalt ab zu schrieben (mal
eben ein Bildschirm-Foto ging damals noch nicht wirklich gut)

Ich kann mich nicht erinnern, einmal ausprobiert zu haben, was eine
andere Taste als eine zweite ESC bewirkt hatte.

Josef

[Kay Martinen]

Am 17.05.22 um 11:13 schrieb Ralf Kiefer:

> Bernd Laengerich wrote:
>
>> Ich erinnere mich an Swap-Orgien auf dem Diskettenlaufwerk und der klassischen
>> Fehlermeldung:
>

> Klassisches Ressourcenproblem der 1980er: Geldmangel ;-) Im Ernst: mit

Ganz im Ernst. Dieses Ressourcenproblem hat nie aufgehört aktuell zu
bleiben. Es wird nur immer schlimmer.

Hier müßen irgendwo Geldstaubsauger laufen. Bitte alle mal still sein
und auf ein Heulen horchen. Die müssen doch zu finden sein [Axt bereit
haltend]. :-/


> ausreichend Massenspeicher war das nie ein Problem. In meinem Apple IIe
> entspannte sich die Situation zunächst mit dem Betrieb eines
> 640kB-Laufwerks neben dem originalen mit 140kB. Dann kam die RAM-Disk
> mit 512kB dazu, später eine mit 1MB, was den Ablauf erheblich
> beschleunigte nicht nur wg. möglicher Diskettenwechsel.

War vielleicht das gleiche Problem das ich nebenan mit dem M&T Pascal
erwähnte. Nur konnte das diesbezüglich recht wenig. Speichererweiterung
beim C-64 ist schwierig, beim 128 mit der REU einfach aber nicht
nutzbar. Und die beiden Disk-Lw. halfen mir damals auch nicht.

Mit dem COMAL-Modul lief es deutlich besser und schneller. Kein Wunder.
Das ist immer sofort DA. Man konnte übrigens mit "BYE" in das normale
Basic wechseln. Zurück kam man IMHO mit einem SYS(irgendwas?)

[Marcel Mueller]

Am 16.05.22 um 09:52 schrieb F. W.:

> UCSD-Pascal wurde 1979 von Steve Jobs aufgegriffen und für den Apple II
> angeboten ("Apple Pascal"). Mit zwei Diskettenlaufwerken,
> 80-Zeichen-Karte und 48 k RAM lief das System auch recht flüssig.
>
> Weshalb ich mich heute manchmal frage, warum mein 16 GB RAM-System so
> langsam ist, aber das ein ein anderes Thema.

Die Antwort ist einfach. Programme werden immer so geschrieben, dass sie
den Rechner des Entwicklers gerade so nicht lahm legen. Dass man sie
überhaupt benutzen kann, liegt daran, dass sie auf dem Rechner des Users
im Schnitt erst ein paar Jahre später eingesetzt werden, und dann ist
die Technik schon wieder weiter.

> UCSD-Pascal war ein tolles Lernsystem. Ich habe es als schwierig, aber
> leistungsfähig in Erinnerung. Hatte man das Konzept erstmal verstanden,
> gab es prima Unterstützung beim Lernen von Pascal. Ein Compilerfehler
> wurde beispielsweise im Editor an der richtigen Stelle angezeigt.

Ich erinnere mich nur sehr dunkel.

> Aus heutiger Sicht wirkt das System alt. Aber damals war es für uns
> Pascal-Freaks di ganze Welt.

Tatsächlich war ich nie ein besonderer Pascal-Freak. Ich fand es etwas
umständlich. Aber klar, besser als die Basics von damals war es allemal
- da war ja selbst DEC-Assembler angenehmer zu programmieren.

Mit C und ein paar Jahre später C++ konnte ich mich besser anfreunden.
Auch wenn zumindest die Borland C++ Compiler wohl zeitlebens eine eigene
Casting-Show für Compiler- und Optimizer-Bugs hatten. Aber mit IBM
Vissual Age C++ war das Thema dann durch. Der war seiner Zeit damals
weit voraus.


Marcel

[olaf]

Ralf Kiefer <R.Kiefe...@gmx.de> wrote:


>Es hieß eigentlich nur "Pascal", weil das der erste Compiler auf diesem
>System war. Tatsächlich gab's kurz danach Fortran, später Modula, und
>einen C-Compiler soll es auch gegeben habe. Wer zu C was weiß, bitte
>melden :-) Entweder war der seinerzeit Paperware, oder er ist
>verschollen.

Ich bin mir relativ sicher auch eine LISP Version dazu gehabt zu haben.
Die hab ich aber nur einmal gestartet weil hyper-krass-lahm.

Olaf

[F. W.]

Am 18.05.2022 um 00:00 schrieb Marcel Mueller:

> Mit C und ein paar Jahre später C++ konnte ich mich besser
> anfreunden.

Ich finde es schon merkwürdig, dass es so etwas wie

var strAntwort: string;

case strAntwort of

'Ja': Positiv (Arg);
'No': Negativ (Arg);

end;

in C eigentlich gar nicht gibt. Oder hat jemand eine Lösung?

FW

[Peter Heitzer]

do {
if (!strcmp(antwort,"Ja")) { ...; break; }
if (!strcmp(antwort,"No")) { ...; break; }
} while (0);

--
Dipl.-Inform(FH) Peter Heitzer, peter....@rz.uni-regensburg.de

[F. W.]

Am 18.05.2022 um 11:08 schrieb Peter Heitzer:
> F. W. <m...@home.com> wrote:
>> Am 18.05.2022 um 00:00 schrieb Marcel Mueller:
>
>>> Mit C und ein paar Jahre später C++ konnte ich mich besser
>>> anfreunden.
>
>> Ich finde es schon merkwürdig, dass es so etwas wie
>
>> var strAntwort: string;
>
>> case strAntwort of
>
>> 'Ja': Positiv (Arg);
>> 'No': Negativ (Arg);
>
>> end;
>
>> in C eigentlich gar nicht gibt. Oder hat jemand eine Lösung?
>
>> FW
>
> do {
> if (!strcmp(antwort,"Ja")) { ...; break; }
> if (!strcmp(antwort,"No")) { ...; break; }
> } while (0);
>

Natürlich nicht so elegant wie switch()...aber gut.

FW

[Peter Heitzer]

Mit einem Makro für Präprozessor könnte man es noch hübscher ausschauen
lassen.

>FW

[Arno Welzel]

Marcel Mueller:

> Am 16.05.22 um 09:52 schrieb F. W.:
>> UCSD-Pascal wurde 1979 von Steve Jobs aufgegriffen und für den Apple II
>> angeboten ("Apple Pascal"). Mit zwei Diskettenlaufwerken,
>> 80-Zeichen-Karte und 48 k RAM lief das System auch recht flüssig.
>>
>> Weshalb ich mich heute manchmal frage, warum mein 16 GB RAM-System so
>> langsam ist, aber das ein ein anderes Thema.
>
> Die Antwort ist einfach. Programme werden immer so geschrieben, dass sie
> den Rechner des Entwicklers gerade so nicht lahm legen. Dass man sie
> überhaupt benutzen kann, liegt daran, dass sie auf dem Rechner des Users
> im Schnitt erst ein paar Jahre später eingesetzt werden, und dann ist
> die Technik schon wieder weiter.

Dann habe ich ja großes Glück, dass selbst mein mittlerweile gut 8(!)
Jahre alter PC immer noch absolut flüssig läuft. Und ja, ich nutze
aktuelle Software damit.

[Arno Welzel]

F. W.:

Es gibt switch() - aber das kann C nicht auf Strings prüfen, da switch()
einen skalaren Datentyp braucht und C keinen skalaren Datentyp für
Strings kennt, sondern nur Zeiger auf Null-terminierte Zeichenketten.

[Martin Ebert]

Am 18.05.22 um 06:47 schrieb olaf:

Falls es noch um Borland und "Turbo" geht: Es gab noch
Turbo-Prolog.

Mt

[Rolf Bombach]

Kay Martinen schrieb:

> Am 17.05.22 um 11:13 schrieb Ralf Kiefer:
>> Bernd Laengerich wrote:
>>
>>> Ich erinnere mich an Swap-Orgien auf dem Diskettenlaufwerk und der klassischen
>>> Fehlermeldung:
>>
>> Klassisches Ressourcenproblem der 1980er: Geldmangel ;-) Im Ernst: mit
>
> Ganz im Ernst. Dieses Ressourcenproblem hat nie aufgehört aktuell zu
> bleiben. Es wird nur immer schlimmer.
>
> Hier müßen irgendwo Geldstaubsauger laufen. Bitte alle mal still sein
> und auf ein Heulen horchen. Die müssen doch zu finden sein [Axt bereit
> haltend]. :-/

Und auch dazu hat Niklaus Wirth eine Meinung:

https://de.wikipedia.org/wiki/Wirthsches_Gesetz

--
mfg Rolf Bombach