#10417
>訳書で言うところの序論（"Introduction"）の
>最初の５パラグラフほどを読んでいただくと、その先を読みすすめるべきか判断
>できると思います。

　構造化、という文脈で、この本が出てきたのでしたっけ？　たぶん、もう５パラグラフ
読んだと思うけど（最後までできるものなら読み通したいとの判断）、僕との会話で
としきさんが何に引っかかったのか（思い出したか）知りたいので、もう一度読んで
みます。
「序論」後半は、先の各章の簡単な紹介ですよね。
　ただ、元がｐｄｆで上下さかさま（ＯＣＲで化け化け化け化け）のページが「序論」
に入っていたみたいなので、ちょっと１ページごとのe-text作りになりそう。

　具象的個々別々の問題への抽象的解法を見出す。

　僕が日常的にやっている作業より高度なテキスト処理の話だと思うけど、プログラミング
環境を整えるプログラムの作成について、が全体のテーマですよね。
　grep使って、statementだけ取り出す、とか。
　grepの作り方、という話でしょうけど。


冒頭５パラグラフ。
------------------------------------------------------------------------------
	INTRODUCTION

We are going to discuss two things in this book -- how to write programs 
that make good tools, and how to program well in the process. 

What do we mean by a tool? Suppose you have a 5000-line Pascal program 
and you need to find all references to the variable time, to make sure it can 
safely be changed from type integer to type real. How would you do it? 

One possibility is to get a listing and mark it up with a red pencil. But it 
doesn't take much imagination to see what's wrong with red-penciling a hundred 
pages of computer paper. It's mindless and boring busy-work, with lots of 
opportunities for error. And even after you've found all instances of time, you 
still can't do much, because the red marks aren't machine readable. 

Another approach is to write a simple program to find lines containing the 
identifier time. This is an improvement, for such a program is faster and more 
accurate than doing the job by hand. The trouble is that the program is so specialized 
that it will be used once by its author, then tucked away and forgotten. 
No one else will benefit from the effort that went into writing it, and something 
very much like it will have to be reinvented for each new application. 

Finding time's in a Pascal program is a special case of a general problem, 
finding patterns in text. Whoever wanted references to time today will want 
references to some other variable tomorrow, readln and writeln calls the 
day after, and next week an entirely different pattern in some unrelated text. 
Red penciling never ends. The way to cope with the general problem is to provide 
a general purpose pattern finder that will look for a specified pattern and 
print all the lines where it occurs. Then anyone can say 

	find pattern 

and the job is done. find is a tool: it uses the machine; it solves a general 
problem, not a special case; and it's so easy to use that people will use it instead 
of building their own. 
------------------------------------------------------------------------------

　おお、ちゃんとパスカル用になっている。が、内容は同じと言ってよいでしょう。
　ただ、ここまで一般的（抽象的）な問題を解決するツールを僕が開発するとは思えない
ですけどね。grep/sed/awkの使い方を十分マスターすれば良いような気がする。
まだまだ十分でないから。
　逆に、

2022/11/06  18:58    369 srch_do1.def
2022/10/29  11:23    220 srch_do2.def
2022/10/31  22:44    199 srch_do3.def
2022/10/31  23:06    209 srch_do4.def
2022/11/01  01:59    199 srch_do5.def
2022/11/01  02:13    131 srch_do6.def
2022/11/18  11:42    176 srch_do7.def
2022/11/06  18:25    321 srch_do8.def
2022/11/14  01:08    126 srch_do9.def
2022/11/16  00:15    298 srch_doa.def
2022/11/17  17:25    321 srch_dob.def
2022/11/18  11:48    240 srch_doc.def

　これらにちゃんと名前をつけて、管理せい！　という感じですかね。
　あ、これ、もぐら流。中身の変更箇所がちょっとずつ違うだけ。
　これらに一般解はないです。問題のほうが"special case"だから。個別だから
偉いツール群。

　それでも、いい本っぽいと思っています。何かが得られるよう精進したいです。
　ありがとうございます。
　なお、パスカル版の翻訳はないみたいでした。


　蛇足。Pascal版 Intro pp.1-2。ページまたぎ部分。


All of them have been run without change on a variety of machines and Pascal 
compilers. 
				;A
---------------------[End of Page 1]---------------------
				;B
The second concern of this book is how to write good programs.

　このページ区切りフッタあたりに色々なノイズが入ります。Aの箇所にページとか
Bの箇所に"Introduction", "CHAPTER 1", "INSIDE THE IBM PC" (see #10359) とか。
それも壊れて化けたりもして。スペースや改行が入ったりもする。それらをＶｚマクロ
やsedで掃除しています。

　点検は、
>cgrep -A2 -B2 "End of "	;After & Before

　find pattern に同じ。