またWeb検索でこういう記事を見つけた。
全くCOBOLは知らんが・・・いや、ヒデェコードだ(苦笑)。
そこにはこう記述されている。
ちなみにこのプログラムの作成者はChatGPTだ。
だそうだ(笑)。
だからいつも言ってるわけだが、ChatGPTなんかにプログラムを「生成」させても何の勉強にもなんないんだ。
一応また書いておくけど、ChatGPTはネットで公開されているソースコードをデータベースとしてプログラム「らしきモノ」をでっち上げる。
一方、本当に「プログラムを書くのが上手い人」なんてなかなかいないんだ。存在率から言うと圧倒的に「プログラムを書くのがヘタクソな」人の方が多い。
結果として、ChatGPTが統計ベースで動いてる以上、「ヘタクソなコーディング」の方へと引きずられる。
つまり貴方が学ぶのは「ヘタクソなコードの書き方」になるんだ。
よほど(龍虎氏みたいに)上手くやらないと生成AIはプログラミング学習の足を引っ張るだけ、になるだろう。
龍虎氏は、自分でコードを書いて「生成AIに添削させる」と言う上手いやり方をしてる。要はある意味デバッグだよな。彼の「生成AIの使い方」は非常に上手いんだ。
言い換えると「全部AIにコードを生成させても」マズい結果にしかならない、と良く知っている。
さて、その問題のコードを再録しよう。
パッと見ると驚くかもしれんが、確かにCOBOLのコードの印象は、ソースコードが全部大文字ってモンだが、実は全部小文字で書いても構わない。COBOLでは(原則)Aとaは同じになる。これをCase-insensitiveと言う。
C言語が登場する以前はCase-insensitiveな言語の方がフツーで、PascalやBASIC、ANSI Common Lisp(※1)も全てCase-insensitiveな言語だ。
つまり、元々大文字で書こうと小文字で書こうと良かったんだが、最初の標準化(アメリカ国内でのANSI)が成された1968年だとまだモニタの解像度もプリンタの解像度も良くなかったんだよ(笑)。結果、視認性を考えると小文字よか大文字を使った方が良かったわけだ。
逆に言うと、C言語が出てきた頃(1972年以降)、やっとミニコン環境なんかのモニタやプリンタの解像度が良くなった、って事なんだ。
なお、幸いな事に、COBOLは日本産業規格(JIS)でも仕様が制定されているので言語仕様書がJISの方で公開されている(※2)。COBOLはPythonやRustとは違ってキチンとした権威ある公式仕様があるプログラミング言語なんだ。
従って、COBOLを勉強するなら、仕様書に目を通すクセを付けよう。C言語脳のように「一回もC言語の公式仕様書に目を通した事がない」とならないように。
なお、前にも書いたが、言語仕様書はリファレンスマニュアルとは違って、(理想的には)その仕様書に書かれているようにプログラミングしていくと自然とその言語処理系になっている、と言うような性質の文書だ。
つまり、RubyのJIS仕様書に従ってプログラムを組んでいくといつの間にかRuby言語処理系になり、JavaScriptのJIS仕様書に従ってプログラムを組んでいくといつの間にかJavaScriptエンジンになってる、って事だ。COBOLも、仕様書に従ってプログラムを組んでいくとCOBOL処理系になる。
仕様書はこの通り、その言語の細部に対しての記述が書いていて、僕はまだその域には達してないけど、凄腕のハッカーは「仕様書さえ読めば」その言語の入門書を読まずともその言語を使いこなせるようになるらしい。
是非ともそういうトコを目指して欲しい。
なお、COBOLやFortranのような古い言語だとファイルの先頭に色んな下準備をゴチャゴチャ書いてからプログラムを書き始める、と言うような様式になっている。宣言部、とか言うのかね。これを見るとほぼ同時期に登場してるLispのシンプルさは際立ってると思う(笑)。全くこういう様式が要らないからなぁ(笑)。
それはさておき。
このプログラムの問題点はこれだ。
move "なんとやら" to html-line
write html-line
と言う似たような命令が10回も直書きされてる辺り、だ。フツーループを使うだろ、と(笑)。
ヒデェな、ChatGPT(苦笑)。僕はCOBOLは知らんが、COBOLerはこんなコードは書かんだろ(笑)。
しかし、別なトコに問題がある。
その記事の筆者は次のような事を書いている。
出来てもいないのにHTML file 'output.html' has been written successfully.と表示して終了するインチキプログラムであった。
出来てないの?
こっちの環境(GNU COBOL 4.0)だと想定通りに動いてるけどなぁ。
catと言うのはUNIXコマンドで引数に与えたテキストファイルの中身を表示するコマンドだ。
結果、output.htmlと言う名前のテキストファイルは生成され、中身もキチンと作成されている。何も問題はない。
ひょっとしたらGNU COBOLのヴァージョン違いのせいかもしんないが。ChatGPTがGNU COBOL4.0向けのコードを生成したのかもしんない。
その辺は調べてみて欲しい。
しかし問題なのは次の文章だ。
う〜む・・・・・・。ゴメン、何がしたいんだか良く分からん(笑)。
webアプリって何を想定してんだろ。コンパイルしたコードを実行するとWebブラウザが立ち上がってHTMLで書かれた内容が表示されます、とか?
だったらそのコードじゃ無理だ。だってそんな事書いてないじゃん。
いやさ、そのコードって単純に記述された文字列をファイルに書き出してるだけ、だぜ?
Pythonで言うとこのコードとEquivalentだ。何もWebブラウザを立ち上げて・・・とも何も言ってない。COBOLのコードの冗長性のせいで分かりづらいのは事実だがそうだ。COBOLを知らない僕でも分かる(※3)。
例えばPythonなんかだとこのように書く(※4)とWebブラウザが生成したHTMLファイルを引数として立ち上がる。
デフォルト設定にしたw3mテキストブラウザを使ったプログラムの実行結果
原則Webブラウザは端末上で、引数にローカルにあるHTMLファイルを取ると、それを表示するように立ち上がる。
w3m output.html
firefox output.html
vivaldi output.html
ここではPythonだと「端末で打ち込むコマンド」をsubprocessを使って再現している。
なお、それこそChatGPTに依ると、COBOLではこう書けば良い模様だ。
COBOLではPythonのような辞書型もないんで、ブラウザとブラウザの実行のコマンドを組み合わせた配列(テーブル)を作成し、それこそLispで言うトコのassoc(SEARCH-BROWSER)も自分で実装せなアカンく、大変メンドクサイ(笑)。
また、後発の言語のような端末とのコマンドライン引数のやり取りも得意でないらしく非常に面倒臭いアレやコレやになっている。
いずれにせよ厳しい事を言えば、ChatGPTにコードを生成させるだけじゃなく、キチンとそれを読んで「意味」を理解しないで「出来た」「出来ない」だけ言ってても全くプログラミングの勉強にはならない、って事だけは言っておこうと思う。
ChatGPTは結構アホなんだ。
※1: ANSI Common Lispの登場自体はC言語より後だが、ANSI Common LispはLispの伝統であるCase-insensitivityを受け継いでいる。従って、consもCONSもConsも同じモノとして扱われる。
一方、Schemeは現行仕様上Case-sensitiveな言語で(シンボルは)大文字・小文字を区別する。
※2: なお、COBOLのJIS仕様書(2011年に改訂)によると、どうやらCOBOLはcase-sensitiveにするかcase-insensitiveにするか、は実装依存になってるっぽい。つまり、その辺は実装者の好きにして良いようだ。
最初に標準仕様になったCOBOLの時代と違って、今は国際文字コードもあるし、全部大文字として扱うとか小文字として扱う、って仕様が不具合になってきた、って事らしい。
と言う事は、JIS仕様に従った処理系だと手続き名を日本語にしてもいいよ、って事になるんだろう。多分。
※3: なお、COBOLで(ループ込みで)書くとこのようになるが、Pythonだと文字列一つ、でデータを作れるが、COBOLだとMOVE文を「何度も記述する」ハメになったりして文字配列を作らなアカン、とか、モダンなプログラミング観点だと極めて冗長だとしか言いようがない。
いや、ひょっとしたらもっと上手い手があるんか?と思って色々と試したんだが、時間切れだ(苦笑)。
COBOLerの人たちはもっと上手く書くのかもしれないけど、この短時間で分かった事は、やっぱCOBOLの基本設計はALGOL登場以前の古い言語、だと言う事。言い換えると、構造化/抽象化が全然成されてない、と言う感想だ。
悪いけど、ほぼ同時期に登場してるLispが凄すぎる、とか言う感想になってしまった(笑)。
まぁ、現代のプログラミングを学ぼうとする人は使いたがらない/学びたがらないのは当然かもなぁ、って気はする。何か書くのに手間がかかりすぎるんだ。
ちなみに、現代で使われているLispで最も古いのはEmacs Lisp(1976年頃登場?COBOLのANSI化の約10年後登場)だが、Emacs Lispで書いたコードでさえCOBOLのそれより遥かに短い。
なお、人前に初めて姿を表したLispはMIT製のLISP1.5(1960年?)だが、当然実装は残ってない。しかしながら幸いな事に、川合史朗さんがGauche上で動くLisp1.5クローンを作っている模様だ。興味がある人はGauche上で動かしてみて欲しい。最初に人前に登場したLispでさえ、その完成度に関して言うとFortranやCOBOLを遥かに凌駕している洗練された(Sophisticated)プログラミング言語だった、って事が分かるだろう。
MIT系Lispの大雑把な流れ:
LISP1.5(1960年?) ---> Maclisp(1966年) ---> Emacs Lisp(1976年?)
|
|--------------------> ANSI Common Lisp(1994年)
※4: ここでは「自動でWebブラウザを開き」HTMLファイルに書かれた内容を表示させたい、と言った仮定でプログラムを書いている。
これは「Webアプリ」が何を指してるのかサッパリ分からんから、だが、厳密に言うとここで提示したコードもWebアプリじゃない。
例えば、原始的で有名なWebアプリ作成法にCGI(Common Gateway Interface)がある。
CGIは単純に、クライアント(貴方のPCだ)がWebサーバーに情報を送った際、Webサーバーとやり取りして動的にHTMLを生成するプログラムだ。
このモデルでは、サーバーサイドでWebサーバーとやり取りするプログラムが「Webアプリ」(CGI)となる。そして繰り返すが、元々の想定したモデルではJavaScriptはサーバーサイドで動くわけではない。むしろ、動的に生成されたWebページにJavaScriptが埋め込まれていて(あるいはリンク先を参照するようになっていて)、あくまで「実行」はクライアント側のPC(のブラウザ)で行われる(これは原理的にはWeb Assemblyも、だ)。
いずれにせよ、ここで提示したプログラムはWebサーバーとやり取りしてるわけではないんで、狭義の意味では全く「Webアプリ」じゃない。
なお、Webサーバーには2つの意味があって、「ハードウェアとしての」Webサーバーと、「ソフトウェアとしての」Webサーバーがある。実のトコ極端な話、ハードウェアとしてはフツーのパソコン(ラップトップ等のノートパソコン)でもO.K.で、元々の意味だと「Webサーバー」と言うアプリケーションを走らせてるコンピュータ、の事だ。
サーバー専用機、と言うのも基本的にはパソコンと違いがなく、CPUがフツーのパソコンより速いブツを採用してたり(上のモデルを見れば分かるが、「サーバー側でアプリを実行する」以上、処理の負荷はサーバー側にかかり、アクセス過多だと処理が遅くなる)、Webサイトが「24時間営業」な限り、電源つけっぱなしでも安定動作を保証してたり、ハードディスクが壊れた際に予備として「全く同じ内容を持った」ハードディスクを自動で2〜3個作っていて、不具合が生じた時にそっちの方を使う、と言ったような機能が搭載されている(この「いざとなった時の備え」の機能を「冗長性」と呼んだりする)。
古くから言われてる「安く仕上げる」Webアプリの構成をLAMPと言う。これは、OSとしてフリーなLinuxを用い、Webサーバー(アプリケーション)としてはApache、SQLデータベースとしてはMySQL、そしてWebアプリを書くプログラミング言語としてはPerlを用いる、と言う意だ。
基本構成はこれ、ってのは今も変わらないが、要素の一部がすげ替えられたりはする。例えばポール・グレアムはOSとしてはFreeBSDを用い、Webアプリを書くプログラミング言語としてはPerlに加え、ANSI Common Lisp(処理系はCLISP)とC言語を用いた。そしてハードウェアはフツーのPCを使ったらしい。また、Yahoo!もLinuxの代わりにFreeBSDを使っているらしい。
Webアプリと一緒に使うSQLデータベースだと長い間MySQLがデファクトスタンダードだったが、MySQLの権利を持っていたSun MicrosystemsがOracleに買収された事に伴い、Oracleを嫌い、MySQLからフォーク(分離)したMariaDBを採用するケースが現在では多いだろう。なお、Oracleは商用データベースメーカーで、この分野だとMicrosoftでさえ敵わないメーカーで、現在ではプログラミング言語Javaの権利も有している。
Webアプリを作る言語には流行りがあり、PerlがRuby、PHPやPythonに置き換わったり、あるいはサーバーサイドJavaScriptなるモノが導入されたりする。「サーバーサイドJavaScript」ってのは厳つい表現だけど、要はGoogle V8みたいなスタンドアロンJavaScript処理系がサーバー側でPerlの代わりに使われてます、って事だ。
実の事を言うと、「Webプログラミングをするプログラミング言語」は、クライアントサイドじゃなくサーバー側で動く以上、何でも良い、ってのが原則だ。結果、繰り返すが、実のトコプログラミングスクール詐欺師共の格好のネタなんてプログラミング言語は存在しないし、逆に言うと全てのプログラミング言語はそうなり得る。
ただし、単純に言うと
- 文字列処理が得意(生成するHTMLが文字列だらけ、なんで)
- Webサーバーアプリケーションとやり取りするライブラリがあれば便利(そこを自作するのがメンド臭い)
の2点で「Webアプリ向き」と判断されてるに過ぎない(例えばPython、Ruby、PHPなんかはCGI用ライブラリを備えてるが、ANSI Common LispやSchemeの仕様上それは含まれていない)。ポール・グレアムがArcを作った一つの理由が、そのテの「Webアプリを記述する際ラク出来る」Lispを作りたかったから、だ。そして、RacketやGaucheはそのテのライブラリも完備してる(Racketでは「ブログの作り方」の簡単なチュートリアルが存在する)。
一方、COBOLなんかはそのテの(外部でも構わないが)ライブラリがあるかどうかも分からん。そういう意味では「出来ない」のではなく「不利だ」って事だな。
ちなみに、スティーヴ・イエギが書いたエッセイのこの部分の意味も、LAMPを通してみれば分かりやすいだろう。
彼らはObidosウェブサーバを書いた。ObidosがAmazonを成功させたのだ。Obidosがしょぼくなったのは後になってからのことだ。クズを作るエンジニアやWeb開発者、主としてフロントエンドの連中——クズを早く作ることでマネージャを喜ばせるスケジュールに従って動 く連中——がObidosをまずいものにしたのだ。言ってみれば川の流れを詰まらせてしまったのだ。しかしObidosはAmazonの初期の成功の礎石だった。初期にいたすばらしい人たちは、Amazonの神聖なるソースリポジトリに2種類の言語しか入れることを許さなかった。CとLispだ。
つまり初期のAmazonでは、LAMPのAの部分が自作サーバーObidos、そして最後のPがC言語と(恐らく)Emacs Lispだったんだ。
また、GoogleではPの部分がC++、Java、Python、JavaScriptと言う4つのプログラミング言語だ、って事もバラしてくれている(笑)。
(なお、Yahoo!ではC、Perl、Java、Pythonらしい)
いずれにせよ、UNIX系プログラマがWebアプリ作成が得意な理由の一つが、この、「運用されてるWebサーバー」のOSの構成と全く同じ構成で自分のデスクトップ/ラップトップPCが動いてるからだ。自分でUNIXを使ってればWebサーバーも(大方)UNIXなんで「謎はそこには存在しない」。これはMac OS Xでも同様で、WebプログラマがiMacを愛用してる遠い理由にもなる(Mac OS XはUNIXだ)。
反面、Windowsを使ってると殆どのケースでは「Webサーバーで何がどうなってるのか」想像/把握するのは難しい(Windows Serverってのはあるけどな・笑)。
そして同時に、「Windowsを使ってるプログラミング初心者」に対して「Webアプリの作り方を教える」ってのが画餅になる、ってのも分かるだろう。プログラミング初心者がLAMPを構成する、なんつー想定は、あり得ないくらいバカバカしい「仮定」だ、と言う事だ。
※4: Vivaldiは今現在僕が愛用しているWebブラウザだ。かつての(Internet Explorer、Firefoxを含む)三大ブラウザの一角、Operaの開発者がGoogle Chromeの開発版、Google Chromiumをベースにして作り上げたブツだ。個人的な感想だと、Google Chromeは重くなりすぎてるが、Vivaldiの方が比して軽い。
なお、セキュリティの観点から言うと、「新・ブラウザ登場!」とかなった時には適宜乗り換えた方が良い気がしてて、Vivaldiも登場してから随分と経つが、Firefox、Google Chromeに比べるとそれでも新しい。
なお、端末からの起動に関してはMicrosoft Edgeだけは独特のようで、フルパスで指定しなきゃいけなかったりして面倒臭い。単純にMicrosoft Edgeは端末から使用するのをあまり想定してない、って事だろう。
