Does anyone else just feel underwhelmed by the pattern matching? It seems like syntactic sugar over a standard if(x is Type) that doesn't bring a whole lot to the table other than being able to write more error prone code.
My understanding was this was the first pass with adding patterns to the language with later versions potentially extending the types of patterns and / or where patterns can be used in the language.
Yeah, I was expecting something like what you get in F#.
But maybe it is just the nature of the [C#] language. Still, I think this looks more readable than if-statements.
EDIT: Maybe it is just a bad example of pattern matching, the one they put on that page. I'm betting pattern matching works on the added tuple type. That would be pretty handy.
I'm so stoked for F#. I feel it is SO close. As the user experience with dotnet core smooths out(and ionide no longer needs mono) I suspect it will gain a ton of traction.
F# could have caught on if MS had pushed it as a first class citizen. Instead of pitching it as aimed at really smart people that just need more than C#, they should have sold it as "everything C# can do but better", which is practically true.
Some big-name ivy league around the early-to-mid 2000s notoriously ditched Haskell for Java and that caused quite a stir (isn't that why "Why FP Matters" was written, or re-written?).. so rather they'd have to "get back" to teaching FP.
That alone though may also not suffice though, all that gets the ecosystem is super-generalized hyper-abstract "libraries written by and for PhDs".. not that I'm anti-intellectual I don't think, but if we're talking about "taking off".. programming always took off with "the tinkerers" first and foremost. (Sure, some went on to get hooked on Category Theory but certainly not most!)
I guess FP needs the kind of "OOP summer" hype we got in the mid-90s to mid-2000s. And I kinda feel that's in full swing just not coming into full view just yet.
I have worked with for a while but it seemed very difficult to introduce it to a larger team that doesn't see the point in FP. If there was sample code that clearly showed advantages of F# while using the .Net framework things would be easier. But there is nothing available. C# is the number one language in the .NET world.
C# definitely will remain the number 1, and FP will remain used in a minority of places, until more people get exposed to it earlier in their cursus.
The advantages are in the idioms, immutability by default, null not being legit value by default, emphasis on correctness, advanced type system etc.
The issue is often that people doing C# won't gain enough FP practice to see where F# brings most advantages, try to use it as a OO language for really short time and ditch it because tooling and concepts are not the same as what they are used to.
I'm confident though that adoption is rising and that few years from now most .net shops will get exposure to some amount of F# code, and that people who have been doing C# for so long will eventually pick up any functional language, which in turn will make F# really appealing to them.
I'm happy C# is supporting constructs such as local functions and some basic pattern matching (although type tests are probably the worst use case of pattern matching as seen in ML languages), but I'm also concerned the language is evolving toward more and more complicated syntax and rules (see all the kinds of scoping rules for variables and switch statement) and so little things geared toward correctness (readonly locals, non nil references?).
C# focuses on alleviating developer pain, but sometimes making the choice of enabling to do the wrong thing more readily.
The only way I see FP becoming more popular would be if some popular libraries came up that were purely functional and showed the strength of that approach. I think I understand the benefits of FP but it struggle to see how it would fit into the current library ecosystem. There are not many people who have the luxury of building a codebase from scratch. Most of us need to use other libraries.
> The switch stuff? Without edhaustiveness checking and with inheritance, it's a waste of time.
While this isn't possible in the general case, it might be possible to write a rule in FxCop (or other static analysis tool) to do this kind of checking for e.g. private or internal base types, or to at least check for all the derived types of the current assembly (or solution assemblies.) It also looks slightly less ugly than else if chains, which seems to be a driving factor behind a lot of C#'s newer syntactic sugar.
It actually feels more like taking an antipattern (switching like in their example produces terrible code in the long run) and turning it into a language feature.
It doesn't necessarily lead to terrible code in the long run. It depends on which abstraction axis changes more frequently in your code.
Are you familiar with the expression problem? [1] It's a problem that comes up a lot when you have a bunch of algorithms and a bunch of related values in a data structure, and you want to apply the algorithms to the values. If you have a fixed number of algorithms but keep adding new types of values, it makes sense to use virtual methods for the algorithms; if you have a fixed number of types of values, but keep adding new algorithms, it makes sense to use switch statements (ideally with completeness checking), or pattern matching (if available).
The second case is where the C# feature is useful, and it does not produce terrible code in the long run.
I can't say I agree in any way. There's no instance where a switch statement is preferable to a hash table or pattern matching.
If you have a switch with 3 or fewer cases, use if/else. If you have a switch with more cases, a hash table is going to wind up with far less code, and set you up for polymorphism later if you decide you need to go that route.
In the context of the article (C# patterns), I'm talking about switch statements specifically as a kind of pattern matching.
I disagree that hash tables will end up with less code; the dispatch mechanism for a hash table will be significantly longer than a switch, and the compiler can create a hash table for dispatch (using e.g. a perfect hash function). A switch statement will both be faster and easier to understand and read than storing lambdas in a hash table.
For pure readability, languages with good support for hash literals and lambdas may have the edge, but they'll also encourage dynamism that will hurt both simplicity and performance.
How do you create a hash table where the value is an action that depends on the type of the value? The best you can do is something like Dictionary<Type, Action<object>> and use casting in the action, but that's much worse than C# 7.0 switch.
The real benefit of pattern matching is when the compiler helps you handles the different cases and warns you about one's you've missed—which isn't provided by C# 7.0's version.
