私の勝手な感想

まず主催者だったんだなぁ的な・・・。主催者っていうか・・・。
はじめに皆さん集合時間にルーズで、でもまぁそれを見越しての11:00だったので、最初に来た人は幻のゾンビFLTVが見られました。
見ても何も良い事は無いですけれども。

真っ黒Scheme

Schemeの自己反映言語/meta-circular intepreter Blackについての話。

存在自体については、5/5にあったPPIMの帰りにh_iwkさんから聞いて、名前もアレらしいという事からも興味を持っていたんですけれども論文が英語で書かれていて、成る程、アメリカ人向けなんだなという事でスルーしていました。

・・・その時には、ヤドカリさんが発表する事になるとは想像していなかったのだ・・・！！

という事で、個人的にはいつのまにか忘れていた気になるお話を聞けたという事でも面白かったです。
あとは、そもそもヤドカリさんが知ったのがh_iwkさんのコメント経由とかいう事で、うーんちょっと業界は狭いのかもしれない的な。どの業界だろう。

リフレクションタワーを上がり下りする、という感じよりも、現在のレイヤー(階数)表示(?)を見ていると、だるま落としみたいだなーとかいう事を想像していました。
レイヤの切り替えは、通常の継続に押し込んでるのかみたいな事を考えていたんですけれども、メタ継続なるものも在るらしくて、多分なんかその辺がソレなのかなみたいな。

それと、ヤドカリさんの問いとしては
「そもそもプログラムで書き換えるよりも、自分で書き換えた方が良いんじゃないの(実行速度から来る悲しさを考慮した上での発言)」
というのがあって、それはまぁ、出来る時にはそうだなーとかいう事で、私は逐一やるのが面倒臭いケースとして、どっかから書き換えなさい命令が飛んでくる時はどうでしょう、とか返したのでした。

でも、それにしても、そもそも「Schemeの評価器を書き換えるプログラム」を起動して直に書き換えれば良いんじゃないかとかいう事もあるのですけれども動いてるヤツを書き換えるっていうのは少し考えにくいですし、自身を弄れるという事は分かってる人は凄く良く分かるから良いんじゃないかなーとかは。

ただ、ヤドカリさんが、「弄るためのインタフェイスがちょっと分からないとアレですよね」という事を言っていて、でもそれはSchemeの処理系は皆一度は書いていて骨格を掴んでるでしょうから大丈夫なんじゃないかなーとは。

貴重な話が聞けて、頗る幸せでした。

重要な事を忘れていました
日本語辞書登録を有効に活用しようコレですね。

未来のハードウェア言語

ハードウェアをやっている人達のお陰で、頭の悪いプログラムもそれなりに動くので、日頃から本当に感謝しています。
500倍遅く成っても、ハードウェアさんが500倍速くなるから大丈夫ですね。そういう発表ではありません。

ランダムチェック、アサーション、カバレッジの辺りへの繋ぎの背景が伺い知れるような前半は、私はHW記述言語って全然知らなかったので助かりましたというのも在って凄く良かったです。

ただ、そういう「動きを徹底的に調べる」ような事は多分Cとかあの類いの「実行単位が流れて行くのを書いて行く」系の言語でやるからそもそも出てくる事で、本当はもうちょっと定義中心でやるべきなんじゃないか・・・と思っていたらの後半で「ルールベース」「Bluespec」が出て来て、はー凄いスライドだとか思ってました。

CPUカスタマイズや、コプロ生成もイケイケ過ぎて大変です。

この感想を書きながら気付いたのですが「ハードウェア記述言語」って、ハードウェアを「記述」するものであって、その雰囲気は「CやC++で書く」事とは違う雰囲気があって、そういうのも実はどこかにあるんじゃないかな、とか。

ただ、聞きながら意味の分からない質問をする事は私にも出来たんですけれども、その現場は、未就業者で学生の私からは想像の付かない所なんであろうなとは・・・。

並列に動かす何か

未来なのに並列とか全く無いのかと思ったら、矢張り在りました。

異常に頑張らなくても良いっていうのが良くて、実際にCellでコード書いた事がある人は通信部とか苛々でガッデムだろとか多少は痛み入る部分が在ると信じていて、なので多分嬉しいだろうなーとは。私はアレぐらいで書けたら満足があると思います。

Erlangは良い時は良いんですけど、格好付けたい感じだとやっぱりGHC/KL1みたいなんかなーとか。

凄い格好良い事をやろうと思うと、未来では並列を利用するべきな感じにはやぱりなっちゃうとは思ってはいます。
その時には、ハードウェアが追いつくかとかいうよりも、ハードウェアは多分理論のハードな実装だと思っているのでそれは後から追いついてくれるでしょうから、今のうちにソフトな色々をやっておく必要があるかもしれません。

今度π計算と戯れる会とかが在っても良いかもしれません。私は全然π計算は知りませんけど。

あんまり書くとヤバいと思うので自粛

Haskell 98以降の大雑把な進化

白石さんは、view pattern周りの話を丸投げにするんじゃなくて、英語が読めない高校生とかの為にちゃんと纏めるべきだと思います！！

あとは、Haskellでスライドで話していた内容の周りって全くやった事が無いので、なんかの時にやるって書いて、多分やらないんですよねぇ・・・。

Data Paraとかどこで使おう・・・。

兎に角、view pattern考察を書いてください！！view pattern view pattern view pattern view pattern view pattern view pattern view pattern view pattern

それと、CmmとData Flow Analysisの話もです。バックエンドの話って、実は日本語のヤツ全然無いので、それを白石さんがやらないで誰がやるって感じです。そう、白石さんがやります。

未来言語Alloy

発表内容とは余り関係無いですが、さかいさんのコードはAlloyの使える部分をちゃんと使っているコードで、取りあえずイントロダクションの最初数ページだけ見て、分かる部分だけでやった私のソレとは全然違うんだなぁとか言う事を一人で思ってました。

そもそも、日本語のAlloyの発表とか希少さがあると思うので、ラッキーっていう感じなのに加えて、凄く分かる話でした。

小スコープ仮説の話は初めて聞いたのですが、これはもはや仮説レベルの話じゃなくて凄く良くあたる話だと思っていて。
結構自明な部分というのは、書く時に「書き損ねちゃう」事があると思っていて、そういうソレで、「少なくとも、小さいレベルにミスが発生する」んじゃないかなとは。

しかも、Alloyさんはそういう簡単な問題の時のモデル表示は必然的に簡単で見取り易く図示されて幸せで、結果的にそういう自明な部分を消して行けば全体的に正しくなるというスマートさみたいなモノも自然に備わっていて凄いと思います。

ただ、書くのが面倒臭いんですけれども・・・。

Alloyは問題の理解の定着とかを見るのに当たっても凄く使える言語/システムだと思うので、実際に発表を聞いた方がパズルとかに挑戦して見ると楽しいんじゃないかなと。私が言うのもなんですが。

こういう定義寄りな記述を普段あんまりしない人にとってもまず触り易いと思いますし、反例がちゃんと出てくるのも親切だと思いますし。
逆に、そういうの割とやるって人に取っては、少し面倒臭いなぁみたいな感じかもしれません。

"Software Abstractions"は読みたいです。

ドリームクラブ

全然ネタじゃないどころか凝っててひー流石もひかんさんや・・・。って感じでした。

Prologでマクロとか要るシーンは、私には考える事すら能わずなので、その発想からして異常じゃないかと。

Prologでこれやると死んじゃうかなーみたいなsnippetを書く時に、なんでこれがこうなんだみたいな苛つきが発生するので、そういうの解消出来たりするのかなーとか思ってたんですが、全然分かりませんでした。

割とsyntaxが苛つく時があるので、そういう時に自然とコレが出来ると良さそうで、というかマクロかぁみたいな・・・。
徹底的に押し進めると、Haskellさんの関数従属的な何ソレで似た感じでエンコーディング出来て楽しそうかなぁと思ったけど、そういう使い方は楽しく無いです。

本気でPrologなもひかんさんは、ですから、The Craft of Prologの英語を日本語にしながら理解する何かを絶賛やって欲しいなーと思いますです。
私が毎回行くので、少なくとも1人確定という事にしておいてください。お願いします。

それと、Prologをはじめるべき〜みたいな話はちゃんと在って、生活が豊かに成るとかがあると思います。
単純にunify的な発想だけじゃなくて、バックグラウンドに理論の話があって、そこに述語論理とかの話があって、普段あんまりやれない事にも親しめる的なそれとか、それとか。

私はPrologをお勉強したお陰で、TaPLも読めますし、よりHaskellさんが分かるっていう感じにもなるので、Prologは凄くお得です。まず損する訳が無いみたいな。

でもPrologのコードとかは全然書かないで処理系書いた系の私にはやっぱりThe Craft of Prologの英語を日本語にしながら理解する何かは絶賛ですねー。

国に消される前に

hogelogさんは本当にホシノ・ルリさんに対して何かで、安心を覚えます。

でも私は機動戦艦ナデシコを見た事が無いので、見ます。見ます見ますいう詐欺が最近は多いのがでもなぁ・・・。
リマスター版が出てるんですっけ。

Luaは全然知らないので、ごめんなさいって感じだったんですが、良いGCで良いエロゲーが作られる事を信じています。

Language Tranceparency

「言語というレイヤーを無くす言語」で、あの中間表現が絡む図が出て来たのが少し不味かったんじゃないかという感じでした私的には。

yharaさんのUnbabelみたいな感じかなーと思ってたら何か違うらしくて、何が違うんだろうという事を考えていました。

LLVM IRとか、JVM Byte Codeとか.NET CLIとかは複数の言語が落ちる先としてはそうで、あれだと他の言語で書いて同じソレに落ちるソレはライブラリとして使えるので、それだと多分なんか違うだろうから、というかアレから元の言語に復元出来るメリットが何だろうみたいなそれでうーん結局良く分からないぷいという悲しい感じでした。

他の人は分かってる感じだと思ったので、分からない私に説明してくださいよ！！

分からんぷいに成ったので、他の言語を丸ごと何らかの抽象化レベル(関数単位とかライブラリ単位)で持てる言語自身はそうなのでは無いかとか思ってて、その言語が持つ何かが、含んだ全ての言語の最小公倍数的に「成らない」ようにすればどうなるんだろうとかいう事を考えていました。

最小公倍数で考えるとUnbabel風になるのでそれは面白く無いだろうなぁと思っていたら、寧ろ他の言語が持つライブラリの「何それ」を「自分とこで欲しい」と思うって事が出てくるんじゃないかと思っていて。

それは他の言語が呼び出せるレベルの話じゃなくて、自身の言語で表されるとどうなるのか。

で、それは実はかなり難しいと思っていて。
それと絡んで、私がマルチパラダイム言語が嬉しく無いのは、あいつらは大体適当にホニャララーって書けて信念が無い。他のヤツで出来るののパクリじゃないですかみたいな。パクリはパクリで良いんでしょうけどまぁあんまり好きじゃないっていう。良い悪いの問題じゃなくて単純に好きじゃないです。
本当は自分の哲学に基づいて/自分の神に従って(それは大体他の哲学とか神を含んでいない系)、そこで何かを記述するっていうことが恐ろしく大事な事だと思っています。勝手に。

なので最小公倍数的表現(共通データ型でのやり取り)のレベルじゃなくて、「あの言語のソレがこの言語のドレに対応する」を徹底的に考えれば双方向な変換は出来ると思うんですけどそれはあんまり嬉しく無い。
嬉しいっていうのは恐らく「この言語でこう書けるのか！！」っていう大発見的なものがある時かなーと思っているのでうーん。

むしろ「他の言語がこうなんですよー」という「他の言語の中身を勝手に記述出来る【若さ溢れるニューパワー(http://www.nicovideo.jp/watch/sm338963)】を持つ言語」だとムテキングじゃないのでしょうか！！！

と思って、それ以上は何も考えていません。

Luciferの設計コンセプトと導入予定の機能紹介

オープンバイナリは多分文字通りのバイナリの意味じゃなくて、どうバイナビリティを持たせつつ表現するのか。
あと、バイナリを読む人間は希有なので、それと好き嫌いさんが有るのでオープンなソレが選択出来ると幸せなんじゃないか。

ビューイングシステム(統合開発環境とイコールでは無い?)が発展しろっていうのはあって、ホントソレだよ！！っていう。
人間は愚かな生き物で、何だろう世間的には、IDEとか使わないwwwとかいう流派があるらしいですが、仕方なくemacs使ってる私(別にこれはemacsがダメとかじゃなくてemacsとあんまり変わらない気がするので使ってる)にとっては、清く正しいビューイングシステムは血眼で欲しい。

神性さと魔性さという分け方は良くて、厳かな雰囲気もうけるので、カッコいい、スタイリッシュ、イケイケとか馬鹿さ溢れる表現を控える為に今度から勝手に使わせてもらおうと強く心に誓う私であった。

  • 豊富な型修飾 plenty type qualifications

豊富な型修飾さんは酷く欲しいかなーと思っていて、でも某Haskellさんではここの所を問題にする時は余り無いのでPureなC++心を失って来ている私の頭をかち割りたく成りました。

  • 型復元/修飾復元 type restore / qualification restore

妥当な推論を行うという理解で良いのかな。まぁその妥当が何だろうかという所なんですが、そこはタイトに締め上げれば良くてでも多分こういうのはややっこい。

  • 完全演算表示 providence

これは程々に良いなぁと思うんですけど難しいですね。
それから、主目的である可視性の確保が、バグを殺戮し尽くすという所に繋がる面があるならば、そもそも人間に証明を書かせるのが良いんじゃないかというのが在って。
バグが出るケースの１つとして、コレは明らかにこうだろという思い込みが、言語さんが準備している事と完全一致しない場合。つまり100%ヒットしない場合。
100%ヒットを目指す場合は証明するべきであると思うし、完全に理解の違いがある場合は知らないって感じです。
それがダメなら、値レベルassertionするしか無いんじゃないかなぁというソレで・・・。

値が小さいケースならこの方法でも良いと思うんですけど、もうちょっと複雑な場合はその図形的出力を見るのも困難だと思うので、1次元的に証明出来た方が良いのかもしれないなぁと思っただけですスイマセン・・・。

  • 超例外処理 super exception handling

名前が超ネガティブだなぁと思っていたら、発表を聞いてて凄く妥当な名前だと認識を改めました。
所謂「本筋として返したい値」に対して、そうでない値を単純に例外とするならば、まぁ現状その例外さんの持てる情報量は少ないので、もっとどでかい感じで返すとそれは結局例外を越えてるので、超例外なネーミングになるのかとか。
でも多分ここまで難しい事を私が考えていたら死ぬのでうーん・・・。
単純に実行ヒストリを丸々取って来ておくとかだったら、最後の最後で死ぬ時に、デバッガさんとかで戦わなくて良いので楽かなとかは思いました。

  • 連鎖参照 presenter

多分私の頭が悪いので、実際にコレを書かれると混乱して死ぬので、普通に型推論してくださいって感じでした。

型復元/修飾復元のところでにはさんがバイナリメソッドのような問題が出るんじゃないかと話していて、でもこの辺は他にも問題がある気がするのでともかく先に実装を為されて、実際に問題点が出てからとかで良いんじゃないかと思います。

問題点が出るって事は、もしかしたらより良い方法が出るかもって感じですし。
ただ、「先に実装をして」とかっていうのは軽々しく無い感じだっていうのは分かるんですけれども・・・。

C++にJavaのジェネリクスっぽい機能を入れる案

買い出し行ってて聞いてなかった組なので、情報を元に発表を復元してみる。

http://niha28.sakura.ne.jp/b/log/54
http://www.kmonos.net/wlog/85.html#_0753080507

バイナリのレベルの話は、別にバイナリレベルでアレだったらソレっていう全くにはさんが書いているその事に注目しちゃって、私もココイチで発表聞いた時はソレだったら全くソレで良いんじゃないかなーと思っていて、ところがどっこい後で見るとお前そんなバイナリの話を考えながらカレー食べててすいませんという感じに成りました。

まぁ私はJavaのジェネリクスは知らんので、キーッ！！！ってなってた。うひ。今度Wadlerさんの本を買って読みます。まぁJavaは使わないので本当に読んでみるだけです。

JavaのGenericsって、C++を知ってる人としては、セマンティクスとしては、本当にテンプレートのソレに見えるって感じなんですよね。まぁ、見えるだけなので、実際には違います。

具体的には

#include <iostream>
#include <string>
using namespace std;

template<typename T>
struct SimpleType
{
    T v;
    void set(T val){v = val;}
    T get(){return v;}
};

int main()
{
    SimpleType<char> Char;
    Char.set('0');
    cout << Char.get() << endl;

    SimpleType<int> Int;
    Int.set(0);
    cout << Int.get() << endl;
}

C++のコレっていうのは

class SimpleType<T>
{
    public T v;
    public void set(T val){v = val;}
    public T get(){return v;}
}

public class Simple
{
    public static void main(String args[])
    {
	SimpleType<Character> c = new SimpleType<Character>();
	c.set('0');
	Character c_ = c.get();
	System.out.println(c.get());
	
	SimpleType<Integer> i = new SimpleType<Integer>();
	i.set(0);
	Integer i_ = i.get();
	System.out.println(i.get());
    }
}

Javaのコレでは「無い」って事です。

まぁJavaは知らないんですけど・・・。

前者の方は、

__ZN10SimpleTypeIcE3setEc:
00001e00	pushl	%ebp
00001e01	movl	%esp,%ebp
00001e03	subl	$0x18,%esp
00001e06	movl	0x0c(%ebp),%eax
00001e09	movb	%al,0xf4(%ebp)
00001e0c	movl	0x08(%ebp),%edx
00001e0f	movzbl	0xf4(%ebp),%eax
00001e13	movb	%al,(%edx)
00001e15	leave
00001e16	ret
00001e17	nop
__ZN10SimpleTypeIcE3getEv:
00001e18	pushl	%ebp
00001e19	movl	%esp,%ebp
00001e1b	subl	$0x08,%esp
00001e1e	movl	0x08(%ebp),%eax
00001e21	movzbl	(%eax),%eax
00001e24	movsbl	%al,%eax
00001e27	leave
00001e28	ret
00001e29	nop
__ZN10SimpleTypeIiE3setEi:
00001e2a	pushl	%ebp
00001e2b	movl	%esp,%ebp
00001e2d	subl	$0x08,%esp
00001e30	movl	0x08(%ebp),%edx
00001e33	movl	0x0c(%ebp),%eax
00001e36	movl	%eax,(%edx)
00001e38	leave
00001e39	ret
__ZN10SimpleTypeIiE3getEv:
00001e3a	pushl	%ebp
00001e3b	movl	%esp,%ebp
00001e3d	subl	$0x08,%esp
00001e40	movl	0x08(%ebp),%eax
00001e43	movl	(%eax),%eax
00001e45	leave
00001e46	ret

こんなんがあって、所がJavaさんでは

/Users/ranha/FLTV/misc% javap SimpleType 
Compiled from "Simple.java"
class SimpleType extends java.lang.Object{
    public java.lang.Object v;
    SimpleType();
    public void set(java.lang.Object);
    public java.lang.Object get();
}

Objectさんに成ってます。ぎょえー。まぁC++の人としては肝心なのは「それで、型パラメタ毎にインスタンス化されてるの?」なんですけれどもされてません。

じゃあどうなってるのかなんですが、Objectからのdown-cast時に事が起こります

/Users/ranha/FLTV/niha% javap -v Simple
色々略
const #7 = class	#27;	//  java/lang/Character
const #27 = Asciz	java/lang/Character;
const #11 = class	#33;	//  java/lang/Integer
const #33 = Asciz	java/lang/Integer;


   11:	invokestatic	#4; //Method java/lang/Character.valueOf:(C)Ljava/lang/Character;
   14:	invokevirtual	#5; //Method SimpleType.set:(Ljava/lang/Object;)V
   17:	aload_1
   18:	invokevirtual	#6; //Method SimpleType.get:()Ljava/lang/Object;
   21:	checkcast	#7; //class java/lang/Character ！！！！コレ！！！！
   24:	astore_2
   25:	getstatic	#8; //Field java/lang/System.out:Ljava/io/PrintStream;
   28:	aload_2
   29:	invokevirtual	#9; //Method java/io/PrintStream.println:(Ljava/lang/Object;)V

   42:	invokestatic	#10; //Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
   45:	invokevirtual	#5; //Method SimpleType.set:(Ljava/lang/Object;)V
   48:	aload_3
   49:	invokevirtual	#6; //Method SimpleType.get:()Ljava/lang/Object;
   52:	checkcast	#11; //class java/lang/Integer　！！！！コレ！！！！
   55:	astore	4
   57:	getstatic	#8; //Field java/lang/System.out:Ljava/io/PrintStream;
   60:	aload	4
   62:	invokevirtual	#9; //Method java/io/PrintStream.println:(Ljava/lang/Object;)V

まぁcheckcastっていうのはこの辺(http://java.sun.com/docs/books/jvms/second_edition/html/Instructions2.doc2.html)に書いてるんですが、キャストしても大丈夫かなーみたいなのを調べるだけです。

なので、インスタンスは起きませんねっていう。その意味では、ある種type erasureです。

この辺は誰でも知ってるので良くて

だから C++ にも Java の generics の type erasure ない奴ください

type erasureない奴っていうのは、例えば上の例だと意味的には

struct SimpleTypeChar
{
    Char v;
    void set(Char val){v = val;}
    Char get(){return v;}
};

struct SimpleTypeInt
{
    Int v;
    void set(Int val){v = val;}
    Int get(){return v;}
};

で、「型が違う」んですけど、Javaの奴は根本的にObjectにぶち込んでるだけで「オブジェクトの型としては同じ」でこれが以下なんとかっていうのは、多分偉い人が書くので省略します。

良く訓練された人にとっては、「型の違い」で「何」が「なになにタイム」その他が出来て「何だ」っていうのが分かるらしいです。

私は最近Agda2してて、値と型の区別が付いたり付かなかったりで謎です。

レトリカル・プログラミング

「プログラミング言語」 と見ると恐しくパワフル

楽なのは慣れてるからじゃない,ヤツらがもの凄く強力な言語だから！という発想

この一文は、軽く見ただけだとそうかなーと思うんですが、良く見ると「慣れてるから」じゃないと言ってます。素敵。
このヤツらというのは、自然言語の方です。

kinabaさんの発表なので、どうせ凄いんだろうなーとかじゃなくて、この発表は今回私が発表した所から見るとかなり特別な所があるのでした。

特に後半の、主述述語文(shinhさんが出てくるあたり)の話が楽しい。
会場でも質問があって、スライドにも追記されてるのですが、「関数型言語でいう部分適用(それをクラスのメンバとして持たせて解消するとかじゃなくて！)」をどう「メソッド/メッセージという概念を崩さず」やるかっていうのは、割と凄い事だと思っています。

というのも、一応主催者らしいので、本格的な未来の言語を考えないといけないだろうなーとか実は私も考えていました。
で、それを考えるのが大変な時に、昔の何かを「別のパラダイム(Haskellとか)で書き換えると何か面白く成ったりしてそれで茶を濁すか」というのを考えていて、結局しなかったんですけれども、その観点から見ると結局それをやってのけちゃってるという意味で凄い。

普通の人って、Hoge言語で出来る事をFuga言語でやる時って、Fuga言語の方の「割と残念な方法」でやってのけてソレが終わりかなーって感じになるんですけれども、実はそれって本当にねちっこく考えると面白い所と繋がってたりします。
それこそ、Hoge言語の「有利な事」をFuga言語でやる時って、あんまり率直な方法で出来なかったりして。
で多くの人(私も多くの人側)はそこで諦めちゃって死ぬんですけど、死ぬっていうのは、まぁそんな感じです。ところが、「なんでコレこうなってんねん！」みたいな苛々が爆発しちゃう人、言わば、普通の人より沸点の低い人っていうか切れやすい人はそういう普通の人には視得ていない事が視得てるんじゃないかなーと思っていて・・・。

takano32さんの話の感想と絡めると、同じ事をやるにも「残念な方法」と「イケイケな方法」があって、イケイケっていうのは私の経験上哲学とか神に従ってる方法みたいな、だからどんどんイケイケな方法で、他でやっている事が翻訳出来ないかなーっていうのを考えるのは割と重要です。

感想としては大分ずれちゃったんですけが・・・。

あとコレも関係無いですが、頭の中では「日本語で考えていて」それを言語さんに落とす時で失敗する時がある、論理結合子のならば、またはとかっていうのは割と難しいんじゃないかなーとか、だからそれがどう考えるかっていうのはソレです。

パクるのもやりよう、っていう感じですね。知らない・・・。

話自体としては
http://d.hatena.ne.jp/sumii/20060512/1147427566
や
http://www.tom.sfc.keio.ac.jp/~sakai/d/?date=20080413#p01
この辺も読んでみよう。

最後に

会場を提供してくれたチームラボの皆さん、本当にありがとうございました。
皆さんのおかげで、平穏にイベント自体を行う事が出来ました。
特に、私に至らない点が多々あり結局宣伝タイムが無かった事は、本当に申し訳ないです。

Ustreamの配信/録画は、全てtksさんのおかげで出来ています。本当に感謝しています。

tksさんは、当日も配信に集中してくださっていて、そのおかげで私がずっと他の人の発表を聞く事が出来ていたのですけれども、そこに関しては無駄に長い感想で何とか補えればと思います。

また、殆ど何も考えていなかった状態でもこれだけ上手く回ったのは、「あの主催者はきっと何も考えていない」という事を考えてくれていた方々のおかげだと思いますので、誰とは言いませんが、多分皆さんなんですが、ありがとうございました。

また次回何かを私が企てた時も、基本的に参加者皆でなんとか立ち回せるがポリシーですので、その意味では気兼ねなく参加してください。宜しくお願いします。

みなさんの夏の１つの思い出にも成っていれば、(一応)主催者としては最大の幸せです。