プログラミング言語では構文は本当に重要ですか？[閉まっている]

私の教授の一人は、「構文はプログラミング言語のUIです」と言います。Rubyのような言語は読みやすく、成長していますが、C \ C ++で生産性の高いプログラマーが多いので、プログラマーは本当に構文が重要です受け入れられるべきですか？

私はあなたの意見を知りたいです。

免責事項：私は議論を始めようとはしていません。これは議論の良いトピックだと思いました。

更新：これは良いトピックであることが判明しました。みなさんが参加してくれてうれしいです。

はい、そうです。疑わしい場合は、APL、J、またはBrainfuck、あるいは単純で単純なLispまたはForthを使用して、完全に些細ではないプログラムを理解してください。次に、たとえばPythonと比較してください。

次に、同じPython（またはRuby、またはC＃）をCobolやVB6 などと比較します。

私は、毛むくじゃらの構文が悪いと言って、自然言語のような構文がすべての状況で良いと言うつもりはありません。しかし、わかりにくい構文は大きな違いを生みます。全体として、最も美しいプログラミング言語で記述できるものはすべて、Turingマシンプログラムとして記述することもできますが、通常はしたくないでしょうか。

実際には、それは重要だと思います。可読性についてはすでに上で議論されています。別の問題は、アイデア/アルゴリズムを表現するためにいくつのキーストロークが制限されるかです。さらに別の問題は、単純なタイプミスが人間の目を引くのがどれほど簡単であるか、そしてそれらがどれほどのいたずらを引き起こす可能性があるかです。

また、一部のコンテキストでは、別のコンピュータープログラムを介してコードのフラグメントを分析したり、生成したりするのに役立つことがわかりました。言語の解析、および/または正しいコードの生成の難しさは、そのようなツールを作成/維持するために必要な労力に直接影響します。

あなたの教授はシンタクティックシュガーについて言及していると思います。

構文糖は、物事を読みやすく、または表現しやすくするように設計されたプログラミング言語内の構文を指すコンピューターサイエンス用語であり、それらを表現する別の方法が存在します。

あなたの教授が示唆しているのは、あるプログラミング言語で書かれたコード/構文は、他の言語でもまったく同じ、あるいは同じ言語でも表現できるということです。

構造化プログラミングの定理から引き出されたロバート・マーティンは、RailsConf 2010での基調講演でプログラマーが基本的にプログラミング言語で行うことを抽象化しました。

• シーケンス（割り当て）
• 選択（ifステートメント）
• 反復（do-loops）

それは、すべてのプログラマーが、あるプログラミング言語から別のプログラミング言語まで、単に異なる構文またはユーザーインターフェイス（UI）で行うことです。教授がプログラミング言語について抽象的な話をしている場合、これは私が推測していることです。

そうで本質、構文は重要ではありません。しかし、具体的になりたい場合は、明らかに特定の言語と構文が特定のタスクに他のタスクよりも適しているため、構文が重要であると主張できます。

はいといいえ。

構文にはいくつかの異なる側面があります。

• 読みやすさ
• 表現力
• 構文解析

読みやすさはすでに言及されています。

表現力は興味深いケースです。関数受け渡しを例として使用します。これは、セマンティック/構文の痛みの変曲点のようなものだからです。

C ++を例にとってみましょう。この方法の後に一次関数を作成できます。

class funcClass
{
  int operator()(int);
}
funcClass fun;

void run_func(funcClass fun)
{
   fun();
}

この特定のイディオムは、Stepanovのプログラミングの要素で一般的に使用されています。

一方、Common Lispでは次のようなものでそれを模倣できます：

(defun myfunc() )

(defun run_func(fun)
  (fun))

または、Perlで-

   sub myfunc
   {
   }

   sub run_func
   {
      my $func = shift;
      $func->();          #syntax may be a little off.
   }

または、Pythonで-

def myfunc():
    pass

def run_func(f):
    f()

これらはすべて-基本的に-同じセマンティックコンテンツを持っていますが、C ++の例にはいくつかのタイプのメタデータが含まれています。どの言語が高次関数を渡すという考えを最もよく表現していますか？Common Lispはほとんど構文上のバリエーションを作成しません。C ++では、関数を「実行」するためだけにクラスを作成する必要があります。Perlは、ある程度の差別化については非常に簡単です。Pythonも同様です。

問題領域に最適なアプローチはどれですか？「インピーダンスの不一致」を最小限に抑えて、頭の中で考えを表現できるアプローチはどれですか？

パース可能性は-私の考えでは-大したことです。特に、エラーを起こさずに言語を解析および切断するIDEの機能を参照します。再フォーマットは便利です。トークンで区切られた言語は、ruby / c / pascalなど、適切に解析される傾向があります。

ただし、実際の問題を解決するために、あらゆる種類の主要なシステムがあらゆる深刻な言語で作成されています。構文はいくつかのことを表現するための障壁ですが、回避可能な障壁です。チューリングの等価性とすべて。

構文は間違いなく重要ですが、直感的ではなく、バグを助長する場合は、構文に気付く傾向があります。たとえば、悪名高い「世界の最後のバグ」ジョーク：

if (AlertCode = RED)
   {LaunchNukes();}

構文は重要であり、2つのサポート例を示します。より一般的な構文を持つLispであるDylanと、Lispに似た構文を持つHas​​kellであるLiskellです。それぞれのケースで、まったく同じセマンティクスを持ちながら、根本的に異なる構文を持つ言語の変形が提案されました。

Dylanの場合、より一般的なものを支持してs式をドロップすると、より広範なプログラマを引き付けるのに役立つと考えられていました。プログラマーがLispを使用するのを妨げるのは構文だけではないことが判明しました。

Liskellの場合、s-expressionを使用すると、マクロを簡単に使用できると考えられていました。Haskellではマクロは実際には必要ないため、実験も機能しませんでした。

構文が誰にとっても重要でなければ、どちらの実験も試みられなかったでしょう。

答えは、「問題」をコンピューター要因と人的要因に分離することです。構文には多くの人的要因があります。

• 読みやすさ
• 簡潔さ
• 保守性
• 教育学
• エラー防止
• 目的に対する適切性-REPL言語、スクリプト言語、または大規模システム言語ですか？

コンピューターに関する限り、構文の唯一の問題は、解決する必要があるあいまいさが存在するかどうか、およびコンパイル/解釈時にコードをトークン化/解析するのにかかる時間です-そしてそれはその場合のみです後者の場合、解析のオーバーヘッドが重要な問題です。

そのため、この質問には常に「はい」と「いいえ」の回答が返されます。これには2つの側面があるためです。

構文がなければ、コードブロックの意図を人間レベルで伝達するための共通の「テンプレート」はありません。構文は、コンパイラを標準化できる共通のフレームワークを提供します。メソッドを共有できます。メンテナンスを簡素化できます。

私が何を考えて、本当に重要なのであるAPIへのアクセスに必要なとき、および（メモリ制御とロックのような）低レベルの機能を利用できます。他のほとんどの言語には、これらの機能が含まれています。問題は、追加機能が必要な場合、Cのような言語を使用して実装しなければならないことが多いことです。また、Cを使用している言語とインターフェイスさせるのは面倒です。

Web開発（および数学）以外のすべてについて、C / C ++は依然としてオペレーティングシステムとアプリケーションの言語であることがわかりました。真のマルチスレッド、プリフォーミング、クロスプラットフォームアプリケーション開発のために、ほとんどの場合サポートされています。そして、Cの構文は大丈夫です。とてもシンプルで比較的冗長です。驚くべき構文はそれほど重要ではありません。パワーとAPIの可用性誰もが他の人のコード（ほとんどの場合Cまたはその派生物で記述されています）とのインターフェースをとる必要があります。

構文は間違いなく重要です。言語構文に柔軟性があり、アプリケーションに便利で読みやすいドメイン固有言語を作成できるようになれば、非常に貴重です。これを疑う場合は、18世紀以前に行われたように、平凡なラテン語で代数問題を行うことを想像してください。もちろん、微積分のテキストは初心者には読めませんが、実際には、微積分とライプニッツ表記法を使用して、古典的な方法で数学のページを必要とする問題のクラスをすばやく解決できます。プログラミングは数学のほんの少しです。問題領域に近い便利な表記法は、生産性に大きな違いをもたらします。

6の学部を計算するプログラムは次のとおりです。

S(K(S(S(SI(KK))(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)
(S(KS)(S(K(SI))K))))(KK)KK))))))(S(K(S(S(K(SI))(SII)(S(K(SI))(SII))
(S(K(S(S(KS)(S(KK)(S(SI(KK))(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)KK)))))))
(S(K(S(S(KS)(S(K(SI(KK)))(SI(K(KI)))))))(S(K(S(K(S(S(K(SI))(SII)(S(K(SI))
(SII))(S(K(S(S(KS)(SI(KK)))))(S(S(KS)(S(K(S(KS)))(S(K(S(KK)))(S(S(KS)K)
(K(SI(K(KI))))))))(K(K(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)))))))))))
(S(S(KS)K)(K(SI(K(KI)))))))))))(S(S(KS)K)(K(SI(K(KI))))))(S(S(KS)(S(KK)(S(KS)
(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)
(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)
(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)(KI)
(S(S(KS)(S(KK)(S(KS)(S(K(SI))K))))(KK)KK)))))))

構文は最小限です：

expression: expression term | term
term: ‘(‘ expression ‘)‘ | combinator
combinator: 'S' | 'K' | 'I' 

構文が言語を困難にするものであるという一般的な考えがあるようです。一般に信じられていることでよくあることですが、まったく逆のことが当てはまります。

LISP構文は、上記よりもはるかに多くの構文を持っているため、読み取り可能（あるとしても）のみであることに注意してください。そのため、LISPファンから「構文は重要ではない」と言われたら、結果を求めてSKI計算を試してください。結局、ビット構文がそれほど悪くないことを認めなければなりません。

個人的な好みを超えて問題になるとは思いません。すべてのもの（パフォーマンス、機能など）が等しい場合、言語構文に重点を置くが、c / c ++などの言語のパフォーマンスや、仕事に適した他の言語のパフォーマンスを単に引き継ぐことを選択する理由がわかります。構文はあちこちで悪い考えのように思えます。

はい、構文は重要ですが、実際には読みやすさのためだけです。比較する：

for i in range(10):
   print(i)

（ええ、それはPythonです）

FOR(i<-RNG-<10){PRN<-i}

（ええ、それは私が作った言語です）どちらもまったく同じことを同じ方法で行いますが、構文は異なり、Pythonは読みやすくなっています。はい、構文は間違いなく重要です。「構文糖」でさえ重要です。

 @property
 def year(self):
     return self._date.year

読みやすい

 def year(self):
     return self._date.year
 year = property(year)

うん、確かに。

大きな炎を起こしたい場合は、Cのような言語でオープニングブレースを配置する場所を人々に尋ねてください。というのは

void foo() {
  // blah
}

VS

void foo()
{
  // blah
}

またはVS

void foo() 
{ // blah
}

そして、これはまったく同じ言語です！また、スペース、それらを配置する場所（関数名とブレース、演算子など）について質問します。

1000の答えが保証されています！

構文は重要です。しかし、この日と年齢では、ほとんど完全に読みやすさのために重要であり、実際に必要なキーストロークの量の点ではないと思います。どうして？

• 本当に簡単なものを書いているのでなければ、押すキーの数がプログラムを書く際の制限要因であるなら、あなたは本当に、本当にタイピングするのが面倒であるか、あまりにも早く考えすぎます。
• 最近のすべての適切なIDEには多数のショートカットがあるため、ほとんどの場合、実際に使用しているすべての文字を入力する必要はありません。

とはいえ、冗長すぎると読みやすさに影響を与える可能性があります。私は次のようなものを見たいです：

foreach（stringListの文字列）

に：

stringlist変数によって参照されるリストにあるすべての文字列

...いつでも！

構文はそれを学んでいる人にとって重要であり、エントリーに対する障壁が低いほど、最初はその言語がより一般的になります。しかし、あなたの自己を豊かにそして簡潔に表現するのが難しいか不可能であるなら、それは人気が衰え始めるでしょう。

非常に簡潔で不透明（Perl）は、過度に冗長で冗長な（AppleScript）と同じくらい悪いです。

バランス、参入障壁の低下、生産性の向上、メンテナンスの容易さが必要です。

考慮すべきもう1つのことは、より優れた構文を備えたプログラミング言語は解析が容易であるため、コンパイラの記述が容易になり、高速で、バグが発生しにくくなることです。

簡単に言うと、構文自体は重要ではありません。それを介して表現できるセマンティクスは重要です。