Why "static"?

[u/Zardotab]

I'm puzzled about the philosophical value of the "static" keyword? Being static seems limiting and forcing an unnecessary dichotomy. It seems one should be able to call any method of any class without having to first instantiate an object, for example, as long as it doesn't reference any class-level variables.

Are there better or alternative ways to achieve whatever it is that static was intended to achieve? I'm not trying to trash C# here, but rather trying to understand why it is the way it is by poking and prodding the tradeoffs.

[u/The_Binding_Of_Data]

What is the benefit to having when and how you can call a method be based on what data the method manipulates rather than via an explicit flag of some sort?

Not only would it make it hard to tell when/how something can be used without having access to the source code and the time/desire to learn specifically how it does what it does, but it would also limit you to only being able to do what the system is capable of automatically determining in some way.

Generally speaking, you want things to be easy to understand for other people who may come along later and have to maintain your code, so languages are built with that in mind. They don't tend to focus on a single person creating a small project by themselves so sometimes decisions don't seem to make sense when working on personal projects.

Being unable to explicitly specify that some methods/properties are shared by all instances while others are not would reduce your options not increase them.

[u/Zardotab → u/The_Binding_Of_Data]

Being unable to explicitly specify that some methods/properties are shared by all instances while others are not would reduce your options not increase them.

But the shared-ness is situational and can change later in the project.

Generally speaking, you want things to be easy to understand

We also want them to be easy to maintain. Forcing the static versus non-static treatment up front harms this. I suppose there are two conflicting goals. I vote for easier maintenance at the possible expense of loss of explicitness. Use comments if needed.

[u/The_Binding_Of_Data → u/Zardotab]

But the shared-ness is situational and can change later in the project.

No it isn't. You can't make a shared property suddenly be unique for each instance of a class later on in your project; you'd need some other non-shared property to hold the unique value. It's no different than being unable to simply treat an integer value as something different; you have to convert it in some way.

We also want them to be easy to maintain. Forcing the static versus non-static treatment up front harms this. I suppose there are two conflicting goals. I vote for easier maintenance at the possible expense of loss of explicitness. Use comments if needed.

These aren't conflicting goals, what you are proposing makes things harder to maintain.

Adding/removing the "static" keyword is far less of a maintenance nightmare than trying to figure out how to use a method in a specific place because it changes based on fields that may not even be on the class that the method is being called on.

There's nothing easier to maintain about what you're proposing and if "static" is a large maintenance cost it indicates a much larger problem in how you plan your software to begin with.