beim koreanischlernen bin ich nun wieder so weit mich mit der formung von zeiten zu beschäftigen. dabei ist mir im vergleich an den allgemein im gebrauch befindlichen programmiersprachen ein mangel aufgefallen.
programmiersprachen haben kein zeit gefühl.
programmiersprachen sind wie das leben heute. “lebe jetzt!”. und natürlich ist das richtig. wir leben ja im jetzt und nehmen immer auch nur das jetzt wahr. jedenfalls was äußere inputs und schnittstellen betrifft. ähnlich reagiert ein computer auf interrupts, deren auswirkung von einem stück software unmittelbar analysiert und verarbeitet wird. ein interrupt unterbricht die im gange befindlichen vorgänge und startet je nach art eine bestimmte funktion.
und da hat der mensch doch mehr als nur das unmittelbar spürbare als quelle der wahrnehmung. wir können uns vorstellen, wie zukünftige ereignisse aussehen mögen und welche inputs sie für uns haben werden. für die beispielswiese stellen wir uns vor, heute abend california-maki zu essen. und schon verspüren wir vom input-device - zunge - kommend wie die avokado zwischen zunge und gaumen schmilzt und sich der geschmack von wasabi mit dem von grabbenfleisch mischt. wir haben eine vorstellung davon. und wir können diese sprachlich ausdrücken. “wenn ich heute abend maki esse werde ich es genießen”.
aber warum essen wir maki? warum streben wir nach dem genuß? weil wir wissen, daß wir schon einmal maki gegessen haben, und wir sie damals genossen haben. oder weil uns jemand den selben genuß schmackhaft gemacht hat, falls wir zum ersten mal nach den reisrollen greifen wollen. wir haben also einen speicher, der inputs liefert
unsere sprachlichen zeitausdrucksweisen sind also sprachliche funktionen die mit unserem speicherzugriff zusammenhängen.
“weil maki gut sind, esse ich sie wieder”
man ruft also eine erfahrung ab, und setzt sie als verzweigungs-parameter ein, wobei die verzweigung in diesem fall eine erwartung erzeugt. um den satz einfacher analysieren zu können ändern wir ihn ab.
“maki waren gut, daher esse ich sie in zukunft wieder”
als programm hätten wir hier vielleicht ein wurzel-objekt maki mit vielen erbenden objekten wie temaki, california-maki, kimbap, etc. , mit denen wir nicht nur die bestandteile sondern auch eine güte verbinden. ein interface zu dem objekt ist vielleicht die funktion forstellung (geschmack), die einen wert “sehr gut” zurückliefert. dabei ist das objekt an eine datenbank angebunden und speichert updates dahin und holt den wert von dort (gedächtnis). eine instanz von california-maki ist mit sicherheit die unseres lieblings-japaners.
in meinem fall gibt es z.b. zwei japanische lokale in wien, die tempura-maki machen. beide sind hervorragend. und beide finden sich so in der datenbank und können auch abgefragt werden.
das bedeutet im falle, daß ich tempura-maki und california-maki essen möchte, kann ich also abwägen welches lokal ich auswähle, indem ich die bewertung der maki, mit den preisen und der anheimlichkeit der lokale abrufe, und abwäge.
aber auch hier haben wir vl. ein problem. vl. variiert die qualität der maki und sie waren einmal gut und ein anderes mal nicht ganz so gut.
wenn ich also die frage stelle “wie waren die maki?” so muß ich über statistische aufzeichnungen je objek-instanz scannen und diese auch miteinbeziehen.
man kann das beispiel noch weiter verzweigen, was aber auffällt ist, daß wir immer erst die vergangenheit aufbereiten müssen, wenn wir eine entscheidung treffen wollen, um für die zukunft eine erwartung zu erzeugen - etwas anzustreben. dann müssen wir den event abwarten um den erzeugten datensatz auszuwerten und die objekt-funktionen mit neuen werten zu füttern. das tun wir aber immer in der gegenwart.
unser gehirn funktioniert anders
in unserem kopf spielt sich aber etwas anderes ab. wir kalkulieren voraus und bestätigen nur die ergebnisse, oder tunen die erwarteten ergebnisse mit dem tatsächlichen input nach. bis zum eintreten des events haben wir also unsere erinnerung an die maki als unbestätigtes ergebnis des events im hinterkopf. wir haben also ein ergebnis, ehe der event eintritt. ein erebnis mit dem wir arbeiten.
“was gehst du heute essen?”
“ich werde die besten tempura-maki wiens essen!”
“na gut, da komme ich mit!”
ein noch nicht einmal vorhandenes ergebnis kann als entscheidungsinput für andere menschen herhalten. unsere aufbereite erinnerung kann aber noch mehr.
wir könne uns z.b. eine vorstellung davon machen, wie es schmecken wird makis, satt wie bisher gewohnt in kikko-dings-sojasauce in austernsauce mit zitronensaft zu tauchen.
unsere sprache funktioniert anders
unser denken und damit unsere sprache kennt also vergangenheit und zukunft, erinnerung und erwartung.
“die maki waren gut, sie werden wieder gut sein”
“die maki waren gut, sie werden mit zitronen-austernsauce anders gut sein”
programmiersprachen, die immer einen datensatz importieren müssen um ihn einer verarbeitung zuzuführen, lesen sich da eher:
“wie waren die maki? das ergebnis sagt maki sind gut. Wie werden die maki sein? warten ….. neue funktion anwenden, maki sind gut, das merk ich mir.”
was programmiersprachen brauchen
programmiersprachen benötigen eine art gefiltertes gedächtnis, und die fähigkeit darauf aufbauend voraussagen zu tätigen und das eintreffen abzuprüfen, zu analysieren und einfluß auf das programm selbst nehmen zu lassen.
wie?
ich schlage daher vor programmiersprachen mit den befehlen expect und remember auszustatten. diese sollten schatten-instanzen von objekten erzeugen, deren zustand im fall des eintreffen eines events bestätigt oder getuned werden können sollten.
man kann diese als erbende instanz des eigentlichen objekts betrachten. ihre objekt-hauptfunktion würde in der verarbeitung von vergangenen objekt-eigenschaften bestehen. remember-objekte sollten analyse-funktionen von rein statistischer auswertung über trendanalysen bis zu fuzzy-logic funktionen umfassen.
expect-instanzen sollten die vergangeheit des original-objekts auswerten und den programmcode neuschreiben können. warum? als input zur erzeugung eines neugeschriebenen objekts sollten neue funktionen die dem tunen der ergebnisse dienen können mitverarbeiten können. fließt dem expect-object eine neue erfahrung zu sollte soz. die statistische abweichung für zukünftige abfragen bereitstehen.
hat jemand maki nur so gegessen, aber noch nie in sauce gedippt, könnte bei einem expect(ed)-object natürlich nicht miteinbezogen werden, wie das dann schmeckt. ißt man sie dann zum ersten mal mit sojasauce so revidiert man die vorstellung der maki und fügt die funktion in_soja_dunken(dauer) hinzu, die dem objekt maki einen zusätzlichen inhaltsstoff hinzufügt.
hier liegt wohl eine der größten herausforderungen, den unterschied zum ursprünglichen expect-objekt festzustellen und diesen in den quellcode einfließen zu lassen.
vl würde es reichen eine funktion hinzuzufügen, die das ergebnis in der gleichen form abwandelt, wie zu dem zeitstempel des letzten ergebnisses. damit könnten sowohl remember-objekte als auch expect-objekte bei der erstellung 2 oder mehr ergebnis-pfade bereitstellen, solche in denen große abweichungen bedacht werden, und solche wo minimale abweichungen - vl. auch nur die zum negativen oder positiven - außer acht gelassen werden können. fuzzzzzzy!
gleichzeitig sollten expect-ojekte eine zeitlich begrenzbare lebensdauer haben, da mache erwartungen nie eintreffen. dazu ist eine ständige überwachung erforderlich, die die erwartung mit einem zeitstempel versieht, eine deadline beobachtet und das objekt evtl. zerstört.
genug philosofiert!
