Path: ...!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 15:55:36 +0100
Organization: A noiseless patient Spider
Lines: 249
Message-ID: <vasmh7$hmds$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>
 <var1e5$6186$1@dont-email.me> <vasfms$gcgq$1@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 16:55:35 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="174259085da7cb67cacc3eba8e8469e6";
	logging-data="580028"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+ghVMKt6EO7sWxIZeZ4PiR"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:1B7Fbn58fCF1L7jG2wNjx+pL7cM=
Content-Language: en-GB
In-Reply-To: <vasfms$gcgq$1@dont-email.me>
Bytes: 11164

On 30/08/2024 13:59, David Brown wrote:
> On 30/08/2024 01:49, Bart wrote:
>> 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:
> 
> <snipping for brevity>
> 
>> 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
> 
> It does not /need/ delimiters.

There's lot of things that language syntax might not need. For example, 
I could dispense with the closing parentheses here:

   x = (a + (b + (c + d

as they can supplied as needed at end-of-line. But it's much better idea 
to supply them for all sorts of reasons.

(My Casio calculator allows such parentheses to be left out.)

> It does, sometimes, need a bit more care, especially if you have lots of 
> nesting.

A /lot/ more care.

> (And again let me repeat - I prefer languages to have explicit 
> delimiters.  But that does not stop me being able to write Python code, 
> or being happy with the language overall.  There are a dozen things I 
> dislike about Python, of which whitespace blocking is a very minor one, 
> but there are many dozens more things I do like about it for the tasks 
> for which I use the language.)

I just find the syntax fragile.

>> How about just fixing the ******* language? That must be better than a 
>> million programmers wasting time creating their own fixes.
> 
> Ah, so it is better to invalidate all the work done by these million 
> programmers so far, along with all the tools, books, courses, 
> documentation, etc., than to say that people writing big functions might 
> want to add an occasional comment?  Yes, I can see how that makes 
> perfect sense.

If you're going fix it, then fix up, and not wait 30+ years to do so!

But there can be ways to do it without needing to change existing code 
or tools.

>>
>>> 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.
>>
> 
> Sure.  We all have opinions about all sorts of things.  Some people even 
> have /informed/ opinions, that might be relevant to other people.
> 
>> One thing I despised was the begin-end business in Algol60 and Pascal, 
>> which has the same nuisance as braces in C-like languages.
>>
> 
> You don't like whitespace based blocks, and you don't like explicit 
> delimiters for blocks.  Maybe you just don't like structured 
> programming?  (Not all programming languages are structured.)

Both brace-style (and especially C-style optional braces) and 
indent-based have their problems.


>> 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.

> 
> Ah, it is the need to press a couple of extra keys that you despise so 
> much?

no, it's just poor ergonomics. Language designers must have thought it 
neat to allow only a single statement for function bodies, loop bodies, 
or branches of conditional code.

If someone wanted more than one statement, they wrapped them inside a 
'compound' statement (and hence you ended up with conditional '{-}' and 
conditional 'begin-end'.

But look at these examples:

  if (cond) {s1; s2;}  else  {s3; s4;}
  if cond then begin s1; s2 end  else  begin s3; s4 end

It's clear that those first sets of block delimiters are not needed: s1 
and s2 are already delimited by ') ... else' or 'then ... else'.

A delimiter is only really needed at the end of the final 'else' block:

  if (cond) s1; s2;  else  s3; s4;}
  if cond then s1; s2  else  s3; s4 end

With the second line, it works (this is what Algol68 introduced, and 
what I copied).

But that first line looks weird with its unbalanced closing }. There can 
also be a problem if you wanted to dispense with the brackets around 
'(cond)', as now 'cond' runs into 's1'.

So C-style syntax is not an easy fix; better to leave it.

Note that Python does use block delimiters in some cases:

    if cond:
        s1
        s2
    else
        s3
        s4

Like the 'else' here. It is the one for the final block that is missing.

>> 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.
>>
> 
> That's great.  But being interested in languages, their design, and 
> their features does not mean having an obsession about calling their 
> features "flaws".

Are you saying that no language (C for example) has flaws?

If not, then why can't I call them flaws?

>> It's not just me!
>>
> 
> For every programmer involved in changing and developing the Fortran 
> language, there are a thousand programmers who use it - whichever 
> version of it they find best for their job.  Now, it is important that 
> these one-in-a-thousand programmers are there, improving the language. 
> But most of us are in the 999-in-a-thousand group that /use/ the 
> language.  (In that one-in-a-thousand I am including the people who 
========== REMAINDER OF ARTICLE TRUNCATED ==========