筆者は偏見かも知れないがと前置きしているのだが．．．
＞BASIC系の人は、ごちゃごちゃとして整理できていない。
＞COBOL系は、とにかくデータ中心に書いている。
＞ハードよりの人は、タイミングチャートもしっかり書いてくる。
確かにその通りだと笑ったり、また少しカチンと来たりもするのだが．．． じゃ’C’の人はそんなに立派な仕様書が書けるのかと云いたくもなる。
BASIC一辺倒の私としては少しは抗弁なりしておかなくてはネ。 確かに言語の持つ特性がそういった傾向になりやすい事は否めない、柔軟と云うかエエ加減と云うかお手軽プログラミングと非力なマシン上での稼働からスタートしたBASICの言語仕様は決して褒められたものではないかも知れない、しかしPCの30年近い歴史の中でBASICの果たした偉業は大きいのである、ただそこから脱却できなかった私も情けないと云えば情けないのだが、多少は豊かな理解力と吸収力があっただろう(少なくとも今よりは)私の20代はLatticeCは27万円もしていて、長らく現業密着の企業内プログラマとしてやってきた私にはとても手にする事はできず、80286の出現でもう手に負えなくなるまでBASIC+アセンブラが唯一の選択肢だった。 個人的な事で全く抗弁にもならないが、インタプリタと画面上で格闘するBASICプログラマと、連続用紙に埋もれながらソースと格闘するCOBOLプログラマ、ラダー図を拡げプロコンと格闘しデバッグのリスクが大きいハード寄りのプログラマの間には言語よりも育てられた環境の大きな違いがあったのである。
しかしWeb系のスクリプトのルーズさは昔のBASIC顔負けの様な気もするけど、普及に大きく貢献しているのでしょうネ、きっと。
VB.NETで構文が厳密になり、「テスト駆動開発」なんて言葉が取り沙汰されたりするのだが、はてこれからどうなるのでしょうネ。
1985年に出版された本で、当時の事ですからNEC/PC9801に搭載されたN88BASIC(86)を前提に書かれています、序文からつらつらと眺めるといまさら色々と考えされられる事もあります。 BASICで構造化を云々するのはナンセンスだなんて云う人もいますが、エラー処理も構造化できる様になったVB.NETの時代になってもう一度読み直しても面白いかなと思ったりしています。
これは1986年に発売された本、当時ライフボートから発売されたCインタプリタの解説書です、でそのRUN/Cはいつのまにか姿を消しました、何故でしょ。 BASICプログラマのC移行への一助になったたのでしょうか．．．
ところでこの本の著者は今もSQLやADO関係の書籍で活躍されてますネ(^_^)
PS:Windyさんのツッコミ期待してます(^_^;) ．．．と思ったら八重山行ったんだって、何処でそないに稼いでいるんやろ。
なんかご指名があったようなので・・(^_^;)「構造化BASIC」私も読みましたよ（今でも本棚にありますが）。
当時は「BASICをやると頭が腐るからやらない方がイイ」なんてBASIC害毒説まで流れてましたネ。
懐かしいです。
私もBASICから入ったクチなんですけど、最初に触れたのはカシオのポケコンBASICでした。
それからMSX-BASICに移り、この時点で基礎ができあがってしまったわけで・・。
私は未だに試行錯誤的プログラミングのクセが抜けないですね。
最近それが結構いいと考えるようにもなってきてるんですが。
（コメントは400字以内と言われてしまったので分割して書きます。
）CP/Mで一世を風靡したTurbo Pascalに初めて触れたときはカルチャーショックを受けましたね。
Pascalというのは非常に厳格な言語でいい加減な記述を一切許しませんので構造化プログラミングのお手本と言われていました。
その後Cへ移っていったわけですが、Cより先にPascalを学んだのは正解だったと思います。
この時点でPascalの美しさに魅せられ、BASICには完全に見切りを付けて二度と戻ることはありませんでした。
未だにVisual Basicはサッパリわかりません。
ただ現在の考え方から見ると、CもBASICも結局同じなんですよね。
今さらCとBASICの違いを議論するのはデジカメ全盛時代にAFとMFの優位性を議論するようなものでまったくナンセンスに思えます。
K&Rの定義したCは既に古典的な言語となっており、あちこちに古さが感じられます。
実際、Cというのはかなりいい加減な記述が許される言語でBASICと大差ないというのが私の考え方です。
基本的にCもBASICも「手続き型プログラミング」という同じ範疇に入っている点では違いはないのですよ。
つまり「初めに手続き（関数）ありき」という考え方ですね。
構造化されているかどうかは大した問題ではありません。
BASICも後に構造化を取り入れるようになりましたからCとほとんど同じと言ってもよいのです。
これに対して「オブジェクト指向プログラミング」は「初めにオブジェクトありき」という考え方に基づいているので、発想を180度切り替えなければなりません。
最初にオブジェクトを作って、その中に手続きやデータを実装していくという考え方です。
プログラムの記述順序もまったく逆になりますね。
Cの経験が長い人はなかなか取っつきにくいものですが、一度理解してしまうと非常に合理的にできていることがわかってきます。
手続き指向とオブジェクト指向の差に比べれば構造化の有無は取るに足りない些細なことのように思えます。
Cにオブジェクト指向の要素を追加したものがC++だったわけですが、CとBASICの間の壁は小さいのに対し、CとC++の間には非常に大きな壁があると考えています。
ただC++というのはCに建て増しする形で作られたため、完全な意味でのオブジェクト指向にはなってないのがもう一つ気に入りません。
つまりC++で手続き指向的に書くこともできてしまうんですよね。
CとC++を混在させることも可能です。
Cに慣れたプログラマからは取っつきやすいんでしょうけど、オブジェクト指向を初めから学ぶには向いてないと思いますね。
それに対してJavaは初めからオブジェクト指向を意識して作られた言語で、否応なしにオブジェクト指向的にしか書けないようになっています。
Cに比べて構文チェックが厳格で、いい加減な記述を許さないようになっています。
そういう意味ではPascalに近い部分もあります。
私は最近Javaの美しさに魅せられ、現在最も洗練された言語であると考えています。
これからのクロスプラットフォーム時代に向けて、Javaの可能性に賭けてみようと思っているところです。
perlなどのWeb系スクリプトはBASICよりもさらにルーズで、私もああいうのはどうも苦手ですね。
変数名打ち間違えても何も言ってくれないのでわからないし(^^;、複数の記述方法が許されていたりしてどうもスッキリしない・・。
まあ実用本位と割り切ればそれでいいんでしょうけど・・。
あ?、分割めんどくさい・・・(^^;
う?ん、さすがWindyさん。
ちょっと賢くなった気分、有り難うごさいました。
で八重山へは出発できそうですか、現地リポート愉しみにしてます、でもこう気候が良くなると恨めしさが薄れたりして。
400字って少し少なすぎますよネ。
今日仕事の電話がかかってこなければネ・・・。
あとは知らん。
(^^;明日出かける時に降ってなければよいのですが・・。
ちなみに儲けているわけではありません。
出て行くもんが少ないだけです。
(^^;
今の私は「行ける余裕」より「行ける体」が恨めしいですわ(;_;) 週末に客先のラベル出力フォーマットの切替をしなければならないので今週は余裕を持ってゆっくり仕事しますわ。