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?
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.
Some evidence this is just not true: http://gazagnaire.org/pub/SSGM10.pdf
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.
Disclosure: I'm a functional programmer myself so, what do I know.
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.
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?
> 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.
That's nowhere near pattern matching. Two concepts make pattern matching vastly superior to if-else constructs:
- Non-exhaustive checks by the compiler.
- Destructuring
It's being a combination of destructuring, branch selection and variable assignment that makes pattern matching superior.
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.
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.
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?
With pattern matching you'll get static checking if your matching is exhaustive. Impossible with an if ladder. Therefore they're not semantically equivalent.
type 'a myOption = Some of 'a | None
let f (Some x) = x*x
Warning 8: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
NoneYour solution with type and value checks in an if ladder was called "dynamic typing" exactly for this reason - you select paths dynamically in the runtime without any static checks on soundness of this selection.
I wouldn't. Pattern matching is primarly a conditional, that's why I focused on if-else.
> We're talking about language features semantically equivalent to pattern matching, and, turns out, there are none.
Why would you think that pattern matching revolves around compile-time guarantees? It does not. It's primarly a conditional, everything else is an optional, additional effect. You can have pattern matching in dynamically typed languages (Lisp, Erlang).