Hacker News Reader

Comment by maest | Hacker News Reader

   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>"

View on HN

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.

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).

> 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.

Reply on news.ycombinator.com