Társas magány

Hankiss Elemér blogja üdítő olvasmány, valóban fontos és egymással összefüggő témák kerülnek fel. És halnak el a csendben... ahogy az én válaszaim is.


2012.12.07. Találjuk ki … Mit is?

Találjunk ki egy jobb országot?
...
Találjunk ki egy jobb világot?
...
Találjuk ki, hogy kik vagyunk? Hogy kik legyünk?
...
Találjuk ki, hogy mi a célja, értelme életünknek?
Találjuk ki…?

Nos, én kitaláltam egy számomra szimpatikus jövőt, amire érdemesnek tartom feltenni a saját életemet - csak sajnos túl bonyolultra sikerült ahhoz, hogy mások is megértsék. Egyedül meg nem megy... Pedig még csak nem is az itt felvetett végső kérdésekről, csupán a mai-holnapi tennivalókról van szó (és a mai napig elvezető út okairól, amelyek megértése nélkül kudarcra kárhoztatott minden "jobbító" kísérlet). http://hajnalvilag.blogspot.hu/p/globalis-agy.html

---

2013.01.04. Futball és politika

... Valahogy úgy vagyok a politikával, mint Göre Gábor/Kohn bácsi a futballal. Nem az egyik vagy másik pártnak drukkolok, hanem az országnak. És ezen belül annak, aki szebben és jobban játszik. Mindazoknak, akik többet tesznek vagy tehetnek azért, hogy az ország előre haladjon és ne hátrafelé bukdácsoljon, araszoljon.

Számomra ez meglehetősen abszurd hozzáállás és tökéletes példa. Vegyünk egy gyökeréig kompetitív szabályrendszert, tegyünk bele embereket, végül "szurkoljunk a játéknak", és ne a csapatoknak! :-D
Ehhez "csak" az kell, hogy semmilyen érzelmi kötődésünk ne legyen egyik csapathoz, játékoshoz sem (hogy ne szurkoljunk senkiÉRT), krisztusi jelleggel nézzük el az összes hibát, szabálytalanságot, esetleg durvaságot (hogy ne szurkoljunk senki ELLEN sem). Könyörgöm, ez az emberek hány százaléka által követhető minta? Nem lehetne végre észrevenni, hogy amit most a politikában, gazdaságban, társadalomban látunk, az nem egyéb, mint a legalapvetőbb motivációs törvények kikerülhetetlen következménye? Hogy nem a szereplőkkel van az igazi baj, hanem a SZEREPEKKEL, amelyeket az általunk létrehozott(!), de megváltoztathatatlannak képzelt rendszer definiál?


Ja, bocs: a kötődés viszont TÖRVÉNYSZERŰ, hiszen hatalmi pozícióról, döntéshozói helyzetről, erőforrásokhoz való hozzáférésről van szó, és mint mindig, "üzletről" (lehetőségért cserébe támogatás, "hit"). Következésképpen az itt reklámozott hozzáállás szépen hangzik, egy ideális világban értelmezhető, reálértéke viszont pontosan nulla. De hogy ne csak kritizáljak, ez meg az én mondásom ugyanebben a témában.

---

2013.01.19. „Egyetlen bajom van az életben. Az, hogy nem vagyok valaki más.” (Woody Allen)

Jól hangzik. De vajon komolyan gondolta-e ezt Woody Allen?
Megunhatja az ember magát. Néha már én is úgy érzem, hogy a saját könyökömön jövök ki. Elkopott rutinválaszaim vannak az élet különböző helyzeteire és kérdéseire. De ha választhatnék, valóban vállalnám-e azt, hogy hirtelen más valaki leszek?
Nehéz kérdés. Mert ha úgy általánosságban merül fel a dolog, persze, hogy azt mondanám: Szeretném mondjuk 20 évesen újra kezdeni az életet.
...
És Ön, kedves olvasó, hol, hogyan, milyen esélyekkel, milyen emberként kezdené újra az életét? Vagy minden megkötés nélkül volna kedve s bátorsága beleugrani az ismeretlenbe?

Nem tudom, Woody Allen komolyan gondolta-e. Általában elég tréfás formában veti fel azokat a témákat, amelyek a biológiai értelemben felnőtt homo sapiens egyedet a szellemi felnőttségtől elválasztják. Az eredeti probléma körbejárása elég részletes ebben a posztban - de vajon jó-e a kérdés? Mi van, ha máshogy fogalmazunk? Mondjuk így:

Egyetlen bajom van az életben. Nem vagyok képes önmagammal azonosulni.

Ebből viszont az a kérdés következik: Vajon miért nem vállalom azt, hogy önmagam vagyok? Miért az a fontos, hogy egy nyilvánvalóan lehetetlen gondolatkísérletben vállalnám-e az új testben, új sorsban történő megmérettetést - ahelyett, hogy jelen életemet és sorsomat tenném mérlegre?

Vajon Mózes a barlangban valóban Isten hangját hallotta? Vagy benne fogalmazódott meg a teljes önazonosság tudata: "Vagyok, aki vagyok"... és ez tette képessé arra, hogy egy nyilvánvalóan lehetetlen, ugyanakkor egyértelműen szükséges feladat megvalósítója legyen?

---

2013.01.22. A "valódi" és az "igaz"

Unos-untig idézgetjük József Attila Thomas Mann üdvözlése című versének azt a bizonyos öt sorát:

az igazat mondd, ne csak a valódit,
a fényt, amelytől világlik agyunk,
hisz egymás nélkül sötétben vagyunk.
Ahogy Hans Castorp madame Chauchat testén,
hadd lássunk át magunkon itt ez estén.

Szépek, szíven ütnek, de végiggondoltuk-e, hogy mit is jelentenek ezek a sorok? Mit jelent az, hogy „az igazat mondd, ne csak a valódit”? Mi a különbség az „igaz” és a „valódi” között? Mire gondolhatott a költő? Van valami a valóság, a mindennapi valóság mögött, ami más, több, értékesebb, „igazabb”, mint ez a valóság?
...
Nem azzal a szomorú képtelenséggel állunk-e itt szemben, hogy élünk, de nem tudjuk, hogy miről szól az életünk? S csak néha sejlik föl, sugárzik föl ez a rejtett értelem, vagy az értelem sajgó hiánya.

Megint költői kérdéseket tesz fel a tanár úr (a kifejezés minden értelmezése szerint)... Pedig az igazi kérdés egyszerű: mikor lesz végre bátorságunk elfogadni, hogy a fentiekre a válasz egyszerű, kézenfekvő, csak utáljuk? Már nincs túl sok időnk vakarózni rajta.

---

2013.01.29. Butaság vagy bátorság?

...
Eszembe jut erről egy híres középkori tanmese. Egy ember egy szörny elől menekül. Fejveszett futása közben nem veszi észre, hogy egy szakadék felé rohan. Belezuhanna, de az utolsó pillanatban még épp el tud kapni egy gyökeret. Kétségbeesetten kapaszkodik bele. A feje fölött, ott vicsorog a szörnyeteg, alatta tátong a mélység, Rémülten látja, hogy a gyökeret két egér, egy fehér és egy fekete egér rágja (a nappal és az éjszaka, vagyis a múló idő szimbólumai). A gyökér egyre vékonyul. Emberünk azonban ekkor észreveszi, hogy a gyökéren valami kis méz csorog lefelé. Erőlködik, próbál feljebb kapaszkodni, hogy lenyalhassa a mézet. Miközben, minden pillanatban a halál vár rá. Fölötte a szörny, alatta a szakadék.
Miről szól ez a történet? Az ember végtelen esendőségéről és mohóságáról? Vakságáról? Nyomorúságáról? Vagy halált megvető, hősies élni akarásáról? A reményen túli reményről? Az elmúlás elleni emberi lázadásról? 

A Zen buddhista koanok lényegét pont az adja, ami hiányzik belőlük: a leírt tanulság. Így az olvasó szabadon értelmezheti a saját gondolkodásmódja szerint. Lehet így is :-)

Business logic - brain dump

From the aspect type, a full „bean-like” interface source can be generated, and so this instance will be returned on request. The type restrictions can fully apply here. Behind the interface, a generated mapper code exists that can 1: using the generated constants it can call the generic data access/message sending

Messages: messageID is mandatory; additional parameter type optional; if present, providing a message entity with that aspect is required. Question: id is globally unique OR I can use the same id for multiple entry points with different type parameter?

From the user perspective, the message ID identifies the required service – and that is independent of the actual parameter; and anyways, practically ANY instance can be thrown on that message if it contains the required aspect. On the other hand, the message processor should be different for the different content, because the incoming parameter data has to be handled differently, though there were shared codes for the actual function.

Result: there can be multiple incoming parameter declarations for the same message IDs. The caller may send any of those parameters to the same service – actually the caller does not see the entity, only the aspect with the required type. The message processor can also be declared with the same interface…

So: the proxy implements both interfaces: provide a bean-like typed access to the local data; the referred linked entities (DATA), and the functions that can be called (SERVICE). On the service side, the user code has to implement the SERVICE interface, and has access to the wrapped DATA instance, handled by the framework.

The proxy object itself is an “aspect” instance, with direct access into the access implementation code, that is the actual executor of the proxy wrapping calls (local, no more dispatching). The same applies to the message service interface: that is linked to the dispatcher implementation. This instance is also passed to the working code; it can send message to itself through the proxy object… There is a third component: the actual data area containing the instance data? NO: that is the entity instance that contains a “map” of aspect references connected to data content.
Preliminary idea - The dispatcher contains a tree: implementation / type / loaded business logic class. The lowest level is a Method ID. This ID is returned back to the caller in a map when resolving the message IDs; on actual calls these IDs are referred to, and the actual methods are called after the proper administration. REMEMBER: this dispatcher is STATIC, able only to resolve the known type calls. Another level is responsible for loading new implementation packages, and yet another for parallel thread management. Perhaps additional aspects of the same entity… There is one problem: different implementations can coexist for the same type. The aspect statically refers to the type, but the instance (inside the Entity) may refer to other implementations. So when calling the method, two separate levels are required: the Entity for the actual implementation, and the aspect with the actual type. In this way, the Entity contains ONE ref ID to the implementation, and the Aspect knows the type IDs for the actual message identifier on the type level. Both IDs are required for calling an actual method. This looks good.

The other side does not look this complex: the memory management seems to be clear. The aspect knows its required fields. It passes to the memory manager that returns the offset for each member, and a reference in its config area. When creating an instance, this reference is used, the memory is allocated, and a block ID is returned. On data access, this block ID and the offset is required, the memory content is copied out or loaded into the memory manager area. NO direct access is allowed in the mem manager area. Here we have the locking issue, and also the configuration change features which are other aspects of the memory manager. By default it is only able to serve those instances that it already knows. The initialization is a bi-directional communication between the mem manager and the aspect instance.

Meta - architecture

Meta, because now I don't think about the architecture of the Dust framework (contexts, entities, aspects, messages), not even the connection to the running environment (wrap the hardware drivers into aspects, and thus remove the dependency to the running environment: OS or JRE), but the connection between the Dust ideas to a compiler that is able to transfer them to a computer-executable form.

I do this because I must have a vision of the core functionality without language dependency, and provide running solution to those questions in multiple languages to prove the independence - even if those solutions are fundamentally different because of the language. But first to clarify: for me, "language" means a syntax of a broadly used compiler/interpreter, with which I can reach many environments. "I" mean that I can only use my time, so something that I know or think I can learn in an acceptable time. Therefore my current focus is Java because I know this the best, and if I can use Dust in my work as well, that should be Java. I also have to provide solution to the same requirements in plain C for the contrast. For fun, I keep Objective-C for iOS, Android for other tablets, GWT for generic web interface, and maybe C# for current Windows development. From this, I found Objective-C and C# pretty straightforward environment for my concepts; GWT is mainly Java without reflection for user interface subset (and so a funny mix of Java and C concepts). I know nothing about Android, but I would be surprised if I can't make use of it in months.

I know that there are other paradigms and languages, and it is free for anyone to do a Haskell, Matlab, Prolog; Perl, PHP, Javascript, Ruby or Brainf*ck implementation for the Dust kernel. From my point of view that would be equal waste of time: I don't know these languages, and I don't think that there are environments that can only be used with them and not by the above mentioned ones. To be honest: I don't see too much real value in them either, but that is my private opinion.

"No Dust"

I have concluded to the statement of "there is no Dust Framework". Of course this is not about the existence but the visibility. Yes, the framework exists, a Dust programmer has to know about its structure and yes, the solution will be dependent on the other components one uses, including the framework components. But Dust kernel components and services do not appear on programming environment level, and if you want to provide different implementation, or even different architecture for the Dust kernel services, you are free to do so. Of course that solution will not be compatible with the standard Dust environment, and as the drivers and tools use the kernel too, you would have to reimplement them as well to make your solution run. Or, you can even create a "virtual machine" for your altering kernel inside a standard Dust runtime. But I got far from the original aim.

So, Dust kernel itself is (and should be) invisible on the language level, because we use the language only to provide functionality (behavior) behind the aspect declarations (made either by you or someone else) that can be used in a running Dust environment. So we have the following requirements:

• access data and send messages
• let the runtime identify and call my function on an incoming message
• the code should be able to utilize elements of the (language independent, Dust based) type declarations with the most compiler support (type safety, compile-time warnings or errors)

These functions can be fulfilled very differently in an OO environment (Java) and in plain C of course, but having them provided means that Dust components (even the kernel itself) can be implemented in that language. For a side note: yes, it gives a transparent break through language barrier: you don't have to know that the actual runtime was implemented in C and runs on native level; if it has a Java loader, it can use your components implemented in Java - or vice versa.

Access data / send messages

When the code talks to the environment, this means that it refers to some components around it through identifiers, and the environment should resolve those identifiers to actual component data or service calls. The "context" is (quite poorly though) handled in OO languages with the existence of "this"-like built in language construct through which the code can access its "own" data, so in theory Dust can utilize this - but this has limitations:

• of course there is no such support in non-OO environments;
• even in Java-like environment, if the object provides the gateway to the kernel, it should have to be passed all the way round when calling other services. Not very nice.

For these reasons, and because I want to promote a kind of language-independent Dust coding style, I vote on similar solution, and this means adhering to the limitations of the weaker environment, C. Dust service appears as a final static global object for Java, and as the "send", "get", "set" functions in C. One, totally generic header file included in the code, and it can use Dust - and through this gateway all the functions of all the referred components (including the kernel of course). 

Any code can use these functions, the Dust kernel on the other side has to know the actual context - and yes: you can't play tricks with it. For an OO programmer, this should feel bad: using a super language like a script. On the other hand: the "superness" of that language is not the syntax itself, but the huge set of service components built into the running environment (GUI, persistence, ...), the way that language supports building the data and application structures (classes, reflection, ...) and environment (session information, connection pools, threading). But hey: these things belong to the abstract, language and environment independent architecture of the service, and in fact they should not be burned into a specific running environment.

OR... Convenience

I plan to generate code for the identifiers from Dust declarations in the target language. Why not generate wrapper classes for the types? That would hide the strange behaviors of Dust, would support more type safety, compilation errors when using the wrong identifier on accessing a component. It would also make Dust even more hidden from the programmer, and would make Dust programming very similar to the "normal" way.

Well, at this point I can't decide if I should implement this layer or not. The above reasons are very strong:

• having compile-time errors on access and type issues instead of runtime exceptions is very important;
• when I write implementation and use another component, I really "lock" myself to it. Dust declaration means a strict separation of public interface and private implementation; the provider can change the code, or I can switch to another provider - the interface must be consistent;
• "esoteric": this way Dust can really disappear.

What does it mean to C codes? In each implementation source you can have typed accessor functions to the declared data and message senders (including to "this" with a special reference constant). This might result that a code that does not use direct casting and does not play with void* and can be compiled will be valid as well.

The result is a totally "normal" implementation code. The only difference is that the "connection" of that code (constants, internal and public interfaces) are generated from the declarations and not typed manually - which of course guarantees following the standards with them. When you use a unit, you also get the generated public interface, and can access the methods "normally" - even though that may go through the Dust kernel, sometimes to another core or a separate running node.

I have to admit that this may worth the extra effort, even though I am very far from the point when the required sources can be generated, and I would need running Dust subset to generate them. Or should I type them in? Is it really the point where my absolute favorite KISS rule should be broken?

Or: this is actually the absolute KISS rule: the framework with a minimal footprint on the application level code. In fact, that footprint is actually none. I like that, so even though looks tough, I should follow this direction until it breaks.

Integrating my logic to Dust

TBD

Identifiers

TBD

Dust is a journey

"Life is a journey, not a destination"

Although the origin is not that clear, I have heard this sentence in Amazing from Aerosmith - remember the time when pop music was not trapped in "love me baby" / "I hate the world" / "life sucks" triangle, but actually had lyrics that is worth reading and thinking about... :-)

Finally I have realized why I write a blog about Dust development instead of a wiki specification.

Of course it is a question if the whole idea has meaning, the fundamental question is good and I am looking for the answer in the right direction. But this is a question I can't answer, because this is my faith and passion that this has to exist, has to be written in this way, and I can write it. I can be wrong of course, but what a great way of making mistake this is! And anyway, being an employee now I plan to get a lot of money on using experiences that it gave me; and even if it is finally wrong, you can also find some useful ideas in it.

But what if it is right? I think it should turn the industry upside down. I think it can let us use the full power that we already have in the smallest gadgets (I started programming on machines that had less power than a ... I can't even think of any nowadays smart toys of that weak performance: 640k RAM? 4.77 Mhz (but had Turbo button)? 20MB HDD?). I think it means that what we call crap today can connect huge amount of less fortunate people to our technically global, but economically very limited world. I think the epic failure of a Java processor can be tried again: the Dust kernel is a better choice to be implemented in silicon; the hardware can know all applications internally, and adapt to them, optimize the behavior; Dust is inherently parallel, not by letting the programmer control threads but this is a fundamental element of the software component design.
All in all, I think huge mass of people would benefit from it - and this makes it worth the time and effort for that very little chance. But they will not understand the whole thing at all, which is not a problem.

There should be lots of adopters, who would understand a specification and can use it. For them, Dust will mean truly reusable designs (for more forethinking of course), having the housekeeping done by previous standard components in really any environment, etc. They will give the muscles to Dust, but sorry, I don't really write this blog for them.

There must be some people who will follow the way I think about Dust. They must take over this obsession of something that must be brought to life, to this world. To always take the longest, most weird path through a swamp if they feel that they must go that way - even if there is no light on the other end. And to understand why I do this, what experience and vision forces me doing this now. I publish this blog for that few dozen people out in the world now, or at any later time. They should take this concept further than I could, because of my limited knowledge and time.

So for them: yes, it's ridiculous how I am linked to Esperanto for both any programmer (why not use English, bro?) or for an Esperantist (you don't know the language at all, man!). But I have a very strong vision that Esperanto is an existing, full language; its grammar can be formalized and used to express any state of the world or exact orders without ambiguities; even the speech to text conversion is easier because of the fixed position of the accentuated syllable. Finally, I want to be able to express actually anything in Esperanto, and that should be understandable and executable orders to the Dust environment.

I had the same strong vision before, like "use message object only instead of call parameters", "there is no difference between service and data objects" - the result is a fully declarative software architecture; "the OO paradigm and the Operating System itself is a very useful but fatal failure" - and I could switch to C# in weeks for a POC system; I could design and implement a production system in Objective-C. I feel the same now.

Self containing framework

And here I am again at the root question: how does a Dust application start up? With the addition of the new idea that "there is no Dust framework"... The latter means that there is no static entry point, no framework functions; all such thing are done by the kondutos of the Dust core terms. The only interesting thing is that the "main" function has to set up those items and connect them to each other: this core component network is able to serve the basic functions: message passing and data/reference access requests. Later, when I can add other unuos like serialization, binary loading, GUI, etc, then the framework can stand on its feet.

But first of all, I have to start up the self containing core service network. To do this, I have to create a kunteksto, and put the root components into it in the root initialization call. This code will be generated later from the system deployment information, but now of course I have to write this code myself.

The kunteksto, as this will go later, can be modified in a transaction. I can send ento initialization information (not actual instances, because the objects must be created by the kunteksto - on the other hand: how can the kunteksto create external, not yet added types? hmm...) The ento contains one or more aspektos with initial data and references to other entos. The references are resolved in a lazy creation fashion, so the referred ones get placeholders in the kunteksto, and later when their actual content arrives, are initialized. At the end, the transaction is committed - at this point this means the kunteksto runs a consistency check if all the references are resolved. The kunteksto ento is added to itself (because it is also referred from the entos inside).

At this point I will have a kunteksto from which I can access different functions, but naturally it would not be "Dust-like", so instead of this, I also have to add a test "Runnable" ento, and do those actions in its run message processor. Later on, drivers, external message handlers, etc. will be "Runnable" and started in this way.

Identifiers

This is where the nice idea seems to fail. The identifier (identigilo) is a string constant; the instance should represent its own name. The instance should be

• accessible for the user codes (in generated sources the coder will use them);
• should not be mixed with external objects (cannot be created by the user code, and the messages should contain only these constant values)

It is so nice that I keep forgetting what I already thought over... All components, including this initial framework core is inside a realigo: it has a connection interface to the framework - to itself. The identifiers are generated source codes: enums; the access functions use these enums. On the other hand, the framework resolves the names (the enum name strings) to actual identifier instances, which are lazy created. Now I have to type the eums, but later on that code will also be generated from the identigilos in the unuo. The enum strings are loaded into the global identifier table, and also attached to the enum order number table contained in the realigo. So the client code refers to the table index through the enum, and the reference is resolved by the framework by the enum name at the first call.

The only difference is that during the initialization, this local index table is pushed directly into the kunteksto from the source code.

What to add?

... to be continued...

A "pártatlanság vélelme"

Hankiss Elemér blogján

Valahogy úgy vagyok a politikával, mint Göre Gábor/Kohn bácsi a futballal. Nem az egyik vagy másik pártnak drukkolok, hanem az országnak.  És ezen belül annak, aki szebben és jobban játszik. Mindazoknak, akik többet tesznek vagy tehetnek azért, hogy az ország előre haladjon és ne hátrafelé bukdácsoljon, araszoljon. 

Számomra ez meglehetősen abszurd hozzáállás és tökéletes példa. Vegyünk egy gyökeréig kompetitív szabályrendszert, tegyünk bele embereket, végül "szurkoljunk a játéknak", és ne a csapatoknak! :-D Ehhez "csak" az kell, hogy semmilyen érzelmi kötődésünk ne legyen egyik csapathoz, játékoshoz sem (hogy ne szurkoljunk senkiért), krisztusi jelleggel nézzük el az összes hibát, szabálytalanságot, esetleg durvaságot (hogy ne szurkoljunk senki ellen sem).

Könyörgöm, ez az emberek hány százaléka által követhető minta? Nem lehetne végre észrevenni, hogy amit most a politikában, gazdaságban, társadalomban látunk, az nem egyéb, mint a legalapvetőbb motivációs törvények kikerülhetetlen következménye? Hogy nem a szereplőkkel van az igazi baj, hanem a szerepekkel, amelyeket az általunk létrehozott(!), de megváltoztathatatlannak képzelt rendszer definiál?

Ja, bocs: a kötődés viszont törvényszerű, hiszen hatalmi pozícióról, döntéshozói helyzetről, erőforrásokhoz való hozzáférésről van szó, és mint mindig, "üzletről" (lehetőségért cserébe támogatás, "hit"). Következésképpen az itt reklámozott hozzáállás szépen hangzik, egy ideális világban értelmezhető, reálértéke viszont pontosan nulla. De hogy ne csak kritizáljak, ez meg az én mondásom ugyanebben a témában.

Dust core terms

Now trying to collect the first terms in the Dust vocabulary.

Meta-meta layer

• identigilo: Generic variable type for identifying core data elements: attributes, messages, references. Atomic information, general implementation is an ASCII string identifier (small and upper case English characters, numbers, underscore). Has NO functionality, works like generic constant variable for declaration-level codes (like a GUI display or expression); high level business logic components "see" the identifiers through generated source constants (enum and alike). Not to be confused with the unique identifiers of entities (although it works as that for the core elements, but only within the closest context).
• variablodeklaro: The declaration information of one variable, either a local temporal value in a certain context or a member value inside a type. This connects an identigilo to a usage information structure: data type, life cycle (constant, final, modifiable, etc), ... contained within this component. The identifier must be unique in its actual context, as the value is referred to by it. The type may either be a generic type or a (single or multi-value) reference to other aspects. Handling references is different from generic data, but the identification, passing and resolving should "look similar", especially in expressions and language constructs, this is why they both covered by this component. Side note: "value set" for option selector is handled by a set reference to other entos in this type: the elements of that enumeration are entos themselves. This is different from 
• tipo: This is similar to the normal "type" or "class", contains 0-n variablodeklaro elements forming the "data context", and a list of other tipos that it can accept. All kondutos (business logic) are implemented as being inside the context of an aspekto ("object instance of tipo "class"), that gives the "member variables and references". All logic entry points are reactions to an incoming "message": ento with the primary aspekto of the referred tipo. Furthermore, each tipo contains 0-n "required" tipo elements, which are also required to exist in the same ento. The business logic can refer to these other aspektos of those tipos as present, this feature provides behaviors similar to inherintance without the forces tree structure.
• datumo (generic type) wrapper type for generic types handled by Dust: boolean, integer, etc. The common set is extended by identigilo, which is also a "generic type" in Dust. Funny question: I started reducing this set by saying: no, string is not generic, float is not generic; what remains? Integers with different byte size, like in assembly, and the special identigilo. Am I surprised?

Meta layer

• aspekto: This is similar to the normal "type" or "class", although in Dust you have no independent "Object instances" by an aspekto. It contains 0-n variablodeklaro elements forming the "data context", and a list of other aspektos that it can accept. All business logic are implemented as being inside the context of an aspekto, that gives the "member variables and references" of the business logic. All logic entry points are reactions to an incoming aspekto "message". Furthermore, each aspekto contains 0-n "required" aspekto elements, which are also required to exist in the same ento. The business logic can refer to these other aspektos as present, this feature provides behaviors similar to inherintance without the forces tree structure.
• ento: Entity, a programming object instance inside Dust representing a "being" either in the outer world  (like a person, a booked resource, ...) or inside the virtual world of the running environment (like a GUI element, an event message or even an exception). Each ento has at least one aspekto, and always have a primaraaspekto, which the ento "is".
• kunteksto: container of entos and their relationships. Responsible for storing, resolving ento instances and also for their relationships (which is not stored inside the entos). The kuntekstos form a tree, the root is the first, meta-kunteksto. The connection is invisible for the entos inside, any resolution request not found in the current kunteksto is passed up to the parent until the root. The root kunteksto contains itself as a normal ento, and (as far as I think now) all the other kunteksto instances as well. However, a child kunteksto may contain internal kuntekstos acting as a "virtual machine".

Term context

• vendanto (vendor): the responsible owner of terms and behaviors, responsible for the coherence and the unique identification of the provided element tree.
• bieno (domain, field): the higher area of connected terms. From the application point of view, bieno is the highest level: "all" terms that are handled by Dust has to be distributed into disjunctive, coherent subsets: these domains. However, this is life, different owners can have altering ideas of these domains, their separation and content, there can be multiple, competing alternatives. So, Dust does not try to enforce its own structure as "the" solution, the framework (as meta layer) is designed to handle multiple approaches from different vendors (Dust is only one of them). This is why bieno is under vendanto.
• unuo: a "working unit" inside a bieno. Unuos contain a set of tipos; and an optional list of referred unuos. The tipos can only refer to other tipos from the registered unuos. The Dust running environment ("an application") consists of several unuos, where these references are all resolved within the set, so all used tipos have their declaration and behavior loaded. 

Service layer

• konduto (behavior): the application logic assigned to a tipo. The konduto itself is stateless, exists in one instance, has no "member variables" in any programming language. However, is can be stateful by injecting a workarea object into the aspekto that it handles, so when needed, it can analyze the data (publicly available and handled by Dust), but store local information to it to speed up processing. However, such entos will be harder to serialize (for example).
• realigo: an unuo has a single declaration, but possibly multiple implementations for different actual running environments, like drivers, GUI display frameworks, etc. A vendor an provide multiple realigos for the same unuo, even for unuos from other vendors. Entos representing an actual hardware have to be bound to their own realigo. The realigo contains kondutos for some or all of the tipos in the unuo. Question: what happens when a specialized konduto for an ento refers to a shared ento that has different kondutos in the available realigos?
• sendito (behavior container): in the kunteksto, this component contains the kondutos of the knows tipos. Responsible for calling the proper method with the target aspekto and the received message ento.