Borrowed terminology

The idea of a crosscutting concern comes from aspect-oriented programming. In object-oriented and other kinds of programming, we often find that certain needs, logging and security being the most notable examples, appear in every object. If you want your program to keep a log, you will likely have logging elements all throughout your program, defying the notion of encapsulation.

In order to solve this problem, some forms of AOP use join points. Throughout the code of a Java program, AspectJ forms what one might call a type of preprocessing; it inserts code into the program, called advice, whenever it appears appropriate (only at join points).

Unlike AOP, we make our abstractions at a high enough level that we can imagine using Units both as encapsulated objects and aspects.

Security

In our case, S-Unit defines security in terms of three major problems:

1. How do we identify units? (unit authentication)
2. How do we identify users? (user authentication)
3. Under what circumstances do we restrict the use of units? (user/unit permissioning)

Under these circumstances, we always begin with the first establishment of trust, just like in the real world. A user may choose to trust a unit. In order to make an informed decision, we must have a way of telling the user, verifiably, what the unit does.

This, in reality, would likely demand that we create signing authorities for units, and act as an authenticator. If we were a central authority, we could act as an independent 3rd party verifier to determine exactly what a unit did (its security risks, etc.). We’ll discuss this more when we talk about the Semantic Nexus, Semantwiki (Part IX).

In general, since we’re not an operating system, we have only a few ways to choose from as far as authenticating users. We can take operating system permissions and translate them as necessary, or we can operate as a user authenticator per machine (in effect, be our own permissions manager).

Unit restriction would be based on the intersection of information provided by these two authentications.

Debugging

The concern of debugging is generally to figure out when and where a program has failed. The first thing we can do to make sure that debugging is simple is confine error processing to the unit of failure.

This of course, is not always possible. Rigorous S-Unit programming makes two (not necessarily provable) demands that would make this condition at least imaginable:

1. A channel specifies a semantic data type which does not allow failure cases (i.e. cases that contain data that results in error)
2. By accepting a channel, the unit makes a contract to process every possible message that could appear in that channel viably.

Enforcing the first condition: Semantic Message Validation

In order to validate messages coming in and out of a unit, we must know exactly what data we expect and additionally have rules that confirm this data. It’s a challenge to fit this sort of validation into semantic data; if we say, for example, that an IM message can only be under 4096 characters, we need to add this rule and apply it ourselves. The Semantic Web group, for example, is only interested in adding semantic meanings to data–not restricting or validating that data. We’ll discuss how to attach this validation to semantic data in Parts VI and VII.

Enforcing the second condition: Unit Contract Validation

The only way to guarantee absolutely that a unit can process all possible inputs is to test all possible inputs. Given that this is unlikely, we can still create a Tester unit, which offers to try a series of random inputs and see if a failure is thrown in any case.

A Tester Unit is unique in that we probably can’t imagine attaching it to live applications, which already produce test cases simply by running. Given these conditions, we can limit the number of errors we receive to primarily single-unit errors. How might we diagnose them?

Debugger-Unit

The solution, as you might imagine, is a new unit. The Debugger can attach to every other Unit and can watch variables and keep breakpoints.

This unit, given the architecture of the semantic system, will be unusual in several ways compared to a normal debugger. It will only report breakpoints in its unit; other units will be free to continue operating (unless they are of course attached to the debugger). Another challenge is that, with language-independent units, it will be difficult to develop a true debugger; it will depend very much on compilation techniques, which will receive a more rigorous treatment in Part VI when we discuss languages.

Related links:

http://www-128.ibm.com/developerworks/web/library/wa-debug.html?ca=dgr-lnxw03Dbug

“once i stop changing the name, we’ll know i’ve figured out what it is”

So, in my last entry, I drew a nice diagram that purported to explain exactly how this so called Unit Architecture would be constructed; however, I neglected to have real code to back it up.

How would a Unit be coded? Basically, all a Unit has to expose to the outside world is an interface that lists the semantic types it deals with.

The LinkToIMNetwork specifies 4 interfaces and is basically event-driven. If I update my connection settings (i.e. pick a new server or something), the Human unit sends a message that gets received by ConnectionManager. Want to guess what channel that event goes through? Yup, UserInput.

The ConnectionManager then sends a message through the ConnectionSettings channel to LinkToIMNetwork. We can imagine that these messages can either be handled sequentially or concurrently, and it won’t make much of a difference, syntactically speaking.
If we were to pseudocode the UserList unit, we might see something like the following (note: Wordpress can’t indent):

Unit UserList:
---Channels Out:
-------UserInterface
---Channels In:
-------ListofUsers
------UserInput

In each of the In channels, we’d have to specify how to handle an incoming message. This would be exactly one function, in a language yet to be described. In the out channels, we’d need a way of identifying what sort of semantic data the system would output; in the in channels, we’d need a way of specifying what kinds of semantic data the system would accept (this might allow more than one fit!).

Next episode, we’ll talk about fundamental design concerns that one might call aspects (security, debugging). In Part VI, we’ll talk about the language we might use to handle the incoming messages; its design requirements, and possible fits.

Before we do this, we’ll go into a brief interlude to see MS’s solution to this problem.

Google’s Theorem: It’s already been done

After Gas finally figured out what I was doing, he mentioned that MS had already done this sort of semantic architecture:

[00:20] Gas: Microsofts version of the semantic operating system
[00:20] Gas: is the clipboard
[00:20] Gas: (you think i’m joking?)

Gas was correct that the linking system, in many ways, is solving a similar problem to the clipboard. How do you take a piece of data and give it meaning? The Clipboard uses OLE to translate data formats, allowing us to paste, say, an Excel spreadsheet into a Word document and have it be displayable.

This isn’t the only example of being able to plug data into an system and give it meaning. The Semantic Web is based around the idea of being able to attach meanings to data. For example, this page is a blog entry – the Semantic Web would be able to assign meanings to this beyond simple character data, identifying entries, authors, and the like.

Back to the fun

We are not thinking here purely of the Semantic Web, but rather, a Semantic Web Application–architecture that processes this data. This is in some senses a much simpler problem–we need only deal with subsets of data which are viable.

Similarly, we are not dealing purely with an advanced clipboard. Clipboards hold repositories of data and join it together–we are in fact actually processing that data.

Let’s imagine a series of Units that build an Instant Messaging client. We’ll have a LinkToIMNetwork, a UserList, a ConnectionManager, and the Human unit (refer to previous entry).

You’ll notice, if you’re familiar with UML in other object oriented languages, that there is a–surprising? disturbing? exciting?–lack of type definition in the relationships. All of the units are peers, and there is no aggregation, no subclassing, no nothing. Nowhere do we define a list of methods, and nowhere do we have to specify types by hand. This is exactly what we want if we want a chance of giving the average person an ability to understand the architecture.

For every channel in one unit, we’ll notice a matching channel in another. LinkToIMNetwork passes a ListofUsers to UserList. Because these types are defined as output and input in the two units, connecting the two requires no effort on our part–the linking engine will know what to pass a ListOfUsers, and not anything else.

What happens if there’s ambiguity in the connection?

This will be defined behavior. My initial intuition is to do a multicast. For example, if you connect two UserLists to a LinkToIMNetwork, it will pass the ListofUsers to both.

Reversedly, we can imagine UserList accepting multiple ListsofUsers and aggregating them together. We could have LinkToAIMNetwork and LinkToGoogleNetwork, for example, and plug them both in to UserList.

Won’t this demand a lot of functionality on the part of units?

Yes, only programmers are expected to touch the innards of units, for now at least.

You seem to have ignored a lot of important details–you haven’t touched the ConnectionStatus, for example.

Yeah, I did a half-baked job.

This may give the average user an ability to look at the architecture, but how would they manipulate it? There doesn’t appear to be much room for user intervention.

This depends on a lot of factors. Basically, the more units we have, the more effective (by exponential leaps and bounds) will be the use of the FOOP tool. On one level, we could simply upgrade units–proper upgrading of the LinkToIMNetwork might enable file transfers with less effort than might be typically anticipated. On another level, we could attach units in any way that was semantically allowed, and with expansively defined units, we could make disturbingly good applications out of previously unrelated units.

Tune in next time, when we’ll discuss how we might syntactify such a language.

Related Info

http://en.wikipedia.org/wiki/Component_object_model

http://www.w3.org/TR/owl-guide

Or does it? Hopefully the example we choose will clarify some aspects of how this method differs from standard development techniques.

The Human Unit

One of the quirky parts of programming is dealing with humans. This is no surprise–programming languages aren’t human oriented. It’s easy to sort a list of items in most languages. However in most programs, there is an awkward moment where we call the program into existance. In C, it’s called main. In Python, there’s a whole blog entry by the creator of Python dedicated to it.

With a graphical UI, the challenges seemingly multiply. Computer programming is (typically) a sequential art; things work simplest when one thing follows another. In a (good) graphical UI, the user never waits for the computer to finish; output can come in many forms at many times.

A Human unit is a rather versatile unit to connect to. It works well in the unit scheme because we can connect it to other entities rather simply, in some cases. If we connect “Hello, World!,” a Text unit, to the Human, the output would appear on their screen. If we connect an MP3, the Human would hear the MP3.

How would the system know how to handle connections to Human? This would be a matter of the system understanding the connected unit on a semantic level. We could imagine a semantic attribute being assigned to all values that defines its human interaction.

A Matter of Semantics

Semantic attributes would also allow us a measure of freedom in attaching objects to each other. If we attach a Printer to a Web Browser, we don’t need to tell the Printer to print the web page and not the address of the page it’s currently on.

Is a connection forever?

The previous Printer example seems to suggest that connections don’t remain the same in time. Would we want to script connections to open and close? This is one of the many ridiculous challenges I seem to have written myself into.

Is this a useful method of getting people involved in programming, or just a useful way of visualizing architecture?

But it would be silly to give up on a goal with such a wide potential. In fact, I’m going to go ahead and tool a new paradigm of software architecture. To some extent, we have the pieces we need; all that’s needed is a bit (lot) of imagination and hard work.

We can summarize this in three main points:

1. Programs should be made of individual components that can be easily understood.
2. Components should be able to function independently; we should not have to guide them. Instead, they should have well-defined behaviors.
3. Components should be able to handle all sorts of input.

1. You may not know why the phosphors glow…but you can change the channels.

A program is made up of a set of working components, much like televisions, cars and any other man made object.

Most of us don’t know exactly how TVs work. We don’t know how to build a cathode ray tube. But we know it’s in there, we know how to change the channels, we know that it has a standard plug that can hook up to any cable outlet.

This is what’s missing in an average computer program.

Run a web browser. The browser is one seamless block of code; you can’t say exactly which part is displaying the page, or which part is retrieving it. If you think this is silly/wrong, think about this; many average computer users don’t even understand that there’s a browser at all. They just think of it as the “internet.” This is lexical nonsense!

But we don’t build software so that the concepts programmers see are also clear to the user.

2. Functional Object-Oriented Programming (FOOP)

When we talk about object oriented programming, we’re usually referring to a programming language like Java or Smalltalk. In Java, objects are individual entities that all follow the behavior of the class that spawned them. For example, we can create many Waiter objects based on a Waiter class. The Waiter class tells us that Waiter objects can take orders and remember them. You might imagine a Waiter object having these methods, as dictated to the Waiter by the class:

1. takeOrder(x) //This means, “Waiter, please get us x!”

2. getStatus(x) //This means, “Waiter, tell us how our x is doing. Is it ready?”

Each of these takes an input (that’s called x) and gives us a response. Every Waiter object responds to these method calls.

Now in a way, this model is very intuitive; we can picture an imaginative 9 year old thinking of Waiters as Waiter objects. He or she could read through the Waiter’s 2 methods and call them, making the Waiter takeOrders for every food imaginable until the table was full. The reason this method works well is that it revolves around an object – a Waiter – for which we have a good cognitive model; we know what waiters are and how they function.

What we really want, however, is a more advanced idea of an object. If you give a Waiter an order, they should know what to do with it. We shouldn’t have to call takeOrder at all. This may sound silly, but in the real world we expect not to clear the hurdles of going through a Waiter’s javadoc and figuring out exactly which method of two hundred to call. In order to have truly intuitive programming, we shouldn’t have to be aware of this extraneous information–passing a Waiter an order should just be that.

Make Objects Know What to Do on Their Own!

In order for this to be, we can replace the idea of an object with something more akin to functions in functional programming. While so far we have made objects the primary unit of programming, now we will examine the use of “functions.”

Gas discusses this when he referred to the concept of lambda calculus and functions as first order values. (You may be more familiar with Joel on Software’s example.) We’re not going to go into lambda calculus, so you can ignore this and read the following:

A function doesn’t have to be told what to do when given an input; instead, it knows. Unlike objects, functions are defined by the output they produce for a particular input.

The basic unit I’m developing here is neither a true object nor a traditional function. A traditional object offers more than one way to process data; ours simply accepts data in any form. True functional programming, on the other hand, does not have objects with state (think waiting algorithm, not waiter); its functions are immutable, while we potentially allow units to remember things by having state.

3. Polymorphism: The Universal Translator

Polymorphism, for us, basically means that our unit can understand any sort of input it is given. When you think in a language like C, you generally restrict the input you can process. A function called add in C would be able to add only what it was defined to add. If it was defined for integers, it wouldn’t be able to add fractions or strings, and vice versa.

To create units that anyone would be able to combine in a way that made sense to them, we would have to make this distinction entirely invisible to the user. This is the reason that in Javascript, you can add “abc” and 123 to get “abc123″–addition in JS is polymorphic, able to handle different types.

Now, in order for our unit to be able to handle being thrown all sorts of strange data, we must give that unit some sort of understanding of what the data is. An image, for example, is just a number when we store it on a computer; however that does not mean that when we add two images together we just want to add the two underlying numbers!

This is an extremely challenging problem, and there are two main ways we can tackle it; give each unit the ability to handle all new types of data, or encode in each piece of data some sort of semantic meaning. In the end we may find that both are important; this is a challenge I will address in more detail in Part III.

In Part II, we’ll talk about a concrete example of this unit architecture and also show how we might get a human involved in this process.

Conclusions

If you just look at the rules of the system, without looking at the overarching goals, you might confuse the system I have just devised with a sort of lawless type-unsafe Javascript. In a way, I’m not too unhappy with that definition; if you ask the average math student to add two numbers, they won’t return an error if you give them a fraction and a complex function as the two things to add. (and if they do, they probably won’t make it past their sophomore year.) The point of erasing all these arbitrary distinctions is to remove the unnecessary burdens with which the average person is encumbered when learning to program.

If I took an experienced programmer, and faced them with the implications of my strange unit system, they would likely stick to Lisp or Java or C, and that’s fine. The goal here is to show the average person how to produce useful software without thinking about syntax, type safety, or error handling, even once. Remember the TV! Hopefully, if this becomes clear, then FOOP might demonstrate its worth to power users.

[Ideas with similar visual modeling have made it into big company research projects - see here!]