A whirlwind tour of object-oriented code in F# (2012)
fsharpforfunandprofit.com
fsharpforfunandprofit.com
Additionally, on cases where you’re not specifying the data of the type itself, you can use static type constraints on members. This doesn’t give you a default implementation like Haskell but you can always provide one as a function.
Btw the monadic threading is still very useful, especially when mixing impure code and mutation (when appropriate). The async and result monads, in F# computation expression form, are particularly useful.
For a good example of async + impure code, check out MailboxProcessor, which is part of the standard F# lib. Works similar to CSP/goroutine + channels/actor models; makes parallelized concurrency and message passing easy. You can also make pure mailboxes easily by recursively passing data forward, but sometimes you don’t want to for memory / gc & alloc reasons.
http://jobjo.github.io//2019/04/24/ocaml-has-some-new-shiny-...
I hope it's gotten better.
Laziness is a good default for declarative programming. Nix from NixOS is an example of a recent lazy language and benefits greatly from it.
Even in strict languages, lazy behaviour is often added, for example iterators and streams. Mixing effects and mutation with such constructs is also problematic.
So what I did instead to make my life easier was write F# to create a kind of DSL and create the template lookup scripts for me. I did it all from the browser with repl.it, and I generated dozens of scripts and saved myself a lot of time in the process.
Now I mostly use Racket, but F# is where I kind of started out. It's a fun dialect.
I was writing Powershell in Vim while trying to keep my skunkworks project out of sight because of crappy management policies.
Sometimes you gotta make lemonade...
Better yet, Linux and macOS support via .Net Core is excellent. F# on .Net Core is now a powerful alternative to Node.js.
If I'm making a simple API, I've already moved into territory where I'd prefer to use C# or something like that. The ecosystem is better and you can write it to avoid runtime gotchas.
Big languages/stacks can still write tiny programs.
Don't assume everyone is a fanboy/fangirl just because they have a recommendation.
"Have you looked at F# even to just to see how it works?"
"I won't ever use it. I'm an OO programmer, and it suits me just fine!"
"Do you use LINQ, and understand you can pass functions into methods etc.?"
"Yeah, it makes things so much easier. I don't understand why people wouldn't use it."
"That's really more like functional programming"
"...."
Edit:formatting
- Do you want your data types in one line or 20?
- Pattern matching, or large concretions of if-statements?
- Race conditions: Quality problem, or fun puzzle?C# has support for most F# features, they're just often awkward to use
Discriminated unions: https://github.com/mcintyre321/OneOf and One line value objects: https://github.com/mcintyre321/ValueOf
I know local functions are a recent ish addition to C#. Hoping they keep going down that road.
They can be annoying, I guess, but once you are used to it you don't really notice they are missing. It is annoying if you have to switch languages often, I'm pretty sure I would need a few weeks to get re-acclimated if I had to go back to C# from using TypeScript for so long.
If you can't move to F# or find its tooling abysmal and slow then I have a library [1] that makes the inertia flow positively in the functional direction in C#
My current strategy is to hook my colleges in with languag ext until they move to f# themselves.
I thought that library looked familiar, and realised I was looking at it earlier today when I set up some F# job filters on stackoverflow (you're the only F# job on there that doesn't involve moving to London).
I hope they fix these warts. It can soon be a good alternative to Go for real native applications.
[1] https://github.com/louthy/language-ext/wiki/%22Why-don't-you...
I'm sure there are people out there debating F# vs C# for a new project, and might not realize how many future C# features are already in F# though.
Any source code that i try to go through is sprinkled with so many new keywords, so many different way of combining stuff, that there seems to be so many syntactical stuff going on. It is really making me struggle.
It just feels like a language where the maintainers are going overboard with. And I am sure that once I understand it, I would love it, but the path to get there is so hard.
Pretty much no tutorials or articles are out there and reading sources for small projects is not viable for me either due to the keyword noise and too many ways to do something.
I did not feel anything like this when I taught myself python, ES6, lua, Crystal etc. F# just feels too big.
The lack of a good online tutorial is a problem for me as well. F# For Fun and Profit is decent, but I've not found it a good substitute for a book/tutorial.
Good entry points: Don Syme - his "F# Code I Love" talk has been recorded a few times: https://www.youtube.com/watch?v=aw2BAxG3bdM. I recommend catching a few versions.
Scott Wlaschin - His talks are also great: https://www.youtube.com/watch?v=srQt1NAHYC0. He also runs https://fsharpforfunandprofit.com/ which is a treasure trove.
And I found Isaac Abraham's book excellent and breezy to read: https://www.manning.com/books/get-programming-with-f-sharp
Now that I'm over the hump, I think F# code is far more readable than other languages I'm well versed in (C++/C#). Probably my favorite thing about F# is the strict top-down dependencies. You can open a project and read it in order, and understand it without having to hop around a bunch.
And since most programs can be written in far fewer lines in F#, code written in it ends up feeling very small and economical.
Meanwhile, I'm pretty sure nobody even wants Oracle to be getting involved in Kotlin or Scala or Clojure.
Microsoft's great tooling is what has made (traditionally) it sticky for a lot of developers. F#'s tooling from Microsoft has been a half-hearted effort (organizationally, not speaking of the effort that the F# guys have put in.)
From: https://github.com/dotnet/fsharp/issues/2400
"GiorgioG commented on Oct 19, 2017 @masaeedu - Not to beat a dead horse, but we've been waiting for an RTM release of this since May when VS2017 first RTM'd. We were then told it would likely come in the July release of VS, we're now nearing the tail end of October with no clear idea when we'll get it. It's not @cartermp 's fault, just the reality that MS has not made it a high priority (judging by their actions, not their words.) In summary, if you want to use F#, use VSCode, it has excellent support for F#, as long as you realize it's not Visual Studio, it's a souped up text editor."
And that Oracle alongside Sun and IBM has been there since the begging, and other than IBM, no one else made an offer to buy Sun.
Or if the JVM had died with Sun their languages wouldn't even exist.
F# is on .NET CLR and you can use all the .NET libraries, and it lets you fall back to an imperative style if you need to!
did you try it?
Hint: there is a lot of things required before F# could use latest WinUI or WPF
https://github.com/microsoft/microsoft-ui-xaml/blob/master/d...
Guess what is one of the complains on the feedback thread?
The modeling of state machines using types and functions is pretty revolutionary to me for where I'm currently at development skill wise. Everything just seems so clean and elegant.
Thankfully F# and C# mix so well together I could've written a quick C# project to do it if needed, but I didn't want to break up my F# project into two + some C# glue
In the vast majority of cases though what you said is true. Discriminated unions, records, computation expressions, and type providers are total game changers
Really? When did F# start supporting pointers?
> to influence the direction of the other language (C#)
Lately, it seems it's the other way around: C# is introducing features like Span<T> or default interface members and F# is (quickly) catching up.
Yes, yes, you can do anything in F#, but what should you do?
My opinion is that that what F# is missing is a good set of idioms and a strongly opinionated set of guidelines. To my beginner's eyes, every F# codebase I've seen feels like it's written in a completely different language; it's like the opposite of Python's "one right way to do everything".
I've heard that F# is great for domain-specific languages, but in most cases a DSL is the cardinal opposite of what I want. I want a common language that I can use to express a multitude of different concepts. It seems like all of the guidance out there about F# is about showing off features, being extremely clever, or using F# to teach functional concepts, not actually about writing useful applications.
I always find myself structuring appa like an OO app, which invariably results in something that feels wrong.
For someone for which OO is so entrenched, it's really difficult to think differently - and there doesn't seem to be an idiomatic way to write F# code (not that I've found, anyway); every code base seems to take a different approach.
But unfortunately there are still lot of libraries out there for F# which don't support .net core fully. Especially db access ones.
I'm not saying it's as good as writing F#, or that C# shouldn't include these features of course.
You can browse through some sample apps using the side bar on the left.
My biased perspective as someone who hasn't really used F# very much is this: Perhaps an imperative language such as C# 8.0, with a few high-value functional features sprinkled in, is actually the best of both worlds when viewed through the lens of someone who has to interface with really weird business systems. I use imperative techniques for handling remote calls, exception handling, etc. Then, when I need to work with my internal business logic or models, I can use more functional techniques.
Based on my own understanding and other comments presented here, C# does not seem to preclude the usage of functional approaches to solving problems if you have the discipline and experience to do so. C# also brings with it a host of other benefits in terms of tooling support and simply being able to find other developers who can understand your codebase.
F# in .NET CLI: https://docs.microsoft.com/en-us/dotnet/fsharp/get-started/g...
C# in VS Code: https://docs.microsoft.com/en-us/dotnet/core/tutorials/with-...
Supported Linux versions: https://docs.microsoft.com/en-us/dotnet/core/linux-prerequis...
Supported macOS versions: https://docs.microsoft.com/en-us/dotnet/core/macos-prerequis...
Rider's also an option: https://www.jetbrains.com/rider/
In that case, I think you want an actual IDE and VS Code is not that. The options you have for .Net are Visual Studio and Rider (which is from the same company as IntelliJ and shares a lot of code with it).
As for doing .NET Core stuff, it depends a lot on your setup of both Code & Visual Studio. Code has some nice features that you would need extensions or an upper tier VS version to get. Code can be faster at times as well.
At the end of the day it is a different experience with a few pros & a few cons. It will greatly depend on the way you program.
This is not true for F#.
The maintainers of Ionide also just got Microsoft $$ so that’s even better news.
But working with F# and it’s strong types while at the same being able to write something similar to Python should be a giant selling point to anyone.
If you’re on a Mac or linux just download the .net core sdk and you’re ready to go
Rider is the comparative option for you. I wouldn't waste much time on VS Code, personally.
After setting up the theme and font and such... I love Rider! It's extremely customisable, and actually has some features than VS doesn't. And of course it's backed by ReSharper too. Highly recommended it!
I've been meaning to dig my teeth into F# sometime soon because of its highly functional base.
You are right, however, that OOP should not be the default way to write things in F#.
To go into more detail, the initial implementation in Rider was limited to not much more than syntax highlighting. Inspections were fairly limited, ASP.NET MVC integration was not as featureful.
On the C# side, it's much more developed and refined. Within Rider, it's obviously been the main focus so I suppose it's only natural it's received more polish.