Let me add my 2 cents worth.

I think that if all you are looking for is a better (easier, lighter, whatever ) syntax for exactly the same thing you are so used to doing in C# - you are missing the point. In this thread people made some wonderful points in regards to how much easier the same constructs can be expressed in F# as opposed to C#, but there is so much more...

If you stay on this level you will be stuck in the little endian - big endian war about what it is better

1

List.fold (+) 0 list

or

1

foreach int item in list total += item

To really get from F# what it can do for you you have to change the way you think, design, write your code. There are many books and articles which can explain this much better than I can, so I will not even try - at least not here.

But one thing which I find most facinating and ecouraging is that while it will take more time and effort (at least in the beginning) to take your project from the idea to the compiled code, after you have compiled code you are much closer to the end result. It is not that the debugger is better - it is terrible - but somehow you need much less debugging. It's like thinking functionally forces you closer to the working code.

At least this is what I and my developers feel based on our very limited so far experience with F#

Regarding the implicit mutability of .NET types, such as arrays, I initially shared Ivan Krivyakov's surprise that the following example is actually a mutable type.

1

type Record = { data : int array; }

However, that really does not keep me awake at night. F# does give you all the tools you need to manipulate arrays in a functional way in the Array module. F# does not force mutability on the programmer. Maybe that's a problem, but that's a design decision with which I'm OK.

Ivan also complains that F# lacks functional arrays. I'm not sure what functional arrays are, but after some quick search on google (see e.g. [link:citeseerx.ist.psu.edu]), I wonder if Map<int, 'a> wouldn't do the trick? They seem to have the same performance as far as random accesses are concerned.

>> c# and F# will be learned from each other. and therefore, most featuers

in f# will be
>> gruadually implemented in c# and vice versa.

There is some truth in that, but it's like saying that designers of fighter jets and civilian airliners learn from each other. Sure they do, but a fighter jet will never be a civilian airliner, or vice-versa.

>> . What is the future of F#?no one knows, because F# is nothing special to c# if you
>> consider it carefully and deeply.

I could give you a list of major differences between F# and C#, but it won't be convincing unless you've actually used them. Once you've written a lot of code using pattern matching, curry functions, type inference (not just the C# "var" version), the |> operator, etc, you will, hopefully, become convinced that F# is a very different language, and very much worth knowing.

Well, it's a wierd, mis-informed article. From the get go, sure, any language that supports higher order functions can be called functional. However, actually being able to practise functional programming in C# is quite a bit more difficult.

On to his real point about F# allowing mutation... F# offers such things by design! It's pretty simple; no myths or breakthroughs there. He's got a few things flat our wrong too, like saying classes are mutable by default -- dunno where he came up with that. At any rate, it's quite easy to use lists of records or whatnot in F#, whereas generating compiler-enforced immutablity in C# is much more difficult. Just search for how to make an immutable class in C# -- it isn't easy! The fact that you'll use mutation to modify a Windows Form doesn't have any bearing on the overall ease-of-use that immutability has in F#.

C# and VB have said they'll co-evolve -- supposedly they'll have complete feature parity so it'll just be pure syntax. F#'s going to pick up what it needs for interop, such as supporting C#-style extension methods. C# picking up F# constructs? Good luck. Just search for how many C# users don't even understand what "var" is. Now you expect the VB/C# team to spend the time and money trying to add in all the stuff F# has? Like I said, good luck. I'd _love_ for C# to be more lightweight and functional. But as C# 4 brought nothing new in that aspect, I highly doubt this will happen.

If all you do is use .NET classes and string them together in an OO/imperative way, then yes, F# accomplishes the same thing, albeit with a lot less code. Even in projects where we ARE doing exactly this (NHibernate, ASP.MVC -- pretty standard stuff for C#), we end up with less code in F# because of type inference, pattern matching, and so on. So even if normal .NET stuff was the only thing we ever did, and we never used any of the F# types -- it'd still be a win over C#. (As one of our developers who recently switched from C# to F# on ASP.NET MVC projects said "I'm constantly surprised at how little code I need.")

Once you use workflows, powerful type inference, automatic generalization, discriminated unions, tuple support, etc. -- you cannot make the claim that it's just slightly more concise syntax.

As a test, try performing this: [link:blogs.msdn.com] with C#.

Compare the number of type and generic annotations you must write in C#, versus F#. For me, I really felt this when I had one C# project where the field definitions were over 300 characters long -- needlessly, I might add. In F#, the same thing would have been perhaps 40 chars.

With F#, I'm able to refactor to a much higher extent. Because I don't need to provide all the types for a function, I can easily let bind a couple lines of code, whereas in C#, the overhead to separate out the shared functionality is costs more than the benefit. And this applies to coding in any style in F#.

Anyways, good luck. I encourage you to give F# more of a review and really look at how you can write things easier and more concisely.

-Michael

(On the J# comment, I have no clue what you're talking about. I'm not sure how an outdated-by-design implementation of Java for .NET has anything to do with F#.)