Is it just me, or is C# basically becoming Scala (or, insert your favorite functional language here). Don't get me wrong, this is awesome, .net on Linux, dockerized, is all good, but these moves definitely show Microsoft responding to market changes in a way they didn't used to.
C# first introduced lambdas and LINQ in v3, back in 2007. It was the first mainstream OO language to really push a more functional/mixed-paradigm approach.
This is definitely an area where Microsoft has lead the market, not followed it.
The C# team are very lucky to have F# as a reference implementation on how to implement ML style features on the .NET platform. I'm certain many more features from F#/OCaml will be added in forthcoming releases.
The .NET CLR has advantages over the JVM, especially when comparing C# / F# -> Scala / Java. At a language level, the use of type erasure for generics (which is done at compile-time in Scala/Java) allows you to do things that the .NET CLR wouldn't allow you to do because Generics is part of IL. C# isn't becoming Scala but functional paradigms are coming through into languages as an evolution, rather than stagnating (this is great, in my opinion). These languages are a part of the .NET eco-system and are fantastic, I'm pleased with the path they're going down, albeit maybe they could improve certain syntax in C# 7.0 ;)
C# progress is strongly driven by Microsoft Research. Microsoft Research contains a lot of functional programming fans. I'm quite happy to watch MSR slowly convert the hoard of C# programmers from Java++ devs to Haskell|OCaml devs.
It was clear that ms won't stop adding features aftwr version 3 or 4.i guess c# will be the: does all, can do all and includes all patterns, functions, methods from all other languages you can think of.
There seems to be no control, no feature lock, no "our language will be like language x" or definition they follow. It seems more like they listen to the whole community of developers.
Every language falls victim to the functional paradigm over time, because functional language community is very vocal and promises riches if you use their paradigms. But when you do implement them, they turn out to be hard to use or not viable for big applications and people stick to their old languages anyway.
Throw expressions are particularly welcome. I'd previously dealt with that issue by creating a static method that returned the expected type, but just threw an exception [1][2]
I'm not sure it's explicit in the blog, but it seems the deconstructor will be useful for pattern-matching using 'is'.
Tuples. Yay! Finally!
Pattern-matching-switch-statement: Not an expression. That's a bad call. We have expression based ternary, throws, method bodies, and LINQ; switches are the last and most painful omission.
Local functions: Fantastic for libraries like mine, which is trying to bring functional programming to the C# world, but takes a hit with the allocation of delegates for common operations [3] It should be a boon for anything LINQ based (implementations, rather than usage).
Return by ref and out parameters: I'd be happy if they just removed them from the language. Ugly, error magnets.
All in all, good progress. Hopefully they can make more progress on facilitating expression-based programming, and bring in record types for the next release. The pain of creating immutable types is truly tedious. And I'd desperately like to see partial generic parameter specifying (for when one of the generic arguments can't be inferred by the type-system, so you then end up having to specify them all).
Fully agreed on pattern matching not being an expression. I really dislike that syntax overall. I get the reluctance to introduce new keywords (though this did introduce 'when', but I suppose it's contexual at least), but trying to shoehorn pattern matching into the, um, let's be nice and call it "venerable", old switch/case does not look very ergonomic at all.
And I don't know about you, but I rarely switch over polymorphic types these days, I mostly switch over values, so the pattern matching overall is way less useful to me without records/discriminated unions.
I guess you can't really remove 'ref' and 'out' due to interop. Maybe the ref returns stuff will be nice if we get more performant string/array views in the next version, and I do like the inline 'var out'.
I also want type inference for field declaration+initialization, but I think Eric Lippert once explained why that was a difficult problem to solve, albeit I can't remember the reason.
Of all the new features, ref return leaves me scratching my head. I agree ref and out should go away. Adding more support for ref will only increase its usage when it should be deprecated.
Awesome! Greatly reduces "ugly" boilerplate code like this:
if (control is TextBox)
{
var textBox = (TextBox)control;
textBox...
}
Also, it would be great if Microsoft could make full properties in another way so that you do not have to write a backing field for it. Something like this:
public string LastName
{
get;
set
{
if (value == "Batina")
RaisePropertyChanged();
}
}
I think if you're writing property accessors manually then there should be an explicit private backing field. Otherwise there is just too much magic going on.
Normal auto-implemented properties are fine:
public string LastName {get; set;}
As are read-only ones:
public string LastName {get; private set;}
Yet, I feel that if you are writing logic in there then you should fully control it. Or else there is too much being done that is non-obvious and could cause problems down the line (for others or your future self).
However, they might be able to achieve something with data annotations that wouldn't be too magic. For example:
[RaisePropertyChanged("Batina")]
public string LastName {get; set;}
Tip: In VS you can just type "prop" then press tab to auto-generate the code for a class property. You can then easily auto-change this to a fully implemented version. This also works for "for" and "foreach" loops etc.
I haven't done much Java in a while but do you still have to write out all of your property accessors fully? Might not be too bad if the IDE can generate this code.
So, lets say someone had never worked with C# or .net before and works on a mac - where would you go to get started building a small server application? I assume you would use the .net core stuff? and visual studio code? Any good tutorials for noob-to-the-ecosystem but someone that has programming experience?
It's nice. I went on to modify and hack with what I created to form it into a back end for a mobile app I'm playing around with. There are still some warts in the process (Namely just figuring out how everything fits together and which packages to import) but I've been pleasantly surprised.
It looks like the new Visual Studio for Mac (ie An updated Xamarin Studio) has an ASP.Net Core template. At least I thought I saw that on the live stream earlier today. Might want to check that out!
I'm very disappointed that ref returns were not implemented as syntactic sugar for out params.
A bit of history: game developers have been crying for a solution to the matrix operator problem. A 4x4 matrix is 64 bytes of data. Implement the mathematical operators using C# operators and you're looking at 192 bytes copied per invocation. The workaround is the fake ref operator: void Add(ref Matrix, ref Matrix, out Matrix). The problem is that this results in code smell at the call sites. The ref return was the first compromise, allowing that method to become: ref Matrix Add(...). The ultimate solution would be to allow ref returns and ref parameters on operators, but you need ref returns first.
This feature misses all of that. Maybe we'll get out returns, but the argument against it would be language bloat, and even I'd agree. Sigh.
It puts a smile on my beak that I am a budding (sort of) .Net and C# developer. Microsoft seems to be really jacked up and introducing some very forward thinking functionality into their ecosystem. Been playing with Azure Service Fabric. It is super impressive.
Yeah, Service Fabric is super awesome! I'm refactoring out company's infrastructure to run on it currently - the older stuff runs on MVC 5 on Azure Cloud Service.
I'm refactoring it to ASP.NET Core on Service Fabric. Getting about 50x better real-world performance. Yes, that much. It's insane. Currently on Windows as Service Fabric on Linux is in preview (not comfortable using it in production), but I imagine I'll move it over once that's stable ️
A great time to be a .NET developer! Makes me happy I stuck with it.
I'm interested to see what the production story is for some of these language features. I usually get left a festering minidump with a number of threads, a pile of stacks and some line numbers if I'm lucky these days. It's quite hard determining which dereference or call is the one that triggered the problem in a method body with so many things now compacted into a tight expression.
Granted there should be assertions to prevent these conditions occurring but not everyone on the team is perfect 100% of the time. Sometimes an edge case slides in as well and you have to heavily assert everything and push to test/production to reproduce which isn't ideal.
more improvements that allows more concise code and that looks functional in nature. Which is great, I have to do a lot in C# and really like it as a OO / with functional abilities type language.
But I keep wondering why F# doesn't really take off given a lot of peoples fascination with the functional world. It does functional nicely while still being able to bridge back to the OO world which allows you to easily leverage a LARGE amount of libraries in the .net world. It has a really good community, and F# specific frameworks for various things as well. It's like a hidden gem that people pass over as they look at functional languages with much much smaller ecosystems.
I only played with F#, but my day job is writing FP code in Scala, so let me answer this:
> I keep wondering why F# doesn't really take off given a lot of peoples fascination with the functional world
As a matter of fact there aren't that many people interested in FP, mostly due to a lack of education on the matter. Even many people talking about FP are confused about what FP is. And the problem with the FP ecosystem are the abstractions, which tend to be extremely high level and very productive, however these aren't taught in school and the cost of entry is high.
So let me throw this question right back at you: why F# and not Haskell? And note that the answer you give is going to be applicable to C# versus F# and at the same time flawed ;-)
And you see, raising the abstraction is one way humanity has always tackled complexity, however this is essentially about vertical scalability of talent - or in other words enabling the same people to handle more challenging problems by giving them better tools. But the trouble is that this is incompatible with horizontal scalability, which is about growing by hiring more and more people, i.e. building assembly lines.
So going back to your question, the reason for why not FP is actually simple, but hard to swallow: the software industry is growing due to huge demand, as a consequence a majority of people working in this field are beginners and when the industry has a choice between quality and quantity, it will go for quantity at the expense of quality.
On the other hand the good news is that with the proper education, mindset and tools, as a small team, you can still build products that compete with big companies having virtually unlimited resources.
Most of Microsoft technologies customers are orthodox enterprise companies. They're still using VB and SourceSafe and will not be attracted by ML-like language. So Microsoft is marketing F# cautiously.
But unlike Java world where J2EE suits and Scala/Clojure hipsters coexist (but hugely separated), .NET is in just beginning of transition from Windows-only Visual Studio-only. It's hard to convince people outside of old Windows Server .NET camp to even try these technologies. Recently I tried F#: build process is still painful, involving msbuild files designed for IDE first, build system second, based on XML, with reverse slashes and absolute paths, reminded me of mix between Windows Registry and Apache Ant. MSDN is painful and enterprisey, with 5-10 second page load times.
F# is quite nice (much cleaner and simplier than Scala for example) but still not feels really great. I can't figure out how to do basic polymorphism in it: someone recommended to use classes and interfaces but I don't want OOP at all. Standard library has few polymorphism too: Seq.map, List.map, Set.map. Records are great but type inference behaves strangely.
I'm a little disappointed that pattern matching doesn't simply narrow the variable, and instead requires a new variable name to hold the narrowed type. Even TypeScript narrows the variable in-place!
You may want to deconstruct the value and use the original base value. This seems entirely logical, and consistent with most implementations in functional languages (and I'd say makes TypeScript's implementation the poor one - although I haven't seen it myself to have an opinion on).
I believe this would cause a change in the CLR as opposed to just syntax sugar. It's less of an issue for typescript since all type information is erased at runtime.
major part of these new features are very cool but i'm afraid they could compromise future evolution of the Language.
some implementation details scares me, maybe i'll become used to them, i only hope that these doesn't result in a boomerang for future versions.
Deconstruction implementation is scary, i would prefer to have a special symbol (like the desctrutor) and duples that ignores names are ok but sounds very error prone, maybe i just have to try them to understand, also order sensitive case makes my dev sense tingle...
[+] [-] zilchers|9 years ago|reply
[+] [-] stupidcar|9 years ago|reply
This is definitely an area where Microsoft has lead the market, not followed it.
[+] [-] junkyarddog|9 years ago|reply
[+] [-] jordz|9 years ago|reply
[+] [-] corysama|9 years ago|reply
[+] [-] Bombthecat|9 years ago|reply
There seems to be no control, no feature lock, no "our language will be like language x" or definition they follow. It seems more like they listen to the whole community of developers.
All of them.
[+] [-] skocznymroczny|9 years ago|reply
[+] [-] Locke1689|9 years ago|reply
[+] [-] CurtHagenlocher|9 years ago|reply
[+] [-] louthy|9 years ago|reply
I'm not sure it's explicit in the blog, but it seems the deconstructor will be useful for pattern-matching using 'is'.
Tuples. Yay! Finally!
Pattern-matching-switch-statement: Not an expression. That's a bad call. We have expression based ternary, throws, method bodies, and LINQ; switches are the last and most painful omission.
Local functions: Fantastic for libraries like mine, which is trying to bring functional programming to the C# world, but takes a hit with the allocation of delegates for common operations [3] It should be a boon for anything LINQ based (implementations, rather than usage).
Return by ref and out parameters: I'd be happy if they just removed them from the language. Ugly, error magnets.
All in all, good progress. Hopefully they can make more progress on facilitating expression-based programming, and bring in record types for the next release. The pain of creating immutable types is truly tedious. And I'd desperately like to see partial generic parameter specifying (for when one of the generic arguments can't be inferred by the type-system, so you then end up having to specify them all).
[1] https://github.com/louthy/language-ext/blob/master/LanguageE...
[2] https://github.com/louthy/language-ext/blob/master/LanguageE...
[3] https://github.com/louthy/language-ext/blob/type-classes/Lan...
[+] [-] moogly|9 years ago|reply
And I don't know about you, but I rarely switch over polymorphic types these days, I mostly switch over values, so the pattern matching overall is way less useful to me without records/discriminated unions.
I guess you can't really remove 'ref' and 'out' due to interop. Maybe the ref returns stuff will be nice if we get more performant string/array views in the next version, and I do like the inline 'var out'.
I also want type inference for field declaration+initialization, but I think Eric Lippert once explained why that was a difficult problem to solve, albeit I can't remember the reason.
[+] [-] naasking|9 years ago|reply
I disagree. Firstly, more high-performance non-allocating code can now be written safely instead of dropping down into unsafe languages.
Secondly, ref and out parameters are address types, which the CLR and C# need to properly handle to support value types/structs.
[+] [-] snarfy|9 years ago|reply
[+] [-] batina|9 years ago|reply
Awesome! Greatly reduces "ugly" boilerplate code like this:
Also, it would be great if Microsoft could make full properties in another way so that you do not have to write a backing field for it. Something like this: It would make code more cleaner.[+] [-] jsingleton|9 years ago|reply
Normal auto-implemented properties are fine:
As are read-only ones: Yet, I feel that if you are writing logic in there then you should fully control it. Or else there is too much being done that is non-obvious and could cause problems down the line (for others or your future self).However, they might be able to achieve something with data annotations that wouldn't be too magic. For example:
Tip: In VS you can just type "prop" then press tab to auto-generate the code for a class property. You can then easily auto-change this to a fully implemented version. This also works for "for" and "foreach" loops etc.I haven't done much Java in a while but do you still have to write out all of your property accessors fully? Might not be too bad if the IDE can generate this code.
[+] [-] taspeotis|9 years ago|reply
[+] [-] netcraft|9 years ago|reply
[+] [-] merb|9 years ago|reply
It bundles everything you need. And for the tutorial you can check links from other people.
[+] [-] stdgy|9 years ago|reply
It's nice. I went on to modify and hack with what I created to form it into a back end for a mobile app I'm playing around with. There are still some warts in the process (Namely just figuring out how everything fits together and which packages to import) but I've been pleasantly surprised.
It looks like the new Visual Studio for Mac (ie An updated Xamarin Studio) has an ASP.Net Core template. At least I thought I saw that on the live stream earlier today. Might want to check that out!
[+] [-] annerajb|9 years ago|reply
[+] [-] ldev|9 years ago|reply
[+] [-] te_platt|9 years ago|reply
[+] [-] JamesBarney|9 years ago|reply
The lack of coloration and gray background gave me a little bit of a headache.
[+] [-] zamalek|9 years ago|reply
A bit of history: game developers have been crying for a solution to the matrix operator problem. A 4x4 matrix is 64 bytes of data. Implement the mathematical operators using C# operators and you're looking at 192 bytes copied per invocation. The workaround is the fake ref operator: void Add(ref Matrix, ref Matrix, out Matrix). The problem is that this results in code smell at the call sites. The ref return was the first compromise, allowing that method to become: ref Matrix Add(...). The ultimate solution would be to allow ref returns and ref parameters on operators, but you need ref returns first.
This feature misses all of that. Maybe we'll get out returns, but the argument against it would be language bloat, and even I'd agree. Sigh.
/rant
[+] [-] kukx|9 years ago|reply
Also, could you elaborate what you mean by out returns? Normal returns could be considered "out returns", no?
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] Locke1689|9 years ago|reply
[+] [-] markatkinson|9 years ago|reply
[+] [-] xorxornop|9 years ago|reply
I'm refactoring it to ASP.NET Core on Service Fabric. Getting about 50x better real-world performance. Yes, that much. It's insane. Currently on Windows as Service Fabric on Linux is in preview (not comfortable using it in production), but I imagine I'll move it over once that's stable ️
A great time to be a .NET developer! Makes me happy I stuck with it.
[+] [-] setq|9 years ago|reply
Granted there should be assertions to prevent these conditions occurring but not everyone on the team is perfect 100% of the time. Sometimes an edge case slides in as well and you have to heavily assert everything and push to test/production to reproduce which isn't ideal.
[+] [-] alexro|9 years ago|reply
[+] [-] mattmanser|9 years ago|reply
Nice blog post, shame about the bloody awful presentation.
[+] [-] jdmichal|9 years ago|reply
[+] [-] redwards510|9 years ago|reply
[+] [-] keithnz|9 years ago|reply
But I keep wondering why F# doesn't really take off given a lot of peoples fascination with the functional world. It does functional nicely while still being able to bridge back to the OO world which allows you to easily leverage a LARGE amount of libraries in the .net world. It has a really good community, and F# specific frameworks for various things as well. It's like a hidden gem that people pass over as they look at functional languages with much much smaller ecosystems.
[+] [-] bad_user|9 years ago|reply
> I keep wondering why F# doesn't really take off given a lot of peoples fascination with the functional world
As a matter of fact there aren't that many people interested in FP, mostly due to a lack of education on the matter. Even many people talking about FP are confused about what FP is. And the problem with the FP ecosystem are the abstractions, which tend to be extremely high level and very productive, however these aren't taught in school and the cost of entry is high.
So let me throw this question right back at you: why F# and not Haskell? And note that the answer you give is going to be applicable to C# versus F# and at the same time flawed ;-)
And you see, raising the abstraction is one way humanity has always tackled complexity, however this is essentially about vertical scalability of talent - or in other words enabling the same people to handle more challenging problems by giving them better tools. But the trouble is that this is incompatible with horizontal scalability, which is about growing by hiring more and more people, i.e. building assembly lines.
So going back to your question, the reason for why not FP is actually simple, but hard to swallow: the software industry is growing due to huge demand, as a consequence a majority of people working in this field are beginners and when the industry has a choice between quality and quantity, it will go for quantity at the expense of quality.
On the other hand the good news is that with the proper education, mindset and tools, as a small team, you can still build products that compete with big companies having virtually unlimited resources.
[+] [-] ungzd|9 years ago|reply
But unlike Java world where J2EE suits and Scala/Clojure hipsters coexist (but hugely separated), .NET is in just beginning of transition from Windows-only Visual Studio-only. It's hard to convince people outside of old Windows Server .NET camp to even try these technologies. Recently I tried F#: build process is still painful, involving msbuild files designed for IDE first, build system second, based on XML, with reverse slashes and absolute paths, reminded me of mix between Windows Registry and Apache Ant. MSDN is painful and enterprisey, with 5-10 second page load times.
F# is quite nice (much cleaner and simplier than Scala for example) but still not feels really great. I can't figure out how to do basic polymorphism in it: someone recommended to use classes and interfaces but I don't want OOP at all. Standard library has few polymorphism too: Seq.map, List.map, Set.map. Records are great but type inference behaves strangely.
[+] [-] jdmichal|9 years ago|reply
[+] [-] louthy|9 years ago|reply
[+] [-] dested|9 years ago|reply
[+] [-] seanmcdirmid|9 years ago|reply
[+] [-] muterad_murilax|9 years ago|reply
[+] [-] duke360|9 years ago|reply
Deconstruction implementation is scary, i would prefer to have a special symbol (like the desctrutor) and duples that ignores names are ok but sounds very error prone, maybe i just have to try them to understand, also order sensitive case makes my dev sense tingle...
[+] [-] gigatexal|9 years ago|reply
[+] [-] bobcostas55|9 years ago|reply
[+] [-] junkyarddog|9 years ago|reply
[+] [-] ryenus|9 years ago|reply
[+] [-] stuartd|9 years ago|reply
[+] [-] shaydoc|9 years ago|reply
[+] [-] dpen2016|9 years ago|reply
[deleted]