LWのサイゼリヤ

ミラノ風ドリア300円

6/22 フレームアームズガール総括

・お題箱16

26.pythonの勉強は何から始めましたか? 書籍名やurlなどのオススメ教えて欲しいです。

pythonの勉強に使ったのは


これ一冊です。

よって、一番目の質問への回答はこれですが、オススメかどうかというのは難しいところです。
僕は適当な言語を5個くらい浅くやっただけなのであまり偉そうなことは言えないのですが、技術としてのプログラミング言語は料理や読書とは違って「最初はこれ」「次はこれ」というような一定の学習ステップを踏まないところがあって、簡単には答えられないという話をします。

まず、僕の見たところ、プログラミング言語は「共通事項」+「言語特有の事項」という二点で出来ています。

「共通事項」というのは、どのプログラミング言語でもほとんど同じ部分のことです。
具体的には、「変数」「フロー制御」「関数」とかですね。この辺の概念はどの言語にも存在し、せいぜい細かい書き方が違うだけで、内容は言語によらず全く同一です(オタクに釘を刺しておきますが、変な例外を挙げないでくださいね)。一度何かしらの言語を学習すれば常に30分くらいで読み飛ばすことができますが、初学者にとっては理解に時間のかかる部分でもあります。「a=a+1」「initialize()」のような妙な表記をはじめ、プログラミングをしていなければ触れることのない独特の考え方が詰まっているので、経験がない場合はゼロを発明するインド人(←一度理解すれば簡単だけど、その理解を一度するのが難しいものの喩えです)のように一つ一つ学んでいく必要があるでしょう。

もちろん言語によって違う部分もあって、それが「言語特有の事項」と書いた部分です。例えば、<ここにオブジェクト指向のような具体的な例をいくつか挙げようとしたのですが、あまり知識が無いのでできませんでした>。
言語の仕様だけではなく、ライブラリやコード処理の方式など、外付け的な部分もここに入ってきます。この辺はその言語に独特の部分ですから、他の言語を知っていても改めてちゃんと学ぶ必要があります。

要するに、初学者か経験者かによってプログラミング言語の勉強の意味合い自体が変わってきて、初学者であれば主に共通事項、経験者であればpython特有の事項を知りたいことになると思います。
冒頭に挙げた本は前者の内容が多いです。ノンプラグラマー向けの本であるため、一から始める人のために「コーディングをミスってもパソコンは壊れないから恐れずにいこう」みたいなことが丁寧に丁寧に書いてあります。初心者向けなので意図的に省略している部分も多く、細かい仕様には触れていません。とりあえず動けばOKみたいな感じです。

しかし、それでも僕がこの本を買ったのは、目的意識が明確な点を評価したからです。
目的意識というのは、経験者と初学者というよりは、職業プログラマーと非プログラマーで分かれてくる話題です。
職業プログラマーの場合は、仕様を受け取るか作るかして遂行するための道具というのがプログラミングの存在意義です。つまりプログラミングにとっての外部的な目的が常に存在するのですが、非プログラマーはそうではありません。個人がプログラムを組まねばならない目的などそうそう発生せず、プログラミングはしてもよいし、しなくてもよいのです(僕は職業プログラマーではないので質問者がpythonを使うプログラマーだったらお手上げなんですけど、もしそうならこんなところで僕に聞くわけがないですね)。

そんな非プログラマーにとって、学んだプログラミング言語を「実際に」何に使えるのかを示している本というのはけっこう貴重です。
「実際に」というのが非常に重要なポイントで、大抵の本は「パッと見何かに使えそうだけど、よく考えたら実際に使うことはまず無い」で終わっていることが多いです。

代表的なのはデータベースですね。
だいたいの初心者向けの入門書には「住所録を作ってみよう」みたいな項目があって、「田中 東京都 渋谷区 03-XXXX-XXXX」みたいなデータを格納して取り出す練習をさせられます。これで住所のデータベースを作れるようになりました、はい良かったねとか言ってるわけです。
ちょっと考えれば、何も良くないことがわかります。Excelを使えばいいからです。見にくい使いにくいオナニーソフトではなく、既にプロが作ったものを使うべきです。

プログラマーでもないのにプログラミング本を読んでいる非プログラマーが全面的に悪いとはいえ、非プログラマーがプログラミングの勉強をすると、実際のところ何に使えるのかがよくわからないという問題はかなりの頻度で生じます。料理本を買ったら深海生物の調理方法ばっかり書いてあって、内容はわかったけどこれはいつどこで使うの?みたいな。

その点、冒頭の本は個人利用の範囲でも有益な情報をかき集めてあり、実際に使えるのが非プログラマーにも嬉しいところです。
Webスクレイピング(自動でWebぺージを歩き回る)、画像操作、マウス・キーボード制御あたりは特にいいですね。データベースのようにざっくり汎用的なものが要求されるプログラムではなく、個人的な閲覧や動作に特化したプログラムが作れるので非プログラマーの利用可能性がかなり高いです。

総合して、非プログラマーにはオススメ(プログラミング初学者だと更にコスパがよい)という感じです。
オススメのものを提示するというよりは冒頭の本がどういう人にオススメかを解説する感じになったんですが、最初に書いた通り他のpythonコンテンツには一切触れていないので、この本の対象層でなければ別の場所を当たってください。

27.アイスの爽見て思ったんですけど日常会話だと"そう"ってよく使うのに漫画やラノベだとクール系キャラのそう・・(理解)やそういえば(話題切り替えが稀にある程度で使用機会すくない気がします。なんでなんですかね。

確かにそうですね。情報量が少ないからですかね?
「そう」って、「特に何も感情は動かないし動作もしないけど概ね肯定寄りで理解はした」くらいの反応ですよね。多分人間が何かに応じるうちで最もフラットな反応なので、反応に当たる部分に特に何も書かれていない場合は自動的に「そう」が補われると思います。
物語は劇的でなければならないので、ミクロには省略しても伝わるし、マクロには何ももたらさないものに割くスペースは無いんでしょう(知らんけど)。

ちなみに、爽はアイスにしては珍しくあまり好きじゃないです。シャーベットが邪魔なので普通に中身を詰めてほしいです。

フレームアームズガール完結

db975677[1]
サクラクエストは六話くらいから溜まってて、ひなこのーとエンドカードだけ見てたから、今期全部ちゃんと見たアニメはフレームアームズガールだけだった。
マテリア姉妹、特別好きじゃないと自分では思ってるんだけど、ブログへの登場頻度が明らかに高い(というかマテリア姉妹については延々話すのに他のFAガールについて喋った記憶があんまりない)から実はかなり好きなのかもしれない。

・旅立ちエンド、匿名者との関係

Bパートラストでフレームアームズガールたちが旅立っていくのはかなり良かった。
広義のBTTFエンドなんだけど、回収されないのが展開じゃなくて関係性であるというのが独特で、キャラものへのBTTFエンドの応用としてその手があったかと思ってちょっと感動してしまった。

補足40:BTTFエンドとは、「物語の最終盤(残り数秒~数十秒)で新たな展開が発生してそれを回収せずに終わる」ラストシーンのこと。いわゆる「投げっぱなし」ではあるが、単なる伏線未回収とは異なり、尺的に絶対に回収できないしする気もないことが明らかなものを指す。最近では遊戯王ZEXALが該当。
BTTFは「バックトゥザフューチャー」の略で(以降ネタバレ含)、全てが大団円になったあとにドクが「大変だ」とか言いながら駆け込んできて主人公と一緒に車に乗って走り出したところで映画が終わるというラストシーンが有名なので、これ系の終わり方を俺が勝手にBTTFエンドと呼んでいる(現在ではこのシーンは2への繋ぎということになっているが、1が公開された時点では2の製作は考えられていなかった)。


俺がBTTFエンドを好む理由は世界がいくらでも続く=世界の無限の可能性を示唆してくれるからなんだけど、それと同じで、キャラものにおける関係性に対してBTTF式を採用すると、関係性が閉じない(開いた)ラストシーンが発生してくる。関係性について無限の可能性があるというのを言い換えると、あおという具体的な登場人物との関係を確定した轟雷と違って、轟雷以外のガールズは本編に登場していない匿名の誰かとの関係が確定している(ことが仄めかされている)。
フレームアームズガールたちがマスターを探しに去っていくシーンで頭の中でなんかオリキャラを作ってそいつがマスターになる未来を漠然と想像した人がいるとしたら、そのオリキャラこそが無限の可能性で、いつか関係を確定する匿名の誰かのこと。

迅雷たちが「本当のマスターは他にいる」みたいなことを言いながら去っていくのはなんか薄情な感じもしたけど、

轟雷-----あお

の関係と同じくらい明確に

スティレット-----<匿名A>
バーゼラルド-----<匿名B>


っていう関係を示すためには、あおとは決別しないといけなかった。
しかも適当に旅立つだけだと何が目的なのかよくわかんなくなる(匿名者を名指しするというのは原理的に不可能であり、他の構造から類推させるしかないため)から、轟雷⇔あお間の関係が直接的な旅立ちのモチベーションになるっていう描写も絶対に必要なはず。結婚シーンでおほ^~と思いながらも見事な構造に唸ってしまった。

・中盤以降のキャラの回し方

序盤のコメディは神がかってたけど、中盤からはちょっと微妙だった。
キャラが増えてきたのに応じて「全員に平等に見せ場を渡さなければいけない」みたいな義務感が足を引っ張っていたような気がする。

特に鍋回と出し物回で顕著で、鍋回冒頭で全員に均等に言動を割り振ったパートが個人的にはワースト。全員に出番を回そうとした結果「轟雷はおでんが好き」「迅雷は柳川鍋が好き」みたいな情報の羅列に終わってしまって、設定資料集を読んでいるような印象を受けた。
反面、肝試し回はアーキテクト登場以降で一番面白かった。轟雷は先導するけどスティレットはビビり、迅雷とアーキテクトは手を繋いで他は悪戯に回るっていう風に全体を通してキャラクターが全然違う行動を取っていて、見ていて飽きなかった。

この辺の漠然とした「コメディのうまさ」は、

1.関係性への踏み込み
2.範列関係と連辞関係

みたいな話に帰着されてくると思う。
関係性への踏み込みは多分前にもどっかで話したから簡単に済ませるけど、キャラクター同士より関係性の方が数学的に豊富なので積極的に利用してほしいということ。

範列関係と連辞関係については、しばらく講義をしないといけない。

すごく雑に言うと、
無題
というように複数の文章を並べて解体したとき、縦の繋がりを範列関係、横の繋がりを連辞関係と呼ぶ(縦棒がズレるのでわざわざ画像を作った)。

補足41:普通は逆で、範列を横関係、連辞を縦関係と表現する。
というのは、日本語は縦書き文化だから一般に「縦」という概念を直列概念、「横」という概念を並列概念に対応させるんだけど、ブログは横書きなので逆になってしまった。


補足42:横文字では、範列関係はパラディグム、連辞関係はサンタグムと言う。カッケエ……

範列関係は文中で等価な関係、入れ替えても文章が問題なく成り立つパーツ群のことだと思えばいい。
例えば、上の文章では縦に繋がる[轟雷]と[迅雷]は範列関係にある。だから[轟雷]を[迅雷]に変えても文章は成り立つし、[迅雷]を[轟雷]に変えても同じだ。上の文章に限らず、あらゆる文章で[轟雷]と[迅雷]は入れ替え可能である(内容はともかく、日本語としては)。範列関係にあるパーツのうち、適切なものを挿入して文章を作っていると言ってもいい。

一方、連辞関係はパーツの形式的な繋がりを指す。
例えば、[轟雷]-[は]-[おでん]-[が]-[好き]の順番を入れ替えて[好き]-[おでん]-[は]-[が]-[轟雷]とすると全く意味が通じなくなってしまう。範列関係から抜き出してきたパーツたちは、適切な順番で組み合わせる指針を与えなければ文章として成立しない。その「適切な順番」のことを、連辞関係と呼ぶ。
「適当なパーツ=範列関係」と「適当な順番=連辞関係」という二つの指針によって、日本語の文章は構成されているわけだ。

さて、鍋回でのそれぞれの行動を文章に表してみると、上にも書いた通り

轟雷パート:[轟雷]-[は]-[おでん]-[が]-[好き]
迅雷パート:[迅雷]-[は]-[柳川鍋]-[が]-[好き]

となる。このとき、二つの文章の違いは、主語の他は[おでん]⇔[柳川鍋]という単純な名詞の入れ替えに留まっている。[好き]という述定部分は一致しているし、全体として同じ連辞関係を持っていることがわかる。また、この文章は好みについての文章なのでこれ以上補足するところもなく、これ以外の文章にはあまり発展しない。

一方、肝試し回での行動は、

轟雷パート:[轟雷]-[は]-[スティレット]-[を]-[落ち着かせる]
迅雷パート:[迅雷]-[は]-[アーキテクト]-[と]-[手]-[を]-[繋ぐ]

となり、先程と比べて違いが大きい。
[スティレット][アーキテクト]の部分までは可換だが、それ以降の述定部分は構造が異なるために単純な入れ替えが不能になっており、それぞれがかなり違う行動を取っていることがわかる。[スティレット]の部分を[お化け]-[を]-[怖がる]-[スティレット]として補足説明を足していくことも可能で、それぞれの文章の差異を更に広げることも難しくない。

結局は「キャラクターがコメディするとき、その行動は豊富な方が面白い」というだけの話なんだけど、その「豊富さ」をもう少し明確に表そうとしたとき、つまらないシーンでは行動の差異が範列関係のレベルに留まる一方、面白いシーンでは差異が連辞関係まで拡張されると言えるかもしれない。