C# Pattern Matching • Hacker News Board

Re: C# Pattern Matching

#101

Post by Ididntdothis » Wed, Feb 05, 2020, 12:53 AM UTC

qwerty456127 wrote: post #57

keithnz wrote: post #7

Earlier quoted context omitted.

as an aside, if you got Rider as part of your resharper subscription, try it out, it is basically a drop in replacement for visual studio but faster and with many many little quality of life improvements you never knew you needed :)

> replacement for visual studio but faster How can a IntelliJ Idea derivative written in Java be faster than VistalStudio which is native code? Both Idea and PyCharm work much slower than VisualStudio on my machine.

Visual Studio is written in WPF which is not exactly a speed demon.

Re: C# Pattern Matching

#102

Post by emodendroket » Wed, Feb 05, 2020, 12:54 AM UTC

akra wrote: post #70

Someone1234 wrote: post #43

Earlier quoted context omitted.

Their long game is to slowly convert C# into F# without anyone realizing it. They're roughly half way through already.

From the features they are porting into the language I think this is the case; albeit C# will always be the more verbose language and the features will feel somewhat clunky at times IMO. Pattern matching, async yield return, async/await, etc all were in F# in some form beforehand with features like records and DU's probably being investigated as well. When I read a new C# language version announcement it does feel li…

I used Scala for a bit and then came back to C# and felt like they were porting over all the Scala features, but I think the F# explanation may make more sense.

Re: C# Pattern Matching

#103

Post by hermitdev » Wed, Feb 05, 2020, 12:55 AM UTC

fuzzy2 wrote: post #63

qwerty456127 wrote: post #57

Earlier quoted context omitted.

> replacement for visual studio but faster How can a IntelliJ Idea derivative written in Java be faster than VistalStudio which is native code? Both Idea and PyCharm work much slower than VisualStudio on my machine.

Visual Studio isn't native though. It's .NET and COM. That's also why we're still stuck with 32-bit VS.

That's not why VS is still 32-bit. Apparently folks at MS dont think the extra address space isnt worth it and think it would adversely affect performance [1].

In my own experience in migrating servers from 32 to 64-bit on Linux 12 years ago, 64-bit was around 10-20% slower than the 32-bit build. Dont how itd fare today (no longer at that job). Even though performance was demonstrably slower, 64-bit it was due to edict from the CEO.

For what its worth, neither of the services I was responsible benefited from the extra address space. Mem usage for bother services peaked at around 750 MB.

[1] https://docs.microsoft.com/en-us/archive/blogs/ricom/revisit...

Re: C# Pattern Matching

#104

Post by emodendroket » Wed, Feb 05, 2020, 12:55 AM UTC

throwawa66 wrote: post #14

czechdeveloper wrote: post #10

Earlier quoted context omitted.

Every single feature C# got in past years increased my productivity. I understand that it may cause issues to new learners, but overall, what of them do you consider bloat?

Wait till you get to work in some complex code bases and you'll understand why jamming all kinds of idioms into one language can become a disaster. It's a tool after all, if you know how to use it properly you don't paint yourself into a corner. However, too much flexibility can lead to many problems in larger teams. Good luck!

Seems a little presumptuous to jump right to "everyone who disagrees with me has only worked on trivial projects."

Re: C# Pattern Matching

#105

Post by emodendroket » Wed, Feb 05, 2020, 12:56 AM UTC

throwawa66 wrote: post #60

graphememes wrote: post #44

Earlier quoted context omitted.

You find F# easier to work with. That's all. Doesn't mean others _must_ share your opinion. Good luck to you.

Yes, its all subjective, I know. But stepping out of the garden is what I’d like people to take out of this. Saying C# is the most beautiful language (like some commenter states) is true only if you haven’t dabbled in many languages. And once you do you feel stupid for having had this conviction in the first place. Ive used C# throughout my career, I don’t diss the language or the ecosystem, but other things are to b…

I've used a number of others and still appreciate C#, especially since it's stealing all the features I liked

Re: C# Pattern Matching

#106

Post by Merad » Wed, Feb 05, 2020, 12:57 AM UTC

jesseryoung wrote: post #42

I've always seen switch statements as an anti-pattern in C#. These examples however, do demonstrate neat time saving techniques. Does anybody have examples of real-world use cases that take advantage of this that couldn't (or shouldn't) be solved in a more OO way (Visitor, Strategy, Template Method, etc)

At work our team just finished implementing a filtering library for our web services that's loosely based on OData. The query string value is parsed into an expression tree, then all of the operations on the expression tree are implemented using pattern matching. You could of course implement this with the visitor pattern, but in comparing the two we decided to use pattern matching because it's significantly less verbose and easier to understand.

Re: C# Pattern Matching

#107

Post by emodendroket » Wed, Feb 05, 2020, 12:57 AM UTC

bernawil wrote: post #76

thurn wrote: post #61

Earlier quoted context omitted.

"Type-sensitive" code is encouraged when using the functional style, where you treat objects as dumb "bags of data" that have no inherent functionality of their own. It's still discouraged when following an object-oriented "smart objects" pattern.

How is that particularly functional? In Haskell the same example would be approached at type-level using type classes, something extremely similar to using Interfaces. I guess in a dynamic functional language you'd probably avoid doing this type of contact-oriented stuff, but you'd rather pass a callback at the last point rather than check type of what you got passed.

I worked in Scala for a while and it was pretty common to use these kind of pattern-match statements for a kind of dispatch mechanism. Not even necessarily with types, it might be something like "do one thing when field a is null and field b is not, another thing when it's the other way around, another thing when they're both null, and still another when neither is." The nice thing about it is the compiler can assert that your match is exhaustive.

Re: C# Pattern Matching

#108

Post by flatline » Wed, Feb 05, 2020, 1:00 AM UTC

bilekas wrote: post #65

I'm super embarrassed as a dotNet developer, at times 'engineer', that I don't know this.. I can't list how many time's I've ran into this kind of issue when trying to explain to a peer/intern.. (Only know I probably messed up a bit now) And HN links like this just remind me that I would love to take a 'bus mans holiday' just to catch up on the framework. This is a huge plus to the benefits of sending employees and m…

Keeping a code base up to date is a cultural thing. Keep up to pace yourself. Suggest new features during code review. Encourage curiosity. Hire developers who are interested in technology, from diverse backgrounds. Be enthusiastic and evangelize about new things, it will inspire others even if you don’t realize it.

Re: C# Pattern Matching

#109

Post by jen20 » Wed, Feb 05, 2020, 1:02 AM UTC

qwerty456127 wrote: post #57

keithnz wrote: post #7

Earlier quoted context omitted.

as an aside, if you got Rider as part of your resharper subscription, try it out, it is basically a drop in replacement for visual studio but faster and with many many little quality of life improvements you never knew you needed :)

> replacement for visual studio but faster How can a IntelliJ Idea derivative written in Java be faster than VistalStudio which is native code? Both Idea and PyCharm work much slower than VisualStudio on my machine.

Visual Studio has been unable to keep up with my (not notably fast) typing since like 2005. Rider has no issue. Nor does IntelliJ or CLion or Goland.

Re: C# Pattern Matching

#110

Post by hermitdev » Wed, Feb 05, 2020, 1:05 AM UTC

alkonaut wrote: post #64

jolux wrote: post #46

Earlier quoted context omitted.

C# 8 also has nullable reference types, i.e. comprehensive nullability analysis, which is comparable though not identical to an option type. I really wish for exhaustive pattern matching and ADTs in C#, though.

It always feels a bit half baked when the class library isn’t designed with it though. It would be as if generics were added but not System.Collections.Generic. So while I long thought it would be the perfect addition to C#, I’m not so enthusiastic any more. It would be great (F# is!) but not as good as it would be in a language and platform where it was there all along. In F# this is already an issue when you want t…

> It would be as if generics were added but not System.Collections.Generic

I started with C# in the 1.0 days before generics. The lack of strongly typed collections was very annoying with all of the casts involved. I used to use a template engine/code generator to create strongly typed collections. Can't remember the name of the tool... Probably been since 2002 or 2003 since I used it.