Where's the evidence? What you're repeating is received wisdom -- which lacks any sort of empirical foundation.
Sure, I've seen messes made of goto. I've also seen messes made of nested if's that would be cleaner and easier to read had the developer made proper use of goto.
Goto can be used to cover any of those cases, so it's more difficult to follow.
Should we then claim that conditional iteration is harmful and ban its use?
"What?" You ask. Allow me to explain. There are five essentials of control flow: Direct sequencing, conditional and unconditional branching (if, goto), and bounded and conditional iteration (for, while).
Bounded iteration and conditional branching are can be trivially simulated using conditional iteration. You never need goto, as its use can always be avoided with enough wrangling, so it can replace in practice, if not directly, the unconditional branch as well. When you see a while, then, it could be being used for any control-flow operation. What a horrible thing! Imagine the mess that developers are sure to make tossing "while's" all over the place!
It would be stupid, of course, to ban "while" on those grounds just as its stupid to ban goto on those grounds. Conditional iteration is very helpful, when used as intended. Goto, likewise, can make your code easier to read. After all, sometime avoiding goto (or its doppelgangers, break and the early return) can lead to some messy code.
when you could use a goto statement in code, there is another, better way of doing the same thing
The best argument you make against goto is that it's unnecessary. Of course, with just the conditional and unconditional branch, we can eliminate every other control structure. Should we ditch those instead? We could take it a step further, as you know, and eliminate everything but the while loop!
To be fair, you did say "99% of the time" and use the nebulous qualifier "better". Still, why hurt yourself, and your code, in that remaining 1%? Because someone once told you it was bad?
That's probably because you consider any code with a goto inferior to code without it. It's a no-win situation for the humble unconditional branch.
Goto is intuitive. From CYOA books to tax form instructions, it's use is well-established in the real world. Why should developers keep to this absurd taboo just because some guy said it's bad? It makes no sense.
In my 25 years of software development, I have never found a situation where the use of GOTO would produce better code than putting a little thought into your code.
You'll find that you use goto quite a bit, you just don't type 'goto'. Ever use an early "return"? How about "break"? They're all goto's in disguise, letting you escape from the strictures imposed by structured programming.
More directly, are you telling me you've never produced an ugly rats-nest of if's? I see it all the time, and lament the goto taboo. (Very often, that sort of mess is caused by a lot of little contingencies in a process, an area where goto shines. See any old tax instruction booklet.) If we still taught kids about flow-charts, they'd immediately recognize the value of the goto -- and have far better code as a result.
Argue all you want, but lots of things are bad when misused or overused, from classes to control structures. (Nothing is safe from abuse or criticism!) We just don't have a decidedly religious taboo against them, so why single-out goto? It's actually useful, unlike other harmful things like deep inheritance hierarchies or circular dependencies. Let's focus our efforts on something more productive, and leave goto alone.
Now, we write horrible, impossible-to-follow, spaghetti code without goto!
Remember kids, 'spaghetti code' refers to code with complex *control flow*. That is, if you trace it with a pencil, you end up with a document that looks like a plate of spaghetti. We're, arguably, worse-off now than we were before goto became taboo.
We learned the wrong lesson.
In smalltalk, everything happens somewhere else. --Adele Goldberg
Are you a JRef regular? You usually only get this kind of silliness there.
In reply to "hell is other people" you say "Most of the Universe has no people, hence Universe isn't Hell." That doesn't make any sense.
Let's give you a hand. If we accept that "hell is other people" then we need to assert that "the universe isn't other people" to conclude "the universe isn't hell". If you instead assert "Most of the Universe has no people" then all that follows is "Most of the universe has no hell".
Old reviews focused on old hardware won't tell you much about the OS. Give it a try before you bash it. It's really well-done. Beats Android in my book. It can even properly switch tasks.
Right now, I have a BlackBerry and a FirefoxOS Phone. Not just any FirefoxOS phone, mind you, but the original craptastic ZTE Open. It's still better than the last Android I had. Even running an antique build (1.2) on third-rate hardware, it hasn't crashed on me once.
Give me higher specs and a US release and I'll switch over permanently, not just when traveling.
Out of morbid curiosity, why do you think it's "unusable". (I can actually safely switch tasks and close apps in FXOS, which Android still hasn't quite worked out. It's always a gamble on Android. Will my app stay up while I check this notification or will it close? Is it worth the risk? That alone makes it more usable than Android.)
1: If an accurate simulation of the process of compiled imperative code is pedagogically unsound
No. Setting students up for failure is pedagogically unsound. Don't twist things; that's not productive.
Surely then the pedagogically sound way to learn about coding is top-down -- starting with declarative languages, then working our way closer to the metal, naturally bringing in procedural languages.
What did I say about twisting things? Pedagogy is about process, not content. (Otherwise, some subjects would be unteachable!) Further, I don't think you understand top-down design, or you're being purposefully obtuse.
Moving on: There's a reason that imperative languages dominate the landscape -- other paradigms are just more difficult (for beginners and professionals alike). You could start kids off with a functional language, concatenation language, or a declarative language, though you'd be doing them a disservice. Kids already know how to give instructions, which is what imperative programming is all about! It's incredibly simple, and very easy to understand.
We develop and use programming languages for a single reason: to make programming easier. Have you ever tried to do anything non-trivial in a declarative language? It's a nightmare. Worse, the resulting code looks suspiciously imperative! (First, get the computer to give you x and y from z. From z you can then get it to give you a and b. From a and b, you can get the computer to give you c, the thing want you wanted in the first place.) This could be a weakness of declarative programming, or just a sign that imperative programming is more natural. Either way, it's pretty obvious that declarative programming, outside a few narrow domains, does not succeed in that singular goal of making programming simpler.
As you're probably painfully aware, declarative programming has been an absolute failure for general purpose computing. If it were truly more natural, as you say, shouldn't declarative languages be dominant?
You're too short-sighted. There are positives for you as well, not just the developing world.
See, Mozilla is pushing an open standard app package that other platforms can implement, built completely on existing open standards. That means easy cross-platform mobile apps additional distribution options for developers, For smaller platforms, it means a ready-set of apps for their new platform before launch. Competition in the mobile space for consumers!
That's the point in dispute. I'm not sure anyone seriously considers it part of "Hard-AI" these days, the laity excluded, of course.
So where do I publish a refutation of Searle? I had one on the web once.
In a reputable journal, of course!
I presume you found a way to take down the claim "syntax, by itself, is neither constitutive of nor sufficient for semantics". It's the very core of the argument and I can't see any refutation that doesn't address this point being very strong at all. If you can knock that pillar down, you'll have changed the world. The implications would be far-reaching.
Then you weren't doing it right. The whole point of the exercise is for them to get it wrong.
But that's not pedagogically sound. The first rule: don't set them up for failure. The point of the exercise is to show them that they already have some of the necessary skills, and to foreshadow future topics.
Your job is to take the slightest ambiguity and do it wrong.
You actually... make the sandwich?
We do this because humans think declaratively.
That's a bit of a stretch, isn't it? You always start with 'what' before the 'how'. It's why top-down design has been such a useful and successful approach. (You even hint at that in the sandwich example with the need for further refinement.)
Ask a 4-year-old to tie their shoes (the what) and there's a good chance you'll hear them say "I don't know how". Given them a complicated toy and they'll quickly rush back to you with a "How do I make it do..." Even very young children seek out procedures. Dare I say, it's natural...
Even in the example that started this, you still include the "how" (as you can see by comparison to the C# and loop examples) it's just not in sequence and includes less information useful to the reader. (Hence, it's less readable.)
I think that it's a worthwhile challenge to contribute to the FirefoxOS platform and/or to build apps for it.
Hear, hear! I've released one myself early last year. I wish I had more time for it as it's such an important platform to support.
I love the idea of an app package that you can use on other platforms. The mobile market has needed that for a long time now. If other vendors will support their app packages (as Mozilla intends) that would a massive win for consumers. BlackBerry already supports Android apps, and has the best mobile browser on the market; it shouldn't be a stretch for them. Microsoft, well, they just need apps, not unlike any future players in the mobile market.
The only thing worse than being stuck on an airplane someone talking to someone on their phone: being stuck next to someone talking to no one on their phone.
When people like you incorrectly claim that Firefox doesn't suffer from awful performance or excessive memory usage, the rest of us who have experienced these problems know you're wrong.
FF does periodically hang on me for a few seconds to a minute, though that seems limited to just my laptop. It never happens on my wife's computer, my work desktop, or any of the computers at the lab.
Otherwise, performance seems to be more than acceptable. That is, I haven't been tempted to move back to Chrome. (Now, on old machines still running XP, the difference is night and day. Chrome is basically unusable, while FF works just fine. What I find baffling, of course, is that the reverse used to be true!)
The memory leak? It simply doesn't exist. (The original memory "leak", that started this nonsense meme, turned out to be a myth. It never actually existed.*) It's still not true today.** Of course, people still complain about it. I presume its because they either don't know what a memory leak is or just assume that "it" still exists and want to, as the AC so eloquently put it "bitch and moan". Today, it actually uses less memory than Chrome.
Chrome, incidentally, has had more than its fair-share of reported memory leaks and performance issues lately. They just don't have a meme inspired by a myth to go along with it.
But, hey, I like Australis, so nothing I say counts.
* Setting browser.sessionhistory.max_total_viewers to 0 magically made the alleged leak vanish. Can you guess why? ** There were a couple of actual serious leaks a few years back, but they were quickly fixed.
Ah, I guess I wasn't terrible clear. I mean the test is meaningless as it gains us nothing, regardless of the results. It doesn't matter if users here "don't understand it" or their variations are uncomfortably off from the originals. They can be as wrong as they want and yet, like the originals, still not address the question in any way.
As to the question itself, I'll decline to comment.
often with sophistry and fallacies included in the arguments (cf. Searle)
I'm curious, did you actually find an issue with Searle's argument? You should publish it. You'll be quite famous.
That's ridiculous. Of course humans think procedurally. Don't know how to do something? Here's this step-by-step procedure! If you ask how to bake cookies or change your spark plugs, you'll find (and expect) that you're provided a handy list of steps.
Just think of the classic "peanut-butter and jelly" demonstration of trying to tell someone how to make a sandwich procedurally -- it's really hard, and even many programmers can't do it right first try.
I've used that and similar problems when teaching kids how to program. Not a single child has failed to get it right on the first try. Have you really seen someone fail at this? Were they conscious?
(Just thinking about it, that's often how kids explain things to you when they're proud of some accomplishment. "I did x!... First I... then I... ")
So, without providing a list of steps, can you explain to me how to make a peanut-butter and jelly sandwich? Surely, there's a much more natural way to communicate that knowledge, yes?
Does it really matter? Turing's test is completely meaningless, both in his original proposed forms and the zillions of variations imagined by Slashdot users, as far as answering the essential question "Can machines think?" is concerned. No matter how you vary the test, it's fundamentally unsound. (As you're probably well-aware, this has been discussed to death in the literature.)
It's been dead so long you might as well be arguing a subtle point about phrenology. Is it really worth the effort?
The more experience you have, the easier this becomes, but it is still a more difficult cognitive task than reading a single statement. my_list = [ x*x for x in input_list if x > 0 ] my_list = [] for x in list : if x>0 : my_list.append(x*x)
I strongly disagree. As you said: "you still need to break it down" which, adds to the cognitive load. The for loop is not only neatly broken down for you, but includes additional information to help you understand each part and the relationships between each part.
Further, the components themselves are also "in order" making it read more "naturally". The order in the list comprehension example might as well be completely random. Consider the same example using list comprehensions in C#: my_list = from x in list where x > 0 select x*x;
This is dramatically more readable than the Python example simply because those imperatives of imperative programming (direct sequencing, conditional branching, bounded iteration, and conditional iteration) are still applicable. It's almost as readable as a for loop, though it still requires special/uncommon knowledge; just far less than in the Python example.
I suppose it doesn't really matter how much better or worse than other languages handle them. In every case that I'm familiar, they add complexity (without also adding value, an unforgivable sin). Complexity, naturally, harms readability.
Slashdot Mirror
That was Niklaus Wirth.
Where's the evidence? What you're repeating is received wisdom -- which lacks any sort of empirical foundation.
Sure, I've seen messes made of goto. I've also seen messes made of nested if's that would be cleaner and easier to read had the developer made proper use of goto.
Goto can be used to cover any of those cases, so it's more difficult to follow.
Should we then claim that conditional iteration is harmful and ban its use?
"What?" You ask. Allow me to explain. There are five essentials of control flow: Direct sequencing, conditional and unconditional branching (if, goto), and bounded and conditional iteration (for, while).
Bounded iteration and conditional branching are can be trivially simulated using conditional iteration. You never need goto, as its use can always be avoided with enough wrangling, so it can replace in practice, if not directly, the unconditional branch as well. When you see a while, then, it could be being used for any control-flow operation. What a horrible thing! Imagine the mess that developers are sure to make tossing "while's" all over the place!
It would be stupid, of course, to ban "while" on those grounds just as its stupid to ban goto on those grounds. Conditional iteration is very helpful, when used as intended. Goto, likewise, can make your code easier to read. After all, sometime avoiding goto (or its doppelgangers, break and the early return) can lead to some messy code.
when you could use a goto statement in code, there is another, better way of doing the same thing
The best argument you make against goto is that it's unnecessary. Of course, with just the conditional and unconditional branch, we can eliminate every other control structure. Should we ditch those instead? We could take it a step further, as you know, and eliminate everything but the while loop!
To be fair, you did say "99% of the time" and use the nebulous qualifier "better". Still, why hurt yourself, and your code, in that remaining 1%? Because someone once told you it was bad?
That's probably because you consider any code with a goto inferior to code without it. It's a no-win situation for the humble unconditional branch.
Goto is intuitive. From CYOA books to tax form instructions, it's use is well-established in the real world. Why should developers keep to this absurd taboo just because some guy said it's bad? It makes no sense.
In my 25 years of software development, I have never found a situation where the use of GOTO would produce better code than putting a little thought into your code.
You'll find that you use goto quite a bit, you just don't type 'goto'. Ever use an early "return"? How about "break"? They're all goto's in disguise, letting you escape from the strictures imposed by structured programming.
More directly, are you telling me you've never produced an ugly rats-nest of if's? I see it all the time, and lament the goto taboo. (Very often, that sort of mess is caused by a lot of little contingencies in a process, an area where goto shines. See any old tax instruction booklet.) If we still taught kids about flow-charts, they'd immediately recognize the value of the goto -- and have far better code as a result.
Argue all you want, but lots of things are bad when misused or overused, from classes to control structures. (Nothing is safe from abuse or criticism!) We just don't have a decidedly religious taboo against them, so why single-out goto? It's actually useful, unlike other harmful things like deep inheritance hierarchies or circular dependencies. Let's focus our efforts on something more productive, and leave goto alone.
If you look at the code most C compilers come up with they are not afraid of a goto
As if they had a choice!
Now, we write horrible, impossible-to-follow, spaghetti code without goto!
Remember kids, 'spaghetti code' refers to code with complex *control flow*. That is, if you trace it with a pencil, you end up with a document that looks like a plate of spaghetti. We're, arguably, worse-off now than we were before goto became taboo.
We learned the wrong lesson.
In smalltalk, everything happens somewhere else. --Adele Goldberg
Are you a JRef regular? You usually only get this kind of silliness there.
In reply to "hell is other people" you say "Most of the Universe has no people, hence Universe isn't Hell." That doesn't make any sense.
Let's give you a hand. If we accept that "hell is other people" then we need to assert that "the universe isn't other people" to conclude "the universe isn't hell". If you instead assert "Most of the Universe has no people" then all that follows is "Most of the universe has no hell".
Now go and sin no more.
Basic logic fail!
Old reviews focused on old hardware won't tell you much about the OS. Give it a try before you bash it. It's really well-done. Beats Android in my book. It can even properly switch tasks.
Right now, I have a BlackBerry and a FirefoxOS Phone. Not just any FirefoxOS phone, mind you, but the original craptastic ZTE Open. It's still better than the last Android I had. Even running an antique build (1.2) on third-rate hardware, it hasn't crashed on me once.
Give me higher specs and a US release and I'll switch over permanently, not just when traveling.
Out of morbid curiosity, why do you think it's "unusable". (I can actually safely switch tasks and close apps in FXOS, which Android still hasn't quite worked out. It's always a gamble on Android. Will my app stay up while I check this notification or will it close? Is it worth the risk? That alone makes it more usable than Android.)
1: If an accurate simulation of the process of compiled imperative code is pedagogically unsound
No. Setting students up for failure is pedagogically unsound. Don't twist things; that's not productive.
Surely then the pedagogically sound way to learn about coding is top-down -- starting with declarative languages, then working our way closer to the metal, naturally bringing in procedural languages.
What did I say about twisting things? Pedagogy is about process, not content. (Otherwise, some subjects would be unteachable!) Further, I don't think you understand top-down design, or you're being purposefully obtuse.
Moving on: There's a reason that imperative languages dominate the landscape -- other paradigms are just more difficult (for beginners and professionals alike). You could start kids off with a functional language, concatenation language, or a declarative language, though you'd be doing them a disservice. Kids already know how to give instructions, which is what imperative programming is all about! It's incredibly simple, and very easy to understand.
We develop and use programming languages for a single reason: to make programming easier. Have you ever tried to do anything non-trivial in a declarative language? It's a nightmare. Worse, the resulting code looks suspiciously imperative! (First, get the computer to give you x and y from z. From z you can then get it to give you a and b. From a and b, you can get the computer to give you c, the thing want you wanted in the first place.) This could be a weakness of declarative programming, or just a sign that imperative programming is more natural. Either way, it's pretty obvious that declarative programming, outside a few narrow domains, does not succeed in that singular goal of making programming simpler.
As you're probably painfully aware, declarative programming has been an absolute failure for general purpose computing. If it were truly more natural, as you say, shouldn't declarative languages be dominant?
You're too short-sighted. There are positives for you as well, not just the developing world.
See, Mozilla is pushing an open standard app package that other platforms can implement, built completely on existing open standards. That means easy cross-platform mobile apps additional distribution options for developers, For smaller platforms, it means a ready-set of apps for their new platform before launch. Competition in the mobile space for consumers!
FirefoxOS is one the most important projects I've seen since ... well ... Firefox.
Why anyone would want it to fail, or spread FUD this this, is beyond me.
and since conversation is considered AI-hard,
That's the point in dispute. I'm not sure anyone seriously considers it part of "Hard-AI" these days, the laity excluded, of course.
So where do I publish a refutation of Searle? I had one on the web once.
In a reputable journal, of course!
I presume you found a way to take down the claim "syntax, by itself, is neither constitutive of nor sufficient for semantics". It's the very core of the argument and I can't see any refutation that doesn't address this point being very strong at all. If you can knock that pillar down, you'll have changed the world. The implications would be far-reaching.
I'd love to hear it.
Then you weren't doing it right. The whole point of the exercise is for them to get it wrong.
But that's not pedagogically sound. The first rule: don't set them up for failure. The point of the exercise is to show them that they already have some of the necessary skills, and to foreshadow future topics.
Your job is to take the slightest ambiguity and do it wrong.
You actually ... make the sandwich?
We do this because humans think declaratively.
That's a bit of a stretch, isn't it? You always start with 'what' before the 'how'. It's why top-down design has been such a useful and successful approach. (You even hint at that in the sandwich example with the need for further refinement.)
Ask a 4-year-old to tie their shoes (the what) and there's a good chance you'll hear them say "I don't know how". Given them a complicated toy and they'll quickly rush back to you with a "How do I make it do ..." Even very young children seek out procedures. Dare I say, it's natural...
Even in the example that started this, you still include the "how" (as you can see by comparison to the C# and loop examples) it's just not in sequence and includes less information useful to the reader. (Hence, it's less readable.)
Use < and > <See how easy it is?> You can blame Slashdot for a lot of things, but you've been here too long to blame them for that.
I think that it's a worthwhile challenge to contribute to the FirefoxOS platform and/or to build apps for it.
Hear, hear! I've released one myself early last year. I wish I had more time for it as it's such an important platform to support.
I love the idea of an app package that you can use on other platforms. The mobile market has needed that for a long time now. If other vendors will support their app packages (as Mozilla intends) that would a massive win for consumers. BlackBerry already supports Android apps, and has the best mobile browser on the market; it shouldn't be a stretch for them. Microsoft, well, they just need apps, not unlike any future players in the mobile market.
This is encouraging, but not quite what I was hoping to see on Android
They shuffled menu items around.
The horror! I didn't actually notice any changes, but when I do I'll be sure to rant about that deal-breaking change!
They deleted the status bar which showed you the full URL when you hovered over it.
Terrible, isn't it? Now it only shows the full URL when you hover over ... ummm.... er ... to hell with them!
They came out with FireFox 29 which is a UI abomination.
I know, it's crazy! The last thing users want is a simple interface they can completely customize to satisfy their wants and needs.
The only thing worse than being stuck on an airplane someone talking to someone on their phone: being stuck next to someone talking to no one on their phone.
(You just know that they only do that in public.)
Perhaps he has a phone with a proper keyboard? Possibly with a slick trackpad or (real) stylus for positioning the cursor?
I know, useful tools aren't 'cool' these days...
When people like you incorrectly claim that Firefox doesn't suffer from awful performance or excessive memory usage, the rest of us who have experienced these problems know you're wrong.
FF does periodically hang on me for a few seconds to a minute, though that seems limited to just my laptop. It never happens on my wife's computer, my work desktop, or any of the computers at the lab.
Otherwise, performance seems to be more than acceptable. That is, I haven't been tempted to move back to Chrome. (Now, on old machines still running XP, the difference is night and day. Chrome is basically unusable, while FF works just fine. What I find baffling, of course, is that the reverse used to be true!)
The memory leak? It simply doesn't exist. (The original memory "leak", that started this nonsense meme, turned out to be a myth. It never actually existed.*) It's still not true today.** Of course, people still complain about it. I presume its because they either don't know what a memory leak is or just assume that "it" still exists and want to, as the AC so eloquently put it "bitch and moan". Today, it actually uses less memory than Chrome.
Chrome, incidentally, has had more than its fair-share of reported memory leaks and performance issues lately. They just don't have a meme inspired by a myth to go along with it.
But, hey, I like Australis, so nothing I say counts.
* Setting browser.sessionhistory.max_total_viewers to 0 magically made the alleged leak vanish. Can you guess why?
** There were a couple of actual serious leaks a few years back, but they were quickly fixed.
Ah, I guess I wasn't terrible clear. I mean the test is meaningless as it gains us nothing, regardless of the results. It doesn't matter if users here "don't understand it" or their variations are uncomfortably off from the originals. They can be as wrong as they want and yet, like the originals, still not address the question in any way.
As to the question itself, I'll decline to comment.
often with sophistry and fallacies included in the arguments (cf. Searle)
I'm curious, did you actually find an issue with Searle's argument? You should publish it. You'll be quite famous.
Only if you define "thinking" as something that only a living being is capable of.
No.
Now, go play. The grown-ups are talking.
If I can cut to the core of your argument:
Humans don't think procedurally
That's ridiculous. Of course humans think procedurally. Don't know how to do something? Here's this step-by-step procedure! If you ask how to bake cookies or change your spark plugs, you'll find (and expect) that you're provided a handy list of steps.
Just think of the classic "peanut-butter and jelly" demonstration of trying to tell someone how to make a sandwich procedurally -- it's really hard, and even many programmers can't do it right first try.
I've used that and similar problems when teaching kids how to program. Not a single child has failed to get it right on the first try. Have you really seen someone fail at this? Were they conscious?
(Just thinking about it, that's often how kids explain things to you when they're proud of some accomplishment. "I did x! ... First I ... then I ... ")
So, without providing a list of steps, can you explain to me how to make a peanut-butter and jelly sandwich? Surely, there's a much more natural way to communicate that knowledge, yes?
Does it really matter? Turing's test is completely meaningless, both in his original proposed forms and the zillions of variations imagined by Slashdot users, as far as answering the essential question "Can machines think?" is concerned. No matter how you vary the test, it's fundamentally unsound. (As you're probably well-aware, this has been discussed to death in the literature.)
It's been dead so long you might as well be arguing a subtle point about phrenology. Is it really worth the effort?
The more experience you have, the easier this becomes, but it is still a more difficult cognitive task than reading a single statement.
my_list = [ x*x for x in input_list if x > 0 ]
my_list = [] for x in list : if x>0 : my_list.append(x*x)
I strongly disagree. As you said: "you still need to break it down" which, adds to the cognitive load. The for loop is not only neatly broken down for you, but includes additional information to help you understand each part and the relationships between each part.
Further, the components themselves are also "in order" making it read more "naturally". The order in the list comprehension example might as well be completely random. Consider the same example using list comprehensions in C#:
my_list = from x in list where x > 0 select x*x;
This is dramatically more readable than the Python example simply because those imperatives of imperative programming (direct sequencing, conditional branching, bounded iteration, and conditional iteration) are still applicable. It's almost as readable as a for loop, though it still requires special/uncommon knowledge; just far less than in the Python example.
I suppose it doesn't really matter how much better or worse than other languages handle them. In every case that I'm familiar, they add complexity (without also adding value, an unforgivable sin). Complexity, naturally, harms readability.