151–160 of 162 posts
I would consider switching from underscore if there was a reliable polyfill so that I wouldn't need to be aware of all these browser compatibility constraints. That way I can just drop the polyfill in a couple of years instead of replacing every underscore use. I guess the babel polyfill would do this.
Earlier quoted context omitted.
Something I find very interesting about Swift is it's complete reversal of opinion from Objective-C on this topic. Obj-C basically has the behavior GP wants: call a method on nil (aka: null) and it returns nil/false/0. It's possible to write concise & correct code that relies on this behavior. Swift turns it into a fatal runtime error, and uses the type system to help prevent it from happening. I think there's room f…
There is room for both, but it should be explicit in my opinion. Dart for instance has null safe operators // not null-safe: foo.bar.baz(); // null-safe: foo?.bar?.baz(); If your type system also does null tracking, then you can see where you might have null values and decide to use the null-safe operators.
foo >>= bar >>= baz
Alternate title for the article: "Lists of lodash features replaced by ES6 if you don't mind throwing an exception when given invalid input such as null or undefined". All kidding aside, a lot of our lodash code ends up looking something like this: function (xs) { return _(xs).pluck('foo').filter().value(); } That code clearly expects that xs is an array of objects. However, we might occasionally end up with xs being…
Why not call it 'objects' rather than 'xs'?
Earlier quoted context omitted.
Depending on the particular domain of the task. There are perfectly valid reasons why silently failing is OK.
Sure, we can always make up an examples. Perhaps if you are using null to represent something explicitly in your data. But silently failing on undefined is just going to lead to an other bug somewhere else entirely and half a day of debugging. I would much rather fail early and loudly than having to hunt down some anecdotal bug that happens every prime-th national holiday and is impossible to reproduce.
Having functions/methods return undefined is a huge time and complexity saver for UI code as the application could still be in the process of getting input from the user that then would be passed off to the back-end code once the user was done changing their minds. No point in having a dropdown throw an error because the user is still deciding what they want to appear in the dropdown.
Earlier quoted context omitted.
> No, why would you? Because he's a better programmer than you are, and he knows it. > It's just a loop. There are many kinds of common patterns in loops, abstracting them into resuable higher order functions, aka a collections api is rather basic functional programming; "it's just a loop" is a blub phrase of someone who doesn't see the point because they have tried it long enough to understand the value in a differe…
I know it's currently thought as so, but functional programming is not the be-all, end-all paradigm. If you've been around for a while, you'd have seen the ebb and flow a few times already.
If you've been around for a while, you should have already accepted the benefits of functional programming in the places it's most effective and banished low level procedural programming of loops except in cases where extreme optimization is required. There's no eb and flow here, higher order map/reduce/filter style has been the best way since the 60/70/80's when Lisp and Smalltalk were doing it.
Earlier quoted context omitted.
The language changes too. In ES5 `Object.keys` throws an error for `Object.keys('abc')` but in ES6 it returns an array.
Still a pretty conservative breaking change. Something you'd expect from a committee of people. Lodash has more wiggle room to make absurd changes in future.
Earlier quoted context omitted.
You might dig https://github.com/lodash/lodash-webpack-plugin
We do plenty fine with just `import get from 'lodash/get', however we're fairly eager to upgrade to webpack to to take advantage of it's tree-shaking capabilities.
You'll need something like https://github.com/lodash/babel-plugin-lodash.
I understand why, and once upon a time I was the guy who would commit code where I replaced jQuery and underscore (at the time) calls with native calls. It works, and is totally fine. But what was the point? Some kind of optimization? It was pretty pointless in hindsight and just made my coworkers trouble. Now all my JS code is Ramda/lodash all the way, and it's great (although I opt for Clojure/script when possible)
Im quite out of the loop in the JS world and wanted to ask what happened to underscore? It used to be the de facto utility belt for JS.
Earlier quoted context omitted.
Im quite out of the loop in the JS world and wanted to ask what happened to underscore? It used to be the de facto utility belt for JS.
It's great, but there are better alternatives. Ramda[0] is great, auto-curries everything and has an api similar to Clojures, which is really great. Lodash[1] is a fork of Underscore, with some OOP-isms replaced for FP-isms, which I and many others prefer. [0] http://ramdajs.com/ [1] http://lodash.com/
Earlier quoted context omitted.
Crashing is exactly what the correct program should do if it hits undefined behavior.
What? 1. Where did anyone say we were hitting undefined behavior? We're hitting a well-defined JavaScript value whose name is "undefined". 2. Why is crashing correct? Don't answer in terms of language specs, answer in terms of desired behavior for whatever you're trying to do with the program. Software engineering is a tool for accomplishing other things. Sometimes, yes, software crashing is the right thing in servic…
Crashing in such case is used to avoid incorrect functioning of the program, such as overwriting user data or introducing security vulnerabilities. By definition, if the behavior wasn't expected, the program is in unknown state. Sure, you can gracefully handle such situations (e.g. allow website to load other scripts if the particular piece that "crashes" not important for its functioning, crash just some kind-of sub-process and restart it, or — if it's user input — end up with some predefined value regardless of the incorrect input, etc.), but the correct _default_ behavior is to crash, otherwise you'll end up with unknown state and the algorithm that you wrote will be incorrect.
I recommend anyone who wants to see how much unexpected behavior is in their JavaScript programs to install typescript@next and start adding types, compiling with tsc --strictNullChecks.