7 ms·
In other words, they like the fact that it has features typical among languages oriented toward functional programming. There's no cost-benefit analysis here d
by rtl49 11y ago
In other words, they like the fact that it has features typical among languages oriented toward functional programming.
There's no cost-benefit analysis here discussing the obvious pitfalls from a business perspective, such as a much reduced talent pool and probably higher salaries for the few programmers who are comfortable working with such an uncommon language. There's also no discussion about why they believe a business offering a calendar application needs to use such a technically demanding language. This would be more understandable for, say, Jane Street (high-frequency trading), but for this particular business my naive belief is that this probably will not be the "competitive advantage" they claim it is.
- fulafel 11y agoWhat are your reasons to believe the job market for hippy functional languages is charcteristically highly paid and a "seller's market"? Judging from some anecdotes and the proportion of FP programmers working in academia I would have thought the opposite. Unless you're looking for the shallow end of the talent pool...
- rtl49 11y agoMy prejudice is that anyone competent in functional programming is also comfortable with other programing paradigms, in particular OOP. Not so much the reverse. Thus the limited talent pool and higher wages.
- LeonidasXIV 11y ago> My prejudice is that anyone competent in functional programming is also comfortable with other programing paradigms, in particular OOP. That might be true, but if they are competent in both, that's often because they have switched from OOP to FP and prefer the latter nowadays so if there is a selection between otherwise equivalent jobs, they would tend toward the FP job.
- rtl49 11y agoPerhaps, as you suggest, attracting more talent is one benefit of using an FP-oriented language for their codebase. It would have been nice to see this claim evaluated in the context of a cost-benefit analysis including the costs. This article, which claims that OCaml provides a "competitive advantage," doesn't provide that. Thus I don't believe it is a useful source of information for evaluating the merits of OCaml in particular, or FP in general, in a production environment.
- rwmj 11y agovirt-v2v[1] -- written in OCaml -- had a bunch of contributions from people who mainly work on Java for their dayjobs. The main problem is that people are close-minded and refuse to learn anything new. If you can filter those people out with your hiring processes, then OCaml is not difficult. [1] https://github.com/libguestfs/libguestfs/tree/master/v2v https://github.com/libguestfs/libguestfs/tree/master/v2v
- loudmax 11y agoNot mentioned in the article, but Paul Graham's Python Paradox (http://www.paulgraham.com/pypar.html http://www.paulgraham.com/pypar.html) could a factor. So maybe it's harder to find developers comfortable programming in OCaml, but these developers are a self-selected more refined group. Whether that makes sense for the business at hand is another question.
- the_af 11y ago"Technically demanding" or simply "uncommon"? It seems you're conflating the two.
- rtl49 11y agoActually, I wasn't. The first claim is that there are fewer programmers using OCaml because it's uncommon in industry. The second is that their business has no obvious need for a paradigm which, in my view, requires more education and a stronger understanding of mathematics. I'll admit I don't have any evidence other than personal experience to support the second claim, but the first is easily verified.
- loup-vaillant 11y agoSeriously, I'm quite baffled at the idea that OCaml would be technically demanding. I was taught OCaml in college, along with C, Java, C++, and Prolog. Ocaml was easier than even Java. Much less demanding than the minefield that is C++. And it certainly doesn't require more education. A different education, that's for sure, but not more. As for requiring a stronger understanding of math… Languages like OCaml just don't pretend that programming is not math. So it tends to scare away those who fled math in the first place. C++ and Java are just as mathy (if not more, just see the sheer size of the specifications), but they don't really tell you. <Grumpy Dijkstra> Programming should have been of the applied mathematics department, not the electronic engineering one. </Grumpy Dijkstra>
- rtl49 11y agoI really don't disagree with the substance of your comment, though the Algol-family languages tend to be hard because of disorganized core libraries and occasionally cumbersome syntax rather than because they depend on unfamiliar mathematical constructs. I have little experience in education, but my naive hypothesis is that it would be easier to teach a child, say, Python than any FP-oriented language. I suppose it goes without saying that if children were introduced to the lambda calculus beforehand this might not remain true. See my comment beneath the root to see my clarification of the original post. I don't think Dijkstra would disagree with me. After all, it was he who suggested the average American programmer would benefit "more from learning, say, Latin than yet another programming language."
- fsloth 11y agoI can understand the availability problem created by a reduced talent pool but I didn't know getting cheap labour was a top priority in when hiring quality software engineers. Really, this "oh no a foreign language" thing is way off. Every good software engineer I know would not bat an eye to learn a new language. Ocaml is not quantum physics, it's pretty understandable language.
- rtl49 11y agoSince a few people are kind of getting on my case, I'd like to point out that I learned OCaml for coursework in functional programming and computational linguistics. I'm not suggesting it's useless or comparable to quantum physics in difficulty. I'm only pointing out the reality that the majority of software developers have little to no exposure to functional programming. Few of them will be prepared to commit to a new programming paradigm when there are so many other employment opportunities which use more familiar frameworks and develop skills more widely applicable in the job market. I'd also like to suggest that, for certain applications, the most touted benefit of functional programming (the ease of proving algorithms behave as intended) is not especially relevant. I would even dare to suggest that, in some cases, it may be more rational to hire a "decent" programmer than a "great" one. This is to say nothing about the specific language features of OCaml or the utility of functional programming in general, just that the benefits need to be weighed against the costs. In an article claiming that using OCaml provides a "competitive advantage" from a business perspective, I would have expected a discussion of both.