51–60 of 116 posts
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
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…
function Person(){
this.age = 0;
setInterval(() => {
this.age++;
}, 1000);
}
function Person(){
this.age = 0;
var my = this;
setInterval(function(){
my.age++;
}, 1000);
}
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 t…
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.
Earlier quoted context omitted.
He's probably having issues with async gubbins. Some sort of 'rewind time' in the debugger so you could determine what happened when to get to this state of error.
I also want to be able to run javascript (and the rest of the browser) deterministically in a test environment, and run tests, each with different timing characteristics. Of course, I want to run my server in the same way. So perhaps this is better done inside some "deterministic virtual machine", where the browser and server are run deterministically hand-in-hand.
Second, you can actually execute browser and node code deterministically if you like, by providing alternative implementations of setTimeout, setInterval, setImmediate, etc. that serialize execution of the callbacks in the order of your choice.
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()
var process = seq(filter(isOk), map(toOtherType), flatten);
process(items);
map(process, groupsOfItems)
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.
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…
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…
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 t…
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…
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.)