トップ «前10日分 最新 次10日分» 追記

はじめてのにき

ここの位置付け

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|10|11|12|
2021|01|02|03|04|05|06|07|08|09|10|11|12|
2022|01|02|03|04|05|06|07|08|09|10|11|12|
2023|01|02|03|04|05|06|07|08|09|10|11|12|
2024|01|02|03|04|05|06|07|08|09|10|11|12|
2025|01|02|03|04|05|06|07|

ToDo:


2010-09-16

_ だっくたいぴんぐ

色んな論点があって何が何やら。おもろい。

個人的には、楽できる、ってのはそりゃまぁわかるんだけど、 interface のドキュメント能力に比べて はるかにどうでもいいなーというだけのことが、 元は言いたかっただけなので、 まぁ duck typing のメリットを説明してもらっても 説得されない感じかなーと思いました。

そしてまぁ僕のそのドキュメント能力についての文句は、 たぶん const とかの話と一緒で、 結局まぁ動的言語でデカいもの書きたくねーって言ってるだけにすぎないので、 まぁ言語機能とかを議論してる人には面白くない論点で ごめんなさいという感。

いつも言ってるんだけど、 会社で Python 書くのが楽しくなかったんだよね。 duck typing なはずなのに document 書かんと使い方伝えられないし、 これならいっそきっちり型書かせてくれーという。

さて、本題のだっくたいぴんぐの各論について、 どうでもいい思ったことをそこはかとなく。

http://shinh.skr.jp/m/?date=20100914#c01

interface 多すぎーってのは、 うーん本当にそうかなぁ。 Serializer ってクラスがあるなら Serializable 作らにゃならんのはそうなんだけど、 しかしまぁなんでもかんでも用意する必要は無いんじゃないかなー的な。 なんか標準ライブラリ内に実際に 同じ interface を使うものが複数無い場合は、 まぁ作らんでいい、みたいな基準くらいでいいんじゃないかなぁ。 Java なんかはまぁ、頑張った結果だろうけど、 ありそうなものがあるんじゃないすかねえ。

interface の例として、 Runnable みたいなのがあると思うんだけど、 Ruby の proc って proc like なもの作ったとして、 はて Proc#call を用意すればいいのか Proc#[] を用意すればいいのか… みたいな、まぁドキュメント頼らにゃならんなら、 最初からコードに interface 書きゃいいじゃんねえ的な。 まぁ他の人も言ってる話だけど。

http://shinh.skr.jp/m/?date=20100914#c04

後から interface …って話は、

http://twitter.com/yukihiro_matz/status/24542099876

にある通り Go のアレはそいうのできた…と思う。自信ないが。

http://shinh.skr.jp/m/?date=20100914#c09

は respond_to? とか使ったらそれこそ duck typing の良さってか動的型付けの良さが 失われちゃってる感があるなぁ。 Guido がそういうのはやっちゃダメって言ってた気がする。

ああ matz 先生も言ってる。

http://twitter.com/yukihiro_matz/status/24545594351

あと、そうそう、 duck typing いらねーいらねー言っておきながら、 一個致命的に重要な用途を思い出したのだった。 何かっつーと unit test のための mock というやつ。 あんなもんのために interface とか書きたくない。

(03:46)

_

最初の、

個人的には、楽できる、ってのはそりゃまぁわかるんだけど、 interface のドキュメン
ト能力に比べてはるかにどうでもいいなーというだけのことが、元は言いたかっただけ
なので、まぁ duck typing のメリットを説明してもらっても説得されない感じかなーと
思いました。

はひどい後付けだなー。

昨日の段階では

色々考えた結果、 interface を書かなくていいという type 数節約よりも、 interface
のドキュメントとしての価値の方が重く見てるんだろうなぁと思った。それと同時に、
duck typing は別にメリットとか無くて、動的型だからしょうがなくやってるだけなん
じゃないかと思えてきた。

とか言ってるんだから…

まめさんごめんなさいごめんなさいごめんなさい…

(03:53)

_ そいや

LL っていうけどホントに lightweight なんだろうかー ってのはちょっとイベントとして面白い気がする。 なんか例えば、 C++ と Ruby の人が適当に、 codegolf.com くらいの規模の問題を 10 問程度解いていって、 どっちが早く終わるか、みたいな。 ああでも duck typing とか登場させるならもうちょい規模大きいべきか。 こいう仕様の wiki 作ってくださいーとかそんくらいすかね。

LL イベントとかでやるといいんじゃないかな。 そのイベントでコード書く人はイベントそっちのけで ずっとコード書いてて、 途中で時々進捗聞いたりするとそれぞれの言語の良いとことか 見えたりするやもしれず。

しかし、回答者のレベルをそろえるのはむつかしそうである…

(04:00)

_ おかしい

http://shinh.skr.jp/m/?date=20100916#c02

自分の spam filter を突破できなくてコメント書けないぞ…

> duck typing なはずなのに

「duck typing だから型書かんでいい期待があるのに、結局 document に型書いてるようわーん」という話でした。途中はしょってましたすいません。

http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py

とか見ると、

 Args:
   filename: str, the name of the input file.
   raw_line: str, the line of input text, with comments.
   linenum: int, the number of the current line.
   error: function, an error handler.

とか書いてて大変悲しいわけです。

> is_a? と respond_to?

ああ is_a? はたしかに論外ですね。ただ respond_to? 使うのも、実際はたいして問題にならないことのために (respond_to? で調べて runtime error 出しても、ほっておいてメソッドが無いっていう runtime error が出るのもたいしてかわらない) 動的言語の気軽さみたいなのが損われるという意味で、イマイチなんじゃないかなぁと。

> # 実は大して興味ないはずのこの話題に、どうしてぼくは長文をつっこんでいるのだろう……

ブログ炎上させたい場合はスキのある文章で人の好きな物を批判するといいみたいですね。

(13:52)

本日のツッコミ(全5件) [ツッコミを入れる]

_ もわ [> duck typing なはずなのに document 書かんと使い方伝えられないし、 これならいっそきっちり型..]

_ mame [> duck typing なはずなのに document 書かんと使い方伝えられないし 「duck typi..]

_ kosaki [> # 実は大して興味ないはずのこの話題に、どうしてぼくは長文をつっこんでいるのだろう…… それがshinh先..]

_ mame [> 「duck typing だから型書かんでいい期待があるのに、結局 document に型書いてるようわーん」 ..]

_ shinh [動的型の話が混じっててすいません。 Python の例は例えば、 filename はエラー報告時に %s に..]


2010-09-15

_ 外資系社員が出没するクールなお店

そういえばこれが面白いと教えてもらた。 なんせカレーもラーメンも無いという。

http://gaishishukatsu.com/archives/3686

僕も実は港区西麻布在住の外資系社員なので、 対抗して9選を考えたかったけど、 そもそも在住期間が短すぎて、リピートした店が9個も無い。

  • キュイボンヌ(カレー): チーズと茄子が入ってる安いカレー。おいしいです
  • ずんどう屋(ラーメン): 和風とんこつおいしいです
  • 赤のれん(ラーメン): とんこつラーメンおいしいです

あと一回しか行ってなかったのでもう一度行ってもいいなぁと思えるものは…

  • 三田製麺所(ラーメン): かつおぶしおいしいです
  • 中国茶房8(中華): なんか安くて多かった。あと卑猥なオブジェがある
  • モティ(インドカレー): 普通においしかったけどもっと安くていいよね…

あと吉野家と天下一品とか…それとかつやとかでなんとか9選に

近所に松屋が欲しいです… あとタイ料理屋を探さないといけないと思う

(00:18)


2010-09-14

_ duck typing

http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1146611996

via http://twitter.com/kmizu/status/24476568147

見てて、あれ、俺 duck typing が嬉しいと思ったことあったっけ… と思った。 なんかやたらと元質問者に同意するんだよね。

  • Ruby では…
    • 真剣に無い気がする。なんかわざわざ interface ぽい class 書いたりしてる気がする…
    • そりゃ inspect とか to_s とか to_str の恩恵は受けてるけど、まぁ interface があってもいいよなー
  • コンパイル時 C++ …
    • これは interface 的なもの作る手段無いから、しょうがなくやってるだけって気がする…
  • OCaml …
    • OO したこと無い

はて…

色々考えた結果、 interface を書かなくていいという type 数節約よりも、 interface のドキュメントとしての価値の方が重く見てるんだろうなぁと思った。 それと同時に、 duck typing は別にメリットとか無くて、 動的型だからしょうがなくやってるだけなんじゃないかと思えてきた。

あと静的型なのに duck typing な OCaml の OO はゴミなんじゃないかとも。 使ったこともないのに失礼なヤツだな…

(23:49)

本日のツッコミ(全9件) [ツッコミを入れる]

Before...

_ yt [うわあああファーストクラスモジュールの間違いです。]

_ mame [AspectJ の declare parents とか。> 後付け]

_  [>必要なメソッドをすべて実装しているか不安になるほど複雑な duck typing を使うものなんですか? ..]

_ mame [ドキュメントやサンプルコードを見ます。]

_ aereal [はじめまして。 >あと疑問に思うんですが、あるダックタイピングをしてるメソッドにオブジェクトを引数として渡す場..]


2010-09-08

_ すたーくらふと

しるばーになった。

だいたい

  • 適当に zealot たくさん出す。押し切れれば stalker 出せるようにしつつ殺す。 terran 相手にはこのステップは飛ばして zealot 適当に出す。
  • 押せなさげか terran ならガス取り始めて cybanetics core とかで適当に warp とか覚える。たぶん gateway は 4 つくらい。
  • 適当に戦ってみる。このへんで勝つのが一番面白いパターンの一つな気がする。
  • 相手が好戦的ならこのへんで勝ってるか負けてる気がするので、たいてい相手は守り気味な感じか。
  • 荒らしにビクつきながら適当に。

って感じにやってる気がする。

負けるパターンとしては

  • すごい最初に殺される。 6,7 pool なり zealot 出し負け/操作負けなり
  • stalker 出始めたあたりの戦闘で負ける。最近はあまり無いパターンな気もするけどうまい人相手ならここで負けたりすると思う
  • ひきこもって何やってるかわからん相手が突然すごいもの出してくる

このあたりか。 6,7 pool はたぶん適切に入口ふさげれば大丈夫なんだと思うんだけど、どうもうまくふさげないことが多いのがダメぽ

序盤と序盤後の戦闘負けはまぁヘタなので納得できる。

ひきこもりっ子はどうすればいいんだろうなぁ。 偵察するしかないと思うんだけど、 しかしどう偵察すればいいのか難しい。 observer で missile turret とか photon cannon を 頑張って避けつつ近付く感じですかね… あと observer とか出してると中盤の戦力増強が ちょっと遅れるので、突然ひきこもりっ子が兵出してきたりしたら恐いなー とか思ってしまうのがまた良くない。

(00:09)


2010-09-01

_ mirah

http://www.mirah.org/

最初 AS みたいな感じなのかなと思ったんだけど、

Java を Ruby syntax ぽくした物体と言うべきっぽい。 つまり速いっぽい。 なんか Ruby のつもりで使うとガッカリ感があるかもだけど、 まぁマクロあるんで Java の冗長な繰り返しはそれで防いでねー的な感じっぽい。

コンセプトはあまりに正しいなーと思った。 Eclipse 無くても Java が書ける時代が。

App Engine とかでもいい感じで動いてるっぽい。 あとは GWT あたりとうまいこと連携してくれると 嬉しいんかなーとかなんとか

しかし別に web アプリとか作りたい用事が無いんだよな。

(03:03)

_ ほえー

http://slashdot.jp/it/article.pl?sid=10/08/31/1148237

とおもった。

あとコメント見てわらった。 「はてなのCTO」で十分じゃないのか…

しかしこれではよしき先生が目立たないdesune

http://www.sodan.org/~penny/blosxom.cgi/2010/08/31#xoogler

(03:14)

_ すたーくらふと

やっとこさ勝ちと負けの数が釣り合ったり。 今6連勝してるらしいのでそろそろ しるばーとかになれたりするとはっぴーかもなんだけど、 昇格条件謎らしいしなー

アカウントはもう一度ロックされたので、 パスポートとかスキャンして送ったら秘密の質問の答えを教えてもらえた。

好みの展開は rush びびりつつ兵出したり photon cannon 置いたりしつつ、 偵察に行った probe が適当にどっかわけわけわからんところに 飛行場作って VoidRay 2,3 台でなんか相手をいちびって、 あとは適当に相手の出方見つつ対空とかしてきそうなら VoidRay でいちびってる間に研究した warpgate で 地上の子をたくさん作って相手の 2nd を妨害しつつ、 こっちも作って…みたいな感じだけど、 なんか VoidRay だけで決まってしまうことも多い。 物足りない気がするけど、まぁ勝率稼ぎという意味では良い気がする

最初の守りかたがむつかしいなぁと思う。 一個目の pylon は近くで、 二個目くらいから入口封鎖に向かう感じがいいのかなぁ。 cannon も入口とミネラルとこに置いとくのがいい気がする

(03:32)

本日のツッコミ(全1件) [ツッコミを入れる]

_ もわ [むしろここ見て知ったよ! < よしーき先生のべんちゃー]


2010-08-30

_ i agree!

http://planetrubyonrails.com/

Lots of requests to publish Tetsu Soh's memory profiler on Github. I agree! #rubykaigi

どっかにコード無いんかなーと探してたらこれを見つけた。

(01:49)

_ しりとりプログラミング

というのを漠然と考えた。新しい語の導入を許すと

puts sh = "Hello, world!"

とかで一瞬で解決して、許さないとすぐに無理ゲー感がただよってくる。

ていうか hello だけなら

"Hello, world!
".display

とかでたまたま解決したりするし、ゲームとして色々成立しない。

改行を出すのにムダに苦労してみるとか…

"Hello, world!".display
yield Dir rescue eval "loop { puts ; STDERR; raise exit }"

たぶんルールは

  • "Hello, world!".display ではじまる (つか h で終わる単語がない気がする)
  • NameError とか NoMethodError が飛びそうな場所があるとダメ
  • 新しい名前の導入は禁止
  • eval 以外の文字列ダメ。 eval の中でもしりとりする
  • 外部プロセス呼ぶの禁止
  • 同じ名前は使っちゃだめ
  • なるべく短く

とかか。 eval もなんか取ってつけたような感じだから禁止してもいいかも

"Hello, world!".display
yield Dir rescue END { DATA; ARGF; fail loop { puts; STDERR; raise exit } }
true
__END__

偶然だけど、 END fail raise exit と登場して、 true __END__ でシメててなんかかっこいい。

(02:40)


2010-08-29

_ なごや

続き

  • F# とか、 .Net 系言語はゴルフ場に入れていきたいんだけど簡単かな
  • first class module については話だけでは漠然としたイメージだけしかわからなかったんだけど、後で説明を聞くと D の最初の頃の template みたいなものを思い出す感じなのかなー
    • 実装どうなってるかも見たい
  • camlspotter さん話うまくて面白かった。面白かったなーと思って、しかし考えてみると俺 OCaml のコードとか別に検索したくないよなーと気付いて、うまくだまされた
  • FFTW は僕の印象では SSE のうまい使いかたって気がした。昔 SSE で FFT 書いたら勝てた記憶があるんじゃがーという話をしたら、当時は SSE はまだリリースされてなかったんじゃないかとのこと

その後

  • ネカフェでは何故かウシジマくんを読んで陰鬱な気分になることになってるので読んだ。あとは PSYCO+ は何故か面白いと記憶してたんだけど、読むと面白くなくてびっくりした
  • 味噌煮込みうどん。うどんの麺が固いとかなかなかにヘンな物体だなあと思った。でもおいしかったとおもう
  • 名古屋城…の付近で昼寝
  • 名古屋城…の前で武術大会とかが行なわれていて真剣でなんか切ったりしてた。面白かった
  • 名古屋城。シャチホコの実物が見たかった
  • ふらふらと港に
  • 南極に行った船を見たりとかそういう
  • そこらで夕寝
  • 名古屋でひつまぶし喰おうと思ったら並んでたので矢場とんにフォールバック

(23:57)


2010-08-28

_ 海外旅行

名古屋っぽいもの食いたい。 USB ケーブル無いから GPS 無いのが痛いかな

それはそうといろいろためになったとおもう。なんか忘れそうなんでなにか書いておく。

  • F# は int+float あるん?→無い→これはあると予想して、あるとしたら x+1 から x を int と推論してるのはなんでだろーという疑問だった
  • ins_sort ってリストだと O(N^2)? →そもそも array でも O(N^2) じゃボケ→ぐおおそうだ同じやりとりをほかでもした記憶があるよ…
  • 楽打普通に電卓として便利げ
  • 楽打どうせ Obj. に手を出してるんなら + とか overload してもよさそうな
  • しかしそれをすると電卓としての便利さはなくなる
  • '_a と 'a → 'a は本当になんでもいい。 '_a は一度決まったらそのまま
  • let rec f x = if false then f 1; 2 で x が int になるのが許せない→ f x の定義見てるときは '_a で一旦定義終わって残った '_a は 'a になるんじゃよ
  • πの話を聞いた。昔よりはイメージつかめる気がする
  • 名古屋に何が起きているのか→精力的な人が牽引したのが大きい。組み込みの人の理想と現実みたいななにか
  • なんで OCaml 使ってるん? fun と function とか、 .() と .[] などなどなど… OCaml の文法つらくないすか→意味論とか大事とても大事。文法それほど大事でもないでも意味論だいじ
    • これは C++ とかって const_iterator とかうざくねーといわれたときの自分の反応に近いよなーとか思った。まぁ瑣末なことだと思う
  • overload ほしくないすか→ほしい
  • つか汎用 print は→ほしい。なんか type から generate したりしてる
  • GCaml は→ほしい
  • バックトレース→ある
    • バックトレースフェチとしては今度みる

なんかまだあった気がするけどまぁ

あとは何度も定義読んだであろう Sort モジュールなー


2010-08-27

_ 暗号解読

http://www.amazon.co.jp/%E6%9A%97%E5%8F%B7%E8%A7%A3%E8%AA%AD%E2%80%95%E3%83%AD%E3%82%BC%E3%83%83%E3%82%BF%E3%82%B9%E3%83%88%E3%83%BC%E3%83%B3%E3%81%8B%E3%82%89%E9%87%8F%E5%AD%90%E6%9A%97%E5%8F%B7%E3%81%BE%E3%81%A7-%E3%82%B5%E3%82%A4%E3%83%A2%E3%83%B3-%E3%82%B7%E3%83%B3/dp/4105393022

これを読んだ。面白かった。

- 最初の方の暗号ってその時代に生まれてたら解けたんじゃねと思ってしまうけど解けないんだろうね。なんというか基礎教養的なものってのは案外強いんだよなーたぶん - まだ解けてない宝の地図とかあるのかーロマン - ディフィーさんとヘルマンさん (以下 DH) は別人 - DH より RSA の方が良いようだ…今一つメリットにどうもピンと来ないけど - RSA も DH も発見者は彼らじゃないそうだすげえ

(00:45)

_ ごるふ

http://golf.shinh.org/p.rb?Sort+by+Length+for+OCaml+Golf+Competition

これなんかうちに short coding とか二冊あるから 賞品とかにしたらどうでしょーとか 自分で言っておきながら持ってかえってくるの忘れて 帰省してた。

僕が優勝すればいいのではないか!

(01:07)

_ glibc を初期化したい

MacOSX のバイナリを無理矢理 linux で動かして遊ぼうとしている。 で、なんか、それなりには動くんだけど たいていのプログラムはどっかで crash する感じで、 どうも glibc の初期化ルーチン走ってないのが良くないかぁ という感じのものが多い気がする。 たとえば setlocale とかそういう。

で、 glibc を初期化したいわけだけど、 どうしたらいいかなーというのがあまりいい案がない。

  • Linux の crt1.o を適当にリンクする
  • ただし main は自前のルーチンに置き換え
  • __libc_csu_init とかは必要なんだろうか…必要そうでうざい…
  • main はなんか適当に stack の状態とかを起動状態に戻して entry point に jmp

とかになるのかなーと思うんだけど、 libc の初期化ルーチンを自前でリンクするとかめどい…

なんもしない main を書いて、 それを実行バイナリに落として、 必要な部分を自分の ELF binary にコピってくる… みたいな感じで動くんかなぁ。

リンカじゃなくてローダにすべきだった気がしてきた。

今からやるとするとどっちがラクかなー

(23:54)

本日のツッコミ(全1件) [ツッコミを入れる]

_ isshiki [>暗号解読 ボクも数年前に読みました。感想は今となっては小学生の感想文レベルでしか語れないので控えますが、当時思っ..]


2010-08-26

_ x86-64 の ABI

ややこしいよなぁ…

http://www.x86-64.org/documentation/abi.pdf

これによると struct 返り値は hidden parameter でいいのかなー と思ってたんだけど、 なんか GCC の挙動違うぞ… と思って調べてみたところ、 どうも RAX と RDX に入るならそっち使う、 って感じかなー。

http://agner.org./optimize/calling_conventions.pdf

によるとややこしいなぁ…

(14:29)

_ u-n

http://twitter.com/ssig33/status/22043287159

ホントだと悲しいなあ…

(15:12)


2025年
7月
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
1.shinh(2010-09-16 23:32) 2.mame(2010-09-16 21:21) 3.kosaki(2010-09-16 11:52)
search / home / index

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

shinichiro.hamaji _at_ gmail.com / shinichiro.h