ヒーローズ・オブ・コード」は、開発者、プログラマー、ハッカー、ギーク、オープンソースの反逆者たちが、いかにしてテクノロジーの未来に革命を起こしたかという真実の叙事詩です。
コードヒーローズとは？
この記事は、ポッドキャストシリーズ」のスクリプトです。
はじめに：ITインフラで使われる言語に賞味期限はありません。何十億行もの古典的なコードがメインフレーム用に保守されてきました。しかし、Goのような言語でクラウド用の新しいインフラも構築しています。
クリス・ショートは、COBOLを学ぶことがいかに安全で長期的な賭けであったかを説明しています。リティカ・トリカは、何かを変えなければならないと説明します。より多くの人がCOBOLを学ぶか、COBOLに依存している業界がコードベースを更新するか。どちらも難しい選択です。しかし、未来はCOBOLで書かれているわけではありません。Carmen Hernández Andoh氏は、Goの設計者がどのようにクラウドに適した言語を設計したかったかを共有し、Kelsey Hightower氏は、言語はしばしば1つのタスクに超集中していると指摘しました。しかし、言語はよりオープンで柔軟になってきています。
::
1904年にニューヨークの地下鉄が開通したとき、それは近代的な驚異として驚嘆されました。しかし......100年以上も前に設計されたインフラに、今日の通勤客がまだ頼っているとしたら......？電車は満員で、遅れることもしばしば。ニューヨークの年間20億回もの地下移動に驚嘆する人はもういません。昨日までの時代遅れのインフラに頼っている人々は、それを機能させるための新しい、より良い方法を見つけなければなりません。
::
かつてのインフラ・プロジェクトといえば、地下鉄のような大きくて目に見えるコンクリート製のものが一般的でした。そのため、インフラが損傷したときは一目瞭然でした。高速道路がひび割れたり、電柱が倒れたり。老朽化したインフラと調和した生活を維持するためには、多くの作業が必要です。
::
しかし、物事は常にどちらか一方に偏っていたわけではありません。今日、ITインフラ、遠隔地で稼働するサーバー・ファーム、海を渡る光ファイバー・ケーブル、そしてソフトウェア・インフラも存在します。そして、レガシーなオペレーティング・システムや誰も置き換えようとしないシェル・スクリプトのように、このITインフラがいつ古くなり、使い古されたものになるかを見分けることは不可能です。しかし、今日を可能にしたインフラは、古い地下線路のように老朽化しています。これは現代の生活を混乱させる可能性があります。今日のコマンドラインの英雄たちは、過去に縛られないようにしようとしており、その結果、新しい課題が山ほど生じています。
::
プログラミング言語の世界を探求する第3シーズンの第5弾。COBOLはメインフレームネイティブ言語であり、Goはクラウドネイティブ言語です。COBOLはメインフレームネイティブ言語であり、Goはクラウドネイティブ言語です。COBOLはメインフレームネイティブ言語であり、Goはクラウドネイティブ言語です。このことを理解することで、明日の開発者がニューヨーカーのようにペンステーションに押し込められることを防げるかもしれません。
::
::
やるべきことは山ほどありますが、まずは適切でアクセスしやすい情報がたくさん必要です。まだ始まったばかりです。
::
提督
::
こんにちは、クリス・ショートです。
::
クリスはレッドハットのチーフ・プロダクト・マーケティング・マネージャーで、歴史ファンでもあります。
::
ハバード提督は1940年代に当時としては画期的なFLOW-MATICを開発し、COBOLの祖母として広く知られています。彼女はそこに座って、"おい、メインフレームに載せてくれ "とか、"おい、メインフレームに保存してくれ "と言うことができたわけです。
::
これは大きなゲームチェンジャーでした。突然、メインフレーム環境に特化したCOBOLという機械に依存しない言語ができたのです。可能性は徐々に広がり始めました。
::
メインフレームとCOBOLによって、どの組織も、鉛筆、紙、電卓、計算尺を持った人でいっぱいのオフィスはもう必要ないと言えるようになります。そうすれば、COBOLを使ってアプリケーションを書く人を雇い、財務チーム全体が行っている数学、ロジック、会計のすべてを行わせることができます。つまり、完全な手作業ではなく、より多くの入力をデジタル化できるため、財務チームの人数は少なくて済むのです。
::
もしあなたが新人COBOLプログラマーの一人なら、一生の仕事を得たように感じるでしょう。なぜなら、その仕事の基盤となっているインフラストラクチャー（メインフレーム）はずっとそこにあるからです。
::
ムーアの法則はまだなかったので、10年間ずっと同じメインフレームで仕事ができましたよね。次のオペレーティングシステムや、次のタイプのコンテナオーケストレーターや、AIのような次のものを考える必要がないようなものです。キャリアを通じてCOBOLを使い続けることもできますし、非常に安定しているはずです。
::
しかし、やがてムーアの法則が登場。新しいインフラも登場しました。今日、プログラマーが半世紀前の古い言語を学ぶことはまずありません。しかし現実には、古いメインフレームは実際には消滅していません。つまり、COBOL開発者の必要性も消えていないのです。
::
COBOLの開発者を見つけるのはますます難しくなっています。最終的に起こることは、これらのメインフレームが50年前から存在しているかもしれないということです。今でも優れたCOBOLプログラムを書けるこれらの開発者は、プロジェクトを稼動させたり、メインフレーム内のデータ再編成を完了させたりするために、巨額の報酬を得ることになるでしょう。また、このスキルは間違いなく絶滅しつつあり、有利なキャリア分野になりつつあります。
::
特に製造業や金融業では。何十年も前に構築されたインフラをすべて追い越すことはできません。レガシーコードは世界中にあります。この古いインフラとそれに関連する言語を無視するのは大きな間違いです。
::
2,000億行もあるコードをリファクタリングするのは本当に大変です。いや、私が生きている間にそれがなくなることはないでしょう。
::
クリス・ショートはレッドハットのプリンシパル・プロダクト・マーケティング・マネージャーです。
::
クリスの指摘について少し説明したいと思います。考えてみれば、ATM取引の95％にはCOBOLのコードがあり、それがこの言語とのつながりなのです。しかし、COBOLプログラマーの平均年齢は、この言語よりもそれほど若くはありません。45歳か55歳くらいです。新しい人はこの言語に興味がありません。だから、私が紹介したいのです。
::
リティカ・トリカです。
::
リティカは、以前HackerRankで働いていたテクニカル・エディターです。彼女は、COBOLのこの問題に魅了されています：人々はCOBOLを、メインフレーム以降の時代の無意味な名残だと思っているのです。
::
今日の開発者たちは、COBOLについて考えたことすらありません。
::
しかし、これは災いのもと。
::
今日でも、膨大な量のCOBOLコードが組織のビジネスを動かしています。毎年少なくとも15億行のCOBOLコードが新たに追加されています。特定の業界を見ると、本当に面白いと思います。例えば、国税庁には5,000万行のコードがあります。社会保障庁には6,000万行のコードがあります。 つまり、これらの部門や事業体は、今日最も機密性の高い重要な情報を扱っており、これらのメインフレームのサポートと保守を継続しないことは、非常に大きな混乱を招く可能性があるのです。
::
では、古いインフラを取り除くことができず、魔法の杖を振ってメインフレーム・ビジネス全体を再構築することもできない場合、どうすればいいのでしょうか？時に未来のことばかり考えてしまうコーダーは、過去とどう折り合いをつけるべきなのでしょうか？まずやるべきことは、問題に正面から向き合うことです。
::
若い世代がそのスキルを取り戻さなければなりません。あるいは、メインフレームのある種の近代化が必要になるでしょう。いずれにせよ、この問題がなくなることはありません。だからCOBOLはまだ生きているのです。
::
簡単なことではありません。 リティカは、それがあまりにも長い間無視されてきたと考えています。
::
何十億行ものCOBOLコードを置き換えるのは、非常に高価で、困難で、危険です。COBOLは、このような大量トランザクションのために特別に設計されました。そのため、1960年代にグレース・ハバードによってビジネス・トランザクション用に設計されました。1960年代以来、「壊れていないのなら、なぜ直すのか」という議論があり、現在では、何十年も続いている膨大な量の高価値データがCOBOL上で実行されているという状況になっています。
::
ある意味、リティカは文化の転換を求めているのです。イン」と「アウト」に対する考え方の変化。発展途上国が徐々に年を取るにつれて、その歴史に触れるようになります。老朽化したインフラを取り除くことはできません。つまり、プログラミング言語の歴史も無視できないのです。
::
何かをしなければなりませんでした。HackerRankにいたとき、多くの銀行や金融機関がCOBOL開発者をほとんど絶望的なまでに苦しめているのを目の当たりにしました。この問題は解決されるものではありませんし、ある種の近代化されたシステムを導入するか、人材を育成してモチベーションを高め続ける必要があると思います。個人的には、COBOLが再び普及する日が来ると思います。本当に、COBOLの知識を持つ開発者が全員引退して、COBOLを学ぶ新しい世代の開発者がいなくなったらどうなるんでしょう？何かしなければならないでしょう？ですから、COBOLから新しいクラウドベースのインフラに移行する際には、より体系的で制度化された変更が必要なのです。
::
サンフランシスコ在住のテクニカルライター。
::
リティカが言っていたクラウドベースのインフラについてはどうですか？現在構築されているインフラは、COBOLに縛られているように、将来の世代を特定の言語に縛るのでしょうか？おそらく最大の単一クラウドインフラストラクチャは、2006年に開始されました。2008年に導入され、2010年にはMicrosoft Azureが導入されました。 Go言語は並行処理に重点を置いており、新しいクラウドインフラで成功する態勢が整っています。時代の言語です。
::
Google Goチームのプロジェクトマネージャーをしています。
::
カルメンは、Go言語が今日のインフラとどのように関係しているかを深く理解しています。Goの生みの親とプログラミング言語の歴史との強いつながりから始まります。
::
ロバート・パイク、ロバート・グリーゼマー、ケン・トンプソン。 これらの名前は1960年代からあります。 ケン・トンプソンはB言語を発明し、夏休みにUNIXオペレーティング・システムを発明しました。 ロブ・パイクは文字列エンコーディングUTF-8を発明し、ASCIIも発明しました。彼はケン・トンプソンがUNIXプログラミング環境を共同開発するのを手伝いました。この2人は何年も前の同僚で、C言語を含む以前のプログラミング言語で書かれたオペレーティング・システムに取り組み、発明していました。
::
パイク、グリーゼマー、トンプソンの3人がグーグルで働いた後、重大な問題を発見しました。大量同時実行ができなかったのです。コンパイルするのに何時間も待たされました。彼らはC++を使っていて、コールバックやイベントスケジューラをすべて書かなければなりませんでした。それは2009年のことで、インフラは再び変化していました。C++のような言語は、この新しい現実に適応しにくくなっていました。
::
マルチコア・プロセッサー、ネットワーク化されたシステム、大規模なコンピューティング・クラスター、そしてウェブ・プログラミング・モデルがこうした問題を引き起こしています。さらに、2010年までにプログラマーの数が数千人に達するという業界の成長もあります。そのため、それまではどのプログラミング言語も、問題を正面から解決するのではなく、問題を避けているのです。
::
最終的には、変化を始めなければならない転換点に達するでしょう。
::
おい、意地悪なC++。"じゃあ、何か新しいものを発明できるかやってみようじゃないか "って言ったんです。
::
この新しい言語は、最新のインフラに完璧に適応する必要があります。
::
2005年にクラウドテクノロジーが登場してからは、もはや自分のコンピューターは必要なく、ある程度他の場所で借りれば、分散システムを手に入れることができます。しかし、分散システムやクラウドでは、同時メッセージングの問題があります。Goはデフォルトで非同期プログラミング言語です。基本的に、これは実行するすべての操作が、他のマシンの応答を待たずに完了できることを意味します。したがって、いつでも複数のメッセージを処理することができます。
::
つまり、クラウド・コンピューティングは分散型なのです。Goはまさにそのニーズを満たすために開発され、長い間、この分散コンピューティングを行う標準的な方法のひとつでした。Goは間違いなくクラウド・インフラストラクチャの言語であり、その設計の面でも、過去10年間に生まれたクラウド・インフラストラクチャ・ツールやモジュールのエコシステムの面でも、クラウド・インフラストラクチャの言語なのです。
::
まもなく、Kubernetesなどの主要なアプリケーションがGoで書かれるようになりました。また、GoogleはGo Cloudというオープンソースのライブラリとツールセットを作成し、Goの魅力をさらに高めました。明らかに、Goは新しいエコシステムの言語です。クラウドの言語なのです。そして、Goの開発者が、生き続ける言語を開発するという評判を持っていることは、間違いなく損にはなりません。
::
この業界の他の人たちは、"おい、これはすぐにはなくならないよ "と言うでしょうね。この言語の発明者は、たまたま50年、60年と言語を発明してきました。
::
カルメン・アンドーはグーグル囲碁チームのプロジェクトマネージャー。
::
::
幸運なことに、そのような質問をするのに適した人物を見つけることができました。それが下のこの人。
::
言語を将来も使えるようにするには？言語が現在のインフラに対応していることを知ること。何十年も経てば、新しいインフラが古いインフラに取って代わることは間違いありません。では、将来のスムーズな進化を保証するために、今できることは何でしょうか？
::
私はケルシー・ハイタワーです。Googleでデベロッパー・アウトリーチ・アンバサダーとして、オープン・テクノロジーの導入とGoogle Cloud上の製品への応用に取り組んでいます。
::
ケルシーはプログラミングの未来について多くの時間を費やしています。ある日、Go言語のスキルを保持したまま立ち往生している高齢化したプログラマーたちが、現在のCOBOLのブート不足と同じように、別のグループになるのかどうか、興味があります。この長期的な未来に向けた計画はあるのでしょうか？そこで、私はケルシーと対談しました。
::
...などなど。しかし、インターネットやこの種のネットワークを扱うような、今日直面する新しい課題のいくつかを考えてみると、多くのユーザー、何千人もの同時ユーザー、さまざまなマシンやアーキテクチャ・タイプの組み合わせを扱うことになります。このような新しいシナリオを考えると、通常はそれに対応する新しい言語が必要になります。例えば、JavaScriptはWebのためのものであり、COBOLをWebプログラミングに使えるように改造したいとは思わないでしょう。結局のところ、現在では何百ものかなり確立された言語があり、どれも自分の強みに集中しています。
::
では、その場合、人々をCOBOLに積極的に誘導する必要があるのでしょうか？新しい言語がこれらの新しい問題のために開発され、それらは高度にカスタマイズ可能であり、COBOLがまだカーテンコールのために持ちこたえているとしたら、古いコードを維持できるように、人々がCOBOLを選択するよう奨励する必要があるのでしょうか？
::
まあ、ビジネスとしては難しいでしょうね。10年、20年とCOBOLに投資してきたのに、誰も積極的に新しいCOBOLを学ぼうとはしないでしょうし、大学を出てすぐの頃のように「倍返しだ......」とはならないでしょう。
::
そうです。
::
"...この言語は私の両親より古い" ですから、その分野では、COBOLを使い続けるリスクは何か？COBOLは将来的にも意味があるのでしょうか？COBOLはある種の作業にはまだ有益だと思いますが、前に進むべき時なのか？少し進化する時なのか？COBOLのコードがまだ何十億行もあるのなら、残っているCOBOLの人材を探して採用しなければなりませんが、他の言語がCOBOLから何を学び、他の言語に特定の機能やライブラリを追加できるかを考え始める時期なのかもしれません。
::
COBOLが終了した後の時代は、巨大なインフラプロジェクトになるでしょう。ニューヨークの地下に例えるなら、地下トンネルをすべて取り換えようとするようなものです。ですから、先を見据えて、このような問題を予測し、将来の自分自身を助けることもできないかと考えています。
::
今日のクラウド・コンピューティングをメインフレームと比較した場合、古いコードベースや、古いけれども非常に安定した言語を使い、さらに前進するか変わらないかの選択を迫られるような状況に陥ってしまうのでしょうか？
::
クラウドは、1つのメーカーから提供されるものではないという点で少し違いますよね？多くのクラウド・プロバイダーは通常、テクノロジーのコレクションを提供し、ユーザーはプログラミング言語やプログラミング・パラダイム、イベント駆動型か完全なHTTPベースのウェブサービスかを選択することができます。つまり、どのようにプログラミングするかを選択し、あとは解決すべき問題に集中すればいいのです。つまり、データの出入りはありますが、それをどのように扱うかを選択できるのです。
::
メインフレームには通常、1つのメインインターフェイスがありますよね。タスクを書いたら、こうやって送信して、こうやって監視して、こうやって結果が出る、というように。それ自体が限界です。新しいメインフレームについて考えてみると、新しいテクノロジーもサポートしているので、メインフレームの分野でも、タスクの実行に使えるプログラミング言語の拡張が見られるようになってきています。
::
では、新しい選択肢ができた今、この特定のプログラミングパラダイムからいつ離れ、次に進むべきか、自問自答を始めてください。そうすれば、泥沼にはまることはないと思います。
::
その通りです。
::
::
COBOLで起きたようなことが、今日のどの言語でも起きると思いますか？ 囲碁を例にとると、30年後に囲碁を使いたくなるように改良する努力はありますか？
::
すべての言語がこのような運命をたどるのではないでしょうか？考えてみれば、Pythonの歴史は長いです。Pythonの歴史は長いです。Pythonが再び流行し、機械学習の基礎言語になっています。
::
はい。
::
Tensorflowのようなライブラリの場合、時間だけで測るのは正しい見方ではないかもしれませんね。コミュニティが活発か？言語を適応させる意欲は活発か？Pythonは本当に素晴らしい仕事をしていると思います。例えば、Tensorflowの根底には多くのC++があり、その言語でのプログラミングはPythonほどユーザーフレンドリーではないかもしれません。Pythonを使って、Tensorflowのような人々が使っているものを生成することができます。機械学習が流行っている今、人々はPythonをこの新しい分野に導入しています。 Pythonはまだ健在ですし、これからもしばらくは健在でしょう。Goも同じです。Goが活発であり続けることができれば、多くのインフラツールや草の根レベルの多くのクラウドライブラリのように、Goも活発であり続けるでしょう。ですから、これらのコミュニティが将来に居場所があることを確認し、将来が来たときにまだ居場所があることを確認することがすべてだと思います。
::
そうですね。では、どのようにして言語の将来性を確保するのでしょうか？つまり、20年、30年と使い続けられるように、意図的に言語を設計するにはどうすればいいのでしょうか？
::
言語を使っている人たちは、オープンソースの世界では本当にユニークだと思います。マイクロソフトやサン・マイクロシステムズがJavaのような商用言語を提供していた時代には、誰もがベンダーに頼っていました。現在では、Go、Node.js、Rubyのように、コミュニティがサポートし、コミュニティがランタイム環境と言語にフォーカスしています。そうすれば、誰でも新しいライブラリを追加できますよね？新しいHTTP仕様、そう、HTTP/2が数年前に発表されましたが、これらのコミュニティにはそれぞれ特定のライブラリを追加する貢献者がいました。今、これらの言語はすべて、将来のウェブサイトのほとんどと互換性があります。
::
新しいユースケースに適用可能な言語にしたいのであれば、自分たちで貢献すればいいのです。その結果、もはや1社や2社に限定されるものではなくなりました。もしその会社が倒産してしまったら、ランタイム環境は消滅してしまうかもしれません。そのような問題はもうありません。
::
このポッドキャストでも言われていることです。未来は開かれています。しかし、魅力的なのは、あと数十年もすれば過去もオープンになるということを、どうすれば実現できるかを考えることです。彼らが受け継ぐのは、変化し進化しうるインフラと言語なのです。
::
素晴らしい、参加してくれてありがとう、みんなが何をするのか楽しみです。メインフレームは古典的なテクノロジーですから、レガシーと呼ばないでください。
::
古典的でいいですね。
::
ケルシー・ハイタワーは、グーグルの開発者アウトリーチ・アンバサダーです。
::
私が想像しているのは、古典的なプログラミング言語だけでなく、まだ生まれていない新しいプログラミング言語があふれる未来です。それが私の楽しみな未来です。
::
閉ざされたドアに近づかないでください。
::
::
開発の世界で未来を好む傾向。言語は普及している間だけ役に立つと考えられています。しかし、情報インフラの老朽化が進むにつれ、開発の歴史が現実味を帯びてきます。結局、過去は過去ではないのです。これを思い出すことが仕事です。
::
redhat.com/commandlineheroesに アクセスして、COBOLやGo、あるいは今シーズン取り上げる他の言語についてもっと学んでください。たくさんの素晴らしい資料があなたを待っています。
::
次のエピソードはBashについてです。シェルスクリプトの起源と自動化の鍵について探ります。
::
LCTT SIGおよびLCTT LCRH SIGとは何ですか？
参加して貢献すると、レッドハットと共同貢献者限定の証明書が発行されます。
経由
