Hi all,

I'm a social scientist and I'm preparing some studies on the effects of programming language syntax on learning, motivation to pursue programming, as well as any disproportionate effects that PL syntax has on the appeal of programming to women (more on the latter in a separate post).

So I want to get a better idea of the rationale for various syntactical design decisions, and I'm going to ask you the same question I'll ask the Rust community:

Why are curly braces and semicolons necessary? What information do they carry that a compiler could not otherwise reliably obtain?

Here's an example from the D Overview page:


class Foo
{
    int foo(Bar c) { return c.bar; }
}

class Bar
{
    int bar() { return 3; }
}


Okay, if we remove the curly braces and semicolons, we have:


class Foo

    int foo(Bar c) return c.bar


class Bar

    int bar() return 3


Would it be difficult to compile the clean version? Would there be issues with the design of the lexer/parser? I assume the compiler would recognize keywords like return (and a clean syntax could drive different rules for what statements and expressions could appear on the same line and so forth).

In reality, a compiler would see the above with line ending characters terminating every line (e.g. U+000A), so it would be as line-aware as a human. I've never built lexers or parsers, much less compilers, so maybe I'm missing a major implementation hurdle. I'm just thinking that Facebook has built software that recognizes my face in other people's pictures, so it seems like building software that understands structured text would be a solved problem. It puzzles me to see so much apparent punctuation noise in a 21st-century language (and, to be fair, Rust puzzles me for the same reasons).

JD

On 03/05/2016 3:48 PM, Joe Duarte wrote:
> Hi all,
>
> I'm a social scientist and I'm preparing some studies on the effects of
> programming language syntax on learning, motivation to pursue
> programming, as well as any disproportionate effects that PL syntax has
> on the appeal of programming to women (more on the latter in a separate
> post).
>
> So I want to get a better idea of the rationale for various syntactical
> design decisions, and I'm going to ask you the same question I'll ask
> the Rust community:
>
> Why are curly braces and semicolons necessary? What information do they
> carry that a compiler could not otherwise reliably obtain?
>
> Here's an example from the D Overview page:
>
>
> class Foo
> {
>     int foo(Bar c) { return c.bar; }
> }
>
> class Bar
> {
>     int bar() { return 3; }
> }
>
>
> Okay, if we remove the curly braces and semicolons, we have:
>
>
> class Foo
>
>     int foo(Bar c) return c.bar
>
>
> class Bar
>
>     int bar() return 3
>
>
> Would it be difficult to compile the clean version? Would there be
> issues with the design of the lexer/parser? I assume the compiler would
> recognize keywords like return (and a clean syntax could drive different
> rules for what statements and expressions could appear on the same line
> and so forth).
>
> In reality, a compiler would see the above with line ending characters
> terminating every line (e.g. U+000A), so it would be as line-aware as a
> human. I've never built lexers or parsers, much less compilers, so maybe
> I'm missing a major implementation hurdle. I'm just thinking that
> Facebook has built software that recognizes my face in other people's
> pictures, so it seems like building software that understands structured
> text would be a solved problem. It puzzles me to see so much apparent
> punctuation noise in a 21st-century language (and, to be fair, Rust
> puzzles me for the same reasons).
>
> JD

One of the benefits of having semicolons and braces is that you can have your entire source file on one line!
But ok in all seriousness as shown by Lua its not really required.
Its a stylistic choice at least for me it is.

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.

On Tuesday, 3 May 2016 at 03:48:09 UTC, Joe Duarte wrote:
> Would it be difficult to compile the clean version?

You realize your bias is showing very strongly in the wording of this question, right? I don't agree the naked version is clean at all.

ohimsorryletswritemorecleanlywithoutanyofthatobnoxiouspunctuationnoiseitisalluselessanywaysurelyyoucanstillmakesenseofthisafterallthereareonlysomanywordsintheenglishlanguageandknowinghwatdoesanddoesntmakesenseincontextmeansyoucansurelyparsethisrightout

oh i know you will say thats not a fair comparison it is the punctuation you dislike not the spacing though really the same principle applies actually while the punctuation does have meaning ill concede you can nevertheless parse it without although you might then want other rules

see in a lot of those languages they redefine things like lines to serve the same role as the punctuation

so like instead of ending expressions in punctuation

they end them with a new line instead

meaning you must hit enter at the point that d would allow you to use the semicolon

ditto for indentation

like sure this is readable

but it just bothers me to use as a matter of course

it can even become

~hideous~

crap i cant even use ~ wtf this style of writing sucks it just isnt very expressive nor artistic

* * *

Personally, I sometimes do like writing in all lower case without punctuation, but I do so as a style choice; it tends to be my way of expressing in text that I'm not being entirely serious, in contrast to ordinarily formatted text.

Code is the same thing - I will use different styles for different situations.

It isn't a terribly difficult technical problem to define a programming language to have a different syntax. You can parse them without that much trouble.

But the syntax isn't really there for the compiler's benefit (though there are benefits there, just like asking the user to confirm their email address, getting a bit of redundant information out of the human user can help catch mistakes), it is there for the reader.

I often get lost when there's several levels of whitespace change at once.

def pain:
  if whatever:
    do this
    if this_too:
      also do this
      if one_more:
        oh snap this is kinda long
        it takes several lines
        oh snap this is kinda long
        it takes several lines
        oh snap this is kinda long
        it takes several lines
        oh snap this is kinda long
        it takes several lines
        oh snap this is kinda long
        it takes several lines
        oh snap this is kinda long
        it takes several lines
        oh snap this is kinda long
        it takes several lines
        oh snap this is kinda long
        it takes several lines
        oh snap this is kinda long
        it takes several lines
        oh snap this is kinda long
        it takes several lines
        oh snap this is kinda long
        it takes several lines
        oh snap this is kinda long
        it takes several lines
    quick where we at?



Curly braces in there would show we intended to go a couple levels and give a convenient place to click to ask our editor program to show us where it started too. I really like having that.


Semicolons similarly are a nice way to say "I'm done with this thought", which I'm just used to hitting. When I use languages that don't allow them, I waste quite a bit of time hitting backspace after automatically hitting ;!

Moreover, with a longer line, (or in some cases like debug lines where I want to easily remove two statements with one keypress - yes, my editor can delete a line instantly, but two lines are a bit harder to do) the semicolon gives you the freedom to format it as you will.


a = 5 +
    4 -
    1;

That'd work without the semicolon (usually), but this is different:

a =   5
    + 4
    - 1;


In that case, the line break after the 5 would probably end the statement, leaving the other numbers dangling.

I prefer this formatting in many cases though since then the operators nicely line up. In the first one, the 4 is visually tied to the -, but really, the - is more strongly related to the 1, so I want them grouped together.


Well, I'm late, but to sum up:

* familiarity brings comfort, to look and in using existing workflows like my editor's delete-line feature.

* breaking habits, regardless of whether those habits are perfect in a perfect world, is a source of mental friction that has higher cost than benefit

* punctuation separate from styling leaves both as independent decisions that brings more beauty

It isn't so much that they are necessary, it is that they bring various other benefits.


> I'm a social scientist and I'm preparing some studies on
> the effects of programming language syntax on learning,
> motivation to pursue programming, as well as any disproportionate effects that PL syntax has on the appeal
> of programming to women (more on the latter in a separate
> post).

fascinating, I might tell you some stories from my youth later, but right now, I'm too old to be up this late!

But I'm really curious what the gendered aspect turns out as. I suspect the effect, if it indeed exists, would be strongly tied to the oft-repeated lie that "girls aren't good at math" - math famously uses a lot of symbols, so that association could recall discouraging memories.

On Tuesday, 3 May 2016 at 04:24:37 UTC, Adam D. Ruppe wrote:
> On Tuesday, 3 May 2016 at 03:48:09 UTC, Joe Duarte wrote:
>> [...]
>
> You realize your bias is showing very strongly in the wording of this question, right? I don't agree the naked version is clean at all.
>
> [...]


Praise this

On Mon, 02 May 2016 21:23:48 -0700
Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com> 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.

That redundancy also can make it much easier for the programmer to figure out what's going on. And it better expresses the intent of the code when you have some of those redundancies. Without them, it can be a lot less obvious when something was intentional or a mistake (e.g. how far a particular line was supposed to be indented).

I know that there are plenty of folks who start out programming with a scripting language of some sort and don't like it when they have to deal with braces and/or terminating semicolons, but I think that it's a lot like static typing vs dynamic typing. At first, it might _seem_ more liberating to have dynamic typing, but the number of errors that creep in with dynamic typing is much higher than with static typing, because the compiler simply isn't set up to catch many problems for you with a dynamic language, where it is with a static one.

I think that it's clear that languages like python have shown that it's possible to have a successful language with no curly braces or semicolons and puncuation-like syntax overall, but I don't think that it's been shown that it's necessarily a _good_ idea - just that it can work. It's not that hard to find rants online from folks who used to love python's use of whitespace as a delimiter only to have big enough problems with it in a serious program that they now hate it with a passion.

- Jonathan M Davis

On Tuesday, 3 May 2016 at 04:23:48 UTC, Walter Bright wrote:
> 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.

An example of this would be that Apple SSL bug that has largely been blamed on optional curly braces for if statements with one line in the body.

On Tuesday, 3 May 2016 at 04:24:37 UTC, Adam D. Ruppe wrote:
> But I'm really curious what the gendered aspect turns out as. I suspect the effect, if it indeed exists, would be strongly tied to the oft-repeated lie that "girls aren't good at math" - math famously uses a lot of symbols, so that association could recall discouraging memories.

"Obligatory" xkcd link: https://xkcd.com/385/

On Tuesday, 3 May 2016 at 03:48:09 UTC, Joe Duarte wrote:
> Hi all,
>
> I'm a social scientist and I'm preparing some studies on the effects of programming language syntax on learning, motivation to pursue programming, as well as any disproportionate effects that PL syntax has on the appeal of programming to women (more on the latter in a separate post).
>
> So I want to get a better idea of the rationale for various syntactical design decisions, and I'm going to ask you the same question I'll ask the Rust community:
>
> Why are curly braces and semicolons necessary? What information do they carry that a compiler could not otherwise reliably obtain?
>
> Would it be difficult to compile the clean version? Would there be issues with the design of the lexer/parser? I assume the compiler would recognize keywords like return (and a clean syntax could drive different rules for what statements and expressions could appear on the same line and so forth).
>
> In reality, a compiler would see the above with line ending characters terminating every line (e.g. U+000A), so it would be as line-aware as a human. I've never built lexers or parsers, much less compilers, so maybe I'm missing a major implementation hurdle. I'm just thinking that Facebook has built software that recognizes my face in other people's pictures, so it seems like building software that understands structured text would be a solved problem. It puzzles me to see so much apparent punctuation noise in a 21st-century language (and, to be fair, Rust puzzles me for the same reasons).

The parser needs information about "blocks". Here is an example:

  if (x)
    foo();
    bar();

Is bar() always executed or only if (x) is true? In other words, is bar() part of the block, which is only entered conditionally?

There are three methods to communicate blocks to the compiler: curly braces, significant whitespace (Python, Haskell), or an "end" keyword (Ruby, Pascal). Which one you prefer is subjective.

You mention Facebook and face recognition. I have not seen anyone try machine learning for parsing. It would probably be a fun project, but not a practical one.

You wonder that understanding structured text should be a solved problem. It is. You need to use a formal language, which programming languages are. English for example is much less structured. There easily are ambiguities. For example:

  I saw a man on a hill with a telescope.

Who has the telescope? You or the man you saw? Who is on the hill?

As a programmer, I do not want to write ambiguous programs. We produce more than enough bugs without ambiguity.

On Tuesday, 3 May 2016 at 03:48:09 UTC, Joe Duarte wrote:
> Why are curly braces and semicolons necessary? What information do they carry that a compiler could not otherwise reliably obtain?

Something that hasn't been mentioned so far:

Generating source code is easier with braces. String mixins would be more complicated with significant indentation.