Lil: A Scripting Language(beyondloom.com) |
Lil: A Scripting Language(beyondloom.com) |
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.
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.
Lisps are a good example of using emptiness well, I wouldn't want an empty Lua table to be false, but you can't do classic Lisp programming without a falsy empty list, I wouldn't have it any other way. Large Lisp programs have their problems but it isn't the empty list causing those.
I wouldn't want to use Lil for the things I use Lua for. I think it's a great match for what Decker is doing here.
I would not want to use a language with a spongy type system for any code I'm distributing to other people But for quick one-off scripts that only I will use, it is quite convenient.
[1] http://runtimeterror.com/tech/lil/
[2] https://www.little-lang.org/, https://news.ycombinator.com/item?id=26204218
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)
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?
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`.
Typical argument for the "From table select column" are due to better matching evaluation logic and improving type-ahead suggestions in IDE's, but I haven't yet heard the argument that it also makes parsing simpler.
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!
Decker, a platform that builds on the legacy of Hypercard and classic macOS - https://news.ycombinator.com/item?id=33377964 - Oct 2022 (85 comments)
Noooooo, this is a terrible idea if you want this to be used at any non-trivial scale
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.
Perhaps have a switch that can enables stronger type checking.
Writing the parser as a process has made me (even) more familiar with SQL syntax and semantics and understand it better, which has only increased my disgust[1] of the whole matted thorny snarl that it is. I was asking for a dose of rationality for Lil, not a syntactic infection inherited from a misdesigned language. HTH.
(BTW the designers of SQL knew well that it had other problems and admitted them, eg. search for "A Critique of ANSI SQL Isolation Levels").
[1] yeah, that's the right word.
I'm generally positive about restricting undefined behavior at a lower level (syntax, undefined field accesses, etc), but at a higher level (writing large scale applications, using it outside of intended domains, etc) it's not very clear how and even if you should restrict unintended usage.
The more room you have for "undefined behavior" at a higher level, the more people can explore using a tool in various ways you never thought about. This can in turn be valuable feedback on possible directions to expand your tool in.
test ! "${configdir}"||rm -rf "~/${configdir}"
[ "${configdir}" ]&&rm -rf "~/${configdir}"
test x"${configdir}" = x""||rm -rf "~/${configdir}"
[ x"${configdir}" != x"" ]&&rm -rf "~/${configdir}"
You can also set the "-u" option (in Zsh, `setopt no_unset`) which at least will cause your script to crash with an error if you happen to forget this check. But then you have to remember to set that option as well!
Lua has a similar-ish problem with undefined variables being `nil`, but for the most part Lua is also rather strictly typed, and that will typically end up causing some kind of error deep inside a function call, rather than doing something dangerous silently.
That's Lua for you. The semantic model is dead simple and easy to understand, and even though roughly no one wants typos to become variables, the semantics would have to be less minimal to accomplish this.
So instead, there's a mechanism, a more than adequate one, but one does have to use it.
test "${#configdir}" -lt 1||rm -rf "~/${configdir}"
[ "${#configdir}" -gt 0 ]&&rm -rf "~/${configdir}"