6 ms·

Is it just me, or is C# basically becoming Scala (or, insert your favorite functional language here). Don't get me wrong, this is awesome, .net on Linux, docker

Is it just me, or is C# basically becoming Scala (or, insert your favorite functional language here). Don't get me wrong, this is awesome, .net on Linux, dockerized, is all good, but these moves definitely show Microsoft responding to market changes in a way they didn't used to.

stupidcar 10y ago
C# first introduced lambdas and LINQ in v3, back in 2007. It was the first mainstream OO language to really push a more functional/mixed-paradigm approach. This is definitely an area where Microsoft has lead the market, not followed it.
- louthy 10y ago
  They may have been the first, and LINQ was (and is) a truly great feature (I'd love it if they'd expand the grammar, or allow computation expressions like F#); but the problem I've found with trying to do functional programming in C# is that there's no BCL support. Whereas F# has its functional prelude. I haven't spent much time with Scala, but I get the impression that a lot of the functional stuff is there by default (or at least easily accessibly via Scalaz) and therefore less inertia is needed to write functionally in Scala. Even with LINQ most C# programmers think it's just for querying databases or XML files, they don't realise they have built in monad semantics. I found that I'd have an immutable collections library over there, that wasn't aware of the Option type in that library over there. (So Map.Find(key) couldn't return an Option<V> for example - this makes composition more difficult). So although the language has been steadily going in the right direction, there has been less of a concerted effort on the library front. And therefore C# is still behind IMHO. This is something I've been trying to rectify, by essentially building a functional BCL [1]. I welcome the increased pace of functional features recently. Although sometimes it's frustrating seeing the direction they're going and wishing they'd get there much quicker (expressions everywhere, sum-types, record-types, better type inference). It's interesting that often C# is held up for its inability to do type-classes or ad-hoc polymorphism. But it is in fact possible with C# today [2] [3], and with zero cost (i.e. no reflection, additional memory allocations, or side-stepping of the type-system). It just causes a massive head-ache of manually provided generic arguments... [4] [5] I'd love it if the Roslyn team took some time to deal with the generic parameters inference story. It would help bring ad-hoc polymorphic types to C#, but it would just be awesome in general. [1] https://github.com/louthy/language-ext https://github.com/louthy/language-ext [2] https://github.com/louthy/language-ext/blob/type-classes/LanguageExt.Tests/TypeClassMonad.cs https://github.com/louthy/language-ext/blob/type-classes/Lan... [3] https://github.com/louthy/language-ext/blob/type-classes/LanguageExt.Tests/TypeClassMonoid.cs https://github.com/louthy/language-ext/blob/type-classes/Lan... [4] https://github.com/louthy/language-ext/blob/type-classes/LanguageExt.Core/TypeClasses/Monad/Monad.Prelude.cs#L70 https://github.com/louthy/language-ext/blob/type-classes/Lan... [5] https://github.com/louthy/language-ext/blob/type-classes/LanguageExt.Core/DataTypes/Option/Option.cs#L780 https://github.com/louthy/language-ext/blob/type-classes/Lan...
  - plaguuuuuu 10y ago
    That is really cool. I'm definitely going to try it out.
  - haimez 10y ago
    Arguably, that doesn't count as type classes because it REQUIRES call-site awareness of the implementation. This makes it fully ad-hoc and fully impractical as a useful abstraction. At that point you might as well call a static method without polymorphic parameter types, because it's just as (in)convenient and 100% more readable to the developer maintaining the project after you move on to a better programming language.
    - louthy 10y ago
      > Arguably, that doesn't count as type classes because it REQUIRES call-site awareness of the implementation Yes. I should have stated it's not real type-classes, but it is real ad-hoc polymorphism, which does get you much of the way there. The type-system won't infer the instance, you need to specify it manually. That doesn't make the solution less powerful from a generic programming point-of-view (if anything it makes it more powerful, because you can provide the instance you want to use); however it does make it more awkward to use. > and fully impractical as a useful abstraction. I disagree with this though. Finally being able to define a numeric type, or make types into real monads where a function can declare a constraint that requires an argument to be a monad is a good thing. > At that point you might as well call a static method without polymorphic parameter types From what I can tell, you're thinking of just the call site, but a whole call stack can carry through the constraint, and therefore the call site doesn't need the concrete implementation, it just needs a type that is constrained to the 'type class' (interface). The call site wouldn't know the type of the static method to call in your case. For example with a numeric type: public static T Add<T>(T lhs, T rhs) => // what static method can you call here? If you don't use polymorphic types, then you're not writing generic code, which is what this is for: public static class Math { public int Add(int lhs, int rhs) => lhs + rhs; public double Add(double lhs, double rhs) => lhs + rhs; public float Add(float lhs, float rhs) => lhs + rhs; public decimal Add(decimal lhs, decimal rhs) => lhs + rhs; } What about when you forget: BigInteger, short, byte, long, etc. But with the method I explained above: public interface Num<A> { A Add(A lhs, A rhs); } public struct NumInt : Num<int> { public int Add(int lhs, int rhs) => lhs + rhs; } public struct NumBigInt : Num<BigInteger> { public BigInteger Add(BigInteger lhs, BigInteger rhs) => lhs + rhs; } etc. Any code that works with numeric values can then be written once. I'm sure many C# programmers over the years have cursed over having to write N variants of something that should work with IArithmetic, or INumber, or something similar. This gets around that problem (and without causing any boxing either). So, personally, I think it has value. Even if it's only needed rarely. > because it's just as (in)convenient and 100% more readable to the developer maintaining the project after you move on to a better programming language. My library isn't about the mindset of programmers who are stuck in OO-land with all the conservative nonsense that goes along with it. So although I agree there's a learning curve, I don't think this is too problematic for those who want to write truly generic code. By the way, Microsoft are experimenting with this technique[1] (and new grammar) for future versions of C#. Whether it makes it or not, who knows, but I think it would be a super valuable feature for C#. [1] https://github.com/CaptainHayashi/roslyn/blob/master/concepts/docs/concepts.md https://github.com/CaptainHayashi/roslyn/blob/master/concept...
- addicted 10y ago
  MS's Scala equivalent would be F# which was out in 2005. This is just adding more functional programming aspects to their dominant language.
  - bigdubs 10y ago
    Pedantic comment incoming; F# is more of an ML implementation.
    - Rapzid 10y ago
      Pedant; you're missing the compare for the contrast.
  - seanmcdirmid 10y ago
    Scala is more OO than F# or even C#, in that it has very advanced OO features that are not seen in other OO languages. OO in F# is more about interop.
    - azth 10y ago
      What sort of advanced OO features are you referring to?
      - seanmcdirmid 10y ago
        Traits as full fledged mixins (including state!) are my favorite feature. No other language has this with static typing.
      - deleted 10y ago
        [deleted]
junkyarddog 10y ago
The C# team are very lucky to have F# as a reference implementation on how to implement ML style features on the .NET platform. I'm certain many more features from F#/OCaml will be added in forthcoming releases.
shados 10y ago
all modern languages are basically becoming functional languages, slowly. C# is essentially riding the mainstream wave, trickling down features as the average developer gets familiar with the existing ones.
- naasking 10y ago
  I think you've got it backwards. C# was one of the principle drivers of this wave.
  - oblio 10y ago
    Plus it was the first truly mainstream language to have async/await.
    - rpeden 10y ago
      To be fair, I think VB.NET got async and await at the same time C# did. Lambdas, too.
    - shados 10y ago
      async/await are ways to take functional constructs and make them imperative. So not really relevant in this case (and are actually the reverse)
  - shados 10y ago
    No, not backward, maybe my wording was simply ambiguous. When I say "riding the wave", what I mean is that they are adding functional features as the regular OOP/imperative programmers in the mainstream are done "accepting" the previous ones they added, as opposed to adding everything in one shot and have people get overwhelmed. I didn't mean they were following a wave or anything. Analogies are hard.
corysama 10y ago
C# progress is strongly driven by Microsoft Research. Microsoft Research contains a lot of functional programming fans. I'm quite happy to watch MSR slowly convert the hoard of C# programmers from Java++ devs to Haskell|OCaml devs.
- Locke1689 10y ago
  This is actually not the case -- none of the members of the language design team are MSR employees.
  - junkyarddog 10y ago
    But they have the F# and Haskell teams, who are nearby, to talk to. In particular, F# seems to have had a great influence lately.
CurtHagenlocher 10y ago
It's much easier to change the compiler now that it's implemented in C#. The C++ implementation was much harder to add features to.
- ygra 10y ago
  I don't think it was so much a problem of the implementation language, but rather that every feature needed to be present in both the compiler and VS (for syntax highlighting and IntelliSense) and those have been completely different implementations (I think highlighting and IntelliSense even were different parts). So you had to touch two or three completely different codebases whereas now you only have one.
Locke1689 10y ago
The C# LDM takes inspiration from good ideas from everywhere, including Scala.
Bombthecat 10y ago
It was clear that ms won't stop adding features aftwr version 3 or 4.i guess c# will be the: does all, can do all and includes all patterns, functions, methods from all other languages you can think of. There seems to be no control, no feature lock, no "our language will be like language x" or definition they follow. It seems more like they listen to the whole community of developers. All of them.
- simfoo 10y ago
  Which is funny, because I still remember their "every new feature request starts with -100 points and has to prove real benefits before even being considered for the language" speech
  - ygra 10y ago
    If you follow the language design process (which now is public on Github), they still very carefully consider new features for the language and don't just throw everything in there that people request.
skocznymroczny 10y ago
Every language falls victim to the functional paradigm over time, because functional language community is very vocal and promises riches if you use their paradigms. But when you do implement them, they turn out to be hard to use or not viable for big applications and people stick to their old languages anyway.
jordz 10y ago
The .NET CLR has advantages over the JVM, especially when comparing C# / F# -> Scala / Java. At a language level, the use of type erasure for generics (which is done at compile-time in Scala/Java) allows you to do things that the .NET CLR wouldn't allow you to do because Generics is part of IL. C# isn't becoming Scala but functional paradigms are coming through into languages as an evolution, rather than stagnating (this is great, in my opinion). These languages are a part of the .NET eco-system and are fantastic, I'm pleased with the path they're going down, albeit maybe they could improve certain syntax in C# 7.0 ;)

stupidcar 10y ago

C# first introduced lambdas and LINQ in v3, back in 2007. It was the first mainstream OO language to really push a more functional/mixed-paradigm approach. This is definitely an area where Microsoft has lead the market, not followed it.

louthy 10y ago
They may have been the first, and LINQ was (and is) a truly great feature (I'd love it if they'd expand the grammar, or allow computation expressions like F#); but the problem I've found with trying to do functional programming in C# is that there's no BCL support. Whereas F# has its functional prelude. I haven't spent much time with Scala, but I get the impression that a lot of the functional stuff is there by default (or at least easily accessibly via Scalaz) and therefore less inertia is needed to write functionally in Scala. Even with LINQ most C# programmers think it's just for querying databases or XML files, they don't realise they have built in monad semantics. I found that I'd have an immutable collections library over there, that wasn't aware of the Option type in that library over there. (So Map.Find(key) couldn't return an Option<V> for example - this makes composition more difficult). So although the language has been steadily going in the right direction, there has been less of a concerted effort on the library front. And therefore C# is still behind IMHO. This is something I've been trying to rectify, by essentially building a functional BCL [1]. I welcome the increased pace of functional features recently. Although sometimes it's frustrating seeing the direction they're going and wishing they'd get there much quicker (expressions everywhere, sum-types, record-types, better type inference). It's interesting that often C# is held up for its inability to do type-classes or ad-hoc polymorphism. But it is in fact possible with C# today [2] [3], and with zero cost (i.e. no reflection, additional memory allocations, or side-stepping of the type-system). It just causes a massive head-ache of manually provided generic arguments... [4] [5] I'd love it if the Roslyn team took some time to deal with the generic parameters inference story. It would help bring ad-hoc polymorphic types to C#, but it would just be awesome in general. [1] https://github.com/louthy/language-ext https://github.com/louthy/language-ext [2] https://github.com/louthy/language-ext/blob/type-classes/LanguageExt.Tests/TypeClassMonad.cs https://github.com/louthy/language-ext/blob/type-classes/Lan... [3] https://github.com/louthy/language-ext/blob/type-classes/LanguageExt.Tests/TypeClassMonoid.cs https://github.com/louthy/language-ext/blob/type-classes/Lan... [4] https://github.com/louthy/language-ext/blob/type-classes/LanguageExt.Core/TypeClasses/Monad/Monad.Prelude.cs#L70 https://github.com/louthy/language-ext/blob/type-classes/Lan... [5] https://github.com/louthy/language-ext/blob/type-classes/LanguageExt.Core/DataTypes/Option/Option.cs#L780 https://github.com/louthy/language-ext/blob/type-classes/Lan...
- plaguuuuuu 10y ago
  That is really cool. I'm definitely going to try it out.
- haimez 10y ago
  Arguably, that doesn't count as type classes because it REQUIRES call-site awareness of the implementation. This makes it fully ad-hoc and fully impractical as a useful abstraction. At that point you might as well call a static method without polymorphic parameter types, because it's just as (in)convenient and 100% more readable to the developer maintaining the project after you move on to a better programming language.
  - louthy 10y ago
    > Arguably, that doesn't count as type classes because it REQUIRES call-site awareness of the implementation Yes. I should have stated it's not real type-classes, but it is real ad-hoc polymorphism, which does get you much of the way there. The type-system won't infer the instance, you need to specify it manually. That doesn't make the solution less powerful from a generic programming point-of-view (if anything it makes it more powerful, because you can provide the instance you want to use); however it does make it more awkward to use. > and fully impractical as a useful abstraction. I disagree with this though. Finally being able to define a numeric type, or make types into real monads where a function can declare a constraint that requires an argument to be a monad is a good thing. > At that point you might as well call a static method without polymorphic parameter types From what I can tell, you're thinking of just the call site, but a whole call stack can carry through the constraint, and therefore the call site doesn't need the concrete implementation, it just needs a type that is constrained to the 'type class' (interface). The call site wouldn't know the type of the static method to call in your case. For example with a numeric type: public static T Add<T>(T lhs, T rhs) => // what static method can you call here? If you don't use polymorphic types, then you're not writing generic code, which is what this is for: public static class Math { public int Add(int lhs, int rhs) => lhs + rhs; public double Add(double lhs, double rhs) => lhs + rhs; public float Add(float lhs, float rhs) => lhs + rhs; public decimal Add(decimal lhs, decimal rhs) => lhs + rhs; } What about when you forget: BigInteger, short, byte, long, etc. But with the method I explained above: public interface Num<A> { A Add(A lhs, A rhs); } public struct NumInt : Num<int> { public int Add(int lhs, int rhs) => lhs + rhs; } public struct NumBigInt : Num<BigInteger> { public BigInteger Add(BigInteger lhs, BigInteger rhs) => lhs + rhs; } etc. Any code that works with numeric values can then be written once. I'm sure many C# programmers over the years have cursed over having to write N variants of something that should work with IArithmetic, or INumber, or something similar. This gets around that problem (and without causing any boxing either). So, personally, I think it has value. Even if it's only needed rarely. > because it's just as (in)convenient and 100% more readable to the developer maintaining the project after you move on to a better programming language. My library isn't about the mindset of programmers who are stuck in OO-land with all the conservative nonsense that goes along with it. So although I agree there's a learning curve, I don't think this is too problematic for those who want to write truly generic code. By the way, Microsoft are experimenting with this technique[1] (and new grammar) for future versions of C#. Whether it makes it or not, who knows, but I think it would be a super valuable feature for C#. [1] https://github.com/CaptainHayashi/roslyn/blob/master/concepts/docs/concepts.md https://github.com/CaptainHayashi/roslyn/blob/master/concept...
addicted 10y ago
MS's Scala equivalent would be F# which was out in 2005. This is just adding more functional programming aspects to their dominant language.
- bigdubs 10y ago
  Pedantic comment incoming; F# is more of an ML implementation.
  - Rapzid 10y ago
    Pedant; you're missing the compare for the contrast.
- seanmcdirmid 10y ago
  Scala is more OO than F# or even C#, in that it has very advanced OO features that are not seen in other OO languages. OO in F# is more about interop.
  - azth 10y ago
    What sort of advanced OO features are you referring to?
    - seanmcdirmid 10y ago
      Traits as full fledged mixins (including state!) are my favorite feature. No other language has this with static typing.
    - deleted 10y ago
      [deleted]

junkyarddog 10y ago

The C# team are very lucky to have F# as a reference implementation on how to implement ML style features on the .NET platform. I'm certain many more features from F#/OCaml will be added in forthcoming releases.

shados 10y ago

all modern languages are basically becoming functional languages, slowly. C# is essentially riding the mainstream wave, trickling down features as the average developer gets familiar with the existing ones.

naasking 10y ago
I think you've got it backwards. C# was one of the principle drivers of this wave.
- oblio 10y ago
  Plus it was the first truly mainstream language to have async/await.
  - rpeden 10y ago
    To be fair, I think VB.NET got async and await at the same time C# did. Lambdas, too.
  - shados 10y ago
    async/await are ways to take functional constructs and make them imperative. So not really relevant in this case (and are actually the reverse)
- shados 10y ago
  No, not backward, maybe my wording was simply ambiguous. When I say "riding the wave", what I mean is that they are adding functional features as the regular OOP/imperative programmers in the mainstream are done "accepting" the previous ones they added, as opposed to adding everything in one shot and have people get overwhelmed. I didn't mean they were following a wave or anything. Analogies are hard.

corysama 10y ago

C# progress is strongly driven by Microsoft Research. Microsoft Research contains a lot of functional programming fans. I'm quite happy to watch MSR slowly convert the hoard of C# programmers from Java++ devs to Haskell|OCaml devs.

Locke1689 10y ago
This is actually not the case -- none of the members of the language design team are MSR employees.
- junkyarddog 10y ago
  But they have the F# and Haskell teams, who are nearby, to talk to. In particular, F# seems to have had a great influence lately.

CurtHagenlocher 10y ago

It's much easier to change the compiler now that it's implemented in C#. The C++ implementation was much harder to add features to.

ygra 10y ago
I don't think it was so much a problem of the implementation language, but rather that every feature needed to be present in both the compiler and VS (for syntax highlighting and IntelliSense) and those have been completely different implementations (I think highlighting and IntelliSense even were different parts). So you had to touch two or three completely different codebases whereas now you only have one.

Locke1689 10y ago

The C# LDM takes inspiration from good ideas from everywhere, including Scala.

Bombthecat 10y ago

It was clear that ms won't stop adding features aftwr version 3 or 4.i guess c# will be the: does all, can do all and includes all patterns, functions, methods from all other languages you can think of. There seems to be no control, no feature lock, no "our language will be like language x" or definition they follow. It seems more like they listen to the whole community of developers. All of them.

simfoo 10y ago
Which is funny, because I still remember their "every new feature request starts with -100 points and has to prove real benefits before even being considered for the language" speech
- ygra 10y ago
  If you follow the language design process (which now is public on Github), they still very carefully consider new features for the language and don't just throw everything in there that people request.

skocznymroczny 10y ago

Every language falls victim to the functional paradigm over time, because functional language community is very vocal and promises riches if you use their paradigms. But when you do implement them, they turn out to be hard to use or not viable for big applications and people stick to their old languages anyway.

jordz 10y ago

The .NET CLR has advantages over the JVM, especially when comparing C# / F# -> Scala / Java. At a language level, the use of type erasure for generics (which is done at compile-time in Scala/Java) allows you to do things that the .NET CLR wouldn't allow you to do because Generics is part of IL. C# isn't becoming Scala but functional paradigms are coming through into languages as an evolution, rather than stagnating (this is great, in my opinion). These languages are a part of the .NET eco-system and are fantastic, I'm pleased with the path they're going down, albeit maybe they could improve certain syntax in C# 7.0 ;)