Looks like some kind of LINQ implementation for JS.
Trine – A utility library for functional programming in JavaScript
21–30 of 116 posts
Re: Trine – A utility library for functional programming in JavaScript
#22Earlier quoted context omitted.
Excuse my ignorance but I only have experience in JS and not any other "advanced" or well-established programming langs, how's thin arrow syntax gonna fix this prob that fat arrow can't?
Fat arrow functions have lexical this: this inside the function is bound to what it was outside. Thin arrow functions have a dynamic this, determined by how they are called. Because the library relies on dynamic this as the place where the data is sent, fat arrow syntax isn't useful with it.
Thanks for the explanation.
Re: Trine – A utility library for functional programming in JavaScript
#23Looks 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…
Whoops, my mistake, I meant to say last parameter, which is exactly its point. I recall discussing this with the authors at length, because allong.es usues a similar strategy with functions named ___With, e.g. mapWith, filterWith.
Re: Trine – A utility library for functional programming in JavaScript
#24About 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 start to gain some traction or have disappeared entirely - but when the core language itself is changing (and growing) at this rate, it really becomes an altogether more disconcerting and nightmarish proposition.
Re: Trine – A utility library for functional programming in JavaScript
#25You could always use FP languages for FP and leave JS be...
This presupposes that JavaScript is not a "functional programming language". But that's not really true. JavaScript is a multi-paradigm language supporting both imperative and functional styles.
Sure, most JavaScript code is imperative, but there's no particular reason it should be. Functional programming isn't some late addition, either: the language's design was influenced by functional languages alongside imperative ones.
Re: Trine – A utility library for functional programming in JavaScript
#26One downside of passing data as `this` that isn't mentioned is you can't use the concise function syntax `=>`. If we ever get thin arrows this problem will go away.
There's no point of using `=>` arrows if you're using the bind syntax they're mutually exclusive.
Re: Trine – A utility library for functional programming in JavaScript
#27Perhaps 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. Realistically, neither of those are reasons for it to be bad practice anymore.
Re: Trine – A utility library for functional programming in JavaScript
#28It's a shame there isn't any cross platform supported alternative to mangling javascript even further. But getting all browser developers to agree is probably an even worse nightmare.
Re: Trine – A utility library for functional programming in JavaScript
#29You could always use FP languages for FP and leave JS be...
Well you can't really. If you want to write frontend apps, for example, you have to use JS. You could technically use some FPLang-to-JS compiler, but those suck more often than not. Also, I don't see how "let's not make a thing better just because it was not meant to work this way" is an argument. I'm sure there is a fallacy name for this, but consider some other examples: "You could always use fridges for cooling an…
You could technically use some FPLang-to-JS compiler,
but those suck more often than not.
Re: Trine – A utility library for functional programming in JavaScript
#30You could always use FP languages for FP and leave JS be...
Well you can't really. If you want to write frontend apps, for example, you have to use JS. You could technically use some FPLang-to-JS compiler, but those suck more often than not. Also, I don't see how "let's not make a thing better just because it was not meant to work this way" is an argument. I'm sure there is a fallacy name for this, but consider some other examples: "You could always use fridges for cooling an…
[deleted]