ericsink / blog Goto Github PK

There are simple things I think F# community can do to improve the experience of F# for C# developers. When experienced C# developers encounter these problems, we have a very low opinion of how the F# project is managed:

1. At one point in time, the F# team delisted the F# Tools package we were using in our Visual Studio Solution from NuGet.
2. In Visual Studio 2019, unless you reference a C# static class static member with its fully qualified type name, you will see "red blood" everywhere in the F# project where this reference exists; open [C# Namespace]" simply doesn't work in all cases. Note: the F# project will still compile, but the "error spigot" is extremely annoying to tidy engineers like myself.
3. Referencing a F# project from a Visual Studio sln file was painful before the Common Project System enhancements. This actually helped a lot, but I think it likely introduced the above problem about referencing C# statics.

Then there is simply the "Bad F# code is way harder to debug than bad c# code" for an experienced engineer. Things that annoy me about bad F# I've had to maintain:

1. Excessive use of active patterns.
2. Depending on whether or not type annotations are present and the ordering of expressions in an active pattern statement, the compiler will or will not interactively warn you that some statements are unreachable.* (* This is not 100% confirmed by me, but I suspect it to be the case. This is annoying, because I don't spend enough time with F# to know exactly how to break this problem down into its smallest reproducible pieces.)
3. No CodeLens that displays complex pattern matching data types. This goes along with whether or not type annotations are present. I'm not exactly sure what the right solution here is, but I have frequently spent 4-8 hours understanding 25 lines of F#. I've observed my most frequent action is to hover over the expression in Visual Studio to get type inference details. Holy cow, would I friggin' love CodeLens instead of ToolTips. If the compiler could detect when type annotations are not present and then fling them on the screen right where I would expect to see them, then darn, that would be great. Frequently, there is only one valid type inference for all of this, so the concrete binding can also be displayed.
4. Erik Tsarpalis has touched upon this on Twitter: F# engineers poke fun at C# developers for global state or whatever, when in reality no senior C# developer writes code this way, but F# engineers frequently write code with tightly coupled static module dependencies.

The stuff that you bring up on your blog is neither here nor there for me. I have never personally experienced any of the issues you bring up as actual, material viewpoints. The whole "east vs. west" thing is interesting, but I want NORTH vs. south. I want the needle moved on things that innovate and make me more productive.

Finally, I do find "east vs west" interesting but I think you failed to capture the most salient aspects of east vs. west, which is the difficulties Joe Pamer (now at Facebook) and Don Syme had pushing the CLR team to add basic things like tail recursion. Recently, Neal Gafter pushed for a TypeSwitch IL instruction, and Don Syme politely weighed in on the debate. If you don't have 10 years of context around this and knowledge of Generalized Abstract Data Types, you probably couldn't infer Don's measured comments as "well, we've already been here many times, let's hope you take the time to digest my perspective once more".