|
Triviality is in the eye of the beholder, but I consider this the correct choice for the application. I've already registered my one objection, but don't mind expanding on why I think this is a good idea. Lil is designed for an interesting, if a bit retro, reboot of HyperCard. The fantastic thing about HyperCard was the ability for a user to just... change stuff. In a HyperCard system, users become developers whenever they want to. They're going to make mistakes. A lot of mistakes. Mistakes you and I, as developers, won't understand. What should the runtime do? Not break. "Attempt to index a nil value" is a cruel thing to tell someone who is trying to create a dictionary. What this does: "oh, you're trying to index this value? Ok, it's an empty dictionary now". "Oh, you're trying to sort it into a drop-down list? Empty string, nothing happens". HyperCard scale isn't dozens of developers working on a cadence, with branches and merge reviews. HyperCard scale is someone making something really cool, and dozens, maybe hundreds, of personalizations. Some shared, some not. The distinction between, say, adding photos to a gallery, and adding a photo editor to the stack, is not sharp in HyperCard. I'm very pleased to see this project, although I think the retro aesthetic might be self-limiting at some point. The loss of HyperCard was a real one, we're suffering from it to this day. |