Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Andy Walker <anw@cuboid.co.uk>
Newsgroups: comp.unix.shell,comp.unix.programmer,comp.lang.misc
Subject: Re: Python (was Re: I did not inhale)
Date: Wed, 28 Aug 2024 23:07:11 +0100
Organization: Not very much
Lines: 93
Message-ID: <vao72f$3dhv9$2@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> <vakj7g$303sh$1@dont-email.me>
 <vakn87$30oaf$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 29 Aug 2024 00:07:12 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="997ea9d52d19a9d48b1b147c3f20c54d";
	logging-data="3590121"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+v9Ob38JyMy6qk8nyga2mZ"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:fQXGs3HLKFWtWllwSuLALxjK/Xg=
Content-Language: en-GB
In-Reply-To: <vakn87$30oaf$1@dont-email.me>
Bytes: 5853

On 27/08/2024 15:18, Bart wrote:
[Previous discussion and code snipped -- ANW]
> This was an attempt to port an benchmark into Nim; I'd spent the
> best part of an hour trying to get it right, but it kept going
> wrong. In the end I resorted to artificial block terminators.
> The final code looked like that below. Now it is much, much easier
> to see what goes where, and what belongs to what. I can more
> confidently write that extra statement following the opening 'if'.
> With these changes, the porting went much more smooothly.
>          if q1!=1:
>              for i in countup(2,n):
>                  q[i]=p[i]
> #           end
>              flips=1
>              while true:
>                  qq=q[q1]
>                  if qq==1:
>                      sum+=sign*flips
>                      if flips>maxflips:
>                          maxflips=flips
> #                   end
>                      break
> #               end
>                  q[q1]=q1
>                  if q1>=4:
>                      i=2
>                      j=q1-1
>                      while true:
>                          t=q[i]
>                          q[i]=q[j]
>                          q[j]=t
>                          i+=1
>                          j-=1
>                          if i>=j:
>                              break
> #                       end
> #                   end
> #               end
>                  q1=qq
>                  flips+=1
> #           end
> #       end
> Sure, people CAN program in such languages, but it is harder work> and more error prone.

	ISTM that the difficulty in reading and writing code like that
stems not from the indentation, but
		from a
		  long narrow
		    corridor
		    of program
		  which is
		    difficult to
		    read
		    and write
		    no matter how
		      it is indented.
		Variable indentation
		  merely
		  makes the long
		  column wriggly.
It reminds me of the early autocodes, before the days of block structure.
I don't know Nim [and only a little of Python], so I can't apportion the
difficulty of understanding the code between the language and the chosen
programming style.  But I can't resist adding a few comments:

   (a) Bart takes 14 lines [from "if q1>=4" to the corresponding "# end"]
to express the notion [E&OE]

	for i from 2 to q1%2
	   swap (q[i], q[q1 - i + 1])

Small wonder that he found the code hard to get right!

   (b) There are two occurrences of "while true" and two of "break" in the
code which would not be necessary or appropriate in C or Algol [amongst
others].  Again, IMO these contribute to the obscurity of the code.

   (c) I recognise that code as coming from a version of the "Fannkuch"
benchmark, so I already have it in C and in Algol 68G.  Bart's Nim code
is substantially longer [around twice the length of the A68G].  Brevity
is not everything, but if you are forever scrolling from one window to
the next while your friend gets it all into one window [without losing
clarity of expression], then guess who is going to find it easier to
read, write and understand the code.

   (d) Further, if the code is harder to understand, it has more need of
explanatory comments, which in turn make the code longer, so harder to
navigate around.

-- 
Andy Walker, Nottingham.
    Andy's music pages: www.cuboid.me.uk/andy/Music
    Composer of the day: www.cuboid.me.uk/andy/Music/Composers/Hertel