[HN Gopher] Lil: A Scripting Language
___________________________________________________________________
Lil: A Scripting Language
Author : razetime
Score : 88 points
Date : 2022-10-30 10:54 UTC (12 hours ago)
(HTM) web link (beyondloom.com)
(TXT) w3m dump (beyondloom.com)
| tuke wrote:
| Nice. The embedded querying is neat.
|
| 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 wrote:
| Having written an sql parser, I very very strongly agree.
| expazl wrote:
| I'm curious to know which part of the parsing becomes easier
| with Select moved later in the statements?
|
| 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.
| zasdffaa wrote:
| Good question, my answer was misleading. It changes
| virtually nothing in the parse or in the resulting AST.
|
| 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.
| mananaysiempre wrote:
| 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].
|
| [1] http://runtimeterror.com/tech/lil/
|
| [2] https://www.little-lang.org/,
| https://news.ycombinator.com/item?id=26204218
| badsectoracula wrote:
| 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).
|
| [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)
| hoosieree wrote:
| Wow, the GUI calculator demo in ~2 minutes is pretty impressive:
| https://beyondloom.com/decker/
| zasdffaa wrote:
| > 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.
|
| Noooooo, this is a terrible idea if you want this to be used at
| any non-trivial scale
| samatman wrote:
| 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.
| zasdffaa wrote:
| Turning mistakes into possibly unwanted run-time behaviour is
| dodgy. The user may end up with a problem that's harder to
| debug than just a crash.
|
| Perhaps have a switch that can enables stronger type
| checking.
| notacoward wrote:
| 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.
| unsafecast wrote:
| This is a very domain-specific language, not designed to be
| used at a nontrivial scale. I think it's a good idea in this
| context.
| gjm11 wrote:
| Unfortunately, the fact that a system is not designed to be
| used at a nontrivial scale is no guarantee that it _won 't_
| be used that way. For instance, there are a lot of Excel
| worksheets doing things I am sure the designers of Excel
| never expected Excel to have to do.
| throwamon wrote:
| I mean, Excel does have LET and LAMBDA now...
| samatman wrote:
| 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.
| nerdponx wrote:
| 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.
| hmry wrote:
| Definitely. I would argue even in shell scripts it's not
| always great. Just thinking about all those times rm -rf
| "~/${configdir}" accidentally wiped someone's home directory
| because that unset variable was implicitly turned into an
| empty string, etc.
|
| 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.
| 1vuio0pswjnm7 wrote:
| test ! "${configdir}"||rm -rf "~/${configdir}"
| [ "${configdir}" ]&&rm -rf "~/${configdir}"
| test x"${configdir}" = x""||rm -rf "~/${configdir}"
| [ x"${configdir}" != x"" ]&&rm -rf "~/${configdir}"
|
| This assumes NetBSD ash or Debian ash which is what I use.
| I write scripts for me, not for others and often end up
| using "quick one-off" scripts for years. After decades of
| using UNIX, I have never wiped a root directory
| accidentally (but there is still time). YMMV.
| nerdponx wrote:
| Sure, and in Zsh you can do `(( $+configdir ))` if you
| want to differentiate "unset" from "empty". But the fact
| that you need this check at all demonstrates the
| existence of a problem.
|
| 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.
| samatman wrote:
| Lua hits my personal sweet spot for robustness vs. precision,
| Python is good enough to be worth criticizing, but hey,
| pleasant enough.
|
| 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.
| nerdponx wrote:
| 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?
| tangentstorm wrote:
| 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!
___________________________________________________________________
(page generated 2022-10-30 23:01 UTC)