The 'soft, spongy' type system is nice to see. That kind of strong dynamism is a good choice for the application: it will do the wrong thing sometimes, but will throw fewer show-stopping errors, which are really disheartening for casuals.<p>I do regard casting not-numbers to 0 as a flaw. I've had plenty of bugs where I wished `nil` would automatically cast to to `""` in string position, or the empty list/dict: but I have never, once, wanted a missing number to cast to 0.<p>The number zero doesn't have the "semantics of emptiness" in programming. It shouldn't be treated as false, either, unless we're dealing with a "raw" language, in which case, one should have to at least <i>cast</i> to boolean to get the truthiness of anything.<p>Personally, I would promote this to an error, because the other option, 'NaN', is itself a source of confusion. But at least NaN-poisoning the calculation will eventually inform the user that "htree" isn't a number.
To clarify for others who only follow the link titles, this is not the Tcl-inspired scripting language LIL[1] nor the <i>other</i> Tcl-based, C-clothing-wearing scripting language Little[2].<p>[1] <a href="http://runtimeterror.com/tech/lil/" rel="nofollow">http://runtimeterror.com/tech/lil/</a><p>[2] <a href="https://www.little-lang.org/" rel="nofollow">https://www.little-lang.org/</a>, <a href="https://news.ycombinator.com/item?id=26204218" rel="nofollow">https://news.ycombinator.com/item?id=26204218</a>
This looks like a really interesting set of language features. I do wonder why they decided to invent their own entirely new language though, instead of building on Tcl or Lua or a Basic dialect. Or even embedding Python. I can understand not wanting to use Scheme due to S-expressions being intimidating.<p>Did they consider them harder to learn in layers? Did they feel like some language features were lacking, or were unnecessary/undesirable? Were there problems with syntax that prevented Decker scripts from looking the way they wanted them to look?
Nice. The embedded querying is neat.<p>I see the query language goes: `select ... from`<p>One thing I like about query languages that start with the "from" class is that then it's easier in REPLs to provide suggestions for what can be selected.<p>You type, say, `from people` and you can get a suggestion for `name`.
I've had the pleasure of alpha-testing several builds of lil and decker. It's nice to see that it's out in the wild now.<p>Some of the little applications I made in an hour or two each (with live help from the creator of Lil):<p>- a plotting program that tweens between two different plots when you move a slider<p>- a frame based traditional animation program<p>- a (color!) paint program with reflections for drawing little mandalas<p>It's actually quite a nice tool for rapidly prototyping all kinds of applications.<p>Also, I'm not sure if it's obvious from the given link, but there are implementations of both lil and decker in both C and JavaScript, so it's an incredibly portable little system!
Wow, the GUI calculator demo in ~2 minutes is pretty impressive: <a href="https://beyondloom.com/decker/" rel="nofollow">https://beyondloom.com/decker/</a>
Recent and related:<p><i>Decker, a platform that builds on the legacy of Hypercard and classic macOS</i> - <a href="https://news.ycombinator.com/item?id=33377964" rel="nofollow">https://news.ycombinator.com/item?id=33377964</a> - Oct 2022 (85 comments)
> Lil has a soft, spongy, dynamic type system in which values do their best to convert to a more relevant type as the need arises.<p>Noooooo, this is a terrible idea if you want this to be used at any non-trivial scale