This is something I feared would happen and where open source would be left behind. Maybe they can do something with crowd-sourcing computational power from volunteirs. They were after all able to get Leela Chess Zero to be comparable to AlphaZero by training from volunteer processing power but it seems to me we live in a world now where the best models keep their stuff closed.

In imagine generation too. I'm not sure how well Stable Diffusion can compete in following instructions with all those advanced models that are kept secret.

Scheme Structs are rather interesting, when you define a struct the language by default also exports getter and setter functions with a predictable name though you can override the default name to give them any name, privacy is simply created by choosing to not export these getter and setter functions from the module.

Privacy on the module level rather than on the class level is a far better pattern to be honest. As in other classes defined in the same module can still have access to them.

Kay also considers CLOS and related things “true OO” and those do repeat class name in method call.

    |> 
   ()

For a variadic language you'd need something more involved though. But some kind of syntax can probably be invented in some language.

I also like how in Haskell:

   something =
     { element
     , element1
     , element2
     , element3
     }

That this doesn't have a clear and obvious answer one can expect shows how the issue is politics, not strategy.

When you apply as a mechanic, there is no such weird political debates about certain power tools where people have passionate opinions on which tool to use.

I'm fine with taxing it more in subsidized single-payer healthcare systems though but I also feel that should be done more consistently. I for instance also believe that say high heels should be taxed more because they're bad for one's health for similar reasons or unhealthy food but that's not “socially controversial” enough for that I get which is ultimately what it's always about. “health” is always just an excuse.

People die during parachuting and climbing mount everest. What's the upside really beyond “People enjoy doing it and it's their own life.”?

That's one way to look at it, but the major difference is that one can also pass a a list as one argument, as in `(f x y z)` and `(f (list x y z)` are not the same. The thing with tuples is that a tuple of one datum is the very same as that datum itself and the same is true with the currying situation. `(f x) y` and `f x y` are truly one and the same in Haskell and Ocaml, just as `f(x, y)` and `let val a = (x,y) in f x` are one and the same in SML. This is not the case in Rust where `f(x,y)`, a function called with two arguments, and `f((x,y))`, a function called with one argument that is a tuple of two arguments are two different things.

There is also a difference in Scheme between returning a single value that is a list containing multiple values, and actually returning multiple values, In Rust however there is no difference between returning two values and returning a pair of two values. So Rust functions actually do properly take multiple arguments but always return a single one which may or may not be a tuple. In SML, Haskell and OCaml all functions technically take only one argument and return one value.

Seems like a disaster to use s-expressions for a language like that. I love s-expressions but they only make sense for variadic languages. The entire point of them is to quickly delimit how many arguments are passed.

In say Haskell `f x y z` is the same thing as `(((f x) y) z)`. That is definitely not the case with s-expressions; braces don't delimit; they denote function application. It's like saying that `f(x,y,z)` being the same as `f(x)(y)(z)` which it really isn't. The point of s-expressions is that you often find yourself calling functions with many arguments that are themselves a result of a function application, at that point `foo(a)(g(a,b), h(x,y))` just becomes easier to parse as ((foo a) (g a b) (h x y))`.