News for hackers. Stuff that matters.
Re:An Overview of the Starlark Language by kccqzy on Thursday June 06, 2024 @12:36PM (#40599449)
The problem with "works for every program I am likely to encounter" is that you don't know what kind of programs your users are writing.

Well, now that I think more about it, except when you are Google or Meta and you have a giant monorepo full of code that users of this language has actually written. So if Starlark were to gain a type system, the type system designer would probably just run it through the entire Starlark code at Google.

Speaking of Meta, this suddenly reminds me of Flow https://flow.org/ an effort at Meta to add a bolt-on type system to JavaScript. Naturally it doesn't aim to "work well" 100% of the time but maybe working 80% of the time is already valuable enough for them to use and announce it.

Re:An Overview of the Starlark Language by vlovich123 on Thursday June 06, 2024 @02:36PM (#40600819)
> is that you don't know what kind of programs your users are writing

Except we have lots of easily accessible OSS code available via GitHub/GitLab etc in addition to self-reporting from closed repos. Can you find any instance of an omega combinator in use? I'm not even sure omega combinator is relevant to Starlark given that Starlark is a more limited language derived from Python. For example, it doesn't typically allow for recursion which I believe would be required to express an Omega combinator within it. Yes I know the definition of the combinator says it's not recursive, but that's in a pure CS sense. In a practical sense, there's not much difference between a function being passed itself as an argument and then invoking it vs invoking itself directly, particularly from an enforcement perspective. Indeed, you can verify it'll fail the recursion prevention code in Starlark [1]

[1] https://github.com/bazelbuild/bazel/blob/e1a73e6e89a082e3d80...