4 ms·

I am not sure I like the path c# is going down. For years the language has been trying to evolve from being aesthetic and easy to understand and read. With th

I am not sure I like the path c# is going down. For years the language has been trying to evolve from being aesthetic and easy to understand and read. With the functional implementations and patterns I believe the language is trying to embrace too much. This is not specific to the swith expression in this context but in general. You can write C# in too many forms and I don't believe that's really good.

dgritsko 8y ago
> You can write C# in too many forms and I don't believe that's really good. Why not? And what, exactly, defines "too many"?
- azhenley 8y ago
  Perhaps he means something like Python's motto of "There should be one--and preferably only one--obvious way to do it." https://www.python.org/dev/peps/pep-0020/ https://www.python.org/dev/peps/pep-0020/
  - goto11 8y ago
    I think all the new features are improvements, but I agree the language is getting big with many ways to do the same thing. I don't think MS will ever do a 'Python 3' and cut backwards compatibility.
- kminehart 8y ago
  I know people meme a lot about Go and "not having generics," but I really feel that a lot of the things left out of Go have benefitted it. I've never really been able to jump into a project without a lot of mental overhead. With Go, most code everywhere is written pretty idiomatically, making it easy to approach and read. I've heard similar things about C#, but my experience hasn't been as great. This is a big problem in the JavaScript world in my opinion. So many different ways to solve common problems that it's difficult to approach. OP might be worried this could be happening to C#.
  - dgritsko 8y ago
    I suppose, but that seems like a natural consequence of C#'s desire to move the language "forward" in terms of implementing new features (such as switch expressions or non-nullable reference types) while also maintaining backwards compatibility (for example, you can still use the non-generic "ICollection" interface if you want to). Just a different set of priorities.
  - BoiledCabbage 8y ago
    We could go with a language with just if statements, while statements, function calls and "return" and be extremely easy to jump into. :) While a bit snarky I do think it is one of the fundamental problems with programming language innovation. No matter how smart we are, learning is effortful. And we frequently judge languages not by how productive it is, but by how quickly we can start feeling productive in it. Which often preferences familiar concepts over more powerful concepts. There is a very long feedback loop in properly evaluating a language. At least 1-2 years. You need not just figure out how to do what you already know in the language, you need to learn the new way to think in the language. And that takes time and solving lots of problems. This is only sped up if the language's concepts are kept very similar to a language you already know. We are the bottleneck that slows down language improvement. There is no way anyone can convince me that the hodgepodge of Algol derived languages is one of the best ways out there of writing code. But most new languages will be similar because the hurdles of trying to teach people anything else alongside the actual new interesting concepts of your language are too much of a blocker for any reasonable adoption.
  - flavio81 8y ago
    >I know people meme a lot about Go and "not having generics," but I really feel that a lot of the things left out of Go have benefitted it. Yes, that's why we program in Brainf__k here: It only has the bare essentials and it's so easy to learn.
- nordsieck 8y ago
  > Why not? And what, exactly, defines "too many"? I think Scala was innovating in this respect before Kotlin ate its lunch (it may still be). You could use Scala as everything between Java++ and Haskell--. Developers proficient in Java++ often had a difficult time understanding code written in Haskell--.
runT1ME 8y ago
I agree. It has the flexibility of Scala without the extra power/abstractions Scalaa gives you. I don't love Scala's flexibility but I put up with it because of its power, the trade off isn't worth it for C# to me.
kalekold 8y ago
I think I agree. I used to write a lot of C# v2 and loved it. There didn't seem to be anything 'missing'. Each version since then has added nice things but are they really necessary? Now the language looks huge and complicated and because of that, I'm not sure I'd ever want to use it again.
- goto11 8y ago
  C# 2 did not have Linq. Linq is the best feature ever.
  - Invisig0th 8y ago
    Actually, adding LINQ to C# did not introduce any new functionality at all. Everything you can do in LINQ you could already accomplish in C# without LINQ. Yes, I suppose someone could say that the older code was uglier, but it already had the same capabilities as LINQ. That's been the case for the majority of supposed "new features" in C# for at least the past 8 years or so -- LINQ, inline variables, anonymous functions, string literals etc. It's all just syntactic sugar on top of existing features.
    - Dylan16807 8y ago
      That's the general nature of a turing complete language. The purpose of every feature is making things less ugly.
      - Invisig0th 8y ago
        I'd say it's more the general nature of Microsoft in this particular case. "There should be three different ways to do that" has been the case since Windows 3.1.
    - contravariant 8y ago
      LINQ is surprisingly powerful when you start overloading SelectMany, as that allows you to implement Monads nicely.
    - 8y ago
JustSomeNobody 8y ago
Language designers are not immune to the "code must change constantly otherwise it's abandonware" mentality of today's developers.
oaiey 8y ago
I would not take pattern matching as the right example. I learned pattern matching at the university and always missed it in C#. It is easy and straightforward. When you love lambdas and linq, so C# 3.0, pattern matching is easy. However, when it comes to modern C# and memory management I also think that readability suffers a lot. Memory management on that level is well known to the professional C/C++ folks but most of us are just overloaded with it.

dgritsko 8y ago

> You can write C# in too many forms and I don't believe that's really good. Why not? And what, exactly, defines "too many"?

azhenley 8y ago
Perhaps he means something like Python's motto of "There should be one--and preferably only one--obvious way to do it." https://www.python.org/dev/peps/pep-0020/ https://www.python.org/dev/peps/pep-0020/
- goto11 8y ago
  I think all the new features are improvements, but I agree the language is getting big with many ways to do the same thing. I don't think MS will ever do a 'Python 3' and cut backwards compatibility.
kminehart 8y ago
I know people meme a lot about Go and "not having generics," but I really feel that a lot of the things left out of Go have benefitted it. I've never really been able to jump into a project without a lot of mental overhead. With Go, most code everywhere is written pretty idiomatically, making it easy to approach and read. I've heard similar things about C#, but my experience hasn't been as great. This is a big problem in the JavaScript world in my opinion. So many different ways to solve common problems that it's difficult to approach. OP might be worried this could be happening to C#.
- dgritsko 8y ago
  I suppose, but that seems like a natural consequence of C#'s desire to move the language "forward" in terms of implementing new features (such as switch expressions or non-nullable reference types) while also maintaining backwards compatibility (for example, you can still use the non-generic "ICollection" interface if you want to). Just a different set of priorities.
- BoiledCabbage 8y ago
  We could go with a language with just if statements, while statements, function calls and "return" and be extremely easy to jump into. :) While a bit snarky I do think it is one of the fundamental problems with programming language innovation. No matter how smart we are, learning is effortful. And we frequently judge languages not by how productive it is, but by how quickly we can start feeling productive in it. Which often preferences familiar concepts over more powerful concepts. There is a very long feedback loop in properly evaluating a language. At least 1-2 years. You need not just figure out how to do what you already know in the language, you need to learn the new way to think in the language. And that takes time and solving lots of problems. This is only sped up if the language's concepts are kept very similar to a language you already know. We are the bottleneck that slows down language improvement. There is no way anyone can convince me that the hodgepodge of Algol derived languages is one of the best ways out there of writing code. But most new languages will be similar because the hurdles of trying to teach people anything else alongside the actual new interesting concepts of your language are too much of a blocker for any reasonable adoption.
- flavio81 8y ago
  >I know people meme a lot about Go and "not having generics," but I really feel that a lot of the things left out of Go have benefitted it. Yes, that's why we program in Brainf__k here: It only has the bare essentials and it's so easy to learn.
nordsieck 8y ago
> Why not? And what, exactly, defines "too many"? I think Scala was innovating in this respect before Kotlin ate its lunch (it may still be). You could use Scala as everything between Java++ and Haskell--. Developers proficient in Java++ often had a difficult time understanding code written in Haskell--.

runT1ME 8y ago

I agree. It has the flexibility of Scala without the extra power/abstractions Scalaa gives you. I don't love Scala's flexibility but I put up with it because of its power, the trade off isn't worth it for C# to me.

kalekold 8y ago

I think I agree. I used to write a lot of C# v2 and loved it. There didn't seem to be anything 'missing'. Each version since then has added nice things but are they really necessary? Now the language looks huge and complicated and because of that, I'm not sure I'd ever want to use it again.

goto11 8y ago
C# 2 did not have Linq. Linq is the best feature ever.
- Invisig0th 8y ago
  Actually, adding LINQ to C# did not introduce any new functionality at all. Everything you can do in LINQ you could already accomplish in C# without LINQ. Yes, I suppose someone could say that the older code was uglier, but it already had the same capabilities as LINQ. That's been the case for the majority of supposed "new features" in C# for at least the past 8 years or so -- LINQ, inline variables, anonymous functions, string literals etc. It's all just syntactic sugar on top of existing features.
  - Dylan16807 8y ago
    That's the general nature of a turing complete language. The purpose of every feature is making things less ugly.
    - Invisig0th 8y ago
      I'd say it's more the general nature of Microsoft in this particular case. "There should be three different ways to do that" has been the case since Windows 3.1.
  - contravariant 8y ago
    LINQ is surprisingly powerful when you start overloading SelectMany, as that allows you to implement Monads nicely.
  - 8y ago

JustSomeNobody 8y ago

Language designers are not immune to the "code must change constantly otherwise it's abandonware" mentality of today's developers.

oaiey 8y ago

I would not take pattern matching as the right example. I learned pattern matching at the university and always missed it in C#. It is easy and straightforward. When you love lambdas and linq, so C# 3.0, pattern matching is easy. However, when it comes to modern C# and memory management I also think that readability suffers a lot. Memory management on that level is well known to the professional C/C++ folks but most of us are just overloaded with it.