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

31–40 of 203 posts

Re: The Problem with F# Evangelism

#31

Post by sitkack »

KirinDave wrote: post #13
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…

It's unfortunate tho, because for example what word do I have for the generalization that we call "profunctor" other than a profunctor. Even the words we use to describe a profunctor are "contravariant and covariant" and these words OUGHT to be more applicable to programmers but are not. For many programmers, the axioms of what a function are (a calling point to code which is contravariant in a product and covaraint…

We can sell the vision without sound like a Pythagorean-cult of mathematics (functional programming). Hell, once I showed some of Python programming brethren pure functions they were hooked, HOOKED I tell you!

When I showed how to make an object system using closures, they were like, "Cool!"

Some people start with the math, some people finish with the math and others deny the math. But we can all be better programmers with functional programming. If our goal is to educate, our actions should be the opposite of alienation. Some people gravitate to FP because it is seen as hard, as bad-ass and want to show their mastery to others. Those people should probably not be teaching FP.

Re: The Problem with F# Evangelism

#32

Post by rubber_duck »

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

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

Biggest problem with F# is that it has it's own warts + it's a big upfront switching cost and a steep learning curve but it offers many marginal improvements - when you sum those improvements it ends up being worth it IMO but that's a very hard sell.

Re: The Problem with F# Evangelism

#33

Post by phillipcarter »

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 IntelliSense and the benefits of static typing. F# isn't a scripting language, although it does support F# scripts.

Re: The Problem with F# Evangelism

#34

Post by zubspace »

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 performance requires it. Yes there are hacks and dirty code passages, but if you stick to basic code constructs they are easy to decipher.

If your facing more than 10 million lines of code you start to appreciate simple code. Moreover if different developers, which come and go, are working on it. Living without refactoring and inspection capabilities of resharper is nearly unthinkable to me.

Now, how would you convince someone like me to try out f#?

There are only drawbacks: Obscure things we would need to learn (type classes? monads? xyz?). Probably hard to read, 'clever' code. A mixture of c# and f#. Unknown library, build and deployment issues. And I guess, f# developers are rare around here.

Even after reading this post, there's unfortunately no convincing reason for me and management to give f# a try...

Re: The Problem with F# Evangelism

#35

Post by dep_b »

rottyguy wrote: post #21
phillipcarter wrote: post #17

I actually work on F# at Microsoft. I've had success and some failures when it comes to evangelizing F# through Microsoft (but mostly success if my measures are accurate). I strongly believe that it can be boiled down to one major thing: Programmers learn how to program with C-style languages. C, C++, Java, C#, JavaScript, Python (sorta) . . . they're all in the same family. People, especially while learning, associa…

"...realize that the types of bugs that hold them back can be reduced by using a more powerful language." I hear this a lot with FP but would love to see some real world examples of this if anyone has any links.

I can't give you any examples in F# from the top of my head, haven't touched it for a few months but I did ship software with it. I can give an example in Swift:

C#:

    ResultObject MyFunction(SomeObject some, AnotherObject another)
You have no idea if every value you pass in is required, or if you would always get a ResultObject or also need to expect null. Could possibly throw an Exception as well.

Swift:

    func myFunction(some: SomeObject, another: AnotherObject?) throws -> ResultObject
Forces you to give SomeObject, but you can pass nil to AnotherObject if you would like to, and the code inside this function will be forced to deal with it. Also it will always return ResultObject unless it throws an Error.

You will have no surprises using Swift while C# forces you to guess unless you know the inside of the function. F# works the same as Swift in that regard. You need to be explicit about nullability and mutability, and if it is nullable you are forced to deal with it it before you use it. Immutable and non-nullable is just easier to use.

The leap between C# and F# is much bigger because C# is really good and F# is a real functional language where Objective-C was older and Swift is less functional. Same goes for Java vs. Kotlin. Android Java is terrible compared to C# while Kotlin is much more similar in syntax.

Re: The Problem with F# Evangelism

#36

Post by brianberns »

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.

Re: The Problem with F# Evangelism

#37

Post by brianberns »

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…

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.

Re: The Problem with F# Evangelism

#39

Post by platz »

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…

Type Classes, yes. Dependent types, eh.. that is a bit of a stretch to say the least.

Re: The Problem with F# Evangelism

#40

Post by com2kid »

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…

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

The bar has moved so much on this one. I remember when C#'s wonderful lambda syntax, along with all the extension methods that LINQ added, qualified it as having pretty good functional programming support. Now that other languages have gone out and copied sane lambdas, and "Map" is in libraries left and right, C# has to keep reaching for that higher and higher bar.

Post reply on HN