On: A taste of Rust

[alcuadrado]

Python indentantion-as-block definition has many drawbacks, not to mention the lack of semicolons that forces \

you \

to \

write \

so \

many \

backslashes.

They are not the ultimate solution for block definition and line breaking. You must be very used to them, and that's why you find the lack of it irritating, but that's another story.

Disclaimer: I code python every day of my life nowadays, I'm not a python hater.

[jboy → alcuadrado]

I type many, many more semicolons in C or C++ than I type line-continuation backslashes in Python, so I prefer the option that requires fewer keypresses and less syntactic noise.

Or to put it another way, I'd much rather have to syntactically announce a line-continuation (which happens rarely, and is thus an atypical event that is worthy of note) than announce the end of a statement (which happens every single statement, and is thus to me much less worthy of note).

My reasons for preferring indentation-as-block over brace block-delimiters are similar: The indentation is a much more subtle, unobtrusive, un-noisy alternative to braces.

Furthermore, when I code in C or C++, I indent (and brace-delimit) everything properly, according to a style guide; so if I'd be indenting the block anyway, why not make the indentation syntactically meaningful, to save me some keypresses and slightly decrease the syntactic noise?

Plus, for bonus points, brace-less blocks mean I never need to play the brace-matching game. ("Have I got an extra/missing brace in there somewhere? Put the cursor on the brace and tap `%` until I work out what's out of place." True, it doesn't happen frequently if you keep your blocks and functions small, but I'm quite happy to avoid it altogether.)

[jerf → alcuadrado]

I've written a lot of Python too. When I need to span lines, usually there's an easy way to use parens to do

    blahblah = long().invocation_of.something(with,
                   lots, of, parameters)

which is generally more idiomatic. (Of course one wishes to avoid long lines at all but that's not always possible.)

[alcuadrado → jerf]

I found that parnes rule used as an awful hack a lot of times. I use it only when the parens are naturally placed, but there are people that just add two parens to avoid one backslash... completely insane!

[kzrdude → alcuadrado]

How is the backslash better? The parantheses can stay if you join two lines or split them.

[loqi → kzrdude]

Yup, and parens also allow comments.

[atombender → alcuadrado]

I prefer Ruby's approach, which is not whitespace-sensitive, but has a very liberal approach to where expressions end.

The general rule is, as with Python and Go, that open braces, brackets, parens or quotes have precedence; and operators or punctuation at the end of a line will continue to the next line.

In addition, there are some complicated parsing internals -- not just for expression-ending sensing, but also for supporting parens-less method calls -- that endow the parser with some compiler knowledge about what tokens are variables and what tokens are methods. In other words, the parser has information that violates the parser/compiler separation of concerns, but it works really well in practice.

The only time I ever use \ in Ruby is for string literals that need to be broken up for readability:

    my_string = "This is a very long string that" \
      " must be wrapped."

You can use + or <<, but this will be evaluated at runtime, whereas \ results in a single string allocation.

Of course, Ruby requires "end" for a lot of constructs, but it could have just as well have used braces.

[gnaritas → atombender]

Ruby can use braces instead of end, both are valid.

[atombender → gnaritas]

Hm? Only for blocks. Not classes, methods, if/unless, while or begin/rescue.

[gnaritas → atombender]

Dang, you're right, I could swear otherwise but yup, just on blocks.

[rdtsc → alcuadrado]

if you put a backslash on every line in Python, check your code, variable names. I rely more on splitting on tuples or dictionary items. So you can actually write like this:

    (forces,
     you,
     to,
      ...
     )