4 ms·
My point is that there is a learning curve no matter which way you slice it, as one must also learn to use higher-order functions effectively (I do not believe
by platz 9y ago
My point is that there is a learning curve no matter which way you slice it, as one must also learn to use higher-order functions effectively (I do not believe mainstream devs know this innately) and this is an obstacle for newcomers.
- yogthos 9y agoPretty much all mainstream languages use higher order functions nowadays, it really shouldn't be a foreign concept at this point.
- platz 9y agoThe basics of HOF are not foreign concepts at this point (e.g. map, filter). But FP amplifies the degree and nature in which they are used. for example learning to use folds or transducers. Learning to avoid mutation etc
- cutler 9y agoWhy is learning a few FP concepts considered more taxing than the all the cruft which accompanies OOP? My experience is that FP concepts and idioms are a breath of fresh air compared with OOP design patterns.
- platz 9y agoIt is not 'more taxing'. It is less familiar and implies an effort to learn for an existing dev. (I am talking about existing devs, not those learning their first language). The issue for those folks is not absolute difficulty but motivation.
- yogthos 9y agoAll I can say here is that my team has been using Clojure for over 7 years now, and hiring devs hasn't been a problem. At this point, my view is that if somebody has problems learning these concepts, I probably wouldn't want to hire them to work with any language.
- platz 9y agoI have no doubt you've had great success with clojure. However I question generalizing from 'this was not an issue for my team at my company' to 'this should not be a concern for any company under any given constraints'. I don't doubt most devs wouldn't have problems learning these concepts. It's whether business have capacity to allow those devs to onboard in such a fashion, knowing that different business are subject to different constraints.
- yogthos 9y agoThere are many companies using Clojure large and small, nobody actually using the language has problems hiring people for it. This is not a theoretical debate, there's no evidence to support the notion that Clojure is hard to hire for. In practice, the language is a small part of what a new hire has to learn. Each company has different processes, tools, workflows, frameworks, and so on. A language is only a small part of that. While there are obviously companies where Clojure wouldn't be a good fit, the reasons wouldn't be that it's hard to train new people to work with it.