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

171–180 of 214 posts

Re: C# Pattern Matching

#171

Post by oaiey »

Kipters wrote: post #51
mumblemumble wrote: post #26

Earlier quoted context omitted.

I suspect that it's not an issue of respect so much as an issue of governance. C# remains a commercial language, wholly owned by a single corporate entity. That, I think, allows its maintainers some luxuries that community languages don't enjoy. Chief among them is a whole team of full-time language designers and implementers who can sustain a sort of deep concentration 40-ish hours a week for years on end. I'm prett…

Technically it's owned by .NET Foundation now, but admittedly it's composed of MSFT people by a large part. Also, language design happens on GitHub, and the community is encouraged to get involved.

As long as Microsoft finances the .NET/C# team, neither runtime/libraries nor the language will include anything which does not fit in their strategies/vision. The .NET Foundation will not change anything here. And that is good. The .NET Foundation ensures that the product is legally usable on Linux/Macs/other non Windows platforms and additionally helps the ecosystem.

F# for example is set loose of these constraints.

Re: C# Pattern Matching

#172

Post by 1propionyl »

martijn_himself wrote: post #170

This is neat, but also super confusing. Is the ability to build class hierarchies not the ultimate reason to use C#, an Object-Oriented language? Which one of the two is idiomatic? Great, now we have code littered with methods that take object s as parameters, so we have no clue what to actually pass to the method? C# is a fantastic language but I feel increasingly lost with the barrage of new features added to it.

Class hierarchies are not a desirable feature of object-oriented languages, they're an unfortunate side effect of their historical development. (For example, early versions of Java did not actually have the interface keyword at all.)

There are several very good reasons that the inherited wisdom about OOP includes such phrases as "prefer composition and delegation over inheritance".

There are some cases where class hierarchies are actually good, but they're far rarer than most would suspect. The Liskov Substitution Principle is less of a guide as to how to use inheritance as much as it is a guide as to when you should not be using inheritance at all.

And to address your point: the only time objects with class hierarchy and subclases should be accepted as arguments to methods is precisely when the LSP holds. Otherwise, you're gonna have a bad time.

Re: C# Pattern Matching

#173

Post by ygra »

hermitdev wrote: post #103
fuzzy2 wrote: post #63

Earlier quoted context omitted.

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 edi…

Rico has a point to a degree and every VS version since then reduced memory footprint and improved performance (mostly due to not calculating stuff up-front which may never be needed and doing it on demand).

Microsoft has also pushed since VS 2008 (!) for plug-ins and extensions to use an out-of-process model. I think ReSharper got the message in summer 2019 that it might be a good idea – and incidentally, a lot of their performance comparison of Rider vs. VS comes down to "Rider uses ReSharper in another process, so the IDE doesn't slow down when ReSharper does things", while they themselves still pursued the slower model in VS. Heck, until a few releases ago ReSharper was still using the old synchronous COM APIs for querying the solution after loading, leading to severe pauses when opening a solution or re-loading it after switching source control states.

Vanilla VS is plenty fast and not that memory-hungry. In my experience it's extensions that try to sync with IDE state where a lot of the waiting comes in and in-process extensions where a lot of the memory usage comes from.

Re: C# Pattern Matching

#174

Post by goto11 »

martijn_himself wrote: post #170

This is neat, but also super confusing. Is the ability to build class hierarchies not the ultimate reason to use C#, an Object-Oriented language? Which one of the two is idiomatic? Great, now we have code littered with methods that take object s as parameters, so we have no clue what to actually pass to the method? C# is a fantastic language but I feel increasingly lost with the barrage of new features added to it.

No, the ultimate reason to use C# is to solve problems and build useful applications!

But you are correct that method overriding and pattern matching partially solve the same problem in different ways. C# is not really a pure OO "one way to do it" language anymore, it is a multi-paradigm language, for better or worse. Arguably it have been since anonymous function was added.

Re: C# Pattern Matching

#175

Post by fsloth »

martijn_himself wrote: post #170

This is neat, but also super confusing. Is the ability to build class hierarchies not the ultimate reason to use C#, an Object-Oriented language? Which one of the two is idiomatic? Great, now we have code littered with methods that take object s as parameters, so we have no clue what to actually pass to the method? C# is a fantastic language but I feel increasingly lost with the barrage of new features added to it.

"Is the ability to build class hierarchies not the ultimate reason to use C#, an Object-Oriented language?"

The ultimate reason to use C# is because it's a modern managed language with an excellent base library, excellent tooling and excellent debugging experience.

Object oriented hierarchy is not a value in itself. Often it's an antipattern. I'd day 80% of time you are off much better by cleanly separating your program to "data" and "algorithms", and manipulating data as far as possible in immutable fashion. I.e. when mutating an array, don't overwrite elements, rather copy the values to new array. This will be easier to understand, and likely faster due to how memory and caches work on modern platforms. Etc.

"Which one of the two is idiomatic?"

Idiomatic is a weak argument when talking about programming. Either the problem is trivial, hence all you have left are to discuss trivialities, or you don't understand the problem and are therefore discussing things of very little consequence.

Writing maintainable, understandable code is important. But "idiomatic" gives the idea that there is some higher level ultimate truth on what is always the best formulation for each and every problem.

If you are writing boiler-plate code, then yes, best pattern will emerge eventually. But then it should be self evident which is best way to move forward. Hence, 'idiomatic' once again loses it's value.

Re: C# Pattern Matching

#176

Post by ygra »

vcool07 wrote: post #125

I'm surprised at the no. of recommendations for resharper even now. I thought most of the new features of resharper was already included as part of VS2019. Any specific feature that's missing ?

Resharper still has a bunch more refactoring and navigation tools. Whether that's those that are missing and you're using them, is probably up to each person themselves. The single feature I found missing all the time was smart completion which suggested matching locals/properties based on the expected type of arguments or missing expressions during typing. Everything else I tend to use, navigating to files, types, members, basic refactoring (most-used are extract local and extract method anyway) are all there and wouldn't need Resharper.

Re: C# Pattern Matching

#177

Post by ygra »

zenexer wrote: post #36
moogly wrote: post #33

Earlier quoted context omitted.

It's not reserved (and that's probably why it's not used). Most teams working on languages with a decently long history are very reluctant to add new keywords, because it will break preexisting code. `match` is a very common variable name, not only in relation to regexes. There are of course ways to do contextual parsing so that you can introduce new keywords (I believe this was done in C# with the LINQ extensions),…

C# isn't too hesitant to introduce new keywords because it supports contextual keywords.[0] Many C# keywords are also valid identifiers. In this case, using `match` in place of `where` probably wouldn't have introduced any incompatibilities. In fact, `where` isn't a reserved keyword, either--you can have an identifier named `where`.[1] To an existing C# programmer, `where` makes a lot of sense, since it's used for ma…

C# has never added new reserved keywords. All keywords added after 1.0 are contextual and can still be used as identifiers. With some things like nameof, they even get their special meaning only if there's nothing else of that name that could be called. They take backwards compatibility of existing code quite serious. In fact, the only instance I can remember where C# had a breaking change was in C# 5 with how the foreach loop variable interacted with closures. The probability of code existing that relied on the old behaviour is probably really low, though.

Re: C# Pattern Matching

#178

Post by martijn_himself »

1propionyl wrote: post #172
martijn_himself wrote: post #170

This is neat, but also super confusing. Is the ability to build class hierarchies not the ultimate reason to use C#, an Object-Oriented language? Which one of the two is idiomatic? Great, now we have code littered with methods that take object s as parameters, so we have no clue what to actually pass to the method? C# is a fantastic language but I feel increasingly lost with the barrage of new features added to it.

Class hierarchies are not a desirable feature of object-oriented languages, they're an unfortunate side effect of their historical development. (For example, early versions of Java did not actually have the interface keyword at all.) There are several very good reasons that the inherited wisdom about OOP includes such phrases as "prefer composition and delegation over inheritance". There are some cases where class hi…

These are all valid points and it shows my lack of understanding (same with the other comments), even though I use C# on a semi-regular basis I have a lot to learn!

I don't envy any newcomers to the language though, there is so much to take in.

Re: C# Pattern Matching

#179

Post by 1propionyl »

goto11 wrote: post #174
martijn_himself wrote: post #170

This is neat, but also super confusing. Is the ability to build class hierarchies not the ultimate reason to use C#, an Object-Oriented language? Which one of the two is idiomatic? Great, now we have code littered with methods that take object s as parameters, so we have no clue what to actually pass to the method? C# is a fantastic language but I feel increasingly lost with the barrage of new features added to it.

No, the ultimate reason to use C# is to solve problems and build useful applications! But you are correct that method overriding and pattern matching partially solve the same problem in different ways. C# is not really a pure OO "one way to do it" language anymore, it is a multi-paradigm language, for better or worse. Arguably it have been since anonymous function was added.

Method overriding and pattern matching actually solve the same problem in precisely opposite ways.

In the functional programming community, this is referred to as "the expression problem".

To understand this problem properly you must first accept the idea that every object (or class of objects) in an OO context is essentially an interpreter defined by how it responds to sequential messages (methods).

The crux of the expression problem is the tension between adding new operations over a type (i.e. new methods on the base class of a hierarchy) which requires implanting that method for every existing subclass... and adding new types (new subclases) over which an existing operation (method from the parent class) applies, which requires implementing every existing for the new type (subclass).

There are some "clever" approaches to "solving" this problem, but they only really make sense for types that look and act like ASTs. Despite many complex programs essentially being interpreters for some internal "language", this isn't as useful as one might hope, and the machinery necessary to "solve" the problem relies on a lot of compiler and language extensions.

If you want an example of (uh) "solving" the expression problem, the canonical starting point is Wouter Swierstra's "Data Types a la Carte" paper.

Re: C# Pattern Matching

#180

Post by 1propionyl »

martijn_himself wrote: post #178
1propionyl wrote: post #172

Earlier quoted context omitted.

Class hierarchies are not a desirable feature of object-oriented languages, they're an unfortunate side effect of their historical development. (For example, early versions of Java did not actually have the interface keyword at all.) There are several very good reasons that the inherited wisdom about OOP includes such phrases as "prefer composition and delegation over inheritance". There are some cases where class hi…

These are all valid points and it shows my lack of understanding (same with the other comments), even though I use C# on a semi-regular basis I have a lot to learn! I don't envy any newcomers to the language though, there is so much to take in.

My general advice to anyone working with C# is the same advice given by the authors of Smalltalk to developers.

1) Always prefer composition and delegation to inheritance.

2) Always prefer interface inheritance to implementation inheritance even if in the short term it results in code clones.

3) If you intend to have multiple subclasses that adhere to the Liskov Substitution Principle, it is always better to have IFoo and X implements IFoo, Y implements IFoo... than it is to have abstract class Foo where X, Y extend Foo. You can still do that, behind the scenes, but your public interface should whenever possible be nearly entirely interfaces and concrete classes.

4) Inheriting the body/behavior of methods is seductive but ultimately only a poor excuse for not delegating that will create maintenance headaches down the line.

Post reply on HN