4 ms·
> 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"?
by 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 agoPerhaps 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 agoI 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 agoI 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 agoI 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 agoWe 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--.