プログラミング言語は厳格か緩いか？
PythonおよびJavaScriptでは、セミコロンはオプションです。
PHPでは、配列キーを囲む引用符はオプションです（$_GET[key]対$_GET['key']）、ただしそれらを省略すると、最初にその名前で定数を探します。また、ブロックに対して2つの異なるスタイルを使用できます（コロンまたはブレース区切り）。
私は現在プログラミング言語を作成しています。私はそれをどれだけ厳密にすべきかを決定しようとしています。余分な文字が実際には必要なく、優先順位のために明確に解釈できる場合がたくさんありますが、一貫性を保つためにそれらを強制する必要があるのかどうか疑問に思っています。
どう思いますか？
さて、私の言語は、派手なテンプレート言語ほどプログラミング言語ではありません。 Haml と Djangoテンプレート の間の一種のクロス。私のC＃Webフレームワークで使用されることを意味し、非常に拡張可能であると想定されています。
言語の種類によって使用方法が異なるため、この質問に対する答えは、実際に使用する目的によって異なります。
たとえば、Perlは非常に緩い言語であり、簡単な修正や数値処理スクリプトを書くのに非常に便利です。堅牢なプロジェクトでは、C＃を使用します。
あなたは、ターゲットの使用量に適切なバランスをとる必要があります。厳密であるほど、コードの記述に費やす時間が長くなりますが、堅牢性、再利用性が向上し、保守が容易になります。
（スクリプト言語ではなく）プログラミング言語で私が探しているのはconsistencyと強い型付けです。
現在のプログラミング言語では、あいまいになることなく、たとえば特定の場所でセミコロンを省略できます（{}ブロックの最後の式は1つです）。これらの場合にプログラミング言語で文字を省略できる場合、プログラマーは特別な問題を抱えています。一般的な言語構文に加えて、彼女は今、構文の一部を省略することも許可されているケースを知る必要があります。
この余分な知識は、プログラマーがコードを書くのに問題はありませんが、後で既存のコードを解釈しなければならない人（しばらくしてから元の作者を含む）にとって負担になります。
あなたのPHPの例は、定数keyが同じコンテキストで追加される場合、プログラムに微妙なバグが発生する可能性を開きます。コンパイラはそれが何であったかを知る方法がありませんつまり、問題はコンパイル時ではなく実行時にのみ明らかになります。
あいまいさが存在するすべての場所で、コンパイラーは、プログラマーが実際に何を意味するのかを推測する何らかの方法を持つ必要があります。これが発生するたびに、プログラマーが実際に別の意味を持っている可能性がありますが、あいまいさの解決ルールはありませんでした。
論理的に正しいコードを書くことはすでに十分に困難です。構文のあいまいさを追加することは、表面上は「友好的」に見えるかもしれませんが、コードベースにデバッグするのが難しい、予期しない、新しいバグを導入するためのオープンな招待状です。結論として、できる限り厳密に。
あなたの例から、セミコロンはPythonおよびJavaScriptでは省略可能であると述べました。JavaScriptの場合、少なくとも、これは完全には当てはまりません。セミコロンは、他のCと同じようにJSでも必要です。ファミリー言語ですが、JavaScriptパーサーは、特定の状況下で不足しているセミコロンを挿入するために言語仕様で必要とされます。 これは非常に悪いこととして広く見なされています 意図が間違ってコードが台無しになる傾向があるため。
あなたの言語をどれだけ緩くすべきかという答えは、テキサスのアクセントで言った「パンクはどれほど幸運だと感じていますか？」という質問の答えと同じです。
言語にあまりバリエーションがないのであれば、コーディングの一貫性のために誰もがそれほど努力する必要はありません。ユーザーが不必要に複雑さを増す要求をするとき、私たちはそれを好きではありません、それでなぜ私たちの開発言語についてそれを尋ねられるべきなのでしょうか？
私の個人的な好みは、タイプミスを検出するのに十分な厳格さを持つ能力ですが、余分なボイラープレートはできるだけ少なくします。この問題について http://www.perlmonks.org/?node_id=75579 で話します。
とはいえ、自分で言語を設計していることになります。あなたはそれをあなたが望むものにしてください。
私は一般的に「プログラマーとして私にとって何が簡単になるのか」という側面に陥る傾向があります。もちろん、これには複数の意味があります。 Javascriptには型チェックがほとんどないため、奇妙なバグに遭遇するまではうまく機能します。一方、Haskellには多くの型チェックがあり、より多くの作業を先行させますが、いくつかのクラスのバグを隠します。
正直に言うと、たくさんの言語を調べてそれらが何をするのかを確認し、誰もヒットしないニッチを見つけようとします！
それを行うための明確な正しい方法が1つあるとは思いません。少なくとも、人々がまだコンセンサスを見つけたものがない場合は。したがって、さまざまな型システムを使用して言語を作成することで、学習しています。
幸運を。
私は自分の言語が私が意味することをするのが好きです。一般的に、それは緩い方向にかなり傾いています。また、要素またはブロックに「strict」のタグを付けて、その限られた領域をデバッグ/分析できるようにしたいと考えています。
良いプログラミング言語には厳密なルールが必要であり、その実装では一貫して適用されることが期待されますが、ルールは役立つようにそのような方法で作成する必要があります。さらに、2つの実質的に異なるプログラム間の「ハミング距離」が1つだけである場合を避けるために、言語の設計を検討することをお勧めします。明らかに数値リテラルまたは文字列リテラルではそのようなことはできません（123を意味するプログラマーがタイプ1223または13を代わりに使用する場合、コンパイラーはプログラムの意味をよく理解できません）。一方、言語が:=を割り当てに使用し、==を等価比較に使用し、単一の=を法的目的に使用しない場合、両方の可能性が大幅に減少します。比較であるはずの偶発的な割り当てと、割り当てであるはずの偶然の何もしない比較。
コンパイラーが物事を推論するのに役立つ場所はありますが、そのような推論は最も単純な場合に最も価値があり、より複雑な場合にはあまり価値がないことをお勧めします。たとえば、次のものの置き換えを許可します。
辞書<complicatedType1、complicatedType2> item = 新しい辞書<complicatedType1、complexType2（）>;
と
var item = new Dictionary <complicatedType1、complexType2（）>;
複雑な型推論を必要としませんが、コードを非常に読みやすくします（とりわけ、必要なシナリオでのみ、より詳細な構文を使用します。たとえば、格納場所の型が式の型と正確に一致しないためです）それを作成すると、それを必要とする可能性のある場所に特別な注意を喚起するのに役立ちます）。
より洗練された型推論を試みる際の1つの大きな困難は、あいまいな状況が発生する可能性があることです。良い言語は、プログラマーがコンパイラーにそのようなあいまいさを解決するために使用できる情報を含めることを許可し（たとえば、いくつかの型キャストを他のものよりも好ましいと見なすことにより）、それらが問題ではないと判断することを提案します（たとえば、2つの可能性があってもオーバーロードは異なるコードを実行する可能性があります。プログラマーは、どちらかを使用できる場合でも同じように動作するか、上記のいずれの方法でも処理できないもの（およびそれらのみ）にフラグを立てる必要があることを示しています。
私にとって、読みやすさは最も重要です。
言語を経験した人にとって、コードフラグメントの意味は、コンテキストを深く分析することなく明確になるはずです。
言語は、間違いをできるだけ頻繁に報告できる必要があります。すべてのランダムな文字シーケンスが構文的に正しいプログラムを作成する場合、それは役に立ちません。また、変数が初めて使用されるときに自動的に作成される場合は、clientをcleintと間違って入力しても、コンパイルエラーは発生しません。
構文の他に、言語には明確に定義されたセマンティクスが必要であり、まともな構文を決定するよりも難しいかもしれません...
良い例：
Javaでは、
"1"は文字列、1はint、1.0はdouble、1Lはlongです。一見して、あなたはそれが何であるかを知っています。Javaでは、
=が割り当てです。プリミティブ型の値と参照型の参照を割り当てます。複雑なデータをコピーしたり比較したりすることはありません。Javaでは、メソッドの呼び出しには括弧が必要ですが、この方法は変数とは明確に区別されます。したがって、括弧がない場合は、メソッド定義を検索する必要はなく、データを読み取るだけです。
悪い例：
Javaでは、
clientのようなシンボルは、パッケージパス要素、クラスまたはインターフェイス名、内部クラス名、フィールド名、メソッド名、ローカル変数など、ほとんど何でもかまいません。命名規則を導入するか、それに従うかは、ユーザー次第です。Javaでは、ドット
.は使いすぎです。これは、パッケージ名内のセパレーター、パッケージとクラス間のセパレーター、外部クラスと内部クラス間のセパレーター、インスタンス式とインスタンスで呼び出されるメソッド間のコネクターなどにすることができます。多くの言語では、
ifブロックの波括弧はオプションであり、誰かが（実際には存在しない）ブロックにステートメントをもう1つ追加すると、厄介なミスが発生します。中置演算子：場合によっては、数式で停止して、それが何を意味するのかを段階的に検討する必要があります。私たちは皆、
a * b / c * d + eのような中置記法で数式を書くことに慣れています。ほとんどの場合、加算と減算よりも乗算と除算の優先順位を覚えています（ただし、c*dで除算するのではなく、cだけで除算してからd？）。しかし、独自の優先ルールといくつかの言語ではオーバーロードする追加の挿入演算子が非常に多くあり、追跡するのが困難です。おそらく括弧の使用を強制する方がより良いアプローチでした...