[zozbot234]

Historically, the point of writing 'begin' and 'end' instead of using curly braces was mostly support for non-ASCII character sets where the curly braces are not included. It's why C also has an alternate syntax using <% and %> and COBOL goes as far as writing out arithmetical operators as English text, such as DIVIDE x INTO y GIVING z.

[dwheeler]

Ada, at least, uses begin...end in part because it prevents certain kinds of errors. In its syntax you have to specify what you are ending, reducing the risk of invalid matches and increasing the likelihood of the error report system guessing correctly what you intended. E.g.:

    if X > 0 then
      Y := 0;
    end if;

Curly braces are shorter, but a close curly brace will match any open curly brace. Such is the nature of trade-offs.

[Sakos]

Ngl, I think that's brilliant. Braces matching the wrong brace is like a daily occurrence. It's such a tedious small thing that constantly hounds me whenever I'm writing code

[trealira]

In languages without this feature (most of them), you sometimes see long blocks get labeled at the end anyway. On the other hand, you could argue that if your block is long enough it doesn't fit on the screen, then it should be its own function anyway.

Like this, except replace "..." with many lines of code.

  if (z.p == z.p.p.left) {

      ...

  } else { // z.p != z.p.p.left

      ...

  } // if

[dwheeler]

> In languages without this feature (most of them), you sometimes see long blocks get labeled at the end anyway.

True. However, in Ada at least, if the block types don't match then it's a syntax error detected at compile time by the compiler. Comments like those listed above are often not checked at compile time, and thus aren't very useful for preventing errors.

[zozbot234]

Most programming languages now support reformatters out of the box. Part of the point of those is to make mismatched closing braces more visible.

[suby]

Rainbow brackets, so the brackets themselves are color coded to match with their corresponding partner, are also a godsend.

[usrusr]

I'm surprised that code folding has never really become good/popular enough to make all these things non-issues.

Often it's only for named blocks like functions, and not for the really unhelpful bits like that conditional branch that is long, simple and deep, but really does not deserve spamming a namespace with an unhelpful identifier. And I've yet to see a deliberately short-lived folding to lessen the out of sight, out of mind tax that code folding of associated with. If there was deliberately short-lived folding, perhaps auto-reexpanding whenever the section has scrolled out of view, I'd use folding all the time, to navigate the nesting. The quasi-permanent until explicitly re-expanded cold folding? Yeah, I hardly ever use it, to many bad experiences with forgetting to re-expand.

[bombcar]

Code folding is phenomenal for understanding a codebase and I'm really surprised it wasn't utilized more.

[Sakos]

Even with all these helpers, there's too much cognitive overhead and not enough that IDEs or plugins can do to take that away. Rainbow braces are nice and all, but it's not enough when the underlying concept is broken.

[kaba0]

Scala 3 actually has a brace-less mode that supports this.

[wwweston]

You can do this with PHP, too, but it’s on the rare side except in some templating niches.

The reverse-reserved-word convention like ‘fi’ to end an if block in shell (and other?) languages seems like it functions this way too.

And I guess significant indentation also does this job, albeit with some of its own hazards.

[KerrAvon]

I was under the impression that COBOL's English syntax was intended to be a more human-readable approach, not so much a workaround for character set limitations.

[pavlov]

Maybe both? COBOL predates the first draft of ASCII by several years. Character sets were far from standardized in those days.

[noizejoy]

Lots (most?) of classic COBOL used EBCDIC[0]

[0] https://en.wikipedia.org/wiki/EBCDIC