Kein Schwein programmiert(e) in Forth

[Hans-Peter Diettrich]

Am 16.10.2019 um 23:04 schrieb Axel Berger:

Hans-Peter Diettrich wrote:
MS-DOS mußte ich einmal eindeutschen, weil es das fßr
unsere Laptops nur in Englisch gab, mit dem unsere Anwender nicht
klarkamen.

Glaube ich nicht, aber ich bin sicher, daß sie das behauptet haben.
Immer dann, wenn mir jemand als Grund fĂźr seinen eingedeutschten Mist
angibt, er verstßnde englische Oberflächen nicht,

Welche Oberfläche erwartest Du von MS-DOS, und was fßr Anwender, Ende
der 80er Jahre? Da mußte unsere Messtechnik mit GW-Basic programmiert
werden, weil nur damit serielle Datenerfassung und Grafik gleichzeitig
mĂśglich waren.

Und hÜr bitte auf, meine Beiträge in Deinen Quotes zu verhunzen!

DoDi

 

[Heinz Schmitz]

Wolfgang Allinger wrote:

Mit dieser umgekehrten polnischen Notation mag sich auch niemand so
richtig anfreunden.
Aber das hat es tatsächlich gegeben.

keine Sorge, UPN|RPN gibbet immer noch. Und wers kapiert hat, will nix
anderes mehr.

So ist es. Der HP35 war einfach genial. Und dann die programmierbaren
HPs erst.

Meist lernt man das Programmieren an dem, was da ist oder was man
bekommen kann. Fortran-Kurs an der Uni, aber man kommt nicht an die
Maschine. Teletype an der Uni, natürlich mit Basic. Dann die HPs.
Endlich der Commodore Pet. Dann der Olivetti M24. Und der Pentium
mit 90 MHz . Etc.
Die Software war damals ziemlich teuer, und so nutzte man eben das,
was mit dem OS mitkam. Wenn man einmal da eingestiegen war, wollte
man natürlich nicht mehr "mal eben" das Pferd wechseln. Nicht umsonst
war MS$ den Schulen gegenüber so grosszügig. Fast wie mit Drogen.
Leider kam Linux viel zu spät. Man wollte ja MIT dem System arbeiten,
und nicht nur DARAN.

Grüße,
H.

 

[Roland Franzius]

Am 16.10.2019 um 17:11 schrieb Hans-Juergen Schneider:

"Chr. Maercker" wrote:

Hans-Peter Diettrich wrote:
Sag ich doch immer: wer mit BASIC anfängt, ist als Programmierer fßr
immer versaut :-(

MÜglich. Wobei ich vorher FORTRAN kennengelernt habe. Danach waren
Großrechner fßr mich ein fßr allemal erledigt, Hochsprachen lange Zeit
ebenfalls. Wozu zehn FORTRAN-Anweisungen, wenn sich 1+1 mit ca. Zeilen
in Assembler zusammenzählen lässt?? 5 BASIC hat mich letzlich den
Programmiersprachen wieder etwas näher gebracht, es reichte indes nur
bis Turbo Pascal.

Mir sind Meinungen ßber FORTH vÜllig egal, ich habe damit fast 10 Jahre
lang meine Mikroprozessor-Systeme und ZubehÜr programmiert - nachdem ich
im Studium etwa 20 andere Programmiersprachen kennengelernt hatte.

FORTH hab ich nie kennengelernt. Fßr Z80-Systeme habe ich außer
Assembler fast nur BASIC-Interpreter gesehen.

Mit dieser umgekehrten polnischen Notation mag sich auch niemand so
richtig anfreunden.
Aber das hat es tatsächlich gegeben.

Es gibt im Wesentlichen zwei verschiedene Paradigmen der Betrachtung von
maschineller Datenverarbeitung. Das Ăźbeliche ist eine Maschine, die wie
die staatliche Verwaltung funktioniert, sie wird mit Daten gefĂźttert und
produziert handlungsanweisenden Output fßr Geräte und Leute, die von der
Materie keine Ahnung haben.

Dagegen steht das physikalisch-biologistische Paradigma, eine Gruppe von
Automaten, die durch einen Datenurwald turnt und dabei sowohl eine Spur
geordneter Daten wie auch eine Verbesserung ihrer eigenen
Existenzgrundlage produziert.

Die umgekehrte polnische Notation simplifziert die Dinge dadurch, dass
das Funktionsmodell den Programmierer zwingt alle Daten herbeizuschaffen
und geordnet bereitzulegen, bevor eine Funktion zur AusfĂźhrung kommt.

Dieser Programmierstil beseitigt die Notwendigkeit, fĂźr alles und jedes
erstmal einen Namen zu erfinden, obwohl das Datum nur oder zweimal
verwendet wird.

Auf der anderen Seite verunmĂśglicht die Nichtverwendung von Namen fĂźr
nicht dauerhaft benĂśtigte Funktionen und Variablen in Programmen die
Erkennung das Denkmodells dahinter.

Wegen der Monopolisierung alles und jedes Programmiermodells bis
herunter zu Einzeilern im hyperkapitalistischen Politikmodell sind auch
alle anderen Programmentwickler auf kryptische Zeichenketten als
Bezeichner umgestiegen.

FORTH, Mathematica und andere vereinfachen diesen Ansatz in das Extrem,
dass das assemblierte Programm oder ein Hash davon selbst als sein
Aufrufname dienen kann und wenn ad hoc als anonyme Daten oder Programme
auf dem Stack eingesetzt nach AusfĂźhrung automatisch verschwinden.

Zufällig gestern in Wikipedia nachgeschlagen, die Vorgehensweise der
kompletten Isolation der BIOS-Entwickler von der Produktionsabteilung
und dieser vom Rest der Welt bei Phoenix zur Vermeidung von
Patentrechtsstreitigkeiten mit IBM etc in den 1980ern:

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

--

Roland Franzius

 

[Peter Heitzer]

Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:

On 16.10.19 19:04, Guido Grohmann wrote:
Ralph Aichinger schrieb:
Dave U. Random <random@dave.u> wrote:
Dieses Video visualisiert schoen die populaersten Programmiersprachen

Programmierende Schweine sind selten.

Ja, aber manche Programme sehen trotzdem saumäßig aus.

Fairerweise muss man dazusagen, dass das in jeder Programmiersprache geht

Python hat ja das interessante Feature (manche Leute hassen es
unheimlich) dass EinrĂźckung ein syntaktisches Element ist. Ich finde das
ganz gut, weil es wirklich dazu zwingt, korrekt einzurĂźcken. Aber hilft
auch nicht, man kann auch in Python C programmieren

Hilfreich fĂźr Obfuscation ist hier die Verwendung von lambda, mĂśglichst
geschachtelt ;-)



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

 

[Johannes Bauer]

On 16.10.19 23:45, Ewald Pfau wrote:

Johannes Bauer <dfnsonfsduifb@gmx.de>:

Erstens: "Riad". Zweitens: bei so einem großen Claim ("komplett in
Forth") sollte sich doch ein Beleg auftreiben lassen, oder? Neh, wenn
ich suche nach "riyadh airport forth" sagt mir Google, dass er "Forth"
aus der Suche weggelassen hat, weil da nichts kommt.

Es geht um die Gepäckabfertigung. Forth.com waren einmal mächtig stolz auf
den Auftrag, ist aber schon eine Zeitlang her. Google ist kein Archivmedium,
es tut nur so.

Das stimmt natĂźrlich, aber wenn man gar keine Hits findet, ist es schon
so ein Indiz dass man sich entweder vertippt hat, falsch errinert, ewig
her war oder verboten ist

Finde doch eine Erwähnung, Kapitel 3.3.1 in

https://www.forth.com/resources/forth-programming-language/

Perfekt, vielen Dank!

Die Fußnote, die ich nachgeschlagen habe: "Fifteen Programmers, 400
Computers, 36000 Sensors and FORTH". D.h. schon vom Titel wird klar,
dass Wolfgang um den Faktor 10 Ăźbertrieben hat mit den angeblichen 4000
Computern, aber sei's drum.

Interessant ist der Inhalt nämlich allemal, aber das ganze ist jetzt
eben schon 35 Jahre her. Mit 8 PDP-11s und ~400 8086ern haben sie das
System aufgebaut. Der Prototyp lief unter FORTRAN und Assembler und
wurde wohl von der Forth-Variante in Performance geschlagen.

Sowas, genau sowas, finde ich superspannend. Weil intuitiv sollte man ja
annehmen, dass die mindestens dieselbe Performance erreichen kĂśnnten,
insbesondere da die auf Asm zurĂźckgreifen kĂśnnen. Das Paper ist auch
ehrlich und dokumentiert, warum das so war: "the prototype software
developed under RSX fell far short of meeting the performance
requirements in the system [...] At the 8086 level, the lack of full
multi-tasking in the RMX environment led to both performance problems
and excessively elaborate code [...]"

Das finde ich deswegen spannend, weil genau die Tatsache, also dass
kooperatives Multitasking mit Coroutinen (so verstehe ich Forth
zumindest) eben in den letzten Jahren "neu erfunden" wurde, nennt sich
denn asynchrone Programmierung oder asyncio. Das war lange in den
Programmierparadigmen der typischen Hochsprachen (Fortran/C/etc) gar
nicht vorhanden, und ist dann Ăźber die Skriptsprachen jetzt mittlerweile
wieder reingewandert in klassische Hochsprachen.

Der Grund: Viel hĂśhere Performance verglichen mit klassischen
leichtgewichtigen Threads. Fand ich auch schwer zu glauben,
ehrlichgesagt (weil eigentlich mĂźsste das auch ja derselbe Overhead
sein), die Messungen lĂźgen aber nicht und das wird von dem 1985er Paper
ja auch festgestellt.

wahrscheinlich aussortiert, weil wirklich schon älter, die Fundstelle hat
einen Literaturverweis auf 1985, muss mächtig lustig gewesen sein, damals,
für das gesamte Team - Verweis auf Rather, E.D., “Fifteen Programmers, 400
Computers, 36,000 Sensors and Forth,” Journal of Forth Application and
Research (3, #2, 1985).

Daher habe ich ihn:

http://soton.mpeforth.com/flag/jfar/vol3/no2/article4.pdf

Sehr schĂśnes Paper, sollte man aufheben.

Aber ja, ich nehme an, das ist nicht mehr in Betrieb, wĂźrde mich sehr
wundern wenn in Riad noch PDP-11s und 8086er im Rechenzentrum stehen.

Forth.com ist eine nicht ganz so kleine Firma, mit belastbarereren
Realitätshorizont, vielleicht dort die Liste der Applikationen frequentieren
anstatt hier Ăźber das Zeitgeistige in der Zeitgeistigkeit zu lamentieren:

https://www.forth.com/resources/forth-apps/

Auch spannend. Klingt aber eben eher nach Spezialapplikationen, wie
Wolfgang sie auch aufgezählt hat: Satelliten, Roboterarm vom
Spaceshuttle, Waffensysteme.

Ist ja auch nicht schlimm, fĂźr jeden Topf gibts ja einen Deckel. Aber so
zu tun als sei Forth das, was heute noch federfĂźhrend fĂźr
Embedded-Applikationen eingesetzt wird, ist einfach unwahr.

Achso, wenn ein Openboot nicht bei Ieee weitergefĂźhrt wird, kann es trotzdem
in Verwendung sein. Wenn ein Rechner nicht bootet wie er soll, kann es sein,
dass man damit Bekanntschaft macht, so kĂźrzlich auf einem I7-Laptop, der
bestimmt jĂźnger ist als 20 Jahre. Entsinne mich dunkel, dass es aktuell eine
Opensource-Gruppe fĂźr das Openboot gibt, mĂźsste man aber suchen, wo die sich
herumtreibt.

Bist du dir wirklich sicher, auf dem i7, dass das Forth war? Es gibt ja
die UEFI-Varianten die einen Interpreter haben, der etwas ähnliches
emuliert, aber die sind m.W.n. nicht in Forth implementiert (sondern
geben dir nur eine interaktive "Shell", die so ähnlich aussieht). Aber
ja, macht man immer mit Bekanntschaft, wenn beim Installieren des
Bootloaders was schiefgegangen ist

Ich mach schon lang nichts mehr damit, von daher hab ich aus den Augen
verloren, ob es sonstwo da oder dort solche Listen gibt.

Vielen Dank jedenfalls fĂźr die Referenzen und unaufgeregte Diskussion.
Es geht ja auch gar nicht darum, wer wieviel wo hat, sondern ich finde
eher die Frage spannend warum das besser war, in welches Aspekten und
was man darauf lernen kann um z.B. gute Performance auch in anderen
Systemen zu erreichen.

Viele Grüße,
Johannes

--
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

 

[Andreas Karrer]

* Wolfgang Allinger <all2001@spambog.com>:

keine Sorge, UPN|RPN gibbet immer noch. Und wers kapiert hat, will nix
anderes mehr.

Achwas. Ich weiss sehr genau, was UPN ist, und ich will anderes.

HP kam nicht UPN, weil das so supertoll ist, sondern weil der
HP9100 zu limitiert war, um algebraisches Format zu können.

Der HP 9100A war ein programmierbarer Tischrechner mit
"Tastencode"-Programmierung, der so ziemlich alles, was später in den
HP-Taschenrechnern verbraten wurde, schon konnte. Und zwar 1968, ohne
LED, ohne ICs (und damit ohne RAM und ROM im heutigen Sinn). Ohne HP
9100 kein HP-35.

BTDT. War ganz lustig, die Gehirnwindungen so zu verdrehen, dass sie
dem Rechner passten. Der HP 9100B, den wir am Gymnasium hatten,
existiert noch, und ich habe ihn vor ein paar Jahren mal ausgeliehen,
ein paar Kontakte gereinigt, spröde Gummiteile und Lämpchen ersetzt
-- funktionierte wie am ersten Tag.

Und nachher nie wieder UPN. Denn in der Zwischenzeit hat man begriffen, dass
Computer leistungsfähig genug sind, dass sie sich den Gehirnwindungen
der Menschen anpassen können und nicht umgekehrt. Beispielsweise macht
ein typischer Compiler für höhere Programmiersprachen bei der
Berechnung von algebraischen Ausdrücken genau das: er konvertiert
algebraische Notation in Stack-Arithmetik. Er bildet Terme, wirft sie
auf den Stack, bildet Summen der Top-of-Stack-Elemente usw.


- Andi

 

[Hans-Peter Diettrich]

Am 17.10.2019 um 09:34 schrieb Heinz Schmitz:

Die Software war damals ziemlich teuer, und so nutzte man eben das,
was mit dem OS mitkam.

Dann hast Du wohl den ST verschlafen. Dazu gab es alles, was das Herz
begehrt, als Shareware oder in der PD. IMO ein Grund fĂźr den Untergang,
weil sich kein kommerzieller Anbieter dort halten konnte und so der ST
totgeschwiegen wurde.

DoDi

 

[Hans-Peter Diettrich]

Am 17.10.2019 um 13:22 schrieb Andreas Karrer:

ein typischer Compiler für höhere Programmiersprachen bei der
Berechnung von algebraischen Ausdrücken genau das: er konvertiert
algebraische Notation in Stack-Arithmetik. Er bildet Terme, wirft sie
auf den Stack, bildet Summen der Top-of-Stack-Elemente usw.

Und der Benutzer wundert sich, daß nicht das gewünschte Ergebnis
herauskommt. Weil er keine Ahnung mehr von Numerik hat, falsche
Datentypen verwendet, Über- und Unterläufe produziert, weil ja alles
anscheinend so einfach ist.

DoDi

 

[Hans-Peter Diettrich]

Am 17.10.2019 um 13:28 schrieb Hans-Peter Diettrich:

Am 17.10.2019 um 13:22 schrieb Andreas Karrer:

ein typischer Compiler für höhere Programmiersprachen bei der
Berechnung von algebraischen Ausdrücken genau das: er konvertiert
algebraische Notation in Stack-Arithmetik. Er bildet Terme, wirft sie
auf den Stack, bildet Summen der Top-of-Stack-Elemente usw.

Und der Benutzer wundert sich, daß nicht das gewünschte Ergebnis
herauskommt. Weil er keine Ahnung mehr von Numerik hat, falsche
Datentypen verwendet, Über- und Unterläufe produziert, weil ja alles
anscheinend so einfach ist.

Das wichtigste habe ich noch vergessen: Operator-Prioritäten!

DoDi

 

[Eric Bruecklmeier]

Am 17.10.2019 um 13:28 schrieb Hans-Peter Diettrich:

Am 17.10.2019 um 13:22 schrieb Andreas Karrer:

ein typischer Compiler für höhere Programmiersprachen bei der
Berechnung von algebraischen Ausdrücken genau das: er konvertiert
algebraische Notation in Stack-Arithmetik. Er bildet Terme, wirft sie
auf den Stack, bildet Summen der Top-of-Stack-Elemente usw.

Und der Benutzer wundert sich, daß nicht das gewünschte Ergebnis
herauskommt. Weil er keine Ahnung mehr von Numerik hat, falsche
Datentypen verwendet, Über- und Unterläufe produziert, weil ja alles
anscheinend so einfach ist.

Es war vermutlich schon ein Fehler vom Baum herab zu steigen... viel zu
gefährlich - was da alles passieren kann. Den Abakus durch Elektronik zu
ersetzen war dann gleich der nächste Sündenfall... grauslich!

 

[Johannes Bauer]

On 17.10.19 13:28, Hans-Peter Diettrich wrote:

Am 17.10.2019 um 13:22 schrieb Andreas Karrer:

ein typischer Compiler für höhere Programmiersprachen bei der
Berechnung von algebraischen Ausdrücken genau das: er konvertiert
algebraische Notation in Stack-Arithmetik. Er bildet Terme, wirft sie
auf den Stack, bildet Summen der Top-of-Stack-Elemente usw.

Und der Benutzer wundert sich, daß nicht das gewünschte Ergebnis
herauskommt. Weil er keine Ahnung mehr von Numerik hat, falsche
Datentypen verwendet, Über- und Unterläufe produziert, weil ja alles
anscheinend so einfach ist.

Ein denkbar schlechtes Argument.

Du wirst ja wohl nicht allen Ernstes behaupten wollen, dass man das
Abstraktionsniveau möglichst niedrig ansetzen sollte, damit man eine
geringere Programmierfehlerquote erreicht? Ich vermute, exakt das
Gegenteil ist der Fall. Denn Numerik, Datentypen, Über- und Unterläufe
muss man auch in einer niedrigeren Abstraktion berücksichtigen. Aber
obendrauf kommt dann halt noch krude, umständliche Syntax (z.B. direkt
Assembler-Code oder RPN) die eben nicht direkt das widerspegelt, was ich
machen will.

Beispiel:

y = a x^2 + bx + c

Sofort offensichtlich, was das ist.

#define sqr(x) ((x) * (x))

y = a * sqr(x) + b * x + c;

Und jetzt

mulsd %xmm0, %xmm1
mulsd %xmm0, %xmm1
mulsd %xmm2, %xmm0
addsd %xmm0, %xmm1
addsd %xmm3, %xmm1
movapd %xmm1, %xmm0

Oder eben

x x mul a mul b x mul c add add

(Das ich dreimal angeschaut habe um sicherzugehen, dass es stimmt)

Also ich persönlich bevorzuge die Repräsentation, die dem am nächsten
ist, was tatsächlich mathematisch gemacht wird. Bei der man direkt
erkennen kann, was passiert.

Gruß,
Johannes

--
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

 

[Wolfgang Allinger]

On 17 Oct 19 at group /de/sci/electronics in article h0qlf2Fc2g4U1@mid.individual.net
<peter.heitzer@rz.uni-regensburg.de> (Peter Heitzer) wrote:

Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:
On 16.10.19 19:04, Guido Grohmann wrote:
Ralph Aichinger schrieb:
Dave U. Random <random@dave.u> wrote:
Dieses Video visualisiert schoen die populaersten Programmiersprachen

Programmierende Schweine sind selten.

Ja, aber manche Programme sehen trotzdem saumäßig aus.

Fairerweise muss man dazusagen, dass das in jeder Programmiersprache geht


Python hat ja das interessante Feature (manche Leute hassen es
unheimlich) dass Einrückung ein syntaktisches Element ist. Ich finde das
ganz gut, weil es wirklich dazu zwingt, korrekt einzurücken. Aber hilft
auch nicht, man kann auch in Python C programmieren
Hilfreich für Obfuscation ist hier die Verwendung von lambda, möglichst
geschachtelt ;-)

Und in FORTH lustige Stackturnereien, gewürzt mit ROT -ROT PICK n ROLL
TUCK UNDER dazwischen noch R! R@ RDUP RSWAP RDROP.

Ich hab so erfolgreich mal EPROM Kopierer ausgebootet zusammen mit einem
DALLAS Key in TO92 Gehäuse. Der war im Schaltplan und Stückliste als BC237
aufgeführt. Ich hab da die Kennung abgeschliffen. Heute würde ich sowas
als SMD ohne Bezeichnung einbauen.

Der Kunde wollte die Entwicklung nicht bezahlen, sondern nur per
(weiterverkaufter) Karte von mir. Er hat dann 1, danach 10 gekauft und
dann kam nix mehr

Der Kunde hat dann die Boards schlau wie er war bei Phytec geordert, den
BC237 eingelötet, EPROM kopiert ausgeliefert und sich über die sporadische
Meldung 'EPROM-Fehler, CPU angehalten' "gewundert". Er hat dann wochenlang
per LA, ICE und was weis ich nicht noch alles rumgedoktert, aber die
Routine nicht gefunden und schon garnicht flachlegen können. Was für ein
Pech!

Direkt nach dem RESET wurde der Key obfusciert eingelesen, ne 20 zeilige
Stackturnerei damit gemacht, so umme 100 Werte auffem Stack hinterlassen
und dann nach der kompletten HW Initialisierung wurde die richtige Info
auf dem Stack umgerührt, rausgepuhlt (ich wusste ja, wo die steht), der
Stack bereinigt, eine Zufallszahl erzeugt und in der 1ms Tickerroutine
nach runterzählen der Zahl der R-Stack manipuliert und der EPROM Fehler
angezeigt oder auch mal gnädig zufällig übergangen.

Ich hab dann den Auftrag bekommen, 20(?) seiner Boards gegen flockige
Kohle zu ertüchtigen und dann hat nur noch bei mir bestellt. Endkunde war
wohl BMW und Audi, die werden ihm mächtig Druck gemacht haben.

Man sieht, es gibt Schweine als Kunden und noch grössere Schweine als
Entwickler

Wenn das noch nicht genug ist, dann kann man auch Worte umtaufen.


Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Wolfgang Allinger]

On 17 Oct 19 at group /de/sci/electronics in article qo959d$aj4$1@news.albasani.net
<roland.franzius@uos.de> (Roland Franzius) wrote:

Am 16.10.2019 um 17:11 schrieb Hans-Juergen Schneider:

Mit dieser umgekehrten polnischen Notation mag sich auch niemand so
richtig anfreunden.
Aber das hat es tatsächlich gegeben.



Es gibt im Wesentlichen zwei verschiedene Paradigmen der Betrachtung von
maschineller Datenverarbeitung. Das übeliche ist eine Maschine, die wie
die staatliche Verwaltung funktioniert, sie wird mit Daten gefüttert und
produziert handlungsanweisenden Output für Geräte und Leute, die von der
Materie keine Ahnung haben.

ACK

Dagegen steht das physikalisch-biologistische Paradigma, eine Gruppe von
Automaten, die durch einen Datenurwald turnt und dabei sowohl eine Spur
geordneter Daten wie auch eine Verbesserung ihrer eigenen
Existenzgrundlage produziert.

Die umgekehrte polnische Notation simplifziert die Dinge dadurch, dass
das Funktionsmodell den Programmierer zwingt alle Daten herbeizuschaffen
und geordnet bereitzulegen, bevor eine Funktion zur Ausführung kommt.

Dieser Programmierstil beseitigt die Notwendigkeit, für alles und jedes
erstmal einen Namen zu erfinden, obwohl das Datum nur oder zweimal
verwendet wird.

Auf der anderen Seite verunmöglicht die Nichtverwendung von Namen für
nicht dauerhaft benötigte Funktionen und Variablen in Programmen die
Erkennung das Denkmodells dahinter.

Wegen der Monopolisierung alles und jedes Programmiermodells bis
herunter zu Einzeilern im hyperkapitalistischen Politikmodell sind auch
alle anderen Programmentwickler auf kryptische Zeichenketten als
Bezeichner umgestiegen.

FORTH, Mathematica und andere vereinfachen diesen Ansatz in das Extrem,
dass das assemblierte Programm oder ein Hash davon selbst als sein
Aufrufname dienen kann und wenn ad hoc als anonyme Daten oder Programme
auf dem Stack eingesetzt nach Ausführung automatisch verschwinden.

Zufällig gestern in Wikipedia nachgeschlagen, die Vorgehensweise der
kompletten Isolation der BIOS-Entwickler von der Produktionsabteilung
und dieser vom Rest der Welt bei Phoenix zur Vermeidung von
Patentrechtsstreitigkeiten mit IBM etc in den 1980ern:

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

Danke für Deinen tollen Beitrag.



Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Wolfgang Allinger]

On 17 Oct 19 at group /de/sci/electronics in article qo976r$u91$1@news2.open-news-network.org
<dfnsonfsduifb@gmx.de> (Johannes Bauer) wrote:

On 16.10.19 23:45, Ewald Pfau wrote:
Johannes Bauer <dfnsonfsduifb@gmx.de>:

Erstens: "Riad". Zweitens: bei so einem großen Claim ("komplett in
Forth") sollte sich doch ein Beleg auftreiben lassen, oder? Neh, wenn
ich suche nach "riyadh airport forth" sagt mir Google, dass er "Forth"
aus der Suche weggelassen hat, weil da nichts kommt.

Es geht um die Gepäckabfertigung. Forth.com waren einmal mächtig stolz auf
den Auftrag, ist aber schon eine Zeitlang her. Google ist kein
Archivmedium, es tut nur so.

Das stimmt natürlich, aber wenn man gar keine Hits findet, ist es schon
so ein Indiz dass man sich entweder vertippt hat, falsch errinert, ewig
her war oder verboten ist

Finde doch eine Erwähnung, Kapitel 3.3.1 in

https://www.forth.com/resources/forth-programming-language/

Perfekt, vielen Dank!

Die Fußnote, die ich nachgeschlagen habe: "Fifteen Programmers, 400
Computers, 36000 Sensors and FORTH". D.h. schon vom Titel wird klar,
dass Wolfgang um den Faktor 10 übertrieben hat mit den angeblichen 4000
Computern, aber sei's drum.

Wenn ich wie Du wäre, würde ich jetzt sagen, das mit dem Faktor 10 war ein
bait um Dich anzulocken. Aber ich bin ich, und es war halt nur ein Fehler
von mir ))

Interessant ist der Inhalt nämlich allemal, aber das ganze ist jetzt
eben schon 35 Jahre her. Mit 8 PDP-11s und ~400 8086ern haben sie das
System aufgebaut. Der Prototyp lief unter FORTRAN und Assembler und
wurde wohl von der Forth-Variante in Performance geschlagen.

Sowas, genau sowas, finde ich superspannend. Weil intuitiv sollte man ja
annehmen, dass die mindestens dieselbe Performance erreichen könnten,
insbesondere da die auf Asm zurückgreifen können. Das Paper ist auch
ehrlich und dokumentiert, warum das so war: "the prototype software
developed under RSX fell far short of meeting the performance
requirements in the system [...] At the 8086 level, the lack of full
multi-tasking in the RMX environment led to both performance problems
and excessively elaborate code [...]"

Das finde ich deswegen spannend, weil genau die Tatsache, also dass
kooperatives Multitasking mit Coroutinen (so verstehe ich Forth
zumindest) eben in den letzten Jahren "neu erfunden" wurde,

Kooperatives Multitasking (z.B. in F-PC) hatte ich auch schon mehrfach
erwähnt. Auch das ich den Multitasker verbessert habe und -entgegen allen
Gurus- sogar ABORT-fest gemacht habe.

Will heissen, das in jeder beliebigen Task zB. ein ABORT" aufgerufen
werden kann, ohne das ganze Mutlitaking flachzulegen. Geht sehr elegant
und mit wenig briborium.

task1:

blubber
blafasel ABORT" blafasel gibt keinen Wert zurück" \ shit happens
blub

Noch besser ich hab ABORT" nicht hinten drangefummelt, sondern an den
Anfang der n. Zeile, dann findet man die schnell im Listing, auch wenns
nicht den allg. Formatierungs Richtlinen entspricht. In Forth hat man die
Freiheit

task2:

blubber
blafasel
ABORT" blafasel gibt keinen Wert zurück" \ shit happens
blub

Das QUIT (genereller Abbruch in Forth) hab ich dann auch so umgefummelt,
dass es meldete, welche Task ABORT" throwed, samt opt. Stackdump... und
QUIT... hat dann auch noch die Stacks der betreffenden Tasks gelöscht.

Die Mainloop und/oder der Operator konnte dann entscheiden, ob er die
Task_X neu startet (einfach "Task_X <CR>") eingeben und ab ging die Luzie.

Fehlerbehandlung in Forth ist auch sehr elegant: CATCH THROW Konzept.

nennt sich
denn asynchrone Programmierung oder asyncio. Das war lange in den
Programmierparadigmen der typischen Hochsprachen (Fortran/C/etc) gar
nicht vorhanden, und ist dann über die Skriptsprachen jetzt mittlerweile
wieder reingewandert in klassische Hochsprachen.

Na siehste wohl, Forth kann das schon seeeehr lange

Der Grund: Viel höhere Performance verglichen mit klassischen
leichtgewichtigen Threads. Fand ich auch schwer zu glauben,
ehrlichgesagt (weil eigentlich müsste das auch ja derselbe Overhead
sein), die Messungen lügen aber nicht und das wird von dem 1985er Paper
ja auch festgestellt.

Tja auch die Hinweise darauf von mir haste auch nicht kapiert. War so
schön gemütlich auf Mount Stupid.

wahrscheinlich aussortiert, weil wirklich schon älter, die Fundstelle hat
einen Literaturverweis auf 1985, muss mächtig lustig gewesen sein, damals,
für das gesamte Team - Verweis auf Rather, E.D., ?Fifteen Programmers, 400
Computers, 36,000 Sensors and Forth,? Journal of Forth Application and
Research (3, #2, 1985).

Daher habe ich ihn:

http://soton.mpeforth.com/flag/jfar/vol3/no2/article4.pdf

Sehr schönes Paper, sollte man aufheben.

Aber ja, ich nehme an, das ist nicht mehr in Betrieb, würde mich sehr
wundern wenn in Riad noch PDP-11s und 8086er im Rechenzentrum stehen.

Örks hattest Du mich nicht gerade angepisst wg. "Riad" Tztztz
Tja, einmal Arschloch, immer Arschloch (krummbohrtes)

Forth.com ist eine nicht ganz so kleine Firma, mit belastbarereren
Realitätshorizont, vielleicht dort die Liste der Applikationen
frequentieren anstatt hier über das Zeitgeistige in der Zeitgeistigkeit zu
lamentieren:

https://www.forth.com/resources/forth-apps/

Auch spannend. Klingt aber eben eher nach Spezialapplikationen, wie
Wolfgang sie auch aufgezählt hat: Satelliten, Roboterarm vom
Spaceshuttle, Waffensysteme.

Ist ja auch nicht schlimm, für jeden Topf gibts ja einen Deckel. Aber so
zu tun als sei Forth das, was heute noch federführend für
Embedded-Applikationen eingesetzt wird, ist einfach unwahr.

Nunja, wenn man oben auf Mount Stupid ist, weiss man eben nicht, was man
nicht weiss. Irgendwann stellt man dann fest, dass Forth das alles schon
kannte, sh. RAPID-Prototyping, Interactive-Programming, Kooperatives
Multitasking, Parameter und Return Stack getrennt, Agiles Programming

Achso, wenn ein Openboot nicht bei Ieee weitergeführt wird, kann es
trotzdem in Verwendung sein. Wenn ein Rechner nicht bootet wie er soll,
kann es sein, dass man damit Bekanntschaft macht, so kürzlich auf einem
I7-Laptop, der bestimmt jünger ist als 20 Jahre. Entsinne mich dunkel, dass
es aktuell eine Opensource-Gruppe für das Openboot gibt, müsste man aber
suchen, wo die sich herumtreibt.

Bist du dir wirklich sicher, auf dem i7, dass das Forth war? Es gibt ja
die UEFI-Varianten die einen Interpreter haben, der etwas ähnliches
emuliert, aber die sind m.W.n. nicht in Forth implementiert (sondern
geben dir nur eine interaktive "Shell", die so ähnlich aussieht). Aber
ja, macht man immer mit Bekanntschaft, wenn beim Installieren des
Bootloaders was schiefgegangen ist

Ich mach schon lang nichts mehr damit, von daher hab ich aus den Augen
verloren, ob es sonstwo da oder dort solche Listen gibt.

Vielen Dank jedenfalls für die Referenzen und unaufgeregte Diskussion.
Es geht ja auch gar nicht darum, wer wieviel wo hat, sondern ich finde
eher die Frage spannend warum das besser war, in welches Aspekten und
was man darauf lernen kann um z.B. gute Performance auch in anderen
Systemen zu erreichen.

Nun ja, Chuck Moore (Erfinder von Forth) und -wie ich- KISS Fanboy
-----8x---


Ein Grundprinzip leitete die Entwicklung von Forth
und leitet weiterhin die Anwendungen damit,
schlichtweg:

Halte es einfach ( Keep it Simple )

Eine einfache Lösung ist elegant.

Die elegante Lösung ist das Ergebnis einer gründlichen Anstrengung,
das wirkliche Problem zu verstehen
und überzeugt durch das beeindruckende Gefühl der Richtigkeit.

Ich betone diesen Punkt besonders,
weil er im Gegensatz zu vorherrschenden Meinung steht,
die Leistungsfähigkeit steige mit der Kompliziertheit an.

Einfachheit erzeugt
Vertrauen,
Zuverlässigkeit,
Überschaubarkeit,
und
Schnelligkeit.

Chuck Moore auf der Forth Conference UofR 1990
Übersetzt: (C) 1993 by Dipl.-Ing. Wolfgang Allinger

-----x8---
Nuff Said

Ausser das Chuck ein sehr liebenswerter, ruhiger und bescheidener Mann
ist. Dem oft und übel mitgespielt wurde.

Ich jedoch halte nix von andere Backe hinhalten, bin halt nicht so ein
Genie wie Chuck






Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Hans-Peter Diettrich]

Am 17.10.2019 um 14:21 schrieb Johannes Bauer:

Du wirst ja wohl nicht allen Ernstes behaupten wollen, dass man das
Abstraktionsniveau möglichst niedrig ansetzen sollte, damit man eine
geringere Programmierfehlerquote erreicht? Ich vermute, exakt das
Gegenteil ist der Fall. Denn Numerik, Datentypen, Über- und Unterläufe
muss man auch in einer niedrigeren Abstraktion berücksichtigen.

Ach so, Du verwendest auch noch einen Interpreter, der sich um die
richtigen Datentypen kümmert - so gut er das eben kann?

Vermutlich hast Du dann auch noch nicht verstanden, daß es neben den
tatsächlichen Programmierfehlern auch noch Fehler in der Numerik gibt,
die zu unerwartet falschen oder unterschiedlichen Ergebnissen führen, je
nachdem welchen Compiler und Optimierungslevel man benutzt.

Aber
obendrauf kommt dann halt noch krude, umständliche Syntax (z.B. direkt
Assembler-Code oder RPN) die eben nicht direkt das widerspegelt, was ich
machen will.

Von wegen umständlich siehe unten :-]

Beispiel:

y = a x^2 + bx + c

Sofort offensichtlich, was das ist.

Inklusive der vergessenen Operatoren :-(
Oder soll bx eine weitere Variable sein? :-]

Das ist doch genau das was ich oben meinte, mit schlampigem Denken und
schlampiger Schreibweise, was zu schlampigen Programmen führt :-(

[...]
Aus Deinem Asseblercode werde ich nicht schlau, da fehlen mir die
Parameter, die Du freunlicherweise weggelassen hast. Der 80x87 ließ sich
jedenfalls direkt mit UPN programmieren, das ist nun mal das
natürlichste Rechenverfahren.

Oder eben

x x mul a mul b x mul c add add

(Das ich dreimal angeschaut habe um sicherzugehen, dass es stimmt)

Übersichtlicher:
a x dup * + b x * + c +
oder
a x * b + x * c +
auch bekannt als Horner-Schema
oder
x a over * b + * c +
mit jeweils nur einem Speicherzugriff auf die Variablen.

Also ich persönlich bevorzuge die Repräsentation, die dem am nächsten
ist, was tatsächlich mathematisch gemacht wird.

Und das ist eindeutig UPN. Woher soll man denn vorher wissen, welche der
von mir aufgezählten Varianten Dein Lieblingscompiler erzeugt? Und was
mathematisch eindeutig aussieht, muß nicht unbedingt eindeutig sein. Die
Mathematik kennt Kommutativität und Assoziativität, die mathematisch
immer identische Ergebnisse liefern, numerisch aber dummerweise nicht.

> Bei der man direkt erkennen kann, was passiert.

Das ist was anderes, da kommt Gewohnheit ins Spiel. Und in diesem
Beitrag erkenne ich etliche schlechte Gewohnheiten :-(

DoDi

 

[Johannes Bauer]

On 17.10.19 14:52, Wolfgang Allinger wrote:

Die Fußnote, die ich nachgeschlagen habe: "Fifteen Programmers, 400
Computers, 36000 Sensors and FORTH". D.h. schon vom Titel wird klar,
dass Wolfgang um den Faktor 10 Ăźbertrieben hat mit den angeblichen 4000
Computern, aber sei's drum.

Wenn ich wie Du wäre,

dann wĂźrdest du Belege zu Behauptungen anfĂźhren, statt einfach nur
Geschichten zu erfinden.

nennt sich
denn asynchrone Programmierung oder asyncio. Das war lange in den
Programmierparadigmen der typischen Hochsprachen (Fortran/C/etc) gar
nicht vorhanden, und ist dann Ăźber die Skriptsprachen jetzt mittlerweile
wieder reingewandert in klassische Hochsprachen.

Na siehste wohl, Forth kann das schon seeeehr lange

Und habe ich nie angezweifelt. Wohl aber deine dubiosen Geschichten, die
sich alle als erfunden oder gelogen rausstellen. Wer hätte es gedacht?
Ach ja stimmt, jeder hätte es gedacht.

Der Grund: Viel hĂśhere Performance verglichen mit klassischen
leichtgewichtigen Threads. Fand ich auch schwer zu glauben,
ehrlichgesagt (weil eigentlich mĂźsste das auch ja derselbe Overhead
sein), die Messungen lĂźgen aber nicht und das wird von dem 1985er Paper
ja auch festgestellt.

Tja auch die Hinweise darauf von mir haste auch nicht kapiert.

Ich weiß nicht wie du auf den Trichter kommst, ich hätte das geleugnet.
Das Gegenteil ist der Fall.

Du lässt einfach immer gezielt alle die Information weg, bei der du als
dreister LĂźgner entlarvt wirst und versuchst, anderen Leuten irgendwas
in den Mund zu legen. Absolut unredlich.

Wo sind denn die Datenblätter zu den Forth SPSen? Lego Mindstorms?
Cryptokarten? Die hattest du bequemerweise vergessen. Ich hol schonmal
Popcorn, während du die raussuchst.

Aber ja, ich nehme an, das ist nicht mehr in Betrieb, wĂźrde mich sehr
wundern wenn in Riad noch PDP-11s und 8086er im Rechenzentrum stehen.

Örks hattest Du mich nicht gerade angepisst wg. "Riad" Tztztz

Hä? "Riad" *ist* die korrekte Schreibweise. Oder wovon redest du? Du
hattest in deinem Posting von "Rihad" geschrieben, schon vergessen? Lies
es dir doch nochmal durch, Microprofessor.

bin halt nicht so ein
Genie wie Chuck

Endlich mal ein Punkt, in dem wir vollständig einer Meinung sind.
Vielleicht werden wir ja doch noch allerallerbeste Freunde!

Viele Grüße,
Johannes

--
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

 

[Johannes Bauer]

On 17.10.19 16:10, Hans-Peter Diettrich wrote:

Beispiel:

y = a x^2 + bx + c

Sofort offensichtlich, was das ist.

Inklusive der vergessenen Operatoren :-(

Ist das die erste mathematische Formel, die du in deinem Leben siehst?
Muss ich dir jetzt echt Nachhilfe in Sechtsklassmathe geben? Ohje, bei
dir fehlt's aber wirklich an Einigem.

Das ist doch genau das was ich oben meinte, mit schlampigem Denken und
schlampiger Schreibweise, was zu schlampigen Programmen führt :-(

Sage das doch den Mathematikern der Welt. Die verstehen, was ich meine.
Ich vermute stark, du stellst dich einfach nur dümmer als du bist (sonst
wäre das schon hochgradig bedenklich).

Aus Deinem Asseblercode werde ich nicht schlau,

Wundert mich nicht.

da fehlen mir die
Parameter,

Calling convention nachsehen, wenn du schlau werden willst.

> die Du freunlicherweise weggelassen hast. Der 80x87

Wird nicht mehr verwendet, wenn man Gleitpunktoperationen haben will,
die performen.

x x mul a mul b x mul c add add

(Das ich dreimal angeschaut habe um sicherzugehen, dass es stimmt)

Übersichtlicher:
  a x dup * + b x * + c +
oder
  a x * b + x * c +
auch bekannt als Horner-Schema
oder
  x a over * b + * c +
mit jeweils nur einem Speicherzugriff auf die Variablen.

Äh wie du's drehst und wendest, ich finde es nicht übersichtlich,
sondern einfach nur furchtbar. Egal welche Variante von den dreien.

Also ich persönlich bevorzuge die Repräsentation, die dem am nächsten
ist, was tatsächlich mathematisch gemacht wird.

Und das ist eindeutig UPN.

#1: y = a x^2 + bx + c
#2: y = a * sqr(x) + b * x + c;
#3: x a over * b + * c +

Und du behauptest, #1 und #3 sind ähnlicher als #1 und #2? Hälst du dir
die Augen zu und singst laut "lalalala", damit du die Realität nicht
wahrnehmen musst? Das ist echt absurd.

Woher soll man denn vorher wissen, welche der
von mir aufgezählten Varianten Dein Lieblingscompiler erzeugt? Und was
mathematisch eindeutig aussieht, muß nicht unbedingt eindeutig sein. Die
Mathematik kennt Kommutativität und Assoziativität, die mathematisch
immer identische Ergebnisse liefern, numerisch aber dummerweise nicht.

Gacker!

Ja, alles Probleme, die sich in Hochsprachen überhaupt nicht in den
Griff kriegen lassen, weil man natürlich KEINERLEI Einfluß auf die
Operatorenreihenfolge hat. Klammern und so gibts da ja nicht, gell. Das
geht nur mit UPN, eindeutig.

Jungejunge, du bist wirklich ABSURD ahnungslos und ignorant. Das ist
echt schon nicht mehr witzig, sondern einfach nur verblüffend.

Bei der man direkt erkennen kann, was passiert.

Das ist was anderes, da kommt Gewohnheit ins Spiel. Und in diesem
Beitrag erkenne ich etliche schlechte Gewohnheiten :-(

Weißt du was ne richtig schlechte Angewohnheit ist? Im Usenet Lügen zu
erzählen. Zum Beispiel hattest du mir doch versprochen, mich in deinem
Killfile "schmoren" zu lassen. Offenbar war das aber gelogen.

Lieber DoDi, kannst du mir bitte einen großen Gefallen tun und mich da
wieder aufnehmen? Ich fände es echt cool wenn du deine bizarren
Absurditäten für dich behalten würdest, weil du von mir weniger mit der
Realität konfrontiert wirst.

Vielen Dank im Voraus,
Alles Liebe,
Johannes

--
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

 

[Johannes Bauer]

On 17.10.19 16:10, Hans-Peter Diettrich wrote:

Oder eben

x x mul a mul b x mul c add add

(Das ich dreimal angeschaut habe um sicherzugehen, dass es stimmt)

Übersichtlicher:
  a x dup * + b x * + c +

Ahahaha, ist mir gerade erst aufgefallen! Dann schauen wir doch mal:

a x dup * + b x * + c +

a x x * + b x * + c +

a x2 + b x * + c +

Ist also:

(a + x˛) + bx + c

Gefordert war aber

a * x˛ + bx + c

Geil! Schöner hätte ich nicht beweisen können, dass UPN eben Grütze ist.

Äh, ich wollte sagen, "übersichtlicher".

Danke dir,
Johannes

--
"Performance ist nicht das Problem, es läuft ja nachher beides auf der
selben Hardware." -- Hans-Peter Diettrich in d.s.e.

 

[Wolfgang Allinger]

On 17 Oct 19 at group /de/sci/electronics in article slrnqqgjnc.7aq5.ak-9a@chimborazo.ee.ethz.ch
<ak-9a@gmx.ch> (Andreas Karrer) wrote:

* Wolfgang Allinger <all2001@spambog.com>:

keine Sorge, UPN|RPN gibbet immer noch. Und wers kapiert hat, will nix
anderes mehr.

Achwas. Ich weiss sehr genau, was UPN ist, und ich will anderes.

HP kam nicht UPN, weil das so supertoll ist, sondern weil der
HP9100 zu limitiert war, um algebraisches Format zu können.

Der HP 9100A war ein programmierbarer Tischrechner mit
"Tastencode"-Programmierung, der so ziemlich alles, was später in den
HP-Taschenrechnern verbraten wurde, schon konnte. Und zwar 1968, ohne
LED, ohne ICs (und damit ohne RAM und ROM im heutigen Sinn). Ohne HP
9100 kein HP-35.

BTDT. War ganz lustig, die Gehirnwindungen so zu verdrehen, dass sie
dem Rechner passten. Der HP 9100B, den wir am Gymnasium hatten,
existiert noch, und ich habe ihn vor ein paar Jahren mal ausgeliehen,
ein paar Kontakte gereinigt, spröde Gummiteile und Lämpchen ersetzt
-- funktionierte wie am ersten Tag.

Und nachher nie wieder UPN. Denn in der Zwischenzeit hat man begriffen, dass
Computer leistungsfähig genug sind, dass sie sich den Gehirnwindungen
der Menschen anpassen können und nicht umgekehrt. Beispielsweise macht
ein typischer Compiler für höhere Programmiersprachen bei der
Berechnung von algebraischen Ausdrücken genau das: er konvertiert
algebraische Notation in Stack-Arithmetik. Er bildet Terme, wirft sie
auf den Stack, bildet Summen der Top-of-Stack-Elemente usw.

Schön, wenn der Computer das kann, ich kanns auch und finde es einfacher
(für mich)



Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

 

[Wolfgang Allinger]

On 14 Oct 19 at group /de/sci/electronics in article 20191014204208.N8fXmWIcOllQ@sewer.dizum.com
<random@dave.u> (Dave U. Random) wrote:

Dieses Video visualisiert schoen die populaersten Programmiersprachen der
letzten 50 Jahre. Forth ist nicht einmal unter ferner liefen.
https://www.youtube.com/watch?v=Og847HVwRSI

Hier noch was für FORTH Kennenlernmöchter:

https://learnxinyminutes.com/docs/forth/

https://users.ece.cmu.edu/~koopman/forth/hopl.html



Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

--
Ich bin in Paraguay lebender Trollallergiker reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung!
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot