Scaling to the Enterprise (Part 3 of 4)

(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.

About Stearns

Howard Stearns works at High Fidelity, Inc., creating the metaverse. Mr. Stearns has a quarter century experience in systems engineering, applications consulting, and management of advanced software technologies. He was the technical lead of University of Wisconsin's Croquet project, an ambitious project convened by computing pioneer Alan Kay to transform collaboration through 3D graphics and real-time, persistent shared spaces. The CAD integration products Mr. Stearns created for expert system pioneer ICAD set the market standard through IPO and acquisition by Oracle. The embedded systems he wrote helped transform the industrial diamond market. In the early 2000s, Mr. Stearns was named Technology Strategist for Curl, the only startup founded by WWW pioneer Tim Berners-Lee. An expert on programming languages and operating systems, Mr. Stearns created the Eclipse commercial Common Lisp programming implementation. Mr. Stearns has two degrees from M.I.T., and has directed family businesses in early childhood education and publishing.


  1. 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)?

  2. 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… and…) 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…

  3. What about importing scripts and behaviors from Second Life?

  4. 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”>… and

Comments are closed