7 ms·

OCaml is a nice language and it surely has advantages. But don't treat that as a competitive advantage. All of the benefits mentioned can be easily found in oth

OCaml is a nice language and it surely has advantages. But don't treat that as a competitive advantage. All of the benefits mentioned can be easily found in other programming languages, except for maybe pattern matching, but that can be easily replaced with similar constructs. Using a not very popular programming language can actually make it harder for you to hire people.

sklogic 11y ago
> that can be easily replaced with similar constructs Mind giving an example? > Using a not very popular programming language can actually make it harder for you to hire people. Do you really want to work with people who can't learn a tiny little language?
- dozzie 11y ago
  >> that can be easily replaced with similar constructs > Mind giving an example? You can use, for example, elaborate if-else constructs that firstly try to determine type of the value, then check for values. I've never seen in imperative languages anything similar to conditional that checks both type and content of an expression, and allows to capture parts of that expression into variables. Well, except for precisely the pattern matching construct, where it was implemented deliberately after functional and declarative languages (Rust). >> Using a not very popular programming language can actually make it harder for you to hire people. > Do you really want to work with people who can't learn a tiny little language? I see things a little differently. It's extremely difficult to find an idiot who can write OCaml, while it's fairly easy for C++, Java, or C#. Also, allowing people to learn OCaml and use it every day on the job is a big plus for a company. It's way better than free sandwitches for breakfast in the long run.
  - rlander 11y ago
    You can use, for example, elaborate if-else constructs that firstly try to determine type of the value, then check for values. That's nowhere near pattern matching. Two concepts make pattern matching vastly superior to if-else constructs: - Non-exhaustive checks by the compiler. - Destructuring
    - dozzie 11y ago
      Oh, look, non-exhaustive checks are exactly as with if-else. And no, `match .. with' cannot be calculated in compilation time typically. Poor argument. It's being a combination of destructuring, branch selection and variable assignment that makes pattern matching superior.
  - sklogic 11y ago
    You can also do it in Brainfuck if you like, with an equivalent code bloat. Pattern matching is an order of magnitude more readable and dense than the if ladders. As for the hiring, it is a silly idea in general to seek "programmers in XXX language" (and to position yourself as an XXX programmer). Hire programmers. Just programmers. Languages are irrelevant.
  - loup-vaillant 11y ago
    > You can use, for example, elaborate if-else constructs that firstly try to determine type of the value, then check for values. That's dynamic typing. Very different from pattern matching over sum types: with dynamic typing, you can basically forget about most compile time guarantees. Seriously, you sound like, "why bother with Ocaml when JavaScript does the same thing?". I can tell you from first hand experience that they do not feel the same at all. The other classic example, class hierarchies, is also very different from pattern matching —and much more cumbersome. The only language I know of that kinda bridged the two is Scala, with case classes.
    - dozzie 11y ago
      > That's dynamic typing. No, that's run-time branch selection. Exactly as with pattern matching (`match .. with ..'), except the latter is more convenient. > Seriously, you sound like, "why bother with Ocaml when JavaScript does the same thing?". And you really think I consider elaborate constructions a better thing than concise pattern matching?
      - sklogic 11y ago
        > Exactly as with pattern matching With pattern matching you'll get static checking if your matching is exhaustive. Impossible with an if ladder. Therefore they're not semantically equivalent.
        dozzie 11y ago
        Static checking of a variable, value of which is determined in runtime? How can you do that?
        dragonwriter 11y ago
        Statically checked pattern matching validates that the provided patterns cover all possible values the variable could have (the whole space of the variables declared/inferred type). So the actual runtime value is not necessary: if the match is exhaustive, there is no possible value that could be taken at runtime that would result in no match.
nv-vn 11y ago
From what I've heard, Jane Street mainly (or at least often) hires developers who have never before used OCaml or even functional programming in general.
junke 11y ago
> Using a not very popular programming language can actually make it harder for you to hire people. This is a very popular opinion, but I never see anyone taking the time to bring actual arguments. Do you have any experience hiring people or are you just spreading this seemingly self-evident claim? If a language is popular, wouldn't more companies want to hire for it, which would make recruiting harder? See http://blog.activelylazy.co.uk/2013/05/27/choosing-a-programming-language-recruitment/ http://blog.activelylazy.co.uk/2013/05/27/choosing-a-program.... Also, being popular means that it is being known by a wider audience of people: isn't it harder to filter through all the applicants who say they can write in the popular language?
- mordocai 11y ago
  As someone currently hiring for a mid level popularity language (ruby) I find that we don't have as many applicants as we'd like and that many people who apply have ruby on their resume but have never done an actual project in it. We also do javascript and, despite its popularity, we also get quite a few applicants who have it on their resume and have never used the language for anything useful. Personally, my opinion is just hiring is hard. It is a very valid point though that if you are not willing to hire remote (which my company is not) you are very limited when trying to hire for less popular languages. Alternatively just train people, but that can be expensive.
  - rlander 11y ago
    "The only thing worse than training employees and losing them is to not train them and keep them." Zig Ziglar
rlander 11y ago
Using a not very popular programming language can actually make it harder for you to hire people. That's a non-sequitur! The "unpopular languages make it harder to hire programmers" myth has been debunked many times right here on HN. Just hire smart people, not blub programmers.
- jlouis 11y ago
  One could argue that good programming languages self-select good programmers. And that there are not that many good programmers in the first place.
  - rlander 11y ago
    That's a good point, but this argument's mostly driven by functional programmers and "good languages" usually means Haskell or Lisp, in my experience. Disclosure: I'm a functional programmer myself so, what do I know.
padator 11y ago
> Using a not very popular programming language can actually make it harder for you to hire people. Some evidence this is just not true: http://gazagnaire.org/pub/SSGM10.pdf http://gazagnaire.org/pub/SSGM10.pdf
davorb 11y ago
> Using a not very popular programming language can actually make it harder for you to hire people. The type of people who go about learning OCaml are arguably on the whole more competent and passionate than your average run of the mill Java programmer. Using OCaml might be a good way to separate the wheat from the chaff.

sklogic 11y ago

> that can be easily replaced with similar constructs Mind giving an example? > Using a not very popular programming language can actually make it harder for you to hire people. Do you really want to work with people who can't learn a tiny little language?

dozzie 11y ago
>> that can be easily replaced with similar constructs > Mind giving an example? You can use, for example, elaborate if-else constructs that firstly try to determine type of the value, then check for values. I've never seen in imperative languages anything similar to conditional that checks both type and content of an expression, and allows to capture parts of that expression into variables. Well, except for precisely the pattern matching construct, where it was implemented deliberately after functional and declarative languages (Rust). >> Using a not very popular programming language can actually make it harder for you to hire people. > Do you really want to work with people who can't learn a tiny little language? I see things a little differently. It's extremely difficult to find an idiot who can write OCaml, while it's fairly easy for C++, Java, or C#. Also, allowing people to learn OCaml and use it every day on the job is a big plus for a company. It's way better than free sandwitches for breakfast in the long run.
- rlander 11y ago
  You can use, for example, elaborate if-else constructs that firstly try to determine type of the value, then check for values. That's nowhere near pattern matching. Two concepts make pattern matching vastly superior to if-else constructs: - Non-exhaustive checks by the compiler. - Destructuring
  - dozzie 11y ago
    Oh, look, non-exhaustive checks are exactly as with if-else. And no, `match .. with' cannot be calculated in compilation time typically. Poor argument. It's being a combination of destructuring, branch selection and variable assignment that makes pattern matching superior.
- sklogic 11y ago
  You can also do it in Brainfuck if you like, with an equivalent code bloat. Pattern matching is an order of magnitude more readable and dense than the if ladders. As for the hiring, it is a silly idea in general to seek "programmers in XXX language" (and to position yourself as an XXX programmer). Hire programmers. Just programmers. Languages are irrelevant.
- loup-vaillant 11y ago
  > You can use, for example, elaborate if-else constructs that firstly try to determine type of the value, then check for values. That's dynamic typing. Very different from pattern matching over sum types: with dynamic typing, you can basically forget about most compile time guarantees. Seriously, you sound like, "why bother with Ocaml when JavaScript does the same thing?". I can tell you from first hand experience that they do not feel the same at all. The other classic example, class hierarchies, is also very different from pattern matching —and much more cumbersome. The only language I know of that kinda bridged the two is Scala, with case classes.
  - dozzie 11y ago
    > That's dynamic typing. No, that's run-time branch selection. Exactly as with pattern matching (`match .. with ..'), except the latter is more convenient. > Seriously, you sound like, "why bother with Ocaml when JavaScript does the same thing?". And you really think I consider elaborate constructions a better thing than concise pattern matching?
    - sklogic 11y ago
      > Exactly as with pattern matching With pattern matching you'll get static checking if your matching is exhaustive. Impossible with an if ladder. Therefore they're not semantically equivalent.
      - dozzie 11y ago
        Static checking of a variable, value of which is determined in runtime? How can you do that?
        dragonwriter 11y ago
        Statically checked pattern matching validates that the provided patterns cover all possible values the variable could have (the whole space of the variables declared/inferred type). So the actual runtime value is not necessary: if the match is exhaustive, there is no possible value that could be taken at runtime that would result in no match.

nv-vn 11y ago

From what I've heard, Jane Street mainly (or at least often) hires developers who have never before used OCaml or even functional programming in general.

junke 11y ago

> Using a not very popular programming language can actually make it harder for you to hire people. This is a very popular opinion, but I never see anyone taking the time to bring actual arguments. Do you have any experience hiring people or are you just spreading this seemingly self-evident claim? If a language is popular, wouldn't more companies want to hire for it, which would make recruiting harder? See http://blog.activelylazy.co.uk/2013/05/27/choosing-a-programming-language-recruitment/ http://blog.activelylazy.co.uk/2013/05/27/choosing-a-program.... Also, being popular means that it is being known by a wider audience of people: isn't it harder to filter through all the applicants who say they can write in the popular language?

mordocai 11y ago
As someone currently hiring for a mid level popularity language (ruby) I find that we don't have as many applicants as we'd like and that many people who apply have ruby on their resume but have never done an actual project in it. We also do javascript and, despite its popularity, we also get quite a few applicants who have it on their resume and have never used the language for anything useful. Personally, my opinion is just hiring is hard. It is a very valid point though that if you are not willing to hire remote (which my company is not) you are very limited when trying to hire for less popular languages. Alternatively just train people, but that can be expensive.
- rlander 11y ago
  "The only thing worse than training employees and losing them is to not train them and keep them." Zig Ziglar

rlander 11y ago

Using a not very popular programming language can actually make it harder for you to hire people. That's a non-sequitur! The "unpopular languages make it harder to hire programmers" myth has been debunked many times right here on HN. Just hire smart people, not blub programmers.

jlouis 11y ago
One could argue that good programming languages self-select good programmers. And that there are not that many good programmers in the first place.
- rlander 11y ago
  That's a good point, but this argument's mostly driven by functional programmers and "good languages" usually means Haskell or Lisp, in my experience. Disclosure: I'm a functional programmer myself so, what do I know.

padator 11y ago

> Using a not very popular programming language can actually make it harder for you to hire people. Some evidence this is just not true: http://gazagnaire.org/pub/SSGM10.pdf http://gazagnaire.org/pub/SSGM10.pdf

davorb 11y ago

> Using a not very popular programming language can actually make it harder for you to hire people. The type of people who go about learning OCaml are arguably on the whole more competent and passionate than your average run of the mill Java programmer. Using OCaml might be a good way to separate the wheat from the chaff.