シンタクティック シュガー (IMHO) を使用すると、一般に、非常に最小限のプリミティブ セットからコーディングするよりも、プログラムがはるかに読みやすく、理解しやすくなります。良く考え抜かれたシンタックス シュガーのマイナス面はあまり見当たりません。基本的に、構文糖衣はせいぜい不必要であり、最悪の場合は避けるべきものだと考える人がいるのはなぜですか?
編集:名前を付けたくありませんでしたが、人々が尋ねたので、たとえば、ほとんどの C++ および Java プログラマーは、率直に言って、言語の構文糖衣の完全な欠如を気にしていないようです。多くの場合、砂糖の不足をトレードオフに値するほど言語の他の部分が好きであるとは限りません。それは、彼らが本当に気にしないことです. また、Lisp プログラマーは自分たちの言語の奇妙な表記法をほとんど誇りに思っているようですが (技術的にそうではないため、構文とは呼びません)、この場合は、Lisp のメタプログラミング機能を同じくらい強力にすることができるため、より理解しやすいのです。
シンタックス シュガーはセミコロンの癌を引き起こします。アラン・ペルリス
推論が文脈を参照せずに行われる場合、シンタックス シュガーについて推論することは困難です。なぜ「シンタックス シュガー」が良いか悪いかについてはたくさんの例がありますが、それらはすべて文脈がなければ意味がありません。
シンタックス シュガーは、プログラムを読みやすく理解しやすくするときに優れているとおっしゃいました...そして、シンタックス シュガーが言語の形式的な構造に影響を与えることがあると言うことに反論できます。プログラミング言語の。
糖衣構文の観点から考えるのではなく、読みやすさと理解の容易さを促進する適切に設計された言語と、設計の悪い言語の観点から考えるのが好きです。
よろしく、
シンタックス シュガーは、場合によっては不快な方法で相互作用する可能性があります。
いくつかの具体的な例:
1 つ目は、C# (または Java) 固有のオート ボクシングとロック/同期コンストラクトです。
private int i;
private object o = new object();
private void SomethingNeedingLocking(bool b)
{
object lk = b ? i : o;
lock (lk) { /* do something */ }
}
この例では、任意のオブジェクトを同期ポイントとして使用できる便利なロック構成が、オートボクシングと組み合わされているため、バグが発生する可能性があります。ロックは、i の新しいボックス化されたインスタンスで毎回取得されます。ロック構造が役に立ちすぎていること、およびロックする他の特定の構造の方が優れていることは議論の余地がありますが、確かにその組み合わせにはまだ欠陥があります。
複数の変数宣言とポインター:
long* first, second;
古典的なバグ (見つけやすいですが)。複数の変数のシュガーは、ポインター宣言に適合しません。
一部のコンストラクトは、問題を引き起こすために砂糖の他の側面を必要としません。典型的な例は ++ 演算子です。それはきちんと書くことを避けることができます
i = i + 1;
広く使用されている構造 (および i の使用から変更したい場合は、両方の変数を忘れずに更新する必要があるため、それ自体がバグの可能性がある構造) です。ただし、これは他の式に簡単に埋め込むことができるため、接頭辞と接尾辞の問題が頭をよぎります。for ループ内で使用する場合、これは問題ではありません。評価は他の評価の外側で行われますが、他の場所で使用すると、混乱の原因になる可能性があります (計算の非常に重要な側面を埋め込む可能性があるため (現在または次のいずれか)値を使用する必要があります) を非常に小さく、見逃されやすい形式にします。
上記のすべて (コンパイラーが実際に見つけなければならないロック/ボックスを除く) は、使用方法が問題ないか、経験豊富なプログラマーが「それは私には完全に明らかだ」と考えるかもしれませんが、混乱の余地が確かに存在する場合です。初心者のプログラマーや、別の構文に移行する人向けです。
不必要な砂糖が多すぎると、言語が肥大化するだけです。私は名前を挙げましたが、それではただ炎上しました。:) また、実際の実装を行う代わりに、言語が構文糖衣を使用することもあります。たとえば、「ジェネリック実装」がシンタックス シュガーの薄い層にすぎない名前のない言語があります。
一般に、構文は言語の習得を困難にし、ましてや習得を困難にします。したがって、構文のセットが小さいほど、習得しやすく、習得しやすくなります。これが、多くの新しい言語が人気のある既存の言語から構文を借用する主な理由です。
また、なんらかの理由で興味のない特定の機能を学ぶことを避けることはできますが、最終的には、その機能が好きな他の人のコードを読んでいることに気づき、その機能を理解するためだけにその機能を学ぶ必要があります。コード。
シンタックス シュガーは、プログラムをより理解しやすくしたり、理解しにくくしたりします。些細なことに構文糖衣を追加すると、言語がより複雑になるため、認知的負担が増えるだけです。一方で、特定の概念を特定して強調するために何とか達成する構文糖衣を追加できれば、勝つことができます。
おそらく、舞台裏で実際に何が起こっているのかを知らないプログラマーの混乱につながり、非効率的または不十分に記述されたコードにつながる可能性があるためです。 " また。
それはより多くのタイピングと抽象化のより多くのレイヤーです。私はむしろ、他の言語に組み込まれている機能を模倣するという貧弱な仕事をするために、構文糖衣を付けた言語よりも高いレベルの抽象化を持つように設計された言語を使用したいと考えています.