51–60 of 82 posts
Earlier quoted context omitted.
I believe c# has had tuple support since .net framework v4.
I believe tuple support in v4 is a simple set of classes. There is no language construct specific for the use of tuples, which means it's just a library instead of a programming language feature.
Earlier quoted context omitted.
I believe tuple support in v4 is a simple set of classes. There is no language construct specific for the use of tuples, which means it's just a library instead of a programming language feature.
What are the advantages that language-level tuples would have over the existing System.Tuple class?
The real power of Tuples only comes with deconstruction and matching, such as "var (a,b) = GetSomething()" and "case (_, y)".
So these features would go hand in hand. Deconstruction and matching requires lang level tuples, and lang level tuples are pretty lame without deconstruction and pattern matching.
Earlier quoted context omitted.
I believe tuple support in v4 is a simple set of classes. There is no language construct specific for the use of tuples, which means it's just a library instead of a programming language feature.
What are the advantages that language-level tuples would have over the existing System.Tuple class?
Good start, finally adding records, patterns, tuples, non null, would be a good first step to making C# not feel so heavyweight compared to F#. If the F# team ever gets enough resources to complete with C#'s VS features, perhaps we'd get some serious adoption. As is, F# comes across second class both in tooling and MS marketing - that's not really competing fairly ;) But without making things expressions, it's still…
Just yesterday there was this article illustrating how C# fundamentally can't catch-up with F# on some important characteristics: http://fsharpforfunandprofit.com/posts/is-your-language-unre...
Then use C. In OOP comparing objects of different types is key to inheritance. The reason their example works is because everything in C# inherits from object, so you'll always find some commonality to compare.
You could have the compiler generate a warning when object.equals is used (rather than overridden) but getting rid of comparisons between different object types completely is backwards and will reduce efficiency.
Earlier quoted context omitted.
This is something that does rub my the wrong way a bit as well. F# is a fantastic language, easily my favorite non-Lisp FP language, and possibly period, but it was very clearly second-class in the field of actually building full apps with it. MS just flat does not seem to believe that anyone would want to build full apps with F#, so support for doing so is a bit of a wild frontier. Hopefully with F# in open source h…
It's a self fulfilling prophecy. F# is weak at designing full stack apps because it lacks tooling because it is weak at designing full stack apps. Even now, doing MVC websites is far more difficult out of the box if I code F#. MS still lacks JS backends, so we need third party compilers for that model... Maybe because they don't want to upset or look less than 1000% behind typescript. I will say though otherwise I'm…
This is just something that takes time and commitment from the community. It's only ~7 years old at this point, and if everyone just sits back and whines about the lack of tooling without, y'know, building & releasing something themselves, it'll be an ongoing problem. It's the "take take take" mentality - often disguised as being an open source advocate - of most software devs where they want everything for free (guilty as charged, myself).
That said, WebSharper is out there, which is a pretty solid framework for a lot of tasks. I've been thinking about ways to creatively encourage/solve the tooling problem though, starting with exhorting all of us in the F# community to reduce the whining and redirect the energy into creating solutions. Tooling is only a self-fulfilling prophecy if we continue to act as-if the outcome is out of our hands.
Earlier quoted context omitted.
It's a self fulfilling prophecy. F# is weak at designing full stack apps because it lacks tooling because it is weak at designing full stack apps. Even now, doing MVC websites is far more difficult out of the box if I code F#. MS still lacks JS backends, so we need third party compilers for that model... Maybe because they don't want to upset or look less than 1000% behind typescript. I will say though otherwise I'm…
F# is weak at designing full stack apps because it lacks tooling because it is weak at designing full stack apps. This is just something that takes time and commitment from the community. It's only ~7 years old at this point, and if everyone just sits back and whines about the lack of tooling without, y'know, building & releasing something themselves, it'll be an ongoing problem. It's the "take take take" mentality -…
I think it's too late for non null ref types. But pattern matching, traits and built in code contract would be awesome !
From http://blogs.msdn.com/b/csharpfaq/archive/2014/11/20/new-fea...
"Await in catch and finally blocks has been disallowed until now. We’d somehow convinced ourselves that it wasn’t possible to implement, but now we’ve figured it out, so apparently it wasn’t impossible after all."
I'm hoping this is one of those 'Clark's first law' situations: http://en.wikipedia.org/wiki/Clarke's_three_laws
'When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.'
They've got quite a lot of smart folks working on C#, and it's heartening to me to see them taking another look at non-nullable reference types.
Good start, finally adding records, patterns, tuples, non null, would be a good first step to making C# not feel so heavyweight compared to F#. If the F# team ever gets enough resources to complete with C#'s VS features, perhaps we'd get some serious adoption. As is, F# comes across second class both in tooling and MS marketing - that's not really competing fairly ;) But without making things expressions, it's still…
doesn't C# already have structs ? how are records different from that?
So while I can write
var x = { FirstName = "Riff", LastName = "Raff" }
void Display({ string FirstName, string LastName } nameRecord)
{
}
I've been trying to think of something that drastically change how I coded. Bugs and productivity really are the two major dragons to slay. I'm just spitballing here but something I'd really like to see stuff like code contracts and unit testing, but more integrated with the language, less verbose and requiring less to setup. Being able to let the "meat" of a method be separated from all the error-checking, post, pre…
If you instruct the compiler to treat all warnings as errors (so that variables must be defintitely assigned), then the following code gives you what you want:
public PositiveInt SomeMethod(GreaterThanFive a, NonNegative b)
{
//do stuff;
}
public struct GreaterThanFive
{
readonly int n;
public GreaterThanFive (int n)
{
if(n Good start, finally adding records, patterns, tuples, non null, would be a good first step to making C# not feel so heavyweight compared to F#. If the F# team ever gets enough resources to complete with C#'s VS features, perhaps we'd get some serious adoption. As is, F# comes across second class both in tooling and MS marketing - that's not really competing fairly ;) But without making things expressions, it's still…
Just yesterday there was this article illustrating how C# fundamentally can't catch-up with F# on some important characteristics: http://fsharpforfunandprofit.com/posts/is-your-language-unre...
It's possible to write shitty code in every programming language. Of course, the specific methods of doing so differ, but I've yet to see a Turing-complete language that makes it impossible to write buggy code.