Does this also apply to use of Claude on the Team and Enterprise plans?

> Risk adjusted percentages and mortality odds ratios were adjusted for age at death, sex, race, ethnic group, and educational attainment using logistic regression.

Adjusting for educational attainment is an intriguing choice. If higher educational attainment were to decrease risk of Alzheimer's disease, wouldn't this adjustment optimise out the factor that they're looking for?

Otherwise very interesting results and conclusions. Also what's up with the outlying occupation on the left side of the 1st 2 charts on page 3: "Personal care and service workers, all other" with a mean age of death of 50.65?

Nice, I first saw this on Hack Club ;) Check your terminal to see if it supports certain colours, on mine the darker and lighter colours (eg. maroon/red, purple/magenta) look identical.

Nice to see a larger model in their lineup, I've been using Ternary 8B and it seems to get higher TPS than most other similarly sized models on my hardware.

Allowing people to vote for any project they think is cool is an interesting departure from voting systems of most other Hack Club programmes (most of the time your project will battle for votes in a series of 1v1 matchups). I'm really interested to see how this plays out!

My main concern with these types of programmes is that highly technical yet difficult to demonstrate projects (think programming languages, distributed systems, OSs, CLI tools etc) tend to get disproportionately bad results in voting. People new to programmes like this could be strongly put off by their perceived bad results, and people with knowledge of how the game works will just take their projects to other Hack Club programmes. If I were running this it would have 2 separate groups of prizes: larger ones based on number of hours spent (tracked with Lapse or Hack Hour, because I strongly dislike Hackatime), and smaller ones based on number of votes. However the big flashy prizes (in this case, the Framework laptops) really do attract people – recall that Siege <https://siege.hackclub.com/> was one of Hack Club's best performing efforts despite how easy it was to sink dozens of hours into it and win nothing.

Nonetheless I see the potential and I do hope for a lot of submissions – the programme clearly distances itself from the usual Hack Club status quo ;). Good luck with it!

I wouldn't be surprised if their plan is to keep compatible with 5.1 and adopt newer features where feasible/compatible. Luau, another language with the explicit goal of extending Lua 5.1 in a compatible way, has a section in their documentation listing all newer Lua features and detailing why they chose to or not to adopt them <https://luau.org/compatibility/>. The needs of Luau and LuaJIT are different though the reasoning is nonetheless fascinating.

A comment <https://github.com/LuaJIT/LuaJIT/issues/1475#issuecomment-47...> has already been made on the issue regarding the ternary operator, recommending `if x then y else z` over `x ? y : z`. This is exactly how it's done with if-then-else expressions in Luau <https://luau.org/syntax/#if-then-else-expressions>, another language compatible with Lua, and makes it a ton easier to nest (especially with elseif) and I believe still easier to read than `y if x else z`.

Exactly. I don't understand why people think the ternary operator is needed when you can just make `if` an expression instead of a statement. Then there is no new syntax to learn and `if` just becomes more useful.

I don't really understand where is this need to compress the logic into where small chunks comes from. In result we get single line of code which has multiple statement conditions, different paths, and it's not possible to grasp in one go.

Other practical example why ternary is bad: Many code-coverage solutions break on ternary because they don't correctly see that one of the branches was missed in tests.

Because you can deduplicate certain parts of the logic which make the whole thing less error prone, such as

    if c
      x=1
    else
      x=2

If I ever want to change x, or refactor this code some other way, its a more brittle process over x=c?1:2

The ternary expression also takes up much less space so there is less of an emphasis on it, this can be a stylistic tool in a programmer's toolbox

the oposite is also true, you can have misleading side effects coming from joining things into a single expression

I think that allowing an if statement to return a value to deal with the ternary introduces a now concept to Lua and that is that the value on the final line of a block is a return value much like Ruby. This changes the logic of the entire language more than adding a ternary. I do prefer the if statement as it allows so much more emergent behaviour, but it does have more implications to consider.

I suppose, though I feel what most people in this thread are thinking of is updating the existing if statement to also work as an expression, which does have plenty of implications (not that I think they would be bad, just more of a change to the language than the feature designers were going for) including final returns. The example I took from Luau still keeps the if statement and the if-then-else expression as separate constructs. One problem is that the statement and expression versions look very similar despite having different semantics (expression version must only contain expressions in its branches, must have an `else` case, does not have `end`).

Of course there are differences between LuaJIT and Luau that I think influence their decisions on possible ternary expression features:

- Luau users are disproportionately beginners to programming that I believe would find the if-then-else expression syntax easier to learn; LuaJIT developers have a larger user base of professional devs wanting to make their code faster, and they will probably be more familiar with the `x ? y : z` style since it's used in plenty of other languages.

- Luau is a lot faster moving in its development than LuaJIT in terms of language features, the Luau team just wanted to move people to ternaries from `x and y or z` because it's easier to optimise in a normal interpreter; LuaJIT, with their JIT, I assume would be able to more easily implement optimisations for constructs like `x and y or z` despite its slight semantic differences (my assumption on why the change is being considered now rather than earlier).

The ternary operator is easy to nest if you put each clause on a separate line. Then it looks just like nested if-then-else.

I love the ternary operator as much as anyone. But dang if it doesn't get hard to read when there is are a few, nested even.

Does that operator compile to faster assembly that if I make the same logic with verbose `if` logic? Is that a language specific outcome?

    cond1 ? res1 :
    cond2 ? res2 :
    cond3 ? res3 :
    or_else_res

If they are truly nested, then that is confusing. But if you have an if-else chain, then it can be quite readable.

Or they could just ask granddaddy for advice:

  (cond (cond1 res1)
        (cond2 res2)
        (cond3 res3)
        (t     else_res))

=)

An elegant weapon, for a more civilized age...

I find that so much harder to read compared to if/else or case/when in ruby.

The ? is basically an attempt to use fewer if/else, at the cost of condensed if-else like structure. I always need to look at both parts after the ? whereas in a single if or elsif I don't. case/when in ruby is even better here e. g. regex check:

   def foo(i)
     case i
     when /^cat/
       handle_cats
     when /^dog/
       handle_dogs

(I ommitted the "end"s here to just focus on the conditional logic.)

or

  if cond1 then res1
  else if cond2 then res2
  else if cond3 then res3
  else or_else_res

or

  if cond1 then res1
  elif cond2 then res2
  elif cond3 then res3
  else or_else_res

what is most lua-like?

Unless you mess up its associativity, like PHP until 7.4.

https://wiki.php.net/rfc/ternary_associativity

http://phpsadness.com/sad/30

Congrats on the 1.0.0 release! Being able to write custom tooling in Luau using the Luau parsing APIs will be awesome. Hopefully it makes updating tools to use new Luau features easier – at the moment I have a workflow with a custom-built parser which I'd have to modify to support, for example, the new `const` declarations; having easy access (from scripts) to regularly-updated parser APIs is a big deal for a language that's moving as quickly as Luau is.

Finally. The option for me to enable Copilot data sharing has been locked as disabled for some time, so until now I couldn't even enable it if I wanted to.