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

The Problem with F# Evangelism

thomasbandt.com

Post reply on HN
Print view View original

81–90 of 203 posts

Re: The Problem with F# Evangelism

#81

Post by agentultra »

boondaburrah wrote: post #25
sitkack wrote: post #8

The best way to get someone to tune out when you are trying to convince them to get out their . bubble is to casually introduce words that they don't know. By doing this, you separate yourself from the listener, giving a clear delineation between the noob and the l337 wizard. It also helps to feign surprise, "you dont know about monadic entropy lenses?" or use the word _just_ as in "Just run the parser combinator in…

This is my biggest problem when trying to work in ecmascript and when people ask me if I know things like "mapreduce." They've come up with different words for things, and it drives me nuts. Specifically mapreduce: They call filtering mapping, and mapping reducing. I think this is where Redux gets it's "reducers" from. They aren't reducers damnit! It took me weeks to figure out what the hell they were talking about.

I think Peyton and Co. were right to stick with the mathematical terms when they introduced various concepts to Haskell over the years.

We're now seeing the React community go bananas over "Higher-Order Components." It took one look at it and realized I was looking at Reader and thought, why all the verbiage?

Now I write my React applications using GHCJS and I don't have to mess around with reading terrible backtraces and all the detective work of figuring out how a type error manifested itself. But these communities are forced to repeat history instead of learn from them.

The salient point TFA made for me was that language and evangelism are part of the problem. You can't dive into Haskell if you've been a C# programmer for the last 10 years and expect to have the same level of proficiency you've enjoyed all that time. The most effective way to learn Haskell, F#, et al is to literally start over. And that's a hard sell.

The benefit is that these languages weren't invented: they were discovered. By learning them you'll be learning foundational principles from first-order logic, set theory, and category theory that will make you a better programmer. You can take these principles to any programming language and they will continue to work because it's all maths.

Re: The Problem with F# Evangelism

#82

Post by phillipcarter »

mevile wrote: post #44
d--b wrote: post #27

F# problems from a C# developer point of view: #1 tooling: visual studio integration of F# is poor. You don't get cross language usage reference, so you lose all the benefits of static typic. Projects and references are a mess. Being primarily a scripting language, it feels like a toy language #2 compatibility with C# is poorly done. That F# functions cannot be consumed as C# lambda is a real mess. Boxing / unboxing…

This is what I agree with. I would love to write F#, I write Haskell on Windows, I love functional programming, but jesus the tooling around F# is broken, at least for someone not familiar with it. I can write, compile and run a small example program in C# or C++ in visual studio in minutes, but last I tried, even after spending half a day looking through how to get it done, I couldn't get the F# tooling to work for…

Could you clarify what you had problems with? F# comes with Visual Studio (and VS for Mac), has templates, and builds/runs/debugs/etc out of the box. No need to configure beyond checking "F# language support" in the installer for VS 2017 (and in some cases, the Workloads in that installer come with F# already-checked).

Re: The Problem with F# Evangelism

#83

Post by nurettin »

jasim wrote: post #49
zubspace wrote: post #34

Good post. I really hoped for some f# code after listing all those scenarios where c# fails. Anyway. I work in a c# shop with a large monolithic code base developed by a small team with lots of fluctuations over more than 10 years. I have no functional programming experience at all. I love c# because we actually try to keep the code as simple and linear as possible and only introduce complexity in certain areas if pe…

I'll tell you my experience. I never liked the arguments about reduced bugs or concise code. As a programmer the reason I would use F# (or OCaml, or Haskell, or Elm, or PureScript) is because it increases by day-to-day well-being. I'm happier writing Typed FP because the system is very concrete in my head as I work with it. In a dynamic language, there is always a nagging uncertainty about the system - if you're usin…

In Delphi, I hide this kind of complexity behind methods which check everything for nulls and types at runtime. I imagine I'd do the same thing in C#, too. So if I have json = TJSON.parse('{}'); json.Node['something'].Nodes[0].each(procedure(pNode: TJSONNode) begin; list.add(pNode.GetValue()); end); { Nodes and Node properties actually create empty nodes and keep a debug string to show you where exactly your code failed so you can go back and take a look at which assumption was wrong. I then cleanup everything when the main node is freed.

So my point is; it all depends on how you code something, the language may do it at compile time to prevent runtime assertions, but that also comes with extra baggage (I assume you need to write more code to define your types, function call conditions and mappings)

Re: The Problem with F# Evangelism

#84

Post by d--b »

phillipcarter wrote: post #33
d--b wrote: post #27

F# problems from a C# developer point of view: #1 tooling: visual studio integration of F# is poor. You don't get cross language usage reference, so you lose all the benefits of static typic. Projects and references are a mess. Being primarily a scripting language, it feels like a toy language #2 compatibility with C# is poorly done. That F# functions cannot be consumed as C# lambda is a real mess. Boxing / unboxing…

> #1 tooling: visual studio integration of F# is poor. You don't get cross language usage reference, so you lose all the benefits of static typic. Projects and references are a mess. Being primarily a scripting language, it feels like a toy language Could you clarify what you mean here? Although things like Go to Definition and Find all References don't work across C#/F# boundaries (yet), but you absolutely get Intel…

You get intellisense alright. But using C#, I never need to #open the namespaces myself for it to find the types I am using or the extension methods I need. (Maybe this is because I use resharper, but still, it really slows me down).

Also the benefits of static typing are that it makes it easy to refactor. Here if I change things in C#, I need to grep my F# scripts for usage, it's a real pain.

Re: The Problem with F# Evangelism

#85

Post by d--b »

brianberns wrote: post #36
d--b wrote: post #27

F# problems from a C# developer point of view: #1 tooling: visual studio integration of F# is poor. You don't get cross language usage reference, so you lose all the benefits of static typic. Projects and references are a mess. Being primarily a scripting language, it feels like a toy language #2 compatibility with C# is poorly done. That F# functions cannot be consumed as C# lambda is a real mess. Boxing / unboxing…

I hardly think the lack of a cross language usage reference means that you lose all the benefits of static typing. I don't see F# as primarily a scripting language at all. It builds executables just as well as C# does. F# and C# classes are very compatible, since they're both .NET. If you expose F#-only features (e.g. currying), then obviously C# isn't going to be able to use your API as well.

It just adds up, and right now the combination of these annoyances outweighs the benefits of using F# for me.

Re: The Problem with F# Evangelism

#86

Post by phillipcarter »

pjmlp wrote: post #80
phillipcarter wrote: post #76

Earlier quoted context omitted.

This is for the .NET Core tooling support part of F#, and as we've stated in the blog post, we prioritized the quality of cross-platform usage here. You're free to disagree with this prioritization, but please don't craft a narrative about the relationship between F# and Microsoft that can mislead people as you did before.

If the issues faced by your team were related to C# I assume management would have taken other path. And this is the reason why none of our customers wants to even discuss integrating F# into C# projects.

Perhaps it's worth taking a different viewpoint. With VS 2017, no single release updates every part of the product to the latest things. For example, UWP does not support .NET Standard 2.0 yet. That did not put the VS 2017 15.3 release on hold. Similarly, although F# fully supports .NET Core and .NET Standard 2.0 with this release, the tooling quality wasn't high enough for us to declare the associated tooling support in VS as fully supported. That also did not put the VS 2017 15.3 release on hold. This because we're already three updates into Visual Studio, and it's only been 6 months since its release. Visual Studio updates faster and teams can release things easier and more rapidly without needing to wait for everything else. This is a really good thing.

Re: The Problem with F# Evangelism

#87

Post by brianberns »

d--b wrote: post #85
brianberns wrote: post #36

Earlier quoted context omitted.

I hardly think the lack of a cross language usage reference means that you lose all the benefits of static typing. I don't see F# as primarily a scripting language at all. It builds executables just as well as C# does. F# and C# classes are very compatible, since they're both .NET. If you expose F#-only features (e.g. currying), then obviously C# isn't going to be able to use your API as well.

It just adds up, and right now the combination of these annoyances outweighs the benefits of using F# for me.

This is how my C# developers feel as well. Personally, I've concluded that F# is a more reasonable language than C#, so I see these "annoyances" as challenges that are not a big problem.

Re: The Problem with F# Evangelism

#88

Post by d--b »

nickpeterson wrote: post #26

This article retreads common complaints about the F# experience for outsiders that I've seen numerous time. I'm going to go a different direction. The problem with the F# community is that they keep asking how to convince C# developers to use F#. I'm convinced that is not the right way to grow the F# ecosystem. Most C# developers tend to come from enterprise and have a set of values and practices that is generally at…

I don't think that's correct. I think the main strength of F# lies in its interoperability with C#.

Basically C# and F# are 2 different languages that are good at solving different problems, and are mastered by different people. C# is a solid infrastructure language. F# is a good business modeling language.

What I think is best about F#/C# is to have data scientists / mathematicians work in a language and have infrastructure people work in another one, and yet have those 2 languages interoperate well.

The main issue for me is that they don't actually interoperate very well...

If F# is pushed too far from C#, what's the point? Just use Haskell...

Re: The Problem with F# Evangelism

#89

Post by DeepRote »

nickpeterson wrote: post #26

This article retreads common complaints about the F# experience for outsiders that I've seen numerous time. I'm going to go a different direction. The problem with the F# community is that they keep asking how to convince C# developers to use F#. I'm convinced that is not the right way to grow the F# ecosystem. Most C# developers tend to come from enterprise and have a set of values and practices that is generally at…

Incredibly well-spoken.

I've even had devs ask me if we can use Scala instead after a couple days!

Re: The Problem with F# Evangelism

#90

Post by MichaelGG »

Microsoft promoted this idea that F# is for mathematicians and engineers, so its no wonder that people pick this up. And I'm not sure who is pushing this idea that F# is not fine for OO work. It has all those features. So starting with F# as a "better C#" -- there's nothing wrong with that. Over time I think people will come to view OO as suboptimal, but in the mean time F# is just a better language to use than C#.

MS hasn't funded F# enough, and has crippled the marketing on it to continue to push C# rather than admit they've made mistakes. The tooling issues and other random incompatibilities are why I don't use it as much as I used to - it's too much friction.

Post reply on HN