Thank you. I understand the appeal of a concise keyword like "fn." However, I believe a balance between brevity and clarity is essential.

Consider using "static method()" for statically typed functions and "def method()" for dynamically typed ones. Alternatively, we could use "st method()" if brevity is a priority. These alternatives are still concise yet convey the properties explicitly.

It's worth noting that even though experienced programmers might quickly learn the difference between "fn" and "def," newcomers might struggle. Explicit keywords like "static" reduce mental overhead and improve code readability for everyone, not just newcomers.

I understand the discussion is about something very small, but I like to think about small details, as those make a considerable difference in the big picture. For that reason, in terms of language design, while "fn" is shorter, a slightly longer self-explanatory keyword can enhance the code's long-term maintainability and readability. The trade-off for a few extra characters is minimal compared to the benefits of clear and explicit language constructs.

I hope this clarifies my perspective on why a more explicit keyword might be preferable.

They are only "self-explanatory" to a point and are almost never universally so (to people from different languages). I think familiarity at first sight is likely highly overrated. As long as you can quickly learn the differences, and they don't confuse you from the second to the$\omega$-th viewing, it should be okay. Also, the term "static method: is quite ambiguous (consider@staticmethod).