Sketchpad the first OO model is about templates and prototypes ?
Contrary to the revisionist claim that Smalltalk started the whole GUI revolution, it was sketchpad that did that. And it was done is assembly.
In sketchpad the notion of objects meant “widgets”, things you see on the screen. An object basically means anything you can draw on the screen. That makes sense doesn’t it ?
Key concepts in the paper,
- Master Object / Copy Instance … if you change anything in the master the change is reflected in all the copies.
- Using Blocks to create Master Objects. Blocks are data structures with placeholders in them which are later edited when creating Master Objects.
- Linking multiple objects by constraints so that if you change on, others are changed as well.
Master / Copy / Blocks are also terms used in the printing press! Come to think of it the challenges in both sketchpad and the printing press are the same. In the printing press, letters (called blocks here) are arranged into a templates, which is stored permanatly as a stereotype. From the template, which had placeholders for pictures and decoration you would create a Master and from the Master you create more copies. Here you can see Stephen fry print some stuff. On a side note, assuming you get a 1 million page views in an hour, that means you are printing 1500 pages minute, how wicked is that!
Blocks in Sketchpad are the same as Templates in printing press. I will use the word templates to mean both these. The notion of templates is popular in non-programmers as well whether it be word templates or excel templates or photoshop templates or ableton templates. The notion of template makes a lot of sense once you can of think of anything that has the use case of creating lots of variations from a single base.
I would wager this means, that Template systems like PHP and Liquid are more closer to Sketchpad style of OO than C++/Java/Smalltalk. No wonder it is PHP that powers 70% of the web. The vile and dirty PHP. Basic procedural PHP, without frameworks allows you to create pages very easily. The concept of Master and Copy makes the action at a distance notion very explicit unlike inheritance that hides this concept in the background. If you change the base template, all the copies are affected. C Macros / C++ generics / Ruby Scaffolding / Lisp Macros too come to mind. Rails Scaffolding is probably the equivalent to Lisp macros. In some sense with closures, you can model create placeholders in the runtime with functions. Generic functions too fit here probably because they build on closures.
The reuse capabilities of closures, scaffolds and templates are easier to explain. The phrase “B modifies A”, “B hooks into A” is much better than “B extends A”. These techniques better at code reuse than class inheritance because it is 1 level as opposed to multi level class inheritiance. How many times has the function sort been reused by passing a comparator function ? How easy was it ? How easy is it to reuse code between React and React 15 projects by inheritance ? Can React code be made re-usable with closures instead of inheritance ? Closure B is using A’s code - Changes in B can’t effect code inside A.
Sketchpad also makes it obvious where objects and object thinking is useful, when you have use cases just like the printing press where you build the master copy carefully and build multiple copies from the master like widgets, in all other cases Data and Code should be separated with the help of Modules and Records. The real genius of sketchpad if you have seen the demo, is contraints not “methods” that makes skeletal animations possible. I suppose constraints are bit also like spreadsheets where changes in columns are notified to forumlas, which further propagate value changes. This thinking is completely absent in the OO world which has a half baked notion of obervers. Nowadays we have reactive programming which makes obervers actually useful but we are still yet to capture Sketchpad’s notion of constraints in any meaningful way. I can definitely see game programmers, photoshop users and autocad users utilising this idea to be build complex visual objects. To think that this was done in 1957, in nothing but assembly code is astounding. I could not make it out, but it seems that Ivan Sutherland was using something like today’s Raspberry Pi back in the day.