You sound like an US patent clerk in the 1901's ;) Look at Rx for example, it isn't needed in as many applications but when it is its as revolutionary as LINQ was.
I think reducing friction and increasing productivity is really important, it's not as sexy as some of these other features but it makes real difference in big projects.
I'm getting a little worried about the async-await and task methodology. It's true that they've made a lot of that kind of programming much much easier, but it also means that orchestration is cluttering our code. It seems that now that we've elevated the level of abstraction it should be possible to get rid of it (more or less) by being more declarative in our intent and structures. We're programming on at least one layer below what we should.
Unfortunately I think that might require so large fundamental changes that you need a new language. Many might say, what about F#? While F# is great for certain more algorithm oriented solutions for me it never seemed to quite fit the paradigm of certain applications and enterprise systems.
I think in the end there's a skeleton of a next generation language embedded in what c# has become. If we removed some of the crud and used LINQ style syntax as template perhaps we could take parallelism, asynchronicity and productivity to the next level
PL's are a part product of all of history of computing, but a bigger part is a product of the programming Zeitgeist. It's better to be a young language than to have matured 15-20 years already. Certain syntactic or other choices bite you inthe ass in a new zeitgeist. When I saw Java's implementations of lambda stuff, I cringed a bit. Java's friction in generics, due to choices made about typing, also made me say, "Ouch."
I like to think I've matured out of the language and platform warrior mode enough to yield more objective consideration beyond my most-used and favorites (and are they favorites because they are most used or because they are so good?).
F# has given C# a nice boost in the juicer, but certain earlier choices are ossified and make later adaptations more challenging or, potentially, near impossible to do, do well/right.
I like that C# is going across OS's, but were also entering the Age of Containers and there are implications, opportunities, and challenges we have barely started considering.
I don't know what the future holds, but I know there will be curly braces and that tabs will win the day again... ducks
I think reducing friction and increasing productivity is really important, it's not as sexy as some of these other features but it makes real difference in big projects.
I'm getting a little worried about the async-await and task methodology. It's true that they've made a lot of that kind of programming much much easier, but it also means that orchestration is cluttering our code. It seems that now that we've elevated the level of abstraction it should be possible to get rid of it (more or less) by being more declarative in our intent and structures. We're programming on at least one layer below what we should.
Unfortunately I think that might require so large fundamental changes that you need a new language. Many might say, what about F#? While F# is great for certain more algorithm oriented solutions for me it never seemed to quite fit the paradigm of certain applications and enterprise systems.
I think in the end there's a skeleton of a next generation language embedded in what c# has become. If we removed some of the crud and used LINQ style syntax as template perhaps we could take parallelism, asynchronicity and productivity to the next level