言語が急速に変わる場合、これは良いことと考えられますか？

急速に変化する言語（たとえば、毎年改善される言語）と、ゆっくり改善される言語を見てきました。

私の質問は、言語が急速に変わる場合、これはプログラマーにとって良いことですか、悪いことですか？プログラマーは言語で新しいことを学ぶのが好きですか、それとも既に知っていることを固守することを好みますか？

言語が急速に変わる場合、これはプログラマーにとって良いことですか、悪いことですか？

良い

• この変更により、いくつかの素晴らしいシンタックスシュガーが追加され、バグを減らして将来のコードを記述しやすくなる可能性があります。
• この変更により、プログラマが自分で実装するか、サードパーティに依存する必要があった共通のイディオム/デザインパターンが標準化される場合があります。
• 変更により、言語が通常使用されるテクノロジーとの統合が容易になる場合があります
• 変更は、一般的な間違いを防ぐのに役立つ場合があります
• この変更により、危険なプログラミング手法が廃止または排除される可能性があります
• 変更は、私が自分自身を実装するか、サードパーティに依存しなければならなかったもののために、言語の標準ライブラリに便利な追加を持つかもしれません。

悪い

• この言語は複雑さを増しました-新しい機能は、レガシー機能（C ++とCの関係など）で常にうまく機能するとは限りません。
• レガシーコードは古くなっている可能性があり、更新なしでは新しいバージョンの言語で動作しなくなる可能性があります（Python 2.x-> 3.x）
• 言語用のコンパイラおよびその他のツールを更新する必要があります。現在、潜在的に複数のバージョンが存在します。
• サードパーティのライブラリは新しいバージョンの言語をサポートしていない可能性があります
• 標準の存在にもかかわらず、新しい機能を実装し、その動作のより曖昧なケースのいくつかを定義する標準/通常の方法を見つけるのに時間がかかる場合があります

プログラマーは言語で新しいことを学ぶのが好きですか、それとも既に知っていることを固守することを好みますか？

多くのプログラマーは、新機能を試して好奇心を満たしています。ただし、これは、新機能が製品コードで常に適切であることを意味するものではありません。これはケースバイケースの決定であり、新機能の利点と特定の状況でのアップグレードのコストを比較検討する必要があります。

新しい機能について楽しく学んだり楽しんだりするかもしれませんが、結局のところ、私が本当に気にするのは、有用な製品を誰かに届けることです。合理的なサポートと安定性を備えたモダンなツールセットを選択する必要がありますが、それほど古くはないため、合理的に生産性を上げることはできません。

改善点は素晴らしいです...彼らはしている場合の後方互換性。

C＃はこれをうまく行います。lamdba式、マルチスレッドのサポート、linqなどを追加します...しかし、5年前のC＃2.0プログラムは、変更を必要とせずに正常に機能し、変更を必要とせずにC＃4.0に簡単にアップグレードできます。

新しいことを学ぶことは、タスクをより簡単かつ迅速に行うことができるのであれば素晴らしいことです。学習に1時間を費やすことが開発時間の節約につながる場合、それだけの価値があります。

定期的な改善が必要ですが、コードを以前のバージョンと同じように機能させるためだけに、500 klocのコードベースを壊して大規模な「アップグレードプロジェクト」をトリガーしたくありません。

言語の安定性は、ビジネスと開発者にとって必須です。言語の変更が問題を解決したり、以前のリリースで見逃されていた機能を導入したりする場合は歓迎されますが、流行のように、または競合他社に追いつきたいという理由で言語を変更することはそれほど良くありません。

言語が安定すると、開発者は言語を習得することに集中するのをやめます。なぜなら、言語を習得し、自分が知っていることでビジネスに貢献することに集中するからです。その結果、プロジェクトが短くなり、エンドユーザーが満足し、開発者の誇りが高まります。

変化には学習コストと時間も伴います。すべての雇用主が新しい機能について開発者を教育することを望んでいるわけではありません。これは、開発者が自分自身を訓練するか、そうでない場合に大きな負担を追加します-これは簡単なことではなく、専門コースはそれぞれ$ 1500- $ 3500です！

継続的な変更により、開発者は「レガシー」ソフトウェアをロックできます。これから2年以内にMVVMを使用しなかったASP開発者のケース、またはWPFを習得しなかったWindows Forms開発者のケースを取り上げます。このロックは、開発者のキャリアを著しく傷つける可能性があります。

時間の経過とともに、ビジネスにおけるソフトウェアのアーキテクチャはガーデンサラダのようになります。あらゆる種類のツールとバージョンがあり、プロジェクトをビジネスゲインなしでソフトウェアをあるバージョンから次のバージョンにアップグレードすること以外は何もしません。

正しい答えがあるとは思いません。

一般的に、言語が比較的若い場合、比較的大きな変更を比較的迅速に行う自由度がはるかに高くなります。破壊する既存のコードの大規模なベースはないので、一般的に人々は実験に対してよりオープンです。

言語が古くなるにつれて、誰もが本当に気にするほど広いユーザーになったと仮定すると、既存のコードのベースは、変更できるものに対してますます厳しく制限し始めます。より多くの機能を使用するコードが増えているため、どの変更がコードを破壊する可能性があるかを推測するのが難しくなるだけでなく、人々の期待も変わります。

たとえば、RubyとFortranを書いている人がほぼ同数いると仮定しましょう。さらに、両方にほぼ同じ量のコードがあったと仮定しましょう。私はチャンスがまったく同じそれぞれの割合（と正しいに同じ仕事について取った方法で）を破った変更は可能だろうとかなり良いですと言うだろう多くのより多くのRubyのユーザーに受け入れ原則としてFortranのユーザーよりも（少なくとも、彼らはそれを改善と見なしたと仮定します）。

そもそも言語に対する人々の認識にも大きく依存すると思います。言語を選択人民ので、それの「カッティングエッジ」は多くの、より多くの可能性が高いことは、それがために取るものだならば、既存のコードの多くを破る大きな変化を我慢している保つカッティングエッジの上に。

別の要因は、言語が対象とするプロジェクトのサイズと平均寿命です。比較的小さなプロジェクトに対応する言語や、事前に寿命が短いことがわかっている言語（たとえば、Web UI）は、多くの人が同じコードベースを使用し続ける可能性が低いため、比較的頻繁に破損することを回避できますとにかく、たとえば10年です。初期リリースに到達するまでに5年かかることがある、より大きく、より長寿命のプロジェクトに対応する言語（C ++やJavaなど）は、30年から40年の間、明らかに需要があり、通常の使用（および継続的な開発）になる可能性があります偉大な取引がより安定。

私は彼に彼のC ++が好きだと言われましたが、それはそのままです。彼はDを気にしておらず、Dに興味を持っていません。C＃を知りたくないし、使いたくありません。彼はjavaを学びました。なぜなら、彼はやらなければならない多くのプロジェクトに夢中になっていたからです。

別の人はC＃が大好きで、すべてのキーワードを知らないか、.NET 4ライブラリ（非同期およびすべて）を知らず、抽象的なキーワードまたは使用された属性を使用していません。

私はほとんどの人がドントケアを言っているだけです

アップグレードの影響は、（ライブラリまたはコンパイルされたコードに対して）破壊されています。

C＃について回答します（ただし、この分析はScalaにも適用できます）。

この機能の変更は、言語の「スタイル」に近づいているときにいくつかの問題を引き起こします。

2011年には、C＃でさまざまなことができますが、これは良いことです。残念ながら、2つの異なるパラダイムがあります（それ以上でない場合）。

• OOP
• 機能的（ラムダ関数とLINQを考える）

さまざまなタイプチェックスタイル

• 動的な入力
• 静的入力

いつ使用するかは必ずしも明確ではありません。

それは言語とその言語が持つ次の要素に本当に依存していると思います。たとえば、C＃とJavaがより速いペースで変更をポップし始めたら、それが受け入れられると思います（Carraが言ったように下位互換性がある限り）。しかし、言語がまだ牽引力を獲得しておらず、まだ急速に変化している場合、私が今日学ぼうとすることは6ヶ月間とまったく異なる可能性があるので、私はそれを気にしないことを知っていますこの言語は新しい/人気がないので、それをそのまま伝えることは私にとって有害で​​はありません（読んでください：私のキャリア）。