I like to second Alan's recommendation to explore SK8. SK8 is by far one of my favorite authoring environments, and has served as a critical point in the evolution of my thinking about Dynabook-like platforms. Imagine you start with Hypercard, rebuild its foundation in Lisp (MCL) and ensure extremely tight integration with the host environment; then raise the ceiling by allowing arbitrary data structures, incorporating a prototype-based object system powered by CLOS, and an English-like scripting language (with powerful collections processing) that makes exploratory programming undaunting for beginners, yet practical for professional prototyping; finally, create a simple and consistent direct manipulation environment that allows users to create complex objects just by drawing them from a dictionary of forms (which has always brought to mind the illustrations in The Reactive Engine). What you end up with is an architecture that's powerful, adaptable, supportive and just plain fun to use. Building a meta-tool for dynamic simulations in SK8, for example, is comparatively simple: http://rubenkleiman.com/data/sk8/SK8_UserGuide.zip
I copied all of the SK8 sources, documentation and binaries off of Apple's website years ago, and use a 68K emulator dedicated to SK8 for experimentation. I started to explore porting the sources to the released RMCL environment, but stumbled with incompatibilities between MCL versions and the sheer size of the code base. Taking a step back, I started chatting with the creators of SK8 to try to understand the kernel of the ideas they were after with SK8, and to remove my bias towards the specific implementation. Ruben Kleiman mentioned that if he were to move SK8 into the 21st century, that he'd a.) try to make it as independent as possible, b.) that Javascript + HTML or Java is probably the best way to do this, c.) that the Javascript + HTML(5) approach is particularly powerful, because the dynamic nature of Javascript means that it need not just be the system substrate, but the scripting language as well, d.) that Lisp has no real advantage for a practical implementation, because a dynamic layer can be built in any language, but that the implementation should be supported by a wealth of libraries that, modulo performance requirements, could be used via server services or pipes, and e.) that trying to graft a malleable environment like SK8 onto a fragile UI framework like AWT isn't the right approach. Instead, just start with simple shapes and build up from there. Philip McBride also chimed in at one point; I'm happy to share his advice as well if folks are interested. SK8 certainly isn't a perfect environment by any means, but it's filled with innovative ideas that can serve as inspiration for something better. I've been casually trying to drum up interest for a more thorough research project on Dynabook-like environments here at MIT, but Scratch has been such a success that there doesn't seem to be a lot of talk about how to alter its foundation, or raise its ceiling. I've been desperately wanting to build a software prototype based on Ruben's advice and my countless other Dynabook concept sketches, but (much to my frustration), the course load here gives little opportunity for entertaining heretical notions. _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
