8 ms·

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 cand

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.

EdwardDiego 3y ago
I found F# great for dynamic programming, do you recall what tripped them up?
- gemstones 3y ago
  Parsing realistic (messy) JSON, usually. I would have expected F# to shine at that due to type providers, so it was doubly surprising to me. The F# candidates I've seen spend most of the interview manipulating the data.
  - nick__m 3y ago
    Those F# candidates would have been be better to use C# to do the adhoc data wrangling and F# for algorithmic part of the program.
    - FrustratedMonky 3y ago
      Isn't ad-hoc data wrangling the feature of F#? Why are so many people here against F# for reading/manipulating ad-hoc data, that's what it is good for.
  - throwa18991900 3y ago
    I've seen the opposite, and have seen some pretty big fast large professional systems being built in it. Admittedly most of them are closed source, and the community contribution allowed to be made is small. Most of the developers using it normally just market themselves as C# developers when they change job because of some of the above opinions they see online. Have seen speed comparisons compared to other similar tiered languages internally where F# shines with less code as well particuarly around math (C# is just starting to catch up here). Even seen dynamic problems solved in it to your point in a professional setting to speed up very often run calculations to a large customer base. However technical capability and efficiency of the tool isn't the only concern picking up the comments in this thread so far. The herd effect sadly can make people nervous creating a barrier for people to try it especially if career is in it. What other people think of it, and their preconceived notion can matter.
  - yawaramin 3y ago
    This is likely because people don't have enough real-world experience with functional programming paradigm techniques like 'parse, don't validate' and modelling only the parts needed to handle dynamic input, e.g. as shown here https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/ https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ... It's unfortunate that they decided to pick F# on such problems when they didn't have the (mental) toolkit to tackle them, but I think it speaks more to people being really eager to communicate their enthusiasm for FP. I wouldn't try to ascribe any higher meaning to it.
  - eyelidlessness 3y ago
    This is, from a distance, fascinating anecdata. I would expect F# itself to excel in this area (type oriented development being a huge selling point), and people who’ve chosen it to be attracted to those parts of F# which should excel for it. I’m often surprised when my at-a-distance expectations don’t meet reality, but not so often astonished by it.
  - cjbgkagh 3y ago
    TypeProviders don't do well with messy JSON and are finicky at the best of time, the last thing I'd rely on during an interview. Depends on what you mean by messy? Non-conforming JSON? A custom FParsec parser might be able to sensibly extract the data. If it is conforming to JSON then you'd use normal F# code to work with the standard JSON parsers.
    - gemstones 3y ago
      It’s syntactically valid JSON.
      - cjbgkagh 3y ago
        I don't know then, LinqToJson is a pretty good starting point for F#
  - EdwardDiego 3y ago
    How messy is the JSON exactly? Type providers are awesome when the schema is consistent. But tbh, from what little I know, I'd be expecting you to expect me to solve the issue from first principles. So using a "and then magic" technique might be something interviewees shy from.
    - waffletower 3y ago
      Hahaha, "when the schema is consistent". The strong typing herd keeps thinking it can smash reality into a square hole.
      - EdwardDiego 3y ago
        K.
      - FrustratedMonky 3y ago
        This sentiment is surprising. Doesn't Python crash a lot at run-time, specifically because some 'dynamic types' clash. They become a real type at some point, at compile time or at run time. Why wait for the crash to figure it out?
  - xupybd 3y ago
    I find I spend a lot of time building records for JSON data. Type providers are nice but I've found them to be a little untrustworthy. Normally now I ask Chat GPT to create an F# record from the JSON. Then go through and check everything line by line, redo the types to something sane and use that. But if it were a quick script to do a one off then a type provider will work well.
keyle 3y ago
Are you implying this is a F# problem? What language do candidates do well in? Is F# too approachable due to its closeness to C#, popular with C# professionals, and therefore not approached as a functional programming language as much as a C# extension?
- gemstones 3y ago
  I've seen Elixir, Python, Javascript, Java, Scala, Clojure, C#, Go, and more; not sure who is at the top, but F# is 100% at the bottom (just in my personal experience.) I wouldn't chalk it up to being too approachable.
  - FrustratedMonky 3y ago
    I did think F# had a pretty steep learning curve. So, not approachable. But how did it compare to Scala/Clojure? Those seem to have similar problem with being approachable, and adapted.
lmm 3y ago
I disagree on almost every count: it's a badly written essay, but it makes a valid point. > 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. Does this mean that you're measuring, like, how fast someone can deploy a CRUD webapp in the given language? I can imagine F# would do poorly on that kind of metric; it's optimized for maintainability and doesn't take unprincipled shortcuts, whereas something like Ruby lets you type one line and it will blat out a bunch of defaults via unmaintainable magic. > 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. I don't think it's a general problem; almost everyone who spends any significant time working in F# returns to C# reluctantly if at all. It's already a "better" language in the sense of how nice it is to program in and how productive a programmer feels when doing so. But those aren't the metrics that matter.
- NegativeLatency 3y ago
  Rails has generators you’re talking about not ruby, and I’ve seen and worked on some very maintainable rails apps.
  - lmm 3y ago
    > Rails has generators you’re talking about not ruby They may not be built into Ruby-the-language but they're very much part of Ruby-the-development-community. > I’ve seen and worked on some very maintainable rails apps I've seen far more upgrade breakages in apps built on rails than any other stack.
    - girvo 3y ago
      > I've seen far more upgrade breakages in apps built on rails than any other stack. React Native would like to argue with you on that point
jacamera 3y ago
I'd love to know what dynamic programming exercises you're asking interviewees to complete in the timespan of an interview that wouldn't show up on LeetCode.
- n2d4 3y ago
  I think they meant it in the literal sense; "programming requirements that are dynamic", not dynamic programming algorithms you'd use for the knapsack problem :)
  - paulddraper 3y ago
    "Ad hoc" probably being a less ambiguous wording
- gemstones 3y ago
  It involves a lot of preparation on my part. The ask for the candidate is usually a small service that does some trivial thing in our business domain. The interview problem is usually making a script to manipulate the data, or serve an API endpoint that calls my API and transform the data to match a certain output shape.
  - jacamera 3y ago
    Interesting. So is actually executing the script, server, or API call without errors part of the interview? Is that what makes them "practical" or is it because the data structures and algorithms are related to your business domain? Not trying to nitpick, your comment just piqued my curiosity because you made the point of distinguishing your exercises from leetcode and also stated that those who chose F# were generally poor performers.
    - gemstones 3y ago
      It is, but I’m very forgiving of scripts/services that don’t run right the first time if it’s clear the logic is on the right track. If your logic is sound and you’re stuck on an esoteric error, I usually count that the same as completing the exercise. (There have been cases where the person shows no debugging ability at all, which I do treat as a problem. But if you’re reading the error and there’s just not enough time for a fix, eh you were close enough.)
cjbgkagh 3y ago
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 3y ago
  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?
  - hbrn 3y ago
    > For instance, I’ve never encountered a JavaScript codebase that I have thought couldn’t benefit from just being statically typed with Typescript That's the type bias. If you look at a non-typed codebase, it always feels like it will be better with types. But if you had a chance to go back in time and start the same codebase in Typescript, it would actually come out way worse than what you have today. Types can be great when used sparingly, but with Typescript everyone seems to fall into a trap of constantly creating and then solving "type puzzles" instead of building what matters. If you're doing Typescript, your chances of becoming a product engineer are slim.
  - cjbgkagh 3y ago
    To be clear I wasn't referring 'dynamic programming' but as you say, the use of a dynamic language, or programming without types, mimicking what I assumed the original poster I replied to meant. My guess is that interviewees wishing to return to the typed world they are comfortable with would first try to type the JSON they are working with. Given that the JSON is messy this could be an unbounded amount of work that is unlikely to pay-off within the span of an interview.
Fervicus 3y ago
> 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. Maybe I am mistaken here, but it seems to me that the line you are quoting from the essay implies the opposite of what you said.
xupybd 3y ago
>If I had to pick a language that predicted you'll do poorly on a practical interview exercise, I would pick F# every time As someone that has just spent a while learning F# and really enjoys it, this makes me sad. I hope that I don't have some trait that drew me to F# that also causes me to be less competent.
- chlorion 3y ago
  Don't be sad. This is definitely a skewed perspective from a single person which makes it worse than useless as a way to gauge a random persons competence. I'm sure you could find a person who would claim this same exact thing for any language if you searched around a bit. To derive a useful conclusion you would need to control for all of the factors involved in the interviews and objectively measure their performance compared to other people's, anything less than that is completely useless at best.
- epgui 3y ago
  I don’t think you have any good reason to think you’re inherently less competent. The most important thing is to always be learning. You’ll never be done, embrace that and rejoice in it. Most people more or less stop learning in early adulthood: don’t do that, and you’ll eventually be ahead of the pack.
- FrustratedMonky 3y ago
  I took this post about F# talent to really imply -> F# has language features that protect or handle 'some concept', and then when the programmer was asked to do something else, they had trouble because they wouldn't normally have had to deal with it in F#. It isn't necessarily the F# programmers skill level, if dealing with other languages and needing more code to cover gaps, and knowing the gaps. Can be a great Java programmer, now go do something in assembly, doesn't reflect on the Java skills.
WalterBright 3y ago
> They prefer the safety of the herd I.e. social proof
bloaf 3y ago
That's interesting, because I've tried to use F# several times, and never really felt comfortable. I've written in a bunch of different languages and F# is probably the most disappointing because of how much I want to like it. I feel like F# deceptively presents itself as simple, when in reality it is closer to C# in complexity. I've written in languages that are actually simple (tcl) and it is a joy. I've written in languages that are unashamedly complex (Wolfram language) and that is also fun. But F# occupies that weird middle ground where it seems easy to do what you want, but for some reason you trip over your own shoelaces every time you take a step.
- AdeptusAquinas 3y ago
  I wrote F# for a long time, and there were definite phases to learning and becoming comfortable with it. For example, it's often pitched as a functional language but in reality its a functional-first hybrid language on the .NET framework - to be efficient with it is to embrace this and write imperatively when you need to. Pure syntax wise, its pretty nice, though having a single pass compiler makes it a bit dated feeling compared to other languages.
  - throwaway2037 3y ago
    though having a single pass compiler makes it a bit dated feeling compared to other languages Can you please share how F# could improve with a multi-pass compiler?
    - xupybd 3y ago
      You could have out of order function declarations.
      - bmitc 3y ago
        Forcing linear dependence of files and definitions is considered a feature of F#. In codebases that allow out of order definitions, things get wild real quick.
paulddraper 3y ago
Really? In my experience, the worst performance is by C++ candidates. Why? Not because C++ is bad, or attracts bad programmers. Rather, because if that's the language you reach for a quick solve, you probably don't know very much, and that says something.
bmitc 3y ago
That's weird. I use F# because of its pragmaticism. Every other language tacks on feature after feature. I would say my F# code is boring, which is what I love about F#. And it's especially boring compared to other functional languages. The other pragmatic functional languages are Erlang and Elixir. I would consider most popular languages, like C#, Java, and Python decidely unpragmatic as languages. There's way too many hoops to jump through to concisely describe the problem domain. In F#, I define some types that describe the domain, write some functions, and move on. It's that easy.
bawolff 3y ago
I wonder if that is because people who pick obscure languages are more interested in looking cool than getting the job done. Like in an interview setting, even if they say you can choose any language, it is probably a safer bet to go with something the interviewer has probably seen before.
DonHopkins 3y ago
There should be a thing call "Yeetcode" that rewards you for deleting as much code as you can and still solving the problem.
ak_111 3y ago
Just curious what kind of career did you have that enabled you to have a long stint as function programmer? The fact that you don't use Leet code makes it also sound you are not FAANG so makes it more intriguing.
e12e 3y ago
Curious about what one of your typical "practical exercises" looks like? I'm not a great fan of f# (it's not rational - but every time I've tried to dip my toes, something in the syntax has felt... Tedious? In a way that for example StandardML does not). But it still seems like an eminently powerful and pragmatic language, so I'm surprised by your experience. Ed: I see this was addressed downthread: https://news.ycombinator.com/item?id=36133560 https://news.ycombinator.com/item?id=36133560 https://news.ycombinator.com/item?id=36133578 https://news.ycombinator.com/item?id=36133578 Fascinating that fsharpers trip up on ad- hoc json wrangling - to be fair i used to agonize over nested lists/association lists in lisp - rather than doing the "professional" thing and YOLO assume that three levels down, behind :user - there's a fifth element :email...

EdwardDiego 3y ago

I found F# great for dynamic programming, do you recall what tripped them up?

gemstones 3y ago
Parsing realistic (messy) JSON, usually. I would have expected F# to shine at that due to type providers, so it was doubly surprising to me. The F# candidates I've seen spend most of the interview manipulating the data.
- nick__m 3y ago
  Those F# candidates would have been be better to use C# to do the adhoc data wrangling and F# for algorithmic part of the program.
  - FrustratedMonky 3y ago
    Isn't ad-hoc data wrangling the feature of F#? Why are so many people here against F# for reading/manipulating ad-hoc data, that's what it is good for.
- throwa18991900 3y ago
  I've seen the opposite, and have seen some pretty big fast large professional systems being built in it. Admittedly most of them are closed source, and the community contribution allowed to be made is small. Most of the developers using it normally just market themselves as C# developers when they change job because of some of the above opinions they see online. Have seen speed comparisons compared to other similar tiered languages internally where F# shines with less code as well particuarly around math (C# is just starting to catch up here). Even seen dynamic problems solved in it to your point in a professional setting to speed up very often run calculations to a large customer base. However technical capability and efficiency of the tool isn't the only concern picking up the comments in this thread so far. The herd effect sadly can make people nervous creating a barrier for people to try it especially if career is in it. What other people think of it, and their preconceived notion can matter.
- yawaramin 3y ago
  This is likely because people don't have enough real-world experience with functional programming paradigm techniques like 'parse, don't validate' and modelling only the parts needed to handle dynamic input, e.g. as shown here https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-type-systems-are-not-inherently-more-open/ https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ... It's unfortunate that they decided to pick F# on such problems when they didn't have the (mental) toolkit to tackle them, but I think it speaks more to people being really eager to communicate their enthusiasm for FP. I wouldn't try to ascribe any higher meaning to it.
- eyelidlessness 3y ago
  This is, from a distance, fascinating anecdata. I would expect F# itself to excel in this area (type oriented development being a huge selling point), and people who’ve chosen it to be attracted to those parts of F# which should excel for it. I’m often surprised when my at-a-distance expectations don’t meet reality, but not so often astonished by it.
- cjbgkagh 3y ago
  TypeProviders don't do well with messy JSON and are finicky at the best of time, the last thing I'd rely on during an interview. Depends on what you mean by messy? Non-conforming JSON? A custom FParsec parser might be able to sensibly extract the data. If it is conforming to JSON then you'd use normal F# code to work with the standard JSON parsers.
  - gemstones 3y ago
    It’s syntactically valid JSON.
    - cjbgkagh 3y ago
      I don't know then, LinqToJson is a pretty good starting point for F#
- EdwardDiego 3y ago
  How messy is the JSON exactly? Type providers are awesome when the schema is consistent. But tbh, from what little I know, I'd be expecting you to expect me to solve the issue from first principles. So using a "and then magic" technique might be something interviewees shy from.
  - waffletower 3y ago
    Hahaha, "when the schema is consistent". The strong typing herd keeps thinking it can smash reality into a square hole.
    - EdwardDiego 3y ago
      K.
    - FrustratedMonky 3y ago
      This sentiment is surprising. Doesn't Python crash a lot at run-time, specifically because some 'dynamic types' clash. They become a real type at some point, at compile time or at run time. Why wait for the crash to figure it out?
- xupybd 3y ago
  I find I spend a lot of time building records for JSON data. Type providers are nice but I've found them to be a little untrustworthy. Normally now I ask Chat GPT to create an F# record from the JSON. Then go through and check everything line by line, redo the types to something sane and use that. But if it were a quick script to do a one off then a type provider will work well.

keyle 3y ago

Are you implying this is a F# problem? What language do candidates do well in? Is F# too approachable due to its closeness to C#, popular with C# professionals, and therefore not approached as a functional programming language as much as a C# extension?

gemstones 3y ago
I've seen Elixir, Python, Javascript, Java, Scala, Clojure, C#, Go, and more; not sure who is at the top, but F# is 100% at the bottom (just in my personal experience.) I wouldn't chalk it up to being too approachable.
- FrustratedMonky 3y ago
  I did think F# had a pretty steep learning curve. So, not approachable. But how did it compare to Scala/Clojure? Those seem to have similar problem with being approachable, and adapted.

lmm 3y ago

I disagree on almost every count: it's a badly written essay, but it makes a valid point. > 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. Does this mean that you're measuring, like, how fast someone can deploy a CRUD webapp in the given language? I can imagine F# would do poorly on that kind of metric; it's optimized for maintainability and doesn't take unprincipled shortcuts, whereas something like Ruby lets you type one line and it will blat out a bunch of defaults via unmaintainable magic. > 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. I don't think it's a general problem; almost everyone who spends any significant time working in F# returns to C# reluctantly if at all. It's already a "better" language in the sense of how nice it is to program in and how productive a programmer feels when doing so. But those aren't the metrics that matter.

NegativeLatency 3y ago
Rails has generators you’re talking about not ruby, and I’ve seen and worked on some very maintainable rails apps.
- lmm 3y ago
  > Rails has generators you’re talking about not ruby They may not be built into Ruby-the-language but they're very much part of Ruby-the-development-community. > I’ve seen and worked on some very maintainable rails apps I've seen far more upgrade breakages in apps built on rails than any other stack.
  - girvo 3y ago
    > I've seen far more upgrade breakages in apps built on rails than any other stack. React Native would like to argue with you on that point

jacamera 3y ago

I'd love to know what dynamic programming exercises you're asking interviewees to complete in the timespan of an interview that wouldn't show up on LeetCode.

n2d4 3y ago
I think they meant it in the literal sense; "programming requirements that are dynamic", not dynamic programming algorithms you'd use for the knapsack problem :)
- paulddraper 3y ago
  "Ad hoc" probably being a less ambiguous wording
gemstones 3y ago
It involves a lot of preparation on my part. The ask for the candidate is usually a small service that does some trivial thing in our business domain. The interview problem is usually making a script to manipulate the data, or serve an API endpoint that calls my API and transform the data to match a certain output shape.
- jacamera 3y ago
  Interesting. So is actually executing the script, server, or API call without errors part of the interview? Is that what makes them "practical" or is it because the data structures and algorithms are related to your business domain? Not trying to nitpick, your comment just piqued my curiosity because you made the point of distinguishing your exercises from leetcode and also stated that those who chose F# were generally poor performers.
  - gemstones 3y ago
    It is, but I’m very forgiving of scripts/services that don’t run right the first time if it’s clear the logic is on the right track. If your logic is sound and you’re stuck on an esoteric error, I usually count that the same as completing the exercise. (There have been cases where the person shows no debugging ability at all, which I do treat as a problem. But if you’re reading the error and there’s just not enough time for a fix, eh you were close enough.)

cjbgkagh 3y ago

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 3y ago
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?
- hbrn 3y ago
  > For instance, I’ve never encountered a JavaScript codebase that I have thought couldn’t benefit from just being statically typed with Typescript That's the type bias. If you look at a non-typed codebase, it always feels like it will be better with types. But if you had a chance to go back in time and start the same codebase in Typescript, it would actually come out way worse than what you have today. Types can be great when used sparingly, but with Typescript everyone seems to fall into a trap of constantly creating and then solving "type puzzles" instead of building what matters. If you're doing Typescript, your chances of becoming a product engineer are slim.
- cjbgkagh 3y ago
  To be clear I wasn't referring 'dynamic programming' but as you say, the use of a dynamic language, or programming without types, mimicking what I assumed the original poster I replied to meant. My guess is that interviewees wishing to return to the typed world they are comfortable with would first try to type the JSON they are working with. Given that the JSON is messy this could be an unbounded amount of work that is unlikely to pay-off within the span of an interview.

Fervicus 3y ago

> 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. Maybe I am mistaken here, but it seems to me that the line you are quoting from the essay implies the opposite of what you said.

xupybd 3y ago

>If I had to pick a language that predicted you'll do poorly on a practical interview exercise, I would pick F# every time As someone that has just spent a while learning F# and really enjoys it, this makes me sad. I hope that I don't have some trait that drew me to F# that also causes me to be less competent.

chlorion 3y ago
Don't be sad. This is definitely a skewed perspective from a single person which makes it worse than useless as a way to gauge a random persons competence. I'm sure you could find a person who would claim this same exact thing for any language if you searched around a bit. To derive a useful conclusion you would need to control for all of the factors involved in the interviews and objectively measure their performance compared to other people's, anything less than that is completely useless at best.
epgui 3y ago
I don’t think you have any good reason to think you’re inherently less competent. The most important thing is to always be learning. You’ll never be done, embrace that and rejoice in it. Most people more or less stop learning in early adulthood: don’t do that, and you’ll eventually be ahead of the pack.
FrustratedMonky 3y ago
I took this post about F# talent to really imply -> F# has language features that protect or handle 'some concept', and then when the programmer was asked to do something else, they had trouble because they wouldn't normally have had to deal with it in F#. It isn't necessarily the F# programmers skill level, if dealing with other languages and needing more code to cover gaps, and knowing the gaps. Can be a great Java programmer, now go do something in assembly, doesn't reflect on the Java skills.

WalterBright 3y ago

> They prefer the safety of the herd I.e. social proof

bloaf 3y ago

That's interesting, because I've tried to use F# several times, and never really felt comfortable. I've written in a bunch of different languages and F# is probably the most disappointing because of how much I want to like it. I feel like F# deceptively presents itself as simple, when in reality it is closer to C# in complexity. I've written in languages that are actually simple (tcl) and it is a joy. I've written in languages that are unashamedly complex (Wolfram language) and that is also fun. But F# occupies that weird middle ground where it seems easy to do what you want, but for some reason you trip over your own shoelaces every time you take a step.

AdeptusAquinas 3y ago
I wrote F# for a long time, and there were definite phases to learning and becoming comfortable with it. For example, it's often pitched as a functional language but in reality its a functional-first hybrid language on the .NET framework - to be efficient with it is to embrace this and write imperatively when you need to. Pure syntax wise, its pretty nice, though having a single pass compiler makes it a bit dated feeling compared to other languages.
- throwaway2037 3y ago
  though having a single pass compiler makes it a bit dated feeling compared to other languages Can you please share how F# could improve with a multi-pass compiler?
  - xupybd 3y ago
    You could have out of order function declarations.
    - bmitc 3y ago
      Forcing linear dependence of files and definitions is considered a feature of F#. In codebases that allow out of order definitions, things get wild real quick.

paulddraper 3y ago

Really? In my experience, the worst performance is by C++ candidates. Why? Not because C++ is bad, or attracts bad programmers. Rather, because if that's the language you reach for a quick solve, you probably don't know very much, and that says something.

bmitc 3y ago

That's weird. I use F# because of its pragmaticism. Every other language tacks on feature after feature. I would say my F# code is boring, which is what I love about F#. And it's especially boring compared to other functional languages. The other pragmatic functional languages are Erlang and Elixir. I would consider most popular languages, like C#, Java, and Python decidely unpragmatic as languages. There's way too many hoops to jump through to concisely describe the problem domain. In F#, I define some types that describe the domain, write some functions, and move on. It's that easy.

bawolff 3y ago

I wonder if that is because people who pick obscure languages are more interested in looking cool than getting the job done. Like in an interview setting, even if they say you can choose any language, it is probably a safer bet to go with something the interviewer has probably seen before.

DonHopkins 3y ago

There should be a thing call "Yeetcode" that rewards you for deleting as much code as you can and still solving the problem.

ak_111 3y ago

Just curious what kind of career did you have that enabled you to have a long stint as function programmer? The fact that you don't use Leet code makes it also sound you are not FAANG so makes it more intriguing.

e12e 3y ago

Curious about what one of your typical "practical exercises" looks like? I'm not a great fan of f# (it's not rational - but every time I've tried to dip my toes, something in the syntax has felt... Tedious? In a way that for example StandardML does not). But it still seems like an eminently powerful and pragmatic language, so I'm surprised by your experience. Ed: I see this was addressed downthread: https://news.ycombinator.com/item?id=36133560 https://news.ycombinator.com/item?id=36133560 https://news.ycombinator.com/item?id=36133578 https://news.ycombinator.com/item?id=36133578 Fascinating that fsharpers trip up on ad- hoc json wrangling - to be fair i used to agonize over nested lists/association lists in lisp - rather than doing the "professional" thing and YOLO assume that three levels down, behind :user - there's a fifth element :email...