My understanding* is that Mitch does not want to see Scratch forked and that any MIT students who write Scratch plug-ins are free to do so within the Media Lab walled garden, so that they have code written by great programmers to look at and build off of but ultimately it is just a factory for helping crank out master's theses. At that point the code is not integrated into the project (e.g. doesn't fit into LKG's goals) or is reworked in somehow.
* augmented by beer pints from 10 cent wings night at Asgard's On 4/8/11, Devon Sparks <dspa...@mit.edu> wrote: > 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 > fonc@vpri.org > http://vpri.org/mailman/listinfo/fonc > _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
