トップ «前の日記(2020-06-25) 最新 次の日記(2020-07-01)» 編集

はじめてのにき

ここの位置付け

2004|11|
2005|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|04|05|06|07|08|09|10|11|

ToDo:


2020-06-30

_ UNIX 哲学

の、直交性のあるツールをたくさん作って、組み合わせて使いましょうてやつ、その哲学そのものは僕も好きだし、学ぶことの多い教えだとは思っている。なんだけど、自分の仕事に適用しようとしない方が良いと思ってるんだよな。というか、仕事で 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)

お名前:
E-mail:
コメント:
人生、宇宙、すべての答え
本日のリンク元

2020年
6月
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

search / home / index

全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。

shinichiro.hamaji _at_ gmail.com / shinichiro.h