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