OV reloaded - érteni vélem végre...

Kedves G!

Köszönöm a választ, és a személyes találkozás felvetését is - részemről semmi akadálya. Kérdés viszont, hogy érdemes-e.

Ami miatt részemről igen: gyakorlatilag ti vagytok az egyetlen lehetőség arra, hogy ez a mostani, diktatúra felé forduló történet a legutolsó (következésképpen az éppen megfelelő) pillanatban irányt váltson. 

 - Elég lelkesedés van bennetek, elveket tekintetek fontosnak múltbeli történetek emlegetése helyett, és egyértelműen elhatárolódtok minden politikai ráépüléstől, vagyis nem egy szerintem összeomló rendszeren belül kerestek megoldást.

 - Megfelelő időben jelentetek meg a palettán, a diktatúra már célegyenesbe fordult, de még nincs meg az a kétségbeesés, amely végül oda is kergeti a tömeget. Ez azonban nincs messze, még ahhoz is optimistának kell lennem, hogy "egy éven belül" várjam az államcsődöt - eszerint ti vagytok az utolsó, még értékelhető, média felülethez jutó fellángolás.

Ami miatt kevésbé:

Leveledben is következményeket emlegetsz okok helyett, ahogy az egész kampány ezekre épül jelenleg. Az én felvetésem egyszerű. Kiindulhattok abból, hogy Orbán Viktor hülye, ez kényelmes és egyszerű megoldás; jöhettek azzal, hogy kitaláljátok az egyébként triviális "követeléseket", tömeget szerveztek és jól megbuktatjátok. Magyarul: "rendszerváltás 2.0". Na és? Nem ez a kérdés, hanem az, hogy a "rendszerváltás 1.0", benne a hozzátok teljesen hasonló fiatal Orbán Viktorral, miért és hogyan fordult a mai kiépülő diktatúrává.

Nem fogadom el azt a könnyű választ, hogy "Orbán Viktor meghülyült". Akár csak a személyes szakmai tapasztalatom alapján is állíthatom: kibicnek könnyű. Természetesen lehet megvalósíthatatlan specifikációt teljes mellszélességgel követelni akár egy számítógépes rendszer, akár egy állam esetén. Szerintetek az az idióta, akinek le kell programoznia, vagy meg kell valósítania - és láthatóan nem sikerül neki. Ezt sokáig én is így gondoltam, ma viszont úgy látom, hogy a vezérlőfülkében Orbán Viktor találkozott a valósággal: a világ jelenlegi gazdasági-politikai helyzetével, és a magyar emberek szellemi tunyaságával (ez persze világjelenség, de most erről az országról beszélünk). Kiindulhattok abból, hogy a Fidesz körül álló szakértők egytől egyig ostobák - mert ha nem, akkor azt kellene elfogadnotok, hogy az általatok megfogalmazható igények ismertek, csak az általatok nem látható körülmények miatt nem megvalósíthatók. Számomra logikusabbnak tűnik az utóbbi változat.

Egyre erősebb a meggyőződésem, hogy a jelenlegi folyamatok értelme a következő: a kocsinak nincs tapadása, sodródik a szakadék felé vezető úton, a sofőr pedig egyetlen kiutat lát: letér az útról és a falnak vezeti az autót. Lefordítva: a gazdasági csőd nem egyedi, hanem világjelenség (egyébként általános iskolai matematikai ismeretekkel megérthető); ha hagyjuk, hogy a társadalmi szervezettségünket (amely egyébként az egyetlen "modern" tulajdonságunk jelenleg) szétverje, akkor elképzelhetetlen káoszba sodródunk. Ennél még egy diktatúra is jobb, ha az észhez térítés nem sikerül. Még azt is elhiszem, hogy Orbán Viktor ezzel teljesen őszintén próbálkozott, csak a messiás-váró tömeg zsibbadtsága és a végtelenül szűk látókörű elit önzése ellen tehetetlen volt. Azt is elhiszem, hogy az "ázsiai horda" szöveg nem öntömjénezés, hanem szomorúan elfogadott tapasztalat. Sokkal kisebb méretekben (vagyis minden hatalmi sallang nélkül, közvetlen kommunikációban) én is ugyanezt a következtetést voltam kénytelen levonni. 

Szóval, a Fidesz ellen acsarogni (már... ;-) ) nem vagyok hajlandó még akkor sem, ha a kiút egyetlen lehetőségét látom bennetek, mert az út szerintem nem arra vezet. Bőven eleget írtam az általam látott, és hitem szerint józan gondolkodással bárki által felfogható folyamatokról ahhoz, hogy azt mondjam: kérlek nézzetek rá ezekre, mondjuk innen kezdve: http://hajnalvilag.blogspot.hu/2012/03/jovo-erdeklodes-hianyaban-elmarad.html 

Ha erről szerintetek is van értelme beszélni, meg fogjuk tenni, ha nem, nem :-)

Mélyvíz, csak úszóknak!

Ezt az írást a Humán Platform blogjára szántam, ahol néma csend fogadta az előző bejegyzést. Miután megírtam, kaptam egy választ levélben, még pár dolgot végiggondoltam, és még inkább elfogadhatóvá vált számomra a Fidesz jelenlegi tevékenysége, amit itt még ostorozok. Vicces.

Sehol? Senki? Az elég nagy baj, bár sajnos nem meglepő. Azért pár gondolatot még hozzáteszek ehhez a monológhoz. Remélem ez volt az utolsó alkalom, amikor íráskényszerrel ébredtem.

Vicces, ahogy demokráciának nevezzük azt a rendszert, amelyben élünk. Vajon közületek hányan gondoltak bele abba, hogy egyéni szinten hogyan viszonyulunk a görög polisz-lakóhoz? Oké, azt könnyen lenyeljük, hogy a fizikai képességeink nevetségesek hozzájuk képest: az üldögélve vakarózás, fészbúkolás nem sok izmot fejleszt. De a gondolkodás? Persze ifjaink bizonyos (a nem puskázó "lúzer") része hősiesen megtanul egy rakás szabályt, amit akkor még nem tudtak - aztán vizsga után harmadnapra el is felejtik. De vajon hányan rendelkeznek tiszta képpel arról, mit nevezünk logikus gondolkodásnak? Következtetésnek? Megismerésnek? Képesek lennének saját kútfőből kitalálni azokat a törvényeket, belőlük összerakni, vagy akár csak érzékelni azt a bonyolult rendszert, amelyre ma egész világunk épül? Sokszor hangoztatott "fejlettségünk" sokkal inkább technikai infrastruktúránknak és az általa lehetővé vált szervezettségünknek köszönhető, mint egyéni, rohamosan csökkenő teljesítményünknek. Előbbiek objektív okokból egyre komolyabb veszélyben vannak, ez a valós gond, nem a gazdasági-politikai hőbörgés.

Elnézést, de annyira könnyű transzparensekkel szaladgálni, felelősökre mutogatni, lelkesen kiabálni, hősiesen "vállalni a következményeket"... Ugyan már, milyen következményeket? A "Nagy Előd", Orbán Viktor még joggal félhetett attól, hogy leesik néhány pofon, de már ennek sem volt semmi köze ahhoz, hogy pár évvel azelőtt tényleg félholtra verték a másként gondolkodót; családját, gyerekei jövőjét tette kockára a megszólalással, ESÉLY NÉLKÜL. Igen, erre haladunk ismét. Ángyán József már negyedmillió forint büntetéssel néz szembe azért, mert neki még egyszerre van szakértelme és lelkiismerete (igen, ő valóban követendő példát mutat). A "végeken" már valóban működik az ideológiai tisztogatás: civil szervezetek talpnyalókra cserélése, államigazgatás "igazodása", a hírek már egyirányúak, lassan az igazságszolgáltatás is a "fizető megrendelőhöz" idomul majd. Itt is vannak ma már esélytelen, névtelen hősök, akiket a többség "tipikus lúzernek" lát.

Aki nem tanul a történelemből, megismétli azt, ez jól látható Orbán Viktor és a Fidesz pályáján. A "Humán Platform" vajon milyen alapon hiszi, hogy megúszhatja ugyanezt? Ha nem tanul ebből a példából, csak megismételni lenne képes ugyanezt a történetet. Szerencsére esély sincs rá. Ha nem tud érdemi, tartalmi alternatívát felmutatni ez a társaság a következő fél év során, akkor már nem is kell sportolnia tovább. Rövid helyzetelemzés következik.

Eddig azért nincs államcsőd Magyarországon, mert a pénzvilág számára jól látszik: a kormány pont erre játszik! Valójában tőlük kaptunk egy kis haladékot az észhez térésre, MI, az "istenadta nép", a magát nem "kedves vezetőre áhítozó ázsiai hordaként" definiáló magyarság. Ha viszont Matolcsy úr és piros pöttyös fenekű barátai "beveszik" a Nemzeti Bankot, akkor tényleg reménytelenné válik, hogy Magyarország bármikor bármit visszafizessen. Persze a magán megtakarítások lenyúlásából történő kifizetéseket örömmel eltették - miért ne? A nemzetközi vállalatok, bankok megsarcolására már köhögnek, de még belefér az egyik zsebből másikba pakolás. Viszont ha már semmi mozdítható nem marad, akkor nem fognak magyar államkötvényt venni, ami a folyamatos hiány mellett kifejezetten rosszul veszi ki magát. Lehet nyomni az új óriásplakátokat az EU és a gonosz pénzvilág elleni hőbörgéssel. És lehet majd örülni az állami energiacégnek, mobilszolgáltatónak, médiának, közmunkának és Erzsébet-utalványnak (ami magyarul jegyrendszert jelent). Hamarosan kiderül, mennyire tévedek mindebben - de ha stimmel, akkor nem marad sok mozgástér az alternatív gondolatok számára.

Persze, el lehet menni. Ti viszont, "leendő értelmiség", csak másodhegedűsnek lesztek jók abban a Nyugat-Európában, amely évtizedekkel előttünk jár a bevándorlók EU-kompatibilis, kultúrált, de valahogy mégis a honfitársakat előtérbe helyező kezelésében. Ahogy azt itthon mi is helyesnek tartjuk. És igaza van Orbán Viktornak abban is, hogy ezzel szembesülve az értéktelenebb rész visszajön majd az ő országába, ostorpattogtatónak. Mert ahhoz pont ennyi kell: lelkesedés, nagy arc, hit a vezérszónokokban - továbbá az elemző, önkritikus gondolkodás hiánya. Ha a mai magyar "elittől" valóban csak ennyire telik, akkor jobban járunk egy kiteljesedő orbáni diktatúrával, mint a káosszal.

"Nyíltan a jövőnkről..."

Kedves "Humán Platform", és tüntető diákok!

Amikor ugyanezek a gondolatok a Milla (később nem meglepő módon visszhang nélküli bohózatba fulladó) alternatív elnöki kampányában kerültek elő, megpróbálkoztam néhány szerintem konstruktív gondolat felvetésével, amit most megismételnék.

Szerintetek a Fidesz, és az egyébként minden vereségtől, sőt a gyengeség legapróbb jelétől is irtózó vezetője nincs tisztában azzal, hogy a felvetett kérések teljesítése esetén mindenki aranyba foglalná a nevét, és biztos nyertes lenne a következő választáson? Ha a jelenlegi globális körülmények, és helyi emberi erőforrás lehetővé tenné, akkor bizonyára törekedne is mindezek megoldására. A tény, hogy nem ezt teszik, szerintem egyértelműen arra utal, hogy minden szép elképzelés ellenére ezek a kérések megvalósíthatatlanok. Logikus lépés tehát a "széles tömegek" teljesíthetetlen álmai helyett egy hatalmi szempontból meghatározó erejű, szűkebb kör igényeire koncentrálni, illetve ezt a kört helyzetbe hozni a többiek kiszorításával.

Egyáltalán nem véletlen, hogy annak idején a Fidesz ugyanilyen célokat tűzött maga elé, sőt, az ifjú Orbán Viktor bizonyára sikeres vezetője lenne a mai hallgatói tüntetéseknek - sajnos ezzel analóg módon az is borítékolható, hogy a mai megmozdulások vezéralakjai győzelem esetén pár évtized múlva ugyanebben a szerepben találnák magukat. Hacsak... nem képesek szembenézni a valós kérdésekkel, amelyek elől álmodozásba, majd szükségszerűen a mai káoszba menekülünk. Kérdés viszont, hogy van-e hajlandóság az utcára vonuló fiatalságban erre a szembenézésre? Vajon csak a transzparenseken mutat jól a "beszéljünk nyíltan a jövőnkről" felirat, vagy komoly a szándék? Én mindenesetre most megpróbálom, kérek egy kis figyelmet.

Ma a világon senki nincs, akinek képe lenne a jövőtökről - csak az állítható teljes bizonyossággal, hogy a mai állapottól teljesen eltérő lesz. Az európai jóléti államok, amelyek évtizedek során globális rendszerekre bízták, "exportálták", bevándorlókkal végeztették a kellemetlen fizikai és szellemi munkát, pénzügyi és társadalmi tartalékaik végére értek; a bankrendszer csődjeinek a java még csak most következik, az államok mai irányítása ezeket nem fogja tudni kezelni. A feltörekvő államok villámgyors fejlődése hatalmas társadalmi feszültségekkel jár, és félelmetes kárt okozott a helyi ökológiai rendszerekben (vízháztartás, szennyezések). A kizárólag pénzügyi hatékonyságra optimalizált globális infrastruktúránk a végletekig pazarló módon bánik a valós, véges erőforrásokkal (energia, talaj, ásványkincsek), semmi tekintettel nincs az ökológia és társadalmi rendszerek fenntartására. Az ezekben okozott hatalmas károk növekvő mértékben ütnek vissza ránk, mialatt a ma egyeduralkodó monetáris irányítási rendszer szépen összeroskad.

Személyes véleményem szerint képesek lehetünk megoldani ezeket a problémákat - amennyiben meg tudjuk tartani globális szervezettségünket a mai szinten. Ehhez azonban fizikai szinten (erőforrás és energia használat, szállítás, utazás, ...) sokkal kisebb körfolyamatokat, helyi ellátó rendszereket kell kialakítani. Közületek nagyon sok fiatalra nem az egyetemen van szükség, hanem az ellátó rendszerekben: a földeken, ipari üzemekben, szolgáltató rétegben; az erőforrások ésszerű kihasználása mellett csak a mai mértékhez képest kevés, de irgalmatlan kemény szellemi munkára képes jövendőbeli értelmiségi kiképzésére van lehetőség. Ezt vagy belátjátok/belátjuk, és ennek megfelelően gondolkozunk a felsőoktatásról (és közös jövőnkről) - vagy nem, és a jelenlegi szép, ám értelmetlen listákkal tüntettek, szónokoltok tovább.

Ez viszont valós tartalom, alternatíva hiányában törvényszerűen ki fog fulladni, akkor pedig mai vezetőink szervezik meg helyettünk lényegében ugyanezt (közszolgálati egyetem, közmunka, "jó multiknak" állami szervezésben eladott biorobotok, új földesurak, elsorvadó közoktatás és közellátás). A különbség annyi, hogy a képességek helyett a származás és a "rendszer" iránti hűség lesz a legfontosabb követelmény. A társadalmi feszültségek csak fokozódni fognak, a valós problémák elhárításához elengedhetetlen szervezettségű, méretű és szaktudású "elit" helyett közutálatnak örvendő gerinctelen hajbókoló csapat fog kikerülni az egyetemekről. A "Civilizációnk túlélése" című tárgyból pedig nincs pótvizsga.

Ez az én véleményem. Mi a tiétek?

Az írástudók árulása

Antalffy-blog: Legyek ura

Az alátámasztás nélküli puffogásra nem reagálok, és igazából arra sem vagyok kíváncsi már, hogy Tibor bá mit képes hülyeségnek értékelni a részemről, a többiek milyen alapon állítanak bármit arról, hogy én miről mit gondolok. A válasz nyilvánvaló: minden eszközt megragadtok, amivel elkerülhető, hogy az érvekkel a saját szintjükön foglalkozzatok. Mindannyiunk óriási szerencséjére, erre a süketek párbeszédére a már régen nyilvánvaló értelmetlenségből származó motivációhiányon túl valóban egyre kevesebb időm is van. Hála Istennek!

Tibor bá, nyilván megismételheted ezerszer, ha képtelen vagy felfogni: elsőre is leesett, hogy te az intelligencia képviseletét abban látod, hogy a középszertől az idiótáig terjedő „tömeg” igehirdetőjeként tekintesz magadra. Neked éppen a rögzített énképed miatt nem eshet le: pont EZ A BAJOM veled – pontosabban az általad képviselt, és nagy vehemenciával terjesztett mintával.

Ha Galilei megszavaztatta volna a „tömeget”, vajon állítja, hogy a Föld mozog? Ha a matematika, logika, orvoslás, elektromosság, magfizika, pszichológia, társadalomtudomány, stb. törvényei a „tömeg” értelmi színvonalán lettek volna kidolgozva, itt tartanánk? Nem. Viszont a mindenkori hatalom tisztában volt vele, hogy csak a magasabb szintű és valóban MINŐSÉGI tudás kihasználásával ismerheti meg a tömeg motivációit, gerjeszthet elismerést és csodálatot, és ezek révén irányíthatja is azt. Eközben, többé-kevésbé mellékhatásként a „tömeg” által felfogható, vagy annak vélt tudás mennyisége nőtt, illetve ennek hétköznapi életben megjelenő hasznát is érzékeli, egyre inkább természetesnek veszi (a gőzgéptől a vízvezetéken és kórházon keresztül a mobilinternetig).

Mára éppen ez vált kritikus problémává. A hatalom rájött, hogy az „érteni vélő” tömeg valódi tudás nélkül, üveggyöngyökkel megvezethető, ordítozásra bírható, szavazásra terelhető. A valódi, sok éves erőfeszítést követelő, és csak a megfelelő képességekkel rendelkező kevesek által művelhető (Tibor bá szavaival: érthetetlen és ezért értelmetlen) valódi, minőségi tudásra már nincs igény. (Érdekes, azt mindenki könnyen felfogja, hogy Cseh Lacival nem érdemes versenyt úszni – na de hogy ez a gondolkodásra, véleményformálásra is igaz lenne, az „magas”. Aha…) Hiába lehetetlen ilyen szinten elmagyarázni egy fizikai mennyiség értelmezését (pl: sugárzó elem aktivitása), vagy éppen egy vélemény társadalmi hatását a saját igazáról meggyőzött embernek, attól az még érvényes. Pontosabban: a babonás hiedelmekkel és vágyakkal szemben CSAK az érvényes.

A gondolkodás képességével megáldott, ismeretekkel is rendelkező emberek pedig (Tibor bá filozófiáját követve) beállnak a tömeg szintjén üvölteni, hangadót játszani, mert egyrészt ebből meg lehet élni, másrészt minek belefektetni komoly munkát és időt, valóban igényes szellemi terméket előállítani, amikor az „értékelés” a középszer felfogóképességén múlik? (Én is megpróbáltam, én is elbuktam, a leckét megtanultam. Mostantól jól fogok élni, mert rátok nincs értelme várni.) Az „intelligensek” beállnak a tömeg álmodozásai által magasba emelt, csak álmodásra képes mesélők "mögé" súgónak, "elé" magyarázónak vagy "velük szemben" kritizálónak. Ismétlem: TELJESEN MINDEGY, hogy támogatják vagy ellenzik a vezérürük kolompolását, amíg azt a látszatot keltik, hogy ezek egyáltalán MONDANAK valamit, ami megbeszélésre érdemes. És lehet csodálkozást mímelni, amikor kiderül, hogy saját önös érdekeiket követik a szellemi színvonaluknak megfelelően, és hogy a matematika, pszichológia vagy ökológia törvényeit megváltoztatni nem képesek. Na EZT a hozzáállást képviseled és terjeszted, Tibor bá, és ismétlem: jelen pillanatban minden esély megvan rá, hogy ennek következményeivel fogunk szembesülni rövidesen. Bár szerintem nem azokkal, amiket előre vetítesz, mert sajnos az elemzésed harmatgyenge: a világképed alapján válogatod ki a figyelembe vett tényezőket (és számtalan példa ellenére képtelen vagy felfogni, hogy én például tudatosan törekszem ennek elkerülésére).

Ha ez bárki számára megnyugtató: én egyáltalán nem „akarom feláldozni magam”. Csupán az a helyzet, hogy a saját szentséges hátsómon kívül ismerek magasabb szintű érdekeket és értékeket, amelyekért hajlandó vagyok komoly árat fizetni élet-időben, munkában. A ti zsibbadtságotok rajzol célkeresztet a homlokomra, mert nekem vannak megvalósítható, ezért veszélyes alternatíváim, míg az itt terjesztett borongás csak a hatalom érdekeit szolgálja. Viszont ezennel közhírré teszem, ha eddig nem esett volna le: ha itt diktatúra lesz, és ha kéri, nyugodt lélekkel beállok szolgálni „ellenetek” és „elveim ellen”. Ugyanis az itt hirdetett kilencven (szerintem kidolgozottabb elemzésem és kissé eltérő értelmezésem szerint száz) százalékos veszteséggel járó összeomlás helyett jobb a tíz százalék veszteséggel (hőbörgők és tényleg gyengék) felépíthető „sok birka – kevés úr” struktúra, amely felé éppen a közbülső réteg, az „intelligensek” szűklátókörűsége, önzése miatt haladunk. Érdektelen, hogy mit „szeretnék”, ha azt minden erőfeszítésem dacára sem „lehet”. Nem ez az egyetlen környezet, ahol próbálkoztam. (Jani: korábban több türelmem volt - viszont túl rövid az élet ahhoz, hogy korábban sikertelen mintákat ismételgessek. Szinte minden eddigi próbálkozásom elérhető, elolvasható. Bocs.)

Kertész helyett sírásó

2012.november.25th. at 06:45

Tibor bá’ (52 végére beszúrva): “A másságot a végtelenségig tűröm. A hülyeséget csak egy darabig. A durva, közönséges megnyilvánulásokat semeddig.”

Ez nagyon szép. Nekem egyetlen bajom azzal van, hogy a SAJÁT hülyeségeddel szemben a végtelenségig toleráns vagy, ami persze jogodban áll, csak az necces, hogy mástól is elvárod, miközben az ő “szálkáikat” ostorozod. Kicsit orbánosan hangzik, nem? Vegyük csak az 55-ös hozzászólást! Egy versike és egy sommás megállapítás. Logikai értéke nulla, bizonyító értéke nulla, de vicces, “tömeg által felfogható”, tehát szerinted oké. Ámde…

1: elvileg válaszként született az 52-re. Ugyan már… Az ÉS kötőszót nem sikerült értelmezni, Tibor bá? Állításom szerint ez a viselkedésmód IS jellemző az emberre, ahogy ugyanott SZÓ SZERINT le is írom. De akkor meg MI KÖZE HOZZÁM a rólam alkotott véleményednek? Mondjuk azon kívül, olyan ember írta rólam, aki nem vagy hajlandó OLVASNI?
Viszont létezik az ellentéte, és ugyanolyan jellemző az is. Engedtessék meg Vámosi János dalocskájával szemben Csányi Vilmos etológus professzor kijelentésére hivatkoznom, amely szerint “az ember a legbékésebb állat”. Bár bizonyára az ő bizonyítása, szakvéleménye sokkal bonyolultabb, számodra (és az általad vizionált átlagolvasónak) túl fárasztó is talán. Én naiv módon hiszek abban, hogy ha te nem is, de van, aki felfogja a két érv közötti szintkülönbséget, logikai tartalmazási viszonyokat. Hátha… (mondjuk itt egy rövid összefoglaló)

2: A dalocskádból általánosítani nettó ostobaság. Egyértelmű kérésemnek megfelelően helyezz az említett aranyásók köré húsz indiánt! Rögtön összefogást, talán még önfeláldozást is tapasztalsz, amíg a túlerőben lévő “közös ellenséget” kell hentelni. Az egyéni érdekek minden fölé helyezése azután jön, hogy a résztvevők önmagukat biztonságban hiszik, mert az összefogás mögötti motiváció ereje lecsökken.
EZÉRT ordító baromság a “minden rendben van” tudat folyamatos terjesztése (az erre egyébként vágyódó tömegnek, szóval végső soron a hiba az ön készülékében van: “replace user error”). Az egyéni halál, a civilizációs problémák szőnyeg alá söprése, stb. azt az illúziót keltik, hogy nincs miért összefognunk. Pedig éppen ellenkezőleg: ennek hiánya szó szerint veszélyezteti a civilizált ember létét.

3: Ugyan hol van ez a felfogásod akkor, amikor hangosan hőbörögsz fideszék hatalommániájával szemben? Erkölcsös viselkedést várnál el egy álmodozó tömeg által magasba emelt, csak a saját álmát látni képes embertől? Vagy akkor minek papolsz erről egyáltalán?
Igen, hitleri érában élünk, és akit érdekel a folyamatok mögött álló motiváció, a használt eszközkészlet és a várható jövő, tanulmányozza nyugodtan a Mein Kampf-ot, hiszen ma is “háborúban állunk” a gonosz világgal. Rossz hír: a németek se ébredtek fel időben – a rövidesen bekövetkező államcsőd és a válságkezelés ürügyén bevezetendő parancsuralmi rendszer alatt (amelynek előkészületei folynak valójában a Matolcsy piros pöttyös, nekünk szóló “pávatánca” mögött) már késő lesz. Nem “geddon” lesz itt, hanem diktatúra, amely elválasztja az urat a szolgától, és végre elnémíthatja, vagy akár gond nélkül agyonlőheti a másként vélekedőket.

4: És végül: TE VAGY AZ, aki felfegyverzett túlélő vadállatok bandájának szervezésében látja a jövőt, ezt az igét hirdeted orrba-szájba…
Itt meg (igen az 53-ban) leírod a receptet, hogyan irtanák ki ŐK egymást, amikor kiderül, hogy szervezettség, erőforrások, szaktudás és helyismeret hiányában KÉPTELENEK fenntartani önmagukat. Ezt talán inkább beszéld meg magaddal, mielőtt arról álmodoznál, hogy értelmes dolgot csinálsz…

Tudom, hogy semmi értelme ezt leírnom, mert ugyanúgy figyelmen kívül hagyod, vagy kiskapukat keresel benne, ahogy mindig – pedig már nagybetűvel írom azt, amit figyelmen kívül szoktál hagyni, hátha úgy feltűnik. Öregnek érzed már magad ahhoz, hogy esetleg a saját véleményeden kívül mást is figyelembe végy, netán változtass a saját megkövült, önző, másokat ekéző, mindig másokban hibát kereső hozzáállásodon. Mielőtt megint az igehirdetésedre hivatkoznál, olvasd újra a 4-est!
Nem érdekel, és nincs türelmem végigjátszani ezt sokadszor. Igénytelen hülyeséget beszélsz, és hiába vagy intelligens, attól még lehetsz ostoba – vagy szép magyar szóval: OKTALAN. Hiába tudsz “szinte mindenről valamit”, ha nem tudsz “valamiről szinte mindent”, és nem vagy hajlandó felismerni az összefüggéseket.

Szerintem.

… egyébként a másik véleményét sommásan “faszságnak” nevezni (Tibor bá, 62) SZERINTEM durva és közönséges dolog. És ez így hogy, házigazda, blog policy maker uram? ;-)

53, Technomuzsik: Világtörténelmet, ennél rövidebben leírva még nem láttam. Gratulálok ! Kár (?), hogy a mondat folytatását jelenleg még senki sem tudja.

Köszönöm. Tudod, semmi erőfeszítésbe nem kerül nekem ilyen frappáns mondat összerakása, nem is figyeltem közben. Csakhogy ehhez nekem LEFELÉ kell mennem egy olyan szintre, ahol Tibor bának IGAZA VAN, és nincs megoldás. Olyan emberek tapsáért, akik megsértődnek, ha azt mondom: MÁSZNI kéne a megoldáshoz, nem “tömegeknek” meg mindig másoknak, hanem SZEMÉLYESEN NEKIK kellene megemelni a nagyságos feneküket. Igaz, Jani?

“a mondat folytatását jelenleg még senki sem tudja”?

Tudod, a téteket akkor szokás az asztalra tenni, amikor még forog a kerék.
Nem vagyok senki, és mivel ez a profi szinten űzött szakmám, legjobb tudásom szerint összeállítottam a lehetséges forgatókönyveket, ezt nem akarom már ezredszer elismételni. Ezek között igen, szerepel az itteni szánalmas verzió is, sokkal nagyobb eséllyel (figyeltél, Tibor bá?), mint az általam támogatott kimenetel.

A végeredmény viszont tőlem, tőled, tőlünk függ. Attól, hogy milyennek látjuk ma a világot, hiszünk-e a jövőben, hajlandóak vagyunk-e felelősséget vállalni érte és saját tetteinkért. “Fogyasztóként”, “leendő túlélőként” vagy “egy mainál élhetőbb jövőt építőként” gondolunk magunkra. Az első kettő között a jövő szempontjából SEMMI KÜLÖNBSÉG.

Kertész helyett sírásó mindkettő.

Legyek ura

2012.november.22nd. at 06:00

Tibor bá: Olyan szépen álltok be a sorba és nyilatkozataikkal igazoljátok azt, amit írtam, hogy meg kell ismételnem. A tény az, hogy az Ember nem “humánus”. Ez egy hatalmas önbecsapás. Aki ezt nem fogadja el, az képtelen szembenézni a tényekkel. Nem ritka jelenség! De igazán értelmes emberekre nem jellemző. Nyugodtan nyomjátok csak tovább, hogy milyen jó az ember. Ez olyan, mint amikor valaki a sötétben kiabál, mert FÉL. Nyomjátok csak, nyomjátok. Talán akkor majd elmúlik.

Érdekes, mennyire képtelen az önző, kizárólag egyedi tulajdonságokban gondolkodni képes, majd abból elfogadhatatlan logikával általánosító “igazán értelmes ember” megérteni, hogy a valóság (akár a tömeg-alapú: biológia, evolúció, társadalomtudomány, akár az egyéni: pszichológia) NEM fekete-fehér.

Nincs jelentősége annak, hogy “Tibor bá tudja a tutit”. Itt nem precedencia alapú ítéletek vannak, minden egyes eset egy kaotikus környezetben kerül kiértékelésre, és statisztikai valószínűségek adják az eredményt. Az ember empatikus ÉS agresszív. Együttműködő ÉS versengő. Képes feláldozni másokat saját érdekeiért ÉS képes feláldozni önmagát mások érdekeiért.

Konkrét példa: “ölnél a kajáért” – ellenpélda: “összefognál a másikkal, és ketten jóval kisebb kockázattal ölnétek meg a harmadikat kajáért” – folytatás: “összefogva KÉNYSZERÍTHETNÉTEK a harmadikat, hogy kaját szerezzen/termeljen nektek” – tovább folytatva: “összefogva MEGGYŐZHETNÉTEK a harmadikat, hogy neki is az a jó, ha kaját szerez/termel ‘nekünk’” – még tovább: “elérhetnétek, hogy ESZÉBE SE JUSSON más lehetőség, mint kaját szerezni/termelni nektek”.
Erőforrások, terület és hatékonyság – máris a közösségi evolúciónál, mémeknél, mintáknál, törzsnél tartunk. A ma (a hálózatos gondolkodásra képtelen, ügyesen megvezetett okoskodók által) piedesztálra emelt egyén pedig definíció szerint esélytelen áldozat a rá szervezetten vadászó törzs ellenében. Legyen az egy kitalált gyerekcsapat, a Hitlerjugend/úttörő mozgalom/cserkészet, államhatalom vagy a globális pénz alapú irányító struktúra.

Minden egyes egyénben rövid és hosszú távú hatások keverékének pillanatnyi állapota eredményezi a döntést (ugye emlékszünk még arra az MRI vizsgálatra, amely bizonyítja, hogy a döntés előbb születik meg, mint a hozzá vezető “logikus magyarázat”? Ide is linkeltem…) Társadalmi szinten az egyedek és a rendszer kölcsönhatásai még kavarnak rajta egyet, ami egyedi szinten megoldhatatlan végtelen paraméteres függvényhalmaz, “megoldhatatlan”. Viszont léteznek tudományosan ellenőrzött módszerek amelyek pont ilyen rendszerek viselkedésének felmérésére és befolyásolására alkalmasak – nem egyedi szinten, de megfelelő halmazon és időtávon egyre stabilabb módon.

Szabad feltenni a kérdést, hogy aki hajlandó (khmm…) utánanézni és felfogni ennek jelentőségét, továbbá megfelelő erőforrásokkal rendelkezik hozzá, vajon használja-e rajtunk? Vajon képesek vagyunk-e a kocsmai hőzöngés szintjén megragadva felfogni, hogy mit miért látunk (és gondolunk) úgy, ahogy azt “látnunk adatik”? Vajon érdemes-e fekete-fehéret játszani és minősítgetni a többieket – vagy ez pontosan az a minta, amelynek követése révén egyének statisztikailag kezelhető homogén masszájává alakulunk?

Na aki EZT nem képes felfogni és helyén kezelni, az talán kisebb lelkesedéssel osztogassa az eszét, mert magának sem elég. (Bocs Tibor bá… veled ellentétben én csak most kezdtem el “nem veled beszélni”, hanem a véleményemet hangoztatni. Vajon te meddig mész el a “nálam lehet ezt is” demonstrációval?)

Identifiers and aspect references

How does a business logic object access other aspects? The connection can be dynamic and static.

Dynamic connection means something that the code accesses "right now" and it can change. Like in the messenger application, get a list of messages and select one. The selected and displayed mail is a temporal connection to a message, you can select another message and switch the display to it.

A static connection is something that the actual code can't change, only uses them, it creates the environment where the code is running. There are known examples for this in "standard programming": this is the Runtime for a static application, or the Servlet Context / Session for a web service; the start up parameters and the Environment variables, content of a configuration file or servlet / context xml.

In Dust this goes further. In standard programming, the code contains the function and member variable names, static / global variables. They are resolved by the compiler and linker to memory offsets and jump table indexes, burnt into the binary (and causing unwanted component dependency network, version compatibility issues and the  "dll hell").

Here you have aspect references only. Simple put: you have dynamic aspect references to object that you want to work with; and static references for telling what you want to do. When you declare that you want to use a certain type, field or shared instance, you actually issue Dust to generate a new constant: an index in a reference table through which you want to access that field or instance. The signature of your implementation contains this list with the referred identifiers, and when your code is active, this list is resolved (either immediately or in lazy-fashion: when first referred to) to actual type and field references - which are Aspect instances again. When you refer to a field, you actually use an index in your reference table, and behind it you get the aspect instance defining that field (and actually knowing not only the memory offset of that data, but all other settings like type, life cycle, access rights, etc.) The code there is responsible for giving you the content of that field from the actual Entity instance (which is then required to contain the memory for all the aspects with proper offsets again).

This finally answers the oldest question of mine: what is an "initial" Dust application and how it starts? The minimum Dust is the meta entity (Type, Aspect, ...) instances in a self-containing Context, with all their static references resolved to each other in code level (this code is generated from the core configuration). The core configuration can be extended to the required types, and we have a static-typed application (no type or binary loading, upgrading, like a GWT presenter); or even to all the entity instances (and we have an embedded application with no dynamic memory management). Of course, memory management and type / binary loading is the "next ring" of Dust kernel, above the absolute necessary core.

I still have issues with the Reference management. It now seems that Aspect instances can only contain generic variables; references to other Aspects require special care, using Containers and / or a dedicated Reference manager. This will be the next run.

"Tudja itt valaki, mi az az Egység?"

Régen voltam itt és nem tudom lehet e a fórumban keresni. Tudja itt valaki, mi az az Egység?Ha valaki tudja, akkor mennyire mélyen és mennyire meggyőzően?

A kérdés vicces, de beleszaladtam, és hirtelen kedvem támadt írni róla.

Számomra az egység azt jelenti, hogy önismeret, szaktudás, politika, technológia, történelem, lélektan és társadalomtudomány területéről származó ismeretek és következtetések egyetlen hálózatot alkotnak. Mondom: alkotnak önmagukban, tőlem függetlenül.

Nagyon hosszú idő és kíméletlen elemezgetés révén az emberi elme alkalmassá válhat arra, hogy ezt a hálózatot hiányos tudása és képességei dacára felismerje, önmagát ennek közepén, a világot a külső oldalán érzékelje. Ez végtelen magányos dolog, mert ha hasonló látásmódú emberrel találkozik, nincs mit mondania - de egyetlen egyet sem talál, a többiek számára pedig érthetetlen, amit mond. Ugyanakkor ez lényegtelen, mert ez az állapot teljesen egyértelmű feladatokat és utat rajzol, melynek követésére minden erőre szükség van, és minden lényeges visszajelzést megad, továbbá az állapothoz vezető út végiggondolása elég meggyőző arra nézve, hogy nincs kint és bent: minden külső történésre pont úgy és pont akkor volt szükség, hogy a belső kialakulhasson, és ez így is fog maradni. A hálózat alkotta gömb csupán azért fontos, hogy a külső jelenségek önmagukban, önámítás és illúziók kergetése nélkül értelmezhetőkké váljanak, az egyén számára minden ismeretével harmóniában álló azonnali reakciókká alakuljanak. Az aktuális képességeinek határáig tágított emberi tudat mint szappanbuborék: színes, mozog és torzít ugyan - de semmit nem takar, és a pillanatnyi körülményekhez a minimális belső feszültséggel alkalmazkodni képes, térben zárt, lágy formát alkot.

Viszont szerintem a Mátrix első részének forgatókönyvét megíró ember tudja ezt. Talán őt keresed. Vagy inkább azt, hogy végre megértsd, és magad válj azzá, akit keresel.

Eredeti hely

Válasz erre

There is no "Dust Framework"

The newest finding. As I was looking for the absolute minimum requirements from a framework (more precisely: an external framework runtime environment) it seems to disappear.

When I have all business logic implemented as business logic components derived from a common base class, it seems possible that the proper network of these elements (the grains of Dust) can do all the required operations. The "application" itself is not more but a component entity that has a Context, which is totally similar to any other "Context holders", like a GUI window or a serializer. The only difference is the initial boot process, where the application started on the machine, has a generated code segment that puts some preconfigured entities (like the meta-level type and service holder instances) into the Context before giving the control to the "launch" message handler.

It will take some time to process this idea.

"Népnevelő..." :-)

2012.november.15th. at 04:33

Tibor bá (blog bejegyzés vége): ... Világviszonylatban a dolgozó kisemberek százmilliói vannak súlyosan eladósodva, mert abban bíztak, hogy mindig lesz állásuk, kvázi jövedelmük, amiből majd törleszteni tudnak. Nem tudnak, tehát elveszítik még azt is, amijük van. Ez pedig szociális felforduláshoz vezet. Ezt persze lehetne kezelni, de csak akkor, ha az oligarchák le tudnák győzni a kapzsiságukat. Nem tudják, mert ők is Emberből vannak összegyúrva. Ez a Napnál is világosabb, csak olyan népnevelők nem látják be, mint például Attila (PV), vagy Kedves Loránd.

Megszólíttatván: ismét örülök, hogy nevetségesen triviális, természetesen ismert és feldolgozott tényeket tálalsz “számomra újdonságként”. Arról pedig igazán nem tehetek, hogy a felvetett problémákra adott, a jelen pillanatban elérhető emberi természetet és technológiai eszközöket alapul vevő, legjobb (és elnézést, de az itt megnyilatkozókkal ellentétben tanult, húsz éve aktívan használt és működő) rendszertervezői tudásom szerint megalapozott elemzésem és megvalósításra érdemes javaslatom
– NEM fér rá egy söralátétre
– NEM lehet hangosan elordibálni az utcasarkon a “tömegek számára”
– épp ellenkezőleg: komoly gondolkodóktól is jelentős erőfeszítést igényel a megértése.

Számomra inkább az tűnik viccesnek, hogy ez a felsorolás bárki számára meglepő, vagy hogy te egy ilyen poszt megírásával párhuzamosan komolyan gondolod, hogy a “korrupcióellenes mozgalom” ötleted egy áprilisi tréfánál komolyabban vehető.

Semmi gondom nincs azzal, hogy hülyének nézel, szíved joga. De azért talán ennyire ne reklámozd azt, hogy nem vagy hajlandó a megértés minimális szándékával komolyan végiggondolni azt, amit NEKED írok. Még akkor sem, ha számodra a párbeszédünk nem több, mint nyilvános demonstrációja annak, hogy hajlandó vagy meghagyni a blogodon a veled ellentétes véleményt.

Uff, én beszéltem.

---

Az utolsó sort felejtsétek el. A “feszültség-csökkentő mosoly” itt nincs a helyén.

Runtime 1

The runtime is the heart of Dust - not a surprise. The most important: I must believe that it is also totally simple. I must not think about speed right now, only one rule: KISS. Later on, when I have a working implementation based on the bones, there will be time to add muscles. But I should not start with them.

What is the ultimate minimum for this environment?

There is no type management, or array, map of types. I only need type by its id on meta level (reading a serialized content, or generating a GUI), otherwise the type is referred directly from the aspect.
No need of context management, the Context instances are also in one Context: the root context of the application.
There is no static Dust API. All codes run as event processors, so they have the same base class, and the Dust API is the functions of that base class. Even Dust kernel, which is only another instance in its own Context.

Esperanto programming

This is a strange one. I feel that I should use the Esperanto language for creating the terms in Dust. The reasons are the following.

Internationalization

Information systems are theoretically global. A person is a person, a chair is a chair, a calendar is a calendar everywhere on the Earth, at least on declaration level. Of course, we put different holidays into the calendar in Hungary and China, we write texts in different languages, and we want to see the user interface or the notification messages from our calendar in our chosen language - but the types and the business logic is the same.

However, in general we use English language to write source codes and comments - that is: we declare the elements in a natural language that we assume the other programmers will understand. So, in fact our systems are English by default, and then translated to other natural languages. However, the terms of our task domain should not be English, that is another "implementation", not the abstract definition. Luckily enough, we have an artificial language with the simplest possible (artificial) grammar, and a full word set for daily and scientific use. Luckily enough: I myself don't know Esperanto! so I will have an immediate need of anything I do to be translated to English, which I, and my fellow programmers can understand. It is a fundamental design decision of mine to separate identifiers from text information, where identifiers are hidden, programmatic information that can never get out of the system to the user, only through a translator - but now this will be an inevitable requirement because I (and my colleagues) would not understand the user interface or logs, if it is not translated to a language we know.

Esoteric

The esoteric reason behind the decision is that with Dust I start to create a parallel world. For the first time of course, I create the meta-meta layer: the definitions of "Type", "Aspect", "Entity", etc.; instances of these types will contain "themselves": the Type, Aspect, Entity, ... type definitions. Then other type definitions come which describe a Person, a Chair, etc. and then instances of persons, chairs, etc. So finally I will have an information system that can represent entities and relations in the external world. So far there is nothing new, all software does the same, yet the programmers don't think about it, and uses the constructs of the programming language for the meta layers and start with practical types. But here I talk about a system where for declarations I don't use a programming language construct, but an independent, external utility.

The structure of that knowledge, the meaning of the terms are the "words", the types: a "Person" is a structure of information that we have described in the Person type. Not a human perception of a Person, but an informatic representation of a person. A natural language word represents a human understanding - the artificial language word represents a type definition. A human knowledge can, and has to be simplified and organized to what the actual type definition can hold; and a human perception can be built by a human brain after browsing complex information networks available in the information system. I also think that all system knowledge can be translated to syntactically valid sentences; but to understand (parse) sentences, it is a fundamental need that the generation rules are clean, simple and obvious.

I accept Noam Chomsky's sentence that Esperanto is not a language. A natural language expresses and also affects the unique structure and complexity of the human brain, with all parallelism, analogies, different meanings, the very nature of human existence. This must be transformed when dealing with mathematics, natural sciences or computers to an environment that is locked to strict rules and only one, perfectly defined meaning. This can only be done on the human side, and I think all the attempts for automatic translation and machine understanding are doomed. The machine understanding will always fail on this in a certain percentage, and the more important it is that the machine does exactly what I want, the less likely that I will ever trust a speech-to-text engine and would want a button to press instead. Or: I have to learn how the machine will understand my sentences, and talk to it using an ultimately simplified "Language-for-my-coffee-maker"... But why?

We do have Esperanto, an artificial generic language. If we have the type definitions (the exact "technical meaning") of each word in a transparent form (again in Esperanto), we have a perfectly clean interface to the system: we can know what attributes, commands, relations we can refer to when talking to the coffee machine. We can use a simple but generic (and so globally available) language that is easy to learn, and so enter a world where we can actually talk to any entity in an unambiguous way, and we don't have to learn a locally crippled natural language for each new type we meet (as we do today for each new software, forget the text-to-speech part, any user interface does just this... not to mention the famous example of the new Office package).

I think it is possible that with Esperanto we can actually do anything in this information system. We can take a totally new component, understand its features, query its state and use its function, all without any additional user interface, just by using the fact that we know Esperanto (the "human script language of Dust"). The essential simplification and clarification between our thoughts and the machine understandable, unambiguous commands - and back: building ideas from the received unambiguous information is done in our brain, using our own, internal natural/artificial language translation. In this scenario, all parties do what they are the best at.

The last sentence: the business logic is now implemented in a programming language - but as I have already mentioned: a source code is nothing else but a more human readable form of a forest (mathematical graph term) of construct nodes of that language (declaration, value transfer, decision, call, repeat, ...). This is to what the compiler/interpreter transforms the text files, and then executes it (interpreter) or further transforms it to machine instruction code arrays. Thinking in this way, the source code itself is equivalent to an entity hierarchy, and any entity hierarchy can be transformed to Esperanto sentences, so perhaps this is the end of programming languages as well: we only need the declaration of the construct nodes to express just any action using them. (Of course this is not among the first targets, just a strange idea.)

Az ezeregyedik kiáltvány :-)

2012.november.8th. at 21:00

65, Tibor bá: Ez annyira szép, és elegáns párhuzam, hogy kifélkövérítettem. Csak azt kellene belátnod, hogy a Viktorok is mind benne vannak az “emberi természetben”. Vágj le egyet, nő helyette három.

Köszi, gondoltam, hogy jól passzol ide.

A jelenség természetességével is tisztában vagyok, ez egyben frappáns válasz is ejha (66) felvetésére ("Lehet, hogy likvidálni kéne"). A gond csak az, hogy egy kis (falu méretű) közösségben ezt a viselkedésmódot a sarki kocsmában néhány nyolc napon túl gyógyuló mozdulattal kigyógyítják bárkiből – egy “modern” “demokráciában” viszont öltönyös szakértők és bloggerek járják körbe-körbe a végtelenségig, mi meg bambán hagyjuk kiteljesedni.

67, hubab: Amit eddig elolvastam tőled, abból azt veszem ki, hogy nem vagy hajlandó figyelembe venni annak a puszta lehetőségét sem, hogy az emberiség már túlnyújtózott a maga takaróján, és a jelen népesség puszta életben tartása is csak a föld egyre csökkenő tartalékainak teljes felélése árán lehetséges, míg azok léteznek. ... Mitől vagy olyan biztos abban, hogy a hajó még nem ment el? Hogy egyáltalán létezik még elvi megoldás a pozitív kimenetre?

Biztos nem vagyok semmiben. Viszont jogomban áll ELDÖNTENI, hogy miért tartom érdemesnek élni és dolgozni – és mire nem pazarolok időt.

Felvetésedre a válaszom röviden: a “civilizált ember” mai, nyugati közfelfogás szerinti definíciója természetesen tarthatatlan. Viszont szerintem HA képesek leszünk a valódi szükségleteink kielégítésére koncentrálni az idióta álomkergetés helyett, HA hajlandóak leszünk újra DOLGOZNI, közösségként gondolni önmagunkra és hinni a bennünk rejlő lehetőségben, AKKOR nyerhetünk elég időt az “újratervezéshez”. Ha nem, akkor bizony pofára esünk, és NEM lesz “csendesen eléldegélés a romokon”, meg felemelkedés.
Hosszabb választ a Hajnalvilág könyv 97. oldalától olvashatsz.
[... persze erre "hubab" már nem válaszolt.]

---

2012.november.9th. at 07:34

65, Tibor bá: Én csak krónikás vagyok. Én nem okozom az eseményeket, csak észlelem és közzé teszem. Ha lenne hatalmam azon lennék, hogy minden magyar a 10 százalékban legyen.

Azért lefutom ezt az “én csak krónikás vagyok” kört is újra.

1: NEM vagy objektív, ahogy a világon egyetlen ember sem az, semmilyen szempontból nem vagyunk alkalmasak rá. Ezzel a megállapítással mindaddig egyet is értesz, amíg nem rád vonatkozik (a saját objektivitásodra mint abszolút jellemzőre, és nem mint szándékra hivatkozol).

2: Az objektivitás MÉRTÉKE valóban meghatározza azt, hogy mennyire pontosan látjuk a világot, és ettől függ az, hogy mire vagyunk KÉPESEK a jelen pillanatban. Például: az álmodozókat megvezetik, mert direkt ezt kívánják, és minél nagyobb a homogén álmodozók köre, annál hatalmasabb (és idiótább) vezért emelnek maguk fölé. Szimpla MATEK. Egyébként a tréfa kedvéért: a “fides” jelentése hit, latinul.

3: Viszont UGYANILYEN fontos az, hogy milyennek akarod látni a világot, milyennek hiszed a jelenségek látszata mögött. Ennek alapján hozol döntéseket, és (képességeid mértékében) ebbe az irányba MOZGATOD a világot.

—

Te “csak” krónikás vagy. De ezzel mindenkit, aki a blogodat olvassa, elriasztod a nagy közösségi, konstruktív gondolkodástól, az ember jövőjébe vetett hittől; és egyéni túlélős barkácsolásra biztatod, táplálod bennük azt az illúziót, hogy ennek bármi értelme lenne. Pedig te is leírod, hogy az ebben gondolkodók szépen állítsák sorba a szeretteiket, húzzanak ki kilenc “eldobhatót” minden egyes olyan emberért, akit szeretnének megtartani. VAGY: próbáljanak más megoldást keresni, még ha lehetetlennek látszik is.

Továbbá: HA Orbán Viktor olvasná a blogodat, és a benne leírt jövőképet, a párbeszédek tartalmát és színvonalát, szerinted elgondolkodna azon, hogy mit is csinál? Szerintem éppen ellenkezőleg: ebben is csak visszaigazolást látna. Nem is alaptalanul.

Na ezért vitáztam veled eddig – de már minden fontosat elmondtam.

---

2012.november.10th. at 04:35

77 Tibor bá Ez az a kitérőktől hemzsegő szöveg elkerülésének üdítő példája, amit nálad még nem volt alkalmam tapasztalni. Inspiráló!

Az objektivitásról írottakkal egyetértek. Az ember legfeljebb törekszik rá, de tökéletesen nem tudja elérni. Na de, tudsz ennél jobbat? Ráadásul ez mindenkire, tehát rád is vonatkozik. Az a tudat, hogy abszolút objektív neme lehetsz, nem béníthat le. Különben is döntéseidnél egyéni dolgokkal súlyozod a tényezőket, ami máris a szubjektivitás felé tol. Például: Túlélési stratégia esetén nekem jó, ha van hátra egy évtized, esetleg másfél. Nyilván a felkészülésnél ez egy objektív tényező számomra, de más nézete szerint szubjektív.

Krónikás ügy: Juliánusz barát időben jelezte, hogy a mongol horda nyugatra tart. Kérdésem: Ezzel elriasztotta a nagy közösségi, konstruktív gondolkodástól a magyarokat? Ellenkezőleg, inspirálhatta volna őket, ha hallgatnak rá. – persze ezt te másképp látod. Jogod van hozzá.

Hátulról előre: “mit csinálhat máshogy egy krónikás”?
Például ahelyett, hogy “birkanépezik”, meg túlélő tanfolyamokat szervez (mert “nem szeretném, de úgyis minden összeomlik”), meg “mozgalmat indít a korrupció ellen (HAHAHA…) mondhat olyat, hogy

Hölgyeim és Uraim, ébresztő!

Magyarországon IGENIS VANNAK olyan emberek, akiket a felelősségtudat és személyes felelősségvállalás, a szaktudás és a jó szándék tesz vezetővé, NEM a “modern” “demokrácia” amúgy is fejre állított, majd lassan kézi távvezérlővé barkácsolt szabályai. Például:

• Államfő / miniszterelnök: Róna Péter
• Földművelésügy: Ángyán József
• Gazdaság: Demján Sándor
• Oktatás: Molnár Lajos
• Média, kisebbség: Pikó András

A sor folytatható, alternatívák kereshetők. De ahelyett, hogy a zsibbadt tömeget ekézném nyafogva, meg százalékokon töprengenék, kijelentem, hogy ÉN személyesen őket akarom vezető szerepben látni, és kérlek téged, kedves olvasó:

• gondolkodj el azon, hogy ilyen emberi minőséget akarsz-e az ország vezetésében látni – vagy azt, akik most ücsörögnek ott!
• keress további jelölteket, vitázzunk EZEN nagy szavak, zsidózás meg turulos-koronás maszlag helyett – és nézzük végre LEVEGŐNEK azokat a balfékeket, egyetlen gondolatot, egyetlen másodpercet ne pazaroljunk rájuk!
• ha van kedved, csinálhatunk akár mozgalmat is, de NEM azért, hogy MI mondjuk meg a tutit, hanem azért, hogy végre ŐK mondhassák meg!
• és végül: ÉN követni fogom őket akkor is, ha éppen kényelmetlen, amit mondanak, mert BENNÜK én személyesen megbízom!

Még akár idézhetnél is tőlem, mondjuk ilyet:

A fásultság, végtelen unalom és kiábrándultság nem kellemes érzés, de alapvetően jó. Azokról az eszközökről, amelyek igyekeznek egységes, százalékokkal és mutatókkal mérhető tömeggé formálni bennünket, egyenként kiderül, hogy mennyit érnek, ugyanakkor mibe kerülnek nekünk és a bolygónak. A király meztelen, hiába a kikiáltók hangos üvöltése, a fizetett hangulatcsinálók suttogása a tömegben – az ember újra keresni kezdi szomszédja kezét.

Tudjuk már, hogy a bennünket pirosra, narancsra, kékre vagy zöldre festő, százalékokért bármit kimondó „teamek” folyamatosan lesnek, méregetnek minket; minden óhajt és az ellenkezőjét is felírják zászlajukra – csak sajnos oly kevés már ott a hely a korábbi elvek, ígéretek mellett.

Így aztán egyre erősebben vágyunk arra, hogy valaki végre mondjon igazat, ha fáj is – és ne hagyja abba csak emiatt. Igenis szúrja a tűt, vágja a húst, fájjon, ha kell; de szeretet, felelősségtudat és hit legyen a szemében, ne tartson poharat a véremnek, és ne koccintson vele a műtőasztal alatt.

Ma mindez vágyálom csupán, és nem a szereplők miatt, mert bár ők egyénileg természetesen felelősek az általuk okozott kárért, de ha lecseréljük őket, ugyanolyanok állnak a helyükre. De talán éppen ez tesz minket elég erőssé, elhatározottá ahhoz, hogy felvállaljuk és kimondjuk: igen, én magam vagyok ez a rendszer.
Magam vágytam arra, hogy szebb világot hazudjanak nekem, én kívántam, hogy elvakítsanak, elkábítsanak, és magam is részt veszek mások becsapásában. Most viszont látni akarok, színről színre úgy, ahogy a dolgok vannak, és igazat akarok mondani akkor is, ha ez sokba kerül nekem, mert megcsömörlöttem már ettől a kusza, önmagának folyamatosan ellentmondó rendszertől, amelynek része vagyok. Leesni az ágyról nagyon kellemetlen, de ha ez szükséges ahhoz, hogy végre felébredjünk egy lázálomból, akkor megéri.

(Hajnalvilág, 2008 - 86. oldal)

—

TE mondhatnál ilyet, mert EZ valóban “inspirálhat” embereket a nagyobb közösségi összefogásra – az általad elővett témák és hangulat NEM.
Én nem mondhatok ilyet, mert szerintem a jelen helyzet következmény, az okok feltárásáért ennél jóval messzebbre kell menni.

Az objektivitásos téma:

Igen, ha sarokba szorítalak és éppen jó hangulatod van, akkor egyáltalán válaszolsz, nem küldesz elmeorvoshoz (mint korábban néhányszor) és képes vagy elismerni – de csak olvasd el ezt az egyetlen bekezdésedet. Azonnal visszatámadsz, és már azonnal elfelejted, hogy KIVEL beszélsz.
ÉN vagyok az, aki állandóan a saját szubjektivitását tekinti alapnak, ÉN vagyok az, aki csak a szóismétlés miatt nem írja bele minden mondatába, hogy “szerintem”. ÉN vagyok az, aki az egész életét azzal tölti, hogy magukat objektívnak és alaposnak képzelő emberek kósza ötleteiből egy valóban objektív világban (számítógép) működő rendszert faragjon.

Igen, képes vagyok lemenni arra a szintre, amit te szeretsz, de ott a jelen problémákra NINCS MEGOLDÁS, mert ahhoz igen távoli rendszerek közötti összefüggési hálózat ismerete és feltárása szükséges alapkövetelmény! EZT próbálom elmesélni a “kitérőktől hemzsegő” szövegeimben. És igen: baromi kemény agymunkát igényel a követése is, nem is várhatom el senkitől – tőled sem, nem hogy az “istenadta néptől”. De akkor minek és kinek beszélek?

No azt hiszem, itt volt elég, megint az ellenállhatatlan ágyúgolyó és az áttörhetetlen fal konfliktusánál járunk.

Entity containers and locks

Entity containers targets the problem of transactions: changing multiple entity instances and attributes within a single action. The change must be "atomic", all updates must be done or discarded to keep the components in valid, consistent state - but the modification process requires time, and the operation may be interrupted by a failure (hardware, system, connection - this is the traditional transaction management) or another concurrent modification (programming language lock and synchronization constructs).

Moving the state representation to Dust means that the code should never meet this situation - it can control the "commit" / "rollback" operations, but it does not have to actively protect anything from transaction errors: it should work as configured. The encapsulation gives a way to support this, using a hierarchy of entity containers.

The Dust runtime is merely an entity instance container, with an API to get references to them, access their content and send messages. Its actual operation: the ability of handling the types, entities, messages, and that it can go for other entities upon requests are actually the functions of some required (and later time: properly protected) kernel "meta" entities.

As long as an operation accesses entities and reads their content, we have no problem, this operation can run in parallel with many components accessing the same instance. Writing causes the trouble. Of course, parallel write requests should not be allowed - but we also should not let a write operation complete while another code is actually reading the same entity, because it is nonsense to get different results to the same question (like: I make a decision because of the state of an item, and do other actions, yet the item state gets modified at the same time).

The solution (at least seems to be) quite simple, using the restrictions above. When a code uses a reference, it gets connected to its local usage pool, and also linked into the using contexts list of the aspect. When the message processing ends (the code returns), the references are released and removed from the list. When a code request a write operation, the Aspect gets locked to that code, and all concurrent write requests are suspended until this lock lives. However, the code does not change that aspect instance: it is shallow-cloned into a secondary Entity container. Whenever this code, or any other that it calls refers to this Aspect, they receive this temporal instance; but it is linked to the original container, and any instance missing from the current container will be resolved from (or by) its parent.

So, the update code collects duplicates into the local container, but does not break other processes by the parallel modification as long as it runs. When it ends, the temporary context is released and the updates are committed. This is the point when readers could be broken, so the commit process waits for all current references to be released to the item, and also blocks opening new read references to the target objects. In the root level, commit means updating the instance in its persistent storage as well.

Deadlocks

Of course, this "generic approach" has inevitable problems because of its simplicity. It can naturally result in deadlocks: parallel processes both waiting for an instance blocked by the other. However, this information is not hidden somewhere in the runtime, behind the language constructs, but clearly visible in the Dust runtime thread manager - and can be resolved there. On the other hand, the approach of atomizing the business logic and moving all state representation to Dust means that the message responding codes will be short and simple, so the synchronization problems "should" become more visible and manageable.

Releasing and listening

In longer operations the coder should take care of the consequences of having some entities locked for a longer period of time, consider the side effects and implement the behavior wisely. For example: one entity contains information that has effects on other entities. When this entity changes, many others also has to be updated. If it runs in cycle, it would gradually lock all the touched entities, which is not good - so, it can commit changes for each item thus releasing them from the local context. Of course, with the messaging architecture this is not the case: the update request can be broadcast to all members, the message processor does the update, so the change is done in the local context of the called message processor, and the local commit is done when the processor exits.

However, what should happen to the originating object? It depends. It may remain locked all along the update process to block concurrent modification. Or the relevant data can be extracted for creating the update message, and then the code can release the entity, so even if it gets updated during the child processes, the actual modification will be coherent (though obsolete). Or, the source object can be released, but the process can listen to its change, and if it gets updated while the process is running, it can stop the operation and restart it with the updated information again.

Operation contexts

Another typical situation is when the modification process is of "unknown length": the system enters a state of updating some entities, but has to wait for external events to happen. This is the generic scenario behind all user interfaces, server communication, interaction with a hardware component, etc. I would say that reading data from the hard drive is also the same situation.

The current programming methodology uses wait calls, spins in cycles, etc, in this case, which is again a situation when the code represents the application state, and which considered evil in Dust. The command is sent to the hardware, the information is presented to the user, so this task is done, the activated message processor code must return. The event will appear some time later, dispatched to the component again, resulting in a data change (mouse movement and click -> user interface component state change -> data modification), the relevant message processors are called, and then again the system stops and waits for the next event.

The state between these operations are stored in an operation context, a temporal persistent entity container. This is independent from Dust kernel container (which represents the "actual global state of the things"), and floats above it, containing "one required new state under construction". Such contexts can be created by some system level components - like one that can display a GUI window, open a network channel or start a stream deserialization process. When the context is closed, it can rollback the operation: throw the container, or, by default, commit it: update all entities of the parent container. Yes, this is a tree, and a window called modally from another window can update the parent window's context, and NOT the root under it (and for exchange, it can see the actual modifications made on the parent window).

This again relates to locking. The GUI displays many entities, and updates some. The update locking can break through the context depending on the configuration. The definition should contain if it

• locks the target item globally, blocking others to modify it, but ensure that no concurrent modification takes place - better for atomic components,
• or let others do parallel modification and merge the modifications on commit if needed - better for big components like source codes.

The displayed entities are another problem: they would block updates because of the read registration. An alternative is that the GUI elements listen to the displayed entity, but release it. So, the updates are allowed, but the controls get notification about it and so they can reflect to parallel changes. This is a recipe both for parallel displaying and editing the same data instances, and for screen sharing, depending on if the listening is registered to the target or the GUI element entity.

Esti mese: Viktor és a léghajó

Ennek úgy tűnik sosem lesz vége... Újra karattyolok Antalffy Tibor blogján.

2012.november.7th. at 20:07

... amit Orbán tesz, az ő szempontjából szerintem teljesen racionális, csak addig tűnik bénázásnak, amíg nem akarjuk elfogadni, hogy egyszerűen a saját kapunkra támad. A hülye ötletek tárháza a nekünk szóló “pávatánc”, rágni való gumicsont – a lényeg viszont az, hogy ne maradjon egyéni mozgástered, anyagi függetlenséged, szorulj rá a nemzeti tőgyre. És ne is reméld, hogy lehet máshogy is, mert a “hazán kívül” csak a “gonoszok” vannak.

---

2012.november.8th. at 04:14

60, Ábel: Én látok bizonyos lépéseket, amik éppen abban az irányba hatnak, hogy minél kevésbé szoruljanak rá az egyes alrendszerek az állami tőgyre, ami nemsokára úgyis teljesen elapad/levágják stb.

Pl. mindenhol szabad már állatot tartani. Vagy az, hogy fokozatosan kivonják az állami pénzt a felsőoktatásból, egészségügyből: ettől ezek részben sorvadnak, de részben meg fogják találni azokat a forrásokat, amikből mégis fennmaradhatnak. Persze nem mindenki számára, csak annak, aki meg tudja fizetni. Ez a társadalmi mobilitás vége lesz, de a geddon után úgysincs más.

Ne haragudj, ez ostobaság. Elég közelről látom, ahogy a szó szoros értelmében kivéreztetik a magyar civil társadalmat, például a környezetvédelmi szervezeteket, amelyek a közfelfogással ellentétben NEM a szemétszedésről meg az atomos láncolgatásról szólnak, hanem a fenntartható élet-minták feltárásáról és népszerűsítéséről (lásd itt például Géza tudását). Most már egyre inkább múlt időben.
A társadalmi rendszerek fenntartása NEM “rentábilis”, ezek nem teremtenek pénzre váltható értéket, nincs “nettó bevétel”; elvileg a gazdaság termelő részének kellene finanszíroznia (erről szólnak az adók). Ha ez nem történik meg, akkor a kiváltságos kevesek számára marad elérhető, a “többiek” mennek a levesbe, ami NEM a megoldás, hanem a totális összeomlás receptje, lásd Görögországot (de ha jobban figyelsz, az egész “fejlett nyugatot” élen Amerikával) a lejtőn lefelé – és Argentínát, ahogy jóvátehetetlen következmények mellett kifelé próbál araszolni. Engedelmeddel Tibor bá, egy régi(!!!) írásom: újsütetű messiásunkat ekéztem ezzel áprilisban.

59, Tibor bá: Az egészet megette a fene, de miért kell siettetni? legalább én szeretnék “békebeli” módon elhunyni.

De nem ezért firkálok itt megint, hanem azért, mert megint egy ide szánt szösszenettel ébredtem (fél négykor, rohadt dolog ez a prófétaság). Figyelj csak:

Viktorunk olyan, mint a süllyedő léghajó kapitánya, aki kidobja az égőt (mert veszélyes), aztán a gázpalackokat (mert égő nélkül minek), lebontja a kosár oldalát és a köteleket nyiszálgatja. Minden ilyen lépés után megtapsoltatja magát, hogy na, megint emelkedünk, akárki láthatja! És miért? Mert a ballaszt homokból szép várat épít Kennek és Barbie-nak (a “benne hívő igaz magyaroknak”), és ahhoz semmiképpen nem akar hozzányúlni.

Ezzel az a bajom, Tibor bá, hogy például ebből lehet plakátot nyomni, meg pólóra felrajzolni, meg hőbörögni – de a léghajó felemelése, amelyért való erőfeszítés az EGYETLEN erkölcsileg, emberileg elfogadható megoldás (azért, hogy nem csak TE, hanem mindannyian tisztességben addig élhessünk, amíg adatik, és békében nyugodjunk el, amikor eljön az ideje) nem ezen múlik.

—

Ahogy egyébként az “apostoli magyar királyságon”, okoskodáson vagy a lezuhanásra való felkészülésen sem. Azt a vitát meg nem nyitom újra, hogy aki MA, a kényelmes székecskéjéből és életkéjéből a “geddon után” szöveggel jön, az az én szótáramban nem felel meg az “ember” fogalom definíciójának. Mindegy, ezzel ébredtem, leírtam, szép napot. Dolgozni is kéne még, mielőtt munkába mennék.

---

2012.november.8th. at 05:05

Ó basszus… hát most kellett leessen a lényeg! Tibor bá! Orbán Viktor TE VAGY!

Pontosan ugyanazt a forgatókönyvet látja, mint te, ugyanazt a logikát követi – csak neki hatalma is van a túlélésre érdemes tíz százalék kiválasztására és támogatására “a többi” rovására (szerk: és ő az, aki a tanácsomnak megfelelően szektát csinál belőlük). De milyen rohadt dolog már ezt a turulos csónakot kívülről nézni…

Bocs… :-D

Entities 2

References

The fundamental difference of Dust is that it considers the software (all of them without exceptions) a state machine. The software is built up from components having many attributes and connections to each other, but both the attributes and the connections are managed and kept inside the framework runtime environment, can be accessed and managed by framework API calls. The software code on the other hand is responsible only for handling events, and not for representing the system state. That is: no "main" function, no waiting cycles and polling, and no final and static variables, local buffers for storing system state information.

Whenever a code (an internal event handler of a component instance) wants to access another component, it can do so only through dust API calls, and only by a component (Aspect) reference that it has received from the incoming message, its own existing component links or by searching for entities using API calls. The code has a very short life: runs only to respond a message (and not to represent a "listening state" for example), and has no need to "remember" any component or state (except for storing such information in its own or other components' attributes).

This means that the Dust runtime is free to handle the actual entity instances behind the API wall as it wants. It is totally irrelevant if the instance is purged from memory and reloaded, replaced with another instance ("dll hell"), exists or temporarily moved to another computer - as long as its attributes are reachable and messages can be sent to it using their references.

Entities 1

Entity versus Aspect

Separation of these terms is fundamental in Dust. The Entity represents the "existence", be it a message, a software component, a real life object or person. The Entity has a life cycle independent from the computer environment, and its computer representation must be synchronized to reflect those changes - this is why we have "information systems". Behind all operations Dust manages entity instances in the background; all information packages come and go in Dust in Entity instances.

Aspects are "objects" of declared and managed types having attributes and implementing business logic (that is: processing and responding to incoming messages). An Entity instance has a collection of Aspects, which collection may change along the life of the Entity - so the Entity itself has a history of changing Aspects, while the Aspects have history of changing Variants, receiving and sending messages.

In any business logic (software code) we can only see Aspects. We use and communicate with these feature collections, not the Entities themselves. Every Aspect instance, where my business logic is integrated, have the list of required service components, with which I have to communicate to do my job. These links are defined in my type, declared when the application configuration is created (deployed to the actual running environment), and resolved when my entity is loaded. In fact, most business logic does not have to get and store entities dynamically, variable content come with the messages that it has to process.

Knowing this, I assume that the business logic code should never access entities, nor aspects directly, through a memory reference or object instance. The Dust kernel API therefore can totally separate the "user" business logic from internal memory and data management, and this is a fundamental step towards security and reliability.

On the other hand, there are special components that have to see through this layer: the generic services like expressions; automatic GUIs that are generated to an Entity by listing its Aspects; or serialization. The idea: i should create Entity, Aspect, Field aspect instances! The component can request them from an incoming Entity instance, and through them it can manage those generic operations. With this trick, there is no programmatic or API difference between kernel and user level code, no new "protected" kernel functions. Of course, the operations must be protected, but again with the same tools as all other Dust security features will be implemented, with the same declaration features.

Working with data 3

Collections again

It is very hard to get rid of old habits and choose a more complex-looking solution (which is complex only until we peek under the hood of the programming language where the problems are hidden).

I thought (and programmed in this way many times) that collections are generic part of data management. Again: they are not. Collections are aspects themselves, they either are part of the owner entity (like: subpanels of a window, scheduled commands of the scheduler, etc.) or referred internal entity members. Yes, the last time I have said that I did not need a collection directly, but only the iteration/search function - but forgot to mention the term "temporary". It is true that I don't need temporary collections, but the object themselves do contain many collections. If they are hidden under the "variant" layer, I have returned to the same problem of temporary collections, but under the hood with expressions for example.

So: Variants do not have multi-value content. If there is a need of it, it is a reference to a Collection aspect or entity. When expression evaluation encounters such a reference, that is again an accumulate / broadcast / search action (and reintroduce the parallel execution on this very low level).

Serialization

When different nodes communicate, they need to serialize their content. This component is responsible for working with references (independent of the actual implementation or the syntax of the stream). The generic solution is that each serialization action contains an ID map, where the unique id of the entity instance and a local, action-unique id is connected. The local id is used all the time, while the content is pushed into the stream only on the first call, when the item is registered into the map. In this way both sides have the simplest way to write and read the self referring structures properly.

Very important: the mapping must be set when starting the serialization: the referred entities may contain back references to the entity being serialized. They must receive the local id only, not start a recursive serialization process. On the other hand: anytime a local id based reference is resolved, the instance itself should be considered "final", but may be incomplete, and its content should not be used at this time. The read process should end with an independent initialization action after all referred components are read.

Content in serialization

From the content point of view, we have static and dynamic serialization.

Static is when I want to store and "remember" something as it is, like a configuration file: I want to keep some settings... NO! The config files are actually the primary source of the stored instances! Hmm... This means that for persistent entities, I have to serialize the content only if that serialization is actually the primary storage for those instances. All the others must only be stored by their unique identifiers (global type Id plus the identifier there). Of course, static serialization cannot contain temporal instances? NO: in some cases, like logging, anything, including temporal instances, must be stored persistently.

Dynamic serialization occurs when I send some content to another active node, which can ask back for additional information as well. In this case, the content of the stream should be optimized by the number of other request that the target has to make when processing the stream content. Some of the referred entities it may already have; others it can miss and ask back for. To cut it short: the sender may add the content of any entity instances to a dynamic serialization, even though the target is not the primary source of that information. This happens if the aim of the communication is in fact to get that instance (like requesting a Person record from a node that owns them), or that they are required to understand the response (sending Address, or Medical records as well with the Person).

It is possible that the sender keeps a sort of log about which objects is had sent to the requester, because it is responsible for keeping them in sync with the actual state, or even add event communication to them (later, this is screen sharing and active teamwork), or at least to optimize the serialization content: send only if the information is not available on the requester side. Of course, this is just an optimization: the requester is allowed to reload all content again (the client may be restarted or lose any content independently from what the server knows about it).

Format and type negotiation

When thinking about connecting to other nodes, we have to keep in mind that the endpoints may have different feature set. The most important is when the client is limited, like it has static type management, so it is simply unable to load a new type to understand the content of the serialization stream.

Level zero is to be able to build a stream connection and be able to transfer bytes through that line reliably. This is a lower level requirement that has to be solved with implementing the proper connector components; as long as I work with Java or other higher level languages, this should be a no issue. However, it also means that I must pack the stream operations into units as well, otherwise I might surprise myself when moving to a more limited environment.

The first level is that both ends must be able to parse and write the stream, that is: be able to handle the actual syntax. This means having Serializer component implementation, and the language elements for that syntax. This is a reference to an existing declarative information package, the EBNF-like declaration of the JSON language, which is actually used to parse and generate JSON streams (and in the hand of the Serializer, a valid JSON serialization) works just like the type declaration themselves. They are persistent entity instances, can be referred to, etc.

So, the limited client has the JSON language definition compiled into its codebase, and the client introduction contains the reference to that instance along with the statement that it is a static client, and cannot handle additional stream formats. When a stream connection is made, this information is used, and the more dynamic node can adapt to this requirement, optionally download the required language definition.

The second level is the content type set. Again, a static client may have final set of types, perhaps encoded again. This is a more generic limitation affecting any environment that is unable to load codes and object dynamically. For example the GWT environment can adapt to additional stream syntax, because if it has the generic EBNF code set, a new syntax is just another structure made from them. However, the GUI declaration types are final, a "Table" type is mapped to one specific code; it is not able to understand new, derived Table types. On a really static client this is also not a question: it is not even able to download and integrate new Type definitions.

So, a limited client introduction can also contain that it has a final type set, and the identifiers of the accepted types. The dynamic sender must "downcast" its content to the required types, and skip aspects that are of types unknown to the client. Naturally, this may result errors because of the lack of required references - the sender must handle these situations. But at least, they are visible...

Working with data 2

Some more meditation on working with data... not surprisingly, they are restrictions.

Floating point

Floating point values are nice, we have the normal mathematical operations with them and also tons of functions like trigonometry, root, etc. As I have just learned, some CPU families don't support floating point operations, and the math library provided with them actually emulates the functions with complex library calls. In a real time system this is not an advantage. Thinking on it further, even a current PC processor should not run floating point calculations because it has a way stronger neighbor there: the GPU...

So, floating point variables should not be considered "generic", but wrapped into a unit, and when deploying an application on a PC, we can consider that as a heterogeneous parallel processing environment, and let the GPU do the calculations. (I don't know how to do this yet, but I am sure that this would be a real advantage). Also some real time systems where floating point calculations are available but not hardware supported (therefore not recommended) can simply declare that they are not compatible with floating point using units.

Collections

Now, collections are wrapped into intelligent Variants that helps message communication, locking, etc., but there is one more thing. The collection should not be available directly, as an independent object or unit. In several years of programming I have found that I actually never use the collection as an object; I iterate the members (sometimes filtered) to collect some information or initiate actions on them. Therefore, I should support the real requirement: the basic functions: isEmpty, count, contains, insert, remove, clear, ... and the iteration itself, either by requiring callbacks with the items or broadcast the same message to them (or some of them based on a filter).

Without this temptation I will not waste memory on creating (sometimes huge) temporal collections just because I want to iterate the members. This also is a kind of "inversion of control": it is not me iterating a collection, but an iteration runs somewhere and I get a callback with each item. If the environment supports it, this can be a parallel operation either for fetching the data, broadcasting a message to them or calling me back with them.

Strings

Strings are basic language elements in most environments, but that is completely wrong. I have to write many string manipulation codes (like searching in them, building them, etc.), but if I look closer, I just repeat features that are available already: in regular expressions/parsers, template engines. Apart from this ad hoc transformation, I just take strings from one place and move them to another - even I take them from source code (or some language provided container like the Java properties file), and write it to the screen, to a log, database (or System.out...). I introduce problems like encoding, language dependency, different formatting standards, etc.

No. Strings (and its big brother, formatted documents) must have their own unit with proper (and black boxed) support for encoding, I/O, templating, etc. and the code must have only one way to deal with them: through their Units, as entity instances.

There is one exception: the Identifier, which is an array of plain ASCII (1 byte long) characters, used for identify components. They have only basic functions (equals, concatenation, find, ...) and all hardware environment can support them on hardware level. The Identifier gets a separate Unit apart from String, used by dust core as well.

Running environment capabilities

With a nice declarative framework one heavy-weight problem is when it hits the hardware and must run on it, and somehow meet the promise of being independent from it. Well, it does cause some problems, and it is again with data.

One is the actual coding. We either have a runtime environment, where the runtime declaration contains that "for Java language, the long is 64 bit". Or 128. It has native support. Or not. Depending on the actual hardware and the runtime version, and perhaps the runtime implementation: someone can make a Java runtime with different features: it actually runs Java code, but the code behaves differently. I don't say that this is an issue of a generic programmer - as long as (s)he is working in one environment and comfortably far from its limitations. But when thinking about designing and coding a Unit which is able to do its job in a Dust environment on practically any platform, this is a tough one.

When working with generic data, we must precisely declare the minimum storage requirement, and so the valid value range (of course by using the common sense terms for it, but perhaps going down to the good old assembly notations);and when generating or writing actual code, we must keep the names, but use the generic data types with proper (perhaps larger) capacity. We might also include range checks, and throw runtime exceptions on overusing the variable: that code works in the current environment, but it does not comply with the type declaration. Of course we can't check the temporal local variables in the running code that will fail on a more limited environment, but at least we can do the check when setting a Variant.

The problem arises again when we have to communicate with a running code, exchanging actual data. This happens on persistent data I/O and on sending messages to entities residing on a different node. The channel (either a shared memory area, network, serial, ...) must have portals on all sides, where the node capabilities are available (endianness, encoding support, etc). The negoriation must take place when configuring a static channel (at deployment time) or when building a dynamic channel (like accessing persistent instances on the specified server node). In dynamic case the node performance must also be considered, like a real time embedded node is not able to negotiate on the channel content, the stronger node must format its content as the weaker can handle it.

Working with data

The keyword here is reusability. I want an environment with totally independent parts, the same components for expression evaluation, interpreting an algorithm or accessing object member values from code; I want both string based access and compile time / run time support for type and nae checking. See how this goes.

Identifier

All starts with this. The Identifier has a short, limited ASCII "name", which must be unique in its context; and a reference to this context, which can either be a type declaration or an actual context (like a code block for interpreter environment).
The Identifier instance can be requested from its context by referring to its name, so it is unique, and adds the context information to the string name, therefore name collisions can be avoided.

Variant

The Variant is the core data element; a wrapper that holds the actual data value. It supports

• generic values like boolean, integer, floating point values and fixed length ASCII strings;
• single object reference to other objects;
• collection of generic values / references. The collection has flags of sorted: if the elements have a fixed enumeration order, and single: one element can appear only once in the collection.

The Variant also has a VariantDeclaration reference, where all meta information of that variant instance is stored. This means that the Variant itself is repeated for all actual values "anywhere"; they can travel through expressions, contexts, etc., but they always hold a reference to a data structure that can define them and the actual value can be understood by them.

Another idea: it holds a reference to an DataObject in which it lives AND a definition index - because in many cases I must go "up" from the Variant to the owner DataObject. And the final blow: the Variant has direct access and modification interface (to be used in expressions and interpreters), but is must invoke the change listeners of the owner DataObject, if exists. This requires DataObject reference in the Variant.

VariantDeclaration

This contains the variant identifier and all other information (type, access, life cycle, etc.). The declaration may come from a type or direct request in an interpreter. The important part is that the declaration is generally repeated for several Variant instances, so it is lifted from them.

The life cycle information (like "already set" or "final") may belong to an object instance - this enforces that the Variant should refer to the DataObject with a declaration index and not the declaration directly.

DataObject

The DataObject contains an array of VariantDeclarations and an array of Variants; it acts as an Aspect instance inside an Entity, but also the context for a running system, or the code block stack in an interpreted algorithm.

To mix flexibility with memory optimization, the most used DataObjects (Aspects) start with their declaration array initialized with the array from their type, which is immutable shared array instance, and sufficient for most cases. However, this instance may be referred from other aspects, resulting a reverse reference to the referring aspects of alien VariantDeclaration. When this thing happens, the array is copied to a mutable declaration array, and the new VariantDeclaration is added to this DataObject together with the new Variant. 

The same applies to the generic DataObjects acting as context: they have no initial declaration array, but extended on each variant declaration request. The only difference: the declaration objects are themselves can be local strings, in this case they must be unique in the actual context. However, types may contain "shared" member declaration, which means they are not contained by the Aspect instance but the identified Context (this feature implements the "static member" feature of the programming language, and extends it by enabling different Context levels like runtime, session, user, ...)

Field

Field is used when we access the Variant from the DataObject; to do so we need the object itself, and an Identifier - which is not just a name, but a context as well. It is also important that the Field itself is more locked to the Identifier than to the object: it is fine to access the same Variant in multiple objects through the same Field instance, but it is not good to switch a Field to access another member Variant of the same object. Consequentially, the Identifier is final, while the object is mutable - although you can get a Field directly from an object by providing the requested identifier, but the field can be reused for other objects that have the same member.

The Field inside is responsible for removing the identifier based string access. It has an object reference, and a VariantDeclaration index inside. When (and only when) you call setObject with a new reference, the identifier is searched in the declaration array of that object, and the index is stored. Whenever you access the content, it is just an indexed access of the variant array of the object behind the field.

Fields are mostly used in declarative "toolkit" components, where the actual context "knows" the required type, the field is identified by the declaration name within the type, and you can manipulate the content through the Field instances. Most of such environments work with multiple object instances of the same type (like a GUI panel, a string template, a table, etc.) for which the Field's final lock to a specific declaration is also a good feature.

FieldSet

A helper component for dynamic access environments: you provide a type and an array of strings, they are internally transferred to an array of identifiers and Field instances, and so you have an indexed access to the values, where the index is in sync with the index of the field name in the string array.

TypeWrapper

The heavy-weight wrapper for an aspect. This is a generated code from the type declaration in the target programming language. It contains a FieldSet by the type, and a reference to an actual Aspect instance, typed get/set functions with type casts by the variant names. The TypeWrapper actually looks like a "normal object" for the programmer. For each Unit declaration, the wrappers can be generated, and used by anyone who wants to use the objects from their native code. The important feature here is that the actual data binding between the wrapper and the data object instance is done runtime, by the declaration and identifiers, not any fompile time fixed tables. This really allows extending the types without breaking the caller code.

It also contains static accessor functions, which are translated to getting and casting the referred items from the declared context (like "Logger.getLog" returns the log object in the closest context: transaction, session, system). The wrapper also incorporates message sending, but this is another story. When working and writing code on this level, it should feel almost like coding without Dust in the background.

Dynamic type management and the application

The fundamental structure of any application is the deployment configuration. A GUI panel that is used to communicate with the user; the runtime environment that transfers hardware events (mouse movement, keyboard keys, etc.) to GUI control actions, then data modification - they are just the same kind of "data" and attached business logic components and implementation as the "Person" record displayed on the screen.

So if the application is anything at all, it is a deployment configuration about what components should be initiated and how they should be wired together with message channels to provide the required functionality. How should this deployment look like? (Of course, the kernel part of this deployment should exist in the form of compiled source code to make the kernel work and be able to load the other components.)

Application types

From structural viewpoint, an application can be static, type dynamic and binary dynamic.

• A static application is one that has all the types and binary codes available compilation time. This application will be able to deal with a fixed set of data and components - like most of current software do. 
• A type dynamic application can deal with an open set of data, like a generic view that is able to load and display any document in a document management system, without knowing all the document types at compilation time. This can be achieved by a sort of configuration-based data management, and template engines. 
• A binary dynamic application can integrate software components at run time that were not known at compilation time. This is a plugin based environment, a typical example is the Eclipse plugin framework.

As the other types are limited subsets of binary dynamic, I plan that one; the others are created by replacing dynamic service components with placeholders providing the configured set of data.

There are also types from memory management point of view (instance-based, pooled and free), but that is out of scope here.

Vendors

The fundamental question is: where the types (and the associated business logic) come from?
They come from the vendors. A vendor is a software designer or implementer organization, who analyzes different problems, offers data structures and attached business logic codes bundled into units. These units can be used as building blocks for providing a specific service to a user. Therefore, all deployment configuration starts with a vendor list. The list contains the unique vendor ID, to which later the units refer to; they provide those types and binaries that this application is built upon at compile time.

However, dynamic applications must extend the list of types or even get new unit binaries as they receive corresponding data items. So, exactly one vendor must be identified as vendor provider, and provide a way to access that vendor server, because it will be used to get more vendors (data can refer to vendors unknown to the application at deployment time), and get connection information to them (to reach them for type declarations and perhaps attached business logic binaries).

In this way, the application can start with a single root vendor (in a generic case, a public server of the creator of that software), with a limited set of units enough to boot, and perhaps to provide the basic functionality. The generic usage of any application is browsing and managing a data hierarchy (be it a word processor, a mailer, a company information system, etc.); the root vendor provides the additional components and the referred data, controls the access to the external links, etc.

A generic dust application refers to the public dust server which returns any registered vendor and allows applications to be built on various components created by them. The actual vendor may choose to allow the application link to dust directly, catching only local references; or act as relay to dust and other vendors to control external access from the application. It is important to know and handle the security risk of getting types and more importantly, binaries from external providers - on the other hand, knowing about and generalizing this access may lead to more stable environments.

Units

Units are the building blocks of any service, the smallest coherent component with the type declarations and the attached business logic. The Vendor can work on multiple areas, which here are called Domain, and a domain can contain multiple units. The unit focuses on solving one and only one task, perhaps in collaboration with other units. If the unit has multiple areas of interest, it has to be split by them, because some other service will later require only some of the areas, not the whole package - so the unit is better when smaller. Featuritis is not welcome here.

Having small units, it is easy to extend the system with new functions. If we have a proper minimal raw byte stream implementation with all higher level features (parsing, event management, caching, etc.) implemented in other units, it is very easy to create new stream units that wrap different network protocols, serial I/O, ... audio, ... interfaces.

The application deployment contains a Unit dictionary with a unique identifier and the actual unit information: the Vendor.Domain.Unit access path, and the actual unit version. The rest of the application declaration can refer only to the types available in the dictionary, using their local IDs. In fact, all persistent data collection, from an application configuration to a relational database behind an information system must contain this unit dictionary to be usable. When creating such collections (a saved document, a configuration file), the unit dictionary must exist in it, that allows later reading and resolution of the content.

All Vendors must be able to resolve its own path+version information to a unit declaration containing the external unit references ("imports") and the type declarations, which must be complete, all references resolved either locally or through the import. Of course, the user of the unit must also resolve the referred units, but not limited to the list that the creator used (the unit requires "a binary stream" which is resolved to a console in one and to serial I/O in another case).

The Vendor may provide business logic to the Unit. For Java, this means Java classes that implement the message processing of an Aspect of the specified Type; compiled and packed into the unit jar for the required JRE version. Right now I will only support J2SE6, but for fun or when required, it can be done for other versions. Later on I should also turn to C or other runtime environments; and a fully declarative algorithmic approach. Not right now, and not for production use.

Types

Dust types are created to extract the design knowledge from a particular programming language to a higher declaration level. "Objects" in Dust are split to the hierarchy of one single Entity (which reflects the mere existence of the represented "thing") and a collection of Aspect instances (what is that thing, what service groups it belongs to). The actual data structures and behaviors are associated to the Aspect instances; each Aspect has one Type.

The type is responsible for controlling the memory containing the data of the Aspect, the serialization, the access, rights and life cycle management (protected, final, etc. fields, relations). Therefore, any type is fully functional when the framework has its declaration, with one limitation: it has "variant" interface. The advantage of putting the programming language away (and using Maps and other objects in Java for content management) has this drawback. I should check Java annotation feature if I can get some of this support back, and have compile time type checking for example upon a generic access function.

On the other hand, this generic access allows creating a type dynamic system in environments where binary dynamic solutions are not available. For example, if I would support types through generated Java sources, they can only be accessed by extending the class loader, would need Class.forName() functions and reflection for generic access of the members. These are heavy-weight requirements, and not supported for example in GWT (which is the planned reference web environment for Dust). This is why I focus on "plain" declarative access and generic data container objects. In previous works (LogMon) I could easily avoid using string based maps for attribute access (having index-based mappers instead), with acceptable performance.

---

These features seem to be enough to initiate a Dust based environment for my current tasks.