SIについて

プログラマってプログムを書くのは好きだけど、なるべく書かずにすむように抽象化したり部品化したりする。これは矛盾してるようにも見える。しかしそもそも自動化をしたいのに、そのために"同じこと"を何度も繰り返し書きたくないというだけのことかもしれない。


サーバにイノベーションのジレンマは起きているか
(1) http://japan.cnet.com/blog/kenn/2003/10/21/entry_post_4/
(2) http://japan.cnet.com/blog/kenn/2003/10/23/entry_post_5/
(3) http://japan.cnet.com/blog/kenn/2003/10/28/entry_post_6/
(4) http://japan.cnet.com/blog/kenn/2003/11/02/entry_post_7/
(5) http://japan.cnet.com/blog/kenn/2003/11/10/entry_post_8/


イノベーションのジレンマに陥る優良企業たち
http://japan.cnet.com/interview/story/0,2000055954,20060205,00.htm
"かつての優良企業がトップの座から落ちるのは、競合他社が強くなったためではなく、むしろ一見取るに足らないような、あまり質の高くないソリューションを提供する新規参入企業が現れたためだと結論づける。...「技術進歩のレベルが顧客の実際のニーズと活用能力をはるかに超えると、行き過ぎが裏目に出る。新興企業に、より安く単純で、高機能を必要としない顧客から見れば十分な性能を持つ商品を提供する機会を与えてしまうのだ」と、Christensenは言う。そして、これを「破壊的イノベーション」と名づける。
 Christensenの考えによると、新規参入企業は低価格帯の市場に一度根をおろせば、その製品を改善してシェアを拡大することができる。場合によっては、市場トップの企業を追い落とすこともあり得るというのだ。"

(3)

「没個性化」の話があるが、
誰が書いても同じになる、という話はプログラマから見るとつまらん話のようにも見える。
しかし、実際の業務やある仕様を、ノーマライズされた表現に落とし込めるのなら、それはすばらしくも思える。



データベースや既存のシステムを、XMLをベースにグラフィカルにつなげられます!っていうタイプの製品は、便利な点もあるけれど、それは多様なシステムに接続できるアダプタの存在価値の比重が大きくて、つまりライブラリが強力だから便利なのではないかという。

Contextureにおけるgroupby

(下書きです。)
Contextureはfunctional database modelをベースとしたDBMSです。
Dataflowもしくはfunctional reactive programmingな仕組みを取り入れています。
functional database modelは、永続化された辞書や連想配列などのデータ構造を
関数と見なして操作するデータベースモデルです。
関数なので、KVSと同じように、キーをつっこめば値が得られる、というのが一番基本的なクエリーになります。
関数なので、複数の関数の合成、つまり直列につなぐ事や並列につなぐことができます。

関数の合成や操作は、HaskellのArrowと雰囲気は同じです。
http://d.hatena.ne.jp/r-west/20070720/1184946510

Arrowでは直列につなぐ演算子は「>>>」ですが、
Contextureではただの「.」(ドット)を使います。
Contextureでは多値を返す関数を基本として、合成操作もすこし拡張してありますが、
その説明はまた今度。

社員や、部署の関係をあらわすデータを例にとります。
所属 :: 社員ID -> 部署ID
所属 = {1:[101],2:[101], 3:[102], 4:[101]}

社員名 :: 社員ID -> String
社員名 = {1:["田中"], 2:["鈴木"], 3:["山田"], 4:["後藤"]}


部署名 :: 部署ID -> String
部署名 = {101:["開発部"], 102:["人事部"]}

年齢 :: 社員ID -> Integer
年齢 = {1:[30], 2:[30],3:[30], 4:[40]}

[1] => 所属.部署名 => ["開発部"]
[1, 3] => 所属.部署名 => ["開発部", "人事部"]

[1] => (所属.部署名,社員名) => [("開発部", "田中")]

~は、inverseの単項演算子です。
~所属は、所属のinverseで、
所属 :: 社員ID -> 部署ID
所属 = {1:[101],2:[101], 3:[102], 4:[101]}
なので、
~所属 :: 社員ID -> 部署ID
~所属 = {101:[1,2,4],102:[3],}
になります。

[101] => (部署名, ~所属.(社員名,年齢))
=> [
   ("開発部", [
     ("田中", 30), ("鈴木", 30), ("後藤", 40)]),
   ("開発部", [
     ("山田", 30)])]


今回はContextureにおけるgroupbyについていまのところ考えている仕様を説明します。
groupbyは、ある属性でまとめるような操作になります。
groupby(~所属, 年齢)
は、~所属を 年齢でグルーピングする感じです。

型は
groupby(~所属, 年齢) :: 部署ID -> Integer -> 社員ID
になります。つまり、部署IDが決まって、Integer(年齢)がきまって
初めて社員IDが得られる、引数を二つとる関数のようなものになります。
データ構造としては、辞書の入れ子になります。
カリー化された関数のようなかんじです。

データは、
groupby(~所属, 年齢) = {
 101:{
  30:[1, 2],
  40:[4]},
  102:{
   30:[3]}}

のようになります。
例としては、つぎのようなかんじになります。

[101] => groupby(~所属, 年齢)
=> [{
  30:[1, 2],
  40:[4]}]
[101] => groupby(~所属, 年齢).社員名
=> [{
  30:["田中", "鈴木"],
  40:["後藤"]}]

"Design Concepts in Programming Languages"がすごくいい。

"Design Concepts in Programming Languages"
この本はすごくいい。
そのわりにまだあまり話題になってないようだ。
おすすめしてくれたAmazon.comに感謝!

プログラミング言語の意味論とかCPS styleの話とか、oopの話とか、type systemの話とかモナドの話とか、
話題がとにかく豊富で、しかもmini languageを使っての説明がとてもわかりやすく面白い(っぽい。)

基本的になにが良いのか説明できるほどよくわかってないので
おすすめの理由は以下を参照。

http://www.haskell.org/pipermail/haskell-cafe/2009-April/060709.html
http://ztrek.blogspot.com/2008/08/recommended-read-design-concepts-in.html

載ってないのはConcurrencyの話題くらいかと思ったら、
Concurrency の話などは、http://dcpl.mit.edu/
のAdditional Materialsで提供される予定らしい。
これを使ったopen coursewareもあるのか。すごいな。

"Design Concepts in Programming Languages"が届いた

Design Concepts in Programming Languages (MIT Press)

Design Concepts in Programming Languages (MIT Press)

とても面白そう。そしてとても分厚い!!
1300ページとかあるよ。さすがに電車でたって読んだら苦しかった。
syntax、semantics、pragmaticsの3つについて
toy languageを使って説明するよ、syntaxは他のコンパイラの本なんかで
詳しく述べられてるからさらっとやるよ、
semanticsとpragmaticsの関係なんかについてちゃんとやるよ
というかんじ。
toy languageはスタック言語のようだ。
スタック言語は未知の世界なのでこれも楽しみ。
スタック言語についてちょっと調べてみた。

http://home.k00.itscom.net/hpcalc/stack.html
有名なところでは、FORTHやpostscriptがスタック言語。
http://hengsu.cocolog-nifty.com/personal_newsn/2007/03/stack_2e3c.html
そういえば、いつもみている
http://d.hatena.ne.jp/propella/
でよく話題にあがるJoyという言語もスタック言語のようだ。
まあこの本をちゃんと読めばスタック言語が理解できるようになっているはずなのでよし。

日本語訳は、syntaxは文法、semanticsは意味もしくは意味論だとして、
pragmaticsはなんだろう。意味的には実装よりの、
式の結果を実際にどのように計算して求めるか、といったことっぽい。
pragmaticsは語用論という訳語があるようだが。。。
まあ、英語で意味が分かれば訳はどうでもいいか。

Tokyo Cabinet メモ

Tokyo CabinetとそのJava APIUbuntuにインストールした。
http://ctrkode-clojure.blogspot.com/2009/05/tokyo-cabinetubuntu.html
あと、mixiブログのTokyoCabinet関連をメモ。
Tokyo Tyrant関連を除く。

http://alpha.mixi.co.jp/blog/?p=84
http://alpha.mixi.co.jp/blog/?p=86
http://alpha.mixi.co.jp/blog/?p=90
http://alpha.mixi.co.jp/blog/?p=96
http://alpha.mixi.co.jp/blog/?p=98

http://alpha.mixi.co.jp/blog/?p=290
http://alpha.mixi.co.jp/blog/?p=292
http://alpha.mixi.co.jp/blog/?p=298
http://alpha.mixi.co.jp/blog/?p=301
http://alpha.mixi.co.jp/blog/?p=318

イミュータブルな言語

http://www.rubyist.net/~matz/20080320.html#p03
を読んで思った。
Erlangの特徴が、immutableな値とアクターモデルだというのは、
とても頷ける。
もうひとつ本質的ではないかもしれないけれど、
パターンマッチングの仕組みが組み込みであるのも特徴だとおもう。
他の言語と比べたときに、とくに特徴にはならないかもしれないが、
=が代入でなくてパターンマッチングで、アクターに送られるメッセージ
もこのパターンマッチで選り分けられる。
Clojureは、
immutableな値に、アクターとパターンマッチはなくて、STMと、
動的に定義できる、他のスレッドから参照できるグローバル変数がある。
これをグローバル変数と言ってよいのか、スペシャル変数、ダイナミック変数、
なんというべきかはもう少し調べないといけないけれど、
動的に設定できてどのスレッドからも見える名前空間がある
というのが、ずいぶんClojureを窮屈でないものにするのに貢献していると思う。
もう一つ、イミュータブルなハッシュマップやセット/集合型というのも
便利だし。

また後でもう少し考えてみたい。

プログラミングに関わる概念、用語とか

http://www.rubyist.net/~matz/20080204.html#p01
を読んで考えた。
以下はあくまで個人的な感想と見解と理解です。
プログラミングに関わる概念や用語はたくさんある。
学問としての計算機科学と、現場よりのプログラミングの技法や知識には当然違いがある。
http://ja.wikipedia.org/wiki/%E8%A8%88%E7%AE%97%E6%A9%9F%E7%A7%91%E5%AD%A6
をみると、

あたりが中心な気がする。
ここらあたりは、もうよく研究し尽くされていて
鉄板という感じ。
どうもソフトウェア工学は計算機科学に含まれるらしい。意外。
計算機科学と理論計算機科学をごっちゃにしていたかな。

ともかくこういう学問の世界は系統だてられていて、
教科書も豊富なのだが、
実技としてのプログラミングを身につけるためのもではない。

ゲームプログラミングをしたりWebアプリや業務アプリケーションを書いたり、
といったことへの入り口から基礎までに関する知識が、
いまいち利用しやすい状態で用意されていない。

たとえばWebアプリを作りたいんだがそもそもプログラミングがわからないのだが、
と言われたときに、自信をもって勧められるサイトや書籍がない。

初めてのプログラミング
やさしいプログラミング

あたりか。いまいちピンとこない。
SICPはよい本だとは思うけれど、まさか普通の初心者には勧められないだろう。
問題がなにかが自分でもわかっていない。
これらの本が不満なのか。
入門書の先が続かないのが不満なのか。
入門書がJavaやCばかりなのが不満なのか。
(個人的には入門にはPythonが適していると思う。Rubyでもいい。
静的型でもいいけれどJavaだと冗長すぎる。

これを書いて気づいたが、実技としてのプログラミングでは、
言語の処理系ありきとなる。
プログラミングには、言語の処理系、コミュニティ、
ライブラリ、書籍やサイト、近くの詳しい人、
その言語で求人があるかどうか、
Webやデータベース、業務に関する知識、
エディタやIDEに関する知識、OSに関する知識、
ネットワークに関する知識、
もろもろが関わってくる。

純粋にプログラミングに関係していると思われる用語や概念だけをちょっと
ならべてみた。

抽象化
構造化
関数 引数 戻り値
手続き
状態 状態マシン
副作用
名前空間
クラス プロトタイプ
オブジェクト オブジェクト指向
ループ 繰り返し for while
リンクリスト
配列 可変長配列 リスト ベクター
遅延リスト
リスト内包表記
ハッシュマップ 辞書
コンパイル コンパイラ ネイティブコード 機械語 アセンブラ
バイトコード VM
パース パーサー 
テンプレート ジェネリックプログラミング


などなど。