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.
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.
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.
I don't think they'll truly catch on until universities start 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.
That was true in Portuguese universities in the early 90's and it is still true nowadays.
Back then we had introduction to Lisp, Caml Light, SML and Prolog (LP).
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.
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.
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.
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.
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.
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.