We can't bash on stuff just because we feel it's too complicated. We can only make the case that simplicity is hard but more impactful/meaningful
I’m currently doing a lot of Node.js work and it’s great! but there are things in this world that are not so great and I would like to address a few of those things in this post. The things I write on this blog are highly opinionated and as such you should keep this in mind when you read this. This is not an exact answer to a specific question.
Let’s start with lodash (there’s nothing wrong with lodash, use it if it makes your life easier) this is, from what I can tell, a huge library with lots of auxiliary functions. With tools for doing stuff like currying and Object.assign.
To be fair, Object.assign doesn’t appear to be supported in IE and was just recently added to the language. I’m a bit late to the game so some of this may come as a surprise but I thought we had polyfills for this sort of stuff.
What does not make any sense though is the function _.partial this function takes away from readability. As new person arriving in this world _.partial does currying in a very unintuitive way.
I would much rather prefer it if we just wrote the following code becuase the intent is much clearer and not obscrued by the intricasies of _.partial. I don’t think there’s anything wrong about being explicit.
function AB(a, b) {
}
function B(b) {
return function() {
return AB('a', b)
}
}
Also, if you really do want to curry N arguments left/right you should really consider if your design really needs this or could you do with just passing an argument as an array?
(min <= a && a <= max)
The above is a straightfoward way to check if a value falls within a specifc range. It’s the equiavlent of a SQL BETWEEN. Where the lower and upper bound in inclusive. There are many ways to express the above intent but I find this to be the most clear.
if (!true)
Whenever I want to test for an error condition I tend to do the following. I express the condition which is an error in the form of a Boolean expression and then negate it. if you see if (!condition) the condition is the error condition and the if-statement body is the error handling code. This allows us to parse the condition without considering negation (for the most part). Again, I do feel as if this leads to cleaner code with less intricacies to deal with and it’s a mostly unviersal approach that would work in any language.