Just a Thought...

Sometimes, all it takes is a subtle shift in your viewpoint to open your eyes to new possibilities. The big problem with many existing programming languages is that they don’t always lend themselves to natural parallelization. Yes, that includes Java, C++, C#, and Ruby. It’s not impossible with those languages, it just doesn’t come for free. The reason it’s a big deal nowadays is that multi-core chips are hear to stay. Architectures like the PS3’s Cell architecture are likely to become the norm. The result is like fitting a round peg into a square hole. It’s not impossible, it just requires a lot of work.

So how do social paradigms work to allow an expressive and powerful language with a natural ability to be parallelized? I’m not fully sure, but it might work for the expressive and powerful part. Think about the concept of tagging. A tag is just metadata, and what that metadata means is up to us to decide. Of course, as soon as I use the word metadata, I’m sure I lose a part of my audience. I know my ears turned off the first time I heard that word. It didn’t mean anything to me, and it was an intangible concept that didn’t hold any value. Until, that is, we introduced the concept of tagging.

Metadata is the adjectives your language uses. It’s how you tell a fast car from a slow car.

So if objects are actors, and methods are verbs, how do I make these adjectives work for me. Who assigns these adjectives, and when can they be assigned? Here’s where the social paradigm comes in. Anybody, the developer, the actors (classes), environment, can assign these adjectives to any other actor or thing in the system. So what does that buy me? The purpose for tags is to find things again. What if we do something special with the tags? If a piece of code tags another piece of code, it’s because it wants to do something with it later. In fact the system can use that same mechanism.

For example, what if the language could tell dynamically whether the flyweight pattern was more applicable for you, and you don’t have to do a thing? If the runtime environment can determine how long it takes to create an instance of an object, it can tag the class as “Fast”, “Slow”, or “Average”. With that information, the environment can determine whether it is worth it to keep creating new instances of the object or switch context with the same memory resident object. Alternatively, it might decide to turn a reference to that object as a Future or asynchronous object. Sure you can send messages to the object, and expect the messages to be answered in the order you need them, but the application doesn’t have to stop in its tracks while you are waiting on an answer from a remote source.

OK, so now that we’ve seen something potentially useful, what about the powerful part. Sure it’s pretty cool to use asynchronous calls without declaring that you want something to be asynchronous, but what about other useful things like being able to perform the same function on all objects that were tagged specially? You know, kind of like telling all the stealth enemies to come out of hiding when they’ve been located? Rules engines work this way. You tell the rules to monitor all the objects with certain facts and do something when they match. Oh, isn’t this Functional Programming? Why, how astute of you. Then shouldn’t we use Scala? Scala requires you to be too explicit, and I can’t see any examples of it actually making life easier or easier to understand.

One of my frustrations with the Java Virtual Machine is its security model. In most cases, it is to inflexible and difficult to be used, so the application just runs unprotected—relying on the underlying operating system to enforce any security constraints. It might work for Unix based machines, but Windows machines are usually not protected as well by default. Also, if the application were run as the super user, you can cause some serious problems. Sometimes you want to be able to set up a sandbox, set some attributes for it, and run things inside of that. Kind of like setting up a virtual world for a set of components, or plugins. You can allow that plugin to access only the things you want it to access, and nothing more. What’s better to decide this than code you already trust? You can set up a separate work directory, and have the plugin use it as if it were the default system work directory (or temp directory). The code that set up the world for the plugin to do its job can decide by how often the code bumps into the security constraints if the plugin is behaving nicely.

The concept of the sandboxed little worlds fit well into the “Groups” concept that is present in the social applications. Everyone that is part of a group has a common goal and function. Of course, the same actors can be a member of several groups, and they all have to obey the rules of the group they are in. It’s the same exact instance, it’s just that the context that it is working in is different.

There’s some more possibilities, but this is enough to chew on for now. Of course, many of these things can be done without the need for a new programming language—it’s just that a new syntax would make it easier to work with and hide the implementation details. The resulting language shouldn’t be strictly object oriented, or functional. It should be designed in a way where the language can optimize at runtime based on the resources being used. It should also be designed in a way where it should be readable, understandable, and predictable.