COBOLを軽蔑する理由
人々がCOBOLに言及するとき、それは通常snortまたはうめき声に会います。私はCOBOLについてはあまり知りませんが、その中に書かれたプログラムをいくつか見ました。それは言葉が濃厚で、私のような初心者の目には理解できません。しかし、実際には、すべてのプログラミング言語は一般の人には意味不明なものではありませんか？
私はそれが機能し、うまく機能し、それが設計された業界でまだ広く使用されていることを理解しています。それらは良い言語の特徴ではありませんか？ COBOLの何が悪いのですか？
COBOLは、私が最初に学んだ言語の1つでした。無数のバージョンのBasic、3つまたは4つのアセンブラー言語、およびForthのバリアントを無視すると、最初の5つになり、Pascalと同時に学習しました。 IOW、私はその言語を使った個人的な経験から答えています。
[〜＃〜] edit [〜＃〜]私は古代の経験を言うべきです。 80年代の終わり以降、この言語を使用することはありませんでしたが、ホラーストーリーが歪曲されないように、参考にするために新しい本を購入しました（不快に捨てた古い本を置き換えるため）。しかし、言語が少なくとも過去20年間でどのように進化したかはわかりません。
明らかに、多くの人にとって、それはisjonscaがすでに説明した「古いのは悪い」という見方です-そして、はるかに多くの第三者のパス-私ダウンの態度の事。しかし、その根底にある実際の問題があります。
言葉遣いが多すぎるのは本当の問題です。コードを理解する方法が多すぎます。これは断然最大の問題です。 MOVE、ADD、およびMULTIPLYなどのステートメントを恐怖で見る人々は、これについて少し誇張した見解を持っています。true-COMPUTEステートメントは、他の言語での割り当て。しかし、これらすべての部門やセクションには、依然として多くの混乱が残っています。私がCOBOLで最初に学んだことの1つは、常に標準のA4のページの長いSKELETON.COBをコピーすることから始めることでした。
COBOLdoesにはいくつかの興味深い機能がありますが、それらの機能（たとえばPICのもの）は、プログラミング言語ではなくDBMS、そしてそれは私に通常それらの責任を分離するより良い方法であるように思えます。また、他の言語の一部のライブラリは、PICに相当するものを使用しています（たとえば、C標準ライブラリのprintfおよびscanf）。間違いなく、最高は維持されましたが、最悪は落ちました。
また、すべてのニース機能について、少なくとも1つの許容できない機能がありました。たとえば、ループがどれほど些細なものであっても、本体を別のプロシージャに移動する必要があります。 PERFORM ... UNTIL ...および類似のステートメントは、単一のステートメント（ブロック構造ではない）です。ある意味では、COBOLは構造化プログラミングが発明される前の構造化プログラミングの味でした-そこにがありましたa GO TO、しかし、その使用は推奨されませんでした（少なくとも、私がCOBOLを使用したとき）、特にループは、それほどうまく処理されませんでした。
実際、私が使用した言語後にCOBOLを最も思い出させたのは、dBaseでした。 Ashton-Tate dBase III +と同様。最近、人々は、一般名xBaseにつながったすべてのクローン（Clipper、FoxProなど）を覚えている可能性が高くなり、xHarbourにはまだ生きている子孫がいます。重要なのは、これらはデータベース言語でしたが、SQLに勝るものはありませんでした。
それでも、特定のデータベースで動作するeveryCOBOLプログラムには、そのデータベースの仕様のコピーを含める必要があります（コピーは一貫性を失う可能性があります） 、それはデータベースがそれ自体の構造を知っているxBaseの場合は実際には当てはまりません。
それを考慮すると、COBOLはそれが何であるかを受け入れてもそれほどひどくはありません。しかし、それがではないものは、データ構造を記述するための言語です。これが、C対Pascalの聖戦の時代にCOBOLが大きく苦しんだ理由かもしれません-COBOLがバイナリツリーを再発明するのにまだ良くないことに双方が同意することができました。
ああ-そして、私が決して忘れないことの1つは、私の最初のCOBOL教科書がSORTコマンドを本の範囲外であると述べていなかったことです- どうやら、作者はソートのアイデアに対処できなかったか、またはそれをCOBOL学生の小さな心が対処できる以上のものであると考えた [最後の編集を参照]。そのようなことは、COBOLを真剣に受け止めることを非常に困難にしました。
これの奇妙な側面はジャクソン構造化プログラミングでした。これも私がほぼ同時に、特にCOBOLで使用するために学ぶことを余儀なくされました。これの一部は、入力の構造図を描画し、次に出力の構造図を描画してから、コードの中間の構造図を描画しました。ソートはすでに解決済みの問題であることが明らかに予想されていました-この方法でソートアルゴリズムを導出することはできませんでした。したがって、推奨される教科書で、並べ替えの概念全体が私の小さな心を超えていることは奇妙でしたが、同時に、12の異なる並べ替えアルゴリズムのようなものや、Pascalでそれらを実装する方法を教えられていました。
JSPが処理できる問題は、おそらくCOBOLが比較的適切に実行できることの良いガイドとなるでしょう。しかし、それでも、必ずしもJSPまたはCOBOLがこれらの問題を処理するための優れた方法であることを意味するわけではありません。
[〜＃〜] edit [〜＃〜] 2014年7月30日
これで評判が高まり、ここにあることを思い出しました。たまたま、懐かしさを増した古代の本の収集が原因で、SORTコマンドのWRTポイントを修正できるようになりました。
私がCOBOLを学ぶときに推奨テキストとして最初に使用した本は、Ray Wellandによる「COBOLの方法論的プログラミング」でした。これにはCOBOL 85は含まれていません（私がまだ見たことのない「COBOL-85でのメソッドプログラミング」という新しい版がありましたが）。
「OSに付属のsortユーティリティを使用して、入力ファイルを読み取る前にソートするか、出力ファイルを生成した後にソートすることになっていた」と、以下のようにコメントしています。それに対する私の返事から、「OSに対応する」というポイントを逃しました。 Kindallは、Unixの哲学AFAICTに似たものを提案していました。それは、COBOLが適切なビットに使用され、並べ替えユーティリティなどのOSユーティリティが他のものに使用され、おそらくバッチ/スクリプト/シェル言語を使用してビットを接着しているためです。これは、対話型ソフトウェアがほとんど存在しない古代世界でははるかに理にかなっているため、とにかく作業のバッチ（したがって「バッチ言語」）を送信することになります。
以下は、「COBOLでの方法論的プログラミング」の165〜166ページからの引用です...
順序付けされたシリアルファイルの使用は、ファイル内のレコードをキーで指定された順序にソートする手段が必要であることを意味します。最も大規模なコンピューターシステムには、キーを形成する各データ項目の位置、タイプ、およびサイズを指定してファイルをソートするソートユーティリティがあります。
COBOLプログラム内からレコードをソートする機能もありますが、次の2つの理由により、この本の範囲を超えています。
（a）オペレーティングシステムへのインターフェースはしばしば非常に複雑で、システムごとに異なります。
（b）sortモジュールはANS '74 COBOLのオプションの部分であり、小規模なコンピューターのCOBOLシステムには実装されない場合があります。
したがって、ファイルを指定された順序にソートする機能が存在すると想定され、そのようなファイルを更新する問題が考慮されます。
つまり、kindallは正解です。通常、並べ替えはCOBOLの外部で行われると想定されていました。 1974年ごろ、小規模なコンピューターでは、プログラミング言語から並べ替えを除外する正当な理由があったかもしれません。
私が上で言ったのは、基本的に、本を捨てたために事実を確認できなかった約20年後に得られるものでした。
ただし、1988年と1989年に1974年の標準（1985年の標準ではなく）を取り上げたこの推奨書から正式にCOBOLを研究したことを指摘しておきます。「COBOL for Student」の第3版（Parkin、Yorke、Barnes）- COBOL 85をカバーする最初のエディションは1990年まで発行されませんでした。確かではありませんが、「メソッドプログラミング」のCOBOL 85エディションは1994年まで発行されなかったと思います。
しかし、これは必ずしもCOBOLの世界が足を引っ張っているわけではありません。新しい標準の採用には、現在でも、どの言語でも時間がかかります。
今日の大部分をCOBOLの作成に費やしてきたので、現在の入力を提供できると思います。
まず悪いもの：-
- 関数呼び出しはありません。最新のCOBOLにはいくつかの組み込み関数がありますが、独自の関数を作成することは真剣なエンジニアリングの仕事です。
- サブルーチン呼び出しの型チェックはありません。サブルーチン呼び出しで何でも渡す（または渡さない）ことができます。呼び出されたサブルーチンは、それが正しいパラメータを持っていると仮定し、欠落または無効なパラメータを検出する方法はありません。
- ライブラリはありません。ゼロジルチなし。標準ライブラリはなく、広く利用されている簡単に利用できるライブラリはありません。あなたは何度も何度も何度もcommomplaceタスクをコーディングすることになります。
- すべてがキーワードとして実装されます。言語の作者はライブラリの概念を持っていないため、すべての新機能は新しいキーワードで実装されます。 XMLサポート用のPARSEおよびRENDER。
誤解されている、つまり、親愛なる古い言語に対して一般的に平準化されている、無効または無関係な批判。
冗長。だからあなたはいくつかの余分な文字を入力します！深刻な問題ではありません。多くの場合、COBOLはJavaと言うより冗長ではありません。
"COBOL FILES"この用語はよく使われています。 COBOLがほぼすべてのファイル形式とほぼすべてのファイル編成を処理できるというだけのことはありません。
- マルチスレッドなし。 COBOLが成功する環境では、マルチスレッドは通常、CICSまたはIMSのようなアプリケーションコンテナーに任されています。これは、それが得意ではないプログラマーではなく、.
そして良いもの-COBOLのいくつかの側面は他の言語より優れています：-
- データ構造。 COBOLには、複雑なデータ構造と奇数のデータ型を定義するための簡潔で柔軟な構文があります。
- 10進数演算。 10進数の算術、つまり会計士が理解できる算術が適切に丸められるなど、ネイティブでサポートされています。
- タイムズとともに移動します。 COBOLのいくつかの側面は驚くほど現代的です。組み込みXMLサポート、OOプログラミングのサポート、Javaクラスなどを使用する機能。
- DB2、CICSなどとの統合。これはIBMのメインフレームCOBOLにのみ適用されます（ただし、これはまだ実行中のCOBOLの最大のチャンクです）が、DB2、CICSおよびその他のメインフレーム環境との統合により、データベースのバックアップなどのコーディングが容易になります。他のどの環境よりもWebサービス。
- 画面処理。 AS/400およびMicroFocus Cobolに実装されている標準の画面処理は優れています。
- パフォーマンス。長年にわたり、COBOLコンパイラーは非常に高性能な実行可能ファイルを生成してきました。 IBMメインフレームでCOBOLに勝るのは、ネイティブCとネイティブアセンブラだけです。
つまり、1950年代に委員会によってまとめられた何かのために、全体として非常にうまく機能しています。既存のアプリケーションがCOBOLで実装されており、その仕事をする場合、それを書き直す理由はありません。ただし、本当に正当な理由がない限り、新しいプロジェクトでCOBOLを使用する正当な理由はありません。
これは恐らくジクストラのせいです。ジクストラは、「COBOLの使用は心を傷つけます。したがって、その教育は犯罪と見なされるべきです」と述べました。 Cobolは、単純で、構造化されておらず、冗長であると見なされていました。コードを自己変更する機能（cobolプログラマーの間でも推奨されない習慣）があるため、デバッグやフォローも非常に難しいと考えられていました。
それから、バージョン間の大きな非互換性の問題もあります。
ウィキペディアの言語に関する批評と防御のセクションを読むことをお勧めします- http://en.wikipedia.org/wiki/COBOL#Criticism_and_defense
年齢と冗長性は、一般的に人々がそれについてうめき声を上げるものです。
COBOLを設計する際のIBMの主な目的は、「銀行のマネージャーがプログラムを作成できるようにすること」であったことを思い出したようです。この目標は明らかに言語の設計方法に大きな影響を与えましたが、今ではそれが進化しました。
どうやら、実際には他のどの言語よりも多くのCOBOLが出回っています。ただし、ITで約20年間（銀行業で15年間）働いた後、それに実装された単一のシステムに出会ったことはありません。
COBOLの何が悪いのですか？
何もない。
古くて悪い、「最新が最高」という先入観があると思います。それはまだ非常に多く使用されており、さらに半世紀にわたってコードに十分なメンテナンス作業が行われると確信しています。
1997年に、ガートナーグループは、世界のビジネスの80％がCOBOLで実行されており、年間2,000億行以上のコードが存在し、推定で50億行の新しいコードが毎年あると報告しています。 （ wikipedia 経由）
コーディングでは、常にその仕事に最適なツールを選択する必要があり、特定のハードウェアと連携している特定の業界では、言語が最適です。私はそれが人気があると聞いていた銀行で働いたことがありませんが、ショーンの答えはこれはそうではないことを示しています。
古く見えるレガシーコードに問題がある場合、その前にUIまたはWebインターフェースを配置できる限り、ほとんどのユーザーはその違いすら知らないでしょう。
アプリケーションが限られているため、人々はCOBOLを嫌っています。これは、企業や政府のビジネス、財務、および管理システム用に設計されました。
これらすべての共通点は何ですか？ データ。大量のデータ
データを処理するように設計されていて、朝食用のファイルがたくさんあるのは誰ですか？ コモンのビジネス指向言語と言えますか？
50年前、COBOLは、大量のデータを管理する大規模組織にとって最高のものでした。今日、大量のデータを管理するより良い方法があるので、COBOLはもはや関係ありません。またはそれは？
政府について考えてみましょう。政府はどのデータを追跡する必要がありますか？人々の身分証明書、出生証明書、医療記録、税金（ああ...はい...税金）など。そして、彼らはこれらの情報を無期限に保持する必要があります。今日、そして50年前もそうです。
人々はまた、回答のいくつかで銀行を買収し、実際に銀行はCOBOLのヘビーユーザーです。どうして？他のタイプの企業とは異なり、銀行には通常歴史があります。一部は数百年もの間存在します（ たとえば、この例のように ）。
つまり、50年前のデータの一部が、2011年10月7日の今日、私たちと一緒に存在する必要があります。SQLServerとC＃またはOracleとJavaができましたが、50年前はCOBOLとファイルがありました。
時間が経つにつれ政府や銀行のデータはどんどん大きくなり、システムを移行することはますます高価になりました。つまり、それらはCOBOLにとどまり、ビジネスの進化に合わせて常に維持および進化する必要があります。一部の銀行はゆっくりと移行していますが、他の銀行は、メインフレームの前にNice Web2.0インターフェイスを貼り付けています（c＃とJavaが主に使用されています）。レガシーコードと言いますか？（COBOLは（極端な）レガシーコードと連携します。その中には、何十年にもわたって存在する多くの人々が触れたものがあります-プログラマーが好まないもう1つのこと：D） 。
そして今、あなたは活動のニッチを持っています。 COBOLのアプリケーションが制限され、エクスペリエンスが影響を受けます。
そしてCOBOLを使い始めた人々は、結局、毎年同じように何度も何度も何度も繰り返し、目覚めたときには市場で競争力がなくなっていることに気づきます。 人々は現在PHP、Java、C＃、REST、jQueryを求めており、銀行のみがCOBOLの人々を探しているためです。
この時点で、需要は供給より低く、削減を行わない人は別の場所に移動する必要があります。そして、COBOLは本当に頭を痛めている（コピーアンドペーストはCOBOLの開発の主要なスタイルではなく、その大きな生産性を説明していると信じている）ので、彼らは後輩から始めなければならず、今彼らがCOBOLを手に入れて、それについて彼らのホラーストーリーを話す機会を失うことのない日:)。しかし、あなたはこれらの話を、最近需要がなくなった古いおならの言語について話すことができますが、あなたはそれで立ち往生している不幸な人です。よし...
P.S。およびCOBOLは、他の人によって言及されている他のすべての理由で不良です:)
P.S.2。In 1997, the Gartner Group reported that 80% of the world's business ran on COBOL with over 200 billion lines of code in existence and with an estimated 5 billion lines of new code annually. 本当に？そして、日はそれをどのように測定しましたか？彼らはWordのすべての会社に行って、彼らが持っているCOBOLの行数は何ですか、または何を尋ねましたか？
2つの機能。
ALTERステートメントは純粋に悪です。より最近のCOBOLアプリケーションではめったに使用されませんが、同等の「IF-GOTO」構造よりも効率的だったため、「昔」によく使用されていました。コンピューターに32KのRAMしかない場合、各命令が重要でした。 GOTOステートメントを変更して、別の宛先を指定しました。
これは、コード自体がステートフルであるため、コードを不透明にしました。
データ構造のREDEFINES句（Cの
unionなど）は永続的な問題です。 「フリーユニオン」という用語、つまり弁別子のないオーバーレイされたデータ構造は、問題を要約する方法です。 2つのREDEFINESエイリアスをデータで簡単に区別することはできません。プログラムロジックの広範な読み取りのみが、バイトの2つの代替解釈の意味を決定できます。コードがないとデータを理解できないため、多くのデータ構造が不透明になりました。
英語のような構文の読みやすさは、これら2つの構成要素によって打ち負かされていました。
[モデレーターから、短い回答では重要で興味深い質問が却下されると警告されました。これが不適切だと思われる場合は、詳細を尋ねることができます。または、モデレーターが削除できるようにフラグを立てます。]
私はCOBOLで数年間プログラミングしてきました。その構文は今日の言語と比較して単純であり、あなたが上手に学ぶために多くの理論を必要としません。 COBOLはIBMのCICS（オンライントランザクション管理システム）と非常にうまく連携しており、プログラマーは、アプリケーションのユーザー数を1から数千に拡大するために、コードを書き留める必要があります。 CICSは、画面を表示の単位として使用する（ウィンドウではない）文字ベースのGUIを提供しました。メインフレームで（IBMのGDDM）を使用してグラフを表示できます。 COBOLは、索引ファイル（VSAMおよびISAM）だけでなく、DB2（SQLベースのリレーショナル）およびIMSとも通信できます。 COBOL/CICSは非常に堅牢な環境であり、数週間で習得できます。つまり、テクノロジーではなくビジネスに集中することになるため、8時間のうち7時間はMVMやJavaScriptなどの学習ではなくコーディングに取り組みます。
COBOLの問題は、悪いマーケティングであり、そのためのツールとプログラミング環境を開発するサードパーティからの関心が欠如しています。また、Windowsのようなインターフェイスへのサポートの欠如により、1993年以降、その人気は低下しました。メインフレームのコストにより、顧客はCOBOLの代替とコンパイラを探すようになり、UNIXとDOSで利用可能になりました。 C言語は、より移植性が高く、COBOLにはほとんどないOS関数に直接アクセスできるため、多くの光を引き出しました。
VB、DBase、FoxPro、Clipperなどの言語は、DOS上の同等のCOBOLよりもPC上の「データベース」にアクセスする方法が優れていたため、COBOLは失われました。 CICSは長い間DOSまたはUNIXで安価に作られていなかったため、これらの環境にはその価値はありませんでした。
今日、COBOLは.NETでサポートされていますが、メインフレーム（およびおそらくAS/400）を除いてすべてのプラットフォームでの戦いに負けたと思います。それ。
えっと、私は80年代前半に大学に行きましたが、当時でも人々はCOBOLを軽蔑していました。最大の問題はその冗長性、つまり単純な「Hello、world！」だと思います。 COBOLでは、おそらく50行を超え、その95％は定型文が必要です。それは非常にエレガントで魅力的な言語ではありません。また、昨日の問題を処理するように設計されており、1970年以降に開発された開発パラダイムにはあまり向いていません。レポートがヘッダーとフッターのある無数の列である限り、これは非常に優れたレポート生成言語です。グラフやロゴをどこかに貼り付けたい場合は、忘れてください。 「データ処理」タイプのタスク（5MのATMトランザクションを含む固定形式のファイルを取り、それぞれに単純なバランス調整を行う）の場合、それはまだ最速の言語だと思いますが、それ以上の種類のことを行う開発者は何人いるのでしょうか。そして今日、多くのシステムがXMLまたはJSONを使用しているので、COBOLを使用してそのようなものを解析しようとは考えたくありません（実際には、COBOLでの一般的な解析について考えたくありません！）