Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bart <bc@freeuk.com>
Newsgroups: comp.lang.misc
Subject: Re: Python (was Re: I did not inhale)
Date: Fri, 30 Aug 2024 00:49:25 +0100
Organization: A noiseless patient Spider
Lines: 199
Message-ID: <var1e5$6186$1@dont-email.me>
References: <uu54la$3su5b$6@dont-email.me> <v9m4gd$14scu$1@dont-email.me>
 <20240815182717.189@kylheku.com> <v9npls$1fjus$1@dont-email.me>
 <v9t204$2dofg$1@dont-email.me> <va28pi$3dldm$1@dont-email.me>
 <va2ro9$3gd7v$1@dont-email.me> <va2vt0$3h3gj$1@dont-email.me>
 <va44rh$3p1l6$1@dont-email.me> <va45eq$3pkt9$1@dont-email.me>
 <va4aut$3q4g0$1@dont-email.me> <va4fbr$3qvij$1@dont-email.me>
 <va5108$3tmmd$1@dont-email.me> <va51ok$3tqr9$1@dont-email.me>
 <va5ec2$3vluh$1@dont-email.me> <va6q4g$c1a7$1@dont-email.me>
 <va6rpa$c6bg$1@dont-email.me> <va6se9$cb8e$1@dont-email.me>
 <20240826083330.00004760@gmail.com> <vaises$2k7o6$2@dont-email.me>
 <20240826155113.000005ba@gmail.com> <wwvo75eicla.fsf@LkoBDZeT.terraraq.uk>
 <vak9k9$2ujrs$1@dont-email.me> <valgpu$34s18$1@dont-email.me>
 <vannkg$3ig72$1@dont-email.me> <vanrd8$3j0vv$1@dont-email.me>
 <vantnp$3j94i$1@dont-email.me> <vapp91$3v4l8$3@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 30 Aug 2024 01:49:26 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="174259085da7cb67cacc3eba8e8469e6";
	logging-data="197894"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/9iiL3njT1Mwv0zD2+XlJN"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:5/PBbWkTAerzFyQtp1Ydi8erwCg=
In-Reply-To: <vapp91$3v4l8$3@dont-email.me>
Content-Language: en-GB
Bytes: 9334

On 29/08/2024 13:24, David Brown wrote:
> On 28/08/2024 21:27, Bart wrote:
>> On 28/08/2024 19:48, David Brown wrote:
>>> On 28/08/2024 19:43, Muttley@dastardlyhq.com wrote:
>>>> On Tue, 27 Aug 2024 21:34:54 -0000 (UTC)
>>>> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>>>> On Tue, 27 Aug 2024 11:26:18 +0100, Bart wrote:
>>>>>
>>>>>> (2) You want to temporarily comment out an 'if' line so that the
>>>>>> following block is unconditional. You can't do that with also
>>>>>> unindenting the block.
>>>>>
>>>>> In Emacs, I have commands defined to adjust the indentation of the
>>>>> selected region. Surely any other decent editor would offer the same.
>>>>
>>>> Writing editor editor macros in order to work around fundamentally bad
>>>> language design is not something a programmer should have to waste 
>>>> time on.
>>>>
>>>>
>>>
>>> I don't know about Emacs, but in most editors the way you indent a 
>>> block of code is to select the lines, then press "Tab".  Unindenting 
>>> is "shift-Tab".  Changing tabs to spaces or spaces to tabs is done by 
>>> selecting "Tabs to spaces" from the Edit menu, or something equally 
>>> simple and obvious.  Many editor can be set to convert tabs to spaces 
>>> (or vice versa) when saving files, perhaps specific to the file type 
>>> (so you don't muck up your makefiles).
>>>
>>> It takes a special kind of genius to be able to program, and yet 
>>> still have trouble with this kind of thing.
>>
>> The main problem isn't in changing the indentation of a block of code; 
>> it is in HAVING to do so because of poor language design.
> 
> If I am adding or removing blocks (such as surrounding existing code in 
> a new conditional), then I /have/ to change the indentation - in /any/ 
> language.  (I use indents in my assembly programming too.)  Call it OCD 
> or compulsive behaviour if you like, but I cannot consider code to be 
> finished - even to the level of a quick compile or test - if the 
> indentation is not correct.
> 
> I simply cannot see the problem with Python here, because I would not 
> indent things in any other way in any language.
> 
> The only thing I see as annoying in Python is when you have two or three 
> indentations left hanging :
> 
> def foo(a, b, c) :
>      if a :
>          if b :
>              if c :
>                  doThis()

Let's assume you know this ends here (as there is no concrete bit of 
syntax that will confirm it).

You need to add another statement to that 'if b' block. Even with just 
two intervening lines, you need to take some care. With more, you either 
have to work your way down from 'if b' then move right one tab, or start 
from the first statement ('if c') and work down from that. At the same 
keep an eye out for cues as to the end of the 'if b' block.

It should look like this afterwards:

  def foo(a, b, c) :
       if a :
           if b :
               if c :
                   doThis()
               bnewstmt

That new statement looks rather lonely and exposed though! Do the same 
with 'if a', and it becomes:


  def foo(a, b, c) :
       if a :
           if b :
               if c :
                   doThis()
               bnewstmt

# comment
# comment
           anewstmt


> That looks unfinished to me.

It's just too 'open'. The contents of foo look like they're leaking into 
the rest of the program. As it is, someone looking at this in the future 
wanting to a a new statement to 'if a:' might think it ends before the 
comments since that 'anewstmt' is too far from the main body.

It needs delimiters:


  def foo(a, b, c) :
       if a :
           if b :
               if c :
                   doThis()
               end
               bnewstmt
            end

# comment
# comment
           anewstmt
       end
  end

Now you know that 'if a' doesn't end at that blank line, because no 
'end' has been seen for it.

> So I will add a "return" at the end (with 
> a single tab indent, in this case).  If it is not the end of the 
> function, I will sometimes use a "pass" to pull back the indent level.

So you have problems too. Would you have needed 'return' if 'end's had 
been used in the original?

> Of course, being a sane software developer, I do most of my programming 
> using editors that are suitable for software development.  Most 
> professional carpenters use hammers for their nails, rather than bashing 
> them in with stones - it's the same thing, really.
> 
>>
>> And yet another, of more significance, if that after you've indented a 
>> block, it may now merge into an adjacent block that was already at 
>> that new indent. If you later need to revert that first block back to 
>> it's original position, you'd better make sure you mark that boundary.
>>
> 
> So mark the boundary.  Add a blank line.  Put a comment line describing 
> the steps of the function.  You are making up problems for which you 
> already have good solutions that you would be using in any programming 
> language.

How about just fixing the ******* language? That must be better than a 
million programmers wasting time creating their own fixes.

> Having made your own language(s) gives you no more and no less right to 
> comment about features of other languages that you like or dislike.


I had my opinions even before I used my own stuff.

One thing I despised was the begin-end business in Algol60 and Pascal, 
which has the same nuisance as braces in C-like languages.

I didn't like writing 'end else begin' any more than '} else {'. My 
stuff (and a few languages have picked up on it), uses just 'else', 
which also limits the placement possibilities when you have one token 
rather than three.


> Your problem here is that you are obsessed with finding things that you 
> want to see as misfeatures, design flaws, or problems in other languages 

Yes. I'm into language design. But I'm also interested in aspects of it 
that many disregard, such as microfeatures, or ease of deployment.

> - and then obsess about how you can find new ways to make it more 
> difficult to "work around" them.
========== REMAINDER OF ARTICLE TRUNCATED ==========