Doesn't this depend on strict lazy evaluation? I could imagine if the implementation underneath changed (possibly to take advantage of parallel execution), if any segment had side effects, it would be horrible.
No ifs...alternatives to statement branching in JavaScript
11–20 of 45 posts
Re: No ifs...alternatives to statement branching in JavaScript
#12Dislike of if confuses me. People claim to find conditions wordy or confusing. I don't find conditions particularly difficult to follow, but I have a question from the other side: when you use && and || as logic gates, don't you (in your mind) translate them back into conditions anyhow? Here's his first example without if: function getEventTarget(evt) { evt = evt || window.event; return evt && (evt.target || evt.srcE…
Look at it like this. I am a developer who prefers the terse code compared to the longer if() variety. I've been doing this long enough that its is easier, clearer, and faster for me to understand the "evt = evt || window.event" than it is to trace through all of those if() statements. I used to be the opposite, I couldn't understand the short form or how it worked. Ternaries confused the hell out of me for a while.…
I agree that in some cases, guards, defaults and ternaries flow more naturally.
However, I feel that there's a contradiction. You say that it is easier to understand but have learned to write them in plain old "if" first because it's better. It's easier to get it wrong if you write it shorthand.
If it's better to start writing them in "if", doesn't that mean it's easier to understand? If it is easier to use guards, defaults, and ternaries, you shouldn't have to resort to plain "if" to get the logic right.
And I agree, DOCUMENT!
Re: No ifs...alternatives to statement branching in JavaScript
#13Doesn't this depend on strict lazy evaluation? I could imagine if the implementation underneath changed (possibly to take advantage of parallel execution), if any segment had side effects, it would be horrible.
I can't think of a case where lazy evaluation would be required, only that the semantics of the && and || operators not change.
It's defined as part of the language that && will not evaluate the right hand side unless the left hand side is truthy. A lot more than using this stuff as branching would break if some implementation arbitrarily decided to not follow that anymore.
Re: No ifs...alternatives to statement branching in JavaScript
#14One of the things I love about Google's Closure Compiler is that it takes care of these optimizations for you. If you want, you can write in an explicit readable style and still get any performance benefits.
But these are not performance optimisations. Angus is making the case that functional techniques can be more concise and readable than procedural style control flow.
Are short-circuiting boolean operators as conditional-plus-result-rolled-together really a functional technique? Certainly in strongly typed functional languages like Haskell they're impossible, because his example isn't even well-typed:
evt && (evt.target || evt.srcElement)
Even in Lisp, where you can write like that, it's much more idiomatic to use the if or cond forms, which is more morally equivalent to C's ternary conditional than to short-circuiting booleans.
Re: No ifs...alternatives to statement branching in JavaScript
#15From the title, I was expecting something interesting like "SubText", or at least some kind of talk about dispatch :) Using &&, || etc gets you terse code, but the branching that you mentally work out is exactly the same.
.. unless you use the && and || so much that you end up chunking out specific patterns of usage without having to explicitly think about the branching.
.. which you can do with if as well.
Re: No ifs...alternatives to statement branching in JavaScript
#16Dislike of if confuses me. People claim to find conditions wordy or confusing. I don't find conditions particularly difficult to follow, but I have a question from the other side: when you use && and || as logic gates, don't you (in your mind) translate them back into conditions anyhow? Here's his first example without if: function getEventTarget(evt) { evt = evt || window.event; return evt && (evt.target || evt.srcE…
Simply, no. I prefer to think in boolean expressions rather than sequences of statements. Personally, I'd further reduce it to (assuming there's no JavaScript subtleties I'm missing here; in C/C++ this would have the same semantics):
function getEventTarget(evt) {
return (evt || window.event) && (evt.target || evt.srcElement);
}
Re: No ifs...alternatives to statement branching in JavaScript
#17Earlier quoted context omitted.
Look at it like this. I am a developer who prefers the terse code compared to the longer if() variety. I've been doing this long enough that its is easier, clearer, and faster for me to understand the "evt = evt || window.event" than it is to trace through all of those if() statements. I used to be the opposite, I couldn't understand the short form or how it worked. Ternaries confused the hell out of me for a while.…
I agree that in some cases, guards, defaults and ternaries flow more naturally. However, I feel that there's a contradiction. You say that it is easier to understand but have learned to write them in plain old "if" first because it's better. It's easier to get it wrong if you write it shorthand. If it's better to start writing them in "if", doesn't that mean it's easier to understand? If it is easier to use guards, d…
We sometimes use if-else statements to write out some straight-up logic because we don't understand it at first. So we build it from the ground up. If, after writing it all out with primitives, we realize "Oh, it's just this anded with this and ored with that" then we actually understand the problem.
Put another way: if you write a boolean expression as a sequence of statements, my assumption is you don't really understand what you're doing.
Re: No ifs...alternatives to statement branching in JavaScript
#18Dislike of if confuses me. People claim to find conditions wordy or confusing. I don't find conditions particularly difficult to follow, but I have a question from the other side: when you use && and || as logic gates, don't you (in your mind) translate them back into conditions anyhow? Here's his first example without if: function getEventTarget(evt) { evt = evt || window.event; return evt && (evt.target || evt.srcE…
Simply, no. I prefer to think in boolean expressions rather than sequences of statements. Personally, I'd further reduce it to (assuming there's no JavaScript subtleties I'm missing here; in C/C++ this would have the same semantics): function getEventTarget(evt) { return (evt || window.event) && (evt.target || evt.srcElement); } A boolean expression is straight-up math, and I've been trained to reason about that. Wit…
In the OP's example, evt will retain it's value if passed in as "truthy" or take on the value of window.event otherwise. The return then returns evt and evt.target or evt.srcElement which may from the original passed in evt or really from window.event, which was assigned to evt in the first line.
With your example, evt.target and evt.srcElement are only coming from the passed in evt which may have been passed in as "falsey" and would not take on the target or srcElement of window.event as intended.
I could be mistaken, it's late and I'm rusty. Anyone is free to correct me.
Re: No ifs...alternatives to statement branching in JavaScript
#19Write readable code for your source files and then compile with Google's closure compiler.
Re: No ifs...alternatives to statement branching in JavaScript
#20I'm a very young coder and loved the article, especially how it brings functional features to imperative languages. But what if I write the entire company framework without a single conditional (including loops)? Are this alternatives to be used sparingly or as much as possible? Would you frown upon when you see it? On a side note, I would love to never see a conditional again Even before learning functional programm…
What if you did? Would it be a better framework? Would anybody care at all? I doubt it. This a code style and if you like it, then maybe you use the parts you want. But "micro branching" is still branching and it makes little difference how you do it (except the nod to performance concerns towards the end). Thinking about code style and readability is useful and good, but this is by no means a common way to code. Bew…
It would not be for cleverness, much less for optimization (is it even faster?)
For some reason every time I see a condition I cringe mentally. There's something in a "for" loop that makes me uncomfortable and god, using "map", "filter" and micro branching would help a lot.
I'm just thinking of what I would like to see and checking it against the opinion of others.