3. HOW WILL APPLICATIONS BE DEVELOPED?
(See part 1.)
It is not practical to expect users to develop applications in Squeak. There is too much to learn. But neither is it practical to expect users to develop applications in Java or ANY OTHER COMPUTER LANGUAGE. There is no way that any community of professional developers could possibly keep up with the demand that we hope for unique applications. No matter what language they used, nor even how many developers were available. There’s simply many more users — and user needs — than there are developers. As with scalability of load, we need another approach. The answer is the same: push the load to the edge of the network.
Our whole approach is based on giving end-users to the ability, within the running user-environment itself, to develop their own content, their own interfaces, and their own architecture. End users will be able to build the objects they want directly from within the system, or they can import them from standard specialty “artist” systems. Users will also be able to simply repurpose “found objects” they find while using the system, making changes to their copies as they wish. In addition to content and style (aka “skins”), users will be able to treat application BEHAVIORS in exactly the same way — combining them in new contexts to produce their own applications. Because of the late-binding nature of the system, all of this happens live in the collaborative environment, without writing code, and without the complex edit-compile-restart-debug cycle that so confuses non-programmers. They can do all this in groups and get help because of the collaborative nature of the system. And there is no need to do that which takes the majority of effort in current applications: overcoming WWW statelessness, interfacing between separately developed systems, and providing sharing or access. These are all provided by the architecture itself.
But how will new behavior enter the system? There are no other Croquet-like systems from which to import application behavior, so these will still have to be created by specialists. However, the unit of behavior is much smaller than creating a whole application from scratch. We are designing the system so that a journeyman programmer can create new simple behaviors that anyone can then put together into different applications. Creating new behaviors from scratch will not require the tremendous experience that is otherwise required for developing application software in C++, or Java, or Squeak.
It is only the architecture of new kinds of complex interrelated behaviors, or new system-level code that requires Squeak experience.