4 ms·

Much appreciate your feedback and advice. I was considering using F# instead C# for my potential .NET-based solution. But not because of Microsoft's ML push for

by ablekh 6y ago

Much appreciate your feedback and advice. I was considering using F# instead C# for my potential .NET-based solution. But not because of Microsoft's ML push for F# (which seems to be just a move to achieve feature parity with C# within ML.NET framework, which, by the way, is not as comprehensive as relevant Python ecosystem), but rather because of F#'s meta-programming features. However, the advantages of F# still do not overweight its IMO two main disadvantages: a much more limited (vs. C#) pool of available developers and limited support by tools beyond Microsoft ecosystem (e.g., by JetBrains products).

retendo 6y ago
> a much more limited (vs. C#) pool of available developers I don't plan to hire anyone in the foreseeable future but what I can say is that there's 2 people happily working on the F# codebase at the moment, that do not have any prior experience in the language (professional Swift/ObjC background and played around with other languages). Getting into it is quite easy if you're interested in FP. I wouldn't worry too much about that. Just get some people who are experienced in .NET and some people who are good in FP. > limited support by tools beyond Microsoft ecosystem (e.g., by JetBrains products) I use JetBrains Rider on a Mac, without major problems so far
- ablekh 6y ago
  Fair enough. Thank you, will keep this in mind.
oaiey 6y ago
Google Jetbrains Rider. Do not worry about the pool. The limiting factor in finding good people is the good part not the programming language.
- ablekh 6y ago
  Thank you for sharing your thoughts. I'm aware of JetBrains Rider. In fact, I have installed it on my desktop and used it to explore the above-mentioned .NET boilerplate templates (C#-based). Perhaps, I missed that Rider fully supports F#. Will check it out. Re: finding good people - I certainly agree with importance of focusing on the good part. However, still ... having a significantly larger pool of developers statistically increases chances to find good ones (which is important, especially considering competition with big tech firms in hiring engineering talent).
  - 737maxtw 6y ago
    Does it? I mean, if I see a good developer who is interested in learning F#, that means I have found a good developer who is interested in learning something off the beaten path. For certain organizations that is exactly what they need.
    - ablekh 6y ago
      I think that you're missing my point about the statistical nature of engineering talent hiring. My argument is that you will have higher chances to "see a good developer" in the first place, if relevant pool of potential candidates is larger (of course, under other equal conditions).
      - oaiey 6y ago
        Another aspect of that: do not do functional programming then. There are statistics for .NET which surely also apply to most languages: 10 million C# devs, 1 million VB.NET devs and 100k F# devs. By requiring functional programming the candidate pool shrunk by a factor of 100. There is certainly a higher factor of high talent in FP capable programmers but at the same time the risk for bad hires due to lacking people skills or overly dogmatic work style increases.
        ablekh 6y ago
        Good points. Thank you for bringing them up.
      - kqr 6y ago
        But if you hire "programmers" and train them in F# on the job instead of looking specifically for "F# programmers" you sidestep that problem. My organisations job ad is looking for people with "several years of programming experience by the way we do things in C# and F# but do not expect you to have". Then we weed out the huge majority by issuing a tiny take-home code test (think a few fizzbuzz-style questions) that applicants can complete in whatever language or environment they want. So far, we've received positive feedback on the approach, but also very few truly talented applicants. I think the latter is because we're extremely picky, but I don't know. What I do know is that we wouldn't get better or more qualified applicants by limiting our search to a few languages. Some of the best so far have come with a language we would never have thought to list.

by ablekh 6y ago

retendo 6y ago

> a much more limited (vs. C#) pool of available developers I don't plan to hire anyone in the foreseeable future but what I can say is that there's 2 people happily working on the F# codebase at the moment, that do not have any prior experience in the language (professional Swift/ObjC background and played around with other languages). Getting into it is quite easy if you're interested in FP. I wouldn't worry too much about that. Just get some people who are experienced in .NET and some people who are good in FP. > limited support by tools beyond Microsoft ecosystem (e.g., by JetBrains products) I use JetBrains Rider on a Mac, without major problems so far

ablekh 6y ago
Fair enough. Thank you, will keep this in mind.

oaiey 6y ago

Google Jetbrains Rider. Do not worry about the pool. The limiting factor in finding good people is the good part not the programming language.

ablekh 6y ago
Thank you for sharing your thoughts. I'm aware of JetBrains Rider. In fact, I have installed it on my desktop and used it to explore the above-mentioned .NET boilerplate templates (C#-based). Perhaps, I missed that Rider fully supports F#. Will check it out. Re: finding good people - I certainly agree with importance of focusing on the good part. However, still ... having a significantly larger pool of developers statistically increases chances to find good ones (which is important, especially considering competition with big tech firms in hiring engineering talent).
- 737maxtw 6y ago
  Does it? I mean, if I see a good developer who is interested in learning F#, that means I have found a good developer who is interested in learning something off the beaten path. For certain organizations that is exactly what they need.
  - ablekh 6y ago
    I think that you're missing my point about the statistical nature of engineering talent hiring. My argument is that you will have higher chances to "see a good developer" in the first place, if relevant pool of potential candidates is larger (of course, under other equal conditions).
    - oaiey 6y ago
      Another aspect of that: do not do functional programming then. There are statistics for .NET which surely also apply to most languages: 10 million C# devs, 1 million VB.NET devs and 100k F# devs. By requiring functional programming the candidate pool shrunk by a factor of 100. There is certainly a higher factor of high talent in FP capable programmers but at the same time the risk for bad hires due to lacking people skills or overly dogmatic work style increases.
      - ablekh 6y ago
        Good points. Thank you for bringing them up.
    - kqr 6y ago
      But if you hire "programmers" and train them in F# on the job instead of looking specifically for "F# programmers" you sidestep that problem. My organisations job ad is looking for people with "several years of programming experience by the way we do things in C# and F# but do not expect you to have". Then we weed out the huge majority by issuing a tiny take-home code test (think a few fizzbuzz-style questions) that applicants can complete in whatever language or environment they want. So far, we've received positive feedback on the approach, but also very few truly talented applicants. I think the latter is because we're extremely picky, but I don't know. What I do know is that we wouldn't get better or more qualified applicants by limiting our search to a few languages. Some of the best so far have come with a language we would never have thought to list.