[Someone1234]

> Also C#'s statement-oriented nature just makes things ugly. Stuff like: [code]

I am not following what is bad about the example. Could you reproduce that same code in F# or whatever you're saying is better. It might help explain what you're getting at.

[latkin]

I think OP has something like this in mind:

  let x =
    if ... then
      let a = frob()
      Foo + a
    else Baz

`x` is never in an invalid/uninitialized state, and it's immediately clear exactly what code contributes toward computing its value.

Somewhat related, you can also define nested functions in F#, which is very convenient and tidy. No need for a pile of one-off private helpers at the same syntactic level as your public APIs - just tuck them inside the members which need them.

[noblethrasher]

You can define nested functions in C# in for form of lambdas or anonymous delegates. Admittedly, it's still not quite as pretty as it could be because we don't get to use automatic type propogation (e.g. the `var` keyword).

[louthy]

Of course you could do many things to make C# closer to F# (I've devoted a whole library to coercing it [1]). My preferred approach would be:

    var x = ... 
        ? Foo + frob()
        : Baz;

Or to be truer to the original (using my lib):

    var x = ...
        ? map(frob(), a => Foo + a)
        : Baz;

But the idioms of the language mean that in the real world you see the ugly version with the associated risks of uninitialised variables. I applaud the C# team for the direction they're taking. I suspect C# will end up closer to Scala than it will to F#, which isn't a bad niche for it to be.

[1] https://github.com/louthy/language-ext

[noblethrasher]

Agreed that C# will probably end up closer to Scala. For instance, it's already more straight-forward and elegant to simulate and use type classes/traits in C# than it is in F#.