Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C# Pattern Matching

docs.microsoft.com

Post reply on HN
Print view View original

91–100 of 214 posts

Re: C# Pattern Matching

#91

Post by DaiPlusPlus »

throwawa66 wrote: post #29
konamicode wrote: post #24

Earlier quoted context omitted.

Unlike in C# pattern matching in F# is exhaustive. I’m guessing this is what was meant by “better”.

Yes, i find that a good argument especially if you plan on using this feature a lot it can save you from shooting yourself in the foot. It also is a better idiom in F#, nicer to grok, but that’s subjective. However, only direct experience will make you reconsider. I’ve seen a discriminated union implementation in C# the other day and was repulsed.

I use OneOf in C# a lot now. If you’re thinking of the same one I am the only ugly thing about it is the code-generation required to generate all of the variations from OneOf to OneOf.

Re: C# Pattern Matching

#92

Post by gambler »

wvenable wrote: post #67
gambler wrote: post #55

Earlier quoted context omitted.

The only thing Java proved about language design is that popularity and good language design have zero correlation. If you want to see simplicity that stood the test of time, look at Smalltalk or Lisp.

I appreciated Smalltalk for a while but it is simple only on the surface and once you peel below that it's extremely complicated. Simple syntax doesn't necessarily lead to simple designs. Lisp's limited syntax allows everyone to create their own "language" and that's arguably worse than the fixed set of statements that exist in other languages. I'd even argue that Lisp is inhuman because it's brutal compared to natur…

>I appreciated Smalltalk for a while but it is simple only on the surface and once you peel below that it's extremely complicated.

Not really. Definitely not compared to C# or Java. Smalltalk simply has more system-level code accessible to the user.

I've worked with Java environments that tried to replicate the visual programming features of Smalltalk. They were about 10X the size of a modern Smalltalk distribution (Squak or Pharo), had at least 100 times slower startup time and you still needed an external IDE to get anything "serious" done with them.

Re: C# Pattern Matching

#93

Post by eyegor »

Heads up for C# devs, you should switch all your code bases to use (x is null) and !(x is null) instead of ==. The is operator can't be overloaded, and always compiles to IL eq, whereas == can be overloaded in custom types. Of course it would also be nice if everything was moved to nullable reference types [0], but that's a non trivial amount of work. Note that most C#8 features can be enabled manually through the csproj files, including nullable reference types, even if you're using framework.

[0] https://docs.microsoft.com/en-us/dotnet/csharp/nullable-refe...

Re: C# Pattern Matching

#94

Post by keithnz »

kag0 wrote: post #41

I wrote up how I'd do this in scala, just to compare and contrast val shape: Option[Shape] = ??? shape.map { case Square(0) | Circle(0) => 0 case Triangle(b, h) if b == 0 || h == 0 => 0 case Rectangle(l, h) if l == 0 || h == 0 => 0 case Square(side) => side * side case Circle(radius) => radius * radius * math.Pi case Triangle(base, height) => base * height / 2 case Rectangle(length, height) => length * height } what…

just FYI, the C# can be rewritten as a switch expression which is more comparable to the scala

            return shape switch
            {
                Square s when s.Side == 0 => 0,
                Circle c when c.Radius == 0 => 0,
                Triangle t when t.Base == 0 || t.Height == 0 => 0,
                Rectangle r when r.Length == 0 || r.Height == 0 => 0,
                Square s => (s.Side * s.Side),
                Circle c => (c.Radius * c.Radius * Math.PI),
                Triangle t => (t.Base * t.Height / 2),
                Rectangle r => (r.Length * r.Height),
                _ => throw new ArgumentException(message: "shape is not a recognized shape", paramName: nameof(shape))
            };

Re: C# Pattern Matching

#95

Post by eyegor »

to11mtm wrote: post #53
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 :)

I started using Rider recently. It's faster yes, but seems to be a bit more memory hungry out of the gate than VS+Resharper. There is one HUGE thing I miss however - the Package Manager console. There's still a few things I have to do in there and thus have to switch back to VS.

You can achieve this through nuget.exe from your hidden /.nuget directory iirc.

Re: C# Pattern Matching

#96

Post by DaiPlusPlus »

bob1029 wrote: post #52
totalperspectiv wrote: post #47

At this point I would not be sad if I was forced to use C# for some reason.

You should try it out sometime, regardless of coercion. There isn't much of a barrier to entry anymore. Even installing VS2019 is a pleasant experience now. I have yet to meet a developer who gave C# a legitimate try and then decided it was entirely not for them. That said, I only personally know developers who are working in the realm of B2B application development, so perhaps there are other incompatible use cases…

Data science, vision, etc - this is where Python reigns supreme and using C# is really going against the rest of the industry.

Using OpenCV from .NET is painful, but from Python it feels native.

Re: C# Pattern Matching

#97

Post by eyegor »

eberkund wrote: post #58
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.

Because VS has limitations on the amount of memory it can use and although they have been working on this, there is still functionality which is highly single threaded whereas Rider tends to offload most of the functionality from the UI thread into background processes.

The memory limitations can be partially kicked down the road by setting /largeaddressaware on devenv.exe. Ofc it's still beyond frustrating when you have a large solution with many component projects. I personally ram against the 4gb ceiling constantly.

Re: C# Pattern Matching

#98

Post by dang »

trianglem wrote: post #82
dang wrote: post #30

Earlier quoted context omitted.

Please don't. https://news.ycombinator.com/newsguidelines.html

Thank you for making this a productive space. You are getting paid for this right?

Yes. Actually that fact is more interesting than it looks.

It's all of our good fortune that it's in YC's interests to fund HN just as it is, with the moderators' primary job being to keep it interesting and hopefully keep the community happy. If HN were a startup, we would have to play the growth-hacking game. If it were the media property of some larger corporation, some manager would eventually put a monetization squeeze on it. Either of those tactics would ruin this place, whether or not they succeeded.

YC doesn't need us to do such things because a happy HN is the most valuable-to-YC HN. It's basically an accident—a dual accident of how YC's business works and how things historically developed—that we ended up in that spot. It's a special position to be in, and our first responsibility is to preserve it. Hence our motto, Move slowly and preserve things.

Re: C# Pattern Matching

#99

Post by emodendroket »

flamtap wrote: post #86
jcpst wrote: post #84

Earlier quoted context omitted.

I have clocked in way more hours in Rider than VS. I can flawlessly run and debug our decades old monolith with 40-50 projects and millions LOC, containing C#, VB, Web Forms, WPF, files with 80k lines... And all of our .NET Core services on MacOS, with all my unix-y tooling. There is “VS for Mac”, but it’s not really VS. It’s Xamarin Studio rebranded. Rider works excellent on my Linux box at home as well, where the a…

As a long-time ReSharper user, I’ve been meaning to give rider a close look for some time now. Unfortunately the last project I was on was heavy into WPF, and that was about the only box VS didn’t tick. Any tips, tricks, or pitfalls to avoid making the switch from VS to Rider?

I used VS for years before switching to Rider and honestly... just jump in, there's not much to know. If you've used ReSharper the features should seem pretty familiar.

Re: C# Pattern Matching

#100

Post by emodendroket »

keithnz wrote: post #38
bob1029 wrote: post #31

Earlier quoted context omitted.

The spell checker is probably the single greatest feature in Rider. It works really well on composite type names. E.g. 'CustomerPreferences' would not get a squiggle under it for spelling, but 'CusomerPreferences' would. Performance is arguably better in most circumstances, but it doesn't support some of the bleeding edge .NET Core functionality as well as VS2019 does.

It also doesn't support some dried up crusty .NET functionality like webforms either (it compiles it fine, but doesn't have the code generation tools that VS has )

Every release has more and more stuff though. Like they have added Windows Forms pretty recently.

Right now SSDT and some ancient Linq2Sql stuff is the only thing I still find myself needing VS for.

Post reply on HN