What does C# miss that F# has, in today's .NET 4 world?

F# has units of measure, some syntactic sugar for type fiddling, type providers (which are cool for programming language theorists, but I haven't seen them do much in practice yet). But mostly F#'s fancy pattern matching capabilities.

Personally I don't think that those are anywhere near enough, given C#'s advantages with tooling and more natural integration with existing .NET code.

Well, referential transparency and deep immutability are quite generally useful tools in my opinion that deserve to be used a lot more. Tools, that is, that I would wish to be able to opt into whenever I want, instead of getting them shoved down my throat, after which I have to take a doctorate in CS to relearn how to print to the command line using monad-magic.
[/quote]

Indeed. And that's what we're seeing. Scala and C# pulling in the good stuff of functional programming to use where applicable.

On an unrelated note, I heartily despise the terseness of most functional languages.
[/quote]

I very much agree, though among programming language theorists it's not even discussed. Take a look through LtU sometime and see how much of the site is dedicated to programmer usability. But then again, I tend to be on the far end of the spectrum in wanting/making verbose programming languages.

I think the rub, for me anyway, is that these 5th-gen PLs are becoming more and more functional. It's almost like, us as programmers, are in some weird denial process. We use imperative languages that are becoming more and more functional. But at the same time we say, "OMG, it's functional! The syntax. My eyes, my eyes!" (ok, there's some exaggeration there) We should just brace F#/OCaml/Lisp and be done with it.

(end rant)

[quote name='ranakor' timestamp='1324378739' post='4895664']
What does C# miss that F# has, in today's .NET 4 world?

F# has units of measure, some syntactic sugar for type fiddling, type providers (which are cool for programming language theorists, but I haven't seen them do much in practice yet). But mostly F#'s fancy pattern matching capabilities.

Personally I don't think that those are anywhere near enough, given C#'s advantages with tooling and more natural integration with existing .NET code.
[/quote]
Dunno, considering how painless it is to add an F# project to your C# solution and just call its functions, id say the barrier to entry is very low. I dont see F# replacing C# anytime soon, but its certainly a nice option.

Dont forget the type polymorphism.

Well, referential transparency and deep immutability are quite generally useful tools in my opinion that deserve to be used a lot more. Tools, that is, that I would wish to be able to opt into whenever I want, instead of getting them shoved down my throat, after which I have to take a doctorate in CS to relearn how to print to the command line using monad-magic.
[/quote]

Indeed. And that's what we're seeing. Scala and C# pulling in the good stuff of functional programming to use where applicable.
[/quote]
C# does not have deep immutability (dereferencing an immutable object always returning an immutable object), nor can one declare functions as being pure. I dont see either of these changes coming in C# I suppose.

On an unrelated note, I heartily despise the terseness of most functional languages.
[/quote]

I very much agree, though among programming language theorists it's not even discussed. Take a look through LtU sometime and see how much of the site is dedicated to programmer usability. But then again, I tend to be on the far end of the spectrum in wanting/making verbose programming languages.
[/quote]

Interesting post. Cant find a link to more info about the language though.

Trying not to get too off track...

C# does not have deep immutability (dereferencing an immutable object always returning an immutable object), nor can one declare functions as being pure. I dont see either of these changes coming in C# I suppose.

I don't see deep-immutability as being a language feature (unless I misunderstand you). If you want an immutable object, make one; declare it sealed.
Likewise with pure functions. If you want a pure function, write one.

The optimizer loses some opportunities, but the core concurrency benefits will exist regardless.

Interesting post. Cant find a link to more info about the language though.
[/quote]

Clicking the blog title brings you to the landing page. Most info is there, otherwise a PM might yield better answers to questions.

Trying not to get too off track...

[quote name='Eelco' timestamp='1324397057' post='4895744']
C# does not have deep immutability (dereferencing an immutable object always returning an immutable object), nor can one declare functions as being pure. I dont see either of these changes coming in C# I suppose.

I don't see deep-immutability as being a language feature (unless I misunderstand you). If you want an immutable object, make one; declare it sealed.
Likewise with pure functions. If you want a pure function, write one.

The optimizer loses some opportunities, but the core concurrency benefits will exist regardless.
[/quote]
Well, of course one can always program in an immutable style by convention, in any language. But aside from compiler optimizations, its also a matter of coding efficiency. If I use a library function marked as 'pure', I know what im getting into. If I pass into a function an object declared as immutable, I know its going to be the same before and after the call. Without having to dig into the function and check for myself if the person making that function stuck to the convention.

Sealed only applies to declarations, not to instances of the class, or am i missing something?

I use F# in the financial sector.

good because

Pattern matching and discriminate unions,
Currying,
cleaner syntax, especially when nesting functions in functions and using tuples,
evaluated if statements,

bad because

must explicit cast from int to double, wtf?
must cast 'this' to interface type to use interface functions
no auto property (until F# 3.0)
currying can be really ugly

i prefer F# over C#, you make less mistakes and its easier to change your code because its so breif. Dont really need resharper, in C# resharper is a must

Sealed only applies to declarations, not to instances of the class, or am i missing something?

If you don't seal the class then it can be inherited and made not-immutable.

[quote name='Eelco' timestamp='1324400665' post='4895779']
Sealed only applies to declarations, not to instances of the class, or am i missing something?

If you don't seal the class then it can be inherited and made not-immutable.
[/quote]

Yes, but only if you instantiate that subclass. The issue im concerned with is that an object gotten from a readonly property need itself not be immutable. Even though the object pointed to might not change, the content of the object very well might. Thats a rather useless form of immutability, for the purposes of functional programming.

must explicit cast from int to double, wtf?

I minor point id say, but one that makes sense. The integers are not a subset of the doubles, so it is by no means a lossless conversion. Personally I prefer to only have true upcasts be implicit.

[quote name='Telastyn' timestamp='1324405345' post='4895801']
[quote name='Eelco' timestamp='1324400665' post='4895779']
Sealed only applies to declarations, not to instances of the class, or am i missing something?

If you don't seal the class then it can be inherited and made not-immutable.
[/quote]

Yes, but only if you instantiate that subclass. The issue im concerned with is that an object gotten from a readonly property need itself not be immutable. Even though the object pointed to might not change, the content of the object very well might. Thats a rather useless form of immutability, for the purposes of functional programming.
[/quote]

I understand that, but if you write class A to be immutable, operations that work with A can make decisions based on that design. If some clever bastard comes along and makes B that subtypes A and isn't quite immutable, the function that works with A under the assumption of immutability will likely break. Hence the need to also make the type sealed in addition to effective immutability in order to maintain the implied contract with its consumers.

(and yes, having a compiler to verify such things would be nicer and easier)