Python 3.0 は以前のバージョンとの後方互換性を壊し、言語を (少なくとも一時的に) 2 つのパスに分割します。成熟期にこのような主要な設計段階を経た言語を他に知っていますか?
また、これがプログラミング言語の進化の仕方だと思いますか、それとも支払うべき代償が高すぎると思いますか?
kgiannakakis
質問する
1469 次
12 に答える
16
このような途中での変更を試みる言語は、Perl だけだと思います。もちろん、Python は最初にリリースすることで、その特定のフィニッシュ ラインで Perl を打ち負かしています。ただし、Perl の変更は Python の変更よりもはるかに広範であり、もつれを解消するのはおそらく難しいことに注意してください。
(Perl の「方法は複数ある」という哲学には代償があります。)
.NET ベースの言語のバージョンごとの変更のような例があります (皮肉なことに、.NET の全体的なポイントは API の安定性とクロスプラットフォームの互換性であると想定されていたことを考えると)。しかし、私はそれらの言語を「成熟した」とは言いません。それは常に、外出先で設計し、飛行しながら飛行機を構築するアプローチでした。
または、私が考える傾向があるように、ほとんどの言語は「有機的な成長」または「工学的構築」のいずれかから来ています。Perl は有機的成長の完璧な例です。派手なテキスト処理ツール ala awk/sed として始まり、完全な言語に成長しました。
一方、Python ははるかに高度に設計されています。彼らの Web サイトにある広範なホワイトペーパーを少し時間をかけてさまよって、言語の構文と実装に対する小さな変更であっても、広範な議論が行われていることを確認してください。
プログラミング言語自体が本質的に変化したため、この種の広範な変更を行うという考えは、プログラミング言語にとってやや新しいものです。以前は、新しい命令セットを備えた新しいプロセッサが登場したときにのみ、プログラミング方法論が変更されていました。初期の言語は、非常に低レベルでアセンブリ言語 (C など) と結びついているか、本質的に非常に動的 (Forth、Lisp) である傾向があったため、そのような途中での変更は考慮に値することさえありませんでした。
変更が良いものかどうかはわかりません。ただし、私は Python の開発を指導している人々を信頼する傾向があります。これまでの言語の変化は、おおむね良い方向に進んでいます。
今後、Global Interpreter Lock は構文の変更よりも中心的なものになると思います。ただし、新しいマルチプロセッサ ライブラリはそのほとんどを軽減する可能性があります。
于 2008-11-07T20:37:22.427 に答える
13
ほぼ絶対的な下位互換性を主張することの代償は高すぎます。理由を知りたい場合は、C++で2分間プログラミングしてください。
于 2008-11-07T21:25:59.957 に答える
9
Python チームは、下位互換性の欠如をできる限り簡単に行えるように懸命に取り組んできました。その結果、Python の 2.6 リリースは、簡単なアップグレード プロセスを念頭に置いて作成されました。2.6 にアップグレードすると、実行できるスクリプトがあり、問題なく 3.0 に移行できます。
于 2008-11-07T20:37:50.100 に答える
7
下位互換性にはそれ自体のコストがかかることを言及する価値があります。100％の下位互換性が必要な場合、理想的な方法で言語を進化させることがほとんど不可能な場合があります。Javaのジェネリックスの実装（下位互換性を保つためにコンパイル時に型情報を消去する）は、100％の下位互換性を備えた機能を実装すると、言語機能が最適ではなくなる可能性があることを示す良い例です。
大まかに言えば、下位互換性のある実装が不十分な新機能か、そうでない適切に実装された新機能のどちらかを選択することになります。多くの場合、特に互換性のないコードを自動的に変換できるツールがある場合は、後者の方が適しています。
于 2008-11-07T21:17:04.030 に答える
6
下位互換性の破損の例はたくさんあると思います。これを行った言語の多くは、小さいか、途中で消滅しました。
この例の多くは、言語の名前を変更することを含みました。
Algol60とAlgol68は非常に異なっていたため、Algol68に関する会議は派閥に分かれました。Algol 68派閥、Pascal派閥、PL/I派閥。
WirthのパスカルはModula-3にモーフィングしました。これはpascalと非常によく似ていましたが、構文とセマンティクスは非常に似ていますが、いくつかの新機能があります。それは本当に下位互換性のないPascal-2でしたか？
LispからSchemeへの変更には名前の変更が含まれていました。
古いBプログラミング言語のマニュアルのスキャンを追跡すると、Cへの進化は、急進的ではなく、一種の漸進的であるように見えますが、互換性が損なわれていることがわかります。
Fortranは多くの形で存在していました。確かなことはわかりませんが、DigitalのVAX /VMS用Fortran90は、古代のFortranIVプログラムと完全には互換性がなかったと思います。
RPGは大きな混乱を経験しました-RPGと呼ばれる互換性のない言語は本当に2つあると思います。
結論 私は、思考と学習は避けられないと思います。言語の限界を学ぶことに対して、3つの反応があります。
まったく互換性のない新しい言語を発明します。
あなたが新しい言語を発明することを余儀なくされるまで、漸進的なシャグネ。
制御された思慮深い方法で互換性を破ります。
＃1と＃2はどちらも臆病者の道だと思います。古いものをチャックすることは、それを保存しようとするよりも簡単です。すべての微妙な機能を（どんなに悪くても）維持することは多くの作業であり、その一部はほとんどまたはまったく価値がありません。
営利企業は、「新しいマーケティング」または「既存の顧客の保護」という名目で臆病なアプローチを選択します。そのため、商用ソフトウェアベンチャーはイノベーションの温床ではありません。
Pythonコミュニティがこの変化に取り組んでいる方法でイノベーションを受け入れることができるのは、オープンソースプロジェクトだけだと思います。
于 2008-11-07T21:24:29.337 に答える
4
C# と .NET フレームワークは、バージョン 1.0 と 1.1 の間、および 1.1 と 2.0 の間の互換性を壊しました。異なるバージョンでアプリケーションを実行するには、複数のバージョンの .NET ランタイムをインストールする必要がありました。
少なくとも、ソースをあるバージョンから次のバージョンにアップグレードするためのアップグレード ウィザードが含まれていました (ほとんどのコードで機能しました)。
于 2008-11-07T20:27:16.953 に答える
4
VB6 から VB.net への変換は、この最大の例ではないでしょうか? それとも、それらを2つの別々の言語と考えていますか?
于 2008-11-07T23:29:44.590 に答える
2
Lispの世界では、それは数回起こっています。もちろん、言語は非常に動的であるため、通常、進化は標準ライブラリの一部を廃止し、標準を別の部分にするだけです。
また、Lua4から5はかなり重要でした。しかし、言語コアは非常に最小限であるため、広範囲にわたる変更でさえ数ページに文書化されています。
于 2008-11-07T21:09:55.963 に答える
1
Perl 6 も現在、この種の分裂を経験しています。Perl 5 プログラムは Perl 6 で直接実行されませんが、コードを機能する形式に変換するトランスレータがあります (100% のケースを処理できるとは思いません)。
Perl 6については、Wikipedia に独自の記事さえあります。
于 2008-11-07T20:28:09.120 に答える
1
まず、Python が経験する変化についてのビデオ トークがあります。第二に、変化は良くない。第三に、私は進化を歓迎し、それが必要であると信じています。
于 2008-11-07T20:30:00.460 に答える
0
Rubyプログラミング言語の新しいバージョンも互換性を壊します。
また、gtk、Qt などのライブラリを使用する可能性があると考えてください (互換性のないバージョンもあります)。
進歩をサポートするために、非互換性が必要な場合もあります (ただし、それほど頻繁ではありません)。
于 2009-01-09T12:38:57.730 に答える
0
gcc は、ほぼすべてのマイナー リリースで C++ の処理方法を定期的に変更します。もちろん、これは gcc が規則に従う方法を強化した結果であり、C++ 自体の変更によるものではありません。
于 2008-11-08T04:03:43.257 に答える