  |
はてなキーワード: オブジェクティブとは
今は別にe-Sportsっていう共通認識なんかなくて、ゲームタイトルが個別にe-Sports謳ってるだけじゃない？
大会も主催者毎に採用タイトルバラバラだし、その中の「FPS」ってジャンルだけでもバトルロイヤルやら
オーバーウォッチのようなオブジェクティブ系やら、チームデスマッチやら、バラバラで共通認識で語れるようなもんじゃなくない？
そういう多様性がゲームの良さであるんだろうし、逆にその多様性を雑に「e-Sports」って括ろうとしてるのが微妙な気がするのよな。
でもさ、なんか一貫性が無いように感じるんだよね。
まず、言語の大半の部分がオブジェクト指向言語っぽいデザインになってるのに、listの要素数を測る手段はlen()って*関数*なのはどうなの?
a = [1, 2, 3] len(a) # 3
俺は、sortとsortedって言う命名からこの挙動をまったく予測できなかった。
a = [1, 3, 2] a.sort() # None a # [1, 2, 3]
sorted([1, 3, 2]) # [1, 2, 3]
しかもsortedにdictを渡すとkeyがlistに変換されてソートされて返ってくる。
コードリーダビリティに関する本を開けば、どの本にだって「良い名前を選択する」ことの重要性が書かれていると思う。
「sort()が破壊的で、sorted()が非破壊的、sorted()にdictを渡すとkeyのlistがソートされて返ってくる」これって良い命名なのかな?
", ".join(['1', '2', '4', '8', '16']) # "1, 2, 4, 8, 16"
しかも、これに対する「文字列リテラル (文字列定数) のメソッドを使うのは*醜すぎる*」という意見に対しての公式の返答が、これってのも凄い。
確かにそうかも知れませんが*文字列リテラルは単なる固定された値に過ぎないというのが答えです。文字列に束縛された名前にメソッドが許されるなら、リテラルに使えないようにする論理的な理由はないでしょう。
The Zen of Pythonで「醜いより美しい方がいい」って言ってましたやん。
そもそもリテラルかどうかに関係なくstrインスタンスにこのメソッドがある事がおかしいと思った。
pythonのmapは関数として実装されている。(まただよ...)
list(map(lambda x: x*x, [1, 2, 3])) # [1, 4, 9]
なんでメソッドにしなかったの? って質問に対して公式がこう答えてる。
主な理由は歴史です。複数の型に対しての総称的な操作で、対象のオブジェクトがメソッドを全く持っていなかった (例えば、タプル) としても働くよう意図したものに関数は使われました。
(中略)
うわー、信じられねぇ…
歴史的経緯があるから一貫性が無いのは仕方ないみたいなこの感じ。
これが設計思想に「醜いより美しい方がいい」を掲げるpythonの実装なんだねぇ…
散々pythonの事を悪く言ったけど、おれ実はpythonくんの良い所もいっぱい知ってるんだ。
pythonくんの良い所:
The Zen of PythonにPythonの設計思想が色々書いてある。
「醜いより美しいほうがいい」という指針があることはさっき紹介した通りだ。
でもThe Zen of Pythonには「Although practicality beats purity.(実用性を求めると純粋さが失われることがある。)」とも書いてある。
pythonはこの設計思想を他の言語には無い高いレベルで体現してるとは思う。
pythonは、
無節操に色々取り入れた上で、「tupleからメソッドはやせないから、mapは関数にする」とか、メチャクチャな方法でそれらを統合した言語だ。
だが、そういう言語だからこそ、pythonで書いたコードを育てていく中で様々なパラダイムへとシームレスに変化させていく事ができる。
そういう「不純であるがゆえに柔軟性を持ったプログラミング」言語がpythonだと思う。
rubyの純粋性はすごいよ。イカれたくらい徹底されたオブジェクト指向。
BaseObjectをrootとする継承のツリーの中に世界のすべてが収まっている。
haskellの純粋性も凄い。「代入が無い」プログラミング言語に初めてであった時の衝撃。
でも、そういう純粋性をかなぐり捨てたpythonにはタブーが無い。
ひょっとすると、これはべたべたな一直線の手続き書き時代以来の「全てが一直線に並ぶ気持ちよさ」なのかもなぁ、と思った。
Haskellなんかを書いてると、究極的に、関数型言語におけるプログラムとは、一引数関数の深い深い一直線の入れ子みたいに感じられる。
（いやまぁ、タプルとかもあるけど、原則的に）
構造化⇒OOPと来て、プログラミング言語はGo to hellを廃し、色んな物をDRYに書けるように進化してきたけど、その結果色々なものが並列にばらばらっと並んでいる感じになった。
OOPの大本のsmalltalkはメッセージパッシングの原則の時点で、対等な二つの並列に並んだオブジェクトのやりとりがベースになっている。
勿論オブジェクトは大体内部に別のオブジェクトを抱えていたりして、親子関係があるのは普通だけれど、子同士はやはり並列に順序なく並んでいる。
この並列性のおかげで、例えばそれこそメッセージパッシングをそのまま引き継ぐErlangなんかは、高いスケーラビリティと耐久性を持つわけで、これ自体は素晴らしい発明だ。
ただ、やっぱり並列なヤツラが、ごちゃごちゃっと同時にあって、そいつらが同時にガチャガチャなんかやってたら、神の見えざる手的に、なんとなく全てが上手く噛み合って、プログラムが動きます、って、これどうしても全体像を把握しにくい。
人間の脳みそって、そんな同時並列のものを把握できるようには、出来ていないんだと思う。
上手く動いてはいるんだけど、何で上手く行ってるのか分かるんだけど、分かりにくい。
この気持ち悪さが、今日もどこかのITおじさんを全部staticな書き方に走らせ、OOPわかんねー、と首をかしげながら、何となく使ってる人達の心を、巨大なメソッド作りに導いているのではないかな、と。
なんてったって、Scalaなら並列処理でさえ、モナドなFutureで事実上直線に繋いでいってかいちゃう（Akkaもあるけどあれはオブジェクティブな側面なので）わけで、これは凄く懐かし気持ちいいと思う。
かくして関数型言語は「なんかとにかくきもちいいぃぃぃぃ」な信者を量産している。そしてOOP派との間に、意味分からん溝だけが広がっていく。
お腹の弱いネットワーカーのここ数年をただの好奇心から追いかけてみて、
なんか今すごい泣きそうになっている。
//
大学在学中（？）に地方には当時まだ珍しかった新興クーポンビジネスのブログ担当をまかされ、
クーポン会社を辞めて親父の会社を手伝いながら地元の活性化を志し、
UstやTweetcastなど勃興した駄々漏れ動画サービスを活用し、
（mixi経由の？）地方の社会人サークルビジネスにも顔を出し、
秋になるとネット中毒者としてYahoo知恵袋ウォッチなんかもたしなみ
//
華麗にニコ生顔出しデビューを果たし、新しい職場で働くも体調を崩し、
ニートを経験し、一時はニコ生コミュニティを売り払おうとさえし。
そして
はてなブログで見事にキャッチーな文芸アフィリエイターとして開花した！
と思ったら即座に蹴落とされ。
もともとクーポンに関わってたくらいだからニュービジネス的な才はあったんだろうし、馴染み深かったんだろう。
2010年のはてブの最初1発目がいきなりエガちゃん記事肯定だしね。
いろいろあったんだろうな、考えたんだろうな、と邪推してみたりして、
彼女はこのクソみたいなネットにふさわしいネットあまちゃんだ！
いや便利ネットおもちゃに囲まれてこの東京で人生くすぶってる私達の鏡だ！
とか思い込んだりして。
本当に幸せな結婚生活を送っててほしい。幸せになってほしい。心から。
いつだって。
