This is a nicely written essay and, I think, completely wrong. (One person's experience here, just as a disclaimer.)

I've interviewed a lot of functional candidates in a decade-long stint of functional programming professionally. My interview approach is always the same. All practical exercises, no leetcode here. You can do the exercises in the language you're most comfortable in.

If I had to pick a language that predicted you'll do poorly on a practical interview exercise, I would pick F# every time. For some reason the candidates just do not do well. Now I can think of some confounders - maybe the types of people who would apply to a job with some dynamic programming requirements and people who are good at F# just have no overlap. I've thought about that.

But it seems like this line

    Pragmatists don't make technology decisions on the basis of what is better. They prefer the safety of the herd.

Implies that if someone just saw some code in F# and realized what people can do in it, they would be super impressed. I have not found that to be the case. If that's a general problem and not just a quirk of my personal experience, that has to be fixed first.

cjbgkagh

I think F# programmers lack that gamut because they get comfortable in the eager execution type safe world and stay there with no particular reason to learn dynamic programming techniques. There is also the effect that it allows less advanced functional programmers to be productive so that in randomly sampling currently active functional programmers the F# programmer is less likely to be advanced.

Scala developers were referred to a Java refugees, Swift developers to Objective C refugees, and F# as C# refugees. A weird side effect of Microsoft doing a better job with C# is that there less of a push to F#. Plus F# by virtue of being in Dev Div had the core value proposition (Ocaml on .Net) undermined by the Win vs Dev Div internal battles that tried and failed to kill .Net.

JoeyJoJoJr

I have been programming for 20 years, and yet despite having used dynamic languages I don’t actually know what it means to leverage dynamic programming techniques. For instance, I’ve never encountered a JavaScript codebase that I have thought couldn’t benefit from just being statically typed with Typescript. I get the impression that dynamic programming, besides the odd untyped line of code, is best used only for extremely specific cases?

waffletower

There is much naïveté among the strongly typed herd. When tasked to create glue code translating between two opposing type systems, which is a very common data engineering task, reaching for a strongly typed language is never the best option for code complexity and speed of development. Yet the hammer will often succeed if you hit hard enough and club the nail back to shape when you invariably bend it.

throwaway2037

    There is much naïveté among the strongly typed herd.

Is exactly the reverse also true? Let me try: "There is much naïveté among the weakly typed herd." For every person who thinks Python or Ruby can be used for everything, there is another person who thinks the same for C++ or Rust.

Also, the example that you gave is incredibly specific:

    When tasked to create glue code translating between two opposing type systems, which is a very common data engineering task

Can you provide a concrete example? And what is "data engineering"? I never heard that term before this post.

waffletower

If you are truly interested in understanding my point of view -- a great way to do it would be to learn how to use this Clojure DSL: https://github.com/redplanetlabs/specter You could also think about why Nathan Marz may have bothered to create it. As for data engineering, I think ChatGPT could tell you a lot, and its training is dated from 2021.