げんご仕様って地味に大事だよね、という話
主に自分向けの記事。フィードバック大歓迎。
例えばある軽量テキストマークアップ言語aがあったとき、そのaを変換して、HTMLやTeX、markdownに変換するAというソフトがプログラミング言語αで実装されていた、とする。仮の話だ。
それを見て、言語aに共感するもののプログラミング言語αではなくプログラミング言語βでそのaだけ使いたいとする。せめてサブセットとしてプログラミング言語βでmarkdownへの変換ルーチンだけ書きたいと思ったりして、処理ソフトBを作る。
あるいはmarkdownからその軽量テキストマークアップ言語Aに逆変換するソフト∀を作る人も現れたりもする。
「重要」というのは曖昧かもしれない。ユーザの「マークアップ言語aを快適に使いたい」という要望に寄り添う上で「重要」、という話だ。
ここで、βとαの関係においては開発者同士が熱心に議論する程度で「aとは何か」を決められる。でも、興味を持った別の開発者がプログラミング言語ΖΖで書き始めた時にもそれが出来るとは限らないし、多分ならない。
∀にとってもこれは「重要」になる。aからmarkdown、そしてそこからaへ戻すラウンドトリップの適切さは、少なくとも一部は「aって何」というものへの理解から始まる。
＃ 実際の世界でも、異種の変換・逆変換ソフトのラウンドトリップが失敗することがよくある。「あ、どっちとも解釈できるわ」ならまだ良いものの「どっちが正しいかの基準がないわ」は喧嘩どころの話じゃない。……開発元が同じ変換・逆変換ソフトでラウンドトリップが動作しない？知らん。
仮にマークアップ言語aに不足があったとき、マークアップ言語aを驚くべき用法で使い始めたとき (例えばマークアップ言ってるのに「プログラミング言語としても使いたいのです」とか言い出す)、「これが、マークアップ言語aです」と一言言い切って、少なくとも「オレオレ拡張」がどこであるかを示すための「言い訳」が欲しくなるのではないかと思う。出来ればそれは、「マークアップ言語a仕様策定委員会」から生まれた何かであるべきで、マキシマムはRFCやらISOなんとかかんとか、になるのだと理解している。
＃ 仕様の世間的なパワフルさに応じて非線形に政治的プロセスが増えるじゃねーか、みたいな気もする。それは脇に置いておく
組織や策定プロセス自体にある程度の「筋書き」がないと、オレオレは減らない。上に出てきたmarkdownはある意味で仕様があるのに無視されている世界観で、ここで書いていることの気持ち悪い側面が見えていので固有名詞を書いた。世界中で鬼のように派生があるおかげで何でもかんでもmarkdownになるけど、必ず「お前のmarkdownはどのmarkdownなのか、おお、アフガニスタンにドメスティックな企業の情報共有サービスのmarkdownかじゃぁ無視する」というようなやり取りが発生するような世界だ、と感じる。仕様がないと、この言い訳すら通用しない。
マークアップ言語aが強力だと感じるのなら、多分、その開発と並行して「オレ様の実装は仕様に忠実なのだ。ただしマークアップ言語a v.1.0の仕様はクソだからv1.2の仕様準拠だ」と言い張れる何かがある方が、助かる。それは、自分の開発環境のバージョン管理をすることと同じか、世間的にはそれよりも重要だ、ということになるかもしれない。要は「ピンを止める位置」の問題とも言える。
もちろん、話をちょっと戻して、ソフトA開発元が金取りたい、というのであれば、「重要」という言葉の方向性も異なってくる。場合によっては「マークアップ言語aの仕様なんて知るか糞め黙れ俺らが仕様だ」になることもあると思う。そのアプローチもあって良いと思う。
ただ、大手企業でそれが許されそうな会社でも、「君らも仕様に準拠した実装を作れる」という方向で動いているところはあるように思える。これはマークアップ言語の話ではとっくにないが、自分たちが開発した独自プログラミング言語をせっせと国際仕様にしようとしたりするのも、多分「オレサマが正義だ」以上の力を仕様に感じるからでないのかと思う。
＃いやだってさ、仮に、どこかのオープンソース組織が別の詳細が異なる動作をする実装を作ったら、どう怒っていいか分からない。「参照するものがないじゃーん(・ε・)」ていう言い訳は一応成り立つし、その組織間の喧嘩はともかくユーザは不便をこうむる。
仕様がないのに上手く回る、という話はすぐに思いつかないけど、規模が大きくなるときに仕様無しで全員が空気を読める世界ってどのくらいあるのだろうか。単一の独裁者みたいのがいて、その立場が変化しない状況なら、あり得るかも、とは思う。
収束しないのでここで終わらせる。
例えばある軽量テキストマークアップ言語aがあったとき、そのaを変換して、HTMLやTeX、markdownに変換するAというソフトがプログラミング言語αで実装されていた、とする。仮の話だ。
それを見て、言語aに共感するもののプログラミング言語αではなくプログラミング言語βでそのaだけ使いたいとする。せめてサブセットとしてプログラミング言語βでmarkdownへの変換ルーチンだけ書きたいと思ったりして、処理ソフトBを作る。
あるいはmarkdownからその軽量テキストマークアップ言語Aに逆変換するソフト∀を作る人も現れたりもする。
- マークアップ言語a
- aをプログラミング言語αで処理するソフトA
- aをプログラミング言語βで処理するソフトB
- markdownからマークアップ言語aへ逆に変換するソフト∀
「重要」というのは曖昧かもしれない。ユーザの「マークアップ言語aを快適に使いたい」という要望に寄り添う上で「重要」、という話だ。
ここで、βとαの関係においては開発者同士が熱心に議論する程度で「aとは何か」を決められる。でも、興味を持った別の開発者がプログラミング言語ΖΖで書き始めた時にもそれが出来るとは限らないし、多分ならない。
∀にとってもこれは「重要」になる。aからmarkdown、そしてそこからaへ戻すラウンドトリップの適切さは、少なくとも一部は「aって何」というものへの理解から始まる。
＃ 実際の世界でも、異種の変換・逆変換ソフトのラウンドトリップが失敗することがよくある。「あ、どっちとも解釈できるわ」ならまだ良いものの「どっちが正しいかの基準がないわ」は喧嘩どころの話じゃない。……開発元が同じ変換・逆変換ソフトでラウンドトリップが動作しない？知らん。
仮にマークアップ言語aに不足があったとき、マークアップ言語aを驚くべき用法で使い始めたとき (例えばマークアップ言ってるのに「プログラミング言語としても使いたいのです」とか言い出す)、「これが、マークアップ言語aです」と一言言い切って、少なくとも「オレオレ拡張」がどこであるかを示すための「言い訳」が欲しくなるのではないかと思う。出来ればそれは、「マークアップ言語a仕様策定委員会」から生まれた何かであるべきで、マキシマムはRFCやらISOなんとかかんとか、になるのだと理解している。
＃ 仕様の世間的なパワフルさに応じて非線形に政治的プロセスが増えるじゃねーか、みたいな気もする。それは脇に置いておく
組織や策定プロセス自体にある程度の「筋書き」がないと、オレオレは減らない。上に出てきたmarkdownはある意味で仕様があるのに無視されている世界観で、ここで書いていることの気持ち悪い側面が見えていので固有名詞を書いた。世界中で鬼のように派生があるおかげで何でもかんでもmarkdownになるけど、必ず「お前のmarkdownはどのmarkdownなのか、おお、アフガニスタンにドメスティックな企業の情報共有サービスのmarkdownかじゃぁ無視する」というようなやり取りが発生するような世界だ、と感じる。仕様がないと、この言い訳すら通用しない。
マークアップ言語aが強力だと感じるのなら、多分、その開発と並行して「オレ様の実装は仕様に忠実なのだ。ただしマークアップ言語a v.1.0の仕様はクソだからv1.2の仕様準拠だ」と言い張れる何かがある方が、助かる。それは、自分の開発環境のバージョン管理をすることと同じか、世間的にはそれよりも重要だ、ということになるかもしれない。要は「ピンを止める位置」の問題とも言える。
もちろん、話をちょっと戻して、ソフトA開発元が金取りたい、というのであれば、「重要」という言葉の方向性も異なってくる。場合によっては「マークアップ言語aの仕様なんて知るか糞め黙れ俺らが仕様だ」になることもあると思う。そのアプローチもあって良いと思う。
ただ、大手企業でそれが許されそうな会社でも、「君らも仕様に準拠した実装を作れる」という方向で動いているところはあるように思える。これはマークアップ言語の話ではとっくにないが、自分たちが開発した独自プログラミング言語をせっせと国際仕様にしようとしたりするのも、多分「オレサマが正義だ」以上の力を仕様に感じるからでないのかと思う。
＃いやだってさ、仮に、どこかのオープンソース組織が別の詳細が異なる動作をする実装を作ったら、どう怒っていいか分からない。「参照するものがないじゃーん(・ε・)」ていう言い訳は一応成り立つし、その組織間の喧嘩はともかくユーザは不便をこうむる。
仕様がないのに上手く回る、という話はすぐに思いつかないけど、規模が大きくなるときに仕様無しで全員が空気を読める世界ってどのくらいあるのだろうか。単一の独裁者みたいのがいて、その立場が変化しない状況なら、あり得るかも、とは思う。
収束しないのでここで終わらせる。
