プログラミング言語の後方互換性とその欠陥の修正を維持する

まず、いくつかのコンテキスト（ほとんどの人が知っているもの）：

すべての一般的なプログラミング言語には明確な進化があり、ほとんどの場合バージョンによってマークされます。Java5、6、7など、PHP 5.1、5.2、5.3などがあります。新しいバージョンをリリースすると、新しいAPIが利用可能になり、バグが修正され、追加されます新しい機能、新しいフレームワークなどです。全体として：それは良いことです。

しかし、言語（またはプラットフォーム）の問題はどうでしょうか？言語に何か問題がある場合、開発者はそれを回避するか（可能であれば）、それと共存することを学びます。

現在、これらの言語の開発者は、それらの言語を使用するプログラマーから多くのフィードバックを得ています。そのため、時間（およびバージョン番号）が経過するにつれて、これらの言語の問題はゆっくりと、しかし確実に消えていくことになります。まあ、そうでもない。どうして？下位互換性、それが理由です。しかし、これはなぜですか？より具体的な状況については、以下をお読みください。

私の質問を説明できる最善の方法は、PHPを例として使用することです。

PHPは何千人もの人々に愛され、嫌われています。すべての言語には欠陥がありますが、明らかにPHPは特別です。このブログ投稿をご覧ください。PHPのいわゆる欠陥の非常に長いリストがあります。今、私はPHP開発者ではありません（まだ）が、すべてを読み通しており、そのリストの大きな部分が実際の問題であると確信しています。（潜在的に主観的であるため、すべてではありません）。

さて、もし私がPHPを積極的に開発している人の1人であれば、これらの問題を1つずつ解決したいと思っています。ただし、それを行うと、言語の特定の動作に依存するコードが新しいバージョンで実行されると壊れます。2語で要約すると、後方互換性です。

私が理解していないのは、なぜPHPの下位互換性を保つ必要があるのか​​ということです。これらの問題をすべて修正したPHPバージョン8をリリースした場合、「このバージョンでは古いコードを実行しないでください！」という大きな警告を出すことはできませんか？

非推奨と呼ばれるものがあります。私たちは何年もそれを持っていて、それはうまくいきます。PHPのコンテキスト：最近の人々がどのようにmysql_*関数の使用を積極的に推奨していないか（そして代わりにmysqli_*PDO を推奨するか）を見てください。廃止は機能します。使用できます。それを使うべきです。関数で機能する場合、言語全体で機能しないのはなぜですか？

私（PHPの開発者）がこれを行うとしましょう：

• これらのすべての欠陥を修正した新しいバージョンのPHP（たとえば8）を起動します
• 新しいプロジェクトは、そのバージョンの使用を開始します。これは、はるかに優れた、より明確な、より安全なものだからです。
• ただし、古いバージョンのPHPを放棄しないように、更新プログラムをリリースし続け、セキュリティの問題、バグなどを修正します。これは、ここにリストしていない理由から理にかなっています。これは一般的な習慣です。たとえば、バージョン5.5.xに主に焦点を合わせていたにもかかわらず、OracleがMySQLのバージョン5.1.xを更新し続けた方法を見てください。
• 約3〜4年後、古いバージョンのPHPの更新を停止し、それらを消滅させます。この3年か4年で、ほとんどのプロジェクトはとにかくPHP 8に切り替えられるので、これは問題ありません。

私の質問は次のとおりです。これらの手順はすべて理にかなっていますか？それはとても難しいでしょうか？それができれば、どうしてできないのですか？

はい、欠点は後方互換性を破ることです。しかし、それは支払う価値がありませんか？良い点として、3、4年後には、その問題の90％が修正された言語になります。その名前はその人気を保証します。

編集：OK新しい計画。

それは問題ないように聞こえますが、実際にはほとんど動作しません。人々は実行中のコードを変更することに非常に消極的であり、新しいグリーンフィールドプロジェクトであっても、すでに知っている言語/バージョンからの切り替えを非常に嫌います。

「正常に動作する」既存の実行中のコードを変更することは、プロジェクトの優先順位リストの上位にあるものではありません。言語やプラットフォームの新しいリリースにアップグレードできるようにするために、マネージャーが既に支払われたと考えていたものに努力を払うのではなく、開発者は「今のところ」古いリリースにとどまることを宣言します。新しいリリースでしか利用できない優れた機能をユーザーに呼びかけることはできますが、言語を明確に獲得できないためにユーザーベースを減らすリスクがあります。クールでモダンな機能は、人気のある意見では断片化されたインストールベースの価格と簡単に比較することができず、「アップグレードトレッドミル」であるという評判を得るリスクがあります。

（明らかに、これのほとんどは趣味のために趣味で書いたプロジェクトには当てはまりません。しかし（ここではフレームベイトです...）PHPは、そもそも書くのがとても楽しいので、ハッカーによって不釣り合いに選ばれることはめったにありません。 ）

後方互換性の影響を過小評価しています。すべてのアクティブなプロジェクトが3年または4年で移行するとの予測は、あまりにも楽観的です。

私がPHP開発者だとします。PHPには欠陥がありますが、これらの欠陥を回避する方法は知っています。これが、PHP開発者として報酬を受け取る理由の一部です。ここで、PHP 8が登場し、それらの欠陥を修正するとしますが、下位互換性はありません。結果として：

• PHP 8のコードの更新に時間を費やす必要があります。それは、顧客の要求に応え、新しい機能を実装し、競争に遅れずについていく時間です。
• これを行った後でも、いくつかのコーナーケースや予期しない互換性の問題を見逃して、コードにバグを導入する可能性が十分にあります。

これを考えると、たとえ「より良く、より明確に、より安全に」であっても、PHP 8 に決して移行しないという強い動機があります。まだ数十億行のCOBOLがあると推定されています（！）-明らかにはるかに優れたテクノロジが利用可能であっても、更新のコストはバグのリスクと相まって、価値がありません。

第二に、自分のコードを移行することにしたとしても、重要なアプリはサードパーティのライブラリに依存し、サードパーティのライブラリが移行するという保証はありません。たとえば、Python 3は2008年12月にリリースされましたが、Django（おそらく主要なPython Webフレームワーク）は、ほぼ5年間、安定した本番用のPython 3サポートがありませんでした（こちらとこちらをご覧ください）。

あなたは人間の行動について多くの仮定をしています。変更しすぎると、競合他社を評価することになります。とにかく切り替えに多大な労力を費やさなければならないからです。オープンソース言語の場合、人々は古いバージョンをフォークするだけです。

例としてpythonをご覧ください。3.xは4年間利用可能ですが、まだ広く採用されていません。人々は新しいプロジェクトにそれを使用しようとしますが、メンテナンスがどれだけのコード作業であるかを過小評価していると思います。

もちろん、ほとんどの人はpython 2.xに「欠陥がある」とは考えていませんでした。phpユーザーのような苦情はありませんでした。Phpははるかに不安定な立場にあります。多くの人が既存のコードベースが大きいためにそれだけに固執しているからです。後方互換性が失われた場合、多くの人がPythonに移行するのを待っていた機会を利用するでしょう。

PHP以外の言語では、そうですね、絶対に理にかなっています。それがまさにPython 3への切り替えでPythonが行っていることです。

しかし、PHPの問題は、言語設計自体に多くの欠陥があることです。したがって、「PHP 8」と呼ぶものは完全に異なる言語になります。また、別の言語に切り替える必要がある場合、現在の既存の安定した代替物ではなく、新しいPHPに固執するのはなぜですか？

また、PHPコミュニティは新しいものを適応させるのに非常に時間がかかります。取り除くのにかかった時間を見てくださいregister_globals。2000年以降、セキュリティリスクであることが知られています。12年後にようやく削除されました。別の例として、PHP5が導入されたとき、PHP4よりも大幅に改善されましたが、コミュニティはそれを適応しませんでした。私は4年かけてGoPHP5のような大規模なアクションを取り、採用を開始しました。そして、それは後方互換性のない変更のかなりの量を持っていませんでした。

免責事項：ColdFusionユーザーグループを管理しています。

ColdFusionにも同じ問題があります。多くの人に愛され、多くの人に軽deされています。さらに、Java以前のバージョンに基づいたFUDのトンとトン。ColdFusion 10は昨年発売され、巨大な売り手であり、先週、バージョン11のプレリリースをテストするためにサインアップしました。また、2つの主要なオープンソースの選択肢があります。

CF10には実装したい新機能がたくさんありますが、CF 7または8からの移行は、コードベースのサイズ、今後のプロジェクトの数、すべてを一度テストする必要のあるリソースによっては難しい場合があります'最新バージョンです。8と9の間のいくつかのマイナーな構文上の違い、およびコードが同じ方法でコンパイルされないエッジケースに遭遇しました。見つかったら、コーディング標準に文書化して、将来のプロジェクトや新しい開発者が使用しないようにします。

ただし、ColdFusion 11（または任意のプログラミング言語）が特定の関数と構文を完全に廃止する場合、機能を見つけて置き換えるための労力は膨大なものになる可能性があります。テスト作業は膨大なものになる可能性があります。企業は、開発者、QA、およびプロジェクトマネージャーに、これらの非推奨のものをすべて検索、置換、およびテストするための費用を支払うのですか？疑わしい。

言語の最新バージョンに後方互換性があるが、コードを変更せずにパフォーマンスが向上する場合（CF9はCF8よりも約30％高速で、CF10はCF9よりもはるかに高速です）、関数呼び出しがまだ機能している場合、関数呼び出しの変更を気にしますか？

会社として、私たちはサービスを請求し、ビジネスを構築し、より多くのクライアントをリクルートするために、クライアントを喜ばせ、ニーズを提供することを心配する必要があります。

FWIW、私はいつかjQueryの最新バージョンを入手したいと思っていますが、特定の機能は使用後にいくつかのバージョンが廃止され、システムにあるJavaScriptの量が与えられているため、どのように私たちはそれをやってのけるつもりです。

ここにはトレードオフがあります。本当に修正が必要なバグもありますが、どこかで誰かのコードを壊さなければ変更できないものもあります。すべてのバグ修正が誰かのプロジェクトを破壊するという「ルール」として述べている誰かを覚えているようです。これがプログラマの性質です。

これは（私の考えでは）メジャーリリース、マイナーリリース、リビジョンの違いです。一般原則として：

• メジャーリリースには、重大な変更が含まれていると想定されています。
• マイナーリリースは、動作をわずかに変更する場合があります。
• リビジョンは、ほとんど互換性があるはずです。

たとえば、言語のv2.3で何かを書いている場合、v2.3.2にアップグレードしても違いに気付くことはないでしょう。v2.4にアップグレードすると、いくつかの変更が行われる可能性があります。小さな構文の調整、一部の機能の動作が少し異なるため、ロジックの調整などが必要です。v3.0にアップグレードしても、壊れても驚かないでしょう完全に-非推奨または欠落している機能、サポートされていない、または変更されていないため操作を行に戻すことができないため、実際には新しい変更に対応するためにいくつかの機能を書き換える必要があります。

編集：

Steve Vanceの論文Advanced SCM Branching Strategiesには次のように書かれています。

通常、ピリオドに関連付けられた番号（1.2.3など）で命名された2〜3レベルのリリースがあります。[...]この構造では、最初の番号はメジャーバージョンに関連付けられており、前のバージョンからの重要な機能および機能の強化があることを示しています。また、移行が必要な重大な非互換性がある場合があります。2番目の数字はマイナーバージョンを表します。マイナーバージョンには、より少ない機能と機能強化、多数のバグ修正が含まれ、非互換性はありません。3番目の数字はパッチレベルを指し、ほとんどすべてのバグ修正を意味します。パッチレベル間での機能や機能の強化や非互換性の許可はありません。

私がこれに加える唯一の変更は、プログラマーがバグを「使用する」方法を見つけることが多いという前述の原則です。したがって、バグは、それらを使用したものを破壊するか、回避策が不要になり、問題を引き起こします。

それは本当に言語のターゲットであるものに依存します-言語によってどのタイプのアプリケーションが構築されることを意図していますか。

たとえば、Androidを無視すると、Javaは大規模なエンタープライズシステムとミドルウェアで主に使用されます。これらのタイプのアプリケーションは、サイズと時間の両方で非常に大きくなる傾向があります。これにはいくつかの意味があります。開発段階で50人以上のエンジニアが働く500K + LoCのシステムを想像してください。通常、このタイプのシステムは、その後10人の開発者がメンテナンスを開始します。言語が変更され、変更に後方互換性がない場合、一部の部分を書いたプログラマーがいなくなり、誰も触れたくないため、プロジェクトを新しいバージョンに簡単に移行できません。これは小さな問題です。大きな問題は、500 LoCアプリケーションを新しい言語の制約に適合させるのに費用がかかるという事実にあります。たとえば、ジェネリックが型消去で実装されていなかった場合、List list = new List(); 数百万行のコードをコンパイルする必要はありません。書き直す必要がありますが、多大なコストがかかります。

一方、PHPはWeb上でよりシンプルなアプリケーションに使用される傾向があります。通常、単一のプログラマーまたは小さなチームによって開発されます。開発者は、プロジェクト全体が言語の変更をより簡単に統合できることをよく知っています。また、目的は非常に高速なサイトを構築することであり、高速であるほど良いので、新しい言語機能がこれをより良くすることができれば、後方互換性のコストで実装されます。

Microsoftは、ASP.NET（従来のASPの後継）またはVB.NETで同様の変更を行ったと主張できます（ただし、VB.NETは後者と非常に多くの譲歩をしたため、言語を「再起動」する利点のほとんどが失われました）。

とにかく、移行ツールの助けを借りてVB6コードをVB.NETに移行するという悪夢を誰かが覚えていれば、言語移行ツールは主要な言語の更新ではうまく機能しないことにすぐに同意するでしょう。

プラットフォームを前進させることは可能かもしれませんが、少なくともいくつかの改訂を通じて「非推奨」APIのサポートを提供する必要があります。

人気のあるプログラミング言語で人々が叫ぶ「欠陥」の多くはそうではありません。彼らは、今日のスクリーマーのお気に入りのおもちゃにはその言語が欠けているものがあります。
次の誇大広告がやってくると、その誇大広告に固執していないため、言語に突然欠陥が生じます。

Javaのクロージャの欠如は典型的な例です。それは言語の欠陥ではなく、言語を変更して（悲しいことに議題にあるように）それらを含めると、IMOは基本的にそれを損なうか、少なくとも読んで理解するのをはるかに難しくします。

あまりにも多くの人が見失っているのは、各言語には長所と短所があり、すべての弱さを避けながらすべての強みを組み合わせたものを作成しようとすると、まったく役に立たず、信じられないほど使い果たし、効果的に使用します。

他の人が指摘しているように、後方互換性は既存のユーザーを維持するために不可欠であり、その多くは数千時間と数百万ドル/ユーロを費やして、100万行のコードベースを「より良い」と思うものに改造しない彼らが何年も使用している言語のバージョンよりも、あなたは十分に十分な議論をたくさん持っており、おそらく次の「ジャバキラー」である新しい誇張されたアイデアで遊びたいならおもちゃのクローンに「修正」されない限り、「Java iz ded」と叫ぶのではなく、そのおもちゃで遊ぶのが最善です。

言語の新しいバージョンは、古いバージョンと新しいバージョンの両方でコンパイルするコードの99.99999％が、そうしないように意図的に設計されていない限り、両方で同じように動作することを保証するように努力することをお勧めします新しいバージョンが古いバージョンでコンパイルされたコードを拒否する場合、それはコードが（最高の状態で）危険であり、古いコンパイラと新しいコンパイラの両方でコンパイルされる別の方法で書かれていたためです。

たとえば、JavaまたはC＃に似た新しい言語を設計している場合、それらの言語で許可されている一部のコンテキストで暗黙的な型変換を禁止します。C＃の簡単な例として、

int someInt;
double someDouble;

式someInt.Equals(someDouble)は、変数の内容に関係なくfalseを返すことが保証されています。それはので、コンパイルdoubleに変換取得することができObject、そしてint持っているEqualsその種類の過負荷を、ので、コンパイラは、変換を行い、呼び出しを行います。新しいバージョンのC＃と.NET Frameworkを設計していた場合、有用な処理を実行できない可能性があるため、ボクシングの変換を禁止します。役に立たないが無害な方法でそのような比較を行うプログラムが存在する可能性があり、コンパイラにそのようなコードを拒否させるとそのプログラムが壊れる可能性がありますが、そのような役に立たないコードを修正または削除すると改善されます。

少しわかりにくい例として、仮定します

float f=16777216f;
int i=16777217;

そして、式を検討してくださいf==i。これは、いくつかのコードがフロート/整数の比較を行い、正常に動作することは可能ですが、コードのいずれかのように書き換えるべきであるf==(float)i、(double)f==i;または(double)f==(double)i;[ intにdouble昇進ロスレスなので、後者の二つは同等になります]。直接比較floatしてinteger値を指定するコードの中には、十分に小さい数値を常に処理するものもfloatあり、double比較も同じように動作しますが、コンパイラは一般にそれを知ることができません。コードは、言語の規則がプログラマの意図と一致することを期待するのではなく、どのような比較が必要かを明確にする必要があります。

後方互換性を決して壊さないことが最善です。

Microsoftは、VB6プログラミング言語を互換性を完全に破る新しい言語に置き換えました。そのため、今日でも16歳のVB6はdotNetバージョンよりも人気があります（Tiobeインデックス2014年8月）。そして、ガートナーは、まだ使用されているVB6コードが140億行あると推定しています。

2014年、MicrosoftはVisual Basicプログラミングコミュニティからの要求にもかかわらず、VB6を更新またはオープンソース化しないことを再び発表する必要がありました。しかし、彼らはVB6のサポートを「少なくとも」2024まで延長し、Windows 7および8で正常に動作します。これは、同じバージョンのVB6の26年以上のサポートになります。

MicrosoftがdotNetを使用するためにOfficeを「更新」することはないのに、なぜ既存の作業ソフトウェアを書き直す必要があるのですか？

後方互換性を壊すにはいくつかの異なる問題があります。問題の一部は、ほとんどのプログラミング言語がプラットフォーム（インタープリター/ランタイム）でもあるという事実に起因するものであり、他の問題は人間の性質の仮定に起因するものです。

A.古いバージョンで記述されたコードは、パフォーマンス、セキュリティ、または機能を改善する新しいリリースの利点を得られません。コンパイラー/インタープリターの複数のメジャーバージョンをサポートすることでこの問題を軽減できますが、それは膨大なリソースの浪費です（つまり、高価であるか、時間がかかり、お尻が痛いです）。

B.新しいバージョン用に作成されたコードは、古いバージョンで作成されたコードと互換性がない場合があります。複数のメジャーバージョンの言語を処理できるインタープリター/コンパイラーを使用することでこの問題を回避できますが、これは個別のインタープリター/コンパイラー（Aの回避策）をサポートするよりも面倒です。

C.頻繁に/急速に発生する場合、大きな変更は、単に学習して学習しなければならないため、言語の使用を難しくします。言語の変更により、人々は端を越えて新しい言語に切り替えるか、古いバージョンの言語を使用し続けて新しいバージョンに決して切り替えないようにする可能性があります（Pythonで発生したように）。この場合も、変更は新しいユーザーを引き付け、古いユーザーを興奮させる可能性があります。

D.新しいドキュメントを保持および維持する必要があります。グーグルで物事を調べて、現在使用しているバージョンとは異なるバージョンのドキュメントを読んでいることがわかります。

概して、外部モジュールが使用しているバージョンを気にする必要のないプログラミング言語を作成する場合、適切な理由で後方互換性を壊すこと（言語の主要な欠陥を修正すること）はほぼ間違いなく正しいことです。プログラミング言語の設計者は、これが行われていない主な理由であることをことを、その可能性が過大評価（他の誰かの答えと矛盾する、特に早い時期に、互換性を壊すのコストを）。事実、互換性を損なうという問題は、その言語のユーザーが回避または強化することができます。そして、これはプログラミング言語だけに当てはまりません。これは、API、ユーザーインターフェイスに適用されます-実際には、あらゆる状況のあらゆるインターフェイス。

Facebookは、UIまたは開発者APIを変更すると、人々を大いに困らせます。過去には、プラットフォームの操作が困難でした。場合によっては、APIが突然機能しなくなることがありました。しかし、人々はそれを使い続け、現在、APIとUIは5年前よりも飛躍的に向上しています。人々は、彼らにとって良いか悪いかにかかわらず、変化について不平を言うでしょうが、それ（不平を言う）はその変化を忘れる正当な理由ではありません。残念ながら、プログラミング言語の開発者は、これを使用して、言語の問題を損なわないようにします。

そのため、言語が自身を改善するために重大な変更を行わない別の理由は次のとおりです。

E.言語開発者は、ユーザーが変化を恐れていることが、言語を停滞させる十分な理由だと考えている

F.言語開発者は、言語を作成したときに好きでしたが、おそらく欠陥があると思います。

G.言語が古くなると、通常、開発者の小さなコアセットがなくなり、より多くの委員会が作成した獣になります。これは、これらの言語に関する決定が遅く、しばしば保守的で創造的でないことを意味します。

H.最後の理由は、一部の重大な変更では、インタープリター/ランタイムに対して行われた設計上の決定を大幅に再評価する必要があることです。言語を改善するには、実行するには多すぎる作業が必要になる場合があります。これはほとんどのトーよりもまれな問題だと思います。

多くの場合、言語デザイナーは必ずしもツールデザイナーであるとは限らないため、この問題に対する適切な解決策を考えていないか、適切に実行していません。以下に、重大な変化の問題を解決するために考えられるいくつかの解決策を示します。

1. 削除される前に物事を非推奨にします。

2. 適切な標準の変換ツールを提供します。Pythonは2to3ツールを提供しましたが、宣伝されていなかったし、思い出すようにpython 3に標準で付属していなかったし、うまく動作さえしませんでした修正しませんでした）。コンパイラー/インタープリターが古いバージョンを検出した場合、このコンバーターツールを自動的に実行することもできます。もっと簡単なことは何ですか？

それがPHPコードの問題かどうかはわかりませんが、多くの古い言語では、レガシーコードは数年後、または場合によっては数十年も更新されることはありません。数百万のSLOC）、それを書き換えることは意味がありません。これは、特にライブラリで（更新が簡単であっても）古い問題を知っているにもかかわらず、javaが後方互換性をほぼ宗教的な問題にした理由です。Linuxカーネルの多くのコードは、C99やC11のような標準の採用にもかかわらず、数十年間も更新されなかったと思います。

「起業家」の少ない言語でさえ、古い機能コードを壊すことが問題になる可能性があります。それがPython 2-> 3で起こったことです。多くのライブラリとシステムスクリプトは安定しており、もはや放棄されていたのではなく、安定していて作業を行っていたためです。それらの適応には数年かかります。したがって、開発者として、お気に入りのライブラリがまだ移動していない場合、必ずしもpython 3にジャンプすることはできません。そのため、独自のコードはpython 3でも機能せず、コミュニティの断片化につながります。

問題は後方互換性の問題にあります。私が実行するほとんどのPHPスクリプトは、古いRedHatサーバーで実行されています。将来のスクリプトに新しいバージョンの言語を使用する場合、このサーバーでPHPを更新する必要があり、古いスクリプトが破損したり、古いコードをすべて書き換えるのに何時間もかかるリスクがあります新しい標準。さらに、私の開発者はすべて、特定の方法（その方法が「壊れている」かどうか）に反応するPHPに慣れています。開発者が基本的にPHPを再教育しなければならない可能性があるため、そのように反応しなくなると、生産性にとって大きなハードルになる可能性があります。