5 ms·

I would argue that `end` is a much better choice than both the Python approach and curly braces: https://erik-engheim.medium.com/the-case-against-curly-braces-l

I would argue that `end` is a much better choice than both the Python approach and curly braces: https://erik-engheim.medium.com/the-case-against-curly-braces-languages-dd0a55840fcb https://erik-engheim.medium.com/the-case-against-curly-brace... `end` marks of blocks of code much more clearly than curly braces. It is also requires fewer keyboard taps. To type {} requires holding down four keys in total (shift-[ twice). end is just three key strokes. But more importantly is saves curly braces for other uses where it is more needed.

eigenspace 6y ago
Yeah, I'm very glad we saved curly braces for type parameters in julia. I really dislike the use of <these> in static languages.
- skohan 6y ago
  What's the difference to you for using {} vs <>?
  - eigenspace 6y ago
    < and > are comparison operators for checking if something is less than or greater than something else. This is okay in a static language where there are special slots for a type where only a restricted subset of things can happen. You'd know at the parser level that the < and > are referring to the type meaning or the operator meaning. In julia, types are values and values can live in types, and arbtrary operations can happen in a type. E.g. I can write Tuple{1 < 2} which just becomes the type Tuple{true}, i.e. a Tuple Type with paramemter True.
    - skohan 6y ago
      I feel like this is a solvable problem. For instance you could require parens in the case of expressions using < or > characters.
      - eigenspace 6y ago
        Or you could just not use them for type parameters. That's also a solution for what it's worth. I think the curly braces look better as type params anyways imo.
- renox 6y ago
  Sigh, <> isn't the only way, D (as usual) has a very simple and clever solution f!(types)(parameter)
  - eigenspace 6y ago
    Maybe it's just my julia indoctrination speaking but I find that rather ugly. In julia, f!(types)(parameter) means that f! is a mutating function acting on types which returns a closure which is then called on parameter. We just write Type{paramemer}
    - jodrellblank 6y ago
      > "We just write Type{paramemer}" It seems odd to say "we just write" for some arbitrary choice with its own tradeoffs; {} mean a set in Python or a literal array initialiser in C# or a scriptblock in PowerShell or a dfn in Dyalog APL or a JSON dictionary, etc. With only a limited set of whatever symbols happened to end up on a US ASCII keyboard 40+ years ago, there is heavy competition for them, it's why J broke the symmetry of pairs and went for two-character symbols, why PowerShell went for comparators like -gt and -lt, why C# has => which is completely different from <=, why << is not a double application of less-than but is bit shifting ... To act like there's an objectively better use for {} is to miss how many tradeoffs there are, and how many things people want symbols for out of a standard keyboard.
      - eigenspace 6y ago
        I never said it was objectively better. My point was just that we find Type{parameter} to be nice pleasing syntax, and so reserved the curly braces for that. Of course it’s not objectively better, that’s a dumb attitude towards syntax.
skohan 6y ago
Typing braces is basically a gesture. You hold the shift key with left pinky, and roll right ring finger pinky over open and close brace, then tap back arrow and return to get you inside the block. End is three distinct key presses. Also braces have a nice symmetry, which is also convenient for parsers and tooling to count opens and closes. I also think "end" is just more visually noisy. Braces are a symbol, so it's easy to filter them out when you're looking at code, but a trail of "end"s takes up more real-estate than is semantically justified.
jodrellblank 6y ago
That's not a particularly convincing blogpost - for example you don't need square brackets for indexing, one of Ken Iverson's changes going from APL to J was to see indexing as just another function application and remove square bracket syntax from it. Grouping arithmetic expression is worsened by complex precedence rules, APL always evaluating right-to-left and all operators having the same precendence changes how that works as well (even though it does have grouping parens too). Then complaining that "<>" are used in mathematical expression, but not being annoyed by "main()" in a function declaration or the "?" and ":" used in the complex type expression? Seems to me that "end" is one of the worse available choices; if we're going for keywords, why not make them "endif", "endfor", "endwhile" (or "wend") which makes it explicitly clear what each of: end end end is ending.
- int_19h 6y ago
  Because it doesn't really help as soon as you get repeated nesting, which isn't all that uncommon.

eigenspace 6y ago

Yeah, I'm very glad we saved curly braces for type parameters in julia. I really dislike the use of <these> in static languages.

skohan 6y ago
What's the difference to you for using {} vs <>?
- eigenspace 6y ago
  < and > are comparison operators for checking if something is less than or greater than something else. This is okay in a static language where there are special slots for a type where only a restricted subset of things can happen. You'd know at the parser level that the < and > are referring to the type meaning or the operator meaning. In julia, types are values and values can live in types, and arbtrary operations can happen in a type. E.g. I can write Tuple{1 < 2} which just becomes the type Tuple{true}, i.e. a Tuple Type with paramemter True.
  - skohan 6y ago
    I feel like this is a solvable problem. For instance you could require parens in the case of expressions using < or > characters.
    - eigenspace 6y ago
      Or you could just not use them for type parameters. That's also a solution for what it's worth. I think the curly braces look better as type params anyways imo.
renox 6y ago
Sigh, <> isn't the only way, D (as usual) has a very simple and clever solution f!(types)(parameter)
- eigenspace 6y ago
  Maybe it's just my julia indoctrination speaking but I find that rather ugly. In julia, f!(types)(parameter) means that f! is a mutating function acting on types which returns a closure which is then called on parameter. We just write Type{paramemer}
  - jodrellblank 6y ago
    > "We just write Type{paramemer}" It seems odd to say "we just write" for some arbitrary choice with its own tradeoffs; {} mean a set in Python or a literal array initialiser in C# or a scriptblock in PowerShell or a dfn in Dyalog APL or a JSON dictionary, etc. With only a limited set of whatever symbols happened to end up on a US ASCII keyboard 40+ years ago, there is heavy competition for them, it's why J broke the symmetry of pairs and went for two-character symbols, why PowerShell went for comparators like -gt and -lt, why C# has => which is completely different from <=, why << is not a double application of less-than but is bit shifting ... To act like there's an objectively better use for {} is to miss how many tradeoffs there are, and how many things people want symbols for out of a standard keyboard.
    - eigenspace 6y ago
      I never said it was objectively better. My point was just that we find Type{parameter} to be nice pleasing syntax, and so reserved the curly braces for that. Of course it’s not objectively better, that’s a dumb attitude towards syntax.

skohan 6y ago

Typing braces is basically a gesture. You hold the shift key with left pinky, and roll right ring finger pinky over open and close brace, then tap back arrow and return to get you inside the block. End is three distinct key presses. Also braces have a nice symmetry, which is also convenient for parsers and tooling to count opens and closes. I also think "end" is just more visually noisy. Braces are a symbol, so it's easy to filter them out when you're looking at code, but a trail of "end"s takes up more real-estate than is semantically justified.

jodrellblank 6y ago

That's not a particularly convincing blogpost - for example you don't need square brackets for indexing, one of Ken Iverson's changes going from APL to J was to see indexing as just another function application and remove square bracket syntax from it. Grouping arithmetic expression is worsened by complex precedence rules, APL always evaluating right-to-left and all operators having the same precendence changes how that works as well (even though it does have grouping parens too). Then complaining that "<>" are used in mathematical expression, but not being annoyed by "main()" in a function declaration or the "?" and ":" used in the complex type expression? Seems to me that "end" is one of the worse available choices; if we're going for keywords, why not make them "endif", "endfor", "endwhile" (or "wend") which makes it explicitly clear what each of: end end end is ending.

int_19h 6y ago
Because it doesn't really help as soon as you get repeated nesting, which isn't all that uncommon.