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.
This makes me think of the many programmers who started with BASIC on the early 6502/Z80 systems. BASIC of that era was a truly atrocious language (it got better later) but many of those people went on to learn better tools and make the computing world we know today. The original primitive tool served its purpose, which was largely to get people excited about the possibility of shaping their own experience instead of just consuming prepackaged applications. AFAICT Lil is a far better language than early BASIC, and that's enough.
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.