Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lil: A Scripting Language

beyondloom.com

Post reply on HN
Print view View original

11–20 of 29 posts

Re: Lil: A Scripting Language

#11

Post by notacoward »

samatman wrote: post #9
zasdffaa wrote: post #4

> 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

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 wheneve…

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.

Re: Lil: A Scripting Language

#12

Post by tuke »

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`.

Re: Lil: A Scripting Language

#13

Post by samatman »

nerdponx wrote: post #5
samatman wrote: post #2

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 ha…

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 excepti…

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.

Re: Lil: A Scripting Language

#14

Post by zasdffaa »

tuke wrote: post #12

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`.

Having written an sql parser, I very very strongly agree.

Re: Lil: A Scripting Language

#15

Post by zasdffaa »

samatman wrote: post #9
zasdffaa wrote: post #4

> 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

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 wheneve…

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.

Re: Lil: A Scripting Language

#16

Post by hmry »

nerdponx wrote: post #5
samatman wrote: post #2

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 ha…

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 excepti…

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.

Re: Lil: A Scripting Language

#17

Post by throwamon »

gjm11 wrote: post #8
unsafecast wrote: post #7

Earlier quoted context omitted.

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.

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.

I mean, Excel does have LET and LAMBDA now...

Re: Lil: A Scripting Language

#18

Post by 1vuio0pswjnm7 »

hmry wrote: post #16
nerdponx wrote: post #5

Earlier quoted context omitted.

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 excepti…

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 qui…

   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.

Re: Lil: A Scripting Language

#19

Post by nerdponx »

1vuio0pswjnm7 wrote: post #18
hmry wrote: post #16

Earlier quoted context omitted.

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 qui…

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 acci…

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.

Re: Lil: A Scripting Language

#20

Post by expazl »

zasdffaa wrote: post #14
tuke wrote: post #12

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`.

Having written an sql parser, I very very strongly agree.

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.

Post reply on HN