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.
This sounds very exciting, but I hope that your success takes a little while to get here, as I want Laszlo to take over the web in the meantime.
Actually at Laszlo we face a similar problem: how do we seed the developler community so that there will be enough people building widgets (so that non-programmery, or at least less programmery, people can build their own applications)?
It’s hard to predict timing, but I think the Web will be around for a while! Not a few folks look at Croquet as a better way to access (e.g., as a sort of UI or desktop for) other technologies in a more situated context. (See http://wetmachine.com/i… and http://wetmachine.com/i…) Others see a different way of using a computer altogether, in the same way that the Firefox is different from an IBM3270, or an iPod is different from an Technics XL1200. Either way, it’s going to be a while before it all works.
WRT developer community and code reuse, I’ll have more to say…
What about importing scripts and behaviors from Second Life?
I think that’s a great idea. Do I detect a volunteer?
What’s happening with Second Life is pretty exciting, and I think there’s a lot we can learn from it (by both positive and negative example). I’d like to take a good look at both LSL and Poser animation scripting. We’d have to match up the semantics of objects, names, events, replication, graphics and errors, but we’d probably learn a lot of interesting stuff in the process. From what I’ve seen, I’m not sure I would want to WRITE anything in LSL, but there might not be anything too technically broken with importing them for use in Croquet. Everybody’s welcome. Assuming we can grok out the semantics, I understand that their graphics model is proprietary. Would there be any entities out there who would not want LSL scripts going to into Croquet?
Two interesting links I found for LSL are _day_in_the_se.shtml” rel=”nofollow”>http://www.akuaku.org/archi… and http://secondlife.com/badge…