;.png)
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のバッテリーが。。）
