Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Trine – A utility library for functional programming in JavaScript

github.com

Post reply on HN
Print view View original

101–110 of 116 posts

Re: Trine – A utility library for functional programming in JavaScript

#101

Post by lightblade »

bshimmin wrote: post #24

About halfway through the README, after some examples of the new bind syntax, it says "But why stop there?" Actually, please can we stop here? Just for a bit? This continual, persistent mangling of JavaScript's syntax really is starting to hurt. It's one thing to have to keep on top of the new frameworks springing up every five minutes - which you can, for the most part, ignore for at least six months until they star…

Oh you missed out so much by stopping at "But why stop there?"

> ...can also represent infinite sets

This is the highlight.

Re: Trine – A utility library for functional programming in JavaScript

#102

Post by CrossEye »

quinnirill wrote: post #99
CrossEye wrote: post #55

(Disclosure: one of the authors of Ramda here, so I may well be biased toward a very different approach.) This is an interesting approach, but I get caught right at the beginning, where you say "What you'd really want to do is this: items .filter(isOk) .map(toOtherType) .flatten() But what I really want to do is build a reusable function: var process = seq(filter(isOk), map(toOtherType), flatten); So I can at my leis…

(Disclosure, Trine author here, and also admittedly very inspired by Ramda.) I actually used Ramda quite extensively a while back, because I was convinced it was the right way. However, a while after looking at stack traces that lead to Ramda and not even myself understanding my where each parameter in my own code goes, I decided to stop using it and also dropped these features from Trine. Trine has partial, and that…

It's a funny world. Each of us is looking at the other library thinking there's too much magic involved. :-)

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

Re: Trine – A utility library for functional programming in JavaScript

#104

Post by davnicwil »

striking wrote: post #52
bshimmin wrote: post #24

About halfway through the README, after some examples of the new bind syntax, it says "But why stop there?" Actually, please can we stop here? Just for a bit? This continual, persistent mangling of JavaScript's syntax really is starting to hurt. It's one thing to have to keep on top of the new frameworks springing up every five minutes - which you can, for the most part, ignore for at least six months until they star…

I was almost afraid no one else thought this way. This just makes JavaScript illegible, and adds a negligible number of new features. The only JS I'm ever going to write is ES5, at this point, because the difference between function Person(){ this.age = 0; setInterval(() => { this.age++; }, 1000); } and function Person(){ this.age = 0; var my = this; setInterval(function(){ my.age++; }, 1000); } are barely visible, b…

I agree that the second example, using (var my = this) and then using my inside the anonymous function is not much of a hassle.

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?

Re: Trine – A utility library for functional programming in JavaScript

#105

Post by woah »

bshimmin wrote: post #59
delluminatus wrote: post #46

Earlier quoted context omitted.

I disagree. I think that extending and improving a language is good, and it's certainly not a Javascript-only phenomenon. Off the top of my head, other languages that are considering and implementing syntax extensions include Python (e.g. "yield from"), C# (e.g. "async/await"), and Java (lambda expressions). I actually think that it's pretty low to accuse ECMAScript of "mangling" JS syntax when they are just trying t…

My objections are around the rate of change and the fact that JavaScript is growing into a large, complex language that people are becoming really uncertain how to use.

You are the only person who is really uncertain on it.

Re: Trine – A utility library for functional programming in JavaScript

#106

Post by damagedcake »

delluminatus wrote: post #72
bshimmin wrote: post #59

Earlier quoted context omitted.

My objections are around the rate of change and the fact that JavaScript is growing into a large, complex language that people are becoming really uncertain how to use.

I could see how that's a legitimate concern, it reminds me of some of the complaints I hear about C++ having too many features (I don't use C++, so this is just hearsay). But Javascript is still a much smaller and simpler language than almost anything else out there. Sure, it has some semantic quirks, but the syntax is fundamentally minimal. I think it will be a long time yet before we reach the point of being really…

So interesting thought here...but C# might be a better comparison. This is a language that has seen a lot of change and a lot of added features. But at least some of the earlier features that were part of the language are no longer used much. I think js is more like C# than C++ in this way.

Re: Trine – A utility library for functional programming in JavaScript

#108

Post by quinnirill »

tolmasky wrote: post #88
CrossEye wrote: post #55

(Disclosure: one of the authors of Ramda here, so I may well be biased toward a very different approach.) This is an interesting approach, but I get caught right at the beginning, where you say "What you'd really want to do is this: items .filter(isOk) .map(toOtherType) .flatten() But what I really want to do is build a reusable function: var process = seq(filter(isOk), map(toOtherType), flatten); So I can at my leis…

I believe you showed in one of your demonstrations (or someone else showing ramda), a very simple elegant example: > sum = reduce(add, 0) > sum([1,10,20]) With something like trine, composition can only happen really happen at usage-time, while with Ramda it allows you to reason about the operations separate from the data. I suppose trine could achieve the same by further complicating with some sort of dummy data: su…

Trine can actually already do this particular example:

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

Re: Trine – A utility library for functional programming in JavaScript

#109

Post by quinnirill »

CrossEye wrote: post #55

(Disclosure: one of the authors of Ramda here, so I may well be biased toward a very different approach.) This is an interesting approach, but I get caught right at the beginning, where you say "What you'd really want to do is this: items .filter(isOk) .map(toOtherType) .flatten() But what I really want to do is build a reusable function: var process = seq(filter(isOk), map(toOtherType), flatten); So I can at my leis…

With Trine this would be

    function process () {
      return this
        ::filter(isOk)
        ::map(toOtherType)
        ::flatten();
    }
and then later:

    groupsOfItems::map(process);
Granted, the `flatten` function is not in the Trine yet, somehow forgot that from the initial release.

Re: Trine – A utility library for functional programming in JavaScript

#110

Post by quinnirill »

CrossEye wrote: post #102
quinnirill wrote: post #99

Earlier quoted context omitted.

(Disclosure, Trine author here, and also admittedly very inspired by Ramda.) I actually used Ramda quite extensively a while back, because I was convinced it was the right way. However, a while after looking at stack traces that lead to Ramda and not even myself understanding my where each parameter in my own code goes, I decided to stop using it and also dropped these features from Trine. Trine has partial, and that…

It's a funny world. Each of us is looking at the other library thinking there's too much magic involved. :-) 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'…

> It's a funny world. Each of us is looking at the other library thinking there's too much magic involved. :-)

Heh - I think what feels like magic is the syntax that Trine is presuming, which admittedly might seem magical before trying it out. :) The library itself is just a collection of very primitive methods (with the exception of partial()).

> Ramda is [considering a technique][1] that would significantly reduce call stacks.

That's good to hear! But what I'd really like to see is something that would make the stack trace have a reference to the function definition site, e.g. if I have an error like

    var getIds = map(prop("id"));
    var ids = getIds([{ id: 1 }, null, { id: 2 }]);
the stack trace would also show the definition site of getIds. This is what I get when I compose functions just using the vanilla JS syntax:

    function getIds (items) {
      return items.map(function (item) {
        return item.id; // the stack trace will point here, and I can also add a breakpoint here without it stopping on every unrelated prop() call
      });
    }
Like I mentioned on several occasions here, I'm hoping for JS to get simpler unbound function syntax, which would work well with Trine, and still have the aforementioned benefits:

    let getIds = -> this::map(-> this.id);
> Best of luck!

Thank you, and likewise! <3

Post reply on HN