私の計算機言語の原点は1970年頃のJIS水準7000と呼ばれたFORTRANです。実際には大学の選択の講義で1回の実習をしただけです。大学生協でIBM流パンチカードというのを買って、ついでに専用のコーディング用紙が売られていたか。その頃には当時は高性能のTI社のプログラム電卓(TI-59/TI-58)がありましたし、8bitパソコンがそろそろ手に入る時期でした。
この頃のFORTRANは構造化プログラミングの影響を受けていない時期のもので、長方形(処理)と菱形(判断分岐)と矢印(goto: 制御渡し)のフローチャートは必須でした。もちろんフローチャート(流れ図)はアルゴリズムの記述ですから、データ構造の定義として変数表(特に配列)を手書きして、出力はラインプリンタと決まっていたのでコラムの設計をして。この三種の神器を備えれば怖いものなし、でした。
最近買ったFortan90系の教科書の感想です。しかしまだ最初の方しか見ていません、簡単な紹介が終わった後、延々とread文(入力)とwrite文(出力)の解説が続きます。今やっとループ記述のdo文の解説に達したところです。この本、現代Fortranの並列処理まで解説されているはずなので、どういうペースの解説なのかが気になってきました。
ふむふむ、現代Fortranの出力はUNIX流の標準出力とエラー出力のようです。この考え方はWindowsでも引き継がれていて、今の人には常識と思います。
しかーし、元の大型電子計算機の常識では入力はIBMパンチカードで、出力はラインプリンタかデータを再利用したい場合はIBMパンチカードです。実際、IBMのメインフレームの仮想計算機(VM: バーチャルマシン)でも入出力は仮想パンチカード読み機と仮想パンチカード打ち機と仮想ラインプリンタです。当然ですが、仮想計算機の入出力先はディスク上のファイルです。
エラー出力はもちろんラインプリンタで、山のようなエラー解説が印字されて返ってきます。これはコンパイラが最初のコーディングエラーを検出した時点でそれを指摘して停止するよりは、そのままコンパイル過程を進めてできるだけたくさんのエラーを報告した方が便利だとの認識に拠ります。現在のMicrosoft Visual Studio等のいわゆる統合開発系の設計もそうなっているはずです。タイプミスがあると構文が崩れるので残りのコンパイルは出鱈目(ジャーゴンの羅列)になりがちですが、それでも続行解析が好まれます。
なんだか面白そうなのでこのまま読書を続行します。
この頃のFORTRANは構造化プログラミングの影響を受けていない時期のもので、長方形(処理)と菱形(判断分岐)と矢印(goto: 制御渡し)のフローチャートは必須でした。もちろんフローチャート(流れ図)はアルゴリズムの記述ですから、データ構造の定義として変数表(特に配列)を手書きして、出力はラインプリンタと決まっていたのでコラムの設計をして。この三種の神器を備えれば怖いものなし、でした。
最近買ったFortan90系の教科書の感想です。しかしまだ最初の方しか見ていません、簡単な紹介が終わった後、延々とread文(入力)とwrite文(出力)の解説が続きます。今やっとループ記述のdo文の解説に達したところです。この本、現代Fortranの並列処理まで解説されているはずなので、どういうペースの解説なのかが気になってきました。
ふむふむ、現代Fortranの出力はUNIX流の標準出力とエラー出力のようです。この考え方はWindowsでも引き継がれていて、今の人には常識と思います。
しかーし、元の大型電子計算機の常識では入力はIBMパンチカードで、出力はラインプリンタかデータを再利用したい場合はIBMパンチカードです。実際、IBMのメインフレームの仮想計算機(VM: バーチャルマシン)でも入出力は仮想パンチカード読み機と仮想パンチカード打ち機と仮想ラインプリンタです。当然ですが、仮想計算機の入出力先はディスク上のファイルです。
エラー出力はもちろんラインプリンタで、山のようなエラー解説が印字されて返ってきます。これはコンパイラが最初のコーディングエラーを検出した時点でそれを指摘して停止するよりは、そのままコンパイル過程を進めてできるだけたくさんのエラーを報告した方が便利だとの認識に拠ります。現在のMicrosoft Visual Studio等のいわゆる統合開発系の設計もそうなっているはずです。タイプミスがあると構文が崩れるので残りのコンパイルは出鱈目(ジャーゴンの羅列)になりがちですが、それでも続行解析が好まれます。
なんだか面白そうなのでこのまま読書を続行します。