Timeline for Why do some programming languages have break statements, but not higher-order break statements?
Current License: CC BY-SA 3.0
15 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Sep 16, 2014 at 10:59 | comment | added | ben rudgers |
@FlorianF Sure. So will while or until , and they will always place the conditional test in a syntactically determined location not an arbitrary one. The cleanup is still done by try...catch even in languages like Python that don't have break .
|
|
Sep 16, 2014 at 8:12 | comment | added | Florian F | A break within a try{...}finally{...} within a for loop will still run the finally block. Therefore, break is more than a jump. It is a clean exit from a block of code. (Or even simpler, it will release block-local variables). | |
Sep 15, 2014 at 22:01 | comment | added | ben rudgers |
@FlorianF I said "thin syntactic sugar". It was a remark on the degree of abstraction break provides. Even JMP , as an assembly language instruction is syntactic sugar for machine code (or perhaps a CISC bytecode running on a RISC processor). Programming languages don't contain magic beans. It's Domain Specific Languages all the way down until you get to flip-flops.
|
|
Sep 15, 2014 at 21:40 | comment | added | Florian F | "Syntactic sugar" is always used to downgrade some aspect of a language with no good reason. Why doesn't anyone complain that 'if' is syntactic sugar over a conditional JMP (shudder...) and 'while' is just syntactic sugar over a conditional JMP with another JMP going backwards (yikes)? | |
Sep 15, 2014 at 18:43 | history | edited | ben rudgers | CC BY-SA 3.0 |
deleted 5 characters in body
|
Sep 15, 2014 at 18:40 | comment | added | ben rudgers | The question references Python, if it were C or x86 assembly then the question would be incoherent. We're already talking about languages at a level of abstraction above that where flags and semaphores and pointer dereferences are consistent with the language design - we're outside the realm where "C in any language" is practical. | |
Sep 15, 2014 at 18:33 | history | edited | ben rudgers | CC BY-SA 3.0 |
added 1475 characters in body
|
Sep 15, 2014 at 18:05 | comment | added | amon |
Could you please back up the opinions expressed in this answer with objective facts or reliable sources? As it stands, another user could simply post a contradicting answer like “Using break clearly expresses programmer intent and is on a much higher level than goto . Setting boolean flags to break out of nested loops is far less clear than using a labeled break ”.
|
|
Sep 15, 2014 at 18:04 | comment | added | ben rudgers |
I was answering the question in the abstract so that someone googling might find a useful answer. Sure it's unfortunate that it doesn't make someone already inclined to express their intent using break happy. That's the price of a cup of coffee I suppose.
|
|
Sep 15, 2014 at 17:24 | comment | added | user7043 |
When I use break and continue , they express my intent just fine thankyouverymuch.
|
|
Sep 15, 2014 at 17:19 | history | edited | ben rudgers | CC BY-SA 3.0 |
deleted 124 characters in body
|
Sep 15, 2014 at 16:40 | comment | added | ben rudgers |
Python unlike many other languages, loves the idea of "one true way". In the rest of the world, things are not always so hard and fast. Even Code Complete admits as much. But it still recommends while and until as the best first approach. Then cond\case\switch . And only then, treating something as a corner case. Deeply nested if..then..else does not get much love. Socartes and 孔夫子 beat you to complaining about youth by 2.5 millennia. YMMV.
|
|
Sep 15, 2014 at 16:36 | comment | added | Robert Harvey |
It's a shame that, after all this time, some folks still think that deeply nested if/else statements are somehow clearer than a well-placed break or continue , or that a single point of exit is still preferable to a guard clause.
|
|
Sep 15, 2014 at 16:35 | review | First posts | |||
Sep 15, 2014 at 17:38 | |||||
Sep 15, 2014 at 16:34 | history | answered | ben rudgers | CC BY-SA 3.0 |