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.

Reply via email to