
A whirlwind tour of object-oriented code in F# (2012) - adgasf
https://fsharpforfunandprofit.com/posts/completeness-anything-csharp-can-do/
======
danite
I used to be a big Haskell programmer. While I still love the language, I've
really come around to the idea that strictly evaluated functional languages
like F# or OCaml are the best for programming in. You get the nice functional
features but don't have the straightjacket of laziness forcing you into
certain design decisions. It's really nice sometimes to be able to mix in
impure, side effectful code without having to thread it through a monad. The
OCaml family feels like a nice blend of good sound functional features with
enough escape hatches to be productive in real world programs that might
occasionally need arrays or mutable state or IO. Laziness by default also
makes things like debugging or reasoning about performance frustratingly
difficult. I do miss Haskell's typeclasses in these languages, though. My
ideal language is basically Ocaml/F# but with Haskell's syntax and
typeclasses.

~~~
jlturner
I use F# daily, and to get around this limitation I use hacky custom code
generation an F# script (fsx) to generated specific types.

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.

~~~
danite
Oh, for sure I still love monads. I miss Haskell's do syntax in every other
language. I think it's a great design pattern that starts popping up
constantly once you know where to look. My objection is being forced to use
monads due to the language's lazy by default semantics. You get this problem
with haskell where the IO monad eventually just pollutes a huge chunk of your
code because you can't safely sequence side effects without it. Sometimes I
just wanted an escape hatch that would let me do side effects that I knew to
be safe/harmless. Haskell has unsafePerformIO but it truly is unsafe because
you can't guarantee the execution order of your side effects, which makes it
useless as an escape hatch for a lot of purposes.

~~~
dean177
Ocaml is getting something similar to ‘do’ syntax very soon (but for
applicatives too!):

[http://jobjo.github.io//2019/04/24/ocaml-has-some-new-
shiny-...](http://jobjo.github.io//2019/04/24/ocaml-has-some-new-shiny-
syntax.html)

------
sleibrock
Years ago I was working a miserable job writing boilerplate template code
where I had to sub in variables based on certain conditions, it was using a
very bland language to look up data from our database and format the output. I
wasn't allowed to download any software onto my work computer despite having a
technical background.

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.

~~~
nhlx2
Reads like an opening of a dystopian novel!

~~~
oblio
Heh. I was doing manual deployments because of dumb bank policies so after a
lot of maneuvering I used Powershell and plink.exe to write a small, dumb
version of Python's Fabric to be able to automate deployments.

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...

------
adgasf
F# is a joy to use. After a certain time, many C# developers find themselves
writing in a functional style. F# makes this the default, but lets you
continue using all of your existing code.

Better yet, Linux and macOS support via .Net Core is excellent. F# on .Net
Core is now a powerful alternative to Node.js.

~~~
louthy
> After a certain time, many C# developers find themselves writing in a
> functional style

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#

[https://github.com/louthy/language-ext/](https://github.com/louthy/language-
ext/)

~~~
Scramblejams
Would love to use F# with Unity, but the typical high allocation rates that
come with the functional language territory scare me. Looked at your library,
it's very interesting. I saw your docs note about the allocation efficiency of
Map, would like to hear more. Could you characterize the library's general
allocation story?

~~~
louthy
I've done a short write-up about this:

[https://github.com/louthy/language-
ext/wiki/Performance](https://github.com/louthy/language-ext/wiki/Performance)

~~~
Scramblejams
Terrific info, thanks! Looking forward to using it.

------
rygxqpbsngav
Been using F# on personal projects and C# at work. I noticed my C# coding gone
high quality once I got into functional thinking. It is highly recommended for
anyone to check/learn F#. F# is my goto lang. now to competitive programming
too. I believe F# and ML will make a great combo, but python is still leading.

------
rishav_sharan
Unlike most commentors my experience with F# hasn't been stellar. I feel the
language itself is well designed and the community is great but there is just
so much of it.

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.

~~~
hoelle
I agree, F# is hard to learn. It took me a few months of tinkering to be able
to express myself in it.

Good entry points: Don Syme - his "F# Code I Love" talk has been recorded a
few times:
[https://www.youtube.com/watch?v=aw2BAxG3bdM](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](https://www.youtube.com/watch?v=srQt1NAHYC0).
He also runs
[https://fsharpforfunandprofit.com/](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](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.

------
GiorgioG
The problem is F# doesn't get enough resources internally at Microsoft. How
many times has VS shipped missing the latest version of F# tools? In terms of
community, it's tiny. If I want to do functional programming, F#/.NET isn't
the strongest option. I have several books on F# and as much as I'd like to
learn/use it beyond toying around, I can't help but feel like all it's worth
using for is tinkering (outside of the few shops that use F# extensively.)

~~~
bunderbunder
I find this to be an interesting cultural phenomenon, this thing where people
in .NET-land are skittish about F# because it's not so tightly controlled by
Microsoft.

Meanwhile, I'm pretty sure nobody even _wants_ Oracle to be getting involved
in Kotlin or Scala or Clojure.

~~~
GiorgioG
> this thing where people in .NET-land are skittish about F# because it's not
> so tightly controlled by Microsoft.

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.)

~~~
Rapzid
The irony is that F#s releases are in lock-step with the Visual tools team
releases and schedule.

~~~
GiorgioG
I must vehemently disagree.

From:
[https://github.com/dotnet/fsharp/issues/2400](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."

~~~
Rapzid
Perhaps it's not the case anymore, but I meant more that F# language releases
used to be delayed until the Visual Tools team was ready to release a new
Version for Visual Studio. So essentially, the F# releases seemed to be held
up. Perhaps I'm remembering wrong and/or this has changed since the .Net core
support came in.

------
melling
Here’s a Tour of F# by Microsoft:

[https://docs.microsoft.com/en-
us/dotnet/fsharp/tour](https://docs.microsoft.com/en-us/dotnet/fsharp/tour)

------
new4thaccount
I just bought Scott's book on Railway Oriented Domain Driven Design. So far so
good. I am the domain expert though, so no revelation there.

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.

~~~
arunix
The book is "Domain Modeling Made Functional"

[https://fsharpforfunandprofit.com/books/](https://fsharpforfunandprofit.com/books/)

------
mikece
While there's nothing you can do in C# that cannot be done in F#, the reverse
is not true. The biggest thing that comes to mind is to influence the
direction of the other language (C#). I've heard it said many times that if
you want to see what features will be in C# in the future, look at F#. Too
many features to cite (though Linq is the biggest that comes to mind) were in
production use in F# long before they arrived in C#.

~~~
svick
> While there's nothing you can do in C# that cannot be done in F#

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.

~~~
runevault
To your last point, with the freedom they seem to feel after the Core breakage
(like Span/Memory) C# might start innovating on its own again instead of just
taking awesome pieces from f# and making them part of C#.

------
nlawalker
_> Anything C# can do..._

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_.

~~~
GordonS
As a long time C# dev who has dabbled with F#, I kind of feel the same.

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.

------
joshsyn
I started F# lately and found it absolutely amazing. I come from heavy C#
programming, and always find myself reaching out to have sane default like
immutable types.

But unfortunately there are still lot of libraries out there for F# which
don't support .net core fully. Especially db access ones.

------
macca321
... and exhaustive matching:
[https://github.com/mcintyre321/OneOf](https://github.com/mcintyre321/OneOf)

I'm not saying it's as good as writing F#, or that C# shouldn't include these
features of course.

------
Nelkins
If you want to try F#, here's the full F# compiler in the browser run using
WebAssembly. Very fun to play with:
[https://tryfsharp.fsbolero.io/](https://tryfsharp.fsbolero.io/)

~~~
Nelkins
And it also compiles to Javascript:
[https://fable.io/repl/](https://fable.io/repl/)

You can browse through some sample apps using the side bar on the left.

~~~
onemoresoop
Thanks for posting that. Fable is fantastic

------
bob1029
I think several interesting points were brought up in this thread regarding
the assumption of functional aspects presented in F# by C#. LINQ being the
most popular example. I am currently lead to believe that a purely functional
application development domain is potentially an overreach of theory in terms
of building things that can interact with the real world in very complex and
'functionally-leaky' ways.

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.

~~~
McWobbleston
I really encourage you to use F#, as someone who's done C# for a long time I
find F# (while not perfect) does strike near to that ideal balance of FP /
imperative you speak of. Writing functional code naturally is a breeze, while
the language isn't going to punish you or feel awkward if you need to drop in
some mutable state or OO programming

------
dmitryminkovsky
For all the love Microsoft has been getting these days, I still don’t get how
I’m supposed to write C# or F# without Visual Studio and Windows. Am I missing
something? VSCode doesn’t support these languages, right? I’m a person who
spent a long time trying to write Java in Vim, but switched to IntelliJ and
wouldn’t want to write C#/F# without some comparable IDE.

~~~
yulaow
You can use Rider which is a very good crossplatform JetBrains IDE. I found it
very fast too (I use it on Fedora in my laptop)

~~~
thrower123
Rider is in some ways better than VS. If you have moderately large solutions
and a powerful desktop, you will frequently be butting up against the 32-bit
memory limit of VS, especially if you tear off any editor windows to put on
another monitor (I don't know why this exacerbates the problem so badly, but
I've been seeing it steady since VS 2013). Once you get around 2GB of memory
in use, things drag to a crawl.

------
macca321
One line data types
[https://github.com/mcintyre321/ValueOf](https://github.com/mcintyre321/ValueOf)

------
holtalanm
this is really interesting.

I've been meaning to dig my teeth into F# sometime soon because of its highly
functional base.

------
pjmlp
I missed the examples with EF, WPF, Windows Forms, UWP, WCF.

------
shitgoose
OO in F#. there goes the language...

~~~
adgasf
OOP is not idiomatic F#. It is mostly for interop with C#.

~~~
exyi
I would not say that, sometimes it's quite powerful to combine these
paradigms. I think they would not design a language for CLR only to force them
to create a huge interop subsystem.

You are right, however, that OOP should not be the default way to write things
in F#.

~~~
McWobbleston
I definitely appreciate being able to drop into an OOP style when I find it's
necessary. In a talk Don Syme (F#'s original designer) goes into aspects of OO
he enjoys, those understands the usefulness of, and those he does not enjoy. I
believe it was F# Code I Love, which gives some good insight into the thinking
behind the language.

------
lol768
It's a pity the tooling is comparatively immature, with F# (or at least that
was my experience last time I tried to develop with it). I think Rider is
getting there, though.

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.

~~~
asp_net
I've been developing F# in Rider for the last 4 weeks, and especially the last
update made a huge step forward. It's stable, fast, the test-runner works
perfectly, etc. It's definitely not at the same level as the C# tooling yet,
but it's good enough to be productive. (I'm on macOS by the way, building
Xamarin apps).

~~~
lol768
Glad to hear it's improved!

