Why "fn" and "def" instead of "static def" and "def" (for example)

[oSumAtrIX]

I came across these keywords and was wondering why they were chosen.
As I understand, "fn" is for static typing and "def" for dynamic typing.

The problem I am seeing is that neither "fn" nor "def" express these properties explicitly.
The assumption I assume is that people come from another language and might be able to infer, that "def" functions are dynamically typed (as seen in Python) as opposed to "fn" functions.

What is the reason for not choosing static def vs def as a simple example? It explicitly conveys the properties of the functions. With the static keyword it is explicitly conveyed that the function is statically typed, vice versa.
Compatibility with Python is also not broken as the keyword def is kept and"static def" is added to explicitly convey the static typing property of the function as opposed to "fn" at which the reader is left to guess why there's two kinds of keywords to declare functions. From a language design standpoint I can't understand why "fn" has been used.

[Brian-M-J]

I prefer fn because it's nice and short. Since programmers are going to be writing a whole lot of functions, I'd rather have the introducer keyword be as short as possible.

There's some intuition that fn is strict and static whereas def is loose and dynamic, because Python uses def and Rust uses fn, so I don't think it'll take very long for newbies to learn the difference. The advantage of having short introducers outweighs the disadvantage of possible confusion between the two.

It's a better short-term vs long-term tradeoff IMO.

[oSumAtrIX]

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.

[soraros]

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).