* Rich language constructs that encourage pithy and correct code (e.g. arrays and lists are a language type rather than a library datastructure and the syntax facilitates implementing very readably and succintly common operations on them)
* The combination of algebraic data structures and pattern matching enables succinct implementation of solutions for lots of common programming problems. This was perhaps the biggest wow feature of the language when I learned to use it well.
* Functional languages tend to encourage immutability. F# works idiomatically with mutable data as well, thus being well suited for e.g. numerical code. I would call this letting us have the cake and eat it too.
* I don't think there are any specific downsides to F#. Some programs are better expressed in C# still but the .Net platform allows one to access those classes seamlessly from F# side.
IMHO, these are all wins. There's not much unnecessary language wankery in F#, it was developed as an industrial tool from day 1. so most features have some rationale behind them.
Here is an example of a simple language tool not in Java/C# that makes it easier to write, read, and is safer. http://deliberate-software.com/function-pattern-matching/
F# can also call anything written in .NET, so it's easy to start using it right away.
The biggest complaint people have is that it is a totally new language, and the parts that make it simpler and safer take effort to learn. In all honesty, several developers I know don't want to learn it, mostly because they only know C#, and do not believe the claims of speed and safety. They cannot imagine what could be different, so a day or two in, they just think of it as "syntax wankery", and never get past that point.
Really, the different syntax just makes it about a third the size of the equivalent C#. That alone is fine, and usually is the reason people prefer languages like Ruby/Python. But the real power comes from deeply understanding computation expressions, the LINQ equivalent, and F# data structures. Those three allow code that is much safer and easier to write, without sacrificing any functionality.
At my work, (Winforms app and an MVC4 web site) I use it anywhere I'd use C#.
So you'll want it if you want a functional language and you want to use the .NET platform.
Does that answer your question?
why use a functional language? see http://fsharpforfunandprofit.com/posts/ten-reasons-not-to-us...
Why use f#? see http://fsharpforfunandprofit.com/why-use-fsharp/ (concise for programmers) or http://fpbridge.co.uk/why-fsharp.html (more high level)
more info about fsharp at http://fsharp.org/
my take:
#ecosystem - vibrant and friendly community - open source (long time ago, use pr, wrote by community) - cross plat (linux/mac/win/ios/android) - is .NET, same standard library as C# or VB.NET and virtual machine (CLR). Finally open source - use nuget components written for .net - third party component with commercial support
#language - fun to use - concise, i can easy write code without boilerplate - multi-paradigm (functional first, but can do oop like c#) - easy interop with c#, native - fast - help write correct code (no null reference => no null reference exception, pattern matching, - easy async, parallel, gpu - unit of measure (like 1<m/s> )
and a lot, read the links above for a better (and faster) summary
F# is to C# as C is to Assembler (I regularly use both C# and F# and don't quite agree with this, but it is defensible).
Short answer:
Programming, especially OOP, has a lot of prescriptions: things like coding against interfaces rather than implementations, using abstractions, the law of Demeter, avoiding mutations, prefer composition to inheritance, etc.
Basically, you can think of F# as a language that compiles down to C#, but follows all of the best practices without fuss.
Consider this example of F# code:
type Shape =
| Circle of float
| Square of float
let area s =
match s with
| Circle r -> Math.PI * r * r
| Square sd -> sd * sd
let perimeter s =
match s with
| Circle r -> 2 * Math.PI * r
| Square sd -> sd * 4
public abstract class Shape
{
public abstract float Area();
public abstract float Perimeter();
}
public sealed class Circle
{
readonly float r;
public Circle(float r)
{
this.r = r;
}
public override float Perimeter()
{
return Math.PI * 2 * r;
}
public override float Area()
{
return Math.PI * r * r;
}
}
public sealed class Square
{
readonly float side;
public Circle(float side)
{
this.side = side;
}
public override float Perimeter()
{
return 4 * side;
}
public override float Area()
{
return side * side;
}
}
* The C# code needs 5 times as many line as the F# code (adding a new shape to F# will require about 3 lines, but the corresponding C# class definition will be at least 15 lines).
* The F# code is idiomatic, but hardly any C# programmer seals classes or defines them as immutable by default, even though it is a good practice.
That said, there are some advantages that C# enjoys. Consider our example code: Even though C# requires more lines of code to define a derivative of Shape, at a certain point it will always be easier to add new classes to C# than the corresponding variant to F# (see "The Expression Problem" - on the other hand, adding new functions that apply to Shape will be easier in F# than adding the corresponding new methods in C#). Also, F# is supposed to be a hardcore statically-typed language, but there are some advanced concepts (e.g. type classes) that are easy to realize in C# yet not in F#.
public interface IShape
{
float Area { get; }
float Perimeter { get; }
}
public Circle : IShape
{
readonly float r ;
public Circle(float r)
{
this.r = r;
}
public float Area { get { return Math.PI * r * r; } }
public float Perimeter { get { return 2 * Math.PI * r; } }
}
public Square: IShape
{
readonly float a ;
public Square(float a)
{
this.r = r;
}
public float Area { get { return a * a; } }
public float Perimeter { get { return 4 * a; } }
}
Abstract classes have disjunctive semantics (logical OR) whereas interfaces have conjunctive semantics (logical AND).
The actual important thing that I wanted to capture is that an instance of Shape can only be one kind of shape at a time. With an interface a class could be more than one kind of Shape.
interface IFoo : IShape
{
//some stuff
}
public class SomeShape : IShape, IFoo
{
//I am a circle AND a square!
}Extension methods don't extend the type. They extend the functionality attached to the type.
F# has these too [1] (actually more powerful versions):
The thing about using sum-types (the original Shape example) is that they're not supposed to be extended. You're defining the range of the type, which allows for powerful inference of completeness when using them. If you need extensible classes then F# can do those too, it can represent interfaces, abstract classes and concrete classes [2][3][4], and can even generate ad-hoc classes from an interface by using Object Expressions [5].
I personally try to stick to the pure functional approach, but it can be very handy when interoperating with the .NET framework, or other C# based libraries.
[1] http://fsharpforfunandprofit.com/posts/type-extensions/
[2] http://fsharpforfunandprofit.com/posts/classes/
[3] http://fsharpforfunandprofit.com/posts/inheritance/
[4] http://fsharpforfunandprofit.com/posts/interfaces/
[5] http://fsharpforfunandprofit.com/posts/object-expressions/
type Shape =
| Circle of float
| Square of float
let area = function
| Circle r -> Math.PI * r * r
| Square sd -> sd * sd
let perimeter = function
| Circle r -> 2.0 * Math.PI * r
| Square sd -> sd * 4.0Also would be interesting to see how long would C#6 code be (twice as short?).
Apart from the sample, I also don't understand why F#'s naming patterns are not consistent with the rest of .NET (in terms of starting letter case). Feels alien.
Also how come this was considered a sane syntax for arrays?
[|1; 2; 3|]
instead of
[1, 2, 3]
Even Haskell's syntax is less alien.
Well, programming languages do have a prescriptive aspect. Arrays in C# 1.0 were more fundamental than List whereas the situation in F# 1.0 was the reverse, and F# doesn't really want you to use arrays as much as it wants you to use list.
...
Personally, I always mark my classes as either sealed or abstract. In OO terms, I only care about extending the Shape class, not the individual subclasses because those themselves are are already extensions... of the Shape class. If I did want to extend, say, the Circle class, I would probably make a new abstract class called Ellipse that derived from Shape and then derive Circle from Ellipse.
But, I don't really think in strict OO terms any more. C# has a decent type system (despite what my fellow ML programmers might say), but one of the mistakes of the language (i.e. the spec) is that it conflates types with classes. Those are different things. You may see three classes, but I see one type. In this case it's a sum type called Shape that ranges over Circle and Square. A sum type , as you may know, is just the type-theoretic version of logical OR.
Indeed, it wasn't until I learned about sum types that I finally understood why you would use an abstract class as opposed to an interface: abstract classes are for when you want to say that a Foo is a Bar OR a Baz OR a Biz whereas interfaces are for when you want to say that Foo is a Bar AND a Baz, AND a Biz.
How do I extend Shape to include Triangle without modifying the current code (e.g. in a separate file)?
Subclassing is a good and useful tool that simply works better in C# than F#. But, just as importantly, class hierarchies are often a poor way to model a problem.
It just occurred to me that you may have been asking about extending Shape in the C# example. In that case, you'd just subclass Shape as normal[1]. Some people argue that sum types shouldn't be extended, but I never really understood that. Basically, C# lets you define unbounded sum types (in the form of subclassing) whereas idiomatic F# more or less demands that you know up front how many variants you're going to need.
[1] Although, sometimes I do define my classes to prevent this by marking the constructor(s) of the abstract base class as private, and then writing the derived class definitions within the body of the base class.
let tuple1 = (1, 3) //tuple (int, int)
let tuple2 = 1, 3 //same as before, parens are optional
let list = [ 1; 2; 3 ] //list of int
let array = [| 1; 2; 3; |] //array of int
let listOfTuple1 = [ (0,0); (1,2); (4,5) ] //list of tuple (int, int)
let listOfTuple2 = [ 0,0; 1,2; 4,5 ] //same as before
nice and fast syntax guide http://fsharpforfunandprofit.com/posts/fsharp-in-60-seconds/
type Shape =
| Circle of float
| Square of float
| Rectangle of float * float
Also, even though F# can also subclass, that facility is a bit weak since it can't define protected members.
[1]http://c2.com/cgi/wiki?ExpressionProblem - funny thing is that the linked page coincidentally uses the exact same example code.
The results-processing I could do from anything (R, python), but scripting the run (running N random samples of something, doing simple cross-validation, manually hacking a pseudo-hierarchical model, etc.) is much easier when I have direct access to the C# API.
Since the codebase is always-evolving, the type checks of F# (as opposed to IronPython) are useful when going back to an old script.
I also just enjoy using F#. I'd been hoping to learn a ML-family language for years and working at a F#-friendly shop has let me do that.