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

41–50 of 333 posts

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

#41

Post by xupybd »

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…

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

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

#42

Post by 2h »

xupybd wrote: post #37

I love F#, I use it professionally. But I agree with everything written in this post. I hate that F# is not a safe choice yet. I wish that it were but it doesn't have the critical mass. That means hiring others is not going to be as easy as finding an existing F# developer. Functional programing is different. I don't think it's hard but it's not what most developers have spent years practicing. So there is a learning…

> Functional programing is different.

I think the problem with this line of thinking is that some people insist on using functional tactics EVERYWHERE, even when it doesn't make sense. I get that its ugly to mix functional and imperative code, and maybe some languages dont even allow that. but they should. thats why I like Go, because sometimes a simple for/while loop IS the correct answer.

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

#43

Post by JoeyJoJoJr »

cjbgkagh wrote: post #31
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 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 we…

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?

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

#45

Post by xupybd »

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

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

#46

Post by lmm »

NegativeLatency wrote: post #40
lmm wrote: post #6

Earlier quoted context omitted.

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# woul…

Rails has generators you’re talking about not ruby, and I’ve seen and worked on some very maintainable rails apps.

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

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

#47

Post by xupybd »

2h wrote: post #42
xupybd wrote: post #37

I love F#, I use it professionally. But I agree with everything written in this post. I hate that F# is not a safe choice yet. I wish that it were but it doesn't have the critical mass. That means hiring others is not going to be as easy as finding an existing F# developer. Functional programing is different. I don't think it's hard but it's not what most developers have spent years practicing. So there is a learning…

> Functional programing is different. I think the problem with this line of thinking is that some people insist on using functional tactics EVERYWHERE, even when it doesn't make sense. I get that its ugly to mix functional and imperative code, and maybe some languages dont even allow that. but they should. thats why I like Go, because sometimes a simple for/while loop IS the correct answer.

Yes I think the The Functional Core, Imperative Shell Pattern is a good way to do things.

But somethings take a bit of ramping up. Like the option type, it is great and works well with pattern matching. If you don't know why exhaustive pattern matching with union types and options instead of nulls is amazing then it just feels like coding with your hands tied.

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

#48

Post by cjbgkagh »

JoeyJoJoJr wrote: post #43
cjbgkagh wrote: post #31

Earlier quoted context omitted.

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

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

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.

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

#49

Post by lostmsu »

Semaphor wrote: post #34
muglug wrote: post #32

Progamming language evangelism is basically a zero-sum game. Some languages don't really intrude on one another's territory — e.g. not that many people are rewriting Ruby programs in Rust — but some very directly compete. So if you want to convince someone to use F#, you have to convince them it's significantly better than some other closely-related language. And that's hard! I have a strong suspicion that the next d…

> JavaScript/TypeScript and Python will become even more popular, to the detriment of everything but Go, C++, and Rust. Why do you see the popularity of C# waning?

Rust might take its place if the tooling would be on par. Personally I'd jump.

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

#50

Post by chrfrasco »

> This is how a new product gets across the chasm. Find a pragmatist in pain. Do whatever-it-takes to make them happy with your product. Then go back and do it again.

Good advice, I think the useful idea is: An excellent product in competition with a very good incumbent is a bad idea. A mediocre product in competition with an absent or terrible incumbent is a great idea

Post reply on HN