Re: Python (was Re: I did not inhale)

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