I don't really get the point of the article. Even if I knew little about python, would be it surpsing that a language with no real basic types is probably abstracting a lot?
Even a simple i=0, i=i+1 is "hiding" a lot in python then.
Even a simple i=0, i=i+1 is "hiding" a lot in python then.
It's not like 'for' is limited to counting in other languages. The grand-daddy in c does something until some condition is false, and that thing can equally be incrementing/decrementing a number or invoking some function. That's what a loop does in any case, it compiles down to a conditional jump (JNE/JE..)
Maybe his reason for astonishment is obscured by over-use of an LLM to 'enhance' the text.
C 'for' is a while loop. It's strictly syntactic sugar for an already existing feature. And it's really, really transparent. `for(A; B; C) { do_stuff(); }` isn't just a while loop, it's this while loop:
A;
while(B) {
do_stuff();
C;
}
and get [y,y,y,y]?
Looking back at 2015 when Python 2 was still supported, there was a lot of confusion for why Python 2 would create a tuple while Python 3 created a generator for the following statement:
foo = (x for x in [10, 20, 30])
std::container<T> container;
for (std::container<T>::iterator i = container.begin(); i != container.end(); ++i) { ...}
auto iter = container.begin(); while (iter != container.end()) { ...; ++iter; }
for (auto const & t : container) { ... }This is far more than most iterator designs allow, and as I said if you needed more this is very welcome, but if you didn't it's probably bad news.
C++ can sort iterators for example, so long as they're suitable for indexing back and forth as the sort progresses. Rust's sort functions are defined on its slice types, which makes sense in practical terms but if what you've got isn't quite a slice but could meet the requirements in C++ that's a problem for you.