Today I feel like I finally grokked currying (in Javascript), and of course, like any programmer who has learned a new trick, my mind immediately began racing over how to improve my current codebase using it.
And again, like any programmer, the little voice shouting “[new trick] all the things!” was silenced by another saying, “[new trick] is really complex. maybe you shouldn’t use it.” Curry is sugar, essentially, after all.
I understand that there’s nothing wrong with using a feature in moderation, especially one as mind-bending as currying, but for the sake of simplicity should I avoid using it if something equally as efficient is sufficient?
1
TL;DR: No
IMO Your question contains a bad assumption.
Bad assumption
there’s nothing wrong with using a feature in moderation
This is the wrong way to look at a language and it’s capabilities. You should use whatever idiom, feature, etc, yields the shortest, most maintainable implementation that has reasonable performance for you/your team. It should not be driven by how many times you’ve used it so far. Programming decisions shouldn’t be governed by an arbitrary limitation on the number of time you can use a particular construct on the belief that “this amount is okay, but one more is too much”.
The Question
The question is “is currying to complex for you/your team?”. There are certainly many people for whom currying is not complicated and use it all the time. You mentioned you just learned it, so it is a valid question to ask yourself. However, and this is the important bit, this is a question you must answer. You should consider any external factors like deadlines, the cost of making mistakes (which will rise anytime you’re using something unfamiliar), etc and weigh that against the benefits.
Complexity
Complexity is largely a function of familiarity. Familiarity drives understanding. When you are familiar with an concept it isn’t any more or less complex than anything else. Think about the notion of anonymous function, objects and types, and how complex they were when you first came across them. Conversely, if you never gain any familiarity with the concept, it is and will always remain complex.
Average Team Skill Level
The question of not using something because most of the team doesn’t understand the concept is something I have considered in the past. However I have always decided I would rather force people to learn and develop, rather than have everyone program to a “lower” common denominator. In the past I have had to compromise the best implementation I could give for fear someone else will not be able to maintain/understand it. Now that I can set policy this doesn’t happen.
1
Like all choices in engineering, there is a definite trade-off. What is the benefit of replacing your existing code with your new trick? Is the code easier to maintain, easier to read (which aids in maintainability), is it faster, etc. Also, what are the downsides? Are you working in a team and, if so, does using your knew trick reduce readability for various team members?
In the end, you have to list the pros and cons and determine what you think is best. If it is a issue of skill level within the team, then perhaps you can make efforts to train your team on the new technique and share your insight (your “aha” moment(s)). Then, once your team is better educated on the topic, you can make the decision as a team on how you should approach using this new trick.
If you are working on an open source project, then it could be argued that it is a good thing to stay away from code-uses that could trip up other programmers contributing to the project. Alternatively, it could be argued that you should use such tricks if the project has a good review process where misuse of your new trick could be seen.
And if this is simply a personal project, then do whatever makes you happy!
Hope that this helps! Happy coding!
0