Previous Entry Share Next Entry
Small systems... and distributed ones

Today I stumbled across some very interesting projects by Nickolay Platonov which I'd like to discuss in an OLPC context.

I've been hacking away at TurtleScript fueled partly by a drive for minimalism: a small system is a learnable system. To that end, the language is based on Douglas Crockford's "Simplified JavaScript" (as recognized by this top-down operator precedence parser) which tries hard to include only JavaScript's "Good Parts". For example, the initial code for the TurtleScript system uses prototype inheritance (via Object.create) rather than classical class-style inheritance. In fact, the new operator isn't even included in the Simplified JavaScript/TurtleScript language.

In a discussion of TurtleScript Alan Kay mentioned, "It is very tricky to retain/maintain readability (so the first Smalltalk was also an extensible language not just semantically but syntactically)." And today I stumbled across the Joose library, which gives a very readable syntax for traditional class-based inheritance. It backs this up with a robust meta-object protocol, introspection, and lots of nice features borrowed from Perl 6, CLOS, and Smalltalk. The syntax ought to work fine with the limited tile set of TurtleScript, although I might have to add a tile for the new operator.

However, adding Joose raises some questions. Is the increase in readability worth the addition of such a large library to the system? What impact will this have on understanding problems and debugging? Is a return to class-based inheritance a positive change? (There have been arguments that the make-a-clone-and-change-it practice of prototype inheritance is easier to understand for new learners.) Can a larger overall system actually be easier to understand?

And once we're looking at libraries... Nickolay Platonov is now working on Syncler, based on the Bayou system. Unobstructive replication mechanisms would certainly make it easier to construct the sorts of collaborative applications we've wanted for Sugar. I have two concerns with Syncler's current state. First, the use of explicit continuation-passing style greatly impairs readability. The JavaScript yield keyword helps a lot when writing asynchronous code. (It's not supported by all JavaScript engines, but yield wouldn't be hard to add to TurtleScript.) Second, Syncler's event model uses explicit callbacks. I've been greatly impressed with the Flapjax event model (and its strongly-typed functional cousin). Both of these changes ought to make asynchronous code much more readable—and isn't that an important part of grokking a system?

  • 1

Class-based inheritance

Personally I haven't seen any big and successful project written purely with prototype-based inheritance. Every JS project I seen instead starts with "emulation" of class-based inheritance. May be thats the matter of habit though - I believe both approaches are essentially the same.

About Joose - its not only returning to class-based inheritance. Its also attempt to reduce the state management. Of course, in imperative language, thats the question of discipline.

Joose achieves that in 2 way - 1st is unified approach to class initialization (I noticed, very often I don't need "initialize" method at all)

and 2nd - the meta layer, which allows reduce common code patterns to *declarations*.

My first reaction to the Joose syntax is huh, looks like Moose. Which explains the name!

It's kind of weird when other languages start taking innovations from the Perl world...

Perl 6 have been much more influential as a *design* than it has (to date) as an *implementation*...

  • 1

Log in

No account? Create an account