トップ «前の日記(2012-08-25) 最新 次の日記(2012-08-30)» 編集

はじめてのにき

ここの位置付け

2004|11|
2005|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|04|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|04|05|06|07|08|09|10|11|12|
2012|01|02|03|04|05|06|07|08|09|10|11|12|
2013|01|02|03|04|05|06|07|08|09|10|11|12|
2014|01|02|03|04|05|06|07|08|09|10|11|12|
2015|01|02|03|04|05|06|07|08|09|10|11|12|
2016|01|02|03|04|05|06|07|08|09|10|11|12|
2017|01|02|03|04|05|06|07|08|09|10|11|12|
2018|01|02|03|04|05|06|07|08|09|10|11|12|
2019|01|02|03|04|05|06|07|08|09|10|11|12|
2020|01|02|03|04|05|06|07|08|09|

ToDo:


2012-08-27

_ プロシン日記

http://spro2012.prosym.jp/

プロシン前半は NaCl とたわむれながら話を聞いていた。

竹内先生はテーマがテーマだけに、いつも以上に良い意味でヨタ話としか言えないような。面白いヨタ話できるのはいいことだなぁと思う。

エラー話はエラーに他のコードが混じってくると型とかややこしいことになる気がするんだけどなぁ…と思ったんだけど、後で雑談で他の人に聞いたり、本人に質問したところ、僕の Haskell レベルが解答の意味がわかるレベルに達してないということがわかった。 Haskell ちゃんと勉強しないと話についていけないな…

指針はこう、唯一ビューティフルに真っ向勝負という感じで、しかし真っ向勝負するとええそうですよねーというだけという感が。あとああいう話ってプラクティカルな感じがあまりしないような。発表じゃないけど、関数が長くなるなんてことはありえない、っていう質問は、複数人開発してると自然と長くなる気がするけどな…とそいう意味であまりプラクティカルでない気もした。片方が短い if else はさっさと if continue すると良い、っていうのは webkit とかでもなんとなくそんなルールがしかれてたりする。まぁ良いと思う。

Ruby がこう、 Quine はまぁやればできる感じなんだけど、小文字しばりは個人的にすごいヒットだった。と言ってもすぐにこれはすげーと思った感じではなくて、自分で説明されてるテクニックを書き写してみてはじめてすげーと気付いた感じだったんだけど。

このへんで NaCl でハマってたので、 Ruby いじりにスイッチした。 1.9 では String#each が存在してなくて助かった、ってのと rescue ensure による値の一時退避は、どっちも大変素晴らしいテクニックだと思う。 1.8 でなんとかならんか…ってのと rescue ensure が直感的に一つで良いのではないか…ってのはずっと考えてるけど今のところ思いついていない。ゴルフ場の Quine のところにぜひ欲しい解答なんだけど、 1.8 とサイズの両方がネックになる感じ。 1.8 さえなんとかなればサイズはなんとでもなる気がするんだけどね…

x86/64 は str 命令相変わらずすごいなって感じだったけど、まぁ正直 Ruby のこと考えすぎてて途中ついてけてなかった感が。

ビスケットはかっこよかった。なにか色んなことを考えさせられる感じの。いよいよビューティフルかどうかは知らないけど…近いものとしてはメイドイン俺なんだろうけど、あれよりシンプルにできてる気がしたなぁ。任天堂から出せば良いんじゃ。 http://www.viscuit.com/

kinaba さんの話はあいかわらず面白かった。面白いもの見た時に、すぐに自分で今度使ってみよう…となりにくいのは反省しないとなぁと思わされた。1個目と3個目はたぶん見たことある感じの話で、2個目はなるほどこういうことするのかと。

@_ko1 さんが twitter に functional data structure が何故重要か聞いてわかった、とか書いてて、それはどういう話だったんですか、と今日聞いたら、 map とかだと変数テーブルみたいなやつがスコープ出る時にスタック巻戻せば自動的に元の変数テーブルに戻るとか言ってて、なるほどなぁと感心した。 node を reference count してやれば C++ でも同じもの実現できる?と質問したら yes とのこと。 parent ポインタいらなくなるからメモリ消費も安い、とのこと。でももう少し議論しててスコープ出る時に map 全部なめて reference count 減らさないといけないかな…という話になってダメっぽい気がした。なんかまた考えるとなんとかならんのかな…という感もあるんだけど。あと queue は別に実用性は無いとのこと。

和田先生の話は、この人いつもゴルフの話に聞こえるな…と思ってました。結論がゴルファー向けのアドバイスとして秀逸。

全体的に話が詰め込みすぎに感じるのは、やはりこういうテーマだとみんな語ることが多すぎるんかな…とか思った。

僕が美的なものを感じるのは…と考えていくと、だいたい

http://shinh.skr.jp/slide/mederu/000.html

に書いたな…とか思いました。

あと、久野先生的な意味でないビューティフルはたいていトリッキーなコードと紙一重なのが多くて、例えば free list とかかっこいいけど、久野先生的な意味ではかなりダメだよね…とか。まぁなんかトリッキーなコードは避けた方がいいと言うのはそうなんだろうけど、こう重要なとこで光るのはかっこいいよね…

あと、 STM はこう議論というか、実装のタイプが僕の中で整理できてなくて、相手と前提を共有するのにいつも時間かかってよくないな…と思う。 Haskell もそうなんだけど、自分があんま信用してない技術だけに、時間かけて勉強する気があまり起きなくて困る…

(01:35)

_ downcase hello

とりあえず mame さん的なやりかたで hello は ruby 1.8 でできたけど…

http://shinh.skr.jp/dat_dir/downcase_hello.rb

(03:15)

_ できた

yatta-

あとはゴルフすれば quine できる

(05:03)

お名前:
E-mail:
コメント:
人生、宇宙、すべての答え
本日のリンク元

2012年
8月
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31

search / home / index

全てリンクフリーです。 コード片は自由に使用していただいて構いません。 その他のものはGPL扱いであればあらゆる使用に関して文句は言いません。 なにかあれば下記メールアドレスへ。

shinichiro.hamaji _at_ gmail.com / shinichiro.h