Hacker News Reader

Comment by jrajav | Hacker News Reader

Unfortunately there is no if-expression in JS so sometimes it's awkward _not_ to use ternaries in multi-line statements - for instance, when writing in an expression only context like a string interpolation or JSX. It's also just annoying to not be able to assign conditionally without using it, instead of a more clear and readable if/else. It's one of the more annoying nits of the Algol legacy.

Oh, but fully agreed, nested ternaries is right out. In fact, usually in those other cases too, it's just annoying that there's not a good alternative.

View on HN

If you want the equivalent of if-expression in JS, I think it is much better to make a separate function with a number of returns. In this case the function is already there:

  function deriv(exp, variable) {
    if (is_number(exp)) {
      return 0;
    }
    if (is_variable(exp)) {
      if (is_same_variable(exp, variable)) {
        return 1;
      } else {
        return 0;
      }
    }
    if (is_sum(exp)) {
      return make_sum(deriv(addend(exp), variable),
          deriv(augend(exp), variable));
    }
    if (is_product(exp)) {
      return make_product(deriv(multiplier(exp),
              variable),
          multiplicand(exp)))
    }
    return error(exp, "unknown expression type -- deriv");
  }

Get rid of the else in the is_variable(exp) block and this is a lot more readable than the nested ternary version and seems just as easy to transcode from Scheme. Darn.

It's subjective, but seconded (switch statements are also great for this because they make fall-through logic more obvious).

I'll add a couple of things onto this: early returns are very helpful for me in avoiding nesting if statements (although that's less applicable in this specific example).

  function op(cond) {
    if (cond) {
      //do something
    }
  }

  function op (cond) {
    if (!cond) { return; }
    //do something
  }

And it's good to remember that you can basically stick functions anywhere including inline, so it's not necessarily a requirement to take a function like this and move it to a top level as a private function. If you're only using it in one place you can just define it and call it anonymously.

And don't be afraid to still use ternary operators non-nested. There's a sibling comment complaining about the nested if statement. If that really bothers you, you can still do:

   if (is_variable(exp)) {
      return is_same_variable(exp, variable) ? 1 : 0;
   }

Refreshing to see some love for early return. Often people like to say they are an anti pattern, but then you have to maintain each layer of if nesting in your head (as they are sometimes off screen) when reasoning about code in the middle instead of handling edge cases first and leaving the rest of the method for the core/common case.

  if (is_same_variable(exp, variable)) {
    return 1;
  } else {
    return 0;
  }

should be

   return +is_same_variable(exp, variable)

Yeah, though might want to use Number(is_same_variable(..)) for additional clarity.

Which is one of the reasons why it's difficult to interpret javascript as suitably functional to apply SICP to it.

"Languages do not differ in what they make possible, but in what they make easy."

Or use a switch statement?

There's something satisfying about converting if/else tables to switch statements. I find them so much more readable.

a function _if(cond, a, b) would probably have been better.

Beat me to it :)

It's not the biggest thing in the world, and I don't want to distract from the rest of the book, but this is a situation where writing a one or two line helper function:

  const _ = (cond, a, b) => cond ? a : b;

would have made the code much more readable without much downside that I can see -- at least to my subjective opinion. Maybe I'm missing something.

Edit: comment below correctly points out that if it's important for you to avoid immediate evaluation, you'll need to wrap your conditionals in functions.

JS is not lazily evaluated so that means `a` and `b` would both be evaluated regardless of the result of the cond expression. To make a proper version you have to complicate things by calling it like this:

  _(cond, () => a, () => b)

And _ becomes:

  const _ = (cond, a, b) => cond? a(): b();

And it does matter in this case when looking at the last condition which signals an error (does not return an error value if I understand it correctly). In which case your _ would raise an error even when not appropriate.

That is an excellent point, thanks for pointing that out.

I'm not sure it matters here, the error you're pointing out looks to be getting returned (unless I'm misunderstanding what the book intends the `error` function to do), and creating an Error in Javascript is fine, it doesn't break your program until it's actually thrown.

Edit: just looked at your comment again, and you're saying it does actually throw the error rather than returning it :) So double-corrected on my part :)

But your point stands regardless. There will be scenarios where what you're talking about matters -- JSX also follows this pattern of immediate evaluation and yeah, I see errors from that plenty of times. So it's good to mention.

There is an example in the book showing why this would not work, in short it is because js is not lazy

Reply on news.ycombinator.com