[HN Gopher] Unravelling 'if' statements
___________________________________________________________________
Unravelling 'if' statements
Author : azhenley
Score : 17 points
Date : 2022-10-31 19:05 UTC (3 hours ago)
(HTM) web link (snarky.ca)
(TXT) w3m dump (snarky.ca)
| gumby wrote:
| The real brain damage in most programming syntax is the
| distinction between expressions and statements. Expressions are
| all you need.
| ChadNauseam wrote:
| My favorite thing about rust is how it encourages you to keep
| `return` at the end of your function. `return` is one of the
| most annoying syntax elements to me because you mostly don't
| need it, and it kind of has "side effects" in a way that's not
| obviously visible in the structure of the function.
| throwaway2j94 wrote:
| They are expressions in rust fn main() {
| let () = return (); }
| moffkalast wrote:
| Seems weird to replace an if sentence with a while, since a while
| is just an if with two gotos isn't it?
| twawaaay wrote:
| For some strange reason there exists a subpopulation of
| developers who hate goto/if/switch etc. statements and feel
| compulsion to replace it with an equivalent solution that does
| not use goto/if/switch even if this is done at the cost of
| readability.
|
| They red somewhere that goto/if/switch is bad and now
| mistakenly think if they only get rid of it their code will
| somehow be better. Which is sad and led to a lot of wasted time
| on my part trying to untangle their mess.
| Wowfunhappy wrote:
| Wait. We're putting `if` in the same category as `goto`?
|
| I understand the problems with `goto`, but I'd never heard a
| case against `if` before.
| jemmyw wrote:
| I don't have an aversion to if statements per se, but there's
| a logic to wanting to not over-use them or keep them out of
| code if possible: every code branch requires more work to
| unit test it. However, if you can restructure such that
| instead of using an `if`/branching you instead use whatever
| higher level structures the language provides then you only
| need to test the way it selects code to run is correct rather
| than multiple branches.
| throwaway2j94 wrote:
| goto/if/switch have their uses (especially in C) but I
| consider them low level and deprecated in favor of pattern
| matching, expression-based loops, and fmap / map/reduce
| combinators.
| ok_dad wrote:
| > 2022: "If/else considered dangerous."
|
| I never thought this would happen, does this mean I should
| quit programming? I feel like you can't get much done in a
| computer without branching in a CPU, but maybe I
| misunderstand modern CPU architecture.
| lmm wrote:
| > I never thought this would happen, does this mean I
| should quit programming?
|
| Yes.
|
| > I feel like you can't get much done in a computer
| without branching in a CPU, but maybe I misunderstand
| modern CPU architecture.
|
| Most CPUs have jump instructions, that doesn't mean it's
| a good idea to have gotos in your programming language.
| moffkalast wrote:
| Nah, if I understand the guy correctly it's not about the
| low level stuff. That's hardly going to change any time
| soon.
|
| But in terms of a logic development perspective I guess
| it may be clearer to set up something like instead of
| your average while(true) if (boolean) callback_function()
| put an async on(boolean,callback_function) or something
| and let the language deal with the low level
| implementation of it. Not sure why it would be
| "dangerous" to use the explicit definition, but we can
| maybe do a bit better in terms of clarity by removing the
| optimizable boilerplate?
| twawaaay wrote:
| Of course, I do prefer higher level constructs. Even then
| goto/if/switch are effective, readable solution especially
| if you use them within idioms.
|
| The problem is when people start replacing low level
| statements with other low level equivalents. Or low level
| equivalents that are masquerading as high level. Which
| means they did not understand why you may want to get rid
| of the low level construct and only caused loss of
| readability for no structural benefit.
| the_gastropod wrote:
| (Note: I don't think an aversion to `if` statements is the
| motivation behind the blog post here. Seems more an
| exploration into the minimum feature set needed in Python)
|
| If people are removing if statements at the cost of
| readability, I think they're probably bad candidates for
| replacement. The reason for removing if statements is
| (especially when deeply nested), they're _very_ hard to
| reason about and test. Untangling these things (e.g.,
| polymorphism) is intended to improve readability /
| understandability / ability to be changed. Everything in
| software engineering is a compromise--sometimes a simple if
| statement is a lot clearer than introducing polymorphism
| unnecessarily. Each case will vary.
| lmm wrote:
| I'll take a function that looks and acts like you'd expect
| over a magical keyword any day. Code that behaves
| consistently is worth a bit of overhead; it costs some
| readability in the small, but it more than makes up for it in
| the large.
| benj111 wrote:
| 2 gotos? While: If X Stuff
| Goto while. //Outside of while statement
| [deleted]
| faho wrote:
| The idea behind this series of posts is to see how much of
| _python_ , concretely, is syntactic sugar and how much is
| necessary. How much could you do with e.g. doing macro
| transformation on top of a minimal core?
|
| The last post before this was titled: "MVPy: Minimum Viable
| Python".
|
| So, since python doesn't _have_ goto, you can 't replace while
| with an if with two gotos (without adding a goto to the
| language).
|
| You can replace an `if` with a while tho, easily.
| moffkalast wrote:
| Tbf python isn't exactly a language that's high in sugar to
| start with, it doesn't even have switch statements. Not sure
| why you'd want to take away even more until there's nothing
| usable left. People have the weirdest hobbies hah
| milliams wrote:
| No, but it has the `match` statement which is even better:
| https://docs.python.org/3/whatsnew/3.10.html#pep-634-struct
| u...
| moffkalast wrote:
| I wouldn't exactly call something only available in 3.10
| as something python "has". Most of us haven't moved past
| like 3.8 at best, some still using 2.7 for legacy stuff
| even.
| rgmerk wrote:
| Waiting for the solution that involves transforming Python
| code into an encoded Turing machine and implements a minimal
| UTM in some tiny subset of Python.
___________________________________________________________________
(page generated 2022-10-31 23:01 UTC)