Smalltalk の文法はとてもシンプルです。
覚えることは意外と少ないです。
（書きかけ）
Smalltalk は簡単に始められます。
（書きかけ）
僕は Squeak と VisualWorks しか使ったことがないんですけど、どちらも非常に良くできた開発環境だと感じました。
いや、開発環境というよりは Smalltalk って環境そのものなんですよね。
（書きかけ）
Smalltalk はオブジェクト指向を学ぶのに最適な環境です。
実際、僕は Smalltalk に触れるまでオブジェクト指向というものがなんなのか全く理解できていませんでした。
（書きかけ）
自由自在Squeakプログラミング
Smalltalkで学ぶオブジェクト指向プログラミングの本質
（書きかけ）
やるしかないですね！
LL Future というプログラミング言語関係のイベントに行ってきましたよ。
http://ll.jus.or.jp/2008/
チケットは1000個以上売れたらしいです。
会場に来たのは800人くらいだったそうですが。
こういうイベントに1000人近くの人が集まるっていうのはすごいですね。
基調講演は Perl の作者であるラリー・ウォールさんのお話。
英語でほとんど内容わからず。
推測するに、Perl の次のバージョンである Perl6 では、表面的な部分の変更は少なめにするけど裏でユーザーが弄って言語自体をいろいろカスタマイズできるよー、みたいな事を言っていたと思います。
ていうかそもそも Perl って変な言語なんですよね。
インタープリターがスクリプトを解釈するタイミングに独自の処理を挟み込めたりするようです。
で、Perl6 ではこの機能がさらに拡張されるということなのかな（自信ない）。
どんどん変態的な言語になっていくような気がします（あんま詳しく知らないのでアレですが）。
このイベントには Ruby の作者であるまつもろゆきひろさんも来ていて、パネルディスカッションの時に、「いろいろ作り替えられすぎちゃう言語はどうかと思う」みたいなことを言ってて、これは Perl とは逆の考え方だなぁと思いました。
コードに一貫性がなくなり読みにくくなったりすることを危惧してのことだと思います。
僕もこの意見には賛成です。
ていうか僕自身が「良いデザインのものを思う存分使い倒したい」と考えるたちで、言語自体を自分でカリカリにカスタマイズしたいとか、またはカリカリにカスタマイズされたものを使いたいとかあまり思わない人間なんですね。
初期状態でそこそこ気分良く使えるのがいいんです。
デザインってその辺が非常に重要だと思っていて、例えばユーザーの利便性を考えすぎて自由度が高くなりすぎるのも良くなかったりするんですね。
初期状態で、どのくらいのレベルまでユーザーをアフォードしてくれるのか、みたいなことが重要なんじゃないかと（アフォードの使い方合ってる？）。
でも全くカスタマイズできないのもつまらないですよねぇ。
だからバランスが重要というか。
カスタマイズの仕方にもなんかしらのスマートさというかクールさが求められるようなのがいいかもしれません（どんなんやろ）。
ちょっと話が抽象的になりすぎました。
いやー、デザインって奥が深いですね。
以上、デザインにまつわる考察でした。
LL Future に行ってきました。
非常に良かったです。
良い刺激になりました。
以下、LL Future のメモです。
かなり適当なメモなのでご了承ください。
会場について
迷った
ちゃんと場所を調べてなかったので
かなり広い
500人くらいは入るのかな
1000人は入るらしい
運営について
へんなリストバンドを腕に付けないといけない
WiFi なし
不便
基調講演
ラリー･ウォールさん
Perl 開発者
Perl6 の話
英語
通訳なし
よくわからなかった
LL で未来を発明する
（以下は時系列じゃない。書き方ミスった）
ラリー・ウォールさん
100 year language
impossible to predict
extensible but expressive
self-defined
precisely scoped
paradigm nautral
scalable
optimizable
parallelizable
accessible
teachable
transparent
community-based
楽
住井英二郎さん
MiniCaml の作者
過去にさかのぼってみる
約100年前にラムダとかの理論が論文で発表されていた？！
数百年前に関数は発明されていた
数千年前に変数は発明されていた
自然言語でコンピューターに命令
誰でも使えるような言語
グラフィカル言語
現代のいいものは100年後にも残るんじゃないか
ひげぽんさん
scheme 系の処理系を書いてる
OS を開発している
言語の大統一理論！
言語はすべてLispに！
100年後は誰でもプログラミング的なことができるようになっているんじゃないか
自然言語で
でも全部自然言語でやるのはむり
まつもとゆきひろさん
100語はプログラミング言語は使われていないんじゃないか
コンピューターが自然言語を理解するようになるんじゃないか
藤田喜勝さん
ゲーム開発者
scheme 系
プログラミング言語の進化
サブルーチンの発明
ada にはサブルーチンがある
プログラマが楽になる方向に進むだろう
面倒くさいことをやらなくてすむように
メモリの管理
とにかく面倒
現状
解消されてきている
並列実行
デバッグが面倒
Mutex 使ってがちがちに書けばいけるけど面倒
現状
発展途上
Erlang とか
CPU の新機能で解消できるようになってくるんじゃないか
低レベルのもろもろの面倒を見てくれる
中小度の高いプログラムのほうが性能が出るようになる
現代のいいものは100年後にも残るんじゃないか
いいものってどんなの？
まつもとさん
+ とか - とか
Ruby
プログラミング人口が増えることが重要
日本はプログラミングに関心ある人が結構多い。すごい
ラリーさん
Perl6
住井さん
なぜプログラミング言語理論を？
計算の本質にせまる
抽象化について
数学的計算モデルで定式化
藤田さん
イプシロンを開発
scheme 系
DSL を実装するために作った
ひげぽんさん
Mosh を開発
scheme 系
SIPC に感銘を受けた
最後のほうの章に scheme の処理系を実装する話が載っている
Mona OS
デフォルトで提供されるものをいいものに
これから何をしていくか
ひげぽんさん
OS
全部入りで思想の統一された、フルスタックのOSを提供したい
藤田さん
おもしろそうな言語処理系が出てきたら実装したい
住井さん
大学にいてなにするか
100年後の人が面白いと思えるようなアイデアをちゃんと記録に残す、とか
自分の知的好奇心を満たす方向で
まつもとさん
いろんな言語を増やすのは良くない
コミュニケーションがとれなくなる
なのでRubyにはマクロがない
ラリーさん
英語わかんない。。
関数型はどこがいいのか
まつもとさん
アイデアを盗むのにいい
住井さん
最近どれも似てきている
頭のいい人が多い
藤田さん
括弧が多いのは慣れ
ひげぽんさん
普通の言語にはないような概念がある
藤田さん
エラーメッセージについて
エラーメッセージをもっとよくしてほしい
まつもとさん
あまり考えていない
ひげぽんさん
エラーメッセージがわかりにくかったりするせいで
ユーザーの時間を奪うのはよくない
住井さん
研究しにくい
定量化しにくい
まつもとさん
確かにその通り
あとで対応するのが基本
ユーザーから要望があったときに
レイジー
藤田さん
言語デザイナーが大変になりすぎるのもなー
質問
よしおかさん（ミラクルリナックス）
ノイマン型を前提としている限り、100年後も今とあまり変わらないんじゃないか
まつもとさん
抽象化のレベルが上がる
フラクタル
抽象度が上がっても下がっても同じように見える言語とか
匿名さん
セキュリティについて
ラリーさん
言語とセキュリティは別
まつもとさん
いいアイデアがない
あればご提案を
サイコー！？フレームワーク！
メンバー
ひがやすお
能登信晴
瀧内元気
吉田裕美
ひがやすおさん
会場にいる人で Java 嫌いな人は？
（挙手）
結構いるw
シーサー
LLをリスペクト
ホットデプロイ
ファイルを保存するだけで自動的にデプロイできる
瀧内元気さん
Rails の基本的な説明
かれこれ3年くらい使ってる
重要なのはRubyで動くこと
Rubyで仕事ができるっていいよね
能登信晴さん
DeNA
検索サービスの企画・開発・運営
MobaSiF
Moble Simple Framework
Linux + Apache + MySQL + Perl
そこそこ利用実績あり
シンプル
100%コントロールできるフレームワークがほしかった
ドキュメントが無かった
みんなソース読んでた
軽快な動作
一部Cで実装
Perl XS
ORマッパーは無し
携帯向け
絵文字変換
等
source forge からダウンロードできる
今後
具体的なプランはない
必要に応じて勝手に機能追加してもらったほうが早いかも
吉田裕美さん
独自フレームワーク
作った感想
楽しい
すべてが把握できる
教育がたいへん
Struts
便利なの？
シーサー
素晴らしい
生産性が高い
でもやっぱり面倒
Ruby on Rials
スゴイ！
良くなるのなら多少の互換性はあきらめる
長い目で見るといいのかも
いろんなプラグインが流通している
Gauche on Rails
lisp 好きが高じて
まだプレゼンレベル
Rails でできることは Gauche でもできる
でも何か方向性が違うのでは？
Gauche on Rails 2.0
フレームワークは要するにメタプログラミングなのでは？
Gauche(Lisp) はメタプログラミングのための言語
Gauche は結構LL風
一通りやりたいことはでいる
Gauche(Lisp)ならアプリ毎に専用のフレームワークを作れる
トークセッション
テーマ
フレームワークを誰に勧めたいか
ユーザー、作者に言いたいこと
要望や文句
他のフレームワークに浮気をしたいと思うか
数年後にはどういうフレームワークを使っていると思うか
回答
ひがさん
学習コストが馬鹿にならない
これまでのフレームワーク
機能性の追及
ユーザーに負荷
意外に生産性はあがってない
シーサー
あまり機能追加は行わない方向で
ユーザーに安心して使ってもらうために
枯れさせる方向で
能登さん
MobaSiF も基本的に同じ方向性
すべてが把握できることが大切
瀧内さん
Rails は初心者向けじゃない
複雑なフレームワーク
本気でやれば生産性アップ
吉田さん
Rails の暗黒面
進歩が早い
互換性よりもクールさを重視している
日本語ドキュメントが少ない
やや安定性に欠ける
開発者を選ぶ
最新技術に積極的に取り組んでいける技術者でないと難しい
ひがさん
フレームワークの作者としては機能追加はやりたい
クールと言われたい
フレームワークの今後
吉田さん
Rials にはまった人は Lisp まであと一歩！
能登さん
MobaSiF は今後も5年くらいは使っていくんじゃないか
使っている人は50人くらい
もうちょっと自由度を減らしていこうかなとも考えている
瀧内さん
Rails を使い続けていると思う
フレームワークってWebアプリ意外にもあるよね
ひがさん
安定性を重視
進化はさせない
サポート体制を維持
「設定より規約」について
Rials の影響
あんまりそっちに走りすぎるとブラックボックスに
やりすぎないように
今新しいフレームワークを作っている
質問
フレームワークの内部状態がわかるようになってたらいいな
ひがさん
シーサーはWebからフレームワークの状態がわかる
吉田さん
Rails はエラーメッセージが詳しくてよい
能登さん
MobaSiF はシンプルなのでそういう問題はないと思う
世の中の動きに関して
Java の上で Rails 等のフレームワークを使うのが流行っているが
ひがさん
そんなに使われてないんじゃないか
瀧内さん
JRuby で Rails を動かしてみたい
能登さん
JRuby に期待している知人がいる
安定性とか性能面から
質問
Debian のパッケージ作者
gems について
OS のパッケージ管理システムとどう折り合いを付けていくの？
進歩の速さについて
巷の書籍の情報がすでに古くなってるケースが
そういうのをフォローする人はいないのか
回答
瀧内さん
Ruby は基本ソースからビルド
パッケージだと古い
gems も普通に
毎月勉強会に参加して最新情報を得る
質問者
Debian にも協力してほしい
能登さん
パッケージ化というのは目から鱗
ぜひ協力したい
フレームワークはフルスタックが良いか、小さい部品の寄せ集めが良いか
ひがさん
シーサーはフルスタックだけど、必要な部品を選べるほうが良い
吉田さん
比嘉さんと同じ
瀧内さん
フルスタックがいい
能登さん
MobaSiF はシンプルなのであまり迷わないんじゃないか
ひがさん
初心者にはフルスタックであることをアピールしたほうが良い
だけども切り離せる、というふうなのが良い
まとめ
吉田さん
いろいろ使ってみてほしい
能登さん
MobaSiF 使ってる人少ない。。
Perl は Catarist がある
MobaSiF を是非
瀧内さん
いろいろ使ってみたらいいんじゃないかなぁ
ひがさん
技術を習得するときにはフレームワークを作ってみる
勉強として
ソースを読むよりも実際に書いたほうが身につく
LL でアート
LL でスケッチ
増田さん
フラッシャー
Processing とは
Java ベースの手軽な開発環境
画像、映像、音、デバイス
アーティストや、デザイナーのためのソフトウェアスケッチブック
（デモが非常に面白かった）
Ruby でインタラクティブコンテンツ
RubyCocoa
Core Animation
Leopard から搭載
Quartz Composer
ユーザー体験を重視
LL と相性がいい
Ruby + Processing
action-coding
JRuby + Processing
（面白そう）
Funnel について
マウス、キーボードでは限界
物理的な入出力を活用
funnel.cc
MaxMSP とか
真鍋さん
デザイナー、アーティスト
MaxMSP, Processing
MaxMSP
java, javascript が実行できる
2008年
やっとUnicodeをサポート
python や lua が使える
作品紹介
（興味深いデモ）
質問
メディアアートの今後
もっと巷にあふれてくるようになる
君ならどう書く
30才以下
Code Golf
モデレーター
松野徳大
Yugui
浜地慎一郎
西尾泰和
（おもしろかった）
（メモとってない。。）
古い言語新しい言語
ECMAscript
LLVM
司会
竹迫さん
サイボウズラボ
ppencode
パネリスト
若槻さん
北海道から
arohakun
llvm-gcc
森田さん
omoさん
steps to phantasien
Tamarin
c++
ActionScript
複雑な言語仕様
小林さん
Shibuya.js
JavaScript 上で動く処理系を作っている
新藤さん
BeInteractive
Shibuya.abc
本題
竹迫さん
古い言語
構文解析技術
計算機の性能
コンピュータにやさしい言語
人件費 + 管理台帳 ＜＜＜＜＜ 計算機資源
設定ファイルと言語パーサー
Apache
mod_securigy は lua 言語組み込み
Windows と Unix の比較
iniファイル読み込み、レジストリ操作
Unix には getenv しか
Unix で生まれる言語はテキスト処理が多い
小林さん
orto
JavaScript で実装された JavaVM
Java のバイトコードを読み込んで実行できる
setTimeout でマルチスレッドを実現できる
まとめ
言語処理系を作ってLLVMで高速化！
ライトニングトーク
Twitter で人工無能
dashmark
ドメインが異なるとアクセスできない
Nario
I am CRuby
GC が好き
Ruby による横スクロールゲーム
（PCのバッテリーが。。）
今、仕事で PHP4 を使ってます。
実は僕は本格的に PHP を使うのは初めてなので、言語仕様とか気になった部分から今いろいろ調べ始めているんですけど、いやー、PHP って、かなりおかしな言語ですね。
まず、コンテキストに対する考え方がどうかしてるんじゃないかと。
例えば、以下のプログラムを PHP4 で動かすと興味深い結果が得られます。
<?php
class foo {
function bar() {
echo "class name => " . get_class($this);
}
}
class hoge {
function huga() {
foo::bar();
}
}
$h = new hoge();
$h->huga();
?>
プログラムを実行すると以下のように出力されます（PHP 4.4.8 で動かしてます）。
class name => hoge
意味わかりますか？
わかりますよね。
foo のクラスメソッド bar() 内で $this を参照できて（！）、かつその $this の型（クラス）が hoge なんです！
処理としては、hoge クラスのインスタンス $h のメソッド huga() の中で foo クラスのメソッド bar() をクラスメソッドとして（PHP4 ではクラスメソッドとインスタンスメソッドの区別はない！）呼び出しているんだけど、このときのメソッド bar() における $this ってのが呼び出し元である $h を指してると。
なので get_class() 関数で得られるクラス名が「hoge」になる。
もしかして、huga() と bar() とでコンテキストが共有されているってこと？！
正確なところはソースコードを追わないとなんとも言えないけど、まあなんにせよ言語仕様的に狂ってるよね！
まさか PHP がここまでひどいとは思わなかった。
ごめん、言い過ぎた。
ま、PHPer にとってはこの程度のことは周知の事実なんだろうな。
こういった罠にはまらないように日々細心の注意を払ってプログラミングしてるんだろうな。
偉いなぁ。
PHP5 でどうなってるのかは知らないけど。
言語処理学会第14回年次大会(NLP2008) というのに行ってきました。
なかなかおもしろいですね、こういうの。
何がおもしろいって、質疑応答の時のあの微妙な緊張感。
建設的な質問もあれば、細かいところに突っ込みを入れたがるというか重箱の隅をつつきたがるような感じの質問も。
まあ、いろんな視点があるというのを知れて良いですね。
Web 上のデータからどのように意味のある情報を抽出するか、というような話題が結構多かったように思います。
総じてどの研究も大した成果は出せてない印象を受けました。
というか、まだまだ全然模索段階なんですよね、こういう分野って。
結果の数値を見ても「はあ、そうですか」みたいな、それが何を意味するのか理解しにくいものが多い。
例えば、この理論を応用してこういうことをしてみたらなんと！こんな結果が出ましたー！！、みたいな感じだとわかりやすくて良いんだけどなぁ。
それは期待しすぎか。
それぞれの研究は、結果はともかく、ケーススタディとして非常に価値があると思います。
例えば、機械学習をやろうとしたとき、そのために必要な学習データは人間が作るわけなんですが、その際にもいろんな問題が発生するそうです。
作成する学習データの質に個人間でばらつきが出たりとか、そもそもデータとしてどういうものが正しいのかがよくわからないケースがあったりだとか。
そういう問題って、実際にやってみないとわからないことが多々あると思うんですよね。
Web 上のデータ、特に CGM と呼ばれるようなコンテンツのデータを用いた評判分析の手法とかをいろいろ考えてる人がいるみたいですけど、あれは相当難しいですよ。
今の技術じゃまともな解析結果・意味のある解析結果なんてほとんど出せないと思います。
あと、これが一番重要なことだと思うんですけど、もし仮に Web 上のデータから意図した情報・意味のある情報を取り出すことに成功したとしても、それを用いて有用なアプリケーションが作れるとは限らないと思います。
つまり二段階の難しさがあるわけです。
で、現状、一段階目でかなり豪快につまづいているように見えます。
つーか、こういう Web マイニング的な分野の研究って混沌としてるなぁ。
何がしたいのかよくわからないものが多い。
意図がよくわからなくてもおもしろいものはおもしろいんだけど、おもしろければいいってもんでもないしなぁ。
形態素解析とかの話の方が研究としては純粋な感じで良い印象を受けた。
みんな本当に頭を使って研究しているなぁ、と感じた。
純粋に理論で勝負しないといけない世界だからなぁ。
知らない単語がたくさん出てきた。
ていうか、言語を理解する・文章の意味がわかるというのはどういうことなのか、というような話を本当は聞きたいんですけど、そういうのはやってないですね。
…
あさっても行きまーす。
 |
ことばはどこで育つか 藤永 保 大修館書店 2001-02 |
かなり面白かった。
あとで書く。
できれば毎日更新したいなぁと常々思っているんですが、みんさんいかがおすごしでしょうか。
認知意味論って知ってますか？
今こういう本読んでるんです。
 |
認知意味論のしくみ (シリーズ・日本語のしくみを探る) 籾山 洋介 町田 健 研究社 2002-01 |
この本の初めのほうを読む限りだと、認知意味論ってめちゃくちゃつまんないですね。
言葉で言葉を説明しようとして、自らすすんで罠にはまってるような印象を受けます。
気付いたらどうでもいいようなことばかり喋ってる、というような。
ま、でも文章は読みやすいですけどね。
しかし、「意味」って難しいですね。
いや、難しいなんてもんじゃないですね。
意味わかんないですね。
「なぜ意味が生まれるのか」というのも難しい問題ですが、「なぜそれがそういう意味をもつのか」というのもかなり難しい問題です。
…
話は変わります。
文法の話。
文法についてはいろんな理論があるようです。
いろいろありすぎて、わけがわかりません。
本を読んでもほとんどが意味不明です。
実際のところ、「理屈としてはわからなくもないけど本当にそうなのかはわからない」というような理論だらけなんじゃないでしょうか。
いろんな人がいろんな理論を組み立ててますが、いったいどれが正しいんでしょうか。
ふと思ったのですが、もしかすると、実際の文法の「ルール体系」って一つだけじゃないんじゃないでしょうか。
つまり、複数の「ルール体系」が並存しうるんじゃないかと。
例えば、それぞれの脳によって採用されている「ルール体系」が違ったりするんです。
グループ間や世代間で違ったりするわけです。
時間が経つにつれ、その「ルール体系」が変化し、それによって新しい表現が生まれたりするんじゃないでしょうか。
「ら抜き言葉」とかも、そういうことなのかも。
…
あー、ていうか、この程度のことなら他にも同じこと考えてる人がいるだろうな。
