3 ms·
> C# is becoming a BIG language similar to C++. Yes. And they're on roughly the same trajectory: start out as a relatively small object-oriented and procedural
by mumblemumble 6y ago
> C# is becoming a BIG language similar to C++.
Yes. And they're on roughly the same trajectory: start out as a relatively small object-oriented and procedural language, and then just keep piling on more and more and more features to make the procedural programming more ergonomic. Including by pulling in more and more stuff from functional programming.
On the one hand, it's hard for me to dislike adding pattern matching too much, because I do tend to prefer functional programming. On the other hand, I'm also familiar enough with OOP (it's been most my career) to know that there's a huge overlap between problems that pattern matching can solve, and problems that dynamic dispatch can solve.
The thing is, in these examples of using pattern matching in a language like C# or Python, I never see anyone even considering the object-oriented solution to the problem. They just show how gross the procedural version is. Which isn't quite enough in my book. You don't just want to show that some existing language features are a poor fit for the problem at hand, you want to show that all existing language features are a poor fit. And somehow, despite these being object-oriented languages, the object-oriented solution is never even being considered anymore.
Is it because OOP is that bad? Or is it because we've been badly taught? I know which answer is easier to argue for, but I'm less and less convinced that that's because it's the best answer.
- jayd16 6y agoIn a lot of ways I think the OOP approach is just too cumbersome. If you imagine implementing a handler chain, the logic would be quite verbose and distributed. You might want to use an inline type definition. Then you might want to use an anonymous types, then lambdas. Then you realize that pattern matching is just a sugared version of the OO handler chain.
- mumblemumble 6y agoI was actually thinking something simpler; just having all your types implement an interface, and then following the general "tell, don't ask" dictum. Handlers are useful for some more complex use cases, as is the visitor pattern, but they're frankly overused. It's often enough to create an interface and let the classes handle their own class-specific logic. And polymorphism is not just a sugared version of pattern matching. Each gives you a different kind of flexibility. Polymorphism makes it easy to add new types to an existing set of operations, and pattern matching makes it easier to add new operations to an existing set of types. Which one you need depends on your use case. The common knowledge can get a bit tricky here, though. For example, functional programming is often touted as being ideal for programming language experimentation, because you have pattern matching, but I have found that OOP is more to my taste in this area. The reason is because, nowadays, the set of basic operations a compiler or interpreter needs to do is fairly well-established and static. But the list of things you need to operate on - that is, the set of features in the language you're implementing - will change as you add or remove features from the language.
- CornCobs 6y agoIn my personal opinion when I'm reading code and trying to follow execution flow, OOP's "Everything happens elsewhere" approach is really annoying. In a Java codebase for example I would need to find all implementing classes, then search for that one method being called in each separate file. This means opening multiple files and searching for a few lines of code in each file, just to see what happens. Written in a pattern-matching style there is a nicer correspondence between code-locality and execution-locality - which matches my mental model much more nicely, rather than OOP's colocation of different behaviors on the same entity