Table of Contents

Structural Hermeneutics

Structural Hermeneutics

A text, which claims to be written in “a hacker's view”, starts with a philosophical topic? Well, anything which is needed to do the job has to be considered and understood. Because we don't want to generate dumb code fragments but good code, we have to think about meaning. Generated code fragments today often don't have much meaning – usually, they're just skeletons (omitting all parts, which implement meaning), or they're implementing glue code – code, which is technically needed, but usually does not imply much meaning.

Because we don't want to be constricted this way any more, we first have to understand the semantics of our problem. One of the biggest problems is to understand the semantics of modeling and coding at all. And that means, we first have to understand semantics per se.

We have the same problems as the MDA[1] people had to solve.

For the reader who is interested in meta physics, I'm very sorry, that I'm working using neo-positivism mainly from a pragmatic view. That means, I will not talk about ontology here – and because of that, I will not use this term for other things either. This requires us to have some own definitions:

Semantics        The meaning of a set of terms, which are interrelated.

Semantic Domain        Semantics, which is a domain inside given semantics. That means, it is a part of the meaning of a subset of the set of terms of the semantics where it is a domain inside.

For code generation, it's important that things become computable. This is only possible, if things can be formally described.

What can be formally described? Anything and everything? And there are Goedel holes[2] in it, and that's it? Or is there more than formal languages for describing meaning? I think, the latter is true.

Theorem: There are semantics, which cannot be specified entirely with a formal language. That means, if one describes parts of their meaning with a formal language, there will be meaning left, which cannot specified with this language, independent of what language is chosen.

Proof:

For any set S with |S| > 1 there is an isomorphic set of assertions SA := { ∀x∈S: “x∈S” }, the set of all assertions of the form “x is in S” (and all of them are true, of course, by definition). For any such set, the power set S* exists, with an increased cardinal number, and the isomorphic S*A exists, too. Additionally, the sequence S(i*) exists, with S(i*) := S(i-1*)*, S* := S(1*), the sequence of power sets, and therefore the isomorphic sequence of the corresponding sets of assertions S(i*)A.

In each set of assertions, there is at least as much meaning as the cardinality of the set, because in each set each assertion has meaning, which it does not share with any other assertion of the set (it is the meaning, which differs an element from all other elements in the corresponding set).

Because both sequences are unbound in their cardinality, meaning can have any cardinality, meaning is a real class (as well as “all assertions” or even “all true assertions” are).

Each language is a subset of the power set of it’s symbols: L⊂Σ*. But Σ, the set of symbols of a language, is finite, so Σ* is countable, and any subset of it is countable, so each Language L is countable.

In general language can only reference meaning, and in general Semantics are real classes.

Because meaning now is nothing, which can be formally specified in general, we better constrain the things we're talking about in a way, that we can describe formally:

Semantic Slice        Semantic domain, which can be described formally. That means, it can be specified with a formal language[3].

Now we have terms, we can use to talk about meaning. But meaning always is about topics. There can be no meaning, which does not describe something, otherwise we would not call it “meaning”. So we need now the things meaning is describing:

Issue        An issue is semantics, which is described inside a semantic domain. Described inside a semantic domain means, that it is described using the terms of the semantic domain in the meaning of the semantic domain.

It is interesting to see the recursion. An issue is semantics itself. And a discussion is an issue, as well as the problem how to discuss can be an issue of a discussion itself.

And of course, the formal description problem again:

Formal Issue        An issue, which can be described formally.

Now let's increase granularity. We want to be able to talk about things, and that implies, we want to have the flexibility to discuss from different views:

View        Formal issue, which describes a part of an issue.

Why not “view” and “formal view”? Well, we're working using neo-positivism. And that requires us to use formal systems to discuss, or to be able to use such a system for each topic. There should be no discussion, which is not founded on a formal system, so we don't need something else than a formal view. Or, in short: we don't want to discuss without logics.

The next point is orthogonality. We don't want to discuss always the same things. Any good programmer knows, that missing orthogonality in a language is compromising effectiveness of using that language. So it will make sense to have terms, which imply orthogonality:

Aspects        Views, which describe the same issue and are orthogonal. That means, they don't mutually share meaning about their common issue.

We now have enough terms, which are defined pretty sensible. Let's go to the real work:

Modeling        A modeling is a description of a formal issue. It is a formal issue itself. To model means to specify a modeling.

Meta Modeling        A meta modeling is a modeling, which models modeling. That implies, it describes a formal view of how to model.

We're describing issues, and we're describing the issue how to describe issues. That leads us into:

Meta Hierarchy        A meta hierarchy is a hierarchy of semantic slices, which are ordered in the direction of concretion. The lower a semantic slice is the more concrete it is, the higher it is the more abstract it is.

Because a formal issue is semantics, which can be described formally, a modeling is a semantic slice and describes a semantic slice. That implies, that a meta hierarchy can be seen as a hierarchy of semantic slices.

We have to face the fact that this hierarchy is endless:

Lemma: For each modeling, there is a meta modeling.

Proof: A modeling is a formal issue by definition, so a formal description exists. A meta modeling is such a formal description of a modeling.

So the part of a meta hierarchy we want to use can be chosen arbitrarily, but has to be thetic (because it should work pragmatically). Therefore we'll need good reasons to choose intentionally.

We need concepts.

Concept        A concept is a modeling of views of an issue.

If we understand, that having a concept for an issue means modeling views of an issue, then CodeGen is a concept. That matches the fact, that CodeGen should possibly be part of a formal system and will be used to describe formal systems.

Adding orthogonality, we get:

Orthogonal Concept        A concept is orthogonal, if it only models aspects of its issue.

It is a goal of CodeGen to be an orthogonal concept. Maybe, this cannot be reached, because we cannot guarantee that no meaning is being shared by views we're describing here. But like any philosophical goal, it is something to aim for even if it cannot be reached.

Apropos goals: what we all would like to have is:

Orthogonal Language        A formal language, where every language construct is part of an orthogonal concept for the whole language.

Following our thesis that arbitrary semantics cannot be described formally, it is not generally possible to give a metric for orthogonality. If we will use the terms “more orthogonal” and “less orthogonal” for a language or a concept, we're describing more or less our feeling about this language or concept.



[1] Model Driven Architecture, http://www.omg.org/mda/

[3] See: Uwe Schöning, “Theoretische Informatik kurzgefasst” for a adequate definition for the term “formal language”