Peter, in your own personal finite sample, I am wondering what you might do
TODAY if you looked at your loops again and considered redoing them for an
assortment of reasons ranging from using the code for teaching to efficiency
to just fitting your mood better?

I have seen seasoned authors go back to their early work and groan. Some
have even reissued earlier work with a partial rewrite often with a long
additional preface explaining why and even mentioned what was changed and
bemoaning how they thought differently back then.

My guess is that many of us (meaning myself included) often approach a
problem and go with the first thing that comes to mind. If it fits well
enough, we move on to the next thing we can do. If not, we may step back and
evaluate multiple additional options and try another tack.

I have seen not of sort-of redundant code because someone did not plan ahead
and realize something very similar might be needed later and thus did not
make a general function they could re-use. Occasionally they may later go
back and re-do but often, not so much and just keep copying lines and making
minor modifications. Same general idea.

And perhaps worse, you may write a loop and later have to keep adding code
to deal with new requirements and special cases and rather than pause and
analyze and perhaps start again with a cleaner or more easily extendable
solution, just keep grafting on things to make the darn current code work.
Code that has many ways to exit a loop is often an example of this
happening.

So if you looked at your own code now, in the context of the rest of your
code, would you change things?

in python, I suspect I would seriously change an amazing number of things
for older code including code being ported. It supports quite a few
programming constructs and styles and has access to plenty of modules that
mean you need not re-invent all the time. How many formal loops might you
replace with a list comprehension or use a generator, NOW? How many problems
you once solved by doing things like looping and searching for an element
being present in a list when now you might use a set or dictionary?

The reality is many people learn the basics of a language and write using
fairly basic constructs and only later master the more advanced topics. But
their mature work may then often heavily use those later and more effective
methods. Functional programming often uses constructs where loops become
invisible. Objects often hide loops in all kinds of methods. Sometimes
recursion effectively does a loop. It is sometimes easy to write programs
with no visible loops.

So when counting the various kinds, are you looking for direct or indirect
methods too like map/reduce or vectorized operations?

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On
Behalf Of Peter J. Holzer
Sent: Saturday, September 11, 2021 10:42 AM
To: python-list@python.org
Subject: Re: Friday Finking: Contorted loops

On 2021-09-10 12:26:24 +0100, Alan Gauld via Python-list wrote:
> On 10/09/2021 00:47, Terry Reedy wrote:
> > even one loop is guaranteed.) "do-while" or "repeat-until is even
> > rarer since fractional-loop include this as a special case.
>
> Is there any empirical evidence to support this?
> Or is it just a case of using the tools that are available?
> In my experience of using Pascal (and much later with Delphi) that I
> used repeat loops at least as often as while loops, possibly more.
>
> But using Python and to a lesser extent C (which has a rather horrible
> do/while) construct

How is C's do/while loop more horrible than Pascal's repeat/until? They seem
almost exactly the same to me (the differences I see are the inverted
condition (debatable which is better) and the added block delimiters (which
I actually like)).

> So is it the case that the "need" for repeat loops is rare, simply a
> result of there being no native repeat loop available?

A tiny non-representative data point:

In an old collection of small C programs of mine I find:

35 regular for loops
28 while loops
2 infinite for loops
1 "infinite" for loop (i.e. it exits somewhere in the middle)
0 do/while loops.

So even though do/while loops are available in C (and I don't find them
horrible) I apparently found very little use for them (I'm sure if I look
through more of my C programs I'll find a few examples, but this small
samples shows they are rare.

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

"Avi Gross" <avigross@verizon.net> writes:
>I have seen not of sort-of redundant code because someone did not plan ahead

From my experience, the "plan ahead" approach (waterfall model)
often is less applicable than the "code is design" (Reeve) +
"refactoring" (Fowler) approach. (However, in some fields, planning
ahead is a requirement).

>and realize something very similar might be needed later and thus did not
>make a general function they could re-use. Occasionally they may later go
>back and re-do but often, not so much and just keep copying lines and making
>minor modifications. Same general idea.

I remember having read a discussion in the Web.
The question was something like:

How many times do you have to write a piece of code,
before you create a function for it?

I believe I still remember two answers:

- One time.

- Three times.

The justification I can't remember, but what I would come up
with now would be:

(for "one time":) Functions structure your code. You don't have
to wait for repetitions as an "excuse" to create them.

(for "three times:) Relax. Don't overengineer. You need to have
at least /three/ repetitions to be able to see a clear pattern.

Stefan,

Agreed that writing code to handle all possible eventualities is usually
overkill and results in bloated software delivered very late or not at all.

My point is that often OTHERS start adding requests afterward that seem
trivial to THEM as they have no idea what it takes. I have often done some
kind of data analysis for someone and made a few graphs and suddenly they
ask if I can add something else to the graph such as a few horizontal lines
showing where a danger zone lies, or some kind of average. No problem but to
do that means the new info has to have been made available or can be
calculated and often even means my function needs to take more arguments or
a wider data.frame. Then they reconsider and ask if instead of a line, can I
color the background above that point. Well, yeah, but now I might need to
calculate another column to use to guide that feature. Ah, but can you show
a series of related such graphs as a unit, or perhaps combine several
unrelated graphs in a 3 by 2 matrix. Argh! Sure, I can do that but you did
not ask me to before I started. I now might toss out much of my original
code and rewrite something so all the things needed are made first and then
the graphs are made and recombined in the right output format. This means
that what used to make a graph will now make a data structure to return that
can be used later to recombine into a bigger consolidated graphic.

Does the story end here? Nope. Tons more requests like removing color and
using shades of gray or dotted lines so it can be printed on any printer,
changing the point size of text and other characteristics and introduce
mathematical symbols and equations along the axes and I swear an amazing
number of such fine tunings including taking a series of these things into
one multi-page PDF.

If this was a paid gig and someone offered me a fixed sum, should I tolerate
almost any changes? If this was a regular paid job and this made me late and
not get other things done?

My bottom line is that it may not be reasonable to make a detailed top-down
design and stock with it BUT that code written by ever-changing requirements
can end up badly too. I shudder at times I wrote decent code full of
comments explaining well and a while later had a mess where the comments
lagged behind changes in the code as there was no point in bothering to
update them unless it stopped changing. And, often, by then, I was no longer
interested in spending any more time and sometimes just removed all the
comments and moved on! Good luck to anyone coming along to maintain or
improve the code.

I have to think about when to make a function. Something trivial is often
not worth is. And making a very abstract function that can do a dozen things
if invoked just right with many arguments is sometimes a tad too much when a
few simpler functions might do as well with less overhead and especially
when the uses have fairly little in common. Some languages may discourage
you if the repeated code needs to do things in the current environment and
thus only part of the functionality can be moved away.

-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon.net@python.org> On
Behalf Of Stefan Ram
Sent: Saturday, September 11, 2021 10:56 PM
To: python-list@python.org
Subject: Re: Friday Finking: Contorted loops

"Avi Gross" <avigross@verizon.net> writes:
>I have seen not of sort-of redundant code because someone did not plan
>ahead

From my experience, the "plan ahead" approach (waterfall model)
often is less applicable than the "code is design" (Reeve) +
"refactoring" (Fowler) approach. (However, in some fields, planning
ahead is a requirement).

>and realize something very similar might be needed later and thus did
>not make a general function they could re-use. Occasionally they may
>later go back and re-do but often, not so much and just keep copying
>lines and making minor modifications. Same general idea.

I remember having read a discussion in the Web.
The question was something like:

How many times do you have to write a piece of code,
before you create a function for it?

I believe I still remember two answers:

- One time.

- Three times.

The justification I can't remember, but what I would come up
with now would be:

(for "one time":) Functions structure your code. You don't have
to wait for repetitions as an "excuse" to create them.

(for "three times:) Relax. Don't overengineer. You need to have
at least /three/ repetitions to be able to see a clear pattern.

--
https://mail.python.org/mailman/listinfo/python-list

"Avi Gross" <avigross@verizon.net> writes:
>If this was a paid gig and someone offered me a fixed sum, should I tolerate
>almost any changes? If this was a regular paid job and this made me late and
>not get other things done?

A question is raised here which leaves the technology of
software creation and reaches into the area of software
contract design and software contract implementation.

In the Federal Republic of Germany, an employee is a
dependent worker who is bound by the instructions of his
employer. If that employer instructs the employee that
activity A should have priority over activity B, then it is
not the employee's problem to worry about the consequences.

Here now follow remark concerning freely negotiated
contracts for software projects:

From the point of view of contract drafting, you can make a
preliminary contract that regulates the creation of
a specification. If the specification is accepted by the
client, the main contract comes into force and the
specification is realized. Requests for changes would
require new contract negotiations, during which such
requests can be rejected.

When implementing the contract, it can be difficult for the
contractor to always say "no" to change requests if he is
working from a weaker position (for example, if he urgently
needs that customer or money).

Alternatively, an "agile" contract can be designed that
"embraces" change requests, although here the contract
design can be a bit trickier. Surely the customer will have
to pay more one way or another if they want more changes /
enhancements here too.