私は、COBOLがまだ維持されているニッチ市場にすでにいない限り、そうは思わない。
いいえ、もちろん違います。結局、COBOLは死んだ言語です。それともそうですか？
そのような見方の問題は、このようなサイトのプログラマーは通常、ハイテク企業であり、稼働率が高い（そして同様に燃え尽きる）企業と協力していることです。彼らにとって、COBOLは死んだ言語です-それはどこにも見られません。もうしばらくの間、本当です。
しかし、COBOLはそれらのためのものではありませんでした。ソフトウェア産業にはこれ以上のものがあります。コンピュータは、常にアップグレードして古いものを新しいものに交換する必要があるという非合理的なニーズを持つ人々のために発明されたのではありません。彼らはビジネス目的のために作られました。
あなたはCOBOLを見たいですか？給与を処理したり、商品のトラック輸送や配送（船の場合のように）を処理したり、銀行口座を処理したりする会社に行きます。ユーザーにはほとんど見えないコードの巨大な目に見えないシステムがあり、ほとんどのユーザーは、何らかの形で日常的に（ATM？）
いいえ、死んではいません。しかし、それは確かに「レガシー」です...またはそれは何ですか？
繰り返しますが、それをどのように見るかによって異なります。今日では、多くの人々がCOBOLの代わりにJava、C、またはその他のものを使用して、ゼロから書き直しています...当然ながら、新しいバグを導入しています。これは、COBOLにバグや奇妙な点がないということではありません。それは次の言語と同じぐらいです。もちろんそうです。しかし、「COBOL時代」では、通常よりも真剣にバグを取り込んだ企業（保険、銀行）は、特別な品質のサービスグループでより高品質のコードを作成する傾向がありました。今日、時間と予算が常に品質よりも優先される締め切りがあります。また、これらのシステムは当初、現在の同等のものと比較して、当時より長い期間開発されました。
一部のソフトウェアが30年以上動作している場合、切り替えるインセンティブはどこにありますか？ という古い格言を無視したため、会社全体が廃業しました。「壊れていなければ、修正しないでください。」多くの人が書き直そうとしました事...それから最初の書き換えはかなりの費用がかかり、それから2回目の書き換えはそれ以上の費用がかかりました...そしてそれらの新しく改善されたものはどれもそれを置き換えることができませんでした。先ほど申し上げたように、この業界は急速に燃えており、忘れがちです。
70年代には、COBOLが死んでいるか、すぐに死んでいたので、C/C++が支配するようになりました。その後、80年代初頭に再びPascalが引き継ぎました。それから90年代にはJava THE言語として...
Unisys Mapper、dBase、Clipper、Cold fusionについて考えてみてください。人々はそれらを覚えていますか？それらのそれぞれがCOBOLの重大な問題となるでしょう。
これを考慮すると、大量のトランザクションの処理、バッチ処理、またはレコード/トランザクション指向の処理に最適であり、マネージCOBOLコードとして30年前に作成されたサブルーチンをコンパイルして（エラーなしで）呼び出して呼び出すことができるという事実マネージCOBOL.NETからWindowsや.NETに移行したい場合、適切な代替品を見つけるのに苦労しています。 （10年以上続いたマイクロソフトテクノロジを見つけるのにも苦労しています。）
はい、新しいCOBOLコードが今日書かれています。どこを見ればいいのかを知る必要があります。
COBOL、私見で笑っている人にとって、それはエジプトのピラミッドで笑っているようなものです。彼らは5000年前からそこにいて、次の5000年にはまだそこにいます。交換され、来月忘れられました。
つまり、これらすべてのCOBOLプログラマはどこにいますか？
ああ、ここには摩擦があります。問題は、それらの多くがコンピューティングサイエンスのバックグラウンドを持っていないことです。それらの多くはプロのプログラマーではありません（CS/SEプログラムの大卒者の場合など）。ほとんどの場合、彼らは30代後半から50代のすべての専門分野の人々であり、その仕事のために会社によって完全に訓練されています。つまり、彼らは「COBOLプログラマー」ではありません。彼らが得たトレーニングは、社内から非常に宣伝している会社に固有のものです。そして、それは彼らをほとんど見えなくします。
自分がCOBOLプログラマーだと思ったら、それを試してください。メンテナンスを必要とするCOBOLで記述された数十億行がまだ残っています。
実は不必要な知識などいいえもあるので、知識を広げて（持って）チャンスを広げましょう。
それを学ぶことは意味がありますか？
まあ、それはニッチであり、維持する必要があり、単に書き換えることができない大量の機能しているレガシーコードがあります。だから、それはすべてのプログラマーの大多数にとって実際にはオプションではありませんが、個人の安定した収入のための展望です。
ただし、何十年も前から存在しているソリューションを徐々に改善するのではなく、新しいソリューションの作成に関心がある場合、COBOLはおそらく適切な言語ではありません。
多くのヨーロッパの企業は、依然としてz/vseやcobolプログラムのように実行されるメインフレームに大きく依存しています。誰もが給与を押し上げる市場が一杯になるとは誰も考えていない熟練した共同プログラマーへの要求があります。
問題は、「cobolを使用して何か新しいものを開発することはありますか？」ということです。ほとんどすべてが既存のミッションクリティカルなもののメンテナンスまたはバリエーションであるためです。
私たちは毎日新しいCobolコードを書き、新しいプログラマーを常に探しています。このあたりの供給は少なすぎます。
私は、COBOLとPL/Iのコードが毎日書かれているIBMで働いていました。また、毎秒数千のトランザクションを必要とする多くの銀行のようなIBMのメインフレームに依存している大企業からも、これらの言語は依然としてひどく使用されています。
そのような場所で仕事をしたくない場合は（だから私は6か月間そこで働いただけです）、それらの言語を学ぶことすら考えないでください。
COBOLプログラマーとしての仕事が必要な場合は、ぜひ先に進んで学習してください。
それ以外の理由で、現代のプログラミング手法に役立つと思われる有用な何かを学ぼうとするような場合は、いや、気にしないでください。
2000年に、他のすべての言語を組み合わせたよりも多くのCOBOL行が記述されているという統計を読みました。
さらに、IBMは、任意のMVSシステムでコンパイルされたTEXTデッキ（オブジェクトコード）がすべてのMVSシステムで実行可能であり、Sunが存在する限り、COBOLプログラミングがあることを保証します。輝く。
私がそれをどのように「学習」したかをお話しします。
私はそれを扱うために雇われ、それについて何の手掛かりもなく、一晩でそれを学ぶのに苦労しませんでした。
だから、あなたがそれを必要とするなら、あなたはそれを学ぶことができます。無駄な知識で自分に負担をかける必要はありません。あなたがそれを実際に必要としない限り、それやその取り組みには興味深いものは何もありません。
一般的な答え：特定の実装（言語など）ではなく、コーディングの原則を学ぶ
結局のところ、物事がどのように機能するか（または以前は機能していたか）を知ることは悪いことではありません。
ただし、履歴書ではCOBOLスキルを強調しすぎないようにすることをお勧めします。
一部の場所（たとえば、私が住んでいるシリコンバレー）では、履歴書にCOBOLが含まれていると責任が生じます。確かに、あなたはあなたの専門知識を必要とする場所をあちこちに見つけるかもしれません、そしてその場合は先に進んでそれを宣伝してくださいそれらの場所にのみ。しかし、一般的には、自分に好意を示し、COBOLを知っていることを忘れてください。
ですから、もし興味があればそれを学んでください。誰にも言わないでください。
私はそれに時間を費やすことはありません。
とにかく、COBOLは、20\30年前に開始されたいくつかの大企業にとってミッションクリティカルな多くのレガシーアプリケーションプログラムのビルディングブロックです。
そのため、COBOLでコアビジネスの一部を持っている会社に雇われている場合、それを学び始める必要がある可能性があります。
ワークマーケットの観点からは価値がないかもしれませんが、「古き良き時代」に物事がどのように行われたかを感じただけでそれを確認したい場合があります。 ^^
個人的な観点からは、最初に学ぶべきより良いことがあると思います。ただし、多くの大企業はCOBOLコードベースに非常に大きな投資を行っているため、実際に取り残せないため、COBOLプログラマーがコードベースを維持し、新しいコードを作成するための業界を築いています。私が働いている会社は大規模な金融会社で、開発者向けのテクノロジー分割は、およそ30％がCOBOL、40％がJavaおよび30％C＃です。
オーストラリア最大の求人サイトで「cobol」を検索しました。 87の結果が返されましたが、簡単に言うと、ほとんどが銀行や金融機関のレガシーメンテナンスポジションのようです。おそらくCobolの経験の希少性が原因で、「現代」の言語ベースの仕事よりも明らかにはっきりと給料が高くなります。
ですから、1）レガシーメンテナンスを行うことを気にせず、2）給与が高く、おそらくあまり競争力のないニッチ市場に入りたいと考えるなら、Cobolは学ぶ価値があると思われます。
（私は、Cobol市場はほとんどの第一世界経済で似ていると思いますが、間違っている可能性がありますか？）
作業したい問題のドメインの種類について考えてください。通常、これらのドメインには、一般的に目的に使用される言語のセットがあります。 COBOLがそれに一致する場合は、先に進みます。
私が10フィートのポールでそれを多用するcobolまたは問題のドメインに触れる方法はありません。ハンバーガーをひっくり返したい。
また、言語がプログラミング能力/概念に何らかのボーナス/改善を提供するかどうかも検討してください。 COBOLでできること、実装できないこと、機能が優れていないこと、または別の言語でより適切に示すことができることについては、私は考えられません。
あなたと他の人は違う感じになるかもしれません。
COBOLで書かれたレガシーシステムはまだたくさんあります。それらを保守する場合でも、他のプログラミング言語に移植する場合でも、COBOLについて学ぶ価値はあります。
それが何であれ、複数のプログラミング言語の知識があればプラスになります。これは、持っている知識によって、プログラミング言語を選択したり、さまざまなプロジェクトのニーズに対応したりできるためです。プログラミング言語に関する知識を活用して、より優れた、よりクリーンで効率的なコードを作成し、落とし穴を回避できます。