The Problem with F# Evangelism

Post by MichaelGG » Wed, Aug 16, 2017, 8:34 PM UTC

toyotaboy wrote: post #130

MichaelGG wrote: post #90

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#. M…

No one who knew what they were talking about at Microsoft said F# was for mathematicians and engineers. It's a myth pushed by C# programmers and idiots. It's nonsense and you shouldn't repeat it. People at Microsoft repeatedly said "Simple Code for Simple Problems". C# programmers don't like repeating that.

Post by mevile » Wed, Aug 16, 2017, 8:48 PM UTC

phillipcarter wrote: post #82

mevile wrote: post #44

Earlier quoted context omitted.

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

Post by jdmichal » Wed, Aug 16, 2017, 9:14 PM UTC

louthy wrote: post #69

rubber_duck wrote: post #32

Earlier quoted context omitted.

I disagree with this, you can sell F# to C# developers - things like type providers for SQL checking their query strings in compile time and no extra build step to produce SQL type definitions vs monstrosities such as Entity Framework... if they've been burned by ORMs to drop to stuff like Dapper they'll love F# type providers. Immutable data is also becoming a common pattern even in C# but it's tedious as hell to wr…

> Immutable data is also becoming a common pattern even in C# but it's tedious as hell to write. I can simplify it for you: public class TestClass : Record { public readonly int X; public readonly string Y; public readonly Guid Z; public TestClass(int x, string y, Guid z) { X = x; Y = y; Z = z; } } That is an immutable type that has structural equality and ordering, a strong GetHashCode() implementation, as well as a…

    public class TestClass
    {
        public int X { get; }
        public string Y { get; }
        public Guid Z { get; }

        public TestClass(int x, string y, Guid z)
        {
            X = x;
            Y = y;
            Z = z;
        }
    }

    public class TestClass(
        int X,
        string Y,
        Guid Z);

Post by brianberns » Wed, Aug 16, 2017, 9:26 PM UTC

toyotaboy wrote: post #132

brianberns wrote: post #4

I'm the lone F# developer in a shop full of experienced and talented C# developers. I have clout, but not enough to convince any of them that F# is a better choice for many of our purposes. It's frustrating, but I try to understand that people are just naturally resistant to big changes like this.

Get them to do a training course like "Fast Track to F#"

Post by jackmott » Wed, Aug 16, 2017, 9:28 PM UTC

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…