[master-litty]

I like to consider programming as an art form with many schools of thought. As with art in other mediums, developers enjoy creating and interacting with their art in different ways.

Conflict builds when developers exist in the same ecosystem with different opinions on what this art means to them. It feels like everyone is accomplishing different goals because we really are.

Some people want to continually iterate their code until it matches a perfect vision in their head; It's less (if even at all) about the functionality and more about how we got there. That obviously frustrates people who care about the functionality far more.

[crimsonalucard]

The issue with this way of thinking is that programming lives in a small universe of grammars and not in the real world where the artist can choose any medium to convey his work. So small is this universe that you don't even need art to design the most optimal program. You don't even need science either... you can use logic to calculate the best program design.

Thinking of programming as an art is entirely the wrong direction. Pattern matching, especially exhaustive polymorphic type checking will categorically reduce the amount of logic errors possible with the program. This is logic over art at work.

The main issue for me with c++ is that its overall design has largely been artistic over logical. So tacking on pattern matching makes it an even bigger mess than it already is...

[chaorace]

I think you're striking a false dichotomy between "logic" and "art" here. Programming languages are abstractions created by abstract creatures (/hello/). You simply can't solve a programming language, because the parameters for success will be just as invented and unmoored from absolutes as the subject in question.

[crimsonalucard]

There is no false dichotomy. There very well is a clear dichotomy.

Another person had a similar notion to you and my response to him is more in depth: https://news.ycombinator.com/item?id=21952737

In this case the language we designed is assembly. The parameter for success is: less possibility for bugs. Exhaustive type matching is a definitive and logical improvement because it shrinks the codomain of possible erroneous states, thus less bugs.

[master-litty]

There are certainly more mediums immediately available in a real-world artist's arsenal, but the depth of programming goes beyond the grammar: We do have choices in language (Rust vs. C++), program architecture (APIs exposed, code organization, how it works with the rest of a system), and balancing what "most optimal" even means. With exceptions and constraints of course, I don't think any of these have a universally logical answer.

My favorite example is the Requests library for Python. It dubs itself "HTTP for Humans" -- I find that quite nice from a human perspective, but it may not be the most logical networking choice in all cases. It's an artistic choice by the developer to make it more human-friendly.

At any rate I think the original discussion is, unfortunately, not the greatest example to make this comment on. Comparing pattern matching to switch-cases is like comparing a high-quality brush to a low-quality one.

[crimsonalucard]

API's exposed is a user defined requirement. Most optimal is also user defined.

Whenever something is "user defined" that means you make it up because you're actually exiting the world of the simple program. These things are akin to business requirements or UX/UI.

A popular word that's often used to figure out these things is the word "design" as opposed to "calculate." When we "calculate" something we are performing a mechanical operation designed to solve a problem with the most "optimal" solution. When we "design" something we are pulling a solution out of our imagination with no way to verify that it is the most "optimal" solution. Note that the word "optimal" is something we make up and define ourselves.

For example: What is the optimal way to get from point A to point B? One definition of "optimal" in mathematics (a small universe similar to programming) is the shortest distance. For this we have a calculation: a line. Another definition of "optimal" in the reality we occupy as humans (a large universe much bigger than math or the simulation in our computer systems) is the shortest time it takes for a human to move from A to B. The solution to this is "designed" we have several options to choose from but to fulfill the requirement of shortest time... we currently tend to choose a plane as it is the fastest vehicle available. However, we have no way of knowing whether the plane we took is the best possible solution humanity has ever come up with. The amount of possibilities here is so large we can't calculate a solution.

Programming within the bounds of "design" requirements and user specified definitions of "optimal" lives in a small universe similar to a mathematical universe of axioms and theorems meaning that we can very well calculate the most optimal programs rather then design a sub optimal one. There is much research on this topic, I'd look into Prolog, category theory, dependent types, formal methods and that kind of thing to learn more. It's very deep and is basically a whole different topic.

So given a portion of the definition of "optimal" that most people can agree on: "less bugs at zero performance cost," pattern matching is a calculated improvement over if statements and switch cases. Thanks to exhaustive matching you must handle every possible instantiation of a type or the program cannot compile. This is a definitive and logical improvement over all other case handling methodologies.

There is no need for an artistic analogy to illustrate a point, the improvement is definitive and logical.

Whenever a human turns to "art" to solve a problem it literally means they don't have the knowledge on how to find the most "optimal" solution. Also very likely they don't even have a clear definition of what they want as "optimal."

[master-litty]

This is fascinating and indeed quite deep. You've given me a lot of great perspective, thank you, there is clearly much I can learn here.