3 ms·

Can you explain? In C#, for example, type inference barely works. You have to do e.g.: Func<int, int> inc = x => x + 1; In F#, this is just: let inc x =

Can you explain? In C#, for example, type inference barely works. You have to do e.g.: Func<int, int> inc = x => x + 1; In F#, this is just: let inc x = x + 1 Based off a simple test (coded same thing in both languages), C# requires about 20x more type annotations. Fields, methods, type parameter constraints -- C# simply doesn't implement type inference in most places. You're right that F#'s lambda operator (fun) should be shorter. I'd prefer \. i.e. map (\x.x+1) But verbosity isn't the reason C# devs don't switch to F#. Hell, it's still a "thing" to decide if using "var" is ok.

sixbrx 11y ago
I'm not sure \ is better than "fun", fun does have a certain clarity when reading code, and it's only three extra keystrokes if you include the space, all easier to type than backslash which needs a pinky stretch. Honestly I could go either way though. Also note that C# loses brevity as soon as there are more args than one (such as with commonly used Seq.iteri or folds) because of having to type the "(,)" for C# (the parens annoyingly requiring shift keys) instead of just a space.
Locke1689 11y ago
That's not a "problem" in type inference, that's a design decision where lambda syntax can represent either delegates or expression statements. This is how LINQ-to-SQL can take a LINQ expression and turn it into a SQL statement. However, that doesn't mean we don't wish you wouldn't have to specify the type there -- that's why there's a separate proposal for local functions (https://github.com/dotnet/roslyn/tree/features/local-functions https://github.com/dotnet/roslyn/tree/features/local-functio...), which would allow var inc(x) => x + 1;
- MichaelGG 11y ago
  Yeah, I know the reasoning, I just find it faulty. It's confusing to not know if your code is code or turned into an expression tree. So with that, local functions will have different syntax than normal functions? I don't envy y'all on the C# team; it's gotta be difficult to try to advance it while maintaining backcompat. I just wish MS would put more money and clear marketing into F# instead of pretending like hacking up C# syntax is the only way to continue.
  - Locke1689 11y ago
    I would read this[1] article on F# if you want the realities of the situation [1] http://ericsink.com/entries/fsharp_chasm.html http://ericsink.com/entries/fsharp_chasm.html
    - MichaelGG 11y ago
      That's an excellent post as Eric's a smart guy yet misses the real reasons. Eric's wrong about Swift, and the reason is illuminating. Swift has the full, unconditional support of Apple. Look at the splash pages for Swift[1][2]. There's no comparable page for Obj-C. The docs on Swift[3] make it clear that you're totally set and don't need to worry. It's obvious to any developer that choosing Swift is a good, safe, correct choice and you won't be left hanging. Microsoft chose not to do this for F#. Now compare to how MS markets C#[4] vs F#[5]. C#'s clearly sold as the general dev language for "rapid application development", whereas F# is to "solve complex problems ... such as calculation engines and data-rich analytical services". This sums up MS's attitude, which percolates to customers. F# is just for hyper-intelligent folks doing mathy stuff - not for us normal devs! C# should instead be pitched focusing on it's "familiarity and userbase" just like VB has "English-like syntax which promotes clarity"[6]. Inside VS and .NET overall, it's clear that F# is simply not getting the same level of support. So while Eric might be pointing out that "normal people", meaning the bulk of MS customers, are staying with C# this is just MS fulfilling it's marketing goals. MS refuses to reassure customers that F# can and should be considered for any application where C# is considered. Until that attitude changes, I would not be surprised if customers continue to do what MS says to do. I doubt it'll change. C# has no real competitor (Java's lightyears behind). They've got a proven track record of ignoring F#. Add in the politics and face issues going on (going off the history as well as comments from third parties that have been involved on both sides) and well, what can we really hope for? 1: http://www.apple.com/swift/ http://www.apple.com/swift/ 2: https://developer.apple.com/swift/ https://developer.apple.com/swift/ 3: https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/ https://developer.apple.com/library/ios/documentation/Swift/... 4: https://msdn.microsoft.com/en-us/vstudio/hh341490.aspx https://msdn.microsoft.com/en-us/vstudio/hh341490.aspx 5: https://msdn.microsoft.com/en-us/vstudio/hh388569.aspx https://msdn.microsoft.com/en-us/vstudio/hh388569.aspx 6: https://msdn.microsoft.com/en-us/vstudio/hh388573.aspx https://msdn.microsoft.com/en-us/vstudio/hh388573.aspx
ygra 11y ago
As for fields and other class-level type declarations not using type inference, I guess that's a very conscious decision, considering that those constitute an API, which should be carefully changed, if at all. Just having a method return type silently change when you change something in the method body sounds a bit off to me in that context.
- MichaelGG 11y ago
  I don't think so. Eric Lippert says its due to internal compiler limitations[1]. Though now that they rewrote the compiler and haven't fixed it, who knows. Rust (incorrectly) deliberately requires type annotations for top-level items in the name of clarity. (Which ironically, makes it more difficult for beginners as they now have to make sure they got the type syntax correct just to write functions. Plus it adds visual noise that should be up to the programmer.) As for things changing with type inference... if you run into that problem then add annotations. I'd be surprised if things continue to build after changing e.g. return types. I'd imagine this would only really be a problem with types that have implicit conversions (yet another reason to not have implicit conversions.) 1: http://blogs.msdn.com/b/ericlippert/archive/2009/01/26/why-no-var-on-fields.aspx http://blogs.msdn.com/b/ericlippert/archive/2009/01/26/why-n...
  - Locke1689 11y ago
    Eric is wrong.[1] We could change it, we're choosing not to and I vehemently disagree with those who think we should change it. [1] Well, he was right when he wrote that, but he's wrong now.
    - MichaelGG 11y ago
      Well, that's disappointing. It'd be nice if C# allowed more succinctness, and eliding type annotations is a major part of that. It feels like those aspects of C# were chosen just to implement LINQ, then forgotten. Also don't mistake my tone in my comments. While I am annoyed with the direction MS is taking, C# is still obviously better than most languages and the tooling is a fantastic. I'm happy it is still being improved, despite detractors saying it's too kitchen-sinky or changing too fast.

sixbrx 11y ago

I'm not sure \ is better than "fun", fun does have a certain clarity when reading code, and it's only three extra keystrokes if you include the space, all easier to type than backslash which needs a pinky stretch. Honestly I could go either way though. Also note that C# loses brevity as soon as there are more args than one (such as with commonly used Seq.iteri or folds) because of having to type the "(,)" for C# (the parens annoyingly requiring shift keys) instead of just a space.

Locke1689 11y ago

That's not a "problem" in type inference, that's a design decision where lambda syntax can represent either delegates or expression statements. This is how LINQ-to-SQL can take a LINQ expression and turn it into a SQL statement. However, that doesn't mean we don't wish you wouldn't have to specify the type there -- that's why there's a separate proposal for local functions (https://github.com/dotnet/roslyn/tree/features/local-functions https://github.com/dotnet/roslyn/tree/features/local-functio...), which would allow var inc(x) => x + 1;

MichaelGG 11y ago
Yeah, I know the reasoning, I just find it faulty. It's confusing to not know if your code is code or turned into an expression tree. So with that, local functions will have different syntax than normal functions? I don't envy y'all on the C# team; it's gotta be difficult to try to advance it while maintaining backcompat. I just wish MS would put more money and clear marketing into F# instead of pretending like hacking up C# syntax is the only way to continue.
- Locke1689 11y ago
  I would read this[1] article on F# if you want the realities of the situation [1] http://ericsink.com/entries/fsharp_chasm.html http://ericsink.com/entries/fsharp_chasm.html
  - MichaelGG 11y ago
    That's an excellent post as Eric's a smart guy yet misses the real reasons. Eric's wrong about Swift, and the reason is illuminating. Swift has the full, unconditional support of Apple. Look at the splash pages for Swift[1][2]. There's no comparable page for Obj-C. The docs on Swift[3] make it clear that you're totally set and don't need to worry. It's obvious to any developer that choosing Swift is a good, safe, correct choice and you won't be left hanging. Microsoft chose not to do this for F#. Now compare to how MS markets C#[4] vs F#[5]. C#'s clearly sold as the general dev language for "rapid application development", whereas F# is to "solve complex problems ... such as calculation engines and data-rich analytical services". This sums up MS's attitude, which percolates to customers. F# is just for hyper-intelligent folks doing mathy stuff - not for us normal devs! C# should instead be pitched focusing on it's "familiarity and userbase" just like VB has "English-like syntax which promotes clarity"[6]. Inside VS and .NET overall, it's clear that F# is simply not getting the same level of support. So while Eric might be pointing out that "normal people", meaning the bulk of MS customers, are staying with C# this is just MS fulfilling it's marketing goals. MS refuses to reassure customers that F# can and should be considered for any application where C# is considered. Until that attitude changes, I would not be surprised if customers continue to do what MS says to do. I doubt it'll change. C# has no real competitor (Java's lightyears behind). They've got a proven track record of ignoring F#. Add in the politics and face issues going on (going off the history as well as comments from third parties that have been involved on both sides) and well, what can we really hope for? 1: http://www.apple.com/swift/ http://www.apple.com/swift/ 2: https://developer.apple.com/swift/ https://developer.apple.com/swift/ 3: https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/ https://developer.apple.com/library/ios/documentation/Swift/... 4: https://msdn.microsoft.com/en-us/vstudio/hh341490.aspx https://msdn.microsoft.com/en-us/vstudio/hh341490.aspx 5: https://msdn.microsoft.com/en-us/vstudio/hh388569.aspx https://msdn.microsoft.com/en-us/vstudio/hh388569.aspx 6: https://msdn.microsoft.com/en-us/vstudio/hh388573.aspx https://msdn.microsoft.com/en-us/vstudio/hh388573.aspx

ygra 11y ago

As for fields and other class-level type declarations not using type inference, I guess that's a very conscious decision, considering that those constitute an API, which should be carefully changed, if at all. Just having a method return type silently change when you change something in the method body sounds a bit off to me in that context.

MichaelGG 11y ago
I don't think so. Eric Lippert says its due to internal compiler limitations[1]. Though now that they rewrote the compiler and haven't fixed it, who knows. Rust (incorrectly) deliberately requires type annotations for top-level items in the name of clarity. (Which ironically, makes it more difficult for beginners as they now have to make sure they got the type syntax correct just to write functions. Plus it adds visual noise that should be up to the programmer.) As for things changing with type inference... if you run into that problem then add annotations. I'd be surprised if things continue to build after changing e.g. return types. I'd imagine this would only really be a problem with types that have implicit conversions (yet another reason to not have implicit conversions.) 1: http://blogs.msdn.com/b/ericlippert/archive/2009/01/26/why-no-var-on-fields.aspx http://blogs.msdn.com/b/ericlippert/archive/2009/01/26/why-n...
- Locke1689 11y ago
  Eric is wrong.[1] We could change it, we're choosing not to and I vehemently disagree with those who think we should change it. [1] Well, he was right when he wrote that, but he's wrong now.
  - MichaelGG 11y ago
    Well, that's disappointing. It'd be nice if C# allowed more succinctness, and eliding type annotations is a major part of that. It feels like those aspects of C# were chosen just to implement LINQ, then forgotten. Also don't mistake my tone in my comments. While I am annoyed with the direction MS is taking, C# is still obviously better than most languages and the tooling is a fantastic. I'm happy it is still being improved, despite detractors saying it's too kitchen-sinky or changing too fast.