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

61–70 of 203 posts

Re: The Problem with F# Evangelism

#61

Post by Boothroid »

rubber_duck wrote: post #32
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 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…

I'm interested to know why you describe EF as a monstrosity? Genuine interest, I just started using EF for the first time a few weeks ago for a work project so I've only scratched the surface but it didn't seem terrible, although I did find that only being able to update all tables after a change to the database as opposed to a single table to be a bit of a limitation.

Re: The Problem with F# Evangelism

#62

Post by brianberns »

rjbwork wrote: post #53
brianberns wrote: post #37

Earlier quoted context omitted.

C# developers in my shop loathe the SQL type provider because it requires them to have a compatible SQL Server database schema at build-time. The extra level of organization required is more than they can accept.

Does the F# SQL type provider integrate with the .sqlproj database projects that are in the solution, or do you have to have an actual running SQL database?

It needs a connection string to a real database.

http://fsprojects.github.io/FSharp.Data.SqlClient/

Re: The Problem with F# Evangelism

#63

Post by louthy »

macca321 wrote: post #47
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 think a better approach is encouraging the use of functional/F# concepts in C#.

I take this approach in my language-ext project [1]. I wrote it because as well as wanting to use F#, I had a decade old C# project to maintain, and I wanted to bring functional techniques into. We're (my team) finding that the pull to to F# is diminishing quite significantly; this is partly due to the functional framework features I've added to lang-ext; partly the new features of C# (expression bodied members, tuples, etc.), and majorly the relatively poor tooling.

This is not some desire for ReSharper in F#, it's basic stuff like compilation speed, the amount of time it takes for the red-squiglys to turn up (lulling one into a false sense of security), build issues: I have a C#->F#->C# dependency graph in a new satellite project I'm working on. If I change the root C# project then the F# project won't re-build/link, then at runtime I'll get errors that the F# DLL expected a function or type to exist that I'd removed from the C# one. And the absolute classic about the necessity for ordering files in the project in dependency order... I get that this reduces cyclomatic complexity, and that's laudable, but it's just a pain once a project gets to a reasonable size.

For my open-source projects I had to drop F# APIs from the projects because I couldn't create net451 and netstandard1.X project files that would build, pack, and be deployable to nu-get.

Also the interop story between C# and F# really isn't that good. Even though it's shouted from the rooftops as a main selling point. Everything prefixed with FSharp is ugly, FSharpFunc can't implicitly convert to Func, FSharpOption evaluates to null for None, so you get none of the safeness in C#, FSharpAsync is reeeaaally difficult to consume from C#, etc. This means we have to build an interop layer and that always feels like needless effort. It would be much better if there was some tooling support that could create proxies between the F# and C# worlds.

It always feels like there's something in the way. And the way of human inertia is that those seemingly minor niggles will tend to put people off full-scale adoption. I love F# as a language (well, not its OO grammar, but I don't use that), but C# + language-ext actually gives me pretty much everything I need (bar ADTs).

[1] https://github.com/louthy/language-ext

Re: The Problem with F# Evangelism

#64

Post by Boothroid »

DeepRote wrote: post #11

I've experienced sort of a diagonal problem to this. F# is way too entwined with .NET to be immediately useful to programmers familiar with Ocaml or Scala or Haskell, etc. Some of the basic List. , Array. stuff is simple enough, but then you start talking about interfaces and classes and members and all this stuff that doesn't really translate from C#->sanity very well. I know people love it, but I've long considered…

'There is no merit in your skin color or your genitals.' can't disagree with that.

Re: The Problem with F# Evangelism

#65

Post by smithkl42 »

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…

It's the "Go to Definition" and "Find all References" pieces that are so annoying to me, and slow me down tremendously. It means that (practically) you have to do your whole solution in one language for it to feel like a unified solution, and that makes it hard to start by bolting an F# project onto an existing solution.

Re: The Problem with F# Evangelism

#66

Post by frou_dh »

jasim wrote: post #23

How can you help someone see the beauty and benefit of Typed FP without asking them to just trust you and spend a few months with it? I used to dismiss this as academic noodling till I got tired of OO and started going back to my procedural roots with just plain functions organized into namespaces. I was pretty happy with it till the codebase grew to a point I couldn't keep track of the flow of data. Objects help you…

I'm not in the Typed FP world, but I found the concept of pervasive use of Sum Types making invalid states (according to the project domain) of composite structures _unrepresentable_ to be a pretty compelling nugget to chew on.

A lot of debugging is: This has ended up in a weird state. Whereas the alternative could be that if the code compiles then it's impossible for that to ever be in a weird state.

Re: The Problem with F# Evangelism

#67

Post by TensorMetric »

rubber_duck wrote: post #32
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 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…

The real problem with F# is that it isn't supported everywhere C# is https://news.ycombinator.com/item?id=15026396

Re: The Problem with F# Evangelism

#68

Post by cm2187 »

Boothroid wrote: post #61
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…

I'm interested to know why you describe EF as a monstrosity? Genuine interest, I just started using EF for the first time a few weeks ago for a work project so I've only scratched the surface but it didn't seem terrible, although I did find that only being able to update all tables after a change to the database as opposed to a single table to be a bit of a limitation.

If you use code first it's very easy to get in a corrupted state where it doesn't know how to update the database. Otherwise it speeds up the basic tasks then it gets in your way to write more sophisticated queries.

I found that a good solution is to write a generic sql serialiser that does all the basic operations (insert, update, select, delete, read one or multiple from readers) and do the rest by hand. It avoids most of the tedious code/sql while not getting in your way to do things like transactions, bulk inserts, etc

Re: The Problem with F# Evangelism

#69

Post by louthy »

rubber_duck wrote: post #32
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 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 default ToString() which previews the members, and serialization and deserialization constructs. It's a feature I recently added to language-ext [1].

If you need `With` functionality, then add the following member:

    public TestClass With(int? X = null, string Y = null, Guid? Z = null) =>
        new TestClass(X ?? this.X, Y ?? this.Y, Z ?? this.Z);
Then you can use named parameters to do partial updates:

    value = value.With(X: 456, Y: "World");
Obviously it's still more boilerplate than F#, but C# is never going to have significantly less until we get proper record types and ADTs.

> Functional programming is also seeping in but again tons of boiler plate.

Do you have an example? It's something I've worked on quite heavily over the past few years, so I'm always looking for areas to try and improve the lot of C# devs trying to write functionally.

[1] https://github.com/louthy/language-ext/releases/tag/v2.1.0

Re: The Problem with F# Evangelism

#70

Post by banashark »

I usually don't try to sell F# as compared to C# as noted in many other responses here. Since most of my friends work in other languages I usually just use python as my reference.

#ME: "Hey that stuff at pycon was pretty cool, huh?"

#FRIEND: "Yeah it's interesting the directions they're going with the language."

#ME: "Yeah the optional types could help clean up big code bases, and open up the door for quickcheck-like fuzzy testing."

#FRIEND: "Yeah."

#ME: "And some of the functional programming stuff is pretty neat too, I know it's easier for me to test."

#FRIEND: "It's so much easier."

#ME: "And the asyncio stuff is gonna be really nice to work with when it catches on more."

#FRIEND: "Yeah it seems a lot more ergonomic of a solution."

#ME: "And the binary distributable packaging tools look like they might actually work this time."

#FRIEND: "Probably not, but we can hope."

#ME: "I think I should introduce you to my friend F#."

Then just do some stuff in fsx with a type provider or some other neat stuff and at least you've got the message across.

People get excited about solutions to their problems. If you start giving them more problems then you're only adding to the constant subconscious cognitive load that they bear in regards to software development.

If you show it to them in terms of problems that they already have, you're reducing the cognitive load. Everybody loves having less stress.

But this is just how I approach it. F# is like Python4 for me.

Post reply on HN