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.

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

Sigh, <> isn't the only way, D (as usual) has a very simple and clever solution f!(types)(parameter)

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}

> "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.

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.

What's the difference to you for using {} vs <>?

< 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.

I feel like this is a solvable problem. For instance you could require parens in the case of expressions using < or > characters.

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.

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.

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