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

81–90 of 333 posts

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

#81

Post by waffletower »

EdwardDiego wrote: post #30
gemstones wrote: post #11

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.

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.

Hahaha, "when the schema is consistent". The strong typing herd keeps thinking it can smash reality into a square hole.

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

#82

Post by bmitc »

xupybd wrote: post #78
throwaway2037 wrote: post #66

Earlier quoted context omitted.

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?

You could have out of order function declarations.

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.

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

#83

Post by Andys »

ericsink wrote: post #68

(Author here) Well this is a blast from the past. Back when I wrote this, I kinda hoped F# would surprise me and gain more traction than I expected. But 8 years later, if anything, it seems like the dominance of C# in the .NET ecosystem has grown. F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.

Seeing your name pop up was a blast from the past for me too - I used to read back in the "The Business of Software" days.. circa 2005 I think?

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

#84

Post by systems »

ericsink wrote: post #68

(Author here) Well this is a blast from the past. Back when I wrote this, I kinda hoped F# would surprise me and gain more traction than I expected. But 8 years later, if anything, it seems like the dominance of C# in the .NET ecosystem has grown. F# is still a great language, but the main fact hasn't changed: C# isn't bad enough for F# to thrive.

I don't think it matters how good or bad C# is, Object Oriented Programming is a mess

Learning, how to use an Object System (a tree of objects/classes) is inherently hard

The current problem with F# is that it doesnt do enough to shield you from objects, it does what it can, but still to use F# effectively, you still need to learn some C# and a lot of API that basically Objects inside Objects inside Objects calling Objects calling Objects and more Objects

OOP is bad because eventually OO systems becomes too complex, OO API is intimidation

Separating Data from Behavior manages complexity better

If the only flaw in C# is knowing which method calls requires the new keyword because its a constructor, and which dont because its a factory, that is bad enough to want to avoid it

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

#85

Post by waffletower »

Hasnep wrote: post #77
throwaway2037 wrote: post #67

Earlier quoted context omitted.

There is much naïveté among the strongly typed herd. Is exactly the reverse also true? Let me try: "There is much naïveté among the weakly typed herd." For every person who thinks Python or Ruby can be used for everything, there is another person who thinks the same for C++ or Rust. Also, the example that you gave is incredibly specific: When tasked to create glue code translating between two opposing type systems, w…

I'm a data engineer, it's a fairly new role so it's not well defined yet, but most data engineers write data pipelines to ingest data into a data warehouse and then transform it for the business to use. I'm not sure why using a static language would make translating data types difficult, but I add as many typehints as possible to my Python so I rarely do anything with dynamic types. I guess they're saying for small t…

Using a static language to manipulate complex types, particularly those sourced from a different type system (say complex nested Avro, SQL, or even complex JSON) is much more awkward when the types cannot be normalized into the language automatically as can be done with dynamic languages. Static languages require more a priori knowledge of data types, and are very awkward at handling collections with diverse type membership. Data has many forms in reality -- dynamic languages are much more effective at manipulating data on its own terms.

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

#86

Post by bawolff »

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

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

#87

Post by EdwardDiego »

waffletower wrote: post #81
EdwardDiego wrote: post #30

Earlier quoted context omitted.

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.

Hahaha, "when the schema is consistent". The strong typing herd keeps thinking it can smash reality into a square hole.

K.

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

#88

Post by fulafel »

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…

Languages are so fundamental, it's philosophy, and tools of expression. Debating better ways of doing these things is something that naturally happens in our heads and by extension in discours - the motivations aren't necessarily extrinsic.

Even if your suspicion is right - since so many new programmers enter the field, absolute community sizes can still easily grow and hence we get more real-world viable languages.

Personally I think we've witnessed an acceleration in the coming and going of languages. Go, Rust, TypeScript, Clojure, Elixir, Zig, etc. And C++ is being dethroned in many more application areas than seemed likely only few years ago. And the GPU realm is still nearly entirely untouched territory. Plus the AI craze may yet stir the soup significantly.

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

#89

Post by jayd16 »

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…

C# will stay because Microsoft will push it. Honestly what makes Go so special? I could see another language or even Java or C# get their AOT story together and retake what was lost to Go.

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

#90

Post by waffletower »

throwaway2037 wrote: post #67
waffletower wrote: post #60

Earlier quoted context omitted.

There is much naïveté among the strongly typed herd. When tasked to create glue code translating between two opposing type systems, which is a very common data engineering task, reaching for a strongly typed language is never the best option for code complexity and speed of development. Yet the hammer will often succeed if you hit hard enough and club the nail back to shape when you invariably bend it.

There is much naïveté among the strongly typed herd. Is exactly the reverse also true? Let me try: "There is much naïveté among the weakly typed herd." For every person who thinks Python or Ruby can be used for everything, there is another person who thinks the same for C++ or Rust. Also, the example that you gave is incredibly specific: When tasked to create glue code translating between two opposing type systems, w…

If you are truly interested in understanding my point of view -- a great way to do it would be to learn how to use this Clojure DSL: https://github.com/redplanetlabs/specter You could also think about why Nathan Marz may have bothered to create it. As for data engineering, I think ChatGPT could tell you a lot, and its training is dated from 2021.
Post reply on HN