On Wednesday, 30 April 2014 at 08:52:48 UTC, Chris wrote:
> Say you have a Python file with 500 lines of code. Try to copy and paste something with a different indentation from somewhere else into an if statement.

Paste in non-formatting-mode and use the editor's ability to block indent? Having an editor that will indent/unindent regions when you hit tab/shift-tab helps.

> This kind of patronizing bullshit was invented for non-programmers who might make a mess of the code otherwise.

It is true that Python grew out of a programming language tradition meant for teaching/prototyping.

But the Python syntax it is more useful for an interpreter prompt (REPL) than a syntax with explicit begin/end markers. Most of the non-trivial transformations I do start at the REPL before being pasted into the editor.

> In D you can do this:
>
> if (mode == "TEST") {  // Second block added later
> if (x == 1) {  // First block
>  writeln("Hurray!");
> }
> }

I think Go did the right thing by not requiring the redundant parantheses on the if statement and perhaps also by allowing the omission of semicolons where appropriate etc. Room for improved legibility right there.

In Python I would probably use «TEST» rather than «mode=="test"»:

if TEST&& x == 1:
    …

Ola.

On Wednesday, 30 April 2014 at 10:16:12 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 30 April 2014 at 08:52:48 UTC, Chris wrote:
>> Say you have a Python file with 500 lines of code. Try to copy and paste something with a different indentation from somewhere else into an if statement.
>
> Paste in non-formatting-mode and use the editor's ability to block indent? Having an editor that will indent/unindent regions when you hit tab/shift-tab helps.

Yes it helps, but a language's syntax / usability should not depend on tools like editors. Also, what if I want to use an editor that doesn't support all the fancy formatting stuff?

>> This kind of patronizing bullshit was invented for non-programmers who might make a mess of the code otherwise.
>
> It is true that Python grew out of a programming language tradition meant for teaching/prototyping.
>
> But the Python syntax it is more useful for an interpreter prompt (REPL) than a syntax with explicit begin/end markers. Most of the non-trivial transformations I do start at the REPL before being pasted into the editor.
>
>> In D you can do this:
>>
>> if (mode == "TEST") {  // Second block added later
>> if (x == 1) {  // First block
>> writeln("Hurray!");
>> }
>> }
>
> I think Go did the right thing by not requiring the redundant parantheses on the if statement and perhaps also by allowing the omission of semicolons where appropriate etc. Room for improved legibility right there.
>
> In Python I would probably use «TEST» rather than «mode=="test"»:
>
> if TEST&& x == 1:

By this you change the substance of the if statement merely for test purposes, i.e.

if x == 1: > if TEST && x == 1:

which is not very elegant, and it's error prone (what if you overlook the TEST && bit for release?)

In my D example you leave the essential part untouched. On top of that, the fact that to if statements are at the same indentation level makes it easier to spot that there is something unusual going on there.

On Tuesday, 29 April 2014 at 17:05:50 UTC, Brian Rogoff wrote:
> You must be perpetually perplexed then, because Haskell, Clean, F#, Nimrod and many other languages also use whiitespace to signify indentation.

I suppose I haven't found the whitespace in Haskell and F# so bothersome because the static type systems catch most of the mistakes at compile time that would occur in Python. Haskell also allows optional braces instead of whitespace (whitespace is just syntactic sugar for braces), which can be quite useful at times, especially when copying code.

On 4/30/2014 6:16 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
> On Wednesday, 30 April 2014 at 08:52:48 UTC, Chris wrote:
>> In D you can do this:
>>
>> if (mode == "TEST") {  // Second block added later
>> if (x == 1) {  // First block
>>  writeln("Hurray!");
>> }
>> }

Yea, I do that all the time for debugging...*deliberately* since it makes it trivial to spot the temporary testing code. A language shouldn't get in my way just because it made a false assumption about my workflow.

>
> I think Go did the right thing by not requiring the redundant
> parantheses on the if statement and perhaps also by allowing the
> omission of semicolons where appropriate etc. Room for improved
> legibility right there.
>

Personally, I find Go's reduced parens and such to make it noticeably harder to read. There's less for my eyes to lock onto when visually parsing/scanning. YMMV of course.

On Wednesday, 30 April 2014 at 11:46:32 UTC, Nick Sabalausky wrote:
> On 4/30/2014 6:16 AM, "Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang@gmail.com>" wrote:
>> On Wednesday, 30 April 2014 at 08:52:48 UTC, Chris wrote:
>>> In D you can do this:
>>>
>>> if (mode == "TEST") {  // Second block added later
>>> if (x == 1) {  // First block
>>> writeln("Hurray!");
>>> }
>>> }
>
> Yea, I do that all the time for debugging...*deliberately* since it makes it trivial to spot the temporary testing code. A language shouldn't get in my way just because it made a false assumption about my workflow.

Yep. Good to know I'm not the only one who does this all the time :-)

>>
>> I think Go did the right thing by not requiring the redundant
>> parantheses on the if statement and perhaps also by allowing the
>> omission of semicolons where appropriate etc. Room for improved
>> legibility right there.
>>
>
> Personally, I find Go's reduced parens and such to make it noticeably harder to read. There's less for my eyes to lock onto when visually parsing/scanning. YMMV of course.

On Tuesday, 29 April 2014 at 14:59:25 UTC, logicchains wrote:
> An argument for zero-based indexing from Dijkstra: https://www.cs.utexas.edu/users/EWD/transcriptions/EWD08xx/EWD831.html

Well, indeed, it's impossible to select an empty subrange with convention c (pascal?). Is it a problem? Simply use null instead of an empty range.

On Wednesday, 30 April 2014 at 10:56:22 UTC, Chris wrote:
> which is not very elegant, and it's error prone (what if you overlook the TEST && bit for release?)

I'd probably tie it to DEBUG and make sure it has the correct value whenever DEBUG is false. No need to remove it before release.

Ola.

On Wednesday, 30 April 2014 at 14:57:44 UTC, Ola Fosheim Grøstad wrote:
> On Wednesday, 30 April 2014 at 10:56:22 UTC, Chris wrote:
>> which is not very elegant, and it's error prone (what if you overlook the TEST && bit for release?)
>
> I'd probably tie it to DEBUG and make sure it has the correct value whenever DEBUG is false. No need to remove it before release.
>
> Ola.

I think it is not feasible to tie everything to DEBUG. Debug is a signpost that marks well-defined "problem zones". Often I need just a little writefln() statement somewhere in the code to see what is going on / wrong in a certain block. The simplest example is to insert writeln() simply to see up to which point it prints before the app crashes. Believe it or not, I find this technique very efficient in certain situations.
Python often gets in my way when micro-debugging in this way, because of indentation terror.

On Wednesday, 30 April 2014 at 11:41:29 UTC, logicchains wrote:
> On Tuesday, 29 April 2014 at 17:05:50 UTC, Brian Rogoff wrote:
>> You must be perpetually perplexed then, because Haskell, Clean, F#, Nimrod and many other languages also use whiitespace to signify indentation.
>
> I suppose I haven't found the whitespace in Haskell and F# so bothersome because the static type systems catch most of the mistakes at compile time that would occur in Python. Haskell also allows optional braces instead of whitespace (whitespace is just syntactic sugar for braces), which can be quite useful at times, especially when copying code.

Right, it's not the significant indentation which perplexes you, but the complete lack of compile time checking from Python. I'm perplexed that anyone could prefer that too, but I suppose those programmers who are way smarter than me and don't make any mistakes find types burdensome, or are always writing correct code that can't be type checked by any current checker.

On 4/30/2014 11:59 AM, Chris wrote:
>
> The simplest example is to insert
> writeln() simply to see up to which point it prints before the app
> crashes. Believe it or not, I find this technique very efficient in
> certain situations.

I do that all the time. :)

> Python often gets in my way when micro-debugging in this way, because of
> indentation terror.