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

[cym13 via Digitalmars-d]

On Wednesday, 4 May 2016 at 09:28:41 UTC, Chris wrote:
> On Wednesday, 4 May 2016 at 05:27:43 UTC, tsbockman wrote:
>> On Wednesday, 4 May 2016 at 05:19:35 UTC, Joe Duarte wrote:
>>> 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.

Meh. A programmer's inaptitude to control its text editor 
shouldn't be "fixed" at the language level. Mixing tabs and 
spaces is never a good idea no matter the language for what looks 
"ok" to you will not be so readable for another one using tabs of 
a different length. "Hey, easy, just put a project convention to 
use tabs of, say, 8 chars so that everybody uses the same!" Sure, 
but if you have to fix a length why not just use a fixed length 
character from the start. No, really this is a non-issue.

>> You're not going to even try to fix it until you realize it's 
>> broken, and you won't succeed until you figure out which 
>> line(s) got messed up.
>>
>> Without any redundancy in the syntax, minor corruption of the 
>> code could easily result in a program that still "works" - 
>> that is, compiles and runs without producing an error message 
>> - but whose behaviour has subtly changed. With redundant 
>> syntax, on the other hand, the compiler is more likely to 
>> detect and pinpoint the problem immediately.
>
> I agree. A very common annoyance in Python is the rule that you 
> have to use either tabs or spaces. This is a major annoyance 
> when you open a Python file in a text editor that inserts tabs 
> or spaces automatically. This has happened on countless 
> occasions and it's a trivial issue that detracts your attention 
> from writing code. In Python you spend a lot of time just 
> formatting code instead of writing it. Thus, you're not really 
> more efficient in Python. Now, you might say that a good tool 
> should fix this, but a) fixing things with a tool takes time as 
> well, b) tools might not always be able to tell what your 
> intention was [1], and c) if you need a lot of tools to write 
> even simple code, there's something wrong with the language's 
> design.
>
> As has been said before, Python is not meant to do what D does. 
> Python's rigid syntax rules are purely pedagogical, to avoid 
> that non-programmers make a mess of the source code (as would 
> happen with Perl). Someone who uses D is usually enough into 
> programming (or willing enough to learn it) to be able to deal 
> with curly braces and semicolons. Although not obvious from 
> looking at Python one or two liners, braces and semicolons are 
> valuable features (or tools) whose usefulness only comes 
> apparent once you dig deeper and get into more complicated 
> stuff. Python is a different beast and for Python it's fine to 
> have no curly braces and semicolons. However, the problem is 
> that Python became bigger and bigger and left it's cosy realm 
> of scripting in labs, was used for bigger projects and actually 
> became quite popular. People inferred from this that PLs don't 
> need curly braces and semicolons. Yet Rob Pike's decision to 
> use curly braces in Go is a good example of the hidden dangers 
> of an overly simplistic syntax. It didn't scale.
>
> [1] Consider the following code, which will work correctly:
>
> x = 5
>
> if x < 6:
>   print "Checking value"
>   print "%d is less than 6" % x
>
> Now look at this:
>
> x = 10
>
> if x < 6:
>   print "Checking value"
> print "%d is less than 6" % x  # <--- wrong indentation level
>
> This will incorrectly print "10 is less than 6". Which gives 
> causes two problems
>
> 1. no compiler or editing tool can see what your intention was
> 2. the program works, albeit, incorrectly. In bigger programs, 
> it can take a while to find out why the program is behaving 
> incorrectly, because up to 5 it always works fine, and if 6-10 
> is less common, it can take a while until you even notice the 
> bug.
>
> In D (or C) it doesn't matter:
>
> if (x < 6)
> {
>   writeln("Checking value");
> writefln("%d is less than 6", x);
> }

There again I completely disagree with you. The intent in the 
first braceless sniplet is clearly to have both statements ruled 
by the condition. Eyes look at indentation before anything else 
as prove bugs like goto-fail. Ignoring that intent by allowing 
code to lie with their indentation level like C or D does is more 
of a mistake IMHO.

if (x < 6)
     writeln("Checking value");
     writeln("%d is less than 6", x);

should be at the very least a warning, at best an error.