Trine – A utility library for functional programming in JavaScript (opens in new tab)

Let's say I make a new language called javascript++.

Instead of having `function` be a keyword, I chose `functioooooooooooooooooooooooooooon`. Based on their syntaxes, do you find one fundamentally better?

    let names = persons.map(p => p.name);

    var names = persons.map(function(p) { return p.name; });

    save(value)
      .then(result => this.update(result))
      .catch(err => Application.showError(err, "Could not save."))

Your setInterval example is a somewhat inappropriate example of the usefulness of arrows as it doesn't take any arguments and doesn't return anything (so you didn't need the braces).

But the fact that you have to alias "this" is a big argument in favour of arrow syntax. It may be trivial in a small example, but it's not trivial when extended to an entire app. You'll pretty much end up aliasing "this" in every single method. If you change any logic around, you'll end up having to either add new aliasing, or chase down unused alias variables, just to add/remove closures. (And what do you call that variable? Is it "this_" or "_this" or "self"? When working on a team you'll have to agree on a convention if the code is to remain readable.)

However, in my opinion, repeating this many many times throughout a codebase is irritating to write, and adds extra weight and bug surface area to the code.

Therefore adding some syntax sugar to remove the need to do this, i.e. the first example, is a nice feature. I know opinions on syntax and formatting are pointless and endless, but could you please explain why, for you, is it less legible? Once you're used to it, don't you just scan () => as no-arg anon function signature the same way you scan function() as that now?

  function Person() {
  	this.age = 0;
  	setInterval(this.incAge, 1000, this);
  }
  Person.prototype.incAge = function personIncAge(that) {
  	that.age += 1;
  };

You don't know how much you're missing here. I wish that ECMAScript* considers adding support for "indented syntax" like in Sass to make it even more easier to read and go through the codebase without seeing all these ugly braces around.

*: or a white knight programmer volunteering to offer this functionality for us all :)

items .filter(isOk) .map(toOtherType) ::flatten()

In C# that sort of case is primarily handled by extension methods. They have their issues not least in terms of collisions, but to me they are a beautiful solution. The equivalent in JS would seem to be the always unpopular choice of adding these methods to the prototype, and as with extension methods you'd want the user to opt-in to their addition (possibly at object level here?).

Not sure though, maybe I've missed something.

The best answer to this seems to be simply:

    var sum = ls => ls.reduce(add, 0)

    var currentTotal = reduce(add, 0, nbrs);

    var sum = reduce(add, 0); //=> :: [Number] -> Number

    sum = reduce::partial(add, 0);
    [1,10,20]::sum();

Ramda is [considering a technique][1] that would significantly reduce call stacks. But there is nothing likely to help with you understand parameter orders of your functions. Many users annotate their functions with something like Haskell signatures.

Thank you for bringing forth another interesting library. I'll be following your progress. Best of luck!

[1]: https://github.com/ramda/ramda/pull/907

It was finding that those tools were no longer supporting the way I wanted to work that got me started on Ramda. I'm guessing the same is true for the author of Trine.

Thanks for the information.

One question, though: How do user functions interact in here? If you didn't include `flatten`, but I had my own version of it, would it be straightforward for me to build `process` using my own `flatten`? Do I have to modify some Trine objects, or can I use some simple function references?

Obviously I haven't yet actually dug into the Trine code. Perhaps this weekend.

    // process1 :: (Item -> Bool) -> [Item] -> [OtherType]
    // process2 :: [Item] -> [OtherType]
    process1(isOk, items); //=> [otherType1, otherType2, ...]
    process2(items); //=> [otherType1, otherType2, ...]

    
    var processR1 = seq(filter, map(toOtherType), flatten);
    var processR2 = processR1(isOk);

    
    var processT1 = (isOk, items) => items.filter(isOk).map(toOtherType).flatten()
    var processT2 = items => processT1(isOk, items)

  You could technically use some FPLang-to-JS compiler, 
  but those suck more often than not.

Features like the function bind syntax are only possible with Babel or another transpiler. It will likely be years before you can use them practically without a transpiler in the browser.

A lot of the new syntax/macros/APIs/etc should just be built as modules or Babel plugins rather than core language features. Just because [Syntax X] improves a couple of code snippets doesn't mean it needs to be shipped with the next version of JavaScript.

Do you mean thin arrow fn(s)?

    > function isboxed() { return this instanceof Number; }
    > isboxed.call(5);
    true

It also means trine can never upgrade the version of Babel it is using internally, since Babel could change the helper name that it uses or something, but that might not exist in the version of babel-runtime being used in the code that depends on trine.