
On moving code from C# to F# - blah_blah
http://www.felienne.com/archives/4682
======
carlosnunez
I LOVE F#. I wish I could use it more often. I haven't used it since I worked
at Jane Street three years ago, and Jet.com is the only other place that's
using it seriously at the moment.

It is such an expressive and clear language to write code in. That is until
you start needing to use imperative .NET types :)

~~~
chadzawistowski
I thought Jane Street used OCaml! (I know the two are similar.) Why did they
need to target the CLR?

~~~
thristian
Just a guess: even if your back-end is all OCaml, traders still want to get
data into Excel to play with it.

------
dgudkov
We use both C# and F# in our application, using C# for UI (WPF) and F# for
data processing with a lot of calls from C# to F# and vice verse. Using F# was
crucial, because it allowed writing heavy processing and complex algorithms
(e.g. parallel hash aggregation) in a very clean and concise way with higher-
level abstractions which saved us a lot of time. Things like not having to
deal with null reference exceptions were also a big time-saver. Without F# it
would have taken us one more year to release a production-ready application,
or even made it impossible at all given the time & budget constrains that we
had. If I ever start another project of that scale I will do it using only F#.

------
MichaelGG
I've been using F# for a while and it's been excellent. It's just so less
frustrating than writing C# in all its verbosity. There's really no reason to
not use F# other than legacy or poor management. (Some folks just don't "get
it". Perhaps the same kind of people that use a 20 char variable name when 3
would do. Or that are cautious about using local type inference. I don't know.
But too many people conflate verbosity with readability and get scared.)

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.

~~~
douche
> use a 20 char variable name when 3 would do.

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.

~~~
MichaelGG
I'm talking more like locals. Consider:

    
    
      var newCustomers = getNewCustomers()
      foreach(var newCustomer in newCustomers) {
         newCustomer.this .that etc.
      }
    

Depending on the length of the surrounding function, you're better off using
"xs" and "x". Or "cs" and "c". I think people trick themselves into thinking
that long names somehow provide more context. At a high level, this is
correct: modules, exported functions, etc. But for programming "in the small"
it's just needless noise.

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.
    

It's nicer to instead have: let al = sb.AppendLine al bla ...

This is especially true then the local code pattern is 2, 3, or more lines or
when it contains branches.

~~~
was_boring
I perfer the verbosity because it helps with eliminating ambiguity when the
code changes hands or goes into "maintenance". This is especially true in
weakly, or duck, typed languages.

Both have merits though.

------
snizzitch
The (potential) terseness of F# seems like a bit of a superficial benefit
compared to other features of the language, such as discriminated unions and
pattern matching, excellent support for immutable records, structural equality
by default, computation expressions, etc.

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.

~~~
MichaelGG
I recall reading that bugs are many times related to the size of the code,
across languages. This SO answer has some citations:
[http://programmers.stackexchange.com/a/185684](http://programmers.stackexchange.com/a/185684)

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?

~~~
tonyedgecombe
"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)."

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.

~~~
greggyb
Yes it's going on, and half of it is hacked together in Excel.

------
rtpg
Is it possible to call F# code easily from C#? Or vice versa?

~~~
benrjackson
Consuming C# code from F# works fine.

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

~~~
tigershark
Yes, I agree, but you need to be really careful about tail call recursion
optimisation when calling f# code from c#. In F# it is always guaranteed, in
c# only on 64 bit 4 and above runtime if I remember correctly, so you can't
really rely on it for production code.

~~~
RaleyField
Wouldn't C# interface only with compiled il code and not directly with F# so
any tail call optimizations in F# wouldn't depend on what you later do in C#
compiler?

~~~
tigershark
Yeah, right, the f# compiled code will be already optimised for the tail call
recursion so it can be called safely from the c# code. What I remembered
applies only to the c# generated IL.

------
iuyoynp
please dont override default scrolling behaviour, the site is unusable

~~~
xeromal
For someone uninformed, what did they change? I'm able to scroll using the
keyboard keys, scroll bar, and arrow keys on my keyboard. Is mobile scrolling
what's broken?

~~~
alangpierce
I'm using Chrome on Mac OS and I can't scroll left and right in any of the
code examples. This is particularly bad because the OS hides scroll bars by
default under the assumption that you'll be able to scroll left and right with
the trackpad.

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.

------
lerax
Easy, only up 3 tones.

~~~
recursive
It's a perfect fourth, which is 5 semitones. In other words, it's 2.5 tones.
If you're going to make a pun, at least make it correct.

------
tigershark
I think that this code can be much simpler, it is really difficult for me to
follow it up. I'm not at all an F# expert, I just studied it a bit for fun
last year, but I remember that all the code that I looked at was much more
readable..

