1959年に開発されたプログラミング言語「COBOL」は、自然言語に近いコマンド構文が採用されていることから、金融や自動車、医療業界などで広く使用されています。しかし、柔軟性に欠けるCOBOLを扱える人材は減少傾向にあり、COBOLを用いたシステムは窮地に陥っています。このような状況を打開するために、IBMはCOBOLを最新のプログラミング言語に変換できるジェネレーティブAI「watsonx Code Assistant」を開発しています。
1959年に開発されたプログラミング言語「COBOL」が抱える現代の問題にIBMはどう立ち向かっているのか？ - GIGAZINE
⇧ ということらしいのですが、
非理系の事務員や官吏でもプログラミングできる言語として設計されたため、自然言語である英語に近い記述をめざしたコマンド語彙や構文（シンタックス）が採用されている。特に金額計算など事務処理用に広く使われている。COBOLは自然言語（英語）に近い構文を持つため、そのソースコードは記述が冗長にはなるが、可読性が高い。本のように、部、節、段落、文という階層で記述される。人によっては関数や数式だらけの言語よりもハードルが低い。リフレクションができないなど、モダンなプログラミング言語に比べて論理制御機能は貧弱である。一方、文字列解析や文字列編集、帳票、画面編集などの事務処理機能は豊富である。
⇧ というWikipediaの話が事実だとするならば、何故、COBOLを扱える人材が不足しているのか、疑問なんだが...
『非理系の事務員や官吏でもプログラミングできる言語として設計されたため、自然言語である英語に近い記述をめざしたコマンド語彙や構文（シンタックス）が採用されている。特に金額計算など事務処理用に広く使われている。COBOLは自然言語（英語）に近い構文を持つため、そのソースコードは記述が冗長にはなるが、可読性が高い。』
ってあるんだから、エンジニアじゃない人でも保守・運用していけるような言語の設計になっていると読み取れる書きっぷりになってるし。
おそらく、
- 開発、保守・運用をエンジニアで行う
- 開発、保守・運用をエンジニア以外で行う
1.で考えてるから、人材が見つからないってことなんじゃないのかね？
そもそものCOBOLの言語の設計が、エンジニア以外でも利用できるようになっているっぽいから、無理に別の言語でリプレースせずにCOBOLのままのシステムにしておいて、エンジニア以外で頑張ったらどうかという話にならないのかね？
ただ、実際は、何と言うか、
1959年に開発されたCOBOLは、「コーディングが複雑」「タイピング量が他言語と比べて多い」「コーディング形式に柔軟性がない」などの問題を抱えながらも、数十年にわたって銀行や自動車、保険、政府、医療、金融などの業界で使用されています。
1959年に開発されたプログラミング言語「COBOL」が抱える現代の問題にIBMはどう立ち向かっているのか？ - GIGAZINE
⇧ 可読性が高い、の真逆を行っている気がするんだけどね...
調査機関のInternational Journal of Advanced Research in Science, Communication and Technology(IJARSCT)の(PDFファイル)2022年の調査では、全ての銀行システムのうち43％がCOBOLを使用しており、毎日3兆ドル(約420兆円)もの取引を処理していることが報告されています。
1959年に開発されたプログラミング言語「COBOL」が抱える現代の問題にIBMはどう立ち向かっているのか？ - GIGAZINE
⇧ 上記で言及している銀行システムの総数が分からないから、何とも言えんけど、
しかし、COBOLに関しては多くの専門学校や大学が数十年前に指導を停止しており、今日ではCOBOLの学習に関心のある人物がほとんどいないことが指摘されています。そのため、COBOLが使用されたシステムを保守できるプログラマーが減少、高齢化傾向にあり、後任の人材を見つけることも困難になっています。
1959年に開発されたプログラミング言語「COBOL」が抱える現代の問題にIBMはどう立ち向かっているのか？ - GIGAZINE
⇧ 他の言語でシステムを作り直すことを考えているなら、
- COBOLでの実務経験が豊富な人材が引退する前に手を打つか
- AIの精度が上がるまでシステムを塩漬けにするか
決断は早めにした方が良い気はしますかね。
COBOLの人材が輩出されない流れに向かっている、ってことと、システムの保守・運用を考えると、他の言語で作り直す方針になる気はしますけど。
一方でIBM Z Software担当バイスプレジデントのスカイラ・ルーミス氏は「watsonx Code Assistantは、AIを使ってコードを変換することが可能ですが、あくまで人間の開発者が必要です。watsonx Code Assistantができることは生産性の向上であり、開発者の代わりを務めるものではありません」と注意喚起しています。また、オルソン氏も「IBMがクライアントに提供できる最先端のAIエクスペリエンスは依然として初期段階です」と述べています。
1959年に開発されたプログラミング言語「COBOL」が抱える現代の問題にIBMはどう立ち向かっているのか？ - GIGAZINE
⇧ う～む、結局のところ、COBOLの実務経験が豊富な人材に、実際に動いているソースコードを元に詳細設計書を作る、リバースエンジニアリング的なことをしてもらう感じになるんかね。
ネットの情報が正しいとすると、ソースコードを読めば分かる、が適用できそうにないということだと思いますし...
シェルスクリプトファイルのshebangは#!/usr/bin/env bashを使うのが良い模様
今回の記事で、本ブログの記事数が868記事目ということで、王さんの通算本塁打868本と同じ数になったのですが、ブログ開始が2014年の10月なので、およそ9年ほどかかりましたかね...。
技術的な検証とかしてると、調べるのに時間がかかって記事にするのに時間がかかるので致し方ないですかね。
これまた、職場で気付きを得たので、備忘録として。
いままで、何も気にせずに、盲目的にシェルスクリプトファイルの一行目のshebangには、
#!/bin/bash
⇧ と記述してきたのですが、
⇧ 上記サイト様にありますように、
#!/usr/bin/env bash
⇧ としておくのが良い模様。
これはコマンドのインストール先が、/bin/、/usr/bin/、/usr/local/bin/など、オペレーティングシステムやバージョンによって変わるため。envコマンドは多くのオペレーティングシステムが/usr/bin/envにデプロイしていることから、一旦envを実行してからスクリプトへ処理を移すことでデプロイパスが異なっていても起動できる可能性が高いとされている。
⇧ 上記サイト様にありますように、OS（Operation System）の差異に影響しにくい、クロスプラットフォーム対応としての記述の方法ということみたい。
あくまで、可能性が高い、ということなので、100%動作が保証されるわけでは無いとは思いますが、betterな方法であることは間違いなさそうな感じですかね。
なので、これからは、シェルスクリプトファイルの一行目のshebangには、
#!/usr/bin/env bash
を使っていくようにしますか。
シェルスクリプトファイルのコーディングのベストプラクティスが知りたいんだけど、情報が見当たらないので、有識者の人にまとめていただきたいところですかね。
何と言うか、
⇧1977年がシェルの発祥の年らしいので、同年にシェルスクリプトが利用され始めたと仮定した場合、かれこれ、50年に近づきそうな歴史を刻んできてるわけだから、シェルスクリプトのコーディングのベストプラクティスが確立されていても良いと思うんだけど...
毎度モヤモヤ感が半端ない...
今回はこのへんで。
