プログラミング言語で直面した最大の設計上の欠陥は何ですか？[閉まっている]

すべてのプログラミング言語に設計上の欠陥があるのは、他のほとんどの（すべて？）それはさておき、プログラミング言語のどの設計上の欠陥がプログラマとしてのあなたの歴史を通してあなたを最も悩ませましたか？

特定の目的のために設計されていないという理由だけで言語が「悪い」場合は、設計上の欠陥ではなく、設計の機能なので、そのような煩わしさを挙げないでください。言語がその設計目的に適していない場合、それはもちろん設計の欠陥です。実装固有のことや内部的なことも考慮されません。

私の大きな悩みの1つは、switchを使用するのを忘れた場合、C派生言語のケースがデフォルトで次のケースにフォールスルーする方法breakです。これは非常に低レベルのコード（例：Duff's Device）では有用ですが、通常はアプリケーションレベルのコードには不適切であり、コーディングエラーの一般的な原因であると理解しています。

1995年頃、私が初めてJavaの詳細について読んでいたときのことを思い出します。switch声明に関する部分に到達したとき、デフォルトのフォールスルー動作を保持していたことに非常に失望しました。これは単に別の名前でswitch栄光gotoをもたらします。

私は、C派生言語での=割り当てと==同等性のテストの使用が本当に好きではありませんでした。混乱とエラーの可能性が高すぎます。また===、Javascriptで始めてはいけません。

:=割り当てと=平等性テストの方が良かったでしょう。セマンティクスは、割り当ても値を生成する式である現在とまったく同じである可能性があります。

+Javascriptでの追加と文字列連結の両方の選択は、ひどい間違いでした。値は型付けされていないため+、各オペランドの正確な内容に応じて、追加するか連結するかを決定するビザンチン規則になります。

$文字列の連結など、まったく新しい演算子を導入することは最初から簡単だったでしょう。

Javascriptはデフォルトで主要な問題に対してグローバルになり、JSLintなどを使用しないとバグの原因になることがよくあります

CおよびC ++のプリプロセッサは大がかりで、ふるいのように漏れる抽象化を作成し、ラットの#ifdefステートメントのネストを介してスパゲッティコードを奨励ALL_CAPSし、その制限を回避するために恐ろしく読めない名前を必要とします。これらの問題の原因は、構文レベルまたは意味レベルではなくテキストレベルで動作することです。さまざまなユースケースのために、実際の言語機能に置き換える必要がありました。以下に例を示しますが、これらのいくつかはC ++、C99、または非公式ではあるが事実上の標準の拡張機能で解決されています。

• #include 実際のモジュールシステムに置き換える必要がありました。

• インライン関数とテンプレート/ジェネリックは、ほとんどの関数呼び出しのユースケースを置き換えることができます。

• ある種のマニフェスト/コンパイル時定数機能を使用して、このような定数を宣言できます。 enumのDの拡張は、ここで素晴らしい働きをします。

• 実際の構文ツリーレベルマクロは、さまざまなユースケースを解決できます。

• 文字列ミックスインは、コードインジェクションのユースケースに使用できます。

• static ifまたはversion条件付きコンパイルにステートメントを使用できます。

数百の言語で数百の間違いをリストすることもできますが、IMOは言語設計の観点からは有用な演習ではありません。

どうして？

ある言語の間違いとなるものは、別の言語の間違いではないからです。例えば：

• Cをマネージ（つまり、ガベージコレクション）言語にするか、プリミティブ型を拘束すると、セミポータブルな低レベル言語としての有用性が制限されます。
• Cスタイルのメモリ管理をJavaに追加すると（たとえば、パフォーマンスの問題に対処するために）壊れてしまいます。

学ぶべき教訓はありますが、教訓はめったに明確ではなく、それらを理解するには技術的なトレードオフと歴史的背景を理解する必要があります。（たとえば、ジェネリックの扱いにくいJava実装は、下位互換性を維持するためのビジネス要件をオーバーライドした結果です。）

あなたは新しい言語の設計を真剣に考えている場合はIMO、あなたが実際にする必要が使用して既存の言語の広い範囲を（および歴史的な言語を学ぶ）...と、ミスが何であるか、あなた自身の心を占めています。また、これらの各言語は、特定のニーズを満たすために、特定の歴史的背景で設計されたものであることに留意する必要があります。

学ぶべき一般的なレッスンがある場合、それらは「メタ」レベルにあります。

• すべての目的に理想的なプログラミング言語を設計することはできません。
• 間違いを避けることはできません...特に後から見た場合。
• 多くの間違いは修正するのが苦痛です...あなたの言語のユーザーにとって。
• ターゲットオーディエンスの背景とスキルを考慮する必要があります。すなわち、既存のプログラマー。
• みんなを喜ばせることはできません。

CおよびC ++：意味のないすべての整数型。

特にchar。テキストですか、それとも小さな整数ですか？テキストの場合、それは「ANSI」文字ですか、UTF-8コード単位ですか。整数の場合、符号付きですか、符号なしですか？

int 「ネイティブ」サイズの整数にすることを目的としていましたが、64ビットシステムではそうではありません。

longは、より大きくても大きくなくてもかまいませんint。ポインタのサイズである場合とそうでない場合があります。コンパイラの作成者は、32ビットか64ビットかにかかわらず、ほとんど任意の決定を下します。

間違いなく1970年代の言語。Unicodeの前。64ビットコンピューターの前。

null。

その発明者であるトニー・ホアは、それを「10億ドルの間違い」と呼んでいます。

60年代にALGOLで導入され、現在一般的に使用されているほとんどのプログラミング言語に存在しています。

OCamlやHaskellのような言語で使用されるより良い代替手段は、多分です。一般的な考え方は、オブジェクト参照がnull / empty / nonexistentになる可能性があることを明示的に示さない限り、オブジェクト参照をnull / empty / non-existentにすることはできないということです。

（トニーの謙虚さは素晴らしいものの、ほとんどの人が同じ間違いを犯し、たまたま彼が最初だったと思います。）

PHPを設計した人たちは通常のキーボードを使用していなかったし、colemakキーボードさえ使用していないと感じています。

私はPHP開発者です。PHPは入力するのが楽しくありません。

Who::in::their::right::mind::would::do::this()？::オペレータは、保持シフトしてから2キーの押下が必要です。なんてエネルギーの無駄。

ただし、-> this-> is-> not-> much-> better。また、2つの記号の間にシフトがある3つのキーを押す必要があります。

$last = $we.$have.$the.$dumb.'$'.$character。ドル記号は非常に多くの回数使用され、キーボードの一番上までの賞のストレッチに加えて、シフトキーを押す必要があります。

入力するのがずっと速いキーを使用するようにPHPを設計できないのはなぜですか？なぜwe.do.this()単一のキーを押すだけで必要なキーで変数を開始できないのか、またはまったくしない（JavaScript）で、すべての変数を事前に定義するだけです（とにかくE_STRICTで行う必要があります）！

私は遅いタイピストではありません-しかし、これは単なるデザインの選択に欠けています。

デスクトップの使用は、asp.net内のフォームに影響を与えました。

常にファッジを感じ、ウェブが実際にどのように機能するかを邪魔しました。ありがたいことにasp.net-mvcは同じインスピレーションを受けていますが、そのインスピレーションはRubyなどに与えられています。

私にとっては、PHPの標準ライブラリには命名規則と引数の順序付け規則が絶対に欠けています。

しかしJASS NULLIFY参照への必要性参照されたオブジェクトが削除/リリースされた（または参照が漏れなり、メモリの数バイトが失われてしまう）の後には、より深刻ですが、JASSは、単一の目的言語であることから、その重要ではありません。

私が直面する最大の設計上の欠陥は、pythonがpython 3.xのように設計されていなかったことです。

Cでの配列の崩壊、したがってC ++。

Javaのプリミティブ型。

それらはすべてがの子孫であるという原則を破り、java.lang.Object理論的な観点から言語仕様の追加の複雑さをもたらし、実用的な観点からはコレクションの使用を非常に退屈にします。

オートボクシングは実用的な欠点を軽減するのに役立ちましたが、仕様をさらに複雑にし、大きな太ったバナナスキンを導入することを犠牲にして、単純な算術演算のように見えるものからnullポインター例外を取得できます。

私はPerlを最もよく知っているので、それを選びます。

Perlは多くのアイデアを試しました。いくつかは良かった。いくつかは悪かった。一部はオリジナルであり、正当な理由で広くコピーされていません。

1つはコンテキストの概念です。すべての関数呼び出しはリストまたはスカラーコンテキストで行われ、各コンテキストでまったく異なることを実行できます。http://use.perl.org/~btilly/journal/36756で指摘したように、これはすべてのAPIを複雑にし、Perlコードでの微妙なデザインの問題を頻繁に引き起こします。

次は、構文とデータ型を完全に結び付けるという考え方です。これは、オブジェクトが他のデータ型になりすますことを可能にするタイの発明につながりました。（オーバーロードを使用して同じ効果を達成することもできますが、Perlではタイがより一般的なアプローチです。）

多くの言語が犯すもう1つのよくある間違いは、語彙的ではなく動的スコープを提供することから始めることです。後でこの設計上の決定を元に戻すことは難しく、長期にわたるいぼにつながります。Perlでのこれらのいぼの古典的な説明はhttp://perl.plover.com/FAQs/Namespaces.htmlです。これは、Perlがour変数とstatic変数を追加する前に書かれていることに注意してください。

人々は、静的タイピングと動的タイピングについて合法的に同意しません。私は個人的に動的型付けが好きです。しかし、タイプミスを捕らえるのに十分な構造を持つことが重要です。Perl 5はstrictでこれをうまくやっています。しかし、Perl 1-4はこれを間違えました。他のいくつかの言語には、strictと同じことを行うリントチェッカーがあります。あなたがリントチェックを実施することに長けていれば、それは受け入れられます。

より多くの悪いアイデア（それらの多く）を探しているなら、PHPを学び、その歴史を調べてください。私のお気に入りの過去のミス（非常に多くのセキュリティホールにつながるため、ずっと前に修正されました）は、デフォルトで、フォームパラメータを渡すことで誰でも任意の変数を設定できるようにしました。しかし、それは唯一の間違いではありません。

コードブロックとオブジェクトリテラルのJavaScriptのあいまいさ。

  {a:b}

aラベルおよびb式であるコードブロックです。またはa、値を持つ属性を持つオブジェクトを定義できますb

FORTRANとホワイトスペースの非感受性に戻ります。

仕様に浸透しました。ENDカードが適切に「END」と「E」、「N」、列7-72にこの順に「D」、および他のデータ有り無しではなく、カードとカードのように定義されなければなりませんでした列と他の何もない。

これにより、構文上の混乱が生じやすくなりました。 DO 100 I = 1, 10はループ制御ステートメントDO 100 I = 1. 10でしたが、値1.1をという変数に割り当てたステートメントでしたDO10I。（変数は、最初の文字に応じて型を宣言せずに作成できるという事実がこれに寄与しました。）他の言語とは異なり、トークンを区別するためにスペースを使用して曖昧さをなくす方法はありませんでした。

また、他の人が本当に紛らわしいコードを書くことができました。FORTRANのこの機能が二度と繰り返されない理由があります。

BASICの最大の問題の1つは、初期環境を超えて言語を拡張するための明確に定義された方法がないことであり、完全に互換性のない実装が多数発生します（そして、標準化における事後的な試みはほとんど無関係です）。

ほぼすべての言語は、狂ったプログラマーによって汎用的に使用されます。クレイジーなアイデアが生まれた場合に備えて、最初にその汎用的な使用法を計画することをお勧めします。

私はDSL（ドメイン固有言語）を信じており、言語で私が大切にしていることの1つは、その上でDSLを定義できるかどうかです。

Lispにはマクロがあります-私と同じように、ほとんどの人はこれを良いことだと考えています。

CおよびC ++にはマクロがあります-人々はそれらについて文句を言いますが、私はそれらを使用してDSLを定義することができました。

Javaでは、それらは除外され（したがってC＃では）、それらの欠如は美徳であると宣言されました。確かにそれはあなたがインテリセンスを持っていることを可能にしますが、私にとってはそれは単なる作品です。DSLを実行するには、手動で拡張する必要があります。それは苦痛であり、それは私がたくさんのより少ないコードでもっと多くのことをすることができるにもかかわらず、私を悪いプログラマーのように見せます。

ステートメントを含むすべての言語のステートメント。式ではできないことは何もせず、多くのことを実行できません。?:三項演算子の存在は、それらを回避しようとすることの1つの例にすぎません。JavaScriptでは、特に面倒です。

// With statements:
node.listen(function(arg) {
  var result;
  if (arg) {
    result = 'yes';
  } else {
    result = 'no';
  }
  return result;
})

// Without:
node.listen(function(arg) if (arg) 'yes' else 'no')

私にとっては、Cから派生したすべての言語を悩ませているのは設計上の問題です。つまり、「宙ぶらりんのその他」。この文法上の問題はC ++で解決されるはずでしたが、JavaとC＃にも引き継がれました。

これまでのすべての答えは、多くの主流言語の単一の失敗を指していると思います。

下位互換性に影響を与えずにコア言語を変更する方法はありません。

これが解決すれば、他のほとんどすべてのグリップを解決できます。

編集。

これはライブラリで異なる名前空間を使用することで解決でき、言語のほとんどのコアで同様のことを行うことができますが、複数のコンパイラ/インタープリターをサポートする必要があるかもしれません。

最終的に、完全に満足できる方法でそれを解決する方法を知っているとは思わないが、それは解決策が存在しない、またはそれ以上はできないことを意味しない

Javaのサイレント整数算術オーバーフロー

JavaとC＃の両方には、ジェネリックを追加する際に後方互換性を維持したいため、型システムに迷惑な問題があります。Javaはジェネリックと配列を混在させることを好みません。C＃では、値型を境界として使用できないため、いくつかの有用な署名は許可されません。

後者の例として、

public static T Parse <T>（Type <T> type、string str）ここで、T：Enum

public static object Parse（Type type、string str）

MyEnum e = Enum.Parse（typeof（MyEnum）、str）;

MyEnum e =（MyEnum）Enum.Parse（typeof（MyEnum）、str）;

tl; dr：バージョン1を公開した後ではなく、型システムの設計を開始するときに、パラメトリック多態性について考えてください。

私は炎上するために自分自身を開放しているように感じますが、C ++で参照によってプレーンな古いデータ型を渡す機能を本当に嫌います。参照によって複雑な型を渡すことができるのは少し嫌いです。関数を見ている場合：

void foo()
{
    int a = 8;
    bar(a);
}

呼び出しポイントから、bar完全に異なるファイルで定義される可能性のあるを示す方法はありません。

void bar(int& a)
{
    a++;
}

このようなことをすることは単に悪いソフトウェア設計であり、言語を責めることではないと主張する人もいるかもしれません。ポインターを使用して呼び出す

bar(&a);

より読みやすくなりました。

ALTER

COBOLを学んだとき、ALTERステートメントはまだ標準の一部でした。一言で言えば、このステートメントを使用すると、実行時にプロシージャ呼び出しを変更できます。

危険なのは、めったにアクセスされず、プログラムの残りの部分のフローを完全に変更する可能性のあるコードの不明瞭なセクションにこのステートメントを配置できることです。複数のALTERステートメントを使用すると、いつでもプログラムが何をしていたかを知ることがほぼ不可能になります。

私の大学の教官は、非常に強調して、私たちのプログラムのいずれかでその声明を見たなら、彼は自動的に私たちをflしたと述べました。

プログラミング言語の最悪の罪は、明確に定義されていません。私が覚えているケースはC ++で、その起源は次のとおりです。

1. 定義が非常に悪かったため、次の書籍または例ではプログラムをコンパイルして実行できませんでした。
2. 1つのコンパイラーとOSでコンパイルして実行するようにプログラムを微調整したら、コンパイラーまたはプラットフォームを切り替えた場合、最初からやり直す必要があります。

私が覚えているように、C ++をCと同じくらい専門的に信頼できるものにするために十分に定義されたC ++を得るには、約10年かかりました。

私が罪と考える他の何か（それは別の答えになるでしょうか？）は、いくつかの一般的なタスクを行うための複数の「最良の」方法を持っています。（これも）C ++、Perl、Rubyの場合です。

C ++のクラスは、言語のある種の強制設計パターンです。

実行時に構造体とクラスに違いは実際上ありません。「情報隠蔽」の本当のプログラミングの利点が何であるかを理解するのは非常にわかりにくいので、そこに配置します。

私はそのことに賛成するつもりですが、とにかく、C ++コンパイラはこの言語を書くのがとても難しいので、モンスターのように感じます。

すべての言語には欠点がありますが、一度知ってしまえば迷惑なものはありません。このペアを除く：

複雑な構文と冗長なAPI

これは、Objective-Cのような言語に特に当てはまります。構文が非常に複雑であるだけでなく、APIは次のような関数名を使用します。

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath

私は明確で曖昧さを感じないようにしていますが、これはばかげています。Xcodeを使用するたびに、n00bのように感じますが、それは本当にイライラします。

1. Cで署名された文字-数学者に小さなアイテムの大きなコレクションを持たせるために考案された憎悪
2. ケースを使用してセマンティックコンテンツを運ぶ-再び話す必要はなく、数式を入れるのに十分なスペースがない数学者向け
3. Let / Plainの割り当てと基本的な方言での割り当ての設定-ここに関係する数学者はいないと思います