Monday, August 31, 2009

Parallel Computing: Why the Future Is Compositional, Part II

Part I, II

Abstract

In Part I, I argued that software construction should be strictly compositional and modeled on a hierarchical framework. I wrote that every computer application (or sub-component) will be organized like a tree and will be a branch in the universal tree of all applications. In this post, I argue against the linguistic approach to computer programming and I explain why the tree is the perfect organizational model for software composition.

No Fun For You

Many have argued that the linguistic approach to programming has adequately proved itself in the last half-century and that there is no reason to change to a new approach. My response is that the linguistic approach is what is keeping the computer revolution from reaching its true potential. The reason is that language is purely descriptive in nature and, as such, forces the application designer to learn a complex set of description rules that have nothing to do with application design. The designer’s freedom to create is limited by the non-interactive and tedious nature of the process. Worse, there is no quick and easy way to reuse previously written code in new programs. The end result is pages of code that are hard to decipher and debug because the relationships between objects are not obvious. Creating things is supposed to be fun but writing code is anything but; unless, of course, you’re a computer geek. Is it any wonder that certain cultures and women in general are under-represented in computer programming? The stuff that is out there is boring, ugly and painful. Some of us have no patience for it.

The Other Way Around

Computer programming, as it is now practiced, consists of communicating one’s intentions to a computer via a special language that is easy for the computer to interpret. From my perspective, this is primarily what is wrong with the linguistic approach. A tool should accommodate the user. That is to say, the programmer should not have to learn how computers think in order to communicate with them. I think it should be the other way around. I think it is the computer that should be trying its best to understand the programmer’s intentions and react instantly and intuitively. Consider that humans learn best through trial and error, through direct manipulation and interaction. This is the reason that video games and programs like Google Earth and graphic editors are such a pleasure to use. My thesis is that, since programming is a constructive activity and since humans enjoy using parts to build bigger parts, the programming environment should look and feel like an interactive video game for constructing things. The computer should make it as easy as possible for the programmer. While focusing on the task at hand, the programmer should be able to forget that there is a computer somewhere doing its magic to keep the interface working flawlessly. Programming should be fun.

Masters, Slaves and Hierarchies

Nature teaches us that the best architecture for composition and classification is the tree. The proper function of governments and other organizations is possible only because they are hierarchically structured. My thesis is that the main reason that compositional programming tools have not revolutionized software construction is that there are no master/slave relationships between components. The effective control of behavior (turning an object on or off) among cooperating entities is impossible without such relationships. Object-oriented class hierarchies, as a counter example, are not organized with behavior control in mind. Objects are really of the client/server type, which is not the same thing as master/slave since neither controls the other. Constructing a hierarchical tree of concurrent behaving objects is impossible unless there is a clear understanding as to what controls what. That is to say, every object must be designed in such a way as to form master/slave relationships with other compatible objects.

Automatic Classification

Another problem with current compositional tools has to do with locating the right components from the component repository. A keyword-driven component database can quickly turn into a horrible mess. The trick is to have a system that automatically organizes the components in the database. That is to say, the system should automatically position every component at its correct level and correct branch in the tree. This is possible only if master/slave complementarity is consistent from top to bottom. It suffices to count the levels in the hierarchy. For example, an object may interact (via a gender-enforced lateral connector) with another object inhabiting the same level in the hierarchy but can neither control it (turn it on or off) not be controlled by it. Thus a designer can quickly locate a component by traversing the appropriate branch.

Automatic Factoring

Proper component factoring is essential to effective reuse and composition. Factoring consists of breaking down a component into two or more smaller components that can be used separately. This should not be the responsibility of the programmer but should be handled automatically by the classification mechanism. This can be done by comparing components to see if certain parts of a component are repeated in others. The system can instantly and autonomously break the components into smaller parts. This eliminates redundancy and atomizes parts into the finest possible granularity at a given level of abstraction. Fine granularity makes for easier composition by broadening the choice of components.

The Universal Tree

I foresee the need to maintain a single universal tree of all software components somewhere on the Internet, preferably with the branches distributed throughout the Cloud.


The figure above depicts a hierarchy of components. This could be a single branch within a larger universal tree of applications. As the tree becomes populated, new applications become easier to compose using existing components. Organizations and individuals can still have secret components on their own private servers, if they so desire, but they should make sure that their component repository is properly synchronized with the free global tree. Additionally, it should be possible to insert a component into the public tree without publishing its internal composition. Having a public tree will encourage reuse and eliminate frequent reinvention of the wheel. It goes without saying that all software development tools should have access to the universal tree. More to come.

See also:

COSA, A New Kind of Programming
Why I Hate All Computer Programming Languages
How to Solve the Parallel Programming Crisis
The COSA Control Hierarchy

Thursday, August 13, 2009

Parallel Computing: Why the Future Is Compositional, Part I

Part I, II

Abstract

In this two-part article, I will argue that there is a way to define, organize and use software objects that will transform computer programming from the complex unprincipled mess that it currently is into an orderly, easy to use and pristine compositional paradise. Please read Why I Hate All Computer Programming Languages before continuing.

The Promise

The computer revolution will not come of age until we are all computer programmers by default, whether we know it or not. This will not happen until software construction becomes strictly compositional in nature. Imagine being able to extend the functionality of an application simply by attaching a new component to it with the click of the mouse button. Computer programming for the masses, that is the promise of compositional software. The idea is to create such a huge and easily navigable repository of components that any application can be quickly and flawlessly assembled from existing objects using an intuitive and graphical user interface.

Past Failures

Computer scientists have known for decades that componentizing software is the best way to take advantage of the enormous potential of reuse. As it is, a huge part of computer programming consists of reinventing the wheel, leading to a waste of resources and low productivity. There have been many attempts at devising compositional software tools over the years but they have all fallen short of the goal of truly simplifying computer programming. In my opinion, all past and current approaches suffer from one or more of the following flaws.
1. Algorithmic (implicitly sequential) model.
2. Non-interactive, textual (descriptive) interface.
3. Non-synchronous (non-deterministic) processing.
4. Heterogeneous model.
5. No fundamental software building blocks.
6. No plug-compatible components.
7. No coherent component/object classification system.
The Software Tree

The COSA software model, by contrast to the above, is non-algorithmic (implicitly parallel), graphical, interactive, synchronous and homogeneous. It is based on fundamental building blocks called sensors and effectors, and organizes all objects into plug-compatible components that easily fit into a hierarchical compositional architecture.

The tree is the perfect metaphor for the new approach to software construction and classification that I am proposing. Every COSA application (component) is organized internally as a tree and is itself a node (or branch) in the universal tree of all COSA applications. The leaves of the tree are the fundamental building blocks.

In Part II, I will explain why the use of a tree classification system for all software components is essential to the success of component-based software development.

See also:

COSA, A New Kind of Programming
New Interfaces for Parallel Programming
How to Solve the Parallel Programming Crisis
The COSA Control Hierarchy

Thursday, August 6, 2009

Why I Hate All Computer Programming Languages

That’s All I Want to Do!

I hate computer languages because they force me to learn a bunch of shit that are completely irrelevant to what I want to use them for. When I design an application, I just want to build it. I don’t want to have to use a complex language to describe my intentions to a compiler. Here is what I want to do: I want to look into my bag of components, pick out the ones that I need and snap them together, and that’s it! That’s all I want to do.

I don’t want to know about how to implement loops, tree structures, search algorithms and all that other jazz. If I want my program to save an audio recording to a file, I don’t want to learn about frequency ranges, formats, fidelity, file library interface, audio library interface and so forth. This stuff really gets in the way. I just want to look into my bag of tricks, find what I need and drag them out. Sometimes, when I meditate about modern computer software development tools, I get so frustrated that I feel like screaming at the top of my lungs: That is all I want to do!

Linguistic Straight Jacket

To me, one of the main reasons that the linguistic approach to programming totally sucks is that it is entirely descriptive by definition. This is a major drawback because it immediately forces you into a straight jacket: unless you are ready to describe things in the prescribed, controlled format, you are not allowed to program a computer, sorry. The problem with this is that we humans are tinkerers by nature. We like to play with toys. We enjoy trying various combinations of things to see how they fit together. We like the element of discovery that comes from not knowing exactly how things will behave if they are joined together or taken apart. We like to say things like, “oh”, “aah”, or “that’s cool” when we half-intentionally fumble our way into a surprising design that does exactly what we want it to do and more. Computer languages get in the way of this sort of pleasure because they were created by geeks for geeks. Geeks love to spoil your fun with a bunch of boring crap. For crying out loud, I don’t want to be a geek, even if I am one by necessity. I want to be happy. I want to do cool stuff. I want to build cool things. And, goddamnit, that’s all I want to do!

Conclusion

Unless your application development tool feels like a toy and makes you want to play like a child, then it is crap. It is a primitive relic from a primitive age. It belongs in the Smithsonian right next to the slide rule and the buggy whip. If you, like me, just want to do fun stuff, you should check out Project COSA. COSA is about the future of programming, about making programming fast, rock solid and fun.

[This article is part of my downloadable e-book on the parallel programming crisis.]

See also:

Parallel Computing: Why the Future Is Compositional
COSA, A New Kind of Programming
Half a Century of Crappy Computing
New Interfaces for Parallel Programming
How to Solve the Parallel Programming Crisis
The COSA Control Hierarchy

Wednesday, August 5, 2009

New Interfaces for Parallel Programming

Most of my readers already know that I am a fan of Jeff Han’s multi-touch screen interface technology. I think it is a great interface for future parallel programming in a COSA development environment because it makes it easy to visually manipulate and experiment with a large pool of plug-compatible parallel components. Even though it is easy to represent objects in three dimensions on a 2-D surface, I always felt that it would be nice to be able to virtually immerse oneself into a program under construction. I envisioned a day when an application designer could visually jump into and navigate through a running program under construction. I think it would add a natural and highly productive feel to application design akin to moving around in a familiar environment such as one’s home. The reason is that the brain loves 3-D. It can quickly make sense of and adapt to its surroundings by getting a fix on its position and orientation relative to other nearby objects. Also, previously encountered 3-D configurations or patterns will add to overall scene comprehension in a way that makes it easy to spot out of place or wrongly connected objects that can potentially ruin a design.

This is the reason that I was pleasantly surprised to read about the newest 3-D user interfaces currently being shown at SIGGRAPH 2009, as reported by MIT’s Technology Review. I think this stuff is awesome. In my opinion, anybody who is interested in the future of parallel computing should get acquainted with these new technologies. The availability of a virtual touch interface is particularly interesting, not only because it adds another sensory modality that will reinforce the 3-D experience, but also because it may open the door for even the blind to enjoy computing in a powerful way that they are already familiar with. It might even provide them with an effective sense of 3-D vision through touch, a great help for navigation.

Get ready. The future is on our doorsteps.

See Also:

How to Solve the Parallel Programming Crisis
Why I Hate All Computer Programming Languages