Hacker News Reader

Comment by mekkkkkk | Hacker News Reader

I think the idea is that a loop in many cases doesn't express your intent. What you might want to do is to "set the property 'foo' to 'bar' on all items in an array".

What you might write is "create a variable and set it to zero, then iterate that variable as long as it's smaller than the number of items in the array, and do this between each iteration: take the item at the variables index and set its property 'foo' to 'bar'".

Of course any programmer will instantly see what's going on, but that's not from clarity but from prior experience and familiarity.

View on HN

That's only true for languages that don't support looping over an iterable directly. Or if you need the index while iterating too.

Python, Rust, Swift, C++, ObjC and more all support the equivalent of a foreach loop today. That perfectly shows intent

Agreed, and based on the list here: https://en.m.wikipedia.org/wiki/Foreach_loop the only popular language without for each is C.

And even then, a decent number of data structures provided in headers on *nixes provide for each macros.

True. It is possible though for a language to avoid these iteration constructs as if they are needless plumbing as well. Consider the elegant type system of the XQuery language:

In XQuery, the root type is a flattened sequence. Flattened means not just that [1, [2, 3]] is flattened to [1, 2, 3], but also the a single object 42 is equivalent to a sequence of one object [42].

This means that if I write:

  declare function local:prefixName($name)
  {
     fn:concat("prefix-", $name)
  }

I can invoke it with a single name or a sequence of names without any explicit iteration.

It has drawbacks but using XQuery certainly highlights how much code we normally waste dealing with "things" and "sequences of things" separately.

(Than again working with XQuery also highlights how much code one can waste dealing with XML namespaces :)

Admittedly it's a worst case scenario, but the broader point still holds even with a foreach. You are still picking out each item individually instead of operating on the collection which is what you intend to do. You write "do this for every apple: peel it", instead of "peel the apples".

apples.forEach(peel) is pretty clear, and the distinction is actually important for some operations which could conceivably be applied either to the whole collection or to each item in the collection and thus could be ambiguous in plain English, like “gift wrap the apples.” That could mean giftWrap(apples) or apples.forEach(giftWrap).

Well said! And when this clarity is lacking in a codebase, damn do I find it incredibly frustrating! Like, can’t you just tell me whether you are trying to operate on the items of the collection or the collection as a whole??? Why did you need to adopt this ambiguous formation??

I love me some forEach methods! It's still one off from completely avoiding the loop-think though. A syntax like "apples.'peel()" (where peel is a method on the individual apples) is what I imagine.

As a PS, I think the parent comment was referring to a (corresponding) "for apple in apples: peel(apple)" syntax though. The main point was that you don't have to bother with the manual index iteration as in my worst case example.

Here's another comparison: peel and add to mixer fresh apples only.

    let mut mixer = Mixer::empty();
    apples.for_each(|apple| {
        if apple.is_fresh() {
            mixer.add(apple.peel());
        }
    });

    let mixer = apples
        .filter(Apple::is_fresh)
        .map(Apple::peel)
        .fold(Mixer::empty(), Mixer::add);

They're both pretty clear but I'd prefer the second one (if you used collect instead of fold)

I chose Rust syntax because it allows both chaining and using methods as functions, but avoided Rust-specific features. In addition to `collect` this example is missing `.into_iter()` that both examples would need: I interpreted `apples` as an iterator instead. Otherwise the first example would be clearer with a for loop.

> That's only true for languages that don't support looping over an iterable directly.

Even with loop-over-iterable semantics, explicit loops obscure intent compared to comprehensions and map/reduce/filter/etc.; they are better than C-style loops which in turn are better than conditionals + gotos, but that doesn't make them good at expressing intent in many common cases.

there is also a pretty big difference in what a compiler can do if we express the computation as a set of operations that transform the sets rather than a little rats nest of mutations and jumps.

if you wanted to vectorize the set/jmp version, you'd be trying to tease apart a problem which is undecidable in the limit. vectorizing the transformer version is trivial.

There’s also the reverse: writing as a loopless operation forces the programmer to write code that can be easily vectorized.

In python, the way you write this is more similar to how we express the intent, using dict/list comprehension. But the thing is, for anything more complex that your example, the comprehension notation is harder to read and make changes if you are not really used to it

Pythonic for loops are more or less `for item in list: <block of code>`. Sill no manual management of array indices.

This seems perfectly clear.

  for item in array:
      item.foo = bar

   array.'foo = bar

Is clearer. Or, at least, would be, if one were accustomed to the (fictitious) adverb '.

There's no need for all the ceremony around specifying "for x in y: <some function describing what to do with x>"

It isn't. "For x in y" is literally what we say when speaking as humans unlike that quote thing.

I don't find that to be a convincing argument, because it suggests we should write "foo applied to bar" instead of "foo(bar)" in your code. It's just notation, just because it's new, doesn't mean it's bad.

There's maybe an argument to be made about there being _too much_ notation to learn, but notation makes sense for fundamental concepts (which loops clearly are).

Notation is important. It condenses thought and refines the concepts, making them more visible. In fact, some valid mathematical theory came about from figuring out proper notation and then playing around with it, sometimes in non-rigorous (albeit intuitive ways). e.g. consider how physicists wildly move dx and dy around in differential equations (much to mathematicians' dismay)

Ancient greek geometry textbooks were written in long form: "the square of the hypotenuse side is equal to the sum of squares of the other two sides". We can all agree that the "a^2+b^=c^2" notation is better.

That's an awkward way to speak.

"Take each of my gizmos, then put it in the gizmo box"

    for gizmo in gizmos: gizmo.put_in_box()

"Put all my gizmos in the gizmo box"

    gizmos.'put_in_box()

Or “paint all my gizmos red”.

Your first statement is unambiguous.

Your second sentence is ambiguous. It could mean

1. Put all of my gizmos in a single gizmo box, together, OR

2. Put each of my gizmos in its own gizmo box

Are you talking about the pseudo code or the readable sentences? I hope my point comes across even if there's some linguistic nuance I'm missing.

I'm talking about the readable sentences. The one you labelled as "an awkward way to speak" was unambiguous. The phrasing it seems you preferred was ambiguous. Personally, if I have to write the sentence down and the consumer of the sentence can't ask questions to clarify, I prefer the unambiguous wording. Ie, say exactly what you mean or you may not get what you want.

> A wife asks her husband, a software engineer, “Could you please go shopping for me and buy one carton of milk, and if they have eggs, get 6!” A short time later the husband comes back with 6 cartons of milk. The wife asks him, “Why the hell did you buy 6 cartons of milk?” He replied, “They had eggs.”

The second code doesn’t put all the gizmos in the gizmo box. That’s your intent, but not the reality. All that syntax says is apply function to all elements. It is syntactic sugar for the code you put above; it’s a for each loop.

Well, the argument is about expressing intent, so I guess we agree.

I think you will find that those “humans” you’ve been hanging out with are all programmers or mathematicians. “Humans” don’t talk like this. Most of them have never heard of set theory.

Not necessarily. The later expression might be more common though:

"For every item in this truck, remove that item and put in in the warehouse."

"While this truck is not empty, keep unloading items to the warehouse."

Maybe it's just my mother tongue, but "pour chaque entrée dans la base de données, prends la moyenne et affiche-la" sounds pretty ok (literally in English, for each entry in the database, take the average and print it)

> "For x in y" is literally what we say when speaking as humans unlike that quote thing.

What about:

"Can you unload the truck?"

The current context gives us implied knowledge that we're talking about the items in the truck and where it's getting unloaded to, such as a warehouse if we're near a warehouse door. We only expand on that verbally when we need to such as "Can you throw out the empty boxes in the truck?".

I think this is why programming is nonintuitive, you have to include important steps with very precise words that often go unsaid. Even "throw out" wouldn't convert to the correct intent if a computer executed that statement as is. You would end up literally throwing the empty boxes out of the truck instead of putting them into a dumpster or garbage can (the likely intent based on this example).

That does look pretty nice for this example. I think the problem with it is that introduces too much new syntax that you have to memorize. The beauty of a for loop is that you can do _anything_ with it. And it all works with the same syntax.

  for item in array:
      item.foo = bar

  for item in array:
      item.foo = item.foo * 2

  for item in array:
      my_bar_func(item.foo)

If you special case certain uses of a for loop and add language syntax around it, of course you can make code terser. But it's nice to rely on a small set of very generally useful syntax.

depends on how many different types of loops there really are. now _that_ would make an interesting article.

> The beauty of a for loop is that you can do _anything_ with it.

That’s also the curse: a generic loop can be almost anything (looping over an iterable can't quite express anything, but it can do a lot), so seeing it tells you nothing.

C-style loops can do more (literally anything), and loop-over-iterable syntax has been generally preferred where it can be applied because it tells you more (even if only a little more) about what the block of code is doing up-front.

Constructs that are more specific than loop-over-iterable can be correspondingly more expressive.

> all the ceremony

It's not _that_ verbose -- the trade off in clarity is pretty stark IMO.

In practice many people move between languages frequently daily. This syntax and semantics it provides are fairly different from that of popular languages.

With numpy, this would just be item.foo [:] = bar. Much more readable to me - the whole «for» thing is superfluous.

Neat trick. Didn't know about it.

In pandas it would be item.foo = bar, _as long as_ bar isn't something you can iterate over.

Numpy is all about this. E.g y = np.sin(x). X and y are arrays and you can think of them as «all values of x and y» or «the physical variables x and y»

These comments from people who don’t write software and only use programming for data science. Numpy is superfluous for anyone that doesn’t need it.

Indeed. Also, this notation was lifted straight from Fortran 90 (which itself got it from Matlab, Algol, and the primitive slicing that was possible in older FORTRANs). The idea that a concise notation is helpful for the concept of “put a thing in all the buckets of an array” really is quite old. It does make a lot of sense.

Reply on news.ycombinator.com