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

191–200 of 203 posts

Re: The Problem with F# Evangelism

#191

Post by eropple »

KirinDave wrote: post #122
DeepRote wrote: post #109

Earlier quoted context omitted.

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.

This is where I'm at. When people ask me why I don't write Scala anymore, the best answer I can give is "it is not a language that deserves a The Good Parts book, but desperately needs one."

Re: The Problem with F# Evangelism

#192

Post by phillipcarter »

m_cubed wrote: post #99

I built Tsunami IDE. It is a F# IDE. I built it before VSCode or VS Community came out. I built it as a test to see if cost of Visual Studio was blocking adoption of F# and the ideas that F# codifies. The experiment was successful, I got my answer, and the answer is no. Even with free tools people have a hard time adopting F#. First let me address those who are asking for Type Classes and Dependent Types. These would…

> There is is a not invented here culture at Microsoft Redmond which includes being hostile to Microsoft Research.

I'm 100% okay with criticism about things and think it's a good when people voice it, but this is not based in reality.

MSR (and Don) work together with different groups in Azure and and the developer division. It's not perfect - we are a large, multinational corporation with the same problems in communication across organizations as any large, multinational corporation - but calling the relationship hostile is misleading, harmful to the F# community, harmful to those of us who work on F#, and harmful to F# growth. I really don't appreciate spreading this sort of stuff.

Re: The Problem with F# Evangelism

#193

Post by dcdcdcdc »

pjmlp wrote: post #183
dcdcdcdc wrote: post #181

Earlier quoted context omitted.

I'm not a C# programmer, but it seems to me that the productivity drop argument is weird. Your engineers might be in a local maximum, and it might be worth the temporary productivity drop, if in the long run it would allow them to reach new (and better) heights. This, of course, is an outsider's supposition, and I understand that you're just conveying their point of view.

How it is weird having a productivity drop when everything that is done graphical by tools with a simple mouse click, must be done manually in plain code without any kind of visual assistance, beyond "compile and see how it looks like"?

No, I meant that bringing this fact as an argument is weird: I'm not arguing that there's a productivity drop, I'm saying that it's only temporary.

Furthermore, I have a few years of RAD development experience, and I know as well as you do that not everything may be coded with a couple of mouse clicks. As soon as you hit the business logic, you need to use the keyboard, you need to devise algorithms, you need to evaluate their complexities, and you need to code them down.

That being said, even just getting used to a new language gives you new insights about coding practices.

Re: The Problem with F# Evangelism

#194

Post by bonesss »

pjmlp wrote: post #168
bonesss wrote: post #166

Earlier quoted context omitted.

Domain modelling in F# is lightyears beyond C#s. Parallel and concurrent development, not to mention actor systems (F#s built-in or Akka.net), are also leaps and bounds beyond the C# story. These are Enterprise issues. Identity management, default immutability, distate for null, and exhaustive pattern matching are all major Enteprise features that large, complex, and critical systems see measurable benefit from... Th…

> There is no barrier to mingling F# and C# libs to focus on specific tasks or parts of the app. Try that on .NET Native apps. > F# does not get the same amount of tooling love as C# for the "latest and greatest" from microsoft. No tooling for Blend, WPF, UWP, EF, ASP.NET, no reason to switch and suffer a productivy drop.

You seem to have read past much of my comment :)

> Try that on .NET Native apps.

For a real-world workaround, here: https://docs.microsoft.com/en-us/windows/uwp/porting/desktop...

To quote from the thread: [by] “.NET Native doesn’t support F#,” what’s meant is “.NET Native doesn’t support all of the IL produced by the Visual F# compiler.”, which is one of the MANY reasons MS is now allowing UWP variations.

> No tooling for Blend, WPF, UWP, EF, ASP.NET, no reason to switch and suffer a productivy drop.

This is a reply to a comment saying "Having application libraries in C# and domain code in F# is a common pattern. Particularly at the GUI level, extra-particularly with anything that uses databinding so your domain types can be used directly."

That directly addresses what you're talking about. And, because I've done it myself: it's not entirely true what you're saying here. Those languages bind and analyze .Net objects. What you're talking about is entirely GUI level, and already recommended to take in C#.

The domain modelling productivity advantages CRUSH any gui nonsense. That's before we look at stability and correctness. And error rates. And maintenance productivity.

At the same time, to be blunt: there's no reasonable, scaled, approach to developing applications for any of those technologies that doesn't involve separating domain logic and GUI logic. Using DDD, MVVM, three-layered-app design, or any separation of concerns really and your app will already have the logical divisions required for a C#/F# split, so you can combine the high productivity on the back end with whatever button tweaking you require.

Re: The Problem with F# Evangelism

#195

Post by runT1ME »

corn_dog wrote: post #135
runT1ME wrote: post #112

Earlier quoted context omitted.

My previous job was working for a .NET shop that powered tons of automotive search engines etc. across the web. We moved to more and more functional concepts using C# as the team learned about them and had a lot of success with them. At a certain point, we explored using F#, but the lack of type classes & HKTs meant we kept having to repeat ourselves. We ended up choosing Scala for some new projects despite having an…

Is there anything about using F# that you would see as a plus over Scala or Haskell?

Oh yeah,

1. IDE experience is much better.

2. I like the fact that F# emphasizes the functional aspects, it's a bit of a 'tighter' language than Scala (despite the two crucial missing pieces) and so I think people could learn it a bit faster. Scala has things like structural typing, all kinds of optional syntax, multiple inheritance, etc.

3. Lack of flexibility in syntax is a plus imo for F#. Some of Scala's flexibility is nice, but some of it just confuses the newbies (like the various usages of `_`).

Re: The Problem with F# Evangelism

#196

Post by yawaramin »

d--b wrote: post #88
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 infras…

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

But you said it yourself:

> I think the main strength of F# lies in its interoperability with C#.

Re: The Problem with F# Evangelism

#197

Post by yawaramin »

jackmott wrote: post #149
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 am a C# developer who works on a closed source enterprise app at work. I have contributed to the F# core libs and created an open source F# library.

Have you floated the idea of writing some parts of your app in F#? How did that go over?

Re: The Problem with F# Evangelism

#198

Post by yawaramin »

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.

Units of measure. So in C# you can do something like this (using floats for convenience):

    class Power {
      public static HoursUsed(
        float totalBillDlrs, float deviceWattage, float rateDlrsPerkWh) {
        return 1000.0 * totalBillDlrs / (deviceWattage * rateDlrsPerkWh);
      }
    }
Then call it like this:

    var totalBillDlrs = 10.95;
    var deviceWattage = 100.0;
    var rateDlrsPerkWh = 0.15;

    Power.HoursUsed(deviceWattage, totalBillDlrs, rateDlrsPerkWh);
But, oops! that was actually supposed to be:

    Power.HoursUsed(totalBillDlrs, deviceWattage, rateDlrsPerkWh);
In F# you can use units of measure to prevent this kind of thing at compile time:

    [] type dollar
    [] type watt
    [] type kilowatt
    [] type hour

    module Power =
      let hoursUsed
        (totalBill : float)
        (deviceWattage : float)
        (rate : float) : float =
        1000.0 * totalBill / (deviceWattage * rate)

    let totalBill = 10.95
    let deviceWattage = 100.0
    let rate = 0.15

    // Compile error
    Power.hoursUsed deviceWattage totalBill rate
And, yes, in C# you can use things like named parameters to reduce the chances of something like this, but you can't eliminate it at compile time, which is what F# does.

Re: The Problem with F# Evangelism

#199

Post by yawaramin »

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…

> ... more than 10 million lines of code....

https://twitter.com/kot_2010/status/898941837372686336

Re: The Problem with F# Evangelism

#200

Post by yawaramin »

pjmlp wrote: post #102
magnumkarter wrote: post #94

For me, I only got into .NET because of F#, and even then I pretend C# doesn't exist. I tried learning OCaml, it has cool features, like parametric modules and GADTs. But I always ran into the issue of irreproducible builds. This didn't happened in F#. I eventually tried F# because it was close enough to OCaml and while I was learning OCaml I always referred to this site http://fsharpforfunandprofit.com I'm definitel…

The difference being that Apple is quite vocal that Swift is the future of app development on their platforms, while Microsoft is trying to push UWP as the future of Windows apps (supported languages VB, C#, C++ and JavaScript).

UWP supports JavaScript? Cool, in that case a bunch of transpilers should work (once bindings are written) ... people can just use their preferred languages: OCaml/BuckleScript, F#/Fable, TypeScript, PureScript, et al.

I've actually written and run JScript scripts on Windows Script Host with BuckleScript, it's really nifty. You write strongly-typed code and get a JS artifact that can run on your target platform. For the curious, an example: https://github.com/yawaramin/wsh-bs-test

Post reply on HN