Not that dumb as one might think. What is the purpose of the opening brace after a function declaration in C, for example? It's the only token accepted, so its sole purpose is symmetry with the closing brace, which has an actual purpose.

So it might look silly, but there is no deep reason it couldn't have just been

    int main()
       printf("hello");
    }

That's just as unambiguous to parse.

Technically, the opening brace is needed in C to support K&R style function declarations which apparently were still legal in C11 at least, but I doubt that's a feature anyone wants to replicate in a new language.

Not in the original C, where you had to declare function parameter types like so:

  int foo(x)
    int x;
  {
      return x;
  }

and not in C23 (or GNU C) either, where this is legal (this example is not super useful):

  int foo(int x) [[gnu::aligned]] {
    return x;
  }

In that case, I would prefer Pascal’s (and Basic’s) “end”, however.

Unmatched braces completely mess up text editors, which would need to include a full parser in order to pair-match brackets (it also creates an unresolved tension that will stay with you all day :)

I was going to say the same. And yes - it causes OCD in 90% of devs out there. But it also feels somewhat wrong for editors to match brackets to infer block hierarchy. What if blocks have some sane rule that we don't know yet (i.e other than bracketed blocks and indented blocks)? Perhaps treesitter is the one-stop solution for that problem.

Indeed. Things like di{ probably don't work...

> :)

That’s a mouth, not a paren :/ I won’t be able to sleep tonight :)) (that’s better

Many languages are designed with IDEs in mind and "dumb" text editors are not a concern.

Text editors need fairly complete parsers to match braces anyway. E.g. consider even something as simple as { "}" }. Or {"\"}. The former is reasonably unambiguous, but the latter requires knowing if the escape style of double quoted strings in the given language escapes the second '"' or not. Now try proc {"#{"}"}"} (valid Ruby) vs proc {"{\#{"}"}"} (invalid)

I have an even better idea:

  main(): int
    printf "hello"
    0

;)

Trouble with that is invoking main and declaring main are too similar. I prefer this:

    let main () =
      printf "hello"
      0

Why do we put spaces after punctuation in English?It's completely redundant.actually,why even put a capital letter at the beginning of a sentence?it can obviously be inferred.

OK, I'll stop now, but the point is: matching braces provide visual structure that's helpful to read code, even if it's syntactically redundant.

Prose is not a programming language, isn't it obvious?

One is designed for machines to parse unambiguously, the other has grown organically and chaotically over hundreds of years. Machine parsing has never been a design concern.

Indentation provides visual structure. Matching braces hardly add value to it.

You identified its purpose: symmetry.

Reminds me of TI-BASIC for the TI-83 graphing calculators... The closing ')' is optional at the end of a line, and omitting it could make your program slightly faster...

One step further would be to omit the second brace too. And we arrived at the Python design choice. I think only omitting the first brace is a middle ground most people find unappealing.

Hence Ruby or Oberon style of "end". Personally I have no intention of ever seriously using a language with significant indentation levels. It's not worth suffering the visual clutter.

Niklaus Wirth also removed the BEGIN keyword from control statements in Modula-2 and in Oberon.

Oberon:

  IF a < b THEN
     ...
  END

Pascal:

  IF a < b THEN
  BEGIN
     ...
  END