It's kind of sad that "for" is the keyword programming languages settled on for the loop construct.
Ever since its counterpart "do" was dropped from the for-statement, it's just been utterly nonsensical. I mean how on earth does the word "for" convey a loop?
With the recently designed languages like Go and Swift taking so many cues from the Pascal side of the ALGOL language family, how nobody thought to pick up "repeat" or "loop" is simply beyond me.
Interestingly, the more common way to write that in Ruby would be `(1..10).each { |i| ... }`, or (in the case of needing a multi-line block):
```
(1..10).each do |i|
...
end
```
"do" does end up getting used, but only as syntax for a "block" (similar to what other languages would call a lambda).
Ruby also has a shorthand for when you want to do something `n` times without caring about the iteration number:
```
10.times do
...
end
```
One final note is that loop you wrote above is actually different in Ruby than it is for Python and Rust; `x..y` is an inclusive range in Ruby, whereas `range(x, y)` in Python and `x..y` in Rust are exclusive on the right side. I think you might have realized that since you used different starting values for the other two, but you got it backwards; the Python and Rust loops will loop only nine times, whereas the Ruby one will loop 11 times. Ruby does have a syntax for exclusive ranges though; `x...y` is an inclusive range from `x` to `y - 1`. Similarly, in Rust, `x..=y` gives an inclusive range from `x` to `y`. I don't know of any way to do an inclusive range in Python other than manually, but someone with more Python knowledge might be able to provide something for that.
In math you have the "for all customers there exists a customer that". Maybe I should write up a formal INTERCAL proposal that this should be the proper loop construct in 2020, spelled out in plain Math English like that.
>I mean how on earth does the word "for" convey a loop?
I don't know about a loop per se, but it's used in plain language when you want the same thing to be done to every element in a set. "Clean this item and put it away. Then do that for every other piece of cooking equipment."
It was actually originally borrowed from its cognate für in German:
>>The name for-loop comes from the English word for, which is used as the keyword in many programming languages to introduce a for-loop. The term in English dates to ALGOL 58 and was popularized in the influential later ALGOL 60; it is the direct translation of the earlier German für, used in Superplan (1949–1951) by Heinz Rutishauser, who also was involved in defining ALGOL 58 and ALGOL 60.
I think there's an argument that "do" is just a placeholder for the body of the loop, i.e. "clean this item and put it away". If you flip the order that the body and the iteration are expressed so that it reflects what most programming languages use for syntax, it would be "for each piece of cooking equipment, clean it and put it away". There's no "do" here, nor is it needed.
"Do your homework" doesn't imply a loop either. Nor does "This could take a while"
It should not be a shock that the english language doesn't naturally have a single word that can express both a condition/duration as well as a command without any other helper words.
Do is superfluous. Everything in an imperative program is a request to do something.
> It should not be a shock that the english language doesn't naturally have a single word that can express both a condition/duration as well as a command without any other helper words.
I never asked for a magic word. To the contrary, I was lamenting the lost of the helper word "do", making the "for" alone nonsensical.
> Do is superfluous. Everything in an imperative program is a request to do something.
I disagree. I think "for...do" makes things much clearer than "for" alone.
All languages, both human and programming, have vestigial nonsense like this. All of them. It isn't possible for languages which are used to not have them, I would say.
Wish they'd called it `grob` and called `return` `bolver` so that we can accept they're just syntactic constructs instead of pointlessly assuming meaning from what are just syntactic constructs.
sum = 0
grob (i=0; i<10; i++) {
sum += i
}
bolver sum
I learned programming before I learned English. I was always confused by PRINT vs INPUT: which one reads and which one writes? So yeah, it could have been grob and bolver or anything.
Ironically, I was undone here by bad pedagogy. The text I was reading said something about "`getch` being the opposite of what you expected since you'd think it gets the character from the computer and prints it to the screen, while `putchar` does the opposite of what you expected and doesn't give you the chance to put anything into the computer".
Now, clearly whoever wrote that text had their own conception of the thing, but my mental model was that the computer is executing the program so it is getting the character from me with `getch` and it is putting the character on the screen with `putchar`. So the actual functionality seemed right.
But when you combined that with the text saying that it was counter-intuitive I was like "Oh okay, got to remember it was counter-intuitive. It's the opposite of what I'd think" and so the text induced me to misunderstand. Fortunately I was a child so I learned pretty rapidly that lots of people write total crap (irrespective of the conception, the author should not have pushed it so hard) and it didn't damage my mental model at all.
Oh man, trust me, by the time you start programming, you'll have already studied English.
There's no way around it since non-English documentation is miserable at best.
Looking at the syntax (as a Go beginner), I'm not really sure whether that's less or more to learn. Seems like one of those arbitrary language design decisions that don't make a huge difference either way.
Ever since its counterpart "do" was dropped from the for-statement, it's just been utterly nonsensical. I mean how on earth does the word "for" convey a loop?
With the recently designed languages like Go and Swift taking so many cues from the Pascal side of the ALGOL language family, how nobody thought to pick up "repeat" or "loop" is simply beyond me.