91–100 of 116 posts
I guess the Lodash/Underscore definition of "functional" was right after all!
...I'ma go back to using Ramda now.
Earlier quoted context omitted.
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. 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 [S…
I like this idea a lot. Mostly because it would keep JavaScript from becoming the huge syntactical and idiomatic minefield that modern C++ is.
(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…
That's exactly where I got caught too. I just don't see why I really want to do it that way at all.
My favorite thing about Underscore/Lodash/Ramda is function composition. This seems like a (syntactical) move away from that . . .
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.
I feel that hasn't changed over the years outside of more and more people not knowing how to use JavaScript (and more and more people who actually know their script).
Earlier quoted context omitted.
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, but closures and bine are expensive--present in both cases. It's better to avoid it. Granted, this is a contrived example and sometimes closures are the more elegant solution. function Person() { this.age = 0; setInterval(this.incAge, 1000, this); } Person.prototype.incAge = function personIncAge(that) { that.age += 1; }; http://jsperf.com/bind-vs-closure-vs-param
They're not expensive. You're not binding thousands of times a second anyway, so stop your silly premature optimizations.
(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…
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
Earlier quoted context omitted.
(function double() { return this * 2; }).call(2) === 4 I didn't have to box anything to pass a primitive as this. Maybe some other versions are different, but this works in Chrome 40 and Firefox 33.
Are you sure? > function isboxed() { return this instanceof Number; } > isboxed.call(5); true
> var isboxed = (function() {"use strict"; return function isboxed() {return this instanceof Number;}}());
> isboxed.call(5);
falseEarlier quoted context omitted.
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…
Meh; rockstar developers with no CS background working for over valuated MVP companies implementing half understood techniques described in shady Haskell tutorials cannot possibly be wrong.
(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 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's as far as magic goes, in fact I wanted to make it as far from magical as possible. I think plain old functions are the best form of function composition, albeit I'd love for the syntax to be terser. They're easy to read and easy to reason about, also easy to reorder, no need for higher order functions that go in the middle.
Earlier quoted context omitted.
Agreed. And btw thank you for Ramda, which is a very beautiful thing. Too sad in day-to-day web development lodash is just enough.
That's not sad. Use the tools that work for you. 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.