COBOLを軽する理由 [閉まっている]

人々がCOBOLに言及するとき、それは通常、鼻水またはうめきに会います。COBOLについてはあまり知りませんが、COBOLで書かれたプログラムを見てきました。私はそれが言葉遣いであり、私のような理解できない未経験の目であることがわかります。しかし、実際には、すべてのプログラミング言語が一般人にとって意味のないものではありませんか？

私は、それが機能し、うまく機能し、それが設計された産業でまだ広く使用されていることを理解しています。それらは良い言語の特徴ではありませんか？COBOLの何が悪いのですか？

COBOLは私が最初に学んだ言語の1つです。Basicの無数のバージョン、3つまたは4つのアセンブラー言語、およびForthのバリアントを無視すると、最初の5つになり、Pascalと同時に学習しました。IOW、私は言語を使用して個人的な経験から答えています。

編集私は古代の経験を言う必要があります。80年代の終わり以降、この言語を使用したことはありませんでしたが、ホラーストーリーがあまり歪まないように参照できるように、新しい本を購入しました（嫌悪感で捨てた古い本を置き換えるため）。しかし、少なくとも過去20年で言語がどのように進化したかはわかりません。

明らかに、多くの人にとって、それは jonscaがすでに説明している「古いことは悪い」という見方に過ぎません。しかし、その根底には本当の問題があります。

言葉が多すぎることは本当の問題です-コードを理解する方法にはあまりにも多くの混乱があります。これが最大の問題です。見て人々MOVE、ADDそしてMULTIPLY恐怖内などのステートメントは、真の本の少し誇張されたビューを持っている- COMPUTEステートメントが近い他の言語での割り当てにあります。しかし、これらすべての部門とセクションにはまだ多くの混乱があります。COBOLで最初に学んだことの1つは、常に標準のA4ページのSKELETON.COBをコピーすることから始めることでした。

COBOLにはいくつかの興味深い機能がありますが、それらの機能（例PIC）は、プログラミング言語ではなく、DBMSの一部になりつつあり、私は通常、これらの責任を分離するためのより良い方法であるようです。また、他の言語の一部のライブラリは、それに匹敵するものを使用しますPIC（C標準ライブラリのprintfおよびscanfなど）。おそらく、最高のものが保持されていますが、最悪のものは落ちました。

また、すてきな機能ごとに、少なくとも1つの耐えられない機能がありました。たとえば、ループがどれほど些細なものであっても、本体を別の手順に移動する必要があります。PERFORM ... UNTIL ...同様のステートメントはありませんブロック構造-単一のステートメント。ある意味、COBOLは構造化プログラミングが発明される前の構造化プログラミングの趣味でした-がありましたがGO TO、その使用は推奨されませんでした（少なくともCOBOLを使用した場合）が、特にループ処理はうまく処理されませんでした。

実際、COBOLの後に私が最も思い出させた言語は、dBaseでした。Ashton-Tate dBase III +のように。最近では、xBaseという一般名につながった、現在死んでいるか、死にかけているすべてのクローン（Clipper、FoxProなど）を覚えている可能性が高くなります。xHarbourにはまだ生きている子孫がいます。重要なのは、これらはデータベース言語でしたが、SQLのようなものではないということです。

その場合でも、特定のデータベースで動作するすべての COBOLプログラムがそのデータベースの仕様のコピーを含める必要がある（そして、コピーが最終的に矛盾する可能性がある）場合、データベースがそれ自身の構造を知っているxBaseでは実際にはそうではありません。

それを考慮に入れると、COBOLは、それが何であるかを受け入れた場合、それほどひどいものではありません。しかし、データ構造を記述するための言語ではありません。これがCOBOLがC対Pascalの聖戦の時代に多くの苦しみを受けた理由かもしれません-両者はCOBOLが二分木を再発明するのにふさわしくないことに同意することができました。

ああ、忘れられないことの1つは、最初のCOBOL教科書がSORTコマンドを説明していないことです。コマンドの範囲外であると言っています。 COBOL学生の小さな小さな頭脳が対処できる以上のものであると考えました [最後の編集を参照]。そのようなことから、COBOLを真剣に考えることは非常に困難でした。

これの奇妙な側面は、Jackson Structured Programmingでした。これは、ほぼ同時に、特にCOBOLで使用するために学ぶことを余儀なくされました。その一部は、入力の構造図、次に出力の構造図を描画し、次にコードの中間構造図を描画することでした。ソートはすでに解決済みの問題であることが明らかに予想されていました。この方法ではソートアルゴリズムを導出できませんでした。したがって、推奨される教科書で、並べ替えの概念全体が私の小さな心を超えていると同時に、数十種類の並べ替えアルゴリズムとそれらをPascalで実装する方法などを教えられていると言われるのは奇妙でした。

JSPが処理できる問題は、おそらくCOBOLが比較的うまくできることの良いガイドです。しかし、それでも、それは必ずしもJSPまたはCOBOLがこれらの問題を処理するための良い方法であることを意味しません。

2014年7月30日に編集

私はこれから評判が高まり、ここにいることを思い出しました。たまたま、懐かしさのある古書収集のために、WRTのSORTコマンドを修正することができます。

COBOLを学習するときに推奨テキストとして最初に使用した本は、Ray Wellandによる「COBOLのメソッドプログラミング」でした。これはCOBOL 85をカバーしていません（ただし、後のエディション「Methodical Programming in COBOL-85」はまだ見たことがありません）。

「OSに付属しているソートユーティリティを使用して、入力ファイルを読み取る前にソートするか、生成後に出力ファイルをソートすることになっていた」という以下のすべてのコメント。それへの返信から、「OSに付属」という点を逃しました。KindallはUnixの哲学AFAICTに似たものを提案していました。COBOLはそれが良いビットに使用され、ソートユーティリティなどのOSユーティリティは他のものに使用され、おそらくバッチ/スクリプト/シェル言語を使用してビットを結合します。これは、対話型ソフトウェアがほとんど存在しない古代の世界でははるかに理にかなっているので、とにかく作業のバッチ（つまり「バッチ言語」）を送信することになります。

以下は、「COBOLでのメソッドプログラミング」の165-166ページから引用されています...

順序付けられたシリアルファイルの使用は、ファイル内のレコードをキーで指定された順序に並べ替える手段が必要であることを意味します。ほとんどの大規模なコンピューターシステムには、キーを構成する各データ項目の位置、タイプ、サイズを指定してファイルをソートするソートユーティリティがあります。

COBOLプログラム内からレコードをソートする機能もありますが、これは2つの理由からこのマニュアルの範囲外です。

（a）オペレーティングシステムへのインターフェイスは非常に複雑であることが多く、システムごとに異なります。

（b）並べ替えモジュールはANS '74 COBOLのオプション部分であり、小規模なコンピューターのCOBOLシステムには実装できません。

したがって、ファイルを指定された順序に並べ替えるための機能が存在すると想定され、そのようなファイルを更新する問題が考慮されます。

要するに、kindallは正しいです。通常、ソートはCOBOLの外部で行われるという仮定でした。1974年頃に小さなコンピューターのプログラミング言語から並べ替えを除外することは、実際に正当化されていたかもしれません。

上で言ったことは、基本的に、本を捨てたために事実を確認できなかった約20年後に得られるものです。

ただし、1988年と1989年に1974年の標準（1985年の標準ではない）を扱ったこの推奨書からCOBOLを正式に研究したことを指摘しておく必要があります。 COBOL 85をカバーする初版は1990年まで公開されていませんでした。確信はありませんが、「メソッドプログラミング」のCOBOL 85版は1994年まで公開されていなかったと思います。

しかし、それは必ずしもCOBOLの世界が足を引きずっているわけではありません。現在でも、どの言語でも新しい標準の採用には時間がかかります。

今日のほとんどをCOBOLの作成に費やしてきたので、現在の入力を提供できると思います。

まず悪いもの：-

• 関数呼び出しはありません。最新のCOBOLにはいくつかの組み込み関数がありますが、独自の関数を記述することは深刻なエンジニアリングの仕事です。
• サブルーチン呼び出しの型チェックはありません。サブルーチン呼び出しで何かを渡す（または渡さない）ことができ、呼び出されたサブルーチンはそれが正しいパラメーターを持っていると仮定します。また、欠落または無効なパラメーターを検出する方法はありません。
• ライブラリはありません。ゼロジルチなし。標準ライブラリも、広く使用されている簡単に利用できるライブラリもありません。あなたは何度も何度も何度も繰り返しタスクをコーディングすることになります。
• すべてがキーワードとして実装されます。言語の作成者にはライブラリの概念がないため、新しい機能はすべて、XMLサポート用のPARSEやRENDERなどの新しいキーワードで実装されます。

誤解、すなわち、一般的に無効であるか無関係である親愛なる古い言語に対するレベルの批判。

• 冗長性。したがって、いくつかの余分な文字を入力します！深刻な問題ではありません。多くの場合、COBOLはJavaよりも冗長です。

• 「COBOL FILES」この用語は多くの人に見られます。COBOLがほぼすべてのファイル形式とほぼすべてのファイル編成を処理できるようなものはありません。

• マルチスレッドなし。COBOLが繁栄する環境では、マルチスレッドは通常、CICSやIMSのような、得意なプログラマーではなく、得意なアプリケーションコンテナーに委ねられます。

そして良いもの-COBOLのいくつかの側面は他の言語よりも優れています：-

• データ構造。COBOLには、複雑なデータ構造と奇数データ型を定義するための簡潔で柔軟な構文があります。
• 10進数演算。10進数算術、つまり会計士が理解できる算術、適切な丸めなどのネイティブサポートを備えています。
• タイムズと共に移動します。COBOLのいくつかの側面は驚くほど現代的です。組み込みのXMLサポート、OOプログラミングのサポート、Javaクラスを使用する機能など。
• DB2、CICSなどとの統合。これはIBMのメインフレームCOBOLにのみ適用されます（ただし、それはまだ実行中のCOBOLの最大のチャンクです）。他のどの環境よりもWebサービス。
• スクリーン処理。AS / 400およびMicroFocus Cobolに実装されている標準画面処理は優れています。
• パフォーマンス。長年にわたって、COBOLコンパイラは非常に高性能の実行可能ファイルを生成してきました。ネイティブCおよびネイティブアセンブラーのみがIBMメインフレームのCOBOLを打ち負かしました。

したがって、1950年代に委員会によってまとめられたものについては、全体として非常にうまく機能しています。既存のアプリケーションがCOBOLで実装され、ジョブを実行する場合、それを書き換える理由はありません。しかし、本当に正当な理由がない限り、COBOLを使用する新しいプロジェクトの正当性は見当たりません。

これはおそらくジクストラにかかっているでしょう。ジクストラは、「COBOLの使用は心を傷つける。したがって、その教えは犯罪と見なされるべきである」と述べた。Cobolは、単純で、構造化されておらず、冗長であると見なされていました。コードを自己変更する機能（cobolプログラマの間でも推奨されない慣行）があるため、デバッグや追跡も非常に難しいと見なされていました。

それから、バージョン間の大きな非互換性の問題もあります。

Wikipediaの言語に対する批判と防衛のセクションを読むことをお勧めします-http://en.wikipedia.org/wiki/COBOL#Criticism_and_defense

それは年齢であり、冗長性は一般的に人々がそれについてうめき声を上げるものです。

IBMがCOBOLを設計するときの主な目的は、「銀行のマネージャーがプログラムを作成できるようにすること」だったことを思い出すようです。この目標は明らかに言語の設計方法に大きな影響を与え、現在では進化しています。

どうやら、他のどの言語よりも多くのCOBOLが世に出ています。ただし、ITで20年近く（銀行の15年）働いた後、そのシステムに実装された単一のシステムに出会ったことはありません。

COBOLの何が悪いのですか？

なし。

私は、古いものは悪い、「最新のものが最高のもの」という先入観を持っていると思います。それはまだ非常に使用されており、さらに半世紀の間、コードのメンテナンス作業が十分に行われると確信しています。

1997年、Gartner Groupは、世界のビジネスの80％がCOBOLで実行され、2,000億行を超えるコードが存在し、年間50億行の新しいコードが推定されると報告しました。（ウィキペディア経由）

コーディングでは、常に仕事に最適なツールを選択する必要があり、特定のハードウェアと結婚している特定の業界では、言語が最適です。私は銀行業で働いたことは一度もありませんでした。そこでは人気があると聞きましたが、ショーンの答えはそうではないことを示しています。

古いコードに古い問題があり、その前にUIやWebインターフェイスを平手打ちできる限り、ほとんどのユーザーはその違いさえ知りません。

COBOLの用途は限られているため、人々はCOBOLを嫌います。企業や政府のビジネス、金融、管理システム向けに設計されました。

これらのすべてに共通するものは何ですか？データ。たくさんのデータ。

誰がデータを処理し、朝食用のファイルをたくさん持っているように設計されていると思いますか？COMmonon Business-Oriented Languageと言えますか？

50年前には、大量のデータを管理する大規模な組織にとってCOBOLが最適でした。今日、大量のデータを管理するためのより良い方法があるため、COBOLはもはや関係ありません。またはそれは？

政府について考えてみましょう。政府はどのデータを追跡する必要がありますか？人々の身分証明書、出生証明書、医療記録、税金（ああ...はい...税金）など。そして、彼らはこれらの情報を無期限に保持しなければなりません。

また、人々はいくつかの答えで銀行をnetりました。実際、銀行はCOBOLのヘビーユーザーです。どうして？他の種類の企業とは異なり、銀行には通常歴史があるからです。数百年にわたって存在するものもあります（たとえば、このように）。

つまり、2011年10月7日に、50年分のデータがまだここにある必要があります。現在、SQL ServerとC＃またはOracleとJavaがありますが、50年前にはCOBOLとファイルがありました。

時間が経つにつれて、政府と銀行のデータはどんどん大きくなり、システムの移行はますます高価になりました。つまり、それらはCOBOLのままであり、ビジネスの発展に合わせて恒常的に維持および進化する必要があります。ゆっくりと移行している銀行もあれば、メインフレームの前に素敵なWeb2.0インターフェイスを貼り付けている銀行もあります（c＃とJavaが主に使用されています）。レガシーコードと言えますか？（COBOLは（極端な）レガシーコードと密接に連携します。一部のコードは、数十年にわたって存在する多くの人々に触れられていました-私たちプログラマーが嫌いなもう1つのこと：D）。

そして今、あなたは活動のニッチを持っています。COBOLのアプリケーションは限られているため、経験が影響を受けます。

そして、COBOLに参入する人々は、最終的には毎年同じことを繰り返し行っていることに気づきます。そして、人々が目覚める頃には、人々はPHP、Java、C＃ 、REST、jQuery、および銀行のみがCOBOLの人々を探します。

この時点で、需要は供給よりも低く、カットを行わない人は別の場所に移動する必要があります。そして、彼らはCOBOLが本当に心を不自由ないので後輩として起動する必要があります（ないコピー・ペーストのそれを信じるCOBOLでの開発の主なスタイルは、大きな、その大きな生産性を占めて）、今、彼らはCOBOLを拾った日呪い「とドンそれについてのホラーストーリーを語る機会を失います:)。しかし、最近ではもはや需要がなくなっている古いオナラ言語についての物語を伝えることはできますが、あなたはそれで立ち往生している不幸な人です。まあ...

PSとCOBOLは、他の人が言及した他のすべての理由で悪いです:)

PS2。 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.本当に？そして、日はそれをどのように測定しましたか？彼らは言葉ですべての会社に行って、何行のCOBOLを持っているか、何を求めているのでしょうか？

2つの機能。

• ALTERステートメントは純粋な悪です。最近のCOBOLアプリケーションではめったに使用されませんが、同等の「IF-GOTO」構造よりも効率的だったため、「昔」では頻繁に使用されていました。コンピューターに32KのRAMしかなかった場合、各命令が重要でした。GOTOステートメントを変更して、別の宛先を指定しました。

  これにより、コード自体がステートフルであるため、一部のコードが不透明になりました。

• データ構造内のREDEFINES句（unionCのような）は永続的な問題です。「自由結合」という用語、つまり、弁別子のないオーバーレイされたデータ構造は、問題を要約する方法です。2つのREDEFINESエイリアスをデータで簡単に区別することはできません。プログラムロジックの広範な読み取りのみが、バイトの2つの代替解釈の意味を決定できます。

  データがコードなしでは理解できないため、これにより多くのデータ構造が不透明になりました。

英語のような構文の可読性は、これらの2つの構成要素によって無効になりました。

[モデレーターから、短い答えはあなたの重要で興味深い質問を否定していると警告されました。これを却下する場合は、詳細を尋ねることができます。または、モデレーターが削除できるようにフラグを付けます。]

数年間、COBOLでプログラミングを行ってきました。その構文は、今日の言語に比べて単純であり、学習を進めるために多くの理論を必要としません。COBOLはIBMのCICS（オンライントランザクション管理システム）と非常にうまく機能し、プログラマーはユーザーのアプリケーション数を1から数千に拡大するためにコードを書き留める必要があります。CICSは、画面の表示単位（ウィンドウなし）で機能する文字ベースのGUIを提供しました。メインフレームで（IBMのGDDM）を使用してチャートを表示できます。COBOLは、インデックス付きファイル（VSAMおよびISAM）、DB2（SQLベースのリレーショナル）、およびIMSと通信できます。COBOL / CICSは非常に堅牢な環境であり、数週間で習得できます。つまり、テクノロジーではなくビジネスに専念するため、MVMやJavaScriptなどを習得するのではなく、8時間のうち7時間コーディングに取り組みます。

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を軽cornしていました。最大の問題はその冗長性だと思います-シンプルな「Hello、world！」COBOLでは、おそらく50行を超えており、その95％が定型文である必要があります。とてもエレガントで魅力的な言語ではありません。また、昨日の問題を処理するように設計されており、1970年以降に開発された開発パラダイムにはあまり適していません。レポートがヘッダーとフッターを含む数字の無限の列である限り、非常に優れたレポート生成言語です。グラフまたはロゴをどこかに貼り付けたい場合は、忘れてください。「データ処理」タイプのタスク（5M ATMトランザクションで固定形式のファイルを取得し、それぞれについて単純なバランス調整を行う）にとって、依然として最速の言語だと思います。しかし、そのようなことをする開発者は何人いますか？また、最近では多くのシステムがXMLまたはJSONを使用しているため、そのようなものをCOBOLで解析しようとは考えたくありません（実際、COBOLの一般的な解析を考えたくありません！）