Dartmouth Time Shating System

[Thomas Koenig]

Heute kaum mehr bekannt, aber wegweisend: Auf dem System sollten
Studenten die Furcht vor dem Computer ver- und das Programmieren
lernen, und dafür wurde BASIC entwickelt.

Aber die hatten noch was ganz anderes entwickelt, was die
heute allgegenwärtigen Pipes vorwegnahm, deutlich mächter
war und was heute keiner mehr kennt: Communication Files.
Doug McIllroy (der damalige Chef der ganzen Unix-Nerds wie
Thompson, Ritchie etc, der damals auch die Pipes vorgeschlagen
hat) hat da einen schönen Artikel dazu geschrieben, unter
https://www.cs.dartmouth.edu/~doug/DTSS/commfiles.pdf

Faszinierend.

[Ignatios Souvatzis]

Post by Thomas Koenig
Aber die hatten noch was ganz anderes entwickelt, was die
heute allgegenwärtigen Pipes vorwegnahm, deutlich mächter
war und was heute keiner mehr kennt: Communication Files.
Doug McIllroy (der damalige Chef der ganzen Unix-Nerds wie
Thompson, Ritchie etc, der damals auch die Pipes vorgeschlagen
hat) hat da einen schönen Artikel dazu geschrieben, unter
https://www.cs.dartmouth.edu/~doug/DTSS/commfiles.pdf

Hm, sowas wie named pipes, aber dem Text nach master-seitig noch
flexibler.

puffs, rumpkernel (unter NetBSD) und z.B. exokernel gehen in die
Richtung und teils darueber hinaus.

http://lib.tkk.fi/Diss/2012/isbn9789526049175/isbn9789526049175.pdf


-is

[Arno Welzel]

Post by Thomas Koenig
Heute kaum mehr bekannt, aber wegweisend: Auf dem System sollten
Studenten die Furcht vor dem Computer ver- und das Programmieren
lernen, und dafür wurde BASIC entwickelt.
Aber die hatten noch was ganz anderes entwickelt, was die
heute allgegenwärtigen Pipes vorwegnahm, deutlich mächter
war und was heute keiner mehr kennt: Communication Files.
Doug McIllroy (der damalige Chef der ganzen Unix-Nerds wie
Thompson, Ritchie etc, der damals auch die Pipes vorgeschlagen
hat) hat da einen schönen Artikel dazu geschrieben, unter
https://www.cs.dartmouth.edu/~doug/DTSS/commfiles.pdf

Dazu auch noch das hier, wobe ich nicht sicher bin, ob das vergleichbar ist:

<https://dev.to/leandronsp/inter-process-communication-files-1m34>

[F. W.]

Post by Thomas Koenig
Heute kaum mehr bekannt, aber wegweisend: Auf dem System sollten
Studenten die Furcht vor dem Computer ver- und das Programmieren
lernen, und dafür wurde BASIC entwickelt.

Ich stehe zwar vermutlich ziemlich alleine, aber ich fand bei meinem
ersten Kontakt mit einem BASIC-Interpreter 1981 die Editierung durch
Zeilennummern, das Aufrufen anderer Programme durch CHAIN, die
Einfachheit der Sprache i. A. und die Flexibilität von PRINT i. B. schon
ziemlich beeindruckend.

FW

[Peter J. Holzer]

Post by F. W.

Post by Thomas Koenig
Heute kaum mehr bekannt, aber wegweisend: Auf dem System sollten
Studenten die Furcht vor dem Computer ver- und das Programmieren
lernen, und dafür wurde BASIC entwickelt.

Ich stehe zwar vermutlich ziemlich alleine, aber ich fand bei meinem
ersten Kontakt mit einem BASIC-Interpreter 1981 die Editierung durch
Zeilennummern, das Aufrufen anderer Programme durch CHAIN, die
Einfachheit der Sprache i. A. und die Flexibilität von PRINT i. B. schon
ziemlich beeindruckend.

Die Lernkurve war jedenfalls sehr flach. Man konnte sehr schnell etwas
Herzeigbares programmieren. Zugegeben: Die Latte lag in einer Zeit, in
der die meisten Menschen noch keinen Computer gesehen hatten, auch recht
niedrig.

hp

[Helmut Fischer]

... Die Lernkurve war jedenfalls sehr flach. ...

Du meinst vermutlich "steil"?

Grüße, Helmut

[Peter J. Holzer]

Post by Helmut Fischer

... Die Lernkurve war jedenfalls sehr flach. ...

Du meinst vermutlich "steil"?

Nein, flach. Es war sehr leicht zu beginnen:

10 print "Hello, world"

und sehr leicht, inkrementell etwas dazuzulernen. Vom ersten Hello world
zu Ulams Vermutung in ein oder zwei Doppelstunden. Dann einfache Spiele
mit Text-"Graphik" und bald darauf richtige Graphik (und das hat nur so
lange gedauert, weil wir die Apple ][ erst Ende Dezember bekamen). Zu
keinem Zeitpunkt hatte ich das Gefühl, dass ich da etwas Schwieriges
lernen müsste.

Wenn ich heute eine neue Programmiersprache oder auch nur ein neues
Framework lerne, ist die Lernkurve viel steiler. Das mag damit
zusammenhängen, dass ich nicht mehr 16 bin, aber auch damit, dass es
viel mehr zu lernen gibt (schau dir nur mal die Standard-Library von
Python im Vergleich zu Apple-Basic an) und wenig Zeit dafür (das Projekt
soll ja möglichst gestern schon fertig sein).

hp

[Thomas Klix]

Post by Peter J. Holzer

Post by Helmut Fischer

... Die Lernkurve war jedenfalls sehr flach. ...

Du meinst vermutlich "steil"?

10 print "Hello, world"
und sehr leicht, inkrementell etwas dazuzulernen. Vom ersten Hello world
zu Ulams Vermutung in ein oder zwei Doppelstunden. Dann einfache Spiele
mit Text-"Graphik" und bald darauf richtige Graphik (und das hat nur so
lange gedauert, weil wir die Apple ][ erst Ende Dezember bekamen). Zu
keinem Zeitpunkt hatte ich das Gefühl, dass ich da etwas Schwieriges
lernen müsste.

Bis du auf etwas komplexeres stößt.
Es gibt "SUBMIT"/"RETURN", aber echte Unterprogramme im Sinne von
Funktionen / Subroutines gibt es nicht. Keine lokalen Variabalen.
"Beginners' All-purpose Symbolic Instruction Code" eben.
Wenns ernsthaft wird, wird die Lernkurve steiler.

Post by Peter J. Holzer
Wenn ich heute eine neue Programmiersprache oder auch nur ein neues
Framework lerne, ist die Lernkurve viel steiler. Das mag damit
zusammenhängen, dass ich nicht mehr 16 bin, aber auch damit, dass es
viel mehr zu lernen gibt (schau dir nur mal die Standard-Library von
Python im Vergleich zu Apple-Basic an) und wenig Zeit dafür (das Projekt
soll ja möglichst gestern schon fertig sein).

Wenn du noch 16 wärst, würde ich dir Pascal empfehlen. :-)
Im Ernst, Pascal wurde nicht umsonst als Lehrsprache entwickelt. Mit
Turbo-Pascal habe ich strukturiertes Programmieren gelernt. Dann kam
Turbo-C++.

Aber es stimmt: Die grundsätzlichen Sprachbefehle sind in allen
Programmiersprachen einfach (Schleife, if, case, ...) - aber bis man
sich durch die Bibliotheken gewurstet hat, dauert. Und da habe ich noch
nicht einmal von den Windows-Libs angefangen...

Thomas

[Peter J. Holzer]

Post by Thomas Klix

Post by Peter J. Holzer

Post by Helmut Fischer

... Die Lernkurve war jedenfalls sehr flach. ...

Du meinst vermutlich "steil"?

10 print "Hello, world"
und sehr leicht, inkrementell etwas dazuzulernen. Vom ersten Hello world
zu Ulams Vermutung in ein oder zwei Doppelstunden. Dann einfache Spiele
mit Text-"Graphik" und bald darauf richtige Graphik (und das hat nur so
lange gedauert, weil wir die Apple ][ erst Ende Dezember bekamen). Zu
keinem Zeitpunkt hatte ich das Gefühl, dass ich da etwas Schwieriges
lernen müsste.

Bis du auf etwas komplexeres stößt.
Es gibt "SUBMIT"/"RETURN",

SUBMIT sagt mir nichts. Ich kenne nur GOSUB. War aber auch nicht
schwierig.

Post by Thomas Klix
aber echte Unterprogramme im Sinne von Funktionen / Subroutines gibt
es nicht. Keine lokalen Variabalen. "Beginners' All-purpose Symbolic
Instruction Code" eben.

Es gibt natürlich schwierige Probleme. Wir hatten z.B. einmal die Idee,
ein Programm zur Stundenplanerstellung zu schreiben. Daran wären wir
vermutlich gescheitert[1]. Aber nicht daran, dass wir dafür
BASIC-Features gebraucht hätten, die wir nicht verstanden, sondern
daran, dass wir keine Ahnung von Optimierungsstrategien hatten (und
unsere Lehrer auch nicht).

Post by Thomas Klix
Wenns ernsthaft wird, wird die Lernkurve steiler.

Ich habe ein "ernsthaftes" Programm in BASIC geschrieben (d.h. ich wurde
dafür bezahlt und es hatte nicht-triviale Länge). Man entwickelt
natürlich Strategien, wie man längere BASIC-Programme strukturiert,
damit sie wartbar bleiben (Wartung in der Telefonzelle FTW ;-)). Aber
auch da empfand ich die Lernkurve als flach. Da war nirgends ein
plötzlicher Komplexitätssprung. Es war einfach nur eine Progression.

Post by Thomas Klix

Post by Peter J. Holzer
Wenn ich heute eine neue Programmiersprache oder auch nur ein neues
Framework lerne, ist die Lernkurve viel steiler. Das mag damit
zusammenhängen, dass ich nicht mehr 16 bin, aber auch damit, dass es
viel mehr zu lernen gibt (schau dir nur mal die Standard-Library von
Python im Vergleich zu Apple-Basic an) und wenig Zeit dafür (das Projekt
soll ja möglichst gestern schon fertig sein).

Wenn du noch 16 wärst, würde ich dir Pascal empfehlen. :-)

Das habe ich mit 17 gelernt ;-). Im Kasten hinten im EDV-Raum lagen die
Manuals für Apple-Pascal sowie die Disketten. Die habe ich irgendwann
dort entdeckt. Also habe ich im zweiten Jahr hauptsächlich in Pascal
programmiert (nur in der Schule. Für meinen Heimcomputer gab es keinen
leistbaren Pascal-Compiler - die große Programmiersprachenauswahl kam
dann erst mit dem PC und Zugang zur "Software-Tauschbörse" im Hörsaal).

Post by Thomas Klix
Im Ernst, Pascal wurde nicht umsonst als Lehrsprache entwickelt.

Pascal fand ich konzeptionell deutlich schwieriger als BASIC. Rekursion
war mir nicht auf Anhieb klar, und Pointer habe ich erst verstanden,
nachdem ich sie auch in C kennengelernt hatte. Da war die Lernkurve
schon deutlich steiler. Aber ja - immer noch recht flach.

Man muss auch dazusagen, dass die Lernkurve davon abhängt, was man
macht. Perl und Python haben einige ziemlich anspruchsvolle Konzepte,
aber man muss die nicht notwendigerweise kennen, um in diesen Sprachen
programmieren zu können. Als ich noch öfter auf Perl-Konferenzen war,
gab es einen, der ein großer Verfechter von "Baby-Perl" (wie er das
nannte) war, also nur so viel von der Sprache zu lernen, wie man für
seine Aufgaben braucht. (Ich selbst fühle mich unwohl, wenn ich kein
gutes gedankliches Modell habe. "Das funktioniert so, aber ich weiß
nicht warum" macht mir Bauchweh.)

hp

[1] Ich habe dann ein paar Jahre später während des Studiums etwas
Ähnliches geschrieben. Das hat funktioniert und war zumindest zum
Zeitpunkt meiner Sponsion noch im praktischen Einsatz.

[Thomas Klix]

Post by Peter J. Holzer

Post by Thomas Klix
[...]
Bis du auf etwas komplexeres stößt.
Es gibt "SUBMIT"/"RETURN",

SUBMIT sagt mir nichts. Ich kenne nur GOSUB. War aber auch nicht
schwierig.

Sorry, ich meinte GOSUB. Meine BASIC-Zeit ist etwas her...
Aber an die GOTO-Schweinereien kann ich mich erinnern.
Da fällt mir ein (wir sind ja hier folkloristisch): Mit PL/1 hatte ich
da auch viel Spaß. Das kennt auch GOTO, und wenn man da versucht,
ein fremdes Programm zu verstehen, in dem wild in Unterprogramme und
wieder herausgehüpft wird - es war übel.

Post by Peter J. Holzer

Post by Thomas Klix
aber echte Unterprogramme im Sinne von Funktionen / Subroutines gibt
es nicht. Keine lokalen Variabalen. "Beginners' All-purpose Symbolic
Instruction Code" eben.

Es gibt natürlich schwierige Probleme. Wir hatten z.B. einmal die Idee,
ein Programm zur Stundenplanerstellung zu schreiben. Daran wären wir
vermutlich gescheitert[1]. Aber nicht daran, dass wir dafür
BASIC-Features gebraucht hätten, die wir nicht verstanden, sondern
daran, dass wir keine Ahnung von Optimierungsstrategien hatten (und
unsere Lehrer auch nicht).

Als Lehrling habe ich auch versucht, etwas Schwieriges in BASIC zu
realisieren - bin aber auf halber Strecke gescheitert. (Simulation
ESER-Rechner.) Sowohl BASIC als auch Technik waren überfordert. Okay,
ich vielleicht auch.

Stundenplanerstellung inklusive Raumplanung ist eine Wissenschaft für
sich - was die dafür Verantwortlichen an (Magnet-)Schildchen
rumschubsen, will ich gar nicht wissen.

Post by Peter J. Holzer
[...]
Pascal fand ich konzeptionell deutlich schwieriger als BASIC. Rekursion
war mir nicht auf Anhieb klar, und Pointer habe ich erst verstanden,
nachdem ich sie auch in C kennengelernt hatte. Da war die Lernkurve
schon deutlich steiler. Aber ja - immer noch recht flach.

Natürlich sind ernsthafte Programmiersprachen schwieriger als BASIC.
Gerade Rekursion oder Pointer gehen in BASIC überhaupt nicht.
Aber: Wenn du *das* noch als flache Lernkurve einstufst, bist du einsam
genial. :-)

Post by Peter J. Holzer
Man muss auch dazusagen, dass die Lernkurve davon abhängt, was man
macht. Perl und Python haben einige ziemlich anspruchsvolle Konzepte,
aber man muss die nicht notwendigerweise kennen, um in diesen Sprachen
programmieren zu können. Als ich noch öfter auf Perl-Konferenzen war,
gab es einen, der ein großer Verfechter von "Baby-Perl" (wie er das
nannte) war, also nur so viel von der Sprache zu lernen, wie man für
seine Aufgaben braucht. (Ich selbst fühle mich unwohl, wenn ich kein
gutes gedankliches Modell habe. "Das funktioniert so, aber ich weiß
nicht warum" macht mir Bauchweh.)

Ich frage mich auch, ob jemand "C"s Pragmas tatsächlich nutzt. Gesehen
habe ich es noch nicht.
Aber: "C&P"-Murks habe ich schon gesehen. Konnte nicht funktionieren.
Ich will verstehen, was ich release.

Thomas

[Michael Kraemer @ home]

Post by Thomas Klix
Ich frage mich auch, ob jemand "C"s Pragmas tatsächlich nutzt.

Ja.

Post by Thomas Klix
Gesehen habe ich es noch nicht.

#pragma omp parallel for schedule(dynamic) default(none)\
private(xyz)\
shared(zyx)

[Peter Heitzer]

Post by Michael Kraemer @ home

Post by Thomas Klix
Ich frage mich auch, ob jemand "C"s Pragmas tatsächlich nutzt.

Ja.

Post by Thomas Klix
Gesehen habe ich es noch nicht.

#pragma omp parallel for schedule(dynamic) default(none)\
private(xyz)\
shared(zyx)

oder z.B.
#pragma pack(1)

Bei der Programmierung von PIC Mikrocontrollern mit MPLABX
wird die Konfigurierung (entspricht den Fuses bei AVRs) mit Pragmas
eingestellt.

[Peter J. Holzer]

Post by Thomas Klix

Post by Peter J. Holzer
Pascal fand ich konzeptionell deutlich schwieriger als BASIC. Rekursion
war mir nicht auf Anhieb klar, und Pointer habe ich erst verstanden,
nachdem ich sie auch in C kennengelernt hatte. Da war die Lernkurve
schon deutlich steiler. Aber ja - immer noch recht flach.

Natürlich sind ernsthafte Programmiersprachen schwieriger als BASIC.
Gerade Rekursion oder Pointer gehen in BASIC überhaupt nicht.

Ich glaube, dass GOSUB/RETURN bei den üblichen BASIC-Interpretern einen
Stack verwendet haben. Rekursion wäre somit technisch möglich gewesen.
Aber mangels lokaler Variablen nicht sehr nützlich. Wenn man sich selbst
um das Verwalten der Variablen im Call-Stack kümmern muss, wird jeder
nicht-triviale Algorithmus so kompliziert, dass man die Energie besser
ins "Flachklopfen" der Rekursion in eine Schleife steckt. Das ist zwar
auch schwer zu lesen (unser Lehrbuch enthielt eine Implementation von
Quicksort in BASIC als abschreckendes Beispiel), aber wenigstens nur auf
eine Art und nicht auf zwei widersprüchliche Arten.

Post by Thomas Klix
Aber: Wenn du *das* noch als flache Lernkurve einstufst, bist du einsam
genial. :-)

Ich kenne ein paar geniale Programmierer, die sind deutlich über meinem
Niveau. Aber als etwas überdurchschnittlich schätze ich mich schon ein.

Rekursion empfinde ich eigentlich nicht als sehr schwierig, und ich weiß
nicht mehr, worin da meine anfängliche Verwirrung lag, oder wie ich sie
aufgelöst habe. Wahrscheinlich hat »Gödel, Escher, Bach« lesen geholfen
;-).

Pointer brauchte ich in Pascal erst mal nicht und konnte sie daher
aufschieben. In C brauchte ich sie dann und die Erklärungen in K&R kamen
mir einleuchtend vor. Aber da hatte ich dann auch schon einige
Assembler-Erfahrung, das hat sicher auch geholfen.

Post by Thomas Klix
Ich frage mich auch, ob jemand "C"s Pragmas tatsächlich nutzt.

Mittlerweile gibt es ja ein paar standardisierte. Soweit ich sehe, haben
die alle was mit Floating-Point-Arithmetik zu tun, werden also wohl in
numerisch anspruchsvollem Code verwendet werden.

Lange aber gab es nur compiler-spezifische Pragmas und die hat man eher
nur in plattform-spezifischem Code gesehen. Im Linux-Kernel kommen z.B.
etliche vor. Der konnte auch lange nur mit dem GCC kompiliert werden,
mittlerweile geht es meines Wissens auch mit Clang.

hp

[Thomas Koenig]

Post by Peter J. Holzer

Post by Thomas Klix

Post by Peter J. Holzer
Pascal fand ich konzeptionell deutlich schwieriger als BASIC. Rekursion
war mir nicht auf Anhieb klar, und Pointer habe ich erst verstanden,
nachdem ich sie auch in C kennengelernt hatte. Da war die Lernkurve
schon deutlich steiler. Aber ja - immer noch recht flach.

Natürlich sind ernsthafte Programmiersprachen schwieriger als BASIC.
Gerade Rekursion oder Pointer gehen in BASIC überhaupt nicht.

Ich glaube, dass GOSUB/RETURN bei den üblichen BASIC-Interpretern einen
Stack verwendet haben.

Leider nein, zumindest für die Microsoft-Basic-Derivate wie
Commodore-Basic. Wenn sowas wie ein Stack gewünscht war, dann
musste man den sich selber aus einem Array basteln, und
Variablen konnte man auch nicht lokal halten.

Sowas wie Turbo Basic hatte dann tatsächlich benannte
Unterpgrogramme mit lokalen Variablen usw.

[Peter J. Holzer]

Post by Thomas Koenig

Post by Peter J. Holzer
Ich glaube, dass GOSUB/RETURN bei den üblichen BASIC-Interpretern einen
Stack verwendet haben.

Leider nein, zumindest für die Microsoft-Basic-Derivate wie
Commodore-Basic. Wenn sowas wie ein Stack gewünscht war, dann
musste man den sich selber aus einem Array basteln, und
Variablen konnte man auch nicht lokal halten.

Ich meinte für die Return-Adressen, und das funktioniert zumindest für
Applesoft-BASIC (auch ein MS-BASIC-Derivat):

5 home
10 a = 2
20 gosub 100
25 print 100
30 end
100 if a = 0 then return
110 print a
120 a = a - 1
130 gosub 100
140 return


Das gibt wie erwartet
2
1
100
aus.

Getestet auf <https://www.calormen.com/jsbasic/>, ich weiß nicht, wie
originalgetreu das ist.

Vielleicht kann das ja mal jemand auf richtiger Hardware ausprobieren.

hp

[Thomas Koenig]

Post by Peter J. Holzer

Post by Thomas Koenig

Post by Peter J. Holzer
Ich glaube, dass GOSUB/RETURN bei den üblichen BASIC-Interpretern einen
Stack verwendet haben.

Leider nein, zumindest für die Microsoft-Basic-Derivate wie
Commodore-Basic. Wenn sowas wie ein Stack gewünscht war, dann
musste man den sich selber aus einem Array basteln, und
Variablen konnte man auch nicht lokal halten.

Ich meinte für die Return-Adressen, und das funktioniert zumindest für

OK, das stimmt natürlich.

Beim 6502 mit seinen 256 Bytes war nur der Stack ziemlich schnell
voll...

[Stefan Reuther]

Post by Thomas Koenig

Post by Peter J. Holzer
Ich meinte für die Return-Adressen, und das funktioniert zumindest für

OK, das stimmt natürlich.
Beim 6502 mit seinen 256 Bytes war nur der Stack ziemlich schnell
voll...

Ein typischer Interpreter nutzt für GOSUB/RETURN nicht den
Prozessor-Stack, sondern baut sich da selbst was.

Das geht soweit, dass du bei den späteren BASIC-Dialekten sowas wie

sub foo(a%)
gosub 100
print 10
100 print 20
if a%=1 then return
exit sub
end sub

machen konntest, und es dann zwei verschiedene Stacks gab, einen für
RETURN, einen für EXIT SUB. Beim QuickBasic-Compiler war EXIT SUB
tatsächlich der Prozessor-Stack.


Stefan

[Thomas Koenig]

Post by Stefan Reuther

Post by Thomas Koenig

Post by Peter J. Holzer
Ich meinte für die Return-Adressen, und das funktioniert zumindest für

OK, das stimmt natürlich.
Beim 6502 mit seinen 256 Bytes war nur der Stack ziemlich schnell
voll...

Ein typischer Interpreter nutzt für GOSUB/RETURN nicht den
Prozessor-Stack, sondern baut sich da selbst was.

Beim C64 war es zumindest der Prozessor-Stack.

Post by Stefan Reuther
Das geht soweit, dass du bei den späteren BASIC-Dialekten sowas wie
sub foo(a%)
gosub 100
print 10
100 print 20
if a%=1 then return
exit sub
end sub
machen konntest,

Klar, aber das war ja auch kein BASIC mehr, das war dekadent :-)

[Stefan Reuther]

Post by Thomas Koenig

Post by Stefan Reuther

Post by Thomas Koenig
Beim 6502 mit seinen 256 Bytes war nur der Stack ziemlich schnell
voll...

Ein typischer Interpreter nutzt für GOSUB/RETURN nicht den
Prozessor-Stack, sondern baut sich da selbst was.

Beim C64 war es zumindest der Prozessor-Stack.

In der Tat.

https://github.com/mist64/msbasic/blob/master/flow2.s#L12
https://github.com/mist64/msbasic/blob/master/flow2.s#L79

Wer macht denn sowas?!


Wieder was gelernt,
Stefan

[Peter J. Holzer]

Post by Stefan Reuther

Post by Thomas Koenig

Post by Stefan Reuther

Post by Thomas Koenig
Beim 6502 mit seinen 256 Bytes war nur der Stack ziemlich schnell
voll...

Ein typischer Interpreter nutzt für GOSUB/RETURN nicht den
Prozessor-Stack, sondern baut sich da selbst was.

Beim C64 war es zumindest der Prozessor-Stack.

In der Tat.
https://github.com/mist64/msbasic/blob/master/flow2.s#L12
https://github.com/mist64/msbasic/blob/master/flow2.s#L79
Wer macht denn sowas?!

Guido? Bei CPython wird belegt Rekursion auch Platz am Prozessor-Stack.
IMHO eine etwas unglückliche Designentscheidung. Zwar sind Stacks heute
viel größer als damals, aber im Vergleich zum Gesamtspeicher eher
kleiner. Am C64 waren 256 Bytes ein 256stel des RAMs (bzw. ca. ein
150stel des sichtbaren RAMs). Auf einem Linux-Rechner mit angenommen
16 GB RAM sind 8 MB Stack nur ein 2048stel.

hp

[p***@pocnet.net]

Post by Thomas Klix
Ich frage mich auch, ob jemand "C"s Pragmas tatsächlich nutzt. Gesehen
habe ich es noch nicht.

Ja. Wobei das was ich nutze keine "inhärente" C-Sache ist, sondern eine
IBM-Erweiterung: #pragma mapinc.

<https://www.ibm.com/docs/en/i/7.5?topic=descriptions-mapinc>

Für die interessierte Leserschaft: Das ermöglicht die "dynamische" Erstellung
von Structs in separaten aber automatisch eingebundenen Headerdateien zur
Kompilezeit aus der Feldbeschreibung des referenzierten Systemobjekts
(Datenbanktabelle, Displayfile, etc.). Feld zu klein? Kein Ding. Objekt
anpassen, Code neu kompilieren, fertig. Kein manuelles Ändern von Code
notwendig.

[Martin Klaiber]

Post by Peter J. Holzer

Post by Helmut Fischer

... Die Lernkurve war jedenfalls sehr flach. ...

Du meinst vermutlich "steil"?

10 print "Hello, world"
und sehr leicht, inkrementell etwas dazuzulernen.

Es gibt zwei Bedeutungen von "Lernkurve". Leider meinen sie das genau
Gegensätzliche. Siehe:

<https://de.wikipedia.org/wiki/Lernkurve>

Helmut meint also die ursprüngliche Bedeutung, Du meinst die später
hinzugekommene.

Martin

[Peter J. Holzer]

Post by Martin Klaiber

Post by Peter J. Holzer

Post by Helmut Fischer

... Die Lernkurve war jedenfalls sehr flach. ...

Du meinst vermutlich "steil"?

10 print "Hello, world"
und sehr leicht, inkrementell etwas dazuzulernen.

Es gibt zwei Bedeutungen von "Lernkurve". Leider meinen sie das genau
<https://de.wikipedia.org/wiki/Lernkurve>
Helmut meint also die ursprüngliche Bedeutung, Du meinst die später
hinzugekommene.

Diese ursprüngliche Bedeutung kannte ich bis jetzt nicht. In fast
vierzig Jahren Beschäftigung mit Usability ist mir immer nur "steil" =
"viel Aufwand für wenig Fortschritt" untergekommen.

hp

[Stefan+ (Stefan Froehlich)]

Post by Martin Klaiber

Post by Peter J. Holzer

Post by Helmut Fischer

... Die Lernkurve war jedenfalls sehr flach. ...

Du meinst vermutlich "steil"?

10 print "Hello, world"
und sehr leicht, inkrementell etwas dazuzulernen.

Es gibt zwei Bedeutungen von "Lernkurve". Leider meinen sie das
<https://de.wikipedia.org/wiki/Lernkurve>
Helmut meint also die ursprüngliche Bedeutung, Du meinst die später
hinzugekommene.

Ah, fein. Ich wunderte mich seit jeher, dass die Definition dieser
ominösen Lernkurve aus irgendeinem Grund genau verkehrt herum
gewählt wurde, hatte mir aber nie die Mühe gemacht, das zu
recherchieren.

Die "alternative Definition" hat sich vermutlich durchgesetzt, weil
man mit der "steilen Kurve" einen steilen Hügel verbindet, der
erklommen werden muss. Ein bisschen wie beim Quantensprung...

Servus,
Stefan

[Christian Corti]

Post by Peter J. Holzer
10 print "Hello, world"
und sehr leicht, inkrementell etwas dazuzulernen. Vom ersten Hello world

Das nennt man steil, alldieweil man in der x-Achse die Zeit darstellt,
die man zum Lernen aufgewandt hat, und in der y-Achse den Lernerfolg/das
angeeignete Wissen.
Wenig Zeit - viel gelernt ist nunmal eine sehr steile Kurve.
Du kannst natürlich das Diagram an der ersten Winkelhalbierenden
spiegeln, aber dann ist es keine Lernkurve, sondern eine Aufwandskurve;
wieviel Zeit muß ich aufwenden, um einen bestimmten Lernstand zu
erreichen. Diese Kurve ist dementsprechend flach.

Christian

[Stefan Ram]

Post by Christian Corti
Das nennt man steil, alldieweil man in der x-Achse die Zeit darstellt,
die man zum Lernen aufgewandt hat, und in der y-Achse den Lernerfolg/das
angeeignete Wissen.

|Umgangssprachlich (insbesondere im Softwaremarketing und in
|der Werkzeug-Branche) wird eine Lernkurve als "steil"
|bezeichnet, wenn das Lernen der Bedienung oder Anwendung
|eines Werkzeugs oder Software-Tools schwierig und mühsam ist
Webseite

Ein Berg ist /schwerer/ zu erklimmen, wenn sein Aufstiegsweg
/steiler/ ist. Daher kommt wohl das Bild, "steil" für "schwer".

Übungsaufgabe:

Interpretiere die Bedeutung der Aussage zur Lernkurve in:

|Solo Piano ist nur eine kleine Klaviertastatur. Es zeichnet
|nicht auf, es spielt keine Aufnahmen ab, es hat keine Lernkurve.
Webseite.

[Stefan+ (Stefan Froehlich)]

Vom ersten Hello world zu Ulams Vermutung in ein oder zwei
Doppelstunden. Dann einfache Spiele mit Text-"Graphik" und bald
darauf richtige Graphik (und das hat nur so lange gedauert, weil
wir die Apple ][ erst Ende Dezember bekamen). Zu keinem Zeitpunkt
hatte ich das Gefühl, dass ich da etwas Schwieriges lernen müsste.
Wenn ich heute eine neue Programmiersprache oder auch nur ein
neues Framework lerne, ist die Lernkurve viel steiler. Das mag
damit zusammenhängen, dass ich nicht mehr 16 bin, aber auch damit,
dass es viel mehr zu lernen gibt [...]

Vor allem hat es wohl etwas mit den eigenen Anforderungen an die
erstellte Software zu tun, beginnend bei Robustheit und
Fehlertoleranz für Eingaben, Qualität der Ausgaben, Grafiken und
noch längst nicht endend bei Datenbank- und Netzwerkzugriffen.

Um einen halbwegs simplen, rein numerischen Algorithmus zu
implementieren, wirst Du heute (mit Deiner Programmiererfahrung im
Hinterkopf) bei einer neuen Sprache eher noch weniger lang benötigen
als damals.

Servus,
Stefan