古いCスタイルのメソッド名が現代の言語で引き続き使用されているのはなぜですか？
コンピューティングの初期の頃は、ストレージが限られていたため、printfのような短いメソッド名が理にかなっていることを理解しています。しかし、なぜPython and Goのような現代の言語がC APIの読みにくい名前をまだ使用しているのですか？print_formatのような読みやすい形式に切り替えないのはなぜですか、同じことが他の名前にも当てはまります。 mkdirの代わりにmake_directoryと書いてもかまいません。
人々はこの質問が以前に尋ねられたことを示唆していますが、私が見つけた質問は、省略された名前が悪い習慣であるかどうかについてです。この質問は、この質問に対する回答が通常は「はい」であると想定しています。
しかし、なぜpythonのような現代の言語がC言語のapiの読みにくい名前を使用し続けるのでしょうか？
（ドメイン内の）全員が短い名前を知っているからです。別の名前を付けた場合、人々は「これが
mkdirと何が違うのか？」そして、一般的に、物事が彼らが期待するものではないことを混乱させます。IDEでオートコンプリートを使用しないと、長い名前は、一般に_のような熟練したプログラマーのように文字を入力するのが難しいためです。イライラするプログラマーは言語の採用を制限します。つまり、デザイナーが名前を付けなかったり、離陸したことがないので、それらを使用した言語について聞いたりしません。
もちろん、これらはどちらもちょっと薄っぺらな議論です。
最近では、読み取り可能なコードが書き込み可能なコードよりも優れていることが知られています。 IDEオートコンプリートハンドルオプション2を使用すると、IDEの肥大化や、プログラマーの能力を妨げる松葉杖に反対する人がいます。IDE intellisense（または同等のもの）は＃1の束にも役立ちますが、これは同じ引数を持ち、非オブジェクト指向の環境ではうまく機能しません。
それでも、これらの薄っぺらな議論（および人間味の気まぐれ）は、トレンドを維持するのに十分な勢いです。
なぜ私たちは男の子の名前として古いゲルマン語の「Albert」を使い続け、現代の英語の翻訳「Shining Hero」ではないのですか？
名前は単なるラベルだからです。新しいものに意味のある名前を付けるのは良いことですが、長い間使用すると名前自体が意味を持ちます。
printfは、世代のプログラマに固有の何かを意味します。2桁の数字をどこに印刷するかを示すために%2dを使用するテンプレートを備えた印刷関数などです。
一方、print_formatは、何らかの形でデータをフォーマットして出力する関数を示します。その使用方法を見つけるには、ドキュメントを検索する必要があります。
それは簡単です。伝統的な名前を使用すると、何百万人もの経験豊富なプログラマにとって便利です。 「mkdir」と「printf」の意味を知っています。初心者には少し不便ですが、すぐに乗り越えられます。
同様に、ほとんど（すべて？）のLISP方言は、「head」と「tail」の代わりに「car」と「cdr」を引き続き使用します。
他の人がすでに述べたように、これらのキーワードの多くは十分に確立された意味を持ち、新しい言語などをピックアップすることを非常に簡単にします。そして、 'eokjgv'がmake_directoryの関数になります。
短い名前は、オートコンプリートに依存する必要がないだけでなく、実際の利点もあります。
- より多くのコンテキストをより少ない行または単一の画面に収めることができます
- 厳密なコンピュータサイエンスの意味と共通言語の意味を一致させようとすることの混乱はありません
- 明確化の高速化：
print_formatted_string、print_formatted_string_from_file、print_string_with_lineを区別したい場合、printf、sprintf、println。
もちろん、慣性と文化も大きな要因です-一般的な言語では、あなたの質問は次のような質問に似ています：混乱する文法と膨大な語彙で、人々が英語ではなくエスペラントに切り替えないのはなぜですか
疑似コードを読み取ることで、詳細なプログラムを確認できます。いくつかの小さなメソッドの疑似コードを作成し、それに追加されるボリュームの量を確認します。また、人間の短期記憶も有限量であることを思い出してください。
「長い名前は読みやすくなる」というあなたの仮定は単に真実ではないからです！
逆に、名前が短いほど、アイコンのように名前を一度に識別できる可能性が高くなります（他の条件は同じです）。
しかし、それだけではありません。名前が長いほど、わずかな違いしかない識別子を混乱させる可能性が高くなります。
いつものように、中間点があります。 APIのパブリックメソッドは単一の文字であってはならず、一時的なローカル変数は詩であってはなりません。
必須のxkcdリファレンス：
言語、または既存の言語の次のバージョンを設計し、「古いCスタイルの名前を忘れてしまえば、もっといいアイデアがある」としましょう。 mkdirの名前をmake_directoryに変更します。同じ考え方に従って、他の誰かがcreate_directory、3つ目はcreate_dir、次はnew_directoryなどを発明します。プログラマーは、新しい言語や新しい方言を習得するのがはるかに難しくなりました。なぜなら、コマンドが何をするか、何を期待するかを即座に認識する代わりに、マニュアルを読む必要があるからです。同じ名前と構造を持たないことで、パラメーターの使用方法や順序が異なる可能性が高くなります（覚えているとしたら、.NETは最初にこれを好んで、いくつかのメソッドにはsource, destination、destination, sourceなど）。このバージョンでは、この言語のこの関数が使用しているパラメーターがわからないため、プログラマーが関数を使用するたびにマニュアルを読まなければならないため、プログラミングはエラーが発生しやすくなるか、はるかに遅くなります。
[〜＃〜] all [〜＃〜]の場合、言語設計者はallの将来の言語のCスタイル名をexactlyで変更することに同意することができます同じように、それを行うことには意味があるかもしれません。それを達成するために頑張ってください！
共通のルーツと文化遺産は理由もなくそこにはありません。
他の人が言ったように、これは主にC呼び出しのラッパーにすぎないことが主な理由です。そして、そのケース（短い名前を含む）の場合、大きな利点があります。基本的に、その言語を初めて使用するプログラマーは、それから何を期待するかを知っています。
私が見た場合：
printf（ "幅のトリック：％* d\n"、5、10）
（a）これは正当な理由があること、および（b）最大5スペースを使用できることを知っています。私が見た場合：
printf_formatted_string("Width trick: %*d \n", 5, 10)
私はそれを調べなければ、それが何を意味するのか分かりません。
短いCスタイルの名前は、この言語はCではないが、言語にはCの遺産があり、このprintfは、私たちの言語に適合した、私たちの由緒ある祖先のprintf関数を継承したものです。
Cは非常に基本的な言語であり、新しい言語は「Cスタイル」であると述べることで多くを得ることができます。
同様に、他の言語は、意図的にいくつかのタスクを実行するUnixの方法を組み込んで、同様の（または同一の）ことを実行するためにUnix名を採用することでそれを強化します。 Unixのchmodコマンドに精通していて、おそらく類似のAPIを使用して言語にchmodのような機能を実装している場合は、change_modeなどではなく、ご使用の言語でchmodを呼び出す方がよいでしょう。これは、Unixエクスペリエンスを再利用できることを意味します
一部の人々は、あなたが言語で頻繁に行うかもしれないことはより短い名前を持つべきだと信じています。
有用なことを行うには、すべての言語がオペレーティングシステムと対話する必要がありますが、これらの言語に定義されたAPIがないため、すべての言語がOSを直接呼び出すわけではありません。たとえば、POSIXは、CおよびAdaにバインドするAPIのみを定義します。
OSの非常に重要な部分は、少なくともPOSIXが定義された後、OSのAPIを実装するCライブラリ（libc）です。 POSIXは基本的に、既存のlibcs実装に基づいて定義されました。
言語に言語固有のAPIがない場合は、libcで使用可能な関数を使用する必要があります。次に、libc関数名を変更するか再利用して、それをライブラリーとしてエクスポートするかどうかは、言語デザイナー次第です。
仮想マシンで実行される言語（jvmのようにvm）には同じ問題はないはずです（それが本当に問題である場合）。