Live data from Hacker News

Why F# evangelism isn't working (2015)

ericsink.com

21–30 of 333 posts

Re: Why F# evangelism isn't working (2015)

#21

Earlier quoted context omitted.

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

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.

Re: Why F# evangelism isn't working (2015)

#22

Earlier quoted context omitted.

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

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

Re: Why F# evangelism isn't working (2015)

#24

Earlier quoted context omitted.

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

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.

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.

Re: Why F# evangelism isn't working (2015)

#25
post #8

just as true today as 2015 when the article was written, except C# got even better. While I like the F# language, I don't like the (understandably) abandonware of the small community. I've ported most of my F# stuff to C#, and it's not that much different in that you can program in a functional style in C#. Probably the nicest thing in F# that C# doesn't have is computation expressions.

... or units of measure

This is a surprising gap for most non-ML type systems from what I’ve gathered. I don’t understand the gap, tbh. Most of us aren’t slinging primitive values with no particular domain in mind, it’s weird that we have to encode most of the domain in naming conventions and docs.

Re: Why F# evangelism isn't working (2015)

#26
post #8

just as true today as 2015 when the article was written, except C# got even better. While I like the F# language, I don't like the (understandably) abandonware of the small community. I've ported most of my F# stuff to C#, and it's not that much different in that you can program in a functional style in C#. Probably the nicest thing in F# that C# doesn't have is computation expressions.

On top of your answer and the other, I still think Discriminated Unions are still a big hole in c#. I know they are supposedly working on it, but until they officially release it I'm not believing them.

Re: Why F# evangelism isn't working (2015)

#27

Earlier quoted context omitted.

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.

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 general…

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

Re: Why F# evangelism isn't working (2015)

#29

Earlier quoted context omitted.

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.

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.

It’s syntactically valid JSON.

Re: Why F# evangelism isn't working (2015)

#30

Earlier quoted context omitted.

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

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.

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.

Post reply on HN