<< 「自然キー」で識別するのが、もっとも「自然」 【パターン】 | main | イベント駆動のアーキテクチャ 【これから重要になるパターン】 >>

番号より名前。 ニーモニックコードより名前。 【パターン】

「識別キー」とか「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 とかは、問題領域の言葉をそのまま使った、名前空間に設計できるならそれが、一番わかりやすい。

ドメイン層のクラス名やメソッド名、テーブル名やカラム名も、全部、そう。

「識別キー」の設計は、「番号体系」や「ニーモニックコード」の設計よりも「自然言語に近い名前空間の設計」にこだわり、重視するのが、良い設計なんだと思う。

コメント
初めまして、情報処理の勉強をしている者です。

ニモニックコードにはそういう歴史があるんですね!
とても興味深いです!
コメントする









この記事のトラックバックURL
トラックバック
calendar
     12
3456789
10111213141516
17181920212223
24252627282930
31      
<< December 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM