Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why F# evangelism isn't working (2015)

ericsink.com

Post reply on HN
Print view View original

11–20 of 333 posts

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

#11

Post by gemstones »

EdwardDiego wrote: post #4
gemstones wrote: post #3

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

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.

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

#12

Post by n2d4 »

jacamera wrote: post #10
gemstones wrote: post #3

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

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.

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

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

#13

Post by gemstones »

jacamera wrote: post #10
gemstones wrote: post #3

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

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.

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.

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

#14

Post by slfjw____ »

Likely will never use again

* two async models present: task (C#) & async (f#)

* horrible async performance: perhaps fixed by native task & FSM transformation

* two error handling models: Result (monadic but without do notation) & C# style Exceptions

* not rich in community libraries, like a desert & abandonware

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

#15

Post by jacamera »

I feel like this article is dead on. It's old but the principles still hold true.

> Because C# is really, really good.

The first language I learned was VB.net because I thought "Visual Basic" sounded easy. I quickly moved to C# because it was more popular. I've always been curious about F# but never invested the time to learn it exactly because C# never caused me enough pain.

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

#16

Post by nick__m »

gemstones wrote: post #11
EdwardDiego wrote: post #4

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.

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.

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

#17

Post by KurtMueller »

keithnz wrote: 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

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

#18

Post by jacamera »

gemstones wrote: post #13
jacamera wrote: post #10

Earlier quoted context omitted.

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.

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 generally poor performers.

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

#19

Post by wly_cdgr »

It doesn't help that C# has a much, much better name for the purposes of appealing to Pragmatists (in the article's terminology). Every Pragmatist knows that C is a trusted and proven language. So, something that is an improvement or iteration on C is probably fine, too. But what is F? No one knows.

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

#20

Post by throwa18991900 »

gemstones wrote: post #11
EdwardDiego wrote: post #4

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.

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.

Post reply on HN