Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

No ifs...alternatives to statement branching in JavaScript

javascriptweblog.wordpress.com

Post reply on HN
Print view View original

21–30 of 45 posts

Re: No ifs...alternatives to statement branching in JavaScript

#21

Post by ori_b »

BoppreH wrote: post #6

I'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…

This isn't a functional technique! Functional languages remove assignments and mutable variables. Not branches.

Re: No ifs...alternatives to statement branching in JavaScript

#22

Post by thienan »

lygaret wrote: post #13
planckscnst wrote: post #11

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.

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.

Thanks

Re: No ifs...alternatives to statement branching in JavaScript

#23

Post by BoppreH »

ori_b wrote: post #21
BoppreH wrote: post #6

I'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…

This isn't a functional technique! Functional languages remove assignments and mutable variables. Not branches.

Branches too. The only conditionals I've seen in functional programming are equivalent to the ternary operator.

Unless I'm absurdly wrong, which can happen.

Re: No ifs...alternatives to statement branching in JavaScript

#24

Post by RodgerTheGreat »

planckscnst wrote: post #11

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.

I think you're confusing lazy evaluation with operator short-circuiting. (http://en.wikipedia.org/wiki/Short-circuit_evaluation)

Re: No ifs...alternatives to statement branching in JavaScript

#25

Post by JadeNB »

_delirium wrote: post #14
alexfarran wrote: post #3

Earlier quoted context omitted.

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) You can't apply a boolean operator to an event! And even if you could, the result would always be a boolean. I associate this most commonly with…

> evt && (evt.target || evt.srcElement)

It's certainly true that this isn't well typed (not to mention not valid Haskell, since the . is used for namespacing, not access to member variables), but there's no reason that one couldn't do something conceptually similar:

    class Boolable a where
        toBool :: a -> Bool
        (&&)   :: a -> a -> a
        (||)   :: a -> a -> a

        a && b = if (toBool a) then b else a
        a || b = if (toBool a) then a else b

    instance Boolable Int where
        toBool 0 = False
        toBool _ = True
I don't know how idiomatic this is, but it works. One can see that it really is short-circuiting:

    > :l Boolable
    [1 of 1] Compiling Main             ( Boolable.hs, interpreted )
    Ok, modules loaded: Main.
    > 1 Main.|| undefined :: Int
    1
    > 1 Main.&& undefined :: Int
    *** Exception: Prelude.undefined
I don't know Haskell well enough to know why the `:: Int` on the end is needed, but I'm sure that that, too, can be worked around.

Re: No ifs...alternatives to statement branching in JavaScript

#26

Post by davidw »

BoppreH wrote: post #23
ori_b wrote: post #21

Earlier quoted context omitted.

This isn't a functional technique! Functional languages remove assignments and mutable variables. Not branches.

Branches too. The only conditionals I've seen in functional programming are equivalent to the ternary operator. Unless I'm absurdly wrong, which can happen.

The program still branches (decides which code path to follow) - it just does it with a different mechanism, for instance pattern matching.

Re: No ifs...alternatives to statement branching in JavaScript

#27

Post by jasonkester »

"That's very clever."

The above quote comes from the smartest developer I've ever known, talking about a piece of code I had written that I was just as proud of as this guy is of his ifless branching. It took a minute to sink in that "clever" is not a term you want people using to describe your code.

As a developer, the first time you're going to encounter any piece of code is when FireBug drops you into it with an exception. Personally, I'd prefer to look at a single line that does a single thing.

For any non-trivial implementation of the author's chained implicit conditional logic, a null reference exception will leave you looking at a single line with a half dozen candidates for what might actually be throwing.

Please please please don't make a habit of coding like this for anything but the most trivial cases.

Re: No ifs...alternatives to statement branching in JavaScript

#28

Post by Confusion »

geuis wrote: post #5
telemachos wrote: post #4

Dislike 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've been doing this long enough that its is easier,
  clearer, and faster for me to understand
However, are you also the only one reading the code? If not: is it also easier, clearer and faster to understand for the other ones? On the one hand, they may learn fast when reading code that uses these constructions. On the other hand: perhaps it only sinks in over time and they won't learn fast enough to properly maintain such code.

Re: No ifs...alternatives to statement branching in JavaScript

#29

Post by ori_b »

BoppreH wrote: post #23
ori_b wrote: post #21

Earlier quoted context omitted.

This isn't a functional technique! Functional languages remove assignments and mutable variables. Not branches.

Branches too. The only conditionals I've seen in functional programming are equivalent to the ternary operator. Unless I'm absurdly wrong, which can happen.

I think codesearch can answer you: http://www.google.com/codesearch?q=if+lang%3Ahaskell

Re: No ifs...alternatives to statement branching in JavaScript

#30

Post by gruseom »

scott_s wrote: post #16
telemachos wrote: post #4

Dislike 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…

But that crashes on null in all three languages, no? (i.e. if evt is null and window.event is non-null.) I suppose you could do this:

  function getEventTarget(evt) {
    return (evt || (evt = window.event)) && (evt.target || evt.srcElement);
  }
But that's probably more trouble than it's worth. Anyway, I agree with you in preferring expressions to statements on the whole. It's hard to imagine why anyone would prefer the more than 4x as long version in the OP; to me it reads like a parody.
Post reply on HN