Why F#

http://davefancher.com/2013/01/27/why-f/

by bsg75 • 13 years ago

87 30 13 years ago

pohl• 13 years ago

At one point the discussion turned to language productivity and Phillip remarked that writing C# feels like completing government forms in triplicate. As he elaborated I experienced a sudden burst of clarity into one of the major things that had been bothering me about C# – it’s verbosity!

It's like a parallel universe to the Scala/Java relationship.

Ingaz5• 13 years ago

Even more:

1. Common ascendants

Scala is heavily influenced by OCaml and Haskel.

F# is descendant of OCaml, heavily influenced by Haskel.

2. Past

Don Syme designed generics for .NET.

Martin Odersky designed generics for JVM.

3. Erlang influence

Acca - heavily influenced by Erlang and OTP, MailboxProcessor looking quite similar to Erlang processes.

4. Multiple paradigms

Both languages combine FP and imperative. Scala is more OOP, F# is more FP.

And (in my opinion) F# is looking more "clean" than Scala.

Simple thing in F#:

   let (|>) g f = f g

In Scala becames much more complicated. Also I think that discriminated unions are "prettier" than case-classes.

bad_user2• 13 years ago

> Scala is more OOP, F# is more FP

That depends on your background. As far as FP goes, I wouldn't see myself working in a FP language that doesn't have type-classes or something similar. Clojure has protocols and multimethods, Scala has type-classes based on implicits, while F# doesn't have anything like that.

> F# is looking more "clean" than Scala.

I don't know about that, I got used to Scala code. As far as the languages are concerned, I hate for instance how F# imported some language features from C# that really needed to die a long time ago, like static class members and operator overloading based on said static class members. Scala on the other hand cleaned all that crap. My problem with F# is basically that it has 2 type systems in the same language. Same problem that Ocaml has really, except Ocaml can also do some pretty cool tricks with structural typing for OOP that F# cannot.

But anyway, these issues are actually irrelevant because the choice for developers will end up being the answer to ".NET or the JVM?"

yareally2• 13 years ago

Being able to simultaneously develop in an imperative language (C#) and also a functional language (F#) at the same time on a project can be very appealing depending on what one is doing. With .net or mono, it makes it pretty easy to switch between them.

Sometimes I like having the power to use a functional language for a certain task, but would rather not develop an entire project with one. C# does have functional abilities (Linq), but it's not quite the same.

paf312• 13 years ago

Agreed. I recently wrote my first F# code because the boilerplate associated with emulating pattern matching/discriminated unions in C# was so unappealing. I very much like the ability to wrap a piece of pure F# code in a C# API. I actually think the resulting F# is easier to explain to another developer than a huge collection of visitor classes.

I also feel that I wouldn't want to write the whole app in F#, because I don't feel like the OO/FP approach feels as natural for some parts of the app as plain old C#.

yareally2• 13 years ago

Oh yeah, visitor would be a great example since F# has support of multiple dispatch. When I learned the Visitor pattern at the University I attended, it was one of the hardest things to wrap my head around initially until it finally clicked what it was while writing the code. It's just so counter intuitive to what most would think imperative language design is initially that it can take a bit to sink in. It seems simple enough, but trying to understand it and implement it are two different beasts. I would have gladly done it in a functional language or a Lisp variant if given the option.

Having to explain the Visitor pattern though to someone else would be much more painful than that I imagine versus just writing and explaining it in F#. The code just reads much more naturally for it, since the language supports it without a quirky design pattern.

Ingaz5• 13 years ago

>>I actually think the resulting F# is easier to explain to another developer than a huge collection of visitor classes.

Yes. It's even possible in some cases to use F# source as some kind of pseudo-code with C#-programmers.

MichaelGG2• 13 years ago

Could you elaborate on your last sentence? Especially with F# 3, the OO features should be syntactically the same as C#. You can use F# as a light-syntax C#, really, with a few minor caveats.

For curiosity, what in particular do you find to be unnatural in F#?

namigop• 13 years ago

This is what I did with WcfStorm.Server and WcfStorm.Rest (http://www.wcfstorm.com). The UI layer was written in C#; all other layers in F#. Switching back and forth though between an OO and an FP language (at least from my experience) is not that easy. There were a few instances where I ended up writing a class with mutable properties in F# simply because I didnt want to break my chain of thought so that I can get a feature out quickly

garenp• 13 years ago

Yeah! I love using as many languages as possible with my projects too, that way I can raise the "barrier to entry" to a codebase as high as possible--which comes in really handy if, for example, other folks you work with would otherwise hit you with drive-by craptacular changes that break your pristine codebase (that with any luck you have to clean up yourself afterwards). Also, lets not forget about another nice side-effect: added job security.

srean• 13 years ago

Given that the two comments by pohl and yareally are appreciative of a functional language that interoperates well with a host language, I would like mention Felix, a language I have been lloking at the past few weeks.

It is whole program optimized, strongly typed, polymorphic, ML like language without a default evaluation order that can interact effortlessly with C and C++ code and compiles down to C++, another differentiator is the presence of coroutines

I can point to two tutorials. One explains Felix by beginning from C++ [1], the other describes Felix the language [2].

[1] http://felix-lang.org/web/nutut/intro/intro_index.fdoc

[2] http://felix-lang.org/web/tutorial.fdoc

No analogies are correct, but roughly

Felix is to C++ what Scala is to JVM (or F# is to C#). Note however Felix predates all these languages.

@Ingaz the analogy is a little more literal because Felix compiles down to C++ (unlike OCaML)

Ingaz5• 13 years ago

Interesting.

But I always thought that OCaml to C++ is what F# to C#.

pjmlp• 13 years ago

Specially given OCaml's industry support, mainly in finance.

MichaelGG2• 13 years ago

Sounds much like my own experiences. I recently wrote some APIs in C#, and was reminded just how verbose and limited my writing becomes.

Even if I'm writing code that's not very functional, using F# as a better C# seems to work very well.

The main reasons to use C# are for legacy interop and perhaps if the code isn't a major focus and hiring someone capable of writing F# would actually be a limitation. Some folks also feel F# is clunky for imperative code; I haven't really felt that way.

laichzeit0• 13 years ago

That's great. Will F# get support from Microsoft for our enterprise? Nearly every server is either HPUX, AIX or Solaris. There are a few blade servers running Linux. Java runs on every one of these platforms with great vendor support. What can we expect from Microsoft if we switch to F#? This is the reality of large monolithic parastatal enterprise.

funkiee• 13 years ago

The .Net Platform is a massive enterprise mainstay.

masklinn• 13 years ago

Isn't the first C# example (the class) a pessimization? Why not e.g.

    public class CircleMeasurement
    {
        public double Diameter { get; private set }
        public double Area { get; private set }
        public double Circumference { get; private set }
        public CircleMeasurement(double diameter, double area, double circumference)
        {
            Diameter = diameter;
            Area = area;
            Circumference = circumference;
        }
    }

Arguably there's still a fair bit of repetition due to the constructor, compared to the F# code (and I'm not sure object initializers can be used with private-set properties), but a third of the repetitions have been skipped through implicit backing fields.

sklivvz1971• 13 years ago

Also most of that code can be written automatically with Resharper...

jeremyjh• 13 years ago

Resharper isn't going to read it for you.

Rickasaurus• 13 years ago

And he didn't even implement equality and comparison yet!

EnderMB• 13 years ago

I am a .NET developer by trade, and any other .NET developers I know that have heard of F# love the idea of it and would happily use it. The sad part is that this is often as far as it goes.

I think C# is a fantastic language, but if the development of F# got to the point where I could swap out either language when building an ASP.NET website with no worries about compatibility or missing out on anything (ReSharper being a big one) I would happily use F# on a project, and I'm willing to bet that many other developers would.

What seems to be holding off many people, including myself, is a lack of knowledge and information about F# from the higher-ups.

Why F#

Related Stories