ToDo:
なんかグーグルの日本語でツイートしてる人たちが、ツイターで peer review の進捗を書くようになっているみたいで、面白いなと思った。どういう文化的な背景なのだろう
なんか僕がいた時は hangout の status に乗っけてる人が多かった気がする
(14:45)
because I'm me
いいはなしだなーと
https://twitter.com/girlmeetsNG/status/1299482563782770688
(18:32)
疫病は指数関数に増えるんだよ、てのを信じて、となると最適戦略は増え始めたら最速で厳しいシャットダウンやな、と思ってたのだけど、なんか第二波は増えてる間も指数ぽく見えなかった。どういう理屈で考えると良いのだろう。増え始めると気にする人が増えるから、みたいな PID 制御みたいな考えかたをすれば良いのかな
(11:22)
読み返してやっぱチェインソーより圧倒的に面白いやろ、と思ったけどチェインソーの方が人気もまわりの評価も高いぽんだよな、不思議
wikipedia の説明読んでると面白くて
https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A1%E3%82%A4%E3%82%A2%E3%83%91%E3%83%B3%E3%83%81
長く愛されている「ドラえもん」（藤子・F・不二雄）・「サザエさん』（長谷川町子）・『アンパンマン』（やなせたかし）などの作品を参考にした 主人公のアグニはアンパンマンの頭文字「ア」から、宿敵ドマはドラえもんの「ド」、サンはサザエさんの「サ」から採られた
あたりから興味を持ってインタビューを見たらこれも面白かった
https://natalie.mu/comic/pp/firepunch
(16:52)
年齢によって採用の可否などを決めてはならない、と思うわけだけど、政治家は80近くとかの人にはやって欲しくない、と思う。これはリベラル的には許される考えかたなんだろうか。言い訳はいくらでもあるとは思うけど。。
(16:57)
世の中いろんな人がいるんだなぁ……
https://twitter.com/EU_Kummerspeck/status/1293155297456873475
(15:31)
https://twitter.com/_ko1/status/1281972384036040704
と
https://twitter.com/_ko1/status/1281984532971786240
を見て、エンジニアトピックの作ってみる課題30個、ての考えてみると面白そうだなあ、と思って考えてみた。たぶん普通 CS という時よりも、自分の趣味と実務ぽいの多めだと思う
表記は
みたいになってる
あとダイクストラとか考えた
S式からVMコード出して実行するとかすると一気通貫で良さそう
あと malloc とかも思ったけどいくらなんでも僕の趣味すぎるかと思った
まあゲーム作ると良いと思う
統計わからん
全体的に自分の趣味と知ってる領域に偏る。忘れてる領域多そうで、でも数えると既に30越えてる。座学ぽくなる計算量理論は……チューリングマシンとかラムダ計算とかあって良かった気もする。数学は……まあいいかなあ……。定理証明とかは、まあどうかなあ……というのと
なんとなく、わかってる人は1日でできるけど、わかってない人は勉強するのも含めて1週間くらい、1年もかけて一通りやるとなんか一通りわかった気になれるんじゃないの？くらいの内容になった気がする
(10:06)
人間、ちょっと難しい問題が解けると嬉しくなるので、特に重要性のない、ちょっと難しい問題を見つけて解くのに夢中になってしまう問題がある
でも多くの場合、本当にやった方が良いのは、
であることが多い
このへんに僕が趣味と仕事のコーディングが全然違う、と感じてる理由があるように思う。趣味だと僕は属人性全開のコンテストとか大好きなのだけど、仕事の場合、「必要な簡単な問題をたくさん解いてたら、全体としては非自明な、有用性のあるものができました」みたいな開発が好きで、あまり仕事で属人性多いことやりたくないなあ……と思っている
(12:00)
の、直交性のあるツールをたくさん作って、組み合わせて使いましょうてやつ、その哲学そのものは僕も好きだし、学ぶことの多い教えだとは思っている。なんだけど、自分の仕事に適用しようとしない方が良いと思ってるんだよな。というか、仕事で UNIX 哲学的にバラバラなツール群としてデザインされたものを見ると、げんなりするレベルなので、嫌いといっていいレベルかもしれない
なんでかっていうと、それが真に UNIX の10%程度にでもうまくいっているという例をほとんど見たことがないから、という気もする。 djb が例外くらいの気持ち
バラバラのツールでまとまった機能を実現させるのであれば、そのバラバラのツールが何を、どういうふうにやりとりするか、というのを統一しないといけない。 UNIX であれば行指向のテキストファイルをパイプでやりとりする、みたいな
また、どうすれば使いかたがわかるか、というのも統一しないとわけがわからなくなる。 Linux 環境であれば --help か man でまあだいたいわかる……が info とかを見た方が適切なものがあったり、 Linux 環境ですら完全にうまくいっているとも言えないように思う
もっと UNIX ツール群自体が微妙に感じる部分として、コマンドライン引数があると思う。 cp/diff -r と ls/chmod -R など、このコマンドは似た意味だけど違うオプションなんだなあ……となることは結構あると思う
コマンドライン引数の名前に整合性が取れてないけど、普段そんなに困ってないのは、 UNIX ツール群はそうはいってもおおむね整合性があって、単にたくさんの人がすごい回数使っていて、みんなが共通言語として記憶したから、なのかなあと思う。そして、そこに仕事のプロジェクトで UNIX 哲学を適用しようとするのを微妙に感じる理由がある気がする
仕事のプロジェクトだと、使う頻度も、使う人も UNIX ツール群と比べるとそんなに多くなくて、このプロジェクトのオプション体系はこういう感じなんだなー、というのを学ぶコストがペイしないように思う。 API 経由でモジュール群が連結されていても、プロジェクトごとのお約束とかを覚えたりするコストはどうしても発生するけど、プログラム言語がしばっているぶん、任意の文字列が与えられるオプションに比べると、流儀を覚えるコストは少ない、と感じる。 -help なのか --help なのか、複数入力与える場合は --input x --input y なのか --inputs=x,y なのか、構造化データを受け渡しするこのツールはタブ区切りを受けるのか JSON を受けるのか……などなど
あとたぶんもっと重要なこととして、コンポーネントごとにツールを分けて柔軟な組み合わせができるようになったとして、その柔軟性はなんのためなのか、というのがあると思う。特定の組み合わせでしか意味がないような組み合わせにたいして、ツールがわかれていると間違えて使いうる可能性を高めるし、適当なラッパなんかを提供して間違えないようにしたとしても、そもそもツールをわけるために払ったコストはいったい……ということになる
例としては、 uniq なんてのは sort の後で使われることがほとんどなので、 GNU sort には -u オプションがついてたりする。本来の UNIX 哲学的には微妙なんだろうけど。まあでも uniq は -c をつけたくなることがすごく多くて、これが sort に無いのでなんか結局 sort | uniq -c とやっている。話がそれるけど、 UNIX ツールの(たぶんあとづけの)利点として語られるパイプライン並列は sort+uniq の例では適用できなくて、たぶん、 uniq は速すぎて sort の中でやった方が余計な移動が無くて速いと思う
あとまあ C コンパイラのプリプロセッサとコンパイラとアセンブラのバイナリを分ける話。今時はプリプロセッサはコンパイラが内蔵していて、アセンブラも clang とかだとアーキテクチャによってはコンパイラが持っている。これ、 UNIX 哲学的には、合体させない方が良かった、ということになるんだろうか。あと、昔の UNIX のコンパイラだと、コンパイルフェーズすらバイナリがわかれていて、構文木を作るフェーズとコード生成するフェーズで別バイナリだったのだけど、これもそれが良かった、という主張になるんだろうか(当時はバイナリサイズの制約て話だったんじゃないかと思う)
なんか書くのあきてきた
とか言いつつ、最初に書いた通り UNIX 哲学それ自体はそれなりに好きで、 UNIX ツール群は大好きなんだけど。仕事で書くならライブラリたくさん作ってくっつけてく方が良い気がするんだよな
(08:59)
僕は今でも https://reservoir.tumblr.com/post/68943475/971006-%E5%B0%91%E5%B9%B4%E3%81%AF%E8%8D%92%E9%87%8E%E3%82%92%E7%9B%AE%E6%8C%87%E3%81%99-id-indexhtmlv-112 を信奉する中二心を維持しているので、防衛的特許と言われてようがなんだろうが、特許と言われただけで心拍数が上がる感じがある
(11:56)
| 前 | 2024年 11月 |
次 | ||||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| 1 | 2 | |||||
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。