  |
はてなキーワード:トレランスとは
うーむ
「寛容」の恐怖 ロシア政府が資金提供したプロパガンダ映画は、今夏、公開初週末に192枚のチケットを売り上げた。この映画は、ヨーロッパを自由主義的価値観の悪夢として描いている。 — Meduza
アンドレイ・グラチェフが長年を費やしてこの傑作と称される作品を作り上げたにもかかわらず、『トレランス』は事実上、宣伝活動もほとんど行われないままプレミア上映された。配給会社のシネマウス・スタジオでさえ、YouTubeチャンネルで予告編を公開しなかったことは、皮肉なことだ。グラチェフは、わずか83人の登録者数を持つ自身の個人アカウントで予告編を公開せざるを得なかった。ザハール・プリレピンでさえ、自身のTelegramチャンネルでこの映画について何も語っていない。
リベラルをセルフアイデンティファイする人たちが、ノンリベラルなインディビジュアルをバカにすることがあるけど、そのアティチュードにはちょっとカルチャーショックを受ける。
リベラルって、本来はトレランス、エンゲージメント、そしてミューチュアルリスペクトを基盤にしたバリューセットじゃないのか？
でも、オルタナティブなビリーフを持つ人を「イグノラント」とか「ナイーブ」とか言って、まるでセルフアサートがアブソリュートに正しいみたいにジャッジしてくるのは、どうもアンフェアに感じる。
セルフビリーフが正しいとコンビクションするのはフリーダムだけど、他者をディスることでセルフバリデーションを図るのは、リベラルのコアバリューとディスコネクトしている気がするんだよな。
Permalink |記事への反応(12) | 17:43
ダテコーの事をよく知らない人や見下したい人ばかり寄ってたかってると感じる。
ダテコーは、ネトゲでいう、「ちょっとLVも装備も足りてないけど変わった攻略法を試したいから付き合ってくれる人募集！」ってシャウトしてるPTリーダーみたいな人だと思う。ネットで叩いてる人は、その「ゆるい募集」を見ずに入ってきて、自分では絶対にPTを立てないけれど、入ったらリーダーの指揮とかメンバーの振る舞いの至らなさに悪態をつく、他人への要求が高すぎる人と被って見える。ダテコーがやっていることは、メジャーで洗練されたビジネスライクな効率PTとは違う性質のもの。仮にてさぐれ部活もの以上の大ヒットを当てたとしても、ひねくれ者のダテコーは大手制作会社のような作品は作らない気がする。自分の信じる「ゆるさ」や「面白さ」を表現するために、永遠にチープでマイナーなもの、悪く言うとキャスト・スタッフや視聴者の好意に甘えた、アットホーム感のある作風にこだわりそうだと私は感じる。そして、そういうスケールアップをあえてしない道は、茨の道だけれどもアリだと思っている。
ダテコーはバウンスィという制作会社を経営してるけど、アニメ業界の人はほぼいない。カネがなく(資本金350万だよ)、テレビ業界とコネがあり、メンバーは構成作家や演出家、音響技術者くらいの10人少々。アマチュアレベルのMMDに手を加えた3Dモデルを動かす人形劇アニメにもかかわらず、大手アニメと肩をならべて放送枠をとっている零細ベンチャーみたいなもの。だから大手制作会社と同様の条件でやろうというのは無理ながらも、キャストを含め作風に共感してくれるスタッフの好意と熱意に支えられて、もがいているチャレンジャーという立ち位置。しかも彼はツイートしてるように、キャストに約束した給料は不払いせずきちんと払ってるし(あくまで大手制作会社とくらべて安いから申し訳なく思ってるって事だろう)、自身は会社設立以来1年間無報酬でやっていて、貯金もほぼないそうだ。局で作家をしていたころは一般サラリーマンの3倍ほど貰っていたらしいが、テレビ局の構成作家は3000万稼いで一人前という世界から身を引いた方なので、ベンツを乗り回してみたいなネットの噂で僻んでも仕方がない。ともかく、稼いでいるのに金払いをケチる悪い人間、という風評は悪意的だと思う。
彼を追ってきた人なら分かると思うけれど、実際はクソ真面目で、言われてるような声優アドリブ芸や内輪ネタに頼りすぎた作風を良しとせず、脚本や音響などスタッフ達がきちんと仕上げて編集する作品作りにこだわっている人。だからこそ、現場がそういうディレクションを軽視して「やっぱ声優さんすげーわ任せるわ」ってなるたびに怒って監督をやめている。職分を超えて、声優の負担を増えさせる不健全な状況には敏感な人だ。実際BDのノーカット版などをみた人ならば、編集はじめクリエーターたちのすごさが伝わっていると思うし、最終回の作り方などには、彼の美学を感じさせられる。
あのツイッター発言についても、本意と違う悪意的な捉え方ばかりされていると思う。本意としては、自虐的ながらも、「ウチは普通のとこと違うし当然売れないもんだから、普通のビジネス感覚でやってくる人とはお互い良くない、俺たちはファミリーが欲しかったんだけど残念だ」くらいのことだと思う。私は別に条件が合わなかった相手をdisる意図はないと感じたし、その条件が合わなかった人のことを指して「技量がない」と言っているようには思えなかった。このへんはネットで西野さんが炎上してた時にも私は思ったんだけど、みんな悪意的に捉えすぎている。「ダセー」だとか「お金の奴隷」は西野さん自身に向けられた言葉だし、自分がお金にこだわって可能性を閉ざすやり方を一部改めたからといって、お金(対価)を大切にする普通の人たちを貶す意図は感じなかった。むしろ、西野さんにも石舘さんにも、普通の人達に対して理解を示す言葉があった。それすらも乗り越えて、それを用意周到な言い訳とみなし、煽られたように捉えてしまいカチンとくる自意識過剰な人が多すぎるように思う。自分の労働ぶりを自虐的に捉えている人がそれだけ多いのかもしれない。
ともかく叩いてる人らは彼を典型的なアニメ業界の監督だと思って、「こういう奴がいるから業界は…」と感じているようだけれど、ここまで語ってきた文脈を捉えてもらえれば、ピントがずれていることが分かると思う。業界の薄給問題でほんとに叩くべきなのは大手制作会社で、彼のようにテレビ業界とのコネとアイデアで飛び込んだベンチャー社長みたいな人を叩いてたら、余計に業界は健全化しないと思う。カネはないけどツテとキャストやスタッフの好意に上手に甘えつつ、アニメ業界に切り込んで新しいカタチを提案していく、そういう立ち振舞は資本力のある大手には許されないけど、ベンチャーとしては参入が許容されてしかるべきだ。そういう遊びを許容しないと、市場に新しい風は生まれない。もちろん、労働法の範囲内でだけど。そこは実際にはおそらく問題ないのに、彼が自虐的な言い方をしすぎるせいで、問題のある労働が行われていると勘違いさせている。新しい風と言ったけど、低予算のMMDアニメだとか、リアルタイム3D人形劇の先鞭をつけたのはダテコーだし、実際人を選ぶけどファンはついてるわけだよ。キャストだって、弱小ゆえの至らなさやダサさをネタにして監督をイジる事は多々あれど、ツンデレというか作品も監督も基本愛しているように思う。そういう文脈を捉えてない人や、一般企業で安くこき使われてる人たちの怒りが、ダテコーというアニメ業界を代弁できないイレギュラーな存在に矛先を向けてしまった。本来アニメ業界の大企業のおエライさん方に向けるべき正論を、辺境の霧の中にぶちこんで無駄にしている感じがする。ダテコーの言うことは、クリエイティブの、しかも不安定なベンチャー分野で通用する、熱意の方向性に関する局所的な話なのに、クリエイティブ業に携わることも、ベンチャーにジョインする人脈や熱量とも無縁な性質の勤め人たちから、「一般常識」で殴られている感じが、見ていて本当につらい。
堀江貴文さんなどもそうだけれど、内面がクソ真面目すぎるせいで強い思想をもち、世間から見ると変わったことをやっていて、世の「普通」に一切媚びない人種の方々は、無頓着だからすぐに炎上してしまう。何に無頓着かって、自身のやってきた文脈を一切とらえずに一般論に基づく感情で殴りかかってくる人たちに「誤解」されないための言葉選びや長ったらしい自己説明をまったくしない辺り。そういう異能たちが、出る杭だと叩かれてノーマライズされる方向に圧力が掛かるのは悲しいことだ。
それはさておき、私はダテコーのような新興の弱い買い手が、背伸びをせず等身大の報酬しか出せないけども、その弱さを隠蔽せず、詐称せず、そして契約を強要せずにいる姿勢はとても誠実だし、ホワイトだと思う。「ウチは小さいから相場ほど報酬あげられないけど本当にいいの？考え方に賛同してくれるとかじゃないとやってけないよ？」と正直に言った結果、断られ続ける。それは愚痴りたくもなるけど、むしろ倫理的には賞賛されるものだと思う。取引は双方の合意があって成立する。そのことを売り手(被雇用者)に常に自覚させ、選択権を与え、冷静に賢い判断をしてもらうことは重要なこと。売り手側が考えるまでもなく、お利口な買い条件しか提示しない、良い所しか見せない企業ばかりだと、判断能力が育たなくて恐ろしいし、画一的でいびつ、非現実的だと思う。経済的に未熟な企業から、成熟した企業まで、さまざまあっていい。経済的に未熟な企業はどうしても無い袖は振れない、これを理解せずに「相場を払えないなら経営するな」という人ばかりだと、誰もPTリーダーをやらなくなる、もとい起業しなくなる。もう少し、柔軟性があってもいいはずなんだ。「ボッタクリでも時と場合によっては買うぜ」って人が稀にいるのと同様、「多少安売りしてでもこの会社この人とならコラボレートしたい」という希少な人の存在を、「賃金」のポリコレ棒で生まれる前に消滅させてしまってはいけないと思う。最低賃金だとかダンピング防止みたいな例外はあるものの、基本的には、どんな値段をつけるのも自由であるべきで、そっちの基本部分の方を甘く見ている人が多いように感じる。ボッタクリにも理由があり、存在価値がある。だから絶対悪ではない。自分が買い手の場合にそういう考え方ができるのなら、自分が売り手(被雇用)側になったときに同じ考え方ができていいはずだ。自由状態でこそ市場は成長するし、人間としても取引に多くを学び、成長していくんだと思う。市場の失敗が起こるとしたら、大体は倫理にもとる行い、ズルをしている場合。産地を偽ってボッタクリ価格を正当化している、とかね。そういう訳でもなければ、一方的にすべての企業に「十分な(平均並の)支払い」を求めるのは、経済理解に暗いがゆえに計画経済的な発想になっている人なのかなと思わせる。イラストレーターの買い叩きとかクラウドワークス的なのが批判される時、企業にもっと払えと言う人がその無理筋ぶりに無自覚なのと同じで。
話を戻すと、彼を叩いている人たちは、経済的に未熟な企業を許さないんではなくて、ダテコー側が倫理的に未熟な企業だと思いこんで叩いているようだ。もちろん倫理的に未熟な企業ということなら、市場の失敗をもたらすから零細でも大企業でも許容されるものではない。ただ、その判断をするのはネットの野次馬ではなく、労基署とか公的機関だけれどね。今回のダテコーの件の場合、ダテコーの側は経済的には未熟な企業だけども、倫理的には叩かれるほどの問題はないと思う。若い零細クリエリティブ企業としてはむしろ身分相応で卑屈すぎるくらいで。これがワタミのような余裕のある大企業で、そのくせ相手に判断させる余裕も与えず洗脳に近いことをして雇用するのだったら大問題となって然りだけれど。
あと、叩いている人たちに感じた疑問がもう一つあって。そもそも、一企業が、従業員を養う責任を負うのが当たり前のように思われているけど、重すぎると思う。そういう考え方をしていると、日本の労働環境はいつまでたっても全体的にブラックなままだと思う。企業はおのおのの身の丈にあった、妥当な配分を労働者に与えればいい。それで足りない場合、国が負担する。それはナントカ手当だったり、ベーシックインカムだったりしてもいいけど。そういう考えが前提になってほしい。経営者だって人間だし、完璧ではないし不安定な存在だ。会社が小さいうちは、自分の人生ですら支えられるか分からない。経営者も若い事が多いし。だからもっと柔軟に、雇用区分だとか時間を変えてワークシェアを進め、流動性を高めて、一企業に人生を預けるようなとんでもない常識を変えていかないといけないと思う。労働をフォールトトレランスな分散型に。
他人に求めすぎる悪態ネトゲプレイヤーがPTにありつけなくなる問題の解決策は、PTリーダーに対する期待値を下げること、あるいは気楽にPTを立てれる空気をつくることだ。そういう考え方が出来る人が少しでも増えて欲しいと思う。人生はしょせん、すべてがごっこ遊びで、全ての人がなんらかのロールを演じているにすぎない。お仕事も、特に日本人のお仕事は、お仕事ごっこだ。そんなに崇高に考えて、他人に崇高さを求めてもどだい無理なんだ。もちろん、実際に崇高度が高くて「強い」企業の横暴には敏感になって良いけれど、相手の顔が見えないネットだからこそ、相手ももしかしたら弱い人間なのかも、と想像することはとても大事なことだと思う。慈しみを。神のご加護を。
もし、これが増田だから本人乙とか関係者乙と穿った見方をする人がいたとしたら不本意なので、一応自己紹介すると、私は中部地方に住む32歳職歴なしのニート(家事手伝い)です。
目覚まし時計の電池が切れていて設定時間にアラームが鳴らず冷や汗を書くことがなんどかあり、まじで心臓に悪いので冗長化した。
・目覚まし時計①のアラームを起きたい時間の10分前にセット。目覚めの暖機運転。
②と③は最後の警告としてのアラームなので、これがなったら「絶対に」起きる。
また、②と③のアラームの設定時刻は下手にずらさず同じにしておく。
ずらしてしまうと後になる方を信用して二度寝する可能性があるため。
仮に片方が鳴らなくても可用性を維持できる。
追記:
ブコメ見た。乾電池で動くタイプの時計以外にスマホのアラームもまぜておくと安心度が増しそう。
あと、怖いなと思うのが全て電波時計タイプで統一してしまうこと。事例あるのか知らないけど電波障害かなにかで一斉にずれたらと思うと・・・
第1章プログラミング概念入門1.1計算器1.2変数1.3関数1.4リスト1.5リストについての関数1.6プログラムの正しさ1.7計算量1.8 遅延計算1.9 高階プログラミング1.10 並列性1.11データフロー1.12 明示的状態1.13オブジェクト1.14クラス1.15 非決定性と時間1.16原子性1.17 ここからどこへ行くのか？1.18 練習問題第1部 一般的計算モデル第2章 宣言的計算モデル2.1実用的プログラミング言語の定義2.1.1言語の構文2.1.2言語の意味2.2 単一代入格納域2.2.1 宣言的変数2.2.2 値格納域2.2.3 値生成2.2.4変数識別子2.2.5 識別子を使う値生成2.2.6 部分値2.2.7変数の，変数への束縛2.2.8データフロー変数2.3 核言語2.3.1 構文2.3.2 値と型2.3.3 基本型2.3.4レコードと手続き2.3.5 基本操作2.4 核言語の意味2.4.1 基本概念2.4.2抽象マシン2.4.3 待機不能な文2.4.4 待機可能な文2.4.5 基本概念再訪2.5メモリ管理2.5.1 末尾呼び出し最適化2.5.2メモリライフサイクル2.5.3ガーベッジコレクション2.5.4ガーベッジコレクションは魔術ではない2.5.5Mozartのガーベッジコレクタ2.6 核言語から実用的言語へ2.6.1 構文上の便宜2.6.2関数(fun文)2.6.3 対話的インターフェース(declare文)2.7 例外2.7.1 動機と基本概念2.7.2 例外を持つ宣言的モデル2.7.3 親言語の構文2.7.4システム例外2.8 進んだ話題2.8.1関数型プログラミング言語2.8.2 単一化と内含(entailment)2.8.3 動的型付けと静的型付け2.9 練習問題第3章 宣言的プログラミング技法3.1 宣言的とはどういうことか？3.1.1 宣言的プログラムの分類3.1.2仕様記述言語3.1.3 宣言的モデルにおいてコンポーネントを実装すること3.2 反復計算3.2.1 一般的図式3.2.2 数についての反復3.2.3 局所的手続きを使うこと3.2.4 一般的図式から制御抽象へ3.3再帰計算3.3.1スタックの大きさの増加3.3.2 代入ベースの抽象マシン3.3.3再帰計算を反復計算に変換すること3.4再帰を用いるプログラミング3.4.1 型の記法3.4.2リストについてのプログラミング3.4.3 アキュムレータ3.4.4 差分リスト3.4.5キュー3.4.6 木3.4.7 木を描画すること3.4.8構文解析3.5時間効率と空間効率3.5.1 実行時間3.5.2メモリ使用量3.5.3 償却的計算量3.5.4 性能についての考察3.6 高階プログラミング3.6.1 基本操作3.6.2ループ抽象3.6.3ループの言語的支援3.6.4データ駆動技法3.6.5 明示的遅延計算3.6.6カリー化3.7抽象データ型3.7.1 宣言的スタック3.7.2 宣言的辞書3.7.3単語出現頻度アプリケーション3.7.4安全な抽象データ型3.7.5安全な型を備えた宣言的モデル3.7.6安全な宣言的辞書3.7.7資格とセキュリティ3.8 宣言的でない必要物3.8.1ファイルを伴うテキスト入出力3.8.2グラフィカルユーザインタフェースを伴うテキスト入出力3.8.3ファイルとの状態なしデータI/O3.9 小規模プログラム設計3.9.1設計方法3.9.2プログラム設計の例3.9.3ソフトウェアコンポーネント3.9.4スタンドアロンプログラムの例3.10 練習問題第4章 宣言的並列性4.1データ駆動並列モデル4.1.1 基本概念4.1.2スレッドの意味4.1.3 実行列4.1.4 宣言的並列性とは何か？4.2スレッドプログラミングの基本的技法4.2.1スレッドを生成すること4.2.2スレッドとブラウザ4.2.3スレッドを使うデータフロー計算4.2.4スレッドのスケジューリング4.2.5協調的並列性と競合的並列性4.2.6スレッド操作4.3ストリーム4.3.1 基本的生産者／消費者4.3.2 変換器とパイプライン4.3.3資源を管理し，処理能力を改善すること4.3.4ストリームオブジェクト4.3.5ディジタル論理のシミュレーション4.4 宣言的並列モデルを直接使うこと4.4.1 順序決定並列性4.4.2 コルーチン4.4.3 並列的合成4.5 遅延実行4.5.1 要求駆動並列モデル4.5.2 宣言的計算モデル4.5.3 遅延ストリーム4.5.4有界バッファ4.5.5ファイルを遅延的に読み込むこと4.5.6ハミング問題4.5.7 遅延リスト操作4.5.8 永続的キューとアルゴリズム設計4.5.9リスト内包表記4.6 甘いリアルタイムプログラミング4.6.1 基本操作4.6.2 ティッキング(ticking)4.7Haskell言語4.7.1計算モデル4.7.2 遅延計算4.7.3カリー化4.7.4 多態型4.7.5 型クラス4.8 宣言的プログラムの限界と拡張4.8.1効率性4.8.2 モジュラ性4.8.3 非決定性4.8.4現実世界4.8.5 正しいモデルを選ぶこと4.8.6拡張されたモデル4.8.7 異なるモデルを一緒に使うこと4.9 進んだ話題4.9.1 例外を持つ宣言的並列モデル4.9.2 さらに遅延実行について4.9.3 通信チャンネルとしてのデータフロー変数4.9.4 さらに同期について4.9.5データフロー変数の有用性4.10歴史に関する注記4.11 練習問題第5章メッセージ伝達並列性5.1メッセージ伝達並列モデル5.1.1ポート5.1.2ポートの意味5.2ポートオブジェクト5.2.1 NewPortObject抽象5.2.2 例5.2.3ポートオブジェクトに関する議論5.3 簡単なメッセージプロトコル5.3.1RMI(遠隔メソッド起動)5.3.2 非同期RMI5.3.3 コールバックのあるRMI(スレッド使用)5.3.4 コールバックのあるRMI(継続のためのレコード使用)5.3.5 コールバックのあるRMI(継続のための手続き使用)5.3.6エラー報告5.3.7 コールバックのある非同期RMI5.3.8 二重コールバック5.4 並列性のためのプログラム設計5.4.1 並列コンポーネントを使うプログラミング5.4.2設計方法5.4.3 並列性パターンとしての機能的構成要素5.5 リフト制御システム5.5.1 状態遷移図5.5.2 実装5.5.3 リフト制御システムの改良5.6メソッド伝達モデルを直接使用すること5.6.1 1つのスレッドを共有する複数のポートオブジェクト5.6.2ポートを使う並列キュー5.6.3 終点検出を行うスレッド抽象5.6.4 直列依存関係の除去5.7Erlang言語5.7.1計算モデル5.7.2Erlangプログラミング入門5.7.3 receive操作5.8 進んだ話題5.8.1 非決定性並列モデル5.9 練習問題第6章 明示的状態6.1 状態とは何か？6.1.1 暗黙的(宣言的)状態6.1.2 明示的状態6.2 状態とシステム構築6.2.1システムの性質6.2.2コンポーネントベースプログラミング6.2.3オブジェクト指向プログラミング6.3 明示的状態を持つ宣言的モデル6.3.1セル6.3.2セルの意味6.3.3 宣言的プログラミングとの関係6.3.4 共有と同等6.4データ抽象6.4.1データ抽象を組織する8つの方法6.4.2スタックの変種6.4.3多態性6.4.4引数受け渡し6.4.5 取り消し可能資格6.5 状態ありコレクション6.5.1インデックス付きコレクション6.5.2インデックス付きコレクションを選ぶこと6.5.3 その他のコレクション6.6 状態に関する推論6.6.1 不変表明6.6.2 例6.6.3 表明6.6.4証明規則6.6.5 正常終了6.7 大規模プログラムの設計6.7.1設計方法6.7.2階層的システム構造6.7.3保守性6.7.4 将来の発展6.7.5 さらに深く知るために6.8ケーススタディ6.8.1 遷移的閉包6.8.2単語出現頻度(状態あり辞書を使用する)6.8.3乱数を生成すること6.8.4口コミシミュレーション6.9 進んだ話題6.9.1 状態ありプログラミングの限界6.9.2メモリ管理と外部参照6.10 練習問題第7章オブジェクト指向プログラミング7.1継承7.2 完全なデータ抽象としてのクラス7.2.1 例7.2.2 この例の意味7.2.3クラスとオブジェクトを定義すること7.2.4クラスメンバ7.2.5属性を初期化すること7.2.6 第1級メッセージ7.2.7 第1級の属性7.2.8プログラミング技法7.3 漸増的データ抽象としてのクラス7.3.1継承グラフ7.3.2メソッドアクセス制御(静的束縛と動的束縛)7.3.3カプセル化制御7.3.4転嫁と委任7.3.5内省7.4継承を使うプログラミング7.4.1継承の正しい使い方7.4.2 型に従って階層を構成すること7.4.3 汎用クラス7.4.4 多重継承7.4.5 多重継承に関するおおざっぱな指針7.4.6クラス図の目的7.4.7デザインパターン7.5 他の計算モデルとの関係7.5.1オブジェクトベースプログラミングとコンポーネントベースプログラミング7.5.2 高階プログラミング7.5.3関数分解と型分解7.5.4 すべてをオブジェクトにすべきか？7.6オブジェクトシステムを実装すること7.6.1抽象図7.6.2クラスを実装すること7.6.3オブジェクトの実装7.6.4継承の実装7.7Java言語(直列部分)7.7.1計算モデル7.7.2Javaプログラミング入門7.8能動的オブジェクト7.8.1 例7.8.2 NewActive抽象7.8.3 フラウィウス・ヨセフスの問題7.8.4 その他の能動的オブジェクト抽象7.8.5能動的オブジェクトを使うイベントマネージャ7.9 練習問題第8章 状態共有並列性8.1 状態共有並列モデル8.2 並列性を持つプログラミング8.2.1 さまざまな手法の概観8.2.2 状態共有並列モデルを直接使うこと8.2.3原子的アクションを使うプログラミング8.2.4 さらに読むべき本8.3ロック8.3.1 状態あり並列データ抽象を構築すること8.3.2 タプル空間(Linda)8.3.3ロックを実装すること8.4モニタ8.4.1定義8.4.2有界バッファ8.4.3モニタを使うプログラミング8.4.4モニタを実装すること8.4.5モニタの別の意味8.5トランザクション8.5.1 並列性制御8.5.2 簡易トランザクションマネージャ8.5.3セルについてのトランザクション8.5.4セルについてのトランザクションを実装すること8.5.5トランザクションについてさらに8.6Java言語(並列部分)8.6.1ロック8.6.2モニタ8.7 練習問題第9章 関係プログラミング9.1 関係計算モデル9.1.1 choice文とfail文9.1.2 探索木9.1.3カプセル化された9.1.4 Solve関数9.2 別の例9.2.1 数値例9.2.2パズルとnクイーン問題9.3論理型プログラミングとの関係9.3.1論理と論理型プログラミング9.3.2操作的意味と論理的意味9.3.3 非決定性論理型プログラミング9.3.4純粋Prologとの関係9.3.5 他のモデルにおける論理型プログラミング9.4自然言語構文解析9.4.1 簡単な文法9.4.2 この文法に従う構文解析9.4.3構文木を生成すること9.4.4 限定記号を生成すること9.4.5 パーサを走らせること9.4.6 パーサを「逆向きに(backward)」走らせること9.4.7 単一化文法9.5 文法インタプリタ9.5.1 簡単な文法9.5.2 文法のコード化9.5.3 文法インタプリタを走らせること9.5.4 文法インタプリタを実装すること9.6データベース9.6.1 関係を定義すること9.6.2 関係を使って計算すること9.6.3 関係を実装すること9.7Prolog言語9.7.1計算モデル9.7.2Prologプログラミング入門9.7.3Prologプログラムを関係プログラムに翻訳すること9.8 練習問題第2部 特殊化された計算モデル第10章グラフィカルユーザインタフェースプログラミング10.1 宣言的／手続き的方法10.2 宣言的／手続き的方法を使うこと10.2.1 基本的ユーザインタフェースの要素10.2.2GUIを構築すること10.2.3 宣言的座標10.2.4リサイズ時の宣言的振る舞い10.2.5ウィジェットの動的振る舞い10.3 対話的学習ツールPrototyper10.4ケーススタディ10.4.1 簡単なプログレスモニタ10.4.2 簡単なカレンダウィジェット10.4.3ユーザインタフェースの動的生成10.4.4 状況順応時計10.5GUIツールを実装すること10.6 練習問題第11章 分散プログラミング11.1 分散システムの分類11.2 分散モデル11.3 宣言的データの分散11.3.1オープン分散と大域的ネーミング11.3.2 宣言的データを共有すること11.3.3チケット配布11.3.4ストリーム通信11.4 状態の分散11.4.1 単純状態共有11.4.2 分散字句的スコープ11.5ネットワークアウェアネス11.6 共通分散プログラミングパターン11.6.1 静的オブジェクトとモバイルオブジェクト11.6.2 非同期的オブジェクトとデータフロー11.6.3サーバ11.6.4クローズド分散11.7 分散プロトコル11.7.1言語実体11.7.2モバイル状態プロトコル11.7.3 分散束縛プロトコル11.7.4メモリ管理11.8 部分的失敗11.8.1 失敗モデル11.8.2 失敗処理の簡単な場合11.8.3 回復可能サーバ11.8.4アクティブフォールトトレランス11.9セキュリティ11.10アプリケーションを構築すること11.10.1 まずは集中，後に分散11.10.2 部分的失敗に対処すること11.10.3 分散コンポーネント11.11 練習問題第12章 制約プログラミング12.1 伝播・探索法12.1.1 基本的考え方12.1.2 部分情報を使って計算すること12.1.3 例12.1.4 この例を実行すること12.1.5 まとめ12.2プログラミング技法12.2.1 覆面算12.2.2回文積再訪12.3 制約ベース計算モデル12.3.1 基本的制約と伝播子12.3.2計算空間の探索をプログラムすること12.4計算空間を定義し，使うこと12.4.1深さ優先探索エンジン12.4.2検索エンジンの実行例12.4.3計算空間の生成12.4.4空間の実行12.4.5 制約の登録12.4.6 並列的伝播12.4.7 分配(探索準備)12.4.8空間の状態12.4.9空間のクローン12.4.10選択肢を先に任せること12.4.11空間をマージすること12.4.12空間失敗12.4.13空間に計算を注入すること12.5 関係計算モデルを実装すること12.5.1 choice文12.5.2 Solve関数12.6 練習問題第3部意味第13章言語意味13.1 一般的計算モデル13.1.1 格納域13.1.2 単一代入(制約)格納域13.1.3抽象構文13.1.4構造的規則13.1.5 直列実行と並列実行13.1.6抽象マシンの意味との比較13.1.7変数導入13.1.8 同等性の強制(tell)13.1.9 条件文(ask)13.1.10名前13.1.11手続き抽象13.1.12 明示的状態13.1.13by-need同期13.1.14 読み出し専用変数13.1.15例外処理13.1.16 失敗値13.1.17変数置き換え13.2 宣言的並列性13.2.1 部分停止と全体停止13.2.2論理的同値13.2.3 宣言的並列性の形式的定義13.2.4 合流性13.3 8つの計算モデル13.4 よくある抽象の意味13.5歴史に関する注記13.6 練習問題
