Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I agree that separating logic from side-effects is an excellent lesson that easily translates to less functional programming languages.

Another thing I tend to do now is order function arguments as if the programming language had partial function application. You can see this in JavaScript by comparing lodash to lodash/fp. I think once this practice is established on a team, it can help bring a more uniform feel to the code.



In javascript it's pretty easy to write a function for partial application in either order, you can curry functions forward or backward.

    const map = (arr, mapper) => arr.map(mapper); // Non "traditional" order for arguments
    const curry = f => (...first) => (...second) => f(...first, ...second); // Classic currying: partially apply arguments to the start
    const reverseCurry = f => (...second) => (...first) => f(...first, ...second); // You might want to reverse() first and second depending on the desired syntax
    const arrayMapper = curry(map)(array); // Usually not that useful, more common to map over many arrays with the same function than to map over the same array with many functions
    const funcMapper = reverseCurry(map)(func); // Same benefits as having the classic argument order in the first place
If you're working in a code base that doesn't already implement "most specific argument last", or does so inconsistently, it's very easy to write partial application functions for both cases. If your functions aren't variadic you can even get over the clunky double call syntax by checking the total number of arguments passed thus far, and if it's greater than or equal to the function's "length" (the number of named arguments that it takes) call it, otherwise return the partially applied function, something that is sometimes known as "autocurry".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: