← Back to context

Comment by cupofjoakim

5 hours ago

Interesting. there are some parts i like a lot here, but two things that I really dislike syntax wise. One is the lean towards a chainable syntax - this has proven to a big footgun for many devs in both java streams and typescript, making it very easy to go from O(n) to O(2n). The other part i really dislike is the first argument principle noted. If i myself define `string_and_reverse` and I can call it both through `string_and_reverse(42)` and `42.string_and_reverse()` i could definitely see this leading to some very funky looking chaining.

Perhaps it's just one point from me - not liking chaining :D

> i could definitely see this leading to some very funky looking chaining.

At least for me,

  thing
    .doThis()
    .thenDoThat()
    .andFinallyThis()

is much more readable than

  andFinallyThis(
    thenDoThat(
      doThis(thing)
    )
  )

  • Well, nesting is not the only option.

    ``` thing.doThis() thing.thenDoThat() thing.andFinallyThis()

    // or

    doThis(thing) thenDoThat(thing) andFinallyThis(thing) ```

> making it very easy to go from O(n) to O(2n)

Strictly speaking I assume everyone knows O(n) = O(2n) =O(kn) for k in R.

But I see your point. I assume any decent compiler would merge the loops though

  • Fair! That'd depend on the operations right? For example, AFAIK typescript can't do much about multiple chained `map` calls, and i've seen quite a few `.filter(...).map(...).filter(Boolean).map(...)` :/

    • To be fair this likely should be handled by the interpreter/compiler for the compiled JS. V8 probably can merge this into one loop or another similar based on runtime types

  • what if k = n

    • Then either n is a constant and it's really O(1), or k isn't a constant and its naming was in violation of the International Conventions on Naming Things to Avoid Silly Arguments, section 3, paragraph IV.7 & ff.