Some of the features I'd like to see in C# are borrowed from Midori's programming language (which evolved from Sing#, which evolved from Spec#), F# functional programming language, and D programming language.
C# Code Contracts that were backported from Spec# are broken. Besides being dog slow, they don't compose polymorphically. That kind of facility needs to be in the core language, not a bolt-on terribly slow afterthought. Here C# could take a page out of D's playbook Unit testing should be part of the core language. I've used NUnit, and I've used xUnit.net, and there are others. The problem with them is that they all solve that problem space their own way, so there's lock-in for something that ought to be a core language construct. (As long as I have the magic of NCrunch, I'm only complaining about the lock-in. The test runners can do their own thing their own way with their own reporting models.) Another page out of D's playbook.
The key concept I've picked up on from Midori is bugs are not recoverable errors. That notion is not something that C# has learned.
The other neat thing in Midori is that calling a method that could throw an exception requires notation at the callsite: var y = try blah(); The required try there makes the "invisible goto" no longer invisible.
F# has too many awesome things to list. I wouldn't mind seeing more F#-isms in C#, with due consideration. But C# will never be F#. They serve different programming purposes, and are suitable programming language tools for different domains. And that's a good thing.
C# not having non-nullable references from the get-go was a mistake, and I'm happy to see that this trillion dollar mistake is being addressed. (Sir Tony Hoare's mistake in ALGOL W was merely a billion dollar mistake. C# is much more widespread.)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Some of the features I'd like to see in C# are borrowed from Midori's programming language (which evolved from Sing#, which evolved from Spec#), F# functional programming language, and D programming language.
C# Code Contracts that were backported from Spec# are broken. Besides being dog slow, they don't compose polymorphically. That kind of facility needs to be in the core language, not a bolt-on terribly slow afterthought. Here C# could take a page out of D's playbook
Unit testing should be part of the core language. I've used NUnit, and I've used xUnit.net, and there are others. The problem with them is that they all solve that problem space their own way, so there's lock-in for something that ought to be a core language construct. (As long as I have the magic of NCrunch, I'm only complaining about the lock-in. The test runners can do their own thing their own way with their own reporting models.) Another page out of D's playbook.
The key concept I've picked up on from Midori is bugs are not recoverable errors. That notion is not something that C# has learned.
The other neat thing in Midori is that calling a method that could throw an exception requires notation at the callsite:
var y = try blah();The required try there makes the "invisible goto" no longer invisible.F# has too many awesome things to list. I wouldn't mind seeing more F#-isms in C#, with due consideration. But C# will never be F#. They serve different programming purposes, and are suitable programming language tools for different domains. And that's a good thing.
C# not having non-nullable references from the get-go was a mistake, and I'm happy to see that this trillion dollar mistake is being addressed. (Sir Tony Hoare's mistake in ALGOL W was merely a billion dollar mistake. C# is much more widespread.)