Hacker News Reader

To put it simply, the amount of C# code written makes F# look like a rounding error.

If C# gets these improvements there will be millions of lines of C# that could get better without C# programmers having to learn F#.

It might be too late to update the BCL with them. But that doesn't make it too late to bring the updates to people who work with C# all the time.

I maintain a bunch of C# codebases, and I'd love to have more updates to the language.

Microsoft funds F# as a test playground for future C# features.

F# syntax is too verbose for OOP. Actually functional parts are too, like lambda syntax, LINQ etc. Unless it's improved C# is bound to remain mainstream.

"F# syntax is too verbose for OOP."

Wow. First time I've ever heard that.

It often looks like a mishmash of operators:

bla <- [|bla, bla|] 'bla ''bla |> func bla @@[bla; bla; bla]@@

That's not its OOP syntax. That's its functional syntax.

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.

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.

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-functio...), which would allow

    var inc(x) => x + 1;

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.

I would read this[1] article on F# if you want the realities of the situation

[1] http://ericsink.com/entries/fsharp_chasm.html

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/ 2: https://developer.apple.com/swift/ 3: https://developer.apple.com/library/ios/documentation/Swift/... 4: https://msdn.microsoft.com/en-us/vstudio/hh341490.aspx 5: https://msdn.microsoft.com/en-us/vstudio/hh388569.aspx 6: https://msdn.microsoft.com/en-us/vstudio/hh388573.aspx

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.

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-n...

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.

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.

I doubt your experience with Rust if you refer to its decision to opt for function-local type inference as "incorrect". Whole-program type inference works for scripts, but for programming in the large it's sheer horror. I want my functions to provide certain contracts, and I don't want to have to read the function body to ensure those contracts are upheld (and neither does the typechecker). Typed function signatures keep errors local and are the feature that keeps implicit return values from becoming a footgun.

Most of my experience is with F#, but I've simply not found it to be a problem. At module boundaries, I'm free to annotate as much as I want. The point is that it's up to me to decide what I need. I'd be surprised to find many cases where return types change around and the program still compiles but is now incorrect.

Ideally, items and expressions would have the same syntax and usability. I find in F#, I just start writing a long function with lots of nesting, then copy pieces out to refactor as needed.

Unfortunately, since people are dumb[1], we're stuck with C#. So they might as well improve it as much as possible. This feature could be layered on top of the BCL as extra metadata. Sorta like TypeScript allows you to add type annotations to third-party libraries, C# could take that approach with null. (Yes, this is sorta ugly.)

With tuples, C# can take F#'s approach and special-case common patterns (like TryParse that use out parameters). There's probably only a few patterns where this matters and you'd get most of the benefit. (And I suppose you could always provide annotations to note how to match certain non-tuple-returning functions.)

1: There's really no reason to use C# when we have F#, unless the app is some crap LOB app where programming style/syntax would be the highest barrier to entry. Even then I am suspicious. Anyways there's a lot of untalented developers that apparently cannot cope with FP, or much of anything really, and managers that are scared of different languages.