On: CoffeeScript for TypeScript

[justsomeuser]

Under "Everything is an Expression":

        items = (() => {
          const results = [];
          for (const item of items) {
            if (item.length) {
              results.push(item.toUpperCase());
            } else {
              results.push("<empty>");
            }
          }
          return results;
        })();

Seems like they are purposely making the JS version extra long. It could be:

        items = items.map(x => x.length > 0 ? x.toUpperCase() : `<empty>`)

Edit: Just realised the code on the right is the compiled code, not the "equivalent hand written JS".

[8f2ab37a-ed6c → justsomeuser]

My kingdom for "everything is an expression" in JS/TS, but that would likely require an entirely new language.

[eyelidlessness → 8f2ab37a-ed6c]

If you’re willing to accept a little bit of extra syntax/ceremony, the `do` expressions proposal[1] is pretty much this (but it’s only stage 1 so who knows when/if it’ll land).

1: https://github.com/tc39/proposal-do-expressions

[Yahivin → eyelidlessness]

We often add promising TC39 proposals into Civet so people can experiment without waiting.

We've added https://github.com/tc39/proposal-pipeline-operator, a variant of https://github.com/tc39/proposal-pattern-matching, a variant of https://github.com/tc39/proposal-string-dedent and others.

Since our goal is to be 99% compatible with ES we'll need to accommodate any proposals that become standard and pick up anything TC39 leaves on the table (rest parameters in any position, etc.)

[8f2ab37a-ed6c → eyelidlessness]

Nice! Wasn't aware of that at all.

[davedx → 8f2ab37a-ed6c]

At some point you might as well just use lisp, right? :D

[eyelidlessness → davedx]

I love me some lisp, but I definitely prefer my JS-hosted code to be as close to JS language and semantics as possible (and that’s after a few years working in ClojureScript). Then again I’m commenting in a thread about an article with CoffeeScript in the title so I’m probably the weird one here.

[slifin → eyelidlessness]

Have you considered https://github.com/squint-cljs/squint ?

Personally I couldn't let go of Clojure's other advantages but at least using the syntax would let you step off the syntax churn bus

[eyelidlessness → slifin]

No, unfortunately the greener pastures I found have type annotations. I miss the parentheses like hell, and I miss the actual state semantics of Clojure even more. But I wouldn’t give up static types for any of that. If I explore lisps again I’m going to start with Typed Racket.

[mattigames → justsomeuser]

Given than in JS an empty string is a falsy value you can go even shorter:

     items = items.map(x => x.toUpperCase() || `<empty>`)

[chii → mattigames]

The original ternary "fixes" the cases where `x` is "wrong" (e.g., is not a string - `x.length` does not fail, but evaluates to false, and thus you still get `<empty>`).

This even more terser code will fail if `x.toUpperCase()` fails with an exception (such as when x is not a string).

[mattigames → chii]

Given the example I think it is reasonable to assume it is always an string; otherwise if there is any possibility that x is not a string you can just use optional chaining:

     items = items.map(x => x?.toUpperCase() || `<empty>`)

See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[chii → mattigames]

Good point. I often forget that there's option chaining in javascript (now-a-days).

[root_axis → justsomeuser]

Your version doesn't correspond to the code written on the left side.

[justsomeuser → root_axis]

You are right, I did not realise it was the compiled code.

I thought it was the comparable hand written JS.