プログラミングについての導入
こんにちは、readline.fmです。readline.fmは、純読画趣味の2人が何かの本を読んだ感想を雑談するポッドキャストです。
ハッシュタグは、ハッシュリードラインFMです。
Mixi2にもコミュニティーがあるので、感想やワイワイお待ちしております。
ホスト役は、ゲイエイさんと金城です。それではゲイエイさん、よろしくお願いします。
よろしくお願いします。
今なんかこの定型文全然変えないで読んでて、変わり映えしないなーとか余計なことを考えてたらめっちゃ噛みました。
やっぱ慣れてくると、こうあれですね、うっかりしちゃうみたいな。
そうですね。いやー、CIA回しとかないとやっぱりダメですね。
はい、というわけで、今日もかの有名なワインバーグさんの本を読んでいくわけですが、プログラミングの心理学ですね。
はい。
これはあれですね、現代のザ・サイコロジー・オブ・コンピューター・プログラミングなんで。
うん。
まんまですね。
まんまですね。なんか珍しく放題と現代が一緒な本ですね。
うん。シルバーアニバーサリーエディション。
うん。
25周年記念版。シルバーアニバーサリーエディションって言うんだ。
これはあれですね、銀婚式。25年が銀婚式で、それにちなんでシルバーアニバーサリーエディションっていうのをどっか調べてて、なんでこれで言うんだろうなーと思って調べてたら出てきました。
著書の歴史と影響
そっかそっか。
なんかそういうちょっと気の利いたシャレたことをつけてたみたいですね。
うん。おしゃれですね。
なんかエピローグ読むと50周年記念版も書きたいなーみたいなことが書かれてましたね。
書いてましたね。
いやー書いてほしいな。
25年後って、今回読む本って、もともと1971年に出た本だって結構古いですよね。
そうだいぶですよね。
今まで我々が読んできた本で言うと、トムデマルコの構造化プログラミングとか、あの辺の本とかが70年代とかだったかな。
人月の神話と本を読む本、覗くと。
覗くと。
あれは100年近く経っちゃってるんで、あれを覗くと人月の神話が多分一番古いは古くて、どうなんだろうな。
今見ると1975年だそうですね。人月の神話は。
うん。
現状は。
だからデマルコのプログラミング系の本の方が前か?
しかしたら、ちょっと過去の、構造化分析とシステム使用が78年とかですね。
現状ですか日本語?
現状ですね。
品質と生産性を重視したのやつはちょっと、1982年って書いてありますね。
なので、やっぱりそれらよりも古いっていう感じですね。ちょっとこっちの方から。
ダメだな、80って聞くとちょっと、結構最近なんだみたいな気持ちになり、全然そんなことないので。
そうですね。
生まれる前のことを最近とか言うと頭が混乱するから。
どういう時間軸で生きてるんだっていう感じになりますね。
だいぶ古いですよね、かなり。
もう50年経っちゃいましたね。
ああ、経ってますね。
経ってますね、初版から。ただしワインバーグさんは亡くなっているので、21年に亡くなっているので、50周年版は書かれることができなかったという感じですかね。
いやあ、聞いてみたかったなあ。
いやあ、聞いてみたいですね。
聞いてみたいですね。
ソフトウェアが世界を飲み込むとか言ってた時代が?
2005年ぐらい?4年とか5年ぐらいかな?
違う、ごめんなさい。全然間違えました。ソフトウェア機器の方。
ソフトウェア機器が70年代とかじゃなかったかな。
あれ?70年代でしたっけ?
もうざっくり過去みたいな感じになっちゃってるかな。
昔。
60年代の末ってソフトウェア機器が。
そうですよね。
NATO会議みたいなやつですよね。
そうそうそう。だからそのぐらいの時期。
時期というか、プログラミングとかソフトウェアの社会的な産業においての重要性っていうのが十分高まってきた。
高まってはいる時代背景ではありますね。
まあそうだよな、本出すぐらいだもんな。
まあそうっすね。
じゃなやつ誰が買うんだよ。
まあでもこれ以上大規模なソフトウェアっていうのが作れるのか本当にみたいなこととかいうような不安がなされていたぐらい。
ソフトウェア的にもハードウェア的にも今後本当にこのまま成長できるのかみたいな話はあった中で書かれた本っていう感じですね。
いやー全然わかんねーなー。
これは昔の本だなーって感じがしましたね。
そうですね、なんかやっぱり読んでてちょっと時代が違うな、この前提がわからないみたいなことはいっぱい出てきましたね。
あまりにもピンとこないなーっていうところがありつつ、まだここは本当に変わらないし今でも見かけるよねっていうような話題もちょっと何割ぐらいかわかんないですけど、全然普通にありましたね。
具体的な本当に事柄みたいなものに関してはあまりこう、7割8割とか今もあるよねーとは言い難いんですけど、
より抽象的なというか本質的な部分だと、ここは全然今も変わってないんだなーっていうところは多々ありましたね。
そうですね、そうですね。
なんかそういう間違い探しをしながらじゃないですけど、ここは変わってないね、ここはもう見なくなったね。
見なくなったとしたらなんで解決できたんだっけ、それとも回避してるだけなのかなとか、そういうところで思いを巡らせながら読むのがいい読書体験につながるんじゃないかなーという気がしました。
キレイごと言うとそんな感じ。
心理学的側面の重要性
そうですね、今キレイごと言ってもらってそれすごく賛同だったので、ちょっとキレイごとじゃない視点で自分の感想を喋ると。
汚れ役を押し付けたみたいになってしまった。
やっぱなんか帯に永遠の名著、大謀の復刊とかついてるんですけど、やっぱちょっと今の人が読むには結構厳しいものがあるなーっていう気がするし、
通じづる話はたくさんあるものの、その部分って別にじゃあこの本じゃないといけないかって言われたらそんなことないっていうことが多々あるし、
今まで読んできた中のトムデマルコだったりワインバグだったりの他の本でも同じような話ってされてる部分もあるので、
なんかわざわざそこ、この本にこだわって読まなくても全然いいかなっていうような気持ちになりました。
なのでちょっと読んでて、うーんっていう気持ちになりながら結構読むことが自分は多かったですね。
そうですね、いやそうなんだよな。
コンサルタントの秘密とかね、スーパーエンジニアへの道とか、やっぱりここからどうやって追従していこうかみたいなエッセンスが非常に多かったなと思うんですけど。
なんかこっちは何ですかね、時代っぽい話が多かったんだよな。
もうちょい抽象的な書き方できそうなんですけどね、この人。
そうですよね、そうでしたね。
よりエッセイ風にするとか。
なんかずっと酷いプロジェクトの、よくプログラマーとかエンジニアの話をしてるなーって思って。
忙しいけど、じゃあワインバーグに寄り添ってそのレスポンス、その疑問に答えようと思ったら、
多分この本って、この本の後にさっきのコンサルタントの秘密とか、ライトついてますかとか、スーパーエンジニアへの道とか、いい本っていうのがどんどん書かれていったので、
割とこういうプログラミングの心理学みたいな本を書いて、そこから得られたような知見だったり、フィードバックだったりっていうのが、その後の本に生きてたんじゃないかなっていう、ちょっと肩を持つようなアングルを取ってきたんですがどうでしょうかみたいな。
すごい、交互に綺麗なことを言うみたいな展開になってる。
忙しい人みたいになってしまったけど。
でも前書きかな、25周年版の方かな、ちょっと忘れちゃったんですけど、プログラミングないし、プログラマーに焦点を当てた心理学的な話ってされてないよね。
より、この後に人間学っていう話とかもどんどんやっていくと思うんですけど、人間的側面とか、ハードスキルソフトスキルとかっていう意味でのソフトな部分とかっていうのを無視していくわけにはいかないよねっていうのを本格的にここから探究し始めた感じはありますよね。
だからこそ、このめちゃくちゃクソデカタイトル、プログラミングの心理学っていうふうに生きてると思いますし。
だから逆に言うと、ゲインさんが今言った通りで、この後にどんどんどんどん宣伝されていくし、やっぱり発信した人のところにフィードバックが集まってくると思うので。
こういう出版とかしたり、講演とかしたり、ワークショップやったりっていう中で、ワインバーグ自体の絵がすごい短中を深めていったんじゃないかなっていうような感じがしますね。
だから、すごい乱暴な言い方をすると、このテーマについてはまだまだ入り口にいる青臭いワインバーグの語り口みたいなところはあるかもしれなくて。
それがさっき言った、全然抽象化もっとできそうなのになっていうふうに感じる部分だったりだとか、本人の中ではまだまだ上流がこれからやっていくんだっていうような段階で出してるのかな的な気がしますけど。
50年前にこんな話をしてる中で、やっぱりすごいなぁはすごいなぁなんですか。
そうですね。なんか先見の目がありすぎるというか、まだまだみんながソフトウェア機器だったりとかの話をしてる中で、ここからはもちろんソフトウェアのことも大事なんだけども、人間の方。
この本の前書きの書き方でいくと、工学や数学ってものは、工学っていうのはエンジニアリングですね。数学は洗練されているが、心理学的側面はまだまだ未熟であるっていうようなところを言い方をしてて、その心理学的側面の方に、じゃあもっとフォーカスしましょうねっていうことを言ってて。
いやいや、でもソフトウェア機器みたいな話があって、まだまだ、こういうエンジニアリングっていうのはソフトウェアエンジニアリングっていうよりはもうちょっと広いエンジニアリングだと思うんだけども、でもソフトウェアエンジニアリングだってまだまだ未熟というか、まだまだ考えないといけないことがたくさんある中で、心理学的側面っていうところに目を向けるっていうのは、なんかちょっとみんなと見てる視点が違うんじゃないかなって。
プログラムの歴史と価値
当時いたわけじゃないんで、自分がいたわけじゃないんでわかんないけども、残ってる本とかを読んでいくと、この人はちょっと違うところを見てたんだろうなっていうふうにちょっと感じる部分はやっぱありますね。
すごいですよね。いや売れなさそうですよね。
そうですね。
出版社に企画持ち込んで断られたとか、担当編集担当してくれた人がクビになったとかっていう話がなされていて、でなんかそんな話を前に読んでた2冊もどっかでもしてた気がするし、だから早すぎるんですよね多分時代に対して。
確かに。
そうですね。
まあまあ早すぎるというか生き残ってるから、ギリギリ時代は追いついてきてるのかっていう感じもありつつ。
でもなんか無理矢理頑張って25周年版復刊させたみたいな感じだったような気がするから、若干この残らなさもあったんだけど、まあこれはやっぱり生き延びる必要のある本でしょっていうところで、当時があったみたいな感じ。
結構ギリギリではありそうっていうのはありましたね。
でもこれ25周年版として面白いのは、なんか1章とか1部ごとにこの部を振り返ってとかこの章を振り返ってみたいな、ワインバグ自体自身の言葉が載せられていて、そこの中で今だったらこの話はもう書かないなとか、ここは見方が変わってるなとか。
もちろんこの章は今でも変わらず価値を持っているだろうっていうようなコメントもあるところにあるんですけど、なんかいいですよね、ちゃんと自分で批判してるというか。
本に書かれたことってやっぱり時を経ても変わらぬ、普遍の本質的な価値を持ち続けるものだって思うとやっぱり読んでて辛いじゃないですか。
こいつやっぱ昔だから見方が古くせぇし間違ってんなぐらいの感じで、ちょっと読んでいくぐらいの態度が本当に古典とかクラシックって言われるような本であっても、そこが大事なのは変わらないと思うので。
なんかそういう意味でワインバグ自体が自分の言葉で、いやここはもう古いねとか言ってるっていうのはすごい面白いなって思いましたね。
そうですね、やっぱ過去の自分を肯定するのかなと思ったら結構バッサリ、いやここはもう古いねとか、当時の自分はこれ書いたけど今だったらもうこの章まるごと書かないかもねみたいな感じまで言ってるから。
言ってましたね、言ってましたね。
なんかそういう意味ではすごく、ちゃんと時代が変わってるとか成長してるとかっていうところを本人が捉えながら、過去の自分がやってきたことの良かったところ悪かったところみたいなところをバッサリ言ってるっていうのは、なんかすごく態度としてもなんていうか真摯だったり正しい、いいなって思いますね。
そこまでやるんだったらじゃあもう一回リライトすればみたいなところはあるんですけど、多分意図的にこの形式でやってる部分はあって、25周年版に寄せての2ページ目とか見ると、
通常若い人たちには欠けている歴史的視点を示すためとか、当時推察していたことを改めて検証するチャンスとしてっていうようなことが書いてあって。
どこまで立てつけているかあれかわかんないんですけど、そういう機能を持たせるためには本部はなるべくそのまま残して、ちょっとレビューを自分で入れるっていうのは確かに面白い提災だなっていう気はしますよね。
まあいっぱい書いたんでね、新しい本いっぱい書いたから、もう一回その新しいことに関しては新しい本を読んでもらえばいいし、というところは多分あるから、じゃあこの本を25周年っていうところで出す価値みたいなところを考えた時には、
そういうような過去のものはそのまま残しながら、それに対してコメントしていくっていうフォーマットが良かったんだろうなっていう気がしますね。
まあ滅多なところで言うとそんなところですかね。
と言われているプログラミングの心理学に。ちょっとじゃあ本編入ってきますか。
プログラミングの構成
そうですね。
全体の流れとしては、五部構成でしたっけ。
まあ五部構成なんだけど、実質四部構成で五部はエピローグみたいな感じですね。
そうですねよく見る。
この本とよく見ますね。
最初が第一部人間の行動としてのプログラミング、第二部が社会活動としてのプログラミング、第三部が個人の活動としてのプログラミング、第四部がちょっとアングル変わっててプログラミングの道具って感じですね。
メインが第一から第三部かなという感じ。
そうですね。
第四部はどっちかというと個人の活動としてのプログラミングにちょっと別の領域から踏み込んでいくというか、通路によってどういう影響を与えているんだっけというような話が入ってくると。
そうですね。
まあ素直に前からいきますか。
そうですね前からいきますか。
人間の行動としてのプログラミングですね。人間の行動としてのプログラミングというのは何だつまり。
一応章立てとしては3章あってプログラムを読むっていうのと、良いプログラムとは何か。でプログラミングをどのように研究するかっていうふうな章立てにはなってますね。
そうだから機械の上で動くものだよとか、そういうのに対して人間活動としてってそこにお話をしていくよっていうような部のタイトルですね。
とりあえずちょっと第一章触れてみますか。なんとなくどういう感じかわかるかどうか。
そうですね。
まあプログラムを読むなんですよね第一章が。ただ現代の多分我々の感覚のプログラムを読むっていったときにIDの上とかVSコードとかPHPストームとかいうとこで多分コード読むっていうのと
多分この1970年ぐらいのコードを読むっていうのは多分前提が全然違うんだなって気がしますよね。
そうそうこの本は基本的にあれですもんねパンチカードかなに食わせる。手元でコンパイルも動作確認もできないんですよね。
そうですねだから紙の上で書いたりとかパンチカードだったりとかみたいな時代背景って思うとなんか全然そのプログラムを読むぞっていったときのその読む前提が違うよねと思って
ちょっとここは最初面食らうというかなんか全然違うんだなとりあえず頭を切り替えなきゃなっていう風にまず思ったりもしましたね。
めちゃくちゃ今の我々からするとめちゃくちゃフィジカルな活動ですよね。
そうそうそう
めっちゃ物理みたいな。印刷我々今の我々でもわかるような感覚で言うとプリンターで印刷するのを待つとかそういうのに近い。あれをGitプッシュの代わりにやるんだろうなみたいな感じですよね。
一応上の世代の人と喋ったときにギリギリ紙に書いてたことありますよみたいなそれはなんかパンチカードとかではなく紙に書いていてその紙に書いたものを
いわゆるあのデカいコンピューターパソコンじゃなくてデカいコンピューターが会社にあってそれに打ち込んで実行するみたいな体験はしたことありますというのはギリギリ上の世代で話は聞いたことあるんですけど
同年代とかちょい上ぐらいになるともうパソコンあったからもうわかんないんだよなーそういう話すら聞けないんだよなーみたいな。
僕の絵にプログラム用紙ありますよ。
すごい。
登壇するためのインプットをちょっと整えようと思って買った本がこぼれの本だったんで、付録でプログラム用紙がついてますね。
じゃあそれを印刷してみんなで書いていくわけですよね。
そうですね。いや大変だよな。大変だよなというかそこら辺からわかんないんですよねちょっとこの本が何騒いでいるのかが。
大変だったのかすらよくわかんないんだよですよね。
なんか逆に多分今の我々からしたら例えばそのフィジカルにその複雑さみたいなものってその紙というものの制約があるからむしろわかるんじゃねとか一望できるというか希望感が。
今だとなんかその業数とかバイト数とかでサイズ全体のサイズがどれぐらいですかとかいう話はわかるんだけども。
物理的な感覚としての希望感みたいなものはやっぱりわかんないからむしろ昔の方がわかりやすかったのではみたいなことをちょっと思ったりもしましたね。
なるほど。いやでもコードジャンプできないの厳しいよな。
でもコードジャンプできなくてもわかる程度の複雑さまでしか多分できないと思うんですよね。
人間の脳に収まるところで耐えてるというかまあまあ規模大きくなっちゃうと全然そんなことないのかもしれないですけど。
我々なんかね最近で言うともう人間の脳に収まるわけねえじゃんっていうのを前提にして構造化して隠して隠してみたいなことやってるわけで。
そうそうそう。
まあとはいえねあの別にアセンブラー、アセンブリ言語ばっか出てくるみたいな話ではなくてちゃんとアルファベット使ってアルファベット書かれてるんで。
サンプルコードとか。
そうですね。
まだ読めますよねプロシージャーとか書いてあってGoToとかそんなに出てきてないからジャンプとか。
そうそうそうなんかドゥホワイルみたいのもあるしエンドっていうのもあるからなんかこの辺ループしてんだなとかここからここまでがなんかクリなんだなとかいうのはなんとなくなんとなくわかりますね。
そうですねだからスパゲッティコードではない。
そうそうそう。
まあでもそんな背景がありつつの第1章プログラムを読むですけどなんかここはどうですかどこら辺が面白かったなとか。
プログラムを読むっていうのがまあクリエイティブかっこよく言えばクリエイティブだしすごい難しい複雑な活動だよねっていうところはやっぱり変わらないよねって感じはしますね。
そうですねそうですね。
なんか心に染みた部分とかありますか。
でもそうですね金城さんもメモで書いてくれてるけどあの言語の制約みたいなところによってこう書かれ方が変わってきたりとかする部分みたいなところとかいうところはまあやっぱり現代においてもまあ一緒だよねみたいな気持ちになりましたね。
10ページとかですよね言語の機能を十分に知らないこれを語彙の制約ぶらぶらりの語彙の制約と呼ぼうという以外にもプログラマーの制約はある例えば特定のアルゴリズムを知らなかったとか問題を大きな視点で捉えられなかったために重複を避けられなかったという場合もあるって書かれてて
いきなり言語の機能以外にもって話になっちゃったんですけど知らないとは知らないことってわからないですもんねって言うこともないけどそこなんですよね。
プログラミング言語の理解
この似た話で現代においてもよくあるなって思うのが配列からなんかの要素だけをディクショナリーの配列からこのキーの値だけを取ってきた配列を作りたいみたいなときにPHPでfor eachでぐるぐる回しながらその値を取ってきて配列に追加して作り上げるみたいな
っていうのをなんか行動を見たりするんですけどでもこれあれからも使った立派2で1行で書けるじゃんみたいなこととかあるなっていうのをたまに思うんですけど
でもこれ多分なんかその人がなんかあえてそうしてるってよりはただ単にその関数を知らなかったからそう書いて自分が持ってる手札で精一杯やった結果はそれであって
それって別に実は言語にはそういう機能があるんだよねとか逆に言うと言語にそういう機能がなければそうやってループで書くしかないんだよねとかいうことはあったりするよねみたいなことをちょっと思ったりしましたね
かといって全部の標準関数だったりだとかっていう語彙をみんながちゃんと知らないといけないかっていうとなかなか水準どこでしようみたいなのはありますよね
PHPの配列とか関数めっちゃ多いからな
あれいっぺけっぺけって何回あのドキュメントの一覧を眺めに行ってなんかそれっぽいのないかなみたいなの探したりとか定期的に見るけどなんかこんなのあったんだとか知らないものとかって知らないもあるしなんか使い方が思い浮かばないから頭の中に残ってなくて後々こう他の人が書いてることを見てこうやってこれ使えるんだとかいうこともよくあるし
まあ知ってるものでもなんか第三引き数に実はこれが設定できるんだってこれ設定するとこういう振る舞いするんだみたいなとかその細かい挙動まで全部把握してるかって言ったらそんなこともないしやっぱ全てを知るっていうのはやっぱ無理なんで
そうですねフレームワークのコレクション系のライブラリとかめっちゃなんで法一してるんだろうみたいなところで自問自答してみると確かにみんなコレクションライブラリのAPI全部覚えてるわけじゃないからかみたいな気持ちになったり
あとね普段書いてる言語にはあるけどこっちの言語だとやっぱそれがないみたいなことでいっぱいあるじゃないですか そう我々で言うとやっぱりバーダンプがどこにでもあってほしいなって
そうですね 別の言語を言った瞬間にバーダンプしたいんだけど何て書けばいいんだろうみたいな コンソールどっかバーダンプどっちかあってくれみたいな
でもあれですよねよりプリミティブなそれこそマップリリースとか使わないで全部ループで回すとか
まあ法一ぐらいは知っててほしいのはPHPGではあるんですけど そうですよね
ある程度の基準式一みたいなものがあってそこの語彙レベルに達してないコードになってくるとやっぱり結構しんどいなってなっちゃいますもんね
小学生にはわかるように話すみたいなのと近い思考の切り替えというか思考負荷みたいなものが発生するなという気はしていて
そうですね ループするんだからって言ってじゃあループを入れて全部書かれたらそれはそれでやっぱしんどさもあるしな
僕ちょっと前から全部GoToで書けるようになったんで ループをGoToにすることができます
それをミスなく実装できるかと言われたら
メンテはする気もあるんですね
知ってるものを全部継ぎ込めばいいかっていうと自分が書いてるうちにわけわかんなくなりますからね
これは全部あれぺけぺけで書けるからつってマップとあれマップとあれDDSとかで全部書き換えていって結局そのマップのスコープの中がめちゃくちゃでかくなってきて
何やってんだっけなみたいなのがやたらif elseいっぱいあるなとかになっちゃうと結局メンテナンスができないみたいなことが起きちゃったりして
なんかfor eachとかで書いたほうがもっとすんなり勇気出しこれ別メソッドに切り出しも簡単だったのではみたいなこととかいっぱいあるんでね
あとね昔あれじゃないですかPHPユニットのassert equalsに引数が7個ぐらいあったので
それ本当に全部使うみたいな名前付き引数がない時代ですからねまだ
辛い
5番目がヌルだからこのテストはフレーキーですとか言われても5番目なんだっけみたいな
IDがあればまだ5番目が何かっていうの見えるけどそうじゃないと結局ドキュメントを読みに行かないといけなかったりしますからね
面白いですよねなんかプログラミング言語の設計みたいな話が最後の出てきましたけど
やっぱりテスティングフレームワークとかテストツールってなんだそのプロダクトコード本来のコードの読みやすさをサポートするべきっていう役割があるにもかかわらず
PHPユニットが持ってるassertionメソッドがバッドデザインになってるせいでなんか良くないコードを書く
良くないテストコードを書けるようにするってことは良くないコードを書くことに助長してると思うので
そういう道具によって人間の思考が影響されるみたいなこのプログラミングの心理学的な側面を感じて非常に面白いなーっていう気がしたところで第二章いきますか
テストツールの影響
いきますか
