[thalesmello]

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.

[junke]

> 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-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]

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]

"The only thing worse than training employees and losing them is to not train them and keep them." Zig Ziglar

[padator]

> 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

[rlander]

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]

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]

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.

[davorb]

> 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.

[nv-vn]

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.

[sklogic]

> 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]

>> 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.

[loup-vaillant]

> 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]

> 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]

> 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]

Static checking of a variable, value of which is determined in runtime? How can you do that?

[rlander]

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]

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]

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.