[Openmcl-devel] prompt-for-file (embarrassing question)

[mikel evins]

MCL's good features are partly effects of the platform it was developed on. Old Mac systems didn't really have an OS; they had a ROM-based subroutine library. Application code could do whatever it wanted to; there was no memory protection and no real process model. All of the system's APIs were fully documented in Inside Macintosh, which was three volumes before the Mac Plus, and six volumes by the release of System 7 (though volume 6 was really big).

Nowadays full documentation of the macOS APIs probably requires at least one whole bookshelf, and you aren't as free to do what you like. As examples, you can't just open a window from any old thread in any old process, and you can't inspect arbitrary objects in arbitrary memory.

I's just a lot more work nowadays to build the kinds of stuff that MCL did.

Not to mention that before you can build it, you have to have a clear idea of what to build. MCL was a specific approach to building UIs for a specific platform. You can't just recapitulate MCL. That platform no longer exists and neither, really, does that style of UI. I think if you want a system for building UI that is as approachable and yet flexible as MCL was, you need to start with a pretty clear idea of what makes building a UI good and easy and flexible, but one that fits reasonably into the present day's context. That almost certainly means not trying to be everything to everybody. I suspect it means inventing a fairly specific set of parts and clear and specific ways of plugging them together.

An example of something that accomplished that pretty well is HyperCard. I'm not saying you should build HyperCard. I'm saying HyperCard was specific about exactly what its parts were and how they fit together, and it rejected features that did not fit its model. That kept its complexity down to a manageable level and made it possible to turn out something that was easy and approachable. I think some comparable organizing idea is needed to enable you to keep the feature surface manageably small, both so that you can actually ship it, and so that it actually appears easy and understandable to people who use it.

SK8 isn't very well known, but it did a pretty good job of removing some of HyperCard's limitations and yet remaining highly approachable for people who weren't expert programmers. Of course, it was built on MCL, but equally importantly, it started from HyperCard's easily-graspable conceptual foundation and expanded it judiciously to offer more flexibility and power without abandoning what made HyperCard easy to learn.