It is such an expressive and clear language to write code in. That is until you start needing to use imperative .NET types :)
I tried porting a small demo program, a few hundred lines, directly from C# to F#. It required only 1/20th of the type annotations. I've written web APIs in F# and many took about half the lines of code.
I particularly like the ease in which I can define local functions to reduce redundancy. In, say, C#, there's so much overhead involved that it's just not worth it.
Going back to F# I've written years ago hasn't been hard either. Since the code is so compact, it's not difficult to figure things out.
F# should be MS's flagship. While F# isn't perfect (could use more inference, traits or typeclasses, and macros), in terms of tooling, ecosystem, language features it come out near the top.
Does F# run on .NET Core yet? Last I checked .NET Core and ASP.NET Core didn't support F#, which is a really big demerit for new projects considering this is the platform Microsoft is pushing for future server side applications (as they should be).
You can check https://github.com/enricosada/fsharp-dotnet-cli-samples/wiki... .
Remember to use last know good version of .NET CLI (see https://github.com/enricosada/fsharp-dotnet-cli-samples/wiki... ), until latest version is fixed
I generally think functional programming is a smart idea, but knock it off with the short, generic function names. We're not writing Fortran on an 80-char terminal any more. Name shit what it is, it's going to auto-complete anyway after you type 3-4 characters, so you might as well give it a name that you won't have to puzzle about later.
var newCustomers = getNewCustomers()
foreach(var newCustomer in newCustomers) {
newCustomer.this .that etc.
}
It's not just the hassle of typing long names out; a good editor can help there. It's the visual overhead of having so many extra pixels lit as you read things.
Short functions are good for local functions:
var sb = new StringBuilder()
sb.AppendLine bla
...
sb.AppendLine foo // And another 5 places in the following 10 lines of code.
This is especially true then the local code pattern is 2, 3, or more lines or when it contains branches.
fit the length of the functions. Long names might be indicative of some deeper problem with coding style.
I'm a C# developer with almost a decade of experience, and am pretty enamored with F# as well, but like almost everyone else, am stuck using it solely in my own personal time.
However, I'm not certain how much benefit most teams would gain from using F#, after seeing the average (poor) level to which most developers are able to leverage the C# type system to improve the design of their software. Too many developers are forever stuck in a purely imperative paradigm, only knowing how to type one line of code after another, relying exclusively in enums for "extensibility," etc. It seems a bit hopeful to convince the community at large to switch to a language with an improved type system in hope that it will be used to create better software.
But I think somewhere I read that the number of bugs goes up once a function stops fitting on one screen. Or maybe that was Arthur Whitney - J and K seem to do that nicely, and even his C style does so.
Edit: Of course all those other benefits of F# are huge, indeed. But don't underestimate the advantages and pure joy that excellent "programming in the small" provides.
As far as teams being stuck, you're basically saying that mediocre programmers can't handle good things. That's fine, but then the problem is hiring mediocre programmers. I suppose for a lot of basic CRUD/LOB or "enterprisey" stuff, it's important you can take essentially a typist and have them add business rules (like in Wisconsin, if the user is over 50, remove a certain discount). I don't find this type of programming to be particularly interesting though, so who cares what they use?
Is there really much of that stuff going on? I would have thought they would provide some kind of rules engine to the business rather than hard coding masses of it.
Consuming F# code from C# works pretty well for the most part, although F# specific types are cumbersome to use (records, discriminated unions, computational expressions aka monads). This just means that if you want an F# DLL to be usable from C#, you need to think a little bit about the exposed API (perhaps by adding a C# specific wrapper).
Having said that, IMO the interop between the two is better than the interop between JVM languages like java, scala & clojure (Kotlin is probably different).
You can also do a pure WebAPI module in F#.
http://www.felienne.com/wp-content/themes/zerif-lite/js/smoo...
Also, it's hard to describe exactly what the problem is, but scrolling up and down definitely feels weird and frustrating. For example, a light push that normally goes down a few lines of text on any other page seems to go down a full page. It also seems "stickier", like any scrolling takes a split second to "kick in". As a more contrived example, if I hold two fingers down on the trackpad and scroll up and down in place, any other page will scroll up and down following my fingers, but this page seems to jump around in an inconsistent way.
Something on the page is trying to intercept scroll events and do something smart, but at least on a trackpad on Mac OS in Chrome it makes scrolling feel much worse and less predictable. It looks like Chrome, Firefox, and Safari all behave differently here, with Chrome behaving the worst.
Your users know better than you how fast they intend to scroll. Always.