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.
2012. október 26., péntek
2012. október 25., csütörtök
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
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.
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.
2012. október 23., kedd
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.
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.
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.
2012. október 20., szombat
Igen, ilyen méregzsák vagyok!
2012.október.20th. at 10:45
Ugyan már! A te fogalmaid szerint egyáltalán nem vagyok “jó fej”, ahogy gyakran emlegeted is.
Tisztelem a megalapozott tudást, a konstruktív, őszinte véleményalkotást, a személyes felelősség felvállalását és az értelmes erőfeszítést. Arnie Gundersenben mindegyik megvan, és örömmel teszem hozzá a magam munkáját. (Egyébként fel van festve a pálya. Egy negyedórás film nekem kb. öt órába kerül, mert van hozzá angol átirat. Be kell regisztrálni az universalsubtitles.org-ra, az átirat szöveget betördelni, feltölteni, időzítem, majd lefordítani. Úgy látom, az egész világon nem túl népszerű ez a hobbi, pedig az itt közölt adatok előtt kár, hogy akadály a nyelvismeret hiánya. Most viszont már időm sincs rá – kár, hogy a Greenpeace-nek sincs…)
Herótom van ugyanakkor a felületességtől, a destruktív és titkolózó véleményalkotástól, a személyes felelősségtől való berzenkedéstől, továbbá a szájkaratéval palástolt passzivitástól illetve a logikus gondolkodással simán elkerülhető értelmetlen szerencsétlenkedéstől. Itt mindez bőven megtalálható, így csak a kritikámat tudom hozzátenni. Bővebbet csak akkor, ha elönt a reménykedés, de minden egyes alkalommal a hamvába hal – így aztán egyre jellemzőbb a rövid beszólás.
Például: “Mit szólnátok, ha indítanánk egy aprócska mozgalmat a magyar korrupció ellen?”
Válaszom: “Értelmetlen szerencsétlenkedés.”
De kit érdekel ez? Főleg, ha az indoklás nem három elkiabálható vagy pólóra festhető mondat; megértése gondolkodás, önvizsgálat, némi történelem ismeret és előítélet-mentesség nélkül lehetetlen?
A blogomon nem “kivonatokat gyűjtök”, hanem MINDEN érdemi megszólalásom teljes terjedelmében ott van, másokéból annyit idézek, amire engedélyt kapok vagy ami a megértéshez muszáj, viszont linket mindenhová teszek. Egyrészt azért, mert úgy gondolom, mindenkinek joga rólam véleményt alkotni, ehhez én ezzel tudok hozzájárulni. Nem törlök vagy módosítok utólag tartalmi szinten, mert sokkal fontosabb tanulságot hordoz a korábbi tévedés annál, hogy utólag érdemes lenne reszelgetni rajta.
Másfelől így már nyugodt lélekkel mondok rövid véleményt, hiszen irgalmatlan mennyiségű időt töltöttem különféle környezetekben például a fenti véleményem indoklásával, totális értetlenséget és/vagy személyeskedő beszólásokat “aratva”. Itt is, pont ezzel a témával kapcsolatban is. Akinek van türelme, elolvashatja és érdemi érveket hozhat ellene. Akinek nincs, így bunkónak nevez, ha sokat magyarázok, akkor meg lehülyéz vagy megunja. Az idő pedig drága...
És EZ a szöveg is ismétlés, íme a blogon az egyik korábbi változat, vicces módon majdnem egyidős az itteni bejegyzéssel.
2012.október.20th. at 17:09
Oké, megpróbálok leírni valamit, amit eddig emlékeim szerint még nem tettem, így van értelme a dolognak. Vigyázat, példabeszéd, asszociációs képességeket betölteni!
Szóval egy valódi párbeszéd olyan, mint egy sakkjátszma. A sakknak része a megfelelő tábla és a bábuk, de valójában nem is szükségesek hozzá: sakkozni lehet porba rajzolt rácson kavicsokkal is, vagy akár fejben, minden segédeszköz nélkül – ha nagyon profi vagy. Egy gyerek ugyanakkor a legtökéletesebb táblán SEM tud sakkozni… A sakk ugyanis nem a tábla meg a bábuk, hanem a szabályok ismerete és betartása, akkor is, amikor vesztésre állunk a táblán. Ugyanis még magasabb szinten egy játszma értékét nem az adja, hogy ki nyer vagy veszít, hanem hogy mit sikerül megtanulni közben! Ezt veszíti el mindenki, aki akár csak megpróbálkozik a csalással.
Ezt nem képes vagy hajlandó például belátni a mai kormányzat. Igen, hatalma van megváltoztatni a szabályokat, úgy játszik, mint egy ostoba gyerek: ide-oda rakja a bábukat, és közben izgatottan kiabál. Azok viszont, akik rendesen játszanának, kapkodják a fejüket, igyekeznek alkalmazkodni, de a sokadik értelmezhetetlen lépés után felállnak az asztaltól. Az is, akinek még nem “adtak mattot”. EZÉRT értelmetlen a hazafias szöveg: korrekt és betartott szabályok hiányában nem lehet helyesen játszani. Viszont ugyanezért értelmetlen ugyanilyen hibás gondolkodással “megoldást keresni”.
Lássunk egy példát! Az első mondatod helyes, valóban értetlenül olvastad a reakciómat. A vita szabályai szerint ilyenkor KÉRDÉS következik. Mondjuk: “Agresszívnak tűnik a válaszod. Talán tőlem is herótod van?” Erre a válaszom természetesen “Igen”, egyébként nem lennék agresszív, tehát nem kell megkérdezni, és mehetünk tovább: “Talán felületes vagyok? Mutass példát arra, amikor szerinted felületes voltam!” Tudnék, de felesleges, hiszen ha ugyanolyan felületesen nézed, akkor hiába mutogatok; ha viszont alaposan, akkor magadtól is feltűnik. Akár kizárólag ebben a válaszodban. Viszont minderre nincs szükség, hiszen kérdés helyett tanácsot adsz nekem immár sokadszor, ahelyett, hogy akár kísérletet tennél a leírtak végiggondolására.
Ismétlem, TUDOM, a te fogalmaid szerint most sem vagyok “jó fej”. Durván annyi hajlékonyság van bennem, mint egy baltában, ugyanis itt arról van szó, hogy mit tehetünk a jövőnk érdekében, és ez nem vicc, nem lehet szerencsétlenkedni. Kegyetlen következményeket húzunk magunkra a mostani teszetosza szerencsétlenkedésünkkel, amit kizárólag mértani pontosságú gondolkodással úszhatunk meg. Talán. Nagyon pici eséllyel.
Súlyos félreértés, hogy én barátkozni vagy jófejkedni jönnék ide, vagy csinálnék bármit a neten. Arra megvan a saját személyes életem, ismerőseim, régi és új kollégáim, akik úgy tűnik, jó fejnek tartanak (és nyilván te is így lennél vele). De nem beszélünk ilyen témákról, mert akkor velük is ugyanilyen kemény leszek, és ugyanúgy elhallgatunk egy ponton, mint itt. Így leszek egy szinten túl teljesen egyedül. És ezért karattyolok itt, mert közben olyasmivel foglalkozom, amiben piszok jó lenne nem egyedül lenni. Röviden: minden hitem és önbizalmam kevésnek tűnik hozzá. Persze, ilyen is volt már párszor.
Ennyi. Légy jó, és ha találsz valami értékes angol videót a neten (mondjuk a Fairewinds-en), fordítsd le és oszd meg azokkal, akik nem tudnak elég jól angolul. Ha jut rá, szerintem megéri az időt.
2012.október.21st. at 06:24
Legjobb tudásom szerint SENKI nem születik a logikus gondolkodás, az érdemi vita képességével – ugyanis ez NEM képessége az emberi agynak, éppen ellentétes minden biológiai, lélektani és evolúciós kötöttséggel. EZÉRT töltöttek annyi időt a görögök (vagy mondjuk a tibeti buddhisták) a szabályok megkeresésével, és (a legjobb képességű jelöltekből válogatott) minden egyes tanuló esetén éveket csak azzal, hogy ezt láthatóvá tegyék a számukra.
Nem szerencsés, hogy ezt ma bárki, aki képes kezelni egy billentyűzetet, a magáénak véli.
Vajon miért sakkozik bárki nála jobb sakkozóval? Azért, hogy TANULJON belőle, és egy napon jobb legyen nála.
Miért sakkozik a mester bárkivel? Mert tudatában van saját múlandóságának, tehát az tény, hogy egy napon MINDENKI jobb lesz nála – viszont szeretné, ha ez nem jelentené a színvonal csökkenését. Ja, még valami: “abszolút mester” nem létezik, a jobb játékos többet tanul ugyanabból a partiból…
Hmm? :-)
Tehát “kicsiben”, egyéni szinten lenne végre ideje a “felébredésnek”, a valós problémákat fontossági sorrendbe állítva a megoldásokat keresni ahelyett, hogy mesevilágbeli történetekkel szórakoztatjuk egymást.
És igen, REMÉNYKEDNI, hogy amíg nem szedjük össze magunkat a szükséges mértékben, addig nem lesz újabb gond. Van esetleg hatékonyabb javaslat? Telefon a Jóistenhez vagy a “világ vezetőihez”? Fukushima megakoncert? Imakör és transzcendentális meditáció? :-)
1: Ott is EMBEREK élnek, ugyanolyan joggal a létezéshez, mint bármelyikünk. 2: A keletkező szennyezés radioaktív, százezer évre határozza meg az utódaink sorsát az egész bolygón.
Tudom, te kiábrándultál a saját utódaidból, sajnálom, hogy köpsz a következő generációra, sajnálom, hogy ezt jogosnak érzed, sajnálom, hogy egyáltalán megengeded magadnak.
Szerintem semmi közöm ahhoz, amit TE “megoldásnak” képzelsz, a (valóban értékes) tudásodból gyerekes kliséhalmaz által építesz rendszert. Inkább vállalod a felületességet, az ordító önellentmondásokat, inkább nevezel elmebetegnek, tudatlannak, romantikusnak vagy emberi gondolkodáshoz nem értő technokratának, minthogy ezt megvitasd. (Nem mintha kedvem lenne újra megpróbálni.)
Te épp mostanában mondtál egy szintednek megfelelő viccet. “Tibor bá mozgalmat indít a korrupció felszámolására!” Ahogy korábban írtam: igen, személyesen koccinthatnánk és nevethetnénk rajta egy jót – de erre nekem megvan a saját életem és barátaim. Ez a téma viszont szerintem alkalmatlan a humorizálásra. Egy életveszélyben lévő beteg mellett a műtőben szerintem nincs sok ok a koccintgatásra, de a “próbáljuk meg talán ezt” típusú vagdalkozásra, vagy a “a hülye, minek ment oda” utólagos okoskodásra sem. Itt és most, egyetlen esélyünk van. Szerintem. És elnézést, hogy ha jobb nincs, ha más nincs, én igyekszem orvosként hozzáállni. Nem hentesként, kuruzslóként vagy humorista szerepben. Tudom, hogy egy igen szűk részterületen rendelkezem csak szaktudással, és hogy nagyon kicsi a mozgásterem – tehát valóban: önmagában értéktelen, akár sikerül, akár nem.
Arról, hogy ez számodra “tudom a megoldást” és “csatlakozz hozzám” címszavakra fordul le, nem tehetek. Arról sem, hogy bátorkodsz röviden összefoglalni azt, amiről az előző mondatban is azt állítod, érthetetlen. A rólam szóló összefoglaló MAJDNEM pontos, a hiba a fogalmak használatában és értelmezésében van. Az eltérés körülbelül annyi, mint egy lélegző és egy nem lélegző ember között.
2012.október.22nd. at 19:58
Köszönöm a hozzászólásokat, de közben volt egy érdekes élményem, talán ezt hívják “kegyelemnek” azok, akik komolyan foglalkoznak vele. A véleményem változatlan, de sokkal kevésbé tűnik fontosnak, mint akár egy nappal ezelőtt. Nem is rabolom vele tovább az időtöket.
Az Apokalipszis inkább meditatív dolog a részemről. Bár itt szándékosan nem teregetem gondolkodásomnak ezt az oldalát, de be kell vallanom: nem “bulvár”, nem “szekta-buli”, minden szavát komolyan gondolom; amit magamról írok, valóban így történt és történik.
Ebben a körben inkább ezzel az írással szeretnék “nyomot hagyni”… szerintem néhány felvetett kérdésre választ is ad.
2012.október.23rd. at 09:30
Nem kell túllihegni, semmi különleges új meglátás, öt szóban összefoglalható überbigyó nincs, ha ez érdekelne bárkit, keresgéljen az Édesvíz kiadó és társai körül :-) Én ugyanaz a dagályos techno-pszicho-barbár vagyok, mint eddig; a kapcsolódó dolgokat már régen leírtam. Viszont úgy érzem, megszabadultam végre attól a megmagyarázhatatlan belső késztetéstől, hogy itt tépjem a szám. Lényegében ennyi történt, csak mivel ment itt egy kör rólam, gondoltam nem lépek le szó nélkül.
Az Apokalipszisre meg azért szóltam vissza, mert szerintem nagyságrendekkel nehezebben érthető (az én fogalmaim szerint: sokkal szélesebb analógia-hálózatra épül), mint az itt kritizált szövegeim, tehát pont a “közérthetőségre” kifejezetten rossz példa – azért ajánlottam másikat. Örülnék, ha Tibor bá mégis visszatenné a linket, ha cserébe megígérem, hogy tényleg nem etikátlankodom és olvasóhalászok itt tovább :-D
97, Jani: Tök jó fej dolog tőled ez a video-fordítgatás. ... Az is tetszik, ahogy odagyűjtöd a különböző fórumokon zajlott vitáid kivonatát.
Ugyan már! A te fogalmaid szerint egyáltalán nem vagyok “jó fej”, ahogy gyakran emlegeted is.
Tisztelem a megalapozott tudást, a konstruktív, őszinte véleményalkotást, a személyes felelősség felvállalását és az értelmes erőfeszítést. Arnie Gundersenben mindegyik megvan, és örömmel teszem hozzá a magam munkáját. (Egyébként fel van festve a pálya. Egy negyedórás film nekem kb. öt órába kerül, mert van hozzá angol átirat. Be kell regisztrálni az universalsubtitles.org-ra, az átirat szöveget betördelni, feltölteni, időzítem, majd lefordítani. Úgy látom, az egész világon nem túl népszerű ez a hobbi, pedig az itt közölt adatok előtt kár, hogy akadály a nyelvismeret hiánya. Most viszont már időm sincs rá – kár, hogy a Greenpeace-nek sincs…)
Herótom van ugyanakkor a felületességtől, a destruktív és titkolózó véleményalkotástól, a személyes felelősségtől való berzenkedéstől, továbbá a szájkaratéval palástolt passzivitástól illetve a logikus gondolkodással simán elkerülhető értelmetlen szerencsétlenkedéstől. Itt mindez bőven megtalálható, így csak a kritikámat tudom hozzátenni. Bővebbet csak akkor, ha elönt a reménykedés, de minden egyes alkalommal a hamvába hal – így aztán egyre jellemzőbb a rövid beszólás.
Például: “Mit szólnátok, ha indítanánk egy aprócska mozgalmat a magyar korrupció ellen?”
Válaszom: “Értelmetlen szerencsétlenkedés.”
De kit érdekel ez? Főleg, ha az indoklás nem három elkiabálható vagy pólóra festhető mondat; megértése gondolkodás, önvizsgálat, némi történelem ismeret és előítélet-mentesség nélkül lehetetlen?
A blogomon nem “kivonatokat gyűjtök”, hanem MINDEN érdemi megszólalásom teljes terjedelmében ott van, másokéból annyit idézek, amire engedélyt kapok vagy ami a megértéshez muszáj, viszont linket mindenhová teszek. Egyrészt azért, mert úgy gondolom, mindenkinek joga rólam véleményt alkotni, ehhez én ezzel tudok hozzájárulni. Nem törlök vagy módosítok utólag tartalmi szinten, mert sokkal fontosabb tanulságot hordoz a korábbi tévedés annál, hogy utólag érdemes lenne reszelgetni rajta.
Másfelől így már nyugodt lélekkel mondok rövid véleményt, hiszen irgalmatlan mennyiségű időt töltöttem különféle környezetekben például a fenti véleményem indoklásával, totális értetlenséget és/vagy személyeskedő beszólásokat “aratva”. Itt is, pont ezzel a témával kapcsolatban is. Akinek van türelme, elolvashatja és érdemi érveket hozhat ellene. Akinek nincs, így bunkónak nevez, ha sokat magyarázok, akkor meg lehülyéz vagy megunja. Az idő pedig drága...
És EZ a szöveg is ismétlés, íme a blogon az egyik korábbi változat, vicces módon majdnem egyidős az itteni bejegyzéssel.
2012.október.20th. at 17:09
99, Jani: Kissé értetlenül olvastam a reakciódat. Az előző hozzászólásomban éppen méltányoltam önfeláldozó fordítási tevékenységed. Abban is tévedsz, hogy ne tartanálak jó fejnek.Azért írtam kivonatot, mert azt rakod oda, amit te lényeginek gondolsz, nem a teljes vonatkozó párbeszédet. Legalábbis egy velem folytatott szóváltást csak részben láttam.Szerintem, ne legyél ilyen agresszív.
Oké, megpróbálok leírni valamit, amit eddig emlékeim szerint még nem tettem, így van értelme a dolognak. Vigyázat, példabeszéd, asszociációs képességeket betölteni!
Szóval egy valódi párbeszéd olyan, mint egy sakkjátszma. A sakknak része a megfelelő tábla és a bábuk, de valójában nem is szükségesek hozzá: sakkozni lehet porba rajzolt rácson kavicsokkal is, vagy akár fejben, minden segédeszköz nélkül – ha nagyon profi vagy. Egy gyerek ugyanakkor a legtökéletesebb táblán SEM tud sakkozni… A sakk ugyanis nem a tábla meg a bábuk, hanem a szabályok ismerete és betartása, akkor is, amikor vesztésre állunk a táblán. Ugyanis még magasabb szinten egy játszma értékét nem az adja, hogy ki nyer vagy veszít, hanem hogy mit sikerül megtanulni közben! Ezt veszíti el mindenki, aki akár csak megpróbálkozik a csalással.
Ezt nem képes vagy hajlandó például belátni a mai kormányzat. Igen, hatalma van megváltoztatni a szabályokat, úgy játszik, mint egy ostoba gyerek: ide-oda rakja a bábukat, és közben izgatottan kiabál. Azok viszont, akik rendesen játszanának, kapkodják a fejüket, igyekeznek alkalmazkodni, de a sokadik értelmezhetetlen lépés után felállnak az asztaltól. Az is, akinek még nem “adtak mattot”. EZÉRT értelmetlen a hazafias szöveg: korrekt és betartott szabályok hiányában nem lehet helyesen játszani. Viszont ugyanezért értelmetlen ugyanilyen hibás gondolkodással “megoldást keresni”.
Lássunk egy példát! Az első mondatod helyes, valóban értetlenül olvastad a reakciómat. A vita szabályai szerint ilyenkor KÉRDÉS következik. Mondjuk: “Agresszívnak tűnik a válaszod. Talán tőlem is herótod van?” Erre a válaszom természetesen “Igen”, egyébként nem lennék agresszív, tehát nem kell megkérdezni, és mehetünk tovább: “Talán felületes vagyok? Mutass példát arra, amikor szerinted felületes voltam!” Tudnék, de felesleges, hiszen ha ugyanolyan felületesen nézed, akkor hiába mutogatok; ha viszont alaposan, akkor magadtól is feltűnik. Akár kizárólag ebben a válaszodban. Viszont minderre nincs szükség, hiszen kérdés helyett tanácsot adsz nekem immár sokadszor, ahelyett, hogy akár kísérletet tennél a leírtak végiggondolására.
Ismétlem, TUDOM, a te fogalmaid szerint most sem vagyok “jó fej”. Durván annyi hajlékonyság van bennem, mint egy baltában, ugyanis itt arról van szó, hogy mit tehetünk a jövőnk érdekében, és ez nem vicc, nem lehet szerencsétlenkedni. Kegyetlen következményeket húzunk magunkra a mostani teszetosza szerencsétlenkedésünkkel, amit kizárólag mértani pontosságú gondolkodással úszhatunk meg. Talán. Nagyon pici eséllyel.
Súlyos félreértés, hogy én barátkozni vagy jófejkedni jönnék ide, vagy csinálnék bármit a neten. Arra megvan a saját személyes életem, ismerőseim, régi és új kollégáim, akik úgy tűnik, jó fejnek tartanak (és nyilván te is így lennél vele). De nem beszélünk ilyen témákról, mert akkor velük is ugyanilyen kemény leszek, és ugyanúgy elhallgatunk egy ponton, mint itt. Így leszek egy szinten túl teljesen egyedül. És ezért karattyolok itt, mert közben olyasmivel foglalkozom, amiben piszok jó lenne nem egyedül lenni. Röviden: minden hitem és önbizalmam kevésnek tűnik hozzá. Persze, ilyen is volt már párszor.
Ennyi. Légy jó, és ha találsz valami értékes angol videót a neten (mondjuk a Fairewinds-en), fordítsd le és oszd meg azokkal, akik nem tudnak elég jól angolul. Ha jut rá, szerintem megéri az időt.
2012.október.21st. at 06:24
102, Jani: Te tényleg képes vagy ennyi faszságot összehordani csak azért, meg megdicsértelek? :-) Egyébként, ha herótod van tőlem, nem zaklatlak a továbbiakban. Úgyis megtudtam, hogy a párbeszéd szabályait sem ismerem. Akkor mit kötekedem egy sakk-nagymesterrel? :-) Most próbáltam nem adni tanácsot.Megint egy súlyos tévedés. Nem érdekel, hogy “dicsérsz”, “kritizálsz”, vagy “oktatsz” éppen – kizárólag a tartalomra reagálok. Vajon miért csak arra, és miért neked?
Legjobb tudásom szerint SENKI nem születik a logikus gondolkodás, az érdemi vita képességével – ugyanis ez NEM képessége az emberi agynak, éppen ellentétes minden biológiai, lélektani és evolúciós kötöttséggel. EZÉRT töltöttek annyi időt a görögök (vagy mondjuk a tibeti buddhisták) a szabályok megkeresésével, és (a legjobb képességű jelöltekből válogatott) minden egyes tanuló esetén éveket csak azzal, hogy ezt láthatóvá tegyék a számukra.
Nem szerencsés, hogy ezt ma bárki, aki képes kezelni egy billentyűzetet, a magáénak véli.
Vajon miért sakkozik bárki nála jobb sakkozóval? Azért, hogy TANULJON belőle, és egy napon jobb legyen nála.
Miért sakkozik a mester bárkivel? Mert tudatában van saját múlandóságának, tehát az tény, hogy egy napon MINDENKI jobb lesz nála – viszont szeretné, ha ez nem jelentené a színvonal csökkenését. Ja, még valami: “abszolút mester” nem létezik, a jobb játékos többet tanul ugyanabból a partiból…
Hmm? :-)
103 RJ: Talán térjünk vissza az eredeti témához. Mikor robban ez a ketyegő bomba?Ezek szerint nem tűnt fel: azt állítom, hogy a szerencsétlenkedésünk KÖVETKEZMÉNYEIT már nem lehet kezelni. Csak az okait. Fukushima egy globális probléma, globális méretben “másként gondolkodó” emberiség képes csak megoldani. Hiába csacsogok mondjuk én az elejétől fogva arról, hogy kit érdekel a Higgs bozon vagy a szabadenergia, ez magasabb prioritású azonnal megoldandó kérdés. Hiába a Fairewinds erőlködése, teljesen logikus, megalapozott javaslatai. Kit érdekel?
104 Jani: Szerintem, nem sok eszközünk van, ami használható lenne, ha összedől a tározó.
Tehát “kicsiben”, egyéni szinten lenne végre ideje a “felébredésnek”, a valós problémákat fontossági sorrendbe állítva a megoldásokat keresni ahelyett, hogy mesevilágbeli történetekkel szórakoztatjuk egymást.
És igen, REMÉNYKEDNI, hogy amíg nem szedjük össze magunkat a szükséges mértékben, addig nem lesz újabb gond. Van esetleg hatékonyabb javaslat? Telefon a Jóistenhez vagy a “világ vezetőihez”? Fukushima megakoncert? Imakör és transzcendentális meditáció? :-)
105, Tibor bá: “elsőnek az USA fog szívni, és ez engem boldoggá tesz.”Helyetted szégyellem magam, hogy egy önmagát értelmesnek és embernek nevező lény képes leírni egy ilyen mondatot! (Miután kitöröltem életem első, direkt neked címzett, egyszavas, totálisan személyes sértését.)
1: Ott is EMBEREK élnek, ugyanolyan joggal a létezéshez, mint bármelyikünk. 2: A keletkező szennyezés radioaktív, százezer évre határozza meg az utódaink sorsát az egész bolygón.
Tudom, te kiábrándultál a saját utódaidból, sajnálom, hogy köpsz a következő generációra, sajnálom, hogy ezt jogosnak érzed, sajnálom, hogy egyáltalán megengeded magadnak.
Szerintem semmi közöm ahhoz, amit TE “megoldásnak” képzelsz, a (valóban értékes) tudásodból gyerekes kliséhalmaz által építesz rendszert. Inkább vállalod a felületességet, az ordító önellentmondásokat, inkább nevezel elmebetegnek, tudatlannak, romantikusnak vagy emberi gondolkodáshoz nem értő technokratának, minthogy ezt megvitasd. (Nem mintha kedvem lenne újra megpróbálni.)
Te épp mostanában mondtál egy szintednek megfelelő viccet. “Tibor bá mozgalmat indít a korrupció felszámolására!” Ahogy korábban írtam: igen, személyesen koccinthatnánk és nevethetnénk rajta egy jót – de erre nekem megvan a saját életem és barátaim. Ez a téma viszont szerintem alkalmatlan a humorizálásra. Egy életveszélyben lévő beteg mellett a műtőben szerintem nincs sok ok a koccintgatásra, de a “próbáljuk meg talán ezt” típusú vagdalkozásra, vagy a “a hülye, minek ment oda” utólagos okoskodásra sem. Itt és most, egyetlen esélyünk van. Szerintem. És elnézést, hogy ha jobb nincs, ha más nincs, én igyekszem orvosként hozzáállni. Nem hentesként, kuruzslóként vagy humorista szerepben. Tudom, hogy egy igen szűk részterületen rendelkezem csak szaktudással, és hogy nagyon kicsi a mozgásterem – tehát valóban: önmagában értéktelen, akár sikerül, akár nem.
Arról, hogy ez számodra “tudom a megoldást” és “csatlakozz hozzám” címszavakra fordul le, nem tehetek. Arról sem, hogy bátorkodsz röviden összefoglalni azt, amiről az előző mondatban is azt állítod, érthetetlen. A rólam szóló összefoglaló MAJDNEM pontos, a hiba a fogalmak használatában és értelmezésében van. Az eltérés körülbelül annyi, mint egy lélegző és egy nem lélegző ember között.
2012.október.22nd. at 19:58
Köszönöm a hozzászólásokat, de közben volt egy érdekes élményem, talán ezt hívják “kegyelemnek” azok, akik komolyan foglalkoznak vele. A véleményem változatlan, de sokkal kevésbé tűnik fontosnak, mint akár egy nappal ezelőtt. Nem is rabolom vele tovább az időtöket.
Az Apokalipszis inkább meditatív dolog a részemről. Bár itt szándékosan nem teregetem gondolkodásomnak ezt az oldalát, de be kell vallanom: nem “bulvár”, nem “szekta-buli”, minden szavát komolyan gondolom; amit magamról írok, valóban így történt és történik.
Ebben a körben inkább ezzel az írással szeretnék “nyomot hagyni”… szerintem néhány felvetett kérdésre választ is ad.
2012.október.23rd. at 09:30
Nem kell túllihegni, semmi különleges új meglátás, öt szóban összefoglalható überbigyó nincs, ha ez érdekelne bárkit, keresgéljen az Édesvíz kiadó és társai körül :-) Én ugyanaz a dagályos techno-pszicho-barbár vagyok, mint eddig; a kapcsolódó dolgokat már régen leírtam. Viszont úgy érzem, megszabadultam végre attól a megmagyarázhatatlan belső késztetéstől, hogy itt tépjem a szám. Lényegében ennyi történt, csak mivel ment itt egy kör rólam, gondoltam nem lépek le szó nélkül.
Az Apokalipszisre meg azért szóltam vissza, mert szerintem nagyságrendekkel nehezebben érthető (az én fogalmaim szerint: sokkal szélesebb analógia-hálózatra épül), mint az itt kritizált szövegeim, tehát pont a “közérthetőségre” kifejezetten rossz példa – azért ajánlottam másikat. Örülnék, ha Tibor bá mégis visszatenné a linket, ha cserébe megígérem, hogy tényleg nem etikátlankodom és olvasóhalászok itt tovább :-D
2012. október 18., csütörtök
Vigyázz, a tetőn dolgoznak...
... hát kérem hogy fönt a tetőn komoly munka folyik, azt az emberek ugye érzik. Én csak azt nem értem, hogy azért, mert fönt komolyan dolgoznak, miért mindig lent kell vigyázni?
Hofi Géza
2012.október.18th. at 05:12
35, Tibor bá: Rendesen letettétek lábnyomaitokat a honlapra, csak a címet felejtettétek el: Hiába menekülsz, hiába futsz Nekem elhihetitek. Amikor a gólya bedobott egy magyar kéménybe, a kocka el lett vetve. Legfeljebb még nem tudsz óla, vagy nekem nem hiszed el. De majd hozni fogod az egy szál virágot a síromra, ahogy Algernonnak vitték.
34:
Jani, te is tudod, hogy ezek mind vissza fognak menekülni a “nyomorba”. Én azt tapasztaltam, hogy mindenkinek magának kell rádöbbenni, hogy “A nagyvilágon e kívül nincsen számodra hely, áldjon vagy verjen sors keze, itt élned, s halnod kell.”
Most hol van az a szöveg, amivel engem oltogatsz, és romantikus álmodozónak nevezel? “A magam részéről ragaszkodom az objektív megfigyeléssel szerzett valósághoz.” Ez az ottani kontextusban is ellentmondott a pár sorral feljebb lelkesen helyeselt állításomnak, de ez a “síromra virágot” költői kép azért ROMBOL…
Az én köröm így néz ki: minden tőlem telhetőt megtettem az általad is támadott “birkásodás és pásztorkodás” ellen; hozzád hasonlóan névvel, arccal vállalva a véleményemet – veled ellentétben az “úgyis összeomlik minden” helyett megvalósítható alternatíváról beszélve. Meg ellened ágálva amiatt, hogy a szövegeid összességében a fásultságot erősítik, így közvetett módon a birkásodást támogatják.
Letelepedtem, végleges otthont álmodtam, kifizettem az árát (munkával és örökségből törlesztve a forint alapú OTP hitelt, ahelyett, hogy “az elvárásoknak megfelelően” a huszonéves autónkat cseréltem volna le). Sok időt adtam az életemből egy darab magyar földért, és ez helyes így. Három fiút igyekszem valódi értékek tiszteletére nevelni, amelyben a magyar kultúra és nyelv fontos szerepet játszik (bár nem előzik meg a józan gondolkodást). Be kell persze ismernem, ez utóbbi téren nem állok nyerésre.
Több mint egy évig dolgoztam agyfacsaróan bonyolult dolgon (képzelheted az milyen, amikor én mondom) úgy, hogy közben lassan felkopott az állunk, annak reményében, hogy értelmes partnereket találok vele. Ennyi időbe került elfogadnom, hogy (akár igazam van, akár hülyeség) EGYEDÜL vagyok. Egyedül a hitemmel, a tenni akarásommal, a tudásommal. Meg azzal, hogy a szakmám legújabb “divatjait”, betűszavait, szabványait unott képpel lapozgatom át, de ha kell, TUDOM, hogy mit, hol és miért keressek egy teljesen idegen rendszerben. Most tehát, számomra jóval egyszerűbb (de így is eddig megoldatlan) feladatokon dolgozva építgetem a “nemzetközi karrieremet” egy multinál (és “szívvel-lélekkel”, mert nekem máshogy nem megy, mert nem a “gonosz multit” látom, hanem azokat az okos, jó embereket, akik közé kerültem, egy részük magyar, másik német, francia – na és?).
Ugyanis HA hiába téptem a szám, és az állampárt hatalmon marad a következő választásokon, akkor én lelépek, mert nem akarom ebben az országban megvárni a fociügyvédbojtár elnökké koronázását. Nem a “jobb élet reményében” (ahhoz csak el kellett adnom a munkaidőmet, ami nem kellett “nektek”), hanem egy számomra valósnak tűnő veszély elől megyek el addig, amíg muszáj. Mondhatnám, hogy “ne legyen igazam”, de eddig az élet nem cáfolt rá a jóslataimra (pontosabban csak akkor, amikor alábecsültem a főnök elvakultságát), így azt mondom: szomorúan, de nyugodt lélekkel fogom nézni a dolgot távolról, mert “én szóltam, és amit bírtam, megpróbáltam”.
Legalábbis most így látom. Lehet köpködni.
2012. október 15., hétfő
Accessing data (and the betrayal of informatics)
What we do is called informatics, we are supposed to build information systems. The tools we use for that are the computers, which can process and transform the data, and the way we instruct the computers to process some data is programming. So we are programmers. And all that we have to do our task are tools for programming: different (and numerous) programming languages, different (and devastating amount of) tools to process a certain type of data in a certain way. Finally, we implement software: a collection of algorithms that can be executed in a specific environment: hardware, a certain set of operating system version, or higher level runtime, using a specific set of tools of a specific set of versions. All that we have investigated and found out of data is burnt and hidden into this implementation and execution environment. When it changes, and for all the other, simultaneously existing environments, we have to do the same thing again and again.
If we look at it from the business viewpoint ("work to get money"), this is good. But from any other aspect, ("work to solve a problem in a way that it also remains solved for a considerable amount of time"), this is totally, fundamentally wrong! To correct it, we should return to the basics.
We are supposed to build information systems. The key is the piece of information itself, not how, where, when we process it. The information system is a parallel universe that lives synchronously to the material world; the information system should hold a "shadow" of existing things - exactly one, unique instance that can follow that material (like a person or a car), or conceptual (like a calendar) entity. Dust Framework aims to support building this information system by extracting the concepts, types, pieces of information from the actual implementation environment to a declaration level. It is not dependent on any external framework, only upon itself: the meta-language of declaration (basic terms and their relations) itself is just a declaration, can be corrected or upgraded on need. The actual runtime services are atomized and therefore are wrapped into several black boxes. The representation of this content is also irrelevant: the same entity hierarchy can be stored in a database, LDAP server, in the structure of a file system, or in files of XML, JSON or whatever format.
Data access
The concept is nice, but has very complex consequences. For all execution environments, "data" is a tagged location in the system memory (temporal data storage area), and all we actually do is instructing a piece of hardware, the processor, to do something with the information at that location (read, test, change).
However (except for local, temporal working variables), "data" is not just a location in the system memory: it represent a state of an object in the external world. That object might be visible in other execution environments in this very moment, it might change as I watch it, and it may live longer than my environment (may have existed before I switched my machine on, and will exist when I switch it off). Accessing this piece of information is definitely not that easy as a processor instruction. It is essential how I get, lock and commit (or rollback) this data.
Get data
Lock
Commit / Rollback
If we look at it from the business viewpoint ("work to get money"), this is good. But from any other aspect, ("work to solve a problem in a way that it also remains solved for a considerable amount of time"), this is totally, fundamentally wrong! To correct it, we should return to the basics.
We are supposed to build information systems. The key is the piece of information itself, not how, where, when we process it. The information system is a parallel universe that lives synchronously to the material world; the information system should hold a "shadow" of existing things - exactly one, unique instance that can follow that material (like a person or a car), or conceptual (like a calendar) entity. Dust Framework aims to support building this information system by extracting the concepts, types, pieces of information from the actual implementation environment to a declaration level. It is not dependent on any external framework, only upon itself: the meta-language of declaration (basic terms and their relations) itself is just a declaration, can be corrected or upgraded on need. The actual runtime services are atomized and therefore are wrapped into several black boxes. The representation of this content is also irrelevant: the same entity hierarchy can be stored in a database, LDAP server, in the structure of a file system, or in files of XML, JSON or whatever format.
Data access
The concept is nice, but has very complex consequences. For all execution environments, "data" is a tagged location in the system memory (temporal data storage area), and all we actually do is instructing a piece of hardware, the processor, to do something with the information at that location (read, test, change).
However (except for local, temporal working variables), "data" is not just a location in the system memory: it represent a state of an object in the external world. That object might be visible in other execution environments in this very moment, it might change as I watch it, and it may live longer than my environment (may have existed before I switched my machine on, and will exist when I switch it off). Accessing this piece of information is definitely not that easy as a processor instruction. It is essential how I get, lock and commit (or rollback) this data.
Get data
Lock
Commit / Rollback
2012. október 14., vasárnap
Entity meta-types
With the declarative tools I have to go to the end. Finally, the business logic, which can be implemented in a programming language (right now C is the preferred choice), can only do the following:
- access connected other instances: the connection itself is done through a local ID mapped to the target instance in the deployment
- access values through a variant interface
- send messages to the connected instances (targeted messages)
- send messages to the component's own broadcast channels.
Question: do I need the programming language at all, if its use is reduced to this level, and the above actions can also be used in declarative environments as "action nodes"? I could create the tree of action nodes directly, the same structure that the compiler actually creates when it parses the source code - and I could also parse source code to this structure, and play it in an interpreting environment with the above functions.
Answer: the lowest level, architecture dependent layer has to be programmed directly. I should identify the components of the execution layer (like memory, thread, "class loader" etc.) declare the same way as the lowest level data components (type, field, entity, aspect, channel, ...). The core functionality, process path has to be declared and played using the core items to find the terms and sentences of that layer. In this way I will have a configurable, segmented running environment instead of a monolithic "runtime". Then I will be ready to write that lowest level code for one architecture (be it Java, an OS or else).
When dealing with the abilities of the environment, I must forget actual programming languages and their features: I have to focus on what I want from the environment and why I want it. If I find the right approach, I can be sure that the actual language will help me in implementing it. So, what to support?
Exceptions
Components should not "peek into" the deployment path. When I require a service, I don't know how it will be implemented in the actual environment, like I want to access an entity, and I don't want to know that my environment resolves a storage address and requires the instance at this moment via HTTP requests from multiple servers that execute DB or LDAP queries for me. All points may fail due to different reasons; some should be handled and post processed before reaching me, some should never reach me, etc.
Therefore I should support throwing exceptions in the way of ordinal messages. The environment should immediately stop execution and roll back the operations until a catch is registered. The catch declaration should not break unit boundaries: a unit can catch its own exceptions and react to them in the finest detail (actual exception objects). The exception can be classified to different categories, and catch declaration can refer to these categories. This is a hierarchical structure, and for data I use the entity -> aspect* concept for them. Should I use the same here?
Looks fine. The server encounters an LDAP error, creates and throws an LDAP exception with all the details. However, this exception is private (security reasons) and should never leave the server machine (it is removed from the entity when it gets into an outgoing channel). On the other hand, it can be caught, and another (public) aspect can be added: temporal server error exception, perhaps with a short explanation and the estimated availability information.
Entity meta-type
Okay, so the Entity has a kind of "meta-type aspect", which can be Exception, Persistent Data, Temporal Data, Worker Component?
What is a worker component? That is like a configured parser, a stream channel, a GUI panel. But is it different from any other data? Its life cycle is limited to a session: though some of them "live" as long as the actual running hardware is switched on (the environment components); some are limited to a specific user action (GUI elements); some are even more temporal (event process nodes in a parser). But Temporal Data, the shortest living items (messages) need a life cycle management: should not be disposed when used, should be disposed when all user components finished with them.
One entity may have different life cycle aspects. A GUI element has Persistent Data components: the GUI structure and message path declaration is persistent, it is part of the service declaration; in normal case it is final. However, multiple instances (entities) can refer to the same declaration: multiple windows of the same service type. They are different because the Temporal Data section of the entities are different: actual size, location, language, ... Some of the Temporal Data section MAY be used to update the Persistent section (default location, size, language) - or the declaration can contain Temporal content as well that act as default. The latter is the better: less administration.
Is worker component limited to its actual location (machine)? NO. The Worker Component data can travel through a channel and appear on another machine (for GUI, this is screen sharing on declaration level). That would be a useless limitation.
So, the meta-types are reduced to Persistent, Temporal and Exception meta-types. It seems that references can go in any direction, independent from the life cycle levels, but downward references act as "template" mechanisms. An Exception may refer to a Persistent or a Temporal entity, and that is a direct instance reference: the actual item can be accessed through the reference. On the other hand, a Persistent entity may contain an Exception, but that is only a template, and is "torn off" from the owner (replicated) when used (updated): the server may contain a "temporal server error" exception with "try again=5 min" attribute; this is mapped to any exception sent from the server. But in this case, the sent exception is not "the same instance", the server setting may be modified, it will not affect the existing instances. The same way: the (Temporal) Location aspect in the (Persistent) GUI declaration may be changed (the next windows will appear on a new location), but this does NOT affect the existing windows. On the contrary: a change in a Persistent Data displayed on multiple GUI panels MUST be reflected in all of them.
Feliratkozás:
Bejegyzések (Atom)