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.