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.
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.
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 cast to boolean to get the truthiness of anything.
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.
This is really task/domain-dependent. It's convenient in shell scripts and AWK, but in bigger programs it really isn't good.
One of the things I love about Python is that its type system is actually quite strong, in that implicit conversion is very rare in the standard library and somewhat frowned upon in general. Having "falsy" and "truthy" values that are not actually `bool` instances is maybe the only big exception.
To clarify for others who only follow the link titles, this is not the Tcl-inspired scripting language LIL[1] nor the other Tcl-based, C-clothing-wearing scripting language Little[2].
Amusingly enough, like the linked article's Lil, i used my LIL ~11 years ago to make a HyperCard-inspired painting+card-based database hybrid[0][1] :-P. But mine was something i only played around with for a bit but ultimately abandoned.
Since the language is Tcl-like, i had some commands like "set", "get", etc to ignore arguments like "of", "the", etc for a HyperTalk-ish flavor :-P (obviously in practice the syntax is actually very different and that can be seen in the calculator video[0] below when it comes to expressions).
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.
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?
On their github [0] they mention that they like making compilers, and on the about page on their site [1] they say they like tinkering with new languages. I think they just had a cool idea for a project and wanted to build a language to base it off of with features that were convenient for their goal, and a syntax they enjoyed.
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.
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.
Some of the little applications I made in an hour or two each (with live help from the creator of Lil):
- a plotting program that tweens between two different plots when you move a slider
- a frame based traditional animation program
- a (color!) paint program with reflections for drawing little mandalas
It's actually quite a nice tool for rapidly prototyping all kinds of applications.
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!
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.
samatman|3 years ago
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.
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 cast to boolean to get the truthiness of anything.
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.
nerdponx|3 years ago
One of the things I love about Python is that its type system is actually quite strong, in that implicit conversion is very rare in the standard library and somewhat frowned upon in general. Having "falsy" and "truthy" values that are not actually `bool` instances is maybe the only big exception.
mananaysiempre|3 years ago
[1] http://runtimeterror.com/tech/lil/
[2] https://www.little-lang.org/, https://news.ycombinator.com/item?id=26204218
badsectoracula|3 years ago
Since the language is Tcl-like, i had some commands like "set", "get", etc to ignore arguments like "of", "the", etc for a HyperTalk-ish flavor :-P (obviously in practice the syntax is actually very different and that can be seen in the calculator video[0] below when it comes to expressions).
[0] https://www.youtube.com/watch?v=rshZHDDruAE (making a calculator, shows more LIL)
[1] https://www.youtube.com/watch?v=_8CYosAIIJw (making a telephone book, shows more painting)
nerdponx|3 years ago
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?
xypage|3 years ago
[0]:https://github.com/JohnEarnest
[1]: https://beyondloom.com/about/index.html
tuke|3 years ago
I see the query language goes: `select ... from`
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.
You type, say, `from people` and you can get a suggestion for `name`.
zasdffaa|3 years ago
tangentstorm|3 years ago
Some of the little applications I made in an hour or two each (with live help from the creator of Lil):
- a plotting program that tweens between two different plots when you move a slider
- a frame based traditional animation program
- a (color!) paint program with reflections for drawing little mandalas
It's actually quite a nice tool for rapidly prototyping all kinds of applications.
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!
hoosieree|3 years ago
dang|3 years ago
Decker, a platform that builds on the legacy of Hypercard and classic macOS - https://news.ycombinator.com/item?id=33377964 - Oct 2022 (85 comments)
zasdffaa|3 years ago
Noooooo, this is a terrible idea if you want this to be used at any non-trivial scale
samatman|3 years ago
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.
unsafecast|3 years ago