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.

Reply via email to