web-dev-qa-db-ja.com

構文はプログラミング言語で本当に重要ですか？

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

それについてのあなたの意見を知りたいです。

免責事項：私は議論を始めるつもりはありません。これは良い議論だと思いました。

更新：これは良いトピックです。皆さんも参加してくれてうれしいです。

programming-languagessyntax
41
Saif al Harthi

はい、そうです。疑わしい場合は、 [〜＃〜] apl [〜＃〜] 、または [〜＃〜] j [〜＃〜] 、または- Brainfuck 、または単純で単純なLISPまたはForthでさえ、完全ではないプログラムを理解するようにしてください。次に、例えばPython。

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

all状況では、毛深い構文は良くなく、自然言語のような構文は良いと言っているわけではありません。しかし、あいまいな構文doesは大きな違いをもたらします。全体として、最も美しいプログラミング言語で記述できるものはすべて、チューリングマシンプログラムとしても記述できますが、通常はそうしたくないのでしょうか。

65
9000

実際には問題だと思います。読みやすさについてはすでに上で説明しました。別の問題は、アイデア/アルゴリズムを表現するために必要なキーストロークの数です。さらに別の問題は、単純なタイプミスが人間の目で簡単に見つけられないことと、それがどれほどのいたずらを引き起こすかです。

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

11
Omega Centauri

はいといいえ。

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

  • 読みやすさ
  • 表現力
  • 解析性

読みやすさについてはすでに触れました。

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

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

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

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

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

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

(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++の例にはいくつかのタイプのメタデータが含まれています。高次関数を渡すというアイデアを最もよく表すのはどの言語ですか？一般的なLISPは構文上の変更をほとんど行いません。 C++では、関数を「実行」するためだけにクラスを作成する必要があります。 Perlは、あるレベルの差別化を行うことはかなり簡単です。 Pythonも同様です。

問題の領域に最適なアプローチはどれですか？ 「インピーダンスミスマッチ」を最小限に抑えて、頭の中で考えを最もよく表すことができるアプローチはどれですか。

パーサビリティは-私の心の中で-大したことです。特に、IDEを使用して、エラーを発生させることなく言語を解析およびチョップする機能に言及します。再フォーマットは便利です。トークン区切りの言語は、Ruby/c/Pascalなどを適切に解析する傾向があります。

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

7
Paul Nathan

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

Dylanの場合、より一般的なものを優先してS式を削除すると、より幅広いプログラマーを引き付けるのに役立つと考えられていました。プログラマーがLISPを使用するのを妨げているのは構文だけではないことがわかりました。

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

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

5
Larry Coleman

構文は間違いなく重要ですが、直感的でなく、バ​​グを助長するときに、より気づく傾向があります。たとえば、悪名高い「世界で最後のバグ」の冗談です。

if (AlertCode = RED)
   {LaunchNukes();}
5
Mason Wheeler

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

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

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

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

3
Rei Miyasaka

これは、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の構文は、上記よりもlot more syntaxがあるため、（もしあれば）読み取りのみ可能であることに注意してください。したがって、LISPのファンが「構文は重要ではない」と言った場合は、結果を求めてSKI計算を試してください。彼らはビット構文が結局それほど悪くないことを認めなければならないでしょう。

1
Ingo

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

1
IAbstract

reallyが重要なのはAPIアクセスであり、必要に応じて低レベルの機能（メモリ制御やロックなど）を利用できるかどうか。他のほとんどの言語には、これらの機能が含まれています。問題は、必要なときに追加機能を実装するためにCなどの言語を使用する必要があることです。また、Cと使用している言語とのインターフェースが面倒です。

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

1
unixman83

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

1
kevin cline

はい、そうです。

大きな炎を起こしたい場合は、オープニングブラケットをCのような言語でどこに置いたかを聞いてください。というのは

void foo() {
  // blah
}

VS

void foo()
{
  // blah
}

またはVS

void foo() 
{ // blah
}

そして、これはまったく同じ言語です！また、それらを配置する場所（関数名と括弧、演算子など）についても尋ねます。

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

0
ern0

構文を学ぶ人にとって重要なのは、参入障壁が低いほど、言語の人気が高まる可能性があることです。しかし、その言語があなたの自己を豊かかつ簡潔に表現することが困難または不可能である場合、その人気は衰退し始めます。

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

バランス、参入障壁の低下、高い生産性、簡単なメンテナンスが必要です。

0
user7519

個人的な好み以上に重要だとは思いません。すべてのこと（パフォーマンス、機能など）が等しい場合、言語構文に重点を置くのに、c/c ++などの言語のパフォーマンスを引き継ぐことを選択した理由がわかります。構文は、全体的に悪い考えのように思えます。

0
Kurtis

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

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)
0
Lennart Regebro

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

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

つまり、それがtoo verboseの場合は、読みやすさに影響するポイントに到達する可能性があります。私は次のようなものを見たいと思います：

foreach（stringList内の文字列）

に：

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

...いつでも！

0
berry120