5 ms·

New scripting language which claims to be fast and includes LuaJIT as a comparison in the benchmarks? That is a real test. To do a surface level bikeshed: not

New scripting language which claims to be fast and includes LuaJIT as a comparison in the benchmarks? That is a real test. To do a surface level bikeshed: not a huge fan of whitespace or braces. Needless flexibility in the language when they could just pick one. If there is an eventual code formatter, I assume the decision will be made then.

xcombelle 3y ago
Looks like the doc is written without braces. As such, I guess, that the canonical code is without braces
eviks 3y ago
Here is a concrete need for the flexibility: you can have clean pythonic view by default, but then improve readability with a denser design if you want if (n < 2) { return n else { return fibR(n - 1) + fibR(n - 2)}
- eternityforest 3y ago
  That only works if you're manually formatting the code, hard to imagine a deterministic rule for deciding when to compress, that won't disappoint people rather often. It's a bit too obscure. I can't imagine when I'd ever manually format.
  - postpawl 3y ago
    Yeah, having to change 2nd IF statement line just because you changed the conditions on the 1st IF statement seems like a big negative.
  - eviks 3y ago
    That's the beauty of flexibility - for those cases where beauty matters, it's reachable, but not forced upon anyone else I don't even find it that hard to imagine (I can even imagine multiple seamlessly integrated AI-suggested options generated based on your previously handcrafted examples), but agree with your underlying point that that's likely not going to happen given the state of tooling design across the board
    - eternityforest 3y ago
      Once someone uses a flexible feature, everyone else who works on the codebase has to deal with it too. Anyone who thinks of code as more of an implementation detail than a goal probably won't like not being able to just click auto format and forget it.
      - eviks 3y ago
        So what? It's not like pythonic whitespace prevents similar manual alignment incompatible with autoformat like if x=1... if y=2 So you still have to resolve the coding style conflict somehow
        eternityforest 3y ago
        You can resolve it by choosing a standard style for the whole project and letting auto format do the rest. Maybe even auto rejecting commits that don't match it, like some projects do. You could of course do the same with a flexible language, but without manual formatting at least some part there's probably not going to be as much benefit. I guess you could say "auto format leaves braces alone" but then you don't have a fully machine executable style. Maybe you could have the auto format just always compact the braces, but that seems like encouraging dense one liners, most projects probably want to discourage that.
        eviks 3y ago
        You can't resolve it because it's manual formatting that's not part of the auto format rules, that's the point! And this doesn't depend on braces vs whitespace, manual improvements are possible in either case, so your argument against {} vs space flexibility doesn't have the benefit of forcing machine executable style
- Alifatisk 3y ago
  I think you forgot an curly brace after the if-statement

xcombelle 3y ago

Looks like the doc is written without braces. As such, I guess, that the canonical code is without braces

eviks 3y ago

Here is a concrete need for the flexibility: you can have clean pythonic view by default, but then improve readability with a denser design if you want if (n < 2) { return n else { return fibR(n - 1) + fibR(n - 2)}

eternityforest 3y ago
That only works if you're manually formatting the code, hard to imagine a deterministic rule for deciding when to compress, that won't disappoint people rather often. It's a bit too obscure. I can't imagine when I'd ever manually format.
- postpawl 3y ago
  Yeah, having to change 2nd IF statement line just because you changed the conditions on the 1st IF statement seems like a big negative.
- eviks 3y ago
  That's the beauty of flexibility - for those cases where beauty matters, it's reachable, but not forced upon anyone else I don't even find it that hard to imagine (I can even imagine multiple seamlessly integrated AI-suggested options generated based on your previously handcrafted examples), but agree with your underlying point that that's likely not going to happen given the state of tooling design across the board
  - eternityforest 3y ago
    Once someone uses a flexible feature, everyone else who works on the codebase has to deal with it too. Anyone who thinks of code as more of an implementation detail than a goal probably won't like not being able to just click auto format and forget it.
    - eviks 3y ago
      So what? It's not like pythonic whitespace prevents similar manual alignment incompatible with autoformat like if x=1... if y=2 So you still have to resolve the coding style conflict somehow
      - eternityforest 3y ago
        You can resolve it by choosing a standard style for the whole project and letting auto format do the rest. Maybe even auto rejecting commits that don't match it, like some projects do. You could of course do the same with a flexible language, but without manual formatting at least some part there's probably not going to be as much benefit. I guess you could say "auto format leaves braces alone" but then you don't have a fully machine executable style. Maybe you could have the auto format just always compact the braces, but that seems like encouraging dense one liners, most projects probably want to discourage that.
        eviks 3y ago
        You can't resolve it because it's manual formatting that's not part of the auto format rules, that's the point! And this doesn't depend on braces vs whitespace, manual improvements are possible in either case, so your argument against {} vs space flexibility doesn't have the benefit of forcing machine executable style
Alifatisk 3y ago
I think you forgot an curly brace after the if-statement