More On Sign-Oriented Programming
Sign-oriented programming1 is similar to object-oriented programming. Signs are roughly equivalent to objects. They have attributes and functions. But there’s an important difference: signs must be perceived by the user, either directly or indirectly, by affecting the user’s perception of other signs.
As I wrote in an earlier post, Peter Bøgh Andersen classifies2 signs as being either an interactive sign, an actor sign, a controller sign, an object sign, a layout sign, or a ghost sign. Interactive signs have handling features, which means that they can be controlled or directly influenced by the user. Most of the other signs have permanent or transient features. Permanent features are what distinguishes signs from each other, whereas transient features distinguishes different states of the sign. For instance, in Breakout, the shape of the ball sign is a permanent feature and its direction is a transient feature.
But what about the semiotics of the internals, of the objects that aren’t perceivable either directly or indirectly? The source code clearly is a “text” although its “reader” isn’t the user, so semiotics should apply here as well. But Andersen only touches on it in a few places. He talks about semiology and meta-semiology.
The source code of a particular program is a description of a system expressed in a programming language. Within computer semiotics, that system is seen as a semiotic system. Its “linguistic correspondent,” Andersen writes, “is a linguistic description of some language, for example a grammar of English. Such a description can be defined as meta-semiotics,” but to avoid the awkward term “meta-meta-semiotics,” he follows Louis Hjelmslev “in calling a meta-semiotic a semiology, which makes a meta-meta-semiotic a meta-semiology.”
But what is a meta-semiology? Well, a semiology is a description of a semiotic system or, within the sign-oriented paradigm, a collection of signs. So a semiology describes the signs, their attributes and actions, and how they relate to each other. A meta-semiology is the definition of the semiology, but what does that mean? Andersen writes:
I [have] defined an interface as “a collection of computer-based signs, viz. all parts of system processes that are seen or heard, used, and interpreted by a community of users”, and the interface was classified as a semiotic whose expression plane is manifested in system processes. These processes must be described in a program text that (partially) specifies how the processes are manifested. Therefore the program text must at least play the role of a meta-semiology that specifies the variants of the interface, its object-semiotic.
I find this paragraph to be hard to follow, but he continues with an example that makes things more clear. He asks the reader to consider the source code of Breakout, “the program text that specifies the Breakout system.” Let’s say that the color of some sign in the game, for instance the ball, is set as white in the source code, using the statement color = White. Then changing the statement to color = Yellow would mean something different in the context of the program text. But in the user interface of the game, it would be a meaningless variant. It would only have meaning if there were more than one ball. If the yellow balls would behave differently from the others, they would need to be distinguishable by their permanent features.
So, the semiology, Andersen suggests, “address the interface form, i.e. those features that are operative in the interpretation of the system,” and the meta-semiology is “primarily concerned with the detailed implementation of the form elements.” So in the case of Breakout, the ball sign having different shape would belong to the semiology, whereas that shape being round would belong to the meta-semiology.
1 See my posts “Program Execution as Theatre Play” and “Sign-Oriented Programming.”
2 Peter Bøgh Andersen, A Theory of Computer Semiotics: Semiotic Approaches to Construction and Assessment of Computer Systems, 1997.