Hacker News Reader

Comment by akavi | Hacker News Reader

The tragedy of JS if blocks being statements not expressions is made explicit here

There was a library adding macros to JS that was a thing long ago. I always thought that `cond` would make JSX way better, though JS + macros sounds terrifying in general.

Code example below, `cond` is an example in their tutorial: https://www.sweetjs.org/doc/tutorial.html#sweet-cond

    let realTypeof = cond {
      case x === null: 'null'
      case Array.isArray(x): 'array'
      case typeof x === 'object': 'object'
      default: typeof x
    }

Discussed in 2017 on HN: https://news.ycombinator.com/item?id=14695495

What's wrong with ternary?

Nothing but when you nest them a whole bunch they are far harder to read and understand that if/else.

I frankly find it hard to imagine an expression form of if...else that's more readable than either the JS or Scheme versions of the code.

In fact, I believe the problem with the JS example's readability is the formatting. Here's how I'd format the same code, and I find this quite readable:

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

Scala-style if expressions would be significatly more readable IMO (particularly if you also had the feature of allowing a block to be used as an expression).

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

Just for looksies.

    function deriv(exp,v){
      //v = variable;
      if(is_number(exp) ){ return 0 }
      if(is_variable(exp){ return is_same_variable(exp,v) * 1 }
      if(is_sum(exp)){ 
         a = deriv(addend(exp),v);
         return make_sum(a,a)
      }
      if(is_product(exp)){
         m = multiplier(exp);
         c = multiplicand(exp); 
         a = make_product(m,deriv(c,v));
         b = make_product(deriv(m,v),c));
         return make_sum(a,b)
      }
      return error(exp, "unknown expression type -- deriv");
    }

I'd possibly make it even more syntactically simple by removing the braces for one-line if statements. I know this can be a bit controversial, but for cases like this where the block consists only of a return statement, and where that statement fits on a single line (and where you have a formatter and a linter that will prevent you from writing indentation that doesn't match the semantics), it's very useful for removing visual clutter.

That said, this is pretty much how I'd write it, and seems a lot simpler than the heavily nested ternary (and I say that as a fan of nested ternaries!)

The 0 and 1 are completely unnecessary though in some of these.

Example

is_same_variable(exp, variable) ? 1 : 0

If is_same_variable returns a truthy value then return 1 else 0.

We can remove that and it will still follow the same while also being more readable

It’s calculating the derivative. 0 and 1 aren’t used for their truthiness, but as values. d/dx x becomes 1 and d/dx y becomes 0 (the two cases, same variable and different variable).

JavaScript will coerc the types. 1+1 and true+true both = 2

So you've gone from "nested ternary is hard to read" to "This is an introductory text, let's mix arithmetic with numbers and booleans by using true and false for 1 and 0"? That's a remarkable turn in just a few comments toward the side of obfuscation.

I'm not trying to change the code, I'm only formatting it.

(is(((it any) harder than) this?))

You'd be surprised at how readable Lisp is for people who actually learn it instead of just saying "look, weird language ha-ha!"

Yes, since Lisp isn't hard to read.

They are, but you use ?-: instead of if-else

That still doesn't make all blocks expressions.

In f# everything is an expression and it simplifies the language a lot. The last value in a block is considered the value "return" value of the whole block, which has the knockon effect of getting rid of most returns, allows you to check an if/else to return the same type and such. This also works in conjunction with the type inference, so you get an error when you try to return a string in one branch and an int in another.

I understand. Scala is the same.

JavaScript has a limited form of that via the comma operator.

Reply on news.ycombinator.com