Hacker News Reader

Comment by scythe | Hacker News Reader

>most code is not complex enough to warrant while loops,

  scale = 5

  while (scale > 0.1):

    do_stuff(scale)

    scale = scale/2

Sure, you could use exponentials with range(), but is that really clearer?

View on HN

Even clearer:

    scale = 5
    # The alternative would be exponentials with range(),
    # but it's clearer to use 'while'
    # pylint: disable=[while-used]
    while (scale > 0.1):
        do_stuff(scale)
        scale = scale/2

Less sarcastically, how about:

    scales = itertools.takewhile(
      lambda n: n > 0.1,
      functools.reduce(lambda x, y: x / y, itertools.repeat(2), 5)
    )
    map(do_stuff, scales)

This would be even easier with an 'iterate(x, f)' function which generated (x, f(x), f(f(x)), ...), but I couldn't find one in Python's builtins:

    scales = takewhile(
        lambda n: n > 0.1,
        iterate(5, lambda x: x / 2)
    )
    map(do_stuff, scales)

Poe's law demonstrated.

Indeed, though in a language designed for this style of programming, the idea behind that final example in the GP comment works fine. A Haskell version might look something like this:

    iterate (/2) 5.0
      & takeWhile (>0.1)
      & map do_stuff

The `iterate` generates the infinite sequence, the `takeWhile` specifies how much of it to use, and then we do stuff with each element.

This is arguably a little nicer than the while loop since it exposes the real sequence of values you’re working with more explicitly, but at the very least it is comparably simple in its appearance. The Python version in the GP comment looks bad mostly because of the clumsy lambda syntax.

I shouldn't need to read the code extremely closely or repeatedly to have to figure out what it does when the while loop does it clearly (and in a bounded way that you can literally mathematically prove).

Also, I would scream if some opinionated dev gone crazy with their linter added pylint disables and comments explaining it every time we use a while loop in our codebase.

Why does the linter rule not, instead, check if the while loop is unbounded and warn the user of that? Surely screaming fire when there's an actual fire is better than screaming fire at the first sign of smoke.

> Why does the linter rule not, instead, check if the while loop is unbounded and warn the user of that?

Indeed, the linter only needs to incorporate of the many known solutions to the halting problem.

unBounded = null

> I would scream if some opinionated dev gone crazy with their linter added pylint disables and comments explaining it every time we use a while loop in our codebase.

That sounds like a bad situation, but it completely depends on "every time we use a while loop". The entire point of lint checks is to reduce the occurrences of certain patterns (like while loops, in this case). This post is arguing that "every time we use a while loop" should ideally be the same as "never", in which case you're still correct, but vacuously so.

For a less controversial example, try running your comment through sed 's/while loop/eval/g'. There are certainly situations where 'eval' is the only way to do something; and other situations where 'eval' would be more readable/efficient (e.g. compared to writing a file and spawning a subprocess). Yet we go out of our way to minimise our reliance on 'eval', and I certainly wouldn't mind adding a pylint-disable comment for those times I use it (every few years).

Ironically (to me at least, because it's a construct I use -far- more rarely than while), this actually seems like a case where a C-style for loop might actually be nicer:

    for (my $scale = 5; $scale > 0.1; $scale /= 2) {
      do_stuff($scale);
    }

Or you can use a for to satisfy the linter that is more in the spirit of the while loop, albeit at a cost of O(n) memory where n is the number of iterations the loop takes:

  scale = 5
  t = [1]
  for i in t:
    do_stuff(scale)
    scale = scale/2
    if scale > 0.1:
      t.append(1)

Reply on news.ycombinator.com