31 ms·

Good start, finally adding records, patterns, tuples, non null, would be a good first step to making C# not feel so heavyweight compared to F#. If the F# team e

Good start, finally adding records, patterns, tuples, non null, would be a good first step to making C# not feel so heavyweight compared to F#. If the F# team ever gets enough resources to complete with C#'s VS features, perhaps we'd get some serious adoption. As is, F# comes across second class both in tooling and MS marketing - that's not really competing fairly ;) But without making things expressions, it's still gonna be clunky. First class immutability and expressions instead of statements would help propel it further. I still would feel rather limited about having no type inference on local functions, though. What would be really exciting is if the runtime was also open for some real changes. Traits, non null, slices, maybe even ownership (so we could stack alloc, a huge perf win)... One can dream.

deleted 12y ago
[deleted]
riffraff 12y ago
doesn't C# already have structs ? how are records different from that?
- sanxiyn 12y ago
  Structs have names. Records don't. See http://en.wikipedia.org/wiki/Nominal_type_system http://en.wikipedia.org/wiki/Nominal_type_system and http://en.wikipedia.org/wiki/Structural_type_system http://en.wikipedia.org/wiki/Structural_type_system.
- nikbackm 12y ago
  http://stackoverflow.com/questions/5858550/f-records-vs-net-struct http://stackoverflow.com/questions/5858550/f-records-vs-net-...
- jameshart 12y ago
  C# has anonymous types, which are closer to records, but there's no way to refer to a particular type structure. So while I can write var x = { FirstName = "Riff", LastName = "Raff" } and then go ahead and access x.FirstName and x.LastName, I can't declare a method signature like this: void Display({ string FirstName, string LastName } nameRecord) { } This is the kind of thing which is being proposed (along with possible pattern matching/decomposition syntax which is new ground for C#)
hrvbr 12y ago
Just yesterday there was this article illustrating how C# fundamentally can't catch-up with F# on some important characteristics: http://fsharpforfunandprofit.com/posts/is-your-language-unreasonable/ http://fsharpforfunandprofit.com/posts/is-your-language-unre...
- Someone1234 12y ago
  > Comparing objects of different types is a compile-time error. Then use C. In OOP comparing objects of different types is key to inheritance. The reason their example works is because everything in C# inherits from object, so you'll always find some commonality to compare. You could have the compiler generate a warning when object.equals is used (rather than overridden) but getting rid of comparisons between different object types completely is backwards and will reduce efficiency.
- organsnyder 12y ago
  That article could be summed up as: "Look at all of the ways that the language doesn't protect you from yourself (or the creator of the library you're using)!" It's possible to write shitty code in every programming language. Of course, the specific methods of doing so differ, but I've yet to see a Turing-complete language that makes it impossible to write buggy code.
- achr2 12y ago
  What a poor article.. let me just cherry pick a number of benefits of functional languages and call them requirements for a 'reasonable' language.
tejinderss 12y ago
AFAIK F# is the first class VS citizen since VS 2010. They have a small yet good team working on it. What do you think is missing support in VS for f#?
- MichaelGG 12y ago
  In general, overall tooling is not at the same level. Code gen is focused on a C#-like model, designers aren't there, debugging isn't the same (immediate window, for instance). Last i checked (which was a while ago), VS testing didn't work with F#. Even Intellisense is not as complete. I'm happy with F#, very happy indeed. But it lacks the resources that C# gets thrown at it. And it suffers from MS not having the honesty to just admit MSR outdid them again (as they did with generics), that as a language, F# simply outclasses C#. Instead, we get lines like "F# is for scientific computing" or similar spin. So yes, shipping F# with VS is a good step, and technically it's supported, it's obvious MS has some discomfort there. Which is too bad, cause F# is a rare jewel, nothing else has the combination of language features, interop/library, performance, and tooling.
  - pjmlp 12y ago
    > Instead, we get lines like "F# is for scientific computing" or similar spin. You will never sell the typical VB.NET/C# enterprise .NET developer into F#. I find very commendable what Microsot has done so far, even if it feels too little. It rises the visibility of the language, specially to managers and drives CLR design decisions that help FP implementations, like TCO. Let me know when Oracle gives at very least the same level of support to Scala in Netbeans and JVM design.
    - MichaelGG 12y ago
      F# doesn't (or didn't) use tailcall in CLR in general, because it was too slow. It only does so as a last resort. Or did that all change? Same with stuff like tuples. We get tons of heap allocations because the CLR did poorly with structs. F# had to even go back on their design because of this, and match the BCL tuple type. MS doesn't need to sell the typical enterprise dev. They just need to not sour-coat things and be honest and complete in their statements. It'd also be nice if MS viewed shipping actual language independent code, instead of stuff that takes dependencies on C# compiler details. MS gained a huge amount from the F# folks by getting CLR generics from them - that's one major benefit over the JVM. Just on that alone perhaps they owe them that (maybe, I've little clue of internal politics, except that there is some resentment towards F#, and at least a bit of censorship on publishing things that make C# look poor). Let me know when Microsoft starts shipping Rust-level features, so we can deal with memory safely and reduce bugs without losing perf.
phatboyslim 12y ago
I believe c# has had tuple support since .net framework v4.
- mvitorino 12y ago
  I believe tuple support in v4 is a simple set of classes. There is no language construct specific for the use of tuples, which means it's just a library instead of a programming language feature.
  - andyjohnson0 12y ago
    What are the advantages that language-level tuples would have over the existing System.Tuple class?
    - alkonaut 12y ago
      Without deconstruction and pattern matching, language level tuples would be only sugar: "var x = (1, 2)" versus "var x = Tuple.Create(1,2)" The real power of Tuples only comes with deconstruction and matching, such as "var (a,b) = GetSomething()" and "case (_, y)". So these features would go hand in hand. Deconstruction and matching requires lang level tuples, and lang level tuples are pretty lame without deconstruction and pattern matching.
    - olavk 12y ago
      The ability to write (2, "hello") instead of Tuple.Create(2, "Hello"). But more importantly, syntax for deconstructing tuples will make tuples convenient for returning multiple values from a method. Eg.: (var x, var y) = getPoint(); as shown in the aticle.
      - MichaelGG 12y ago
        Also, the type is simpler to represent. Instead of Tuple<int, string> you just have something like (Int, String).

deleted 12y ago

[deleted]

riffraff 12y ago

doesn't C# already have structs ? how are records different from that?

sanxiyn 12y ago
Structs have names. Records don't. See http://en.wikipedia.org/wiki/Nominal_type_system http://en.wikipedia.org/wiki/Nominal_type_system and http://en.wikipedia.org/wiki/Structural_type_system http://en.wikipedia.org/wiki/Structural_type_system.
nikbackm 12y ago
http://stackoverflow.com/questions/5858550/f-records-vs-net-struct http://stackoverflow.com/questions/5858550/f-records-vs-net-...
jameshart 12y ago
C# has anonymous types, which are closer to records, but there's no way to refer to a particular type structure. So while I can write var x = { FirstName = "Riff", LastName = "Raff" } and then go ahead and access x.FirstName and x.LastName, I can't declare a method signature like this: void Display({ string FirstName, string LastName } nameRecord) { } This is the kind of thing which is being proposed (along with possible pattern matching/decomposition syntax which is new ground for C#)

hrvbr 12y ago

Just yesterday there was this article illustrating how C# fundamentally can't catch-up with F# on some important characteristics: http://fsharpforfunandprofit.com/posts/is-your-language-unreasonable/ http://fsharpforfunandprofit.com/posts/is-your-language-unre...

Someone1234 12y ago
> Comparing objects of different types is a compile-time error. Then use C. In OOP comparing objects of different types is key to inheritance. The reason their example works is because everything in C# inherits from object, so you'll always find some commonality to compare. You could have the compiler generate a warning when object.equals is used (rather than overridden) but getting rid of comparisons between different object types completely is backwards and will reduce efficiency.
organsnyder 12y ago
That article could be summed up as: "Look at all of the ways that the language doesn't protect you from yourself (or the creator of the library you're using)!" It's possible to write shitty code in every programming language. Of course, the specific methods of doing so differ, but I've yet to see a Turing-complete language that makes it impossible to write buggy code.
achr2 12y ago
What a poor article.. let me just cherry pick a number of benefits of functional languages and call them requirements for a 'reasonable' language.

tejinderss 12y ago

AFAIK F# is the first class VS citizen since VS 2010. They have a small yet good team working on it. What do you think is missing support in VS for f#?

MichaelGG 12y ago
In general, overall tooling is not at the same level. Code gen is focused on a C#-like model, designers aren't there, debugging isn't the same (immediate window, for instance). Last i checked (which was a while ago), VS testing didn't work with F#. Even Intellisense is not as complete. I'm happy with F#, very happy indeed. But it lacks the resources that C# gets thrown at it. And it suffers from MS not having the honesty to just admit MSR outdid them again (as they did with generics), that as a language, F# simply outclasses C#. Instead, we get lines like "F# is for scientific computing" or similar spin. So yes, shipping F# with VS is a good step, and technically it's supported, it's obvious MS has some discomfort there. Which is too bad, cause F# is a rare jewel, nothing else has the combination of language features, interop/library, performance, and tooling.
- pjmlp 12y ago
  > Instead, we get lines like "F# is for scientific computing" or similar spin. You will never sell the typical VB.NET/C# enterprise .NET developer into F#. I find very commendable what Microsot has done so far, even if it feels too little. It rises the visibility of the language, specially to managers and drives CLR design decisions that help FP implementations, like TCO. Let me know when Oracle gives at very least the same level of support to Scala in Netbeans and JVM design.
  - MichaelGG 12y ago
    F# doesn't (or didn't) use tailcall in CLR in general, because it was too slow. It only does so as a last resort. Or did that all change? Same with stuff like tuples. We get tons of heap allocations because the CLR did poorly with structs. F# had to even go back on their design because of this, and match the BCL tuple type. MS doesn't need to sell the typical enterprise dev. They just need to not sour-coat things and be honest and complete in their statements. It'd also be nice if MS viewed shipping actual language independent code, instead of stuff that takes dependencies on C# compiler details. MS gained a huge amount from the F# folks by getting CLR generics from them - that's one major benefit over the JVM. Just on that alone perhaps they owe them that (maybe, I've little clue of internal politics, except that there is some resentment towards F#, and at least a bit of censorship on publishing things that make C# look poor). Let me know when Microsoft starts shipping Rust-level features, so we can deal with memory safely and reduce bugs without losing perf.

phatboyslim 12y ago

I believe c# has had tuple support since .net framework v4.

mvitorino 12y ago
I believe tuple support in v4 is a simple set of classes. There is no language construct specific for the use of tuples, which means it's just a library instead of a programming language feature.
- andyjohnson0 12y ago
  What are the advantages that language-level tuples would have over the existing System.Tuple class?
  - alkonaut 12y ago
    Without deconstruction and pattern matching, language level tuples would be only sugar: "var x = (1, 2)" versus "var x = Tuple.Create(1,2)" The real power of Tuples only comes with deconstruction and matching, such as "var (a,b) = GetSomething()" and "case (_, y)". So these features would go hand in hand. Deconstruction and matching requires lang level tuples, and lang level tuples are pretty lame without deconstruction and pattern matching.
  - olavk 12y ago
    The ability to write (2, "hello") instead of Tuple.Create(2, "Hello"). But more importantly, syntax for deconstructing tuples will make tuples convenient for returning multiple values from a method. Eg.: (var x, var y) = getPoint(); as shown in the aticle.
    - MichaelGG 12y ago
      Also, the type is simpler to represent. Instead of Tuple<int, string> you just have something like (Int, String).