今日のテーマ

タイトル	： Re: 「問題解決」（problem solving）
投稿日	： 2022/11/03(木) 13:37
投稿者	：としき
参照先	： http://toshiki.la.coocan.jp/
番号	： 10352 　　 10351 番文太さんへのコメント　　　コメント数 4

> 　問題が解決されるべきレベルで書かれる「高級言語」＝パスカル > 　（真の意味で）問題が解決される、ＣＰＵのレベルで書かれる「低級言語」＝アセンブラこれには、さらに上位があるんですよ。つまり、何が問題であるのか、ということ。そしてそれは多くの場合、高級言語よりもさらに抽象度の高い言語で記述されます。いわゆる「自然言語」というやつです。そして、それを徐々に、え～と、なんていうんだろう、スケールダウン？私らの世代では、段階的詳細化、なんて言い方をしました。今でもこの言葉で検索すればいっぱい引っかかると思う。つまり、最初は紙とペンと自然言語。次に、図でわかりやすく。この図形化の部分が、おそらく、ここ数十年で一番進歩した部分だと思う。かつてはフローチャート一択でしたが、今では何とかチャートというヤツが百花繚乱。そして、これもコンピュータで容易に作画できるようになりました。その次がコンピュータ言語っぽいところなんですが、ここはまだ抽象言語っぽいもので十分。私はBASICっぽい、でも純粋BASICではない言語で考えることが多い。ただ、ここの部分は、この発言冒頭で引用している文太さんの発言にあるように、 Pascalで考える人も多いようです。というか、その辺を考えやすいように設計された言語がPascal、というのが設計思想でもあります。で、Pascalで考えたのならそのままPascalのコンパイラにかけてもいいし、さらにほかの言語に移植するのも容易でしょう。私もこの辺は、わりと基本に忠実なプログラミングをしていましたね。昔、大学生のころ、８ビットアセンブラをハンドアセンブルしていた時代。BASIC でロジックを組んで、それをアセンブラに落とす、ということをしていました。 > 　パスカルの教科書の多くに、「問題解決」という表現がいっぱい出てきます。最近の業界事情は知りませんが。かつての情報処理業界では、問題解決をするのがプログラマーだ、という認識がありました。ただ、解決するためには問題を認識しなければならない。そして、当時は、問題を認識するのがＳＥとか、理想と現実の落差が問題であるわけだから、その理想を提示するのがコンサル、なんて分類がありました。これらのうち、問題認識の部分については、かつて、#7387あたりで話題になった『ライト、ついてますか』が話題の中心としている部分だったりしています。あ、今日はそろそろ時間切れ。野ざらしのほうにもいっぱい書きたいことがあるけど、明日以降になるなぁ。

おなまえ
Ｅメール
タイトル
メッセージ auto soft pre(図表、プログラム) ※折り返さずに改行を入れてね

参照先
暗証キー (英数字で8文字以内)
プレビュー