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

41–50 of 116 posts

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

#41

Post by jdd »

quinnirill wrote: post #7
braythwayt wrote: post #4

Looks interesting, especially in concert with the proposed bind syntax. Fortunately, that syntax is in Babel now, so we can play with these ideas straight away. That being said, the readme did not address why Ramda uses the data as the last parameter and not as `this`: To facilitate partial application.

Ramda actually uses data as the last parameter usually, whereas lodash has it as the first. However, I agree, the readme doesn't quite show the full power of Trine. Trine has `partial`, which allows you to do partial application as so: `parseInt::partial(_)`, that would create a function that acts as parseInt but only takes one argument. This is in sync with the partial application syntax proposal: https://gist.githu…

lodash-fp is a thin layer over lodash enabling auto-curried, data last methods – https://www.npmjs.com/package/lodash-fp

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

#42

Post by jdd »

agumonkey wrote: post #14

I recall lodash author saying that if you want HOF, Datum order to change you can `rearg` the whole library to suit your needs. Maybe the performance penalty is too large, I never tried it.

Yep. There's a package with the method transformations already applied – https://www.npmjs.com/package/lodash-fp

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

#45

Post by cowardlydragon »

TazeTSchnitzel wrote: post #31
thomasfoster96 wrote: post #27

Perhaps what programmers of modern JavaScript should be doing is going back and revisiting things that have been considered harmful practices for quite a while. Some work in extending prototypes would make a huge difference to the readability of lots of code - yet everyone is told this is a bad practice because extending DOM elements is problematic and people are lazy when it comes to global namespace pollution. Real…

Extending prototypes seems like a great idea, until other code running in the same environment does it, and you realise why people stopped doing that.

?Namespaces?

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

#46

Post by delluminatus »

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 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 to add modern extensions that make common patterns easier. Of course this function bind syntax is just a proposal and hasn't been accepted into the standard yet. But what about it bothers you so much? What about iterators or shorter function definitions, are those also nightmarish manglings of syntax? I mean, really. The usage of Javascript is evolving from simple embedded scripts to gigantic client/server applications. It's no surprise that the language itself will evolve as well.

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

#48

Post by TazeTSchnitzel »

[deleted] wrote: post #36
TazeTSchnitzel wrote: post #31

Earlier quoted context omitted.

Extending prototypes seems like a great idea, until other code running in the same environment does it, and you realise why people stopped doing that.

[deleted]

> If you've got a fair degree of knowledge and control over what's in your environment (e.g. Things are documented or standardised, you're using node.js), I don't really see the issue.

Are you checking every single library you use for prototype changes, including the libraries each library depends on, the libraries those depend on, etc.?

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

#49

Post by BonsaiDen »

[deleted] wrote: post #36
TazeTSchnitzel wrote: post #31

Earlier quoted context omitted.

Extending prototypes seems like a great idea, until other code running in the same environment does it, and you realise why people stopped doing that.

[deleted]

Especially under Node.js prototype modification can be a very big issue. Because once you start any third party module, all bets about knowledge and control of your environment are off. Someone, somewhere down the module chain might have messed with the prototype chain in some way and you won't know it until you run into the resulting bugs.

I've been there, and once you start to see random debug logs popping up in your console because you somehow ended up iterating over a `enumerable` prototype extension in a string "enhancement" library used by a third party module, that is used by a third party module. You'll end up having to take one of three choices: Either modify your code to deal with the mess, contact the author of the string library to fix it (and all upstream authors to update their dependencies) or just drop the top level library altogether. None of these are perfectly clean / easy and in some cases these might they might also be impossible (author cannot be reached, won't change his code, you code can't handle it or you simply cannot drop the third party dependency).

Once you start writing a library, you got quite a bit of responsibility resting on your shoulder to not break things upstream :)

We already averted the "nightmare" of io.js / node.js ending up with different ES6 feature sets, so we shouldn't open a new can of worms.

The Node.js ecosystem is wonderful and that in big part stems from the fact that you can basically install any module at any time and things just work.

Post reply on HN