教育と訓練の重要性
で、出書が動機づけ訓練経験。なので、なんかちょっと前にあれですね、あの、MOIの話を前回したりしましたけど、なんかちょっとそこと、なんていうか、連想したりとかもしましたね。
ああ、モチベーションですもんね。なんか触れておきたいところありますか?
ねえ、うーんと、なんて言ったっけな。
アマチュアとプロの話が出てきたのはここら辺でしたっけ?
ああ、そうですね。その話ありましたね。もしかしてアマチュアとプロの話はここじゃなかった?
ここでも出てくるだろうけど、中心的に取り上げてるのを違いそうな気がしてきた。
うーん、そうですね。
うーん、まあそんなに思い入れがある話ではないと聞いてもいいんですけど。
ちょっと軽く話してみたいなって思ったのは、この中で訓練とか経験みたいな、とか同期付けみたいな話をしていて、
教育と訓練みたいな話が出てきて、教育ってのは一般的な原則とかスキルを、イメージとしては座学みたいな感じですかね。
訓練っていうのは現場で具体的なスキルを身につけるために、OJTみたいな感じの話があって、
習うよりも慣れろ、そっちの方が大事で、そういうことのイメージができるからこそ教育、座学が生きるんだよみたいな話があったりするんですけど、
プログラマーって難しそうでもあり、勉強することって、持ち時付け難しそうでもあり、
でも一方で自宅でパソコン買ってきたら始められるから、参入障壁が高いのか低いのかよくわからないみたいな気持ちになったりして、
その辺どうなんでしょうかね、みたいな話してみたいなって思いましたね。
どうなんでしょうかね、いやマジでわからないんだよな。
前提としては学校で教えるようなこと、学校で教えるっていうのは、それを教えたから現場で活躍できるかというとそうではないから、難しいよねみたいな。
参入障壁は高いような気もするよねっていうのはあるんだけど、現代の今の我々の視点からすると高いのかな低いのかなみたいな。
教育的な意味では教育を受けてないと入れないっていうわけじゃ、特に日本においては別に独学で勉強してプログラマーになるっていうのは全然あり得るキャリアパスになってるので、
どうなんですかね、みたいな。
本当に何を持ってみたいな話が出ちゃいますよね。
そうですね。
参入障、例えば0.5人前のプログラマーみたいなものになる上で、0.5人前って何って話なんですけど。
1人前がまずどこなんだって話がありますね。
1人前がどこかがわからないんですけど、例えば何だろう、営業職として0.5人前になるよりかは、プログラミング領域の方が自宅で一人で能力を育むこと、要するに訓練に近いようなレベル上げはしやすい気はするんですよね。
どうなんだろうな。ここは本当に主観というか、自分の目線の話しかできなくて、営業と接客は本当にやってみて無理だったんで、無理としか思ってないんですけど。
そうなんですよね。参入障壁が低いっていうのは、ハードル自体は本当に低いんだけど、ただ独学で続けられるかとか、学習のモチベーションを保つという意味ではちょっと難しいよなっていう気もするんだよなっていう意味で、参入障壁が高いのか低いのか、ハードルが上がったり下がったり繰り返すみたいなことが。
あるよなって。ここで書かれている動機づけ訓練、経験みたいな、どれももちろん大事なんだけども、そこのバランス感みたいなところ、座学と経験とモチベーションみたいなのって、現代に向いてどうなんだろうなっていうのは。
なんかでも、もともと就職食料プログラマーになる前から好きで好きでたまらなくて、10時間とか15時間とかコード書いてました、読んでましたみたいな人とか、全然就職して食料としてやり始めてからもすごいたくさんコード書いたり読んだり、OSSとかで開発も続けてみたいな、明らかにモチベーション高いよねみたいな人とか。
それを20代で社会人になって30代40代50代になっても続けてますみたいな人とかはわかりやすくモチベーション高いし、そういう人は生き残るよねっていう感じがするんですけど、
なんか別にプログラミングそんな好きじゃなくて仕事の中でしかやってないし、そんなに本当に原理を理解したいとか深いところまで納得するまで調べないと気が済まないみたいなタッチの人じゃなくても、食料としてわかんないですけど50代とか60代、引退するまで会社にいるんじゃないかなっていう気はしてはいるんですよね。
って考えると参入障壁って話もそうだし、通用するっていうのもよくわからない。
求められるスキルの幅がすごいありそうな気がしますよね。資格みたいな免許制じゃないから、その辺わかんないですよね。だしプログラマーって直接の売り上げみたいなところとひも付かないから、明確なこの売り上げ到達しなかったらお前ダメなみたいなことも言われにくい。
もちろんサービスが続かなくてとか会社が続かなくて職が流れることはあるかもしれないけど。
個々人の営業ノルマとかみたいな形にはならないですもんね。
すごくわからない職業だなぁみたいなことを読みながらちょっと考えてて。でも人材不足っていうのは続いてるから、やっぱハードルが高いのかなとか。
参入障壁とモチベーション
ハードルが高いから入ってきて長く、ある程度ポイントオブノリタンというか、生き残れるところを超える人が大多数ではないのかなとか。
でもこんだけ家で勉強できるようなものを考えた時に、例えば重機の扱いとかって別に個人でできないじゃないですか。
科学契約品系とかね。
そうそう。に比べたら多分、衝撃はかなり低いよなとか考えると、もっと魅力的だねって思われて、もっと人が来てもいいはずなんだけどなって思ったりもしたりとかして、
この辺難しいなっていうことを思ったりしましたね。
根本的にあれですからね、100人いたら100個売れるようにしようじゃなくて、1人で10個も100個も売れるようにしようみたいなあれではありますからね。
レバレッジが効きすぎるんだよな。
レバレッジを効かせることが本質的な価値、それ以外の全然生き残り方あると思うんですけど。
けど基本的にIT化の最初に言われてた部分って、やっぱり人を減らせるっていうところが多分一番受動化して仕事がオートメーションになって、
人が今まで100人でやらなきゃいけないのが1人でオープレーションできるとかっていうところに価値があるし、最初の頃はフォーカスされてて、
それが多分今では言うとDXみたいなことになってたりとかいう言い方になったりしてたりするんで、
本質は多分それが全てではないと思うけども、結構あちこちでフォーカスされてるのは多分そういうところだったはずなので、
そう考えると人がたくさんいるっていうのはあるしおかしいことかもしれないというか、
そこに気づいたからこそ人を投入していっぱいいろんなツールを作ったら売れるんやっていう話でもあるっちゃあるのかっていう気もするんだけど。
プログラムって言葉自体が工程表とかですからね。流れを作ってこの通りに動かしますっていうのがプログラミングだと思うんで。
自動化でしかないみたいな。
そう考えるとやっぱりレパレッジが効いて人がたくさんいることが大事じゃないとかになると思う。
そうすると人をたくさん連れてくるよりも一人でレパレッジが効く人を採用しようっていう方向にいくし、
それが基準になるとそういうことがどんどん求められていって、
AIのアシストがあるので一人で全部作れるよねって言われて人を減らされて、
上げないといけない成果がどんどんどんどんでかくなっていくという感じなんですかね、直近になると。
そうすると本当に第10章が一体何の話をしてる章なんだっていうのが伝わりづらくなってる気がする。
そうですね。
個人の活動としてはプログラミングっていうタイトルではあるので、
プログラミングの道具と生産活動の変化
一人一人がどうやったらプログラミングやってくれるかな的な話であり、
プログラミングやってくれるっていうのはチャリア的な意味を含めてちゃんと生き残ってくれるっていう話、
どうしたら生き残れるかみたいな話ではあって、だからこそ動機づけ、訓練、経験っていう話。
は出てくると。
そうですね。
そういうアングルで動機づけとか訓練とか、いかにしてプログラマー的な人材っていうのが生産されてくるか的なことが語られてる話。
そうですね。
学校の正式な訓練に期待しすぎると、それだけだとうまくいかんよっていうことをすごく言ってますね。
ちょうど放送大学で面白そうな授業があるねって話を最近してたばっかり。
知ってましたね。
たぶん我々はモチベーションが高い部類にあると思うので、たぶんそういうとこに興味を持つけどみたいな。
そう、訓練とか経験積んだ後に教育っていうのが改めて役に立ちやすいっていうような話はあるんで。
そうそうそう。
まあでも大丈夫でしょう。そんなところですかね。
じゃあ第4部ですね。実質最後の部。
最後の部。
意外と話してる。
意外と話してるけど第4部はもうなんか話すことあんのか。
なるほどね。
4部はプログラミングの道具っていうところで。
振り返ってみますか。
だからプログラミングの周りにあるようなものをひたすら喋ってるっていう感じですかね。
プログラミング自身も言語自身も話の対象ではあったりしましたけど。
まあそれによってね働き方とか生産活動っていうのがどうやって変わってきたのとか。
本編とは違うんですけど、ワインバーグはなんかいろいろツール作ってて、オペレーティングシステムを作ってるし、
たぶんここでオペレーティングシステムっていうと、たぶん今我々が想像するOSよりももっともっと簡素なものだと思うんですけど。
デバッグツール作ったりパフォーマンスアナライザー作ったり、静的動的コードアナライザー作ったりとか、
すごいいろんなものを作ってて、コンパイラだけは作ってこなかったよっていう話をしていて。
逆に言うとコンパイラ以外はいっぱい作ってるのがすげえなって思いましたね。
これコンパイラの話、でもそっか。コンパイラ作ってる人が多すぎるから自分はあんまり魅力になったっていう話ですね。
そうそう。別に自分がやなくてもやってくれるからいいよねっていう話でしたね。
そこはすごい面白いっていうか、ワインバーグってやっぱすげえんだなみたいな。
なんかプログラミングの面よりも違うところがフォーカスされるから。
プログラミング言語の進化
この人そういえばちゃんとプログラマーだったねって思い出すなっていう気持ちになりましたね。
そうですよね。完全に文系の社会学系の博士かなんかかなっていう感じが。
そうそうそう。か優秀なコンサルタントなのかどっちかですね。
全部当たってるんでしょうけどね。
11章がプログラミング言語の話をしていて、当時のプログラミング言語の話をしていて、
やっぱなんかちょっと使いにくいよねみたいな話をしてますね。
これはだから多分今の話になっていくと通じる部分ももちろんあるんだけど、
もうちょっと我々が過去のフォートランとか、こぼるぐらいではそうっちゃそうなんですけど、
いろんなものを見たときに足りない機能が多いよねとか、読んでてちょっとわかりにくいよねっていうことが多分多々あって、
現在に近づいていくと便利になってたりとか読みやすいとか、間違いを起こしにくいように作られてたりとか、
エラーハンドリングしないよねみんなっていうから、エラーを常に改善しましょうみたいな言語が出てきたりとか、
いうふうに進化していってるので、もっとやっぱり現代においては使いやすくなってきてるなっていうところがあったりするんで、
あんまりここ自身の話をしても面白くはないかもしれないなっていう気はしましたね。
まああれですね、プログラムを書くツールっていう側面は散々いろんな人が言ってるから、
どっちかって言語コミュニケーションの道具とか、リンチの投入のための道具っていう側面で考えてみようぜ的な切り口は、
独自性を出してるというか、なるほどねっていう感じがしましたけど、ちゃんと本のタイトルに寄せてきてるなっていう感じは。
確かに確かに。自然に近くなっていくといいよねみたいな話をしてましたね。
振り返ってのところでも、いく分か自然になってきたねとか言ってみたりしますね。
これなんかこの1年ぐらいの話いくと、自然言語でプログラム推薦してくれるって考えると、
だいぶ自然言語に近いコミュニケーションしやすい社長になったんじゃないっていう気はちょっとしますけどね。
ちょっとはしますけどね、どうなんだろうな。
まあ言うてでも出てきたこと読まない。
プログラミング言語を吐かせるための自然言語で操作できるっていう道具なんで。
ちょっと違うっちゃ違うんですよね。そこをブラックボックスにもうちょい扱えるようになったら多分やりたいことに近いような気もするし。
バイブコーディングってそうなんじゃないみたいな気もするなってちょっと思ったりとか。
結局プログラムを自然言語と統一ことによって、要は01のバイナリーでやるのは厳しいよねってなって、
だんだんそれがもうちょい自然言語に近づいていってコミュニケーション、コンピューターとしやすくなったよねってなったときに、
いろんなものをブラックボックス化してきた歴史なのかなと思って。
ってなったときに自然言語でプログラムを入ってくれて実行してくれて欲しいものが動いているってなったら、
それはある種自然言語でプログラムしてると長期的にメンテナンスするものとか、
でかい規模のものを作るのはまたちょっと別だと思うんですけど、
だんだんそれが投下的に扱えるようになってきたんじゃないみたいなことはちょっと自分は思ったりしてますね。
そうですね、プログラミングっていう概念がなくなっちゃえばいいと思うんですけどね、そこまでいくと。
まあ確かにね。
何でもできてくれる君がいれば別に、そこで作ったツールを保存しておけばいいだけなんで、
それってプログラミングなんだっけっていう感じなんですかね、わからないですけどレシピとか言われ方してるんじゃないですか。
確かに確かに。
プログラマーの思考モデル
すでにジェミニとかだとノートブックLMがジェムって言い方になってたりとかするような気がして、
ジェムっていうネームフレーズがもう使われてる気がするから。
依存感で難しそうな。
そう、ややこしそうだなってちょっと思ったり最近しましたけど。
まあそれで言うとね、どっかコンポーズが出てきた時点で、
それすごい目が滑るんですけどっていう気持ち。
そうですね。
なんかね。
タイポしてるんだよなみんな。
ファミアルで。
してますね。
なんか無意識にRまで打つからな。
そうそうそう。しかもね最近はコンポーズやむるみたいになっちゃったからね。
よりちょっと近いんだよなみたいな。
でもまあ11章そんな感じで、12章プログラミング言語の経験則も、
ここはアプリケーションを書いてる側からしても通用するような話ではあるのかな。
統一性、コンパクト化、あとまあ特殊性と先見性、先見異性ってな説が並んでますね。
いやフォートランとかの話が出てきて大人わからんなって気持ちは。
いやそうなんですよね。
すごいするなと思ってやっぱりちょっと難しいなっていうその部分はありましたね。
基本的にずっとフォートランとPL1の話をしてて、コボルがイケてる言語というか最近出てきた息のいい言語として的な扱いでチラッと出てくる。
そうですね。
コボルで書かれてればこんな問題はないかもしれないがぐらいの感じで、そうかコボルかっていう気持ちに。
まあでも十二章。
まあ面白そうなところ281ページで確かにって思ったのが、言語が思考に及ぼした映像の結果プログラマーが解決しようとする問題はその人が知っているプログラミング言語とそれをどの程度知っているかによって決まってくるっていうようなことが書いてあって。
まあこれは確かにそうねっていう感じがしますよね。
なんかやっぱ普段使ってる道具みたいなものが自分の思考にすごい影響してるなっていうのは。
常に結構意識してて、やっぱりリレーショナルデータベース使ってるからかどうしてもリレーショナルデータベースのモデル、それでどうやって扱えるかなっていう風に結構思考が制限されてる。
ある意味では問題解決のたびにフォーカスできてるということもできるけど、集合として扱いたくなるような気持ちになるなっていうのは結構あって。
昔なんかのびかえで人とそうじゃないように考えることってできるのかなっていう風な話をちょっとしたことがあって。
無理じゃない、そっから逃れることはやっぱりちょっと難しいんじゃないみたいな話をしたことがありますね。
なんか我々の世代が一番それに強い影響を受けてるんじゃないかっていう気もしていて、レール図とかそのフォロワーのフレームワークがバーって今出てきましたじゃなくて、
もう一般的になってきましたぐらいのタイミングでプログラミング始めてるんで、テーブル中心設計じゃないですか、我々のマインドセットが。
うん、めっちゃわかるそれ。
そうなるとね、なかなかね、同世代でもゲーム系から入ってきた人とか全く違うんでしょうけど。
でも結局それってやっぱどういうフレームワークに触れてたかとかどういうツールを触ってたかによって、物の見方が規定されてるっていう話ではやっぱあるので。
なんかその辺はすごく、本当はそこから、それも一個のアプローチとしていいんだけど、それ以外のことを前提としながら問題解決をちゃんとやっていかないと、
なんか上手く、ハマるときはすごく強烈にハマるんだけど、そうじゃないものを扱いたいときに、例えばツリー構造とかですけど、ツリー構造を扱いたいときに上手くRDBと相性が悪いなみたいなことが起きたりとかして、
なんかこの枝の途中から値を取りたいんだけど一回全部組み立てないとなとかそういうことが起きちゃったりとかして、上手く扱えないなっていう気持ちになっちゃったりするんで。
ちょうどいい距離感を保ちながらやんないといけないんだよなっていう気持ちにすごいなることはありますね。
そうですよね。いや、どうにかして統制しないといけないんですよ。
ってなったときに新しい言語を毎年1個覚えましょうとかっていう話が多分出てきたりとか、毎年何かしら自分の普段使ってるソリューション、よく使うものと別の問題の解き方をするようなものを触る。
それはもしかしたら、大体いつもRESTで設計するんだったら、RESTフルなAPIを設計するんだったらGRPCとかGraphQLみたいなものに触れてみるかもしれないし、RDBじゃなくてグラフデータベースとかもうちょっと違うデータベースのダイナモみたいなものとかに触れてみるとか、
そういうような別のものに触れることによって新しい視点を手に入れて、上手に問題解決できるようになっていくっていうことが大事になるとか、そういうようなことは全然ありそうですよ。
そうですね。肯定的にっていうと大げさすぎるかもしれないですけど、意識的に取り入れていかないと。いや、MongoDBは触ってたはずなんだけどな。
そうですね。あれで問題を解決しようとすると結構難しいということだけはみんな学んだことだ、可能性割。
未来のプログラミング
でもそう、だからFirebaseとか初めて触った時にめちゃくちゃすごいんだけど、全然正解わからないなーっていう気持ちになったりとか、やっぱりしましたよね。
そうですね。で、結局そうなると枯れてるものに頼りたくなっていくから。
APL1ですか。
枯れてるっていうか。
どこに生えてるんだって。
でも結局そうなるとやっぱTワード3文技術線っていうの神秘感じゃないけど、やっぱり残っているものってSQLだったりとか、UNIXのコマンドラインだったり、レストフルだったり、レールズ的な考え方だったりとか、そういう思想みたいなものにやっぱり触れていって、ある程度オーソドックスなパターンが決まっているものに触れていくみたいなのが
最初のステップとしてはいいんだろうなってなるし、その後っていうのはやっぱりあんまり人が踏み入れてないからこそ、どうやってそこの歴史性みたいなところに触れていくかっていうのは、その人自身の探索能力に依存してしまうみたいなところがあるんだろうなって気がしますね。
あとあれですよね、なんか20年後か30からないんですけど、自分たちの第一言語というかプライマリーの思考モデルとしてオブジェクト思考とはリレーショナルデータベースですって多分、何言ってんだこいつって思われると思うんですよね。
なんでそんなミスマッチが激しいものを好き好んで組み合わせて使ってたんですかみたいな話になるんじゃないかなどうなんだろうな。じゃあオブジェクトデータベースがまた流行るのかどうかは全然わからないんですけど。
いや今まさにそれがあったじゃんって言おうと思った。
いや僕らの視界には入ってないじゃないですか。
そう入ってないけどね。
ドキュメントはね、ドキュメントリビューはありましたけど。
でもまあオブジェクト思考で作る必要はないよねっていう話もまあやっぱあったりするわけで、関数型みたいなものがあったりも最近ではやっぱり喋ってる人はやっぱ増えてるような気もするし、なんか別のパラダイムに打っていくみたいなこととかっていうのは全然まあありそうな気はしますよね。
そう思いますね。まあそれこそコーディングエージェントと相性がいい、なんだろうな、書き方なのか、結合量集なのか、まあそれともサイズ感的にわかりやすくなりやすいからなのかはあれですけど。
まだまだ変わっていくだろうし、けどどう変わっていくかなんて予想はつかないので。
アプリケーションフレームワークのレイヤーでそこらへん抽象するみたいなのはありそうだしな。
この10年ぐらいは多分すごく業務フローを見ましょうみたいな、DDDだっていう話はドメインにフォーカスしましょうみたいなのあったけど、なんか業務に着目するって言ってもなんかデータフローに着目しましょうみたいな話とかも全然あり得るだろうから、
なんかそうなってくるとまた全然違う設計の仕方をするとかもあるだろうし、なんかその辺っていうのは、なんかもっとより良いアプローチとか、なんかもっとみんながコンピューター中心に考えるようになったら、もしかしたら全然違うことを考えたような設計のスタイルが増えていくとか、それに合わせるのは普通だよね、考え方になるかも。
ってなった時にやっぱ人間の思考を規定するものがまた変わってくるっていう風になるから、この辺はまだまだわかんないって感じですね。
そうですね、なんか最近になってまたデータフローダイアグラムの本が出たりとか、またっていうかあんまり周りにデータフローダイアグラムの話をしてる人があんまりいなかったから、我々はねデマルコが言ってたから、あー知ってる知ってるって感じでしたけど。
本出たけど、そして話題にしてる人も全然いないよね。
一人二人ぐらいはなんかフォローしてる人で、え、出るの?みたいなことを言ってる人はいたけど。
僕、ちゃんと入ってます?それ。
近所さん抜いてもう一人ぐらい知ってます。
あーなるほどなるほど。
でもそうですよね、データフローダイアグラムってめちゃくちゃよさそうだけどなんで知られたんですよ、かね?みたいな話を。雑談してましたもんね。
そうそうそう。
って思ったら本が出たから、いやこれは買ったのでは?と思って。
まあ、かねもねイベントソーシング的な話で盛り上がってる人の話とか聞くとめちゃくちゃ面白そうだなっていう感じもしたりとかありますし。
いますね。
で、まあ12章のプログラミング言語設計原則は道具が思考に強く影響するよねっていう話が主題ではないんですけど。
でも一番そこなんじゃないかっていうぐらいな気もするけど。
あーでもそうそう、コボルが出てきてこれはすごい読みやすい言語だからプログラミングの専門家以外も読めるようにっていう話があったんですよーと思いましたね。
まあ蓋を開けてみたらそんなことはなかったぞっていうね。
経営者がプログラムを読むってことができるようになるんじゃないかみたいな話もあったけど、結局そんなことは起きてなかったですからね。
いやむしろそれ読むぐらいだったら本業に集中してくださいみたいなこういう世界ですね。
まあまあどこまでを本業としているかは、人がいなかったらそれも本業になるしみたいなありますもんね。
そうだから要求通りに動かなくていいとか、スケジュールを守らなくていいとかってなればやっぱりプログラミング簡単なので誰でもできると。
誰でもできるし何もできないから矛盾するんですけど。
まあそんなところですかね。
他のプログラミングの道具第13章ありますけど、ここ難しかったなあ。
テストファーストの重要性
ちょっと面白いのが294ページかな。
さっき言った心理的な構えみたいな話と通用するところも通ずるところもあるかもしれないですけど。
何かを観察しようとした時にその観察者のコンテキストとかシチュエーションによっていろいろ見方が歪むっていうのはテストを考える時にもあるよねって話から
一番いいのは最初にテストを書くことだって書いてあって、これすごくないですかテストファーストの話ここでもしてるんだみたいな。
すごいですね。
びっくりした。
まあでも結局それってプログラミングじゃなくて、例えば授業、学校の授業とかでも考えるとここテストに出るよって言われて先に言っとけば、確かにここは大事なんだなみたいな話になるし。
ある意味ではそういう部分からもインスパイアできそうだけど、
でもプログラムの中で、プログラミングの中でそういう話をしているっていうのって、そもそもどうやって実現するかわかんない中で先にテストを用意しとくっていうのがいいぞっていうのって、
なんかすごいですよね。なかなかそれわかってたとしても思い浮かばなかったりとか、いや無理でしょって思って書かないとかいうことはありそうですよね。
そうですね。
あとね、その続きもすごい本質的なこと言ってるなって思うのは、
ここで言うテストとはエラーの存在を発見することであってテスト全体を指しているのではない。
エラーの原因を特定するためのテストはもちろん事前には用意できない。
発見したエラーを修正する手順も無駄。
しかし全てのテストは発見から始まるのだからテストケースを事前に準備しても無駄にはならない。
っていうのはそうなんですよねって思います。
そう、チェッキングはできるけどね。
じゃあテスト全体パスしたからオッケーかっていうと。
バグが見つからなかったことの証明にはなるけど、バグがないことの証明にはなってないので。
そうそうそう。
ここら辺はね。
そうですね。インテグレーションテスト書いてAPIバッチリですって言ってフロントエンド繋ぎ込んだら、
あれ、なんか思った通りに動かないねみたいなこと言って。
テスト書いてあるはずなんだけどなって言いながら。
でも期待した通りに動いてないんだったら意味ないよねって。
道具とプログラミングの未来
そうだねって言うのはよくありますね。
そうっすねそうっすね。
まあでも13章僕的には面白かったのそこかな。
自分はやっぱなんかここでOSの話が出てきて、システム360の話が出てきたりとか、
あとタイムシェアリングの話題が出てきたりとかしたりとかして、
なんていうか、なるほどなんかこういう感じの時代なんだなっていう感じがすごく受けたっていうところですね。
そういうことって今だと別に意識しないよねみたいな。OSあって当然じゃんとか。
そうですね。
CPUがアプリケーションから呼び出されて1個しか怖がらなくても、
それを順次にうまいこと動かしてくれてるとかって、あんまり意識しないですからね。
これそうなんですよね。
今だったらどうするって言ってましたっけこの章。
13章を振り返って320ページ見てみると、
この本をもし今書いたらプログラミング言語に関する2つの章は2段落でおしまいにして、
道具に関するこの章、まあ13章ですね、を5巻か10巻ぐらいに膨らませただろうって書いてあって。
多分違いすぎではって思ったんですけど。
すぐシリーズにしていっぱい書きたがるな。
何書くんですかね。10巻か。コンパイラー以外のこと全部書くのかな。
まあでもなんかそんな勢いはありそうですね。
でも多分やっぱOSどうなのかな。
でも多分こうインバーグの視点でゲームチェンジだったもの。
それはもしかしたらOSとかタイムシェアリングみたいな話かもしれないけど。
そういうものがいかに素晴らしいのかとか、これを有効に使うためにはこうするんやみたいな。
こういうモデルでメンタルモデルとして使うんやみたいな話とかになるのかな。
そうですね。
あとドキュメントに関しては、ドキュメンテーションに関しては25年間であまり改善してないように思われるみたいな話があるんで。
これはここ1年で改善したでしょうね。
めちゃくちゃ読んでて思いました。
ちゃんと読む人が想定できるようになったから、みんながドキュメントを書こうってなり始めてますね。
あとというか勝手によくわからないプログラムがドキュメントを言ったら書いてくれるんで。
そうですね。書いてくれるのもあるし、読んでもらうために人間がヒントとして書くっていうこともあるし。
ドキュメントが足りてないっていうことを考えた時に、その解説の本を書こうっていうモチベーションにつながるとかはもしかしたらあるかもしれないですね。
誤解や実感を通っても。
誤解や実感も書かれても人が読むのかっていう話はありますけど。
最初の3条しか読まないからな。
あとまとめが書いてあるからちゃんとまとめだけ読んでねって言って。
でもやっぱこの道具みたいなところはどんどんいろんなものが出てきて楽しそうにしているっていう感じもあるし、
それってのは多分現代においてもずっと続いていて、みんな新しい道具が出てきたらこれがいいらしいぞって入りのものを紹介するっていうのは今も続いてますねっていう気がしますね。
そうですね。そんなところかな、第4部。
そうですね。
エピローグ。
このエピローグが時の試練を絶えた。何も突きかえることはないっていうのが振り返ってくる。
そうですね。ちょっと面白いなって思ったのが、25年前には提案できなかった2つのことって言ってウェブサイトとメール待ってるよっていうのが書いてあって。
そうだよな、その時代だよなみたいな気持ち。
本の感想と分析
そうですね。インターネット出てきたら家みたいな。URLがhttp://wwwで始まってるっていうのが、なんかSでもないんだなとか、wwwって今でもなくはないけどもつけるのはあんまり一般的じゃないよねみたいなところになってきたりもするから、やっぱそういうところのギャップは感じますね。
電子メールもどうなんですかねっていうのがありますよね。まあでもメールは使うか。
まあメールはギリギリあるよな。
オープンなプロトコルで。
フィルターにさえ引っかからなければ。
DキメとかDマークとかいろいろ大変なことがいっぱいありますけど。
まあまあ一冊そんな感じですかね。参考文献がまたたくさんありますが。
まあまあ。
というわけでどうでしたか読んでみて。
読んでみて、やっぱ全体として脱線した方が楽しい本だなという感じですかね。
そうですね。真正面から受け止めるっていうよりかはちょっと斜めに受け流しつつ。
でもやっぱり所々面白いとか。
時代が経ってみると、全然我々が生きて知ってる時代じゃないのでノスタルジーとかではないですけど。
昔からこうだったのかとか、この時代にもこんなこと言ってるのか的な、そういう面白さはあると思うんで。
まあ逆に言うとそういうものを求めてる人は多分読んでもなんかちょっと辛いなってなっちゃうよね。
そうですね。
学び方を教えてくださいとか、もっと頭良くなりたいんですみたいな本ではないかな。
歴史に学ぶといいと聞いたのでちょっと歴史的な本を読んでみたいと思います。
名著って書いてあるんでちょっと手に取ってみましたってなると、いや別にこれじゃなくてもいいんじゃないっていう気持ちになっちゃうな。
ましてね、ワインバーグだとお金めちゃくちゃお勧めしたくなるような本が多いので。
そうそうそう。ソフトウェア開発だったら2月のシーマンの方がいいんじゃないとかね。
あそこが古いよって。
そうそう。っていう気持ちになるんで、やっぱりちょっと優先順位的なところでは落ちちゃうなっていう本かなって感じですね。
あとはまあ、なんていうか無理して通読しなくてもいいでしょうみたいな気はするか。
そうですね、なんか気になるとこだけ読んで合わないなっていうところは飛ばしてもらえたら。
コーディングとかソフトウェア開発みたいなところがすごい、なんですかね、ハードスキルじゃなくて本当に人間がやってる活動なんだっていうのは一冊通してずっと語っているので、
そういうところにどっぷりつかりたい人とかはいいのかな。
まあ、ピープルウェア的にならないって気持ちに。
ピープルウェアは組織っぽい話じゃないですか。
そうですね。
個人の能力とか個人の調子の良い日悪い日みたいな話はあっちではあんまりなかった気がするんで。
確かにそうですね。
まあ、なんていうか内省をしたい人かっていうところですかね。
おしまいにしてしまいますか。
はい、おしまいにしましょう。
はい、じゃあまた定型文をちょっと今度は集中して読むんで。
構わないように。
今週も放送をお聞きいただきありがとうございます。
ではまた次回。さよなら。
さよなら。
