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

121–130 of 203 posts

Re: The Problem with F# Evangelism

#121

Post by twodave »

phillipcarter wrote: post #86
pjmlp wrote: post #80

Earlier quoted context omitted.

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 suppor…

This, and also VS2017 did in fact ship C# without some things (for instance, full support for value tuples).

Re: The Problem with F# Evangelism

#122

Post by KirinDave »

DeepRote wrote: post #109
KirinDave wrote: post #103

Earlier quoted context omitted.

There is nothing but frustration at Scala's stagnancy driving.

Scala is not even remotely stagnant. Scala programmers are becoming stagnant, but scalac hasnt experienced any major growth slowdowns, Scala native is progressing quite a bit, ScalaJS is still a thing, and Dotty seems to at least be implementing some of that new DOT stuff. I'm not defending how obnoxious it CAN be to write Scala, but say it's stagnant is just dishonest or misinformed. Or both. Also SBT. Fuck sbt.

That is not my perception.

It's difficult to point to a more poorly managed language project than Scala. The net result is a mess with tons of gotchas, performance pitfalls, technical debt and a 3-way split tie in the community.

Scala has driven away a lot of brilliant people.

Re: The Problem with F# Evangelism

#123

Post by KirinDave »

zwieback wrote: post #22
KirinDave wrote: post #13

Earlier quoted context omitted.

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…

Good points but I'm curious: once you "emerge from the other side of it", where are you? In a nuts-and-bolts programming world where you now write better code in a language like C# that has limited functional features or in a more idealistic environment where you write Haskell or OCaml? The latter always seems to be a niche available to few.

You become very good at identifying ways in which to avoid writing error-prone loops. You also get a sense for how to use simple functions of various types rather than more abstract and purpose-built abstractions.

A neat example of the later: dependency injection is a massively more complicated concept than just passing functions that provide a value, while providing even greater flexibility and more obvious reuse.

Re: The Problem with F# Evangelism

#124

Post by nlawalker »

The problem with F# evangelism is that it doesn't exist. No one is evangelizing F#; everyone is evangelizing functional programming. F# is the Python of .NET - it's multi-paradigmatic and you can do whatever you want. Sell it to people that way, and let them get into functional concepts later, or never.

F# has a huge opportunity in the enterprise. A ton of enterprise C# code is not object oriented at all, it's big, poorly thought out clumps of imperative script wrapped in methods and classes so it can be compiled or fit into the framework that's calling it. Sometimes it'll get a quick last pass run on it to make it "more object oriented", because that's what C# code is supposed to be; this usually just makes it worse. It's written in a scripting mindset: the developer needs to get things done, and adds code and bangs on stuff until it compiles and looks right when it runs in the debugger.

F# is actually well suited to this style of development, but it's hard to find anything about it, because every F# tutorial, book and blog post is actually about functional concepts, functional design, functional thinking and functional programming, including this one.

If you want to sell F# to enterprise developers, show them how they can write their C# code in it without having to pretend that it's object oriented anymore, and how that's a good thing.

Re: The Problem with F# Evangelism

#125

Post by sickbeard »

nlawalker wrote: post #124

The problem with F# evangelism is that it doesn't exist. No one is evangelizing F#; everyone is evangelizing functional programming. F# is the Python of .NET - it's multi-paradigmatic and you can do whatever you want. Sell it to people that way, and let them get into functional concepts later, or never. F# has a huge opportunity in the enterprise. A ton of enterprise C# code is not object oriented at all, it's big, p…

Asking businesses to rewrite apps in a different language is a non-starter. It adds no value. The app is already there, written in c#. Why rewrite it in f#?

There has to be some reason to write something in F#, usually the reason is functional programming, which excels in manipulating data. However most programs rarely manipulate data. They show a UI, get some input from a user or server, save, retrieve, re-display in a different form. These kinds of programs work very well when written in imperative languages compared to functional ones.

Re: The Problem with F# Evangelism

#126

Post by pjmlp »

phillipcarter wrote: post #86
pjmlp wrote: post #80

Earlier quoted context omitted.

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 suppor…

Point taken, but apparently Microsoft employees keep forgeting F# is part of .NET, or isn't EditorConfig at all relevant for F#?

https://docs.microsoft.com/en-us/visualstudio/ide/editorconf...

Re: The Problem with F# Evangelism

#127

Post by corn_dog »

DeepRote wrote: post #89
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!

Well can they? :) F# is ok but using it makes me really appreciate scala.

Re: The Problem with F# Evangelism

#128

Post by pjmlp »

nlawalker wrote: post #124

The problem with F# evangelism is that it doesn't exist. No one is evangelizing F#; everyone is evangelizing functional programming. F# is the Python of .NET - it's multi-paradigmatic and you can do whatever you want. Sell it to people that way, and let them get into functional concepts later, or never. F# has a huge opportunity in the enterprise. A ton of enterprise C# code is not object oriented at all, it's big, p…

> If you want to sell F# to enterprise developers, show them how they can write their C# code in it without having to pretend that it's object oriented anymore, and how that's a good thing.

As enterprise consultant, for the types of customer projects I work with, lack of tooling support for Blend, WPF, UWP, EF, ASP.NET is a no-go to move from C# into F#.

Re: The Problem with F# Evangelism

#129

Post by isaacabraham »

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'm seeing lot of "I guess" or unknowns / assumptions here. All I'd suggest is actually try looking at it in bit of detail out speak to someone who's using it now - maybe that would dispel some of the FUD you're feeling.

Your preconceptions are certainly not unusual coming from the C# world, but they're generally just that - conceptions rather than actual reality.

Re: The Problem with F# Evangelism

#130

Post by toyotaboy »

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 reply on HN