Researcher question – what's the point of semicolons and curly braces?

[Joe Duarte via Digitalmars-d]

On Tuesday, 3 May 2016 at 04:23:48 UTC, Walter Bright wrote:
> On 5/2/2016 8:48 PM, Joe Duarte wrote:
>> Why are curly braces and semicolons necessary? What 
>> information do they
>> carry that a compiler could not otherwise reliably obtain?
>
> You are correct in that they are (mostly) redundant. Some 
> ambiguities can arise because D is not a whitespace delimited 
> language. However, the real reasons are:
>
> 1. Redundancy in specification means the compiler can catch 
> more 'typo' mistakes rather than having them compile 
> successfully and then behave mysteriously. If a language has 0 
> redundancy, then any 8745b48%%&*&hjdsfh string would be a valid 
> program. Redundancy is a critical feature of high reliability 
> languages.
>
> Many languages have removed redundancy only to put it back in 
> after bitter experience. The classic is implicit declaration of 
> variables.
>
> 2. The redundancy also means the compiler can 'resync' itself 
> to the input once a syntactic error is detected.
>
> 3. It's instantly familiar to those who program already in 
> "curly brace" languages.

Your point about redundancy is interesting. I assume typos aren't 
random, and I wonder if anyone has researched the patterns there, 
which could inform where PL designers would want to insert 
guards/redundancy with syntax. I wonder if I could dig into this 
with GitHub and BitBucket repos. Maybe other researchers already 
have.

I'm also thinking that braces and semicolons might be satisfying 
to some (most?) programmers as an element of real or perceived 
rigor or safety, independent of the redundancy issue. For 
example, I'm a bit surprised by how popular SASS/SCSS is compared 
to Stylus (CSS preprocessors), given that SASS requires a lot of 
braces and semicolons while Stylus requires neither and has what 
I've been calling "clean" syntax. There could be feature 
differences I don't know about, but I wonder if people feel less 
safe with plain, unadorned text.

I remember that Rob Pike explained why Go requires braces by 
recounting how at Google their tools sometimes lost or damaged 
the indentation in Python source files, breaking those programs. 
I would think that you'd just fix your tools in that case. People 
build such amazing software these days that I'm surprised there'd 
be any issue in nailing down software that handles text files 
without messing up their whitespace or other syntactic structure. 
I don't know, maybe this is a recurring challenge. In any case, 
your redundancy point stands on its own.