Intro To Pattern Matching – Covers C# 9

https://www.c-sharpcorner.com/article/intro-to-pattern-matching-covers-c-sharp-9/

by alugili • 6 years ago

60 62 6 years ago

c-sharpcorner.com

fiveminds4• 6 years ago

what about Active pattern? will come to C# or not?

melling• 6 years ago

We’re all slowing moving to functional programming.

One day we wake up and decide we basically know Haskell, OCaml, etc and take off the training wheels?

fiveminds4• 6 years ago

yes did you see the uncle bob video about programming future? before 11 years. --> it happing today

goto112• 6 years ago

Well F# is based on OCaml, and it have been recognized for some time that C# is adopting more and more features from F#. As the article alludes to, this is not without controversy. Some feel that C# is becoming too bloated, and if you want to program in a functional style, you could just use F# in the first place. C# is much more widespread though, so this makes functional idioms more broadly available.

On the other hand, C# have also gotten deeper support for pass-by-reference and stack allocation which I consider more low level features. So I don't think the development is purely in functional direction.

fiveminds4• 6 years ago

me to you can solve the same problem in 100 ways and each way can have its own tips and ticks and pors and cons! C# will be complex like c++ not for new developers only for experts!

thrower1232• 6 years ago

Every C# release, F# starts looking less and less compelling. There's already a level of friction, since so much of the underlying framework is C#-centric and littered with exceptions and nulls, and if you want to expose F# code to be consumed by C#, you have to dumb things down. And the tooling for F# is considerably less advanced than you get with ReSharper or even out-of-the-box in Visual Studio.

It's a bit of a shame; I suppose that is one of the reasons that some people in the F# community are really pivoting over to WASM and Fable for using F# in the browser.

SuddsMcDuff• 6 years ago

C# can only go so far down the road towards F# without introducing currying and partial application. I can't see those ever being introduced into C#.

jaked894• 6 years ago

The ability to change value by ref is crucial to most real-world apps. This is not surprising, as those apps are modeled to represent a real, dynamic world.

Functional languages tend to disregard this, and demand composition over mutation. While this works for some domains, it's a burdensome complication for others.

Imperative languages are here to stay.

moomin2• 6 years ago

This is rather heavily debunked already. You might want to investigate that.

willtim3• 6 years ago

All the more reason to explicitly model time and not conflate it with the system runtime. As an example, banks have always added entries to a ledger such that the time history of events is explicit and preserved. Functional programming models this very well. An imperative programmer would probably write the final balance on a post-it note in pencil so that it could be destructively updated. Some OOP programmers have actually tried to model banking like this, because their language encourages it.

Another example might be a text editor buffer. Immutable persistent data structures allow one to get many features for free such as versioning, undo, lockless autosave. Memory is cheap now, there's less of a need to throw away some my edits with destructive updates. Even filesystems and databases have realised this is good idea. Destructive updates are bad for valuable data.

Imperative programming is only better for writing low-level system code, which is full of state that ultimately no one in the real world cares about.

mumblemumble3• 6 years ago

I don't think so. Pattern matching and the like are just window dressing. The two true distinguishing features of Haskell are that it's lazy, and the compiler enforces referential transparency. Neither of those is something you can get by simply adding features to an existing language.

And, if you aren't working within those strictures, you're still just not even in the same universe. No matter how many variables you make immutable, you'll still be able to log events by just executing a log statement, and you'll still be able to create a function that talks to a remote service, and call it from anywhere. So, you might use a few functional-inspired features when they're convenient, but the actual structure of your program is probably still imperative to the core.

cultus• 6 years ago

Haskell still doesn't have real referential transparency. It's all a matter of degrees and no language is pure, even Agda or Coq. The concept of IO as a world state you pass around is deeply flawed, especially with multiple cores. You cannot be in control of the world, so you don't really have equational reasoning. At any rate, there can be unsafePerformIOs lurking anywhere.

I really think delimited-continuation based algebraic effects are the way to go.

damnyou• 6 years ago

It turns out that that "window dressing" is by far the most practically useful part of functional languages.

sweeneyrod• 6 years ago

By this standard OCaml and Lisp aren't functional either.

alkonaut• 6 years ago

I think the gravity is towards a middle ground that looks like imperative, but is quite functional compared to C, Java, C++ or early C#.

Sum types, powerful type inference and and immutable-as-default.

Kotlin, Rust, Typescript are all recent-ish languages an all fit into this category. Meanwhile F# approaches it from the other direction (start with OCaml and sprinkle on some imperative and OO).

tartoran• 6 years ago

One of the advantages of F# is the simplicity and ‘graspability’ it yields but I have nothing against C# adopting more functional features. I just think this will confuse beginners quite a bit so the ladder is getting sparser rungs in a way. Maybe it is a good think maybe it’s not, only time will tell

mysonytv3• 6 years ago

exactly this is the problem.I think small language with limited features is better of one language which can do everything and it need a lot of expertise. Simple is beautiful. If the developers need FP than why not F# integrated in C#?

dmitriid2• 6 years ago

Too bad pattern matching implementations in C# (possibly in JS [1] and other languages [2]) don't go beyond basically matching in switches and maybe perhaps somwewhat inside function bodies.

One of the greatest powers of pattern matching comes from being abole to match in function definitions. The simplest example:

  fac(0) -> 1;
  fac(N) when N > 0 -> N*fac(N-1).

This makes a lot of code much more readable and more concise.

[1] https://github.com/tc39/proposal-pattern-matching

[2] http://cr.openjdk.java.net/~briangoetz/amber/pattern-match.h...

dotnet2222• 6 years ago

I think the most of us are agree that PM will make the code more readable and clean bla bla bla, but the problem in the C# language. Do you know how many ways that you can check the null in C#? (object == null) try to collect them and tell me which one is good. I think the problem here is C# blowing-up

platz5• 6 years ago

C#'s pattern matching does not include the ability to check for exhaustiveness, which is need to make pattern matching comparable in utility and power to inheritance (i.e. so you can actually replace inheritance w/ pattern matching.)

Much like how the compiler assists you when writing subclasseses so that you've implemented all the required methods, real Pattern Matching (F#) gives you the same guarantees from the compiler that you've handled all the possible cases appropriately.

Exhaustiveness checking is what elevates pattern matching to the other side of the expression problem, which is about getting feedback from the compiler to help you write programs.

a glorified switch statement does not help you do that, and so you still have to write subclasses to get compiler feedback.

mjburgess3• 6 years ago

Do you know why they dont do exhaustiveness checking?

They don't in scala either and I had assumed that was to do with type erasure. Given F# does however, presumably there is no limitation to C# doing it?

seemslegit3• 6 years ago

Nor should it, assuming a fixed set of derived classes is a bad OOP/SOLID practice as it breaks the "objects should be opened to extension" principle and prior to introduction of RTTI in C++ it wasn't even a design possibility - you either specified the concrete type or relied on abstraction and polymorphism.

dmitriid2• 6 years ago

Erlang doesn't check for exhaustiveness either, and pattern matching is awesome :)

Without exhaustiveness it might not be feasible for a statically types PL though, but I don't know nearly enough to even speculate on that.

moron4hire3• 6 years ago

I'm just going to leave this here, for all the "X > Y" talk, inserting either OO and FP into X and Y in whatever order you want: https://en.wikipedia.org/wiki/Expression_problem

Twisol2• 6 years ago

Several languages on either side of the OOP vs. FP divide include both solutions to the problem -- for example, open subtyping vs. sealed case classes in Scala, and traits vs. sum types in Rust. There's more to both OOP and FP than the expression problem.

moron4hire3• 6 years ago

That's my point. There are people who claim "my-current-shiny is the only way". Yes, OOP and FP languages have different solutions to the problem, because it's a real problem. You need to have both OO and Functional features in your language. "OOP vs FP" is a false dichotomy.

tasogare• 6 years ago

I would love if the not operator is usable instead of ! in other places than pattern matching. It's something I've wanted for a long time.

LandR2• 6 years ago

Do you mean the word 'not'?

moron4hire3• 6 years ago

I don't agree that growing a language necessarily makes it harder to learn. Quite the opposite, I think it makes it easier to learn.

Look at how asynchronous code was handled in C# in the past versus today. In the past, you first had to define a delegate type for the signature of the procedure you wanted to run. Then you'd assign something to that delegate, probably a method sitting in a class somewhere. You can now call BeginInvoke on that reference, passing in a callback function. That callback function has to be another method sitting in a class somewhere. You also get this IAsyncResult object returned, with no immediate guidance as to what it's supposed to do. Is it different than the IAsyncResult that gets passed to the callback? No? There's this "AsyncState" object you're supposed to pass, with no clue what it's meant for. If you don't need it, you pass null, which is pretty much every case. Need to return a value? Call EndInvoke with the IAsyncResult object you received in the callback. But wait, where's my delegate instance on which I need to call EndInvoke? Guess I need to hoist it to be a field in my class now. I suppose you could pass it as that AsyncState parameter, but now you're having to do in your head the type-checking job that the compiler should be doing for you.

None of this is guessable from just reading the code. You have to read the documentation in multiple places to figure out what is going on. For added fun, now try composing multiple async operations in sequence.

Contrast to today, we do "Task.Run(<some lambda expression>)". You tell me what is easier to learn?

You see "fewer keywords, fewer features" and see "simplicity". I see those things and I see "more boilerplate for implementing code" > "complexity".

thrower1232• 6 years ago

Yes, I am very happy that I never have to deal with IAsyncResult and BeginOperation()/EndOperation() method pairs, with callbacks and waithandles to make sure things happen in the correct sequence, ever again.

It was just horrible.

mysonytv3• 6 years ago

if the old stuff will be considered as "deprecated" then it is ok. I love c# and I hope this language will not blowing up like c++. Thank you for the tip!

brainzap• 6 years ago

oh my god people still do class Car examples. So hard to use a real world example with all this open source code...

moksly• 6 years ago

They do. I have a side job as an external examiner for CS students and the first years are still taught the same Car/Animal examples when learning about polymorphism that I was decades ago.

I’ve never once used that knowledge professionally to any sort of success. The complexity of polymorphism always ended up biting us (any company/org I’ve worked at) in the ass when things eventually grew way too far apart than what was originally envisioned when the polymorphism made sense.

Kinda hilarious that they are still teaching it with those useless examples though. You’d have thought they could come up with something better by now. I mean, I get why you’d chose something obvious, but in my experience CS students seem to understand polymorphism perfectly well without making a duck quack and a dog go woof.

But what do I know, I can’t even make it work.

mjburgess3• 6 years ago

I doubt there's any programme you've ever written that makes no use of polymorphism (the contextual resolution between multiple semantics to a term).

Even 1 + 1 is polymorphic, ie., "1" + "1" selects for a different behaviour.

Method overriding may rely on inheritance, and the problem is usually the inheritance not the polymorphism.

Floegipoky• 6 years ago

I have far fewer problems with the Car than I do with the rest of the example.

The problem comes when you want to add continually new methods all the time

This is not a real problem! Violating encapsulation to avoid dealing with the occasional merge conflict is probably the worst use of pattern matching I've ever seen. The tug-of-war between OO and FP is greatly exaggerated.

mysonytv3• 6 years ago

and the other are still using Foo and Bar :-/

Intro To Pattern Matching – Covers C# 9

Related Stories