How coding in Python is bad for you

[Steven D'Aprano]

On Tuesday 24 January 2017 13:38, Chris Angelico wrote:

> On Tue, Jan 24, 2017 at 12:47 PM, BartC <bc at freeuk.com> wrote:

>> Take the same code with block
>> delimiters, and take out that same indent:
>>
>> if 0 then
>>     print ("one")
>> print ("two")
>> endif
>> print ("three")
>>
>> It still compiles, it still runs, and still shows the correct "three" as
>> output.
> 
> My point is that you *assume* that showing just "three" is the correct
> behaviour. Why? Why do you automatically assume that the indentation
> is wrong and the endif is correct? All you have is that the two
> disagree.

It's Bart's special language, so the correct behaviour is whatever he says it 
is :-)

But more seriously, it's easy to typo an extra indent. It's harder to typo 
"endif" when you actually meant to type, oh, "ending = 1 if condition else 3", 
say. So faced with ambiguity, and the insistence that the right way to break 
ambiguity is to guess ("Do What I Mean, dammit!!!") the most likely guess is 
that the indentation is wrong.

But not guaranteed. That's the thing about being ambiguous -- there is a chance 
that the indentation is correct.

This *especially* applies to languages like C, when open/close delimiters 
optional if the block is only a single statement, and where the delimiters are 
only a single character.

And sure enough, C is prone to indent/brace mismatch errors.

When I design my killer language, it won't fail when there's a mismatch between 
indentation and open/close delimiters. Nor will it just give priority to one or 
the other. Instead, it will learn from your errors and typos in order to 
determine which you are statistically more likely to want, and silently compile 
the code that way. But without changing the source code, of course.



-- 
Steven
"Ever since I learned about confirmation bias, I've been seeing 
it everywhere." - Jon Ronson