「識別キー」とか「ID」 というと、番号体系やコード体系のイメージが強いと思う。
39857, 10.13.xx.255 とかの数字ID
AK-4483 とかアルファベットと数字
UK, JP とかのニーモニックコード
などが、コンピュータの世界で、よく使われる形式ですね。
もちろん、一般の世界でも、
090-9999-0000 形式の電話番号、 113-0031 形式の郵便番号とかは、使っている。
私は、記述的な「名前」による識別のほうが、わかりやすく、良い識別方法だと思っている。
10.13.xx.255 より、somewhere.over.the.rainbow のほうが、わかりやすい。
ニーモニックも、プログラミングの世界ではあたりまえだけど、
cp より copy
mv より move
のほうが「はるか」にわかりやすい。自然言語を使った名前が、やっぱり一番。
ソフトウェア技術者は、番号やニーモニックを扱うことに慣れているけど、かなりの部分は、古びた悪しき習慣なんじゃないかと思っている。
大昔、機械語しかなかった時代に、 LD(ロード命令)や、ST(ストア命令)というニーモニックは画期的だった。 0110 だとロード、1110 だとストアなんていうのが、LD / ST で書けるのは、ほんと革命。
この時代は、まさに、LD とか、 ST が「ニーモニック(覚えやすい)」コードだった。
Unix の初期の開発者たちは、こういう時代の人たちだから、ニーモニック大好き。
だから、Unix の初期の時代からあるコマンドは、ニーモニックのオンパレード。
cd, ls, cp, mv, dd, ls, sh, cc, ...
Unix( Linux ) で、文字数が多いコマンドは、まちがいなく、後から追加されたコマンド。 Unix 原始時代には、3文字、4文字のコマンドはなかった(と思う)。
50 bps レベルのテレタイプが主流で、300 bps が高速!通信回線だった時代。
メモリも、32KB とかで大容量。
この時代だと、copy より、cp の方が、効率が良い、というのが、大真面目な議論だった。
自然言語の「冗長」な表記は、とんでもない、ことだった。
もっとも、同時代の VAX は、help, link, run, ... というように、自然言語重視派。
Unix 初期の連中が、変わり者だったのかな?
まあ、いずれにしても、いまでも、ソフトウェア技術者の多くは、ニーモニックが当たり前だとおもっているし、自然言語の表記より、ニーモニックのほうが、好みかもしれない。
私は、自然言語派。プログラミングの世界といえども、人間にとっては、ぱっとわかりやすいのは、自然言語にきまっている。
だから、 def, val, var, << :: | とか連発するプログラミング言語は嫌いなんですよねえ。
生産性(可読性)が低いと思っている。
Unix の初期開発者たちは、自分たちは、ニーモニック大好きだったけど、
The quick brown fox jumps over the lazy dog.
を単語に分解して、単語数を数えるプログラム、とか、自然言語の文字列を処理する、という分野で、コンピュータの世界に大きな変革をもたらした。
汎用コンピュータ用のOSは、「固定長」が絶対条件。
可変長とか、動的にヒープを獲得・開放するなんていう発想はなかった。
だから、プログラム設計、ファイル設計、通信電文設計、どれも、最大桁数をきめ、最初から固定で割り当てる設計する。一文字もデータがなくても、最大桁数をメモリやディスクに確保してしまう。
かなり資源の無駄遣いです。
どんな長さがくるか、予測できない、自然言語文字列の処理は、大の苦手だった。
Unix では、可変長、動的なリソースの獲得・開放を扱うための、データ構造とアルゴリズムにこだわった。
C 言語の勉強とは、データ構造とアルゴリズムの勉強だった。
また、ストリーム型の処理(文字単位で処理していく)も特徴。
メモリ上のバッファは固定長でも、データ自体は、可変長で、NL とか EOF が来るまで読み込む、という「可変長文字列の行単位の処理」というのは、画期的だった。
もっとも、一秒間に、5文字送るのがせいぜいのテレタイプ回線で、通信していたりすると、一文字ずつ、順番に処理する、という発想に自然になるんだろうけど。
Unix や、VAX では、可変長で、動的確保と開放が基本思想。現在のコンピューティングでは、もちろん、こちらが当たり前。
もっとも、OSの内部では、テーブル等は、固定長・固定数のことが多かった。
ぎりぎりの性能を重視すれば、可変長・動的割当は、かなり鈍重な処理ですからね。
長さ固定とか、コード化して短縮表記とかは、コンピュータが高価で、ソフトウェアも、原始的な時代の遺物に近いと思うんですよねえ。
もちろん、今でも、固定長とか、短縮表記が、意味のある世界もあるだろうけど、可変長の自然言語の表記、というのが、基本トレンドでしょう。
ソフトウェア技術、ハードや通信のコストからすれば「固定長・短縮表記」は、はるか昔の話し。
今は「可変長で、自然言語の冗長な表記」を扱うのに、ハードの制約もないし、プログラミングも、便利なツールがたくさん揃っている。
もっと、自然言語に近づけようよ、ということ。
DSLの議論なんかも、こういうトレンドの一つでしょう。
まあ、技術者のニーモニック好きは、そう簡単にはかわらないかもしれない。
ニーモニック好きの技術者が、ニーモニック連発の言語使って、「ドメイン固有の言語」の議論しているのは、なんか、滑稽に見える。(まじめに取り組んでいる方には申し訳ありませんが)
ドメイン固有言語は「自然言語」でしょう、やっぱり。
xml の名前空間とか、URI とかは、問題領域の言葉をそのまま使った、名前空間に設計できるならそれが、一番わかりやすい。
ドメイン層のクラス名やメソッド名、テーブル名やカラム名も、全部、そう。
「識別キー」の設計は、「番号体系」や「ニーモニックコード」の設計よりも「自然言語に近い名前空間の設計」にこだわり、重視するのが、良い設計なんだと思う。
39857, 10.13.xx.255 とかの数字ID
AK-4483 とかアルファベットと数字
UK, JP とかのニーモニックコード
などが、コンピュータの世界で、よく使われる形式ですね。
もちろん、一般の世界でも、
090-9999-0000 形式の電話番号、 113-0031 形式の郵便番号とかは、使っている。
私は、記述的な「名前」による識別のほうが、わかりやすく、良い識別方法だと思っている。
10.13.xx.255 より、somewhere.over.the.rainbow のほうが、わかりやすい。
ニーモニックも、プログラミングの世界ではあたりまえだけど、
cp より copy
mv より move
のほうが「はるか」にわかりやすい。自然言語を使った名前が、やっぱり一番。
ソフトウェア技術者は、番号やニーモニックを扱うことに慣れているけど、かなりの部分は、古びた悪しき習慣なんじゃないかと思っている。
ニーモニック
大昔、機械語しかなかった時代に、 LD(ロード命令)や、ST(ストア命令)というニーモニックは画期的だった。 0110 だとロード、1110 だとストアなんていうのが、LD / ST で書けるのは、ほんと革命。
この時代は、まさに、LD とか、 ST が「ニーモニック(覚えやすい)」コードだった。
Unix の初期の開発者たちは、こういう時代の人たちだから、ニーモニック大好き。
だから、Unix の初期の時代からあるコマンドは、ニーモニックのオンパレード。
cd, ls, cp, mv, dd, ls, sh, cc, ...
Unix( Linux ) で、文字数が多いコマンドは、まちがいなく、後から追加されたコマンド。 Unix 原始時代には、3文字、4文字のコマンドはなかった(と思う)。
50 bps レベルのテレタイプが主流で、300 bps が高速!通信回線だった時代。
メモリも、32KB とかで大容量。
この時代だと、copy より、cp の方が、効率が良い、というのが、大真面目な議論だった。
自然言語の「冗長」な表記は、とんでもない、ことだった。
もっとも、同時代の VAX は、help, link, run, ... というように、自然言語重視派。
Unix 初期の連中が、変わり者だったのかな?
まあ、いずれにしても、いまでも、ソフトウェア技術者の多くは、ニーモニックが当たり前だとおもっているし、自然言語の表記より、ニーモニックのほうが、好みかもしれない。
私は、自然言語派。プログラミングの世界といえども、人間にとっては、ぱっとわかりやすいのは、自然言語にきまっている。
だから、 def, val, var, << :: | とか連発するプログラミング言語は嫌いなんですよねえ。
生産性(可読性)が低いと思っている。
自然言語の文字列の処理という技術革命
Unix の初期開発者たちは、自分たちは、ニーモニック大好きだったけど、
The quick brown fox jumps over the lazy dog.
を単語に分解して、単語数を数えるプログラム、とか、自然言語の文字列を処理する、という分野で、コンピュータの世界に大きな変革をもたらした。
汎用コンピュータ用のOSは、「固定長」が絶対条件。
可変長とか、動的にヒープを獲得・開放するなんていう発想はなかった。
だから、プログラム設計、ファイル設計、通信電文設計、どれも、最大桁数をきめ、最初から固定で割り当てる設計する。一文字もデータがなくても、最大桁数をメモリやディスクに確保してしまう。
かなり資源の無駄遣いです。
どんな長さがくるか、予測できない、自然言語文字列の処理は、大の苦手だった。
Unix では、可変長、動的なリソースの獲得・開放を扱うための、データ構造とアルゴリズムにこだわった。
C 言語の勉強とは、データ構造とアルゴリズムの勉強だった。
また、ストリーム型の処理(文字単位で処理していく)も特徴。
メモリ上のバッファは固定長でも、データ自体は、可変長で、NL とか EOF が来るまで読み込む、という「可変長文字列の行単位の処理」というのは、画期的だった。
もっとも、一秒間に、5文字送るのがせいぜいのテレタイプ回線で、通信していたりすると、一文字ずつ、順番に処理する、という発想に自然になるんだろうけど。
Unix や、VAX では、可変長で、動的確保と開放が基本思想。現在のコンピューティングでは、もちろん、こちらが当たり前。
もっとも、OSの内部では、テーブル等は、固定長・固定数のことが多かった。
ぎりぎりの性能を重視すれば、可変長・動的割当は、かなり鈍重な処理ですからね。
長さ固定とか、コード化して短縮表記とかは、コンピュータが高価で、ソフトウェアも、原始的な時代の遺物に近いと思うんですよねえ。
もちろん、今でも、固定長とか、短縮表記が、意味のある世界もあるだろうけど、可変長の自然言語の表記、というのが、基本トレンドでしょう。
ソフトウェア技術、ハードや通信のコストからすれば「固定長・短縮表記」は、はるか昔の話し。
今は「可変長で、自然言語の冗長な表記」を扱うのに、ハードの制約もないし、プログラミングも、便利なツールがたくさん揃っている。
もっと、自然言語に近づけようよ、ということ。
DSLの議論なんかも、こういうトレンドの一つでしょう。
まあ、技術者のニーモニック好きは、そう簡単にはかわらないかもしれない。
ニーモニック好きの技術者が、ニーモニック連発の言語使って、「ドメイン固有の言語」の議論しているのは、なんか、滑稽に見える。(まじめに取り組んでいる方には申し訳ありませんが)
ドメイン固有言語は「自然言語」でしょう、やっぱり。
自然言語に近い名前空間を設計して使おう
xml の名前空間とか、URI とかは、問題領域の言葉をそのまま使った、名前空間に設計できるならそれが、一番わかりやすい。
ドメイン層のクラス名やメソッド名、テーブル名やカラム名も、全部、そう。
「識別キー」の設計は、「番号体系」や「ニーモニックコード」の設計よりも「自然言語に近い名前空間の設計」にこだわり、重視するのが、良い設計なんだと思う。