Talking about two sided forms (German: Zwei-Seiten-Formen), is talking about abstractions.
"An abstraction is a boundary with two sides."
That is the first sentence of this blog post by Eric Sink, titled "The .NET Abstraction Pile". The points of his article are:
- Good technology decision making requires you to know what's going on underneath the abstractions.
- Really tall piles of abstractions should be treated with suspicion. So far my [= Eric Sink ; /rgb] experience with .NET has been a pleasant surprise, but a really conservative ISV project manager today might still avoid C# and Java in favor of C++.
As Andreas Mertens made a technology decision here (in German) but admits that he still hasn't fully understood what he calls the "Pile-Relationsstruktur" (English: structure of Pile relations), it might be of some help to ask: what's going on underneath the abstractions?
The following (clickable) image shows the layered architecture of the Pile Reference Implementation available for download here.
In terms of Eric's example, regarding Control Flow, we are talking about abstraction #3, the CLR or "virtual machine", and #4 to #8:
- C# […]
- CLR. C# runs on the Common Language Runtime, which is a huge abstraction. In fact, if we all weren't so worried about comparing .NET to Java we would be calling the CLR a "virtual machine", which it is.
- C++. The CLR is written in lower level languages like C++ and C.
- Assembly. C++ is implemented by compiling it to x86 assembler code. We've taken a big, big jump here. Compared to C++, assembly language doesn't feel very abstract at all.
- Microcode. Did you think Assembly was the lowest level of programming? Certainly not. Each x86 assembler instruction is a little program written in an even lower level language called microcode.
- Logical gates. Microcode is implemented by circuits which provide logical gates, including NOT, AND, OR, and NAND.
- Transistors. Logical gates are implemented by transistors, an electronic component with three wires sticking out of it.
As Andreas' blog resides under the domain lawsofform.de/, grabbing George Spencer Brown's book title "Laws of Forms", we could focus on abstraction #7, the logical gates here, cause
"The Laws of Form presented by George Spencer Brown in 1969 introduce a compact symbolic notation for NAND with any number of arguments and in effect try to develop a way of discussing NAND and reasoning directly in terms of it. (The axioms normally used are essentially the Sheffer ones […].)"
(Wolfram 2002 – A new kind of science, p. 1173)
The world hidden underneath the Pile Space layer, the Pile_Objects, has more in common with logical gates and/or transistors than with virtual machines. Implementations like that of Ralf Westphal (including the upcoming implementation of Andreas Mertens) are a start, but — to quote Pile Systems' specification paper Absolut Pile : Essentials for Implementing the Pile Concept:
The Pile System like any system is axiomatic, i.e. it is based on some fundamental rules or axioms. In the case of Pile these are three equations defining the relations between Cp0, Cp1, Cp2. (Cp stands for “Combinative pointer”). The Cp defined by the Associative parent of each object is called Cp0, the Cp defined by the Normative parent of each object is called Cp1, and the Cp defining the parenthood of each object is called Cp2.
Implementing Pile means essentially implementing these three core equations. Without them there is no Pile – which is not to say that there is nothing: some functions might be similar to Pile, some properties might look like Pile. But they all will lack something essential and this lacking will show up sooner or later […]
What are these equations? The Open Source Pile Developers Mailing List at SourceForge likes to give the answer — and more. Please join us here .