5 ms·

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

by rjbwork 10y ago

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.

snowcrshd 10y ago
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.
- rjbwork 10y ago
  Didn't want to do this out of the gates, but now that I've started a discussion, and folks seem to agree, check out this library I'm working on. https://github.com/Jagged/OneOf https://github.com/Jagged/OneOf I've got some more performance improvements and code cleanup in my stash RN I've not quite finished up yet.
  - rjbwork 10y ago
    Forgot to say earlier - Currently being distributed @ https://www.nuget.org/packages/DiscU https://www.nuget.org/packages/DiscU
- platz 10y ago
  you're right; it's not (my other comment on this page: https://news.ycombinator.com/item?id=13835765 https://news.ycombinator.com/item?id=13835765)
nunez 10y ago
Yeah; it's nothing like F#, unfortunately. It's kind of unreadable as-is, actually.
- KallDrexx 10y ago
  I think it looks good for switch usage at least.
- Rapzid 10y ago
  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.
  - maxxxxx 10y ago
    I don't know. F# has been the next great thing for a long time but it never really happened.
    - deleted 10y ago
      [deleted]
    - tmccrmck 10y ago
      That's kind of the story with every functional language (Haskell, Clojure, OCaml). I don't think they'll truly catch on until universities start teaching FP.
      - dualogy 10y ago
        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.
      - 10y ago
nigelsampson 10y ago
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.
debacle 10y ago
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.
- barrkel 10y ago
  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. [1] https://en.wikipedia.org/wiki/Expression_problem https://en.wikipedia.org/wiki/Expression_problem
  - debacle 10y ago
    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.
    - svick 10y ago
      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.
    - barrkel 10y ago
      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.
moomin 10y ago
The (x is int i) stuff looks like an improvement. The switch stuff? Without edhaustiveness checking and with inheritance, it's a waste of time.
- MaulingMonkey 10y ago
  > 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.
specialist 10y ago
Pattern matching is nice syntactic sugar for tablesque conditionals. Table driven decisions without the table. As in truth tables, where the conditions are encoded in cascading if / then if / ... blocks vs captured in a precomputed 2D array. I forget what we call that style of programming. It's mentioned in Code Complete. Though it's not a common idiom.
- platz 10y ago
  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.

by rjbwork 10y ago

snowcrshd 10y ago

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.

rjbwork 10y ago
Didn't want to do this out of the gates, but now that I've started a discussion, and folks seem to agree, check out this library I'm working on. https://github.com/Jagged/OneOf https://github.com/Jagged/OneOf I've got some more performance improvements and code cleanup in my stash RN I've not quite finished up yet.
- rjbwork 10y ago
  Forgot to say earlier - Currently being distributed @ https://www.nuget.org/packages/DiscU https://www.nuget.org/packages/DiscU
platz 10y ago
you're right; it's not (my other comment on this page: https://news.ycombinator.com/item?id=13835765 https://news.ycombinator.com/item?id=13835765)

nunez 10y ago

Yeah; it's nothing like F#, unfortunately. It's kind of unreadable as-is, actually.

KallDrexx 10y ago
I think it looks good for switch usage at least.
Rapzid 10y ago
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.
- maxxxxx 10y ago
  I don't know. F# has been the next great thing for a long time but it never really happened.
  - deleted 10y ago
    [deleted]
  - tmccrmck 10y ago
    That's kind of the story with every functional language (Haskell, Clojure, OCaml). I don't think they'll truly catch on until universities start teaching FP.
    - dualogy 10y ago
      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.
    - 10y ago

nigelsampson 10y ago

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.

debacle 10y ago

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.

barrkel 10y ago
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. [1] https://en.wikipedia.org/wiki/Expression_problem https://en.wikipedia.org/wiki/Expression_problem
- debacle 10y ago
  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.
  - svick 10y ago
    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.
  - barrkel 10y ago
    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.

moomin 10y ago

The (x is int i) stuff looks like an improvement. The switch stuff? Without edhaustiveness checking and with inheritance, it's a waste of time.

MaulingMonkey 10y ago
> 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.

specialist 10y ago

Pattern matching is nice syntactic sugar for tablesque conditionals. Table driven decisions without the table. As in truth tables, where the conditions are encoded in cascading if / then if / ... blocks vs captured in a precomputed 2D array. I forget what we call that style of programming. It's mentioned in Code Complete. Though it's not a common idiom.

platz 10y ago
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.