 
|
はてなキーワード: デフォルトとは
財政的に大きな問題を抱える日本は、今後どのような道が残されているのでしょうか。
組織や構造を変革するには、一度クラッシュしてしまった方がよいという意見もありますが、これは絶対に防がなくてはなりません。
クラッシュするということは、国民が持っている定期預金や生命保険、信託、郵貯など、全部がぶっ飛んでしまうということです。
そうなると皆さんはクラッシュした後、生き残れるでしょうか。
例えばアメリカでは国債を外国人に買わせて、国内で買っている人は少ないので、国民は生き残れるでしょう。
しかし、日本の場合は、国債のほとんどを国民が知らずに持っているわけです。
ギリシャでは国債がクラッシュし、ギリシャ人ではなく、ドイツやフランス、イタリアの銀行が救済を求めています。
日本の場合は、金融機関が倒産の危機に陥った場合、そこに預けているのは国民なのです。
その国民のお金が１４００兆円あり、それがすべてひっくり返ることになったら、多くの人は生きていけなくなります。
戦争が終わった後、戦時国債が全てデフォルトしましたが、ハイパーインフレが起こり、１００分の１にデノミをしました。
当時のような事態を乗り越えられる準備をしている国民はいません。
安心して、郵貯を買ったり、定期預金をしたりしているものがぶっ飛んでしまうわけですから、日本人は生活できなくなるのは分かりきっています。
私は「国を信用するな」、「市場が暴力装置だ」と叫んできましたが、まさにそういうことなのです。
クラッシュした方がいいという議論をする人が識者の中にもいますが（池田信夫など）、どうかしていると思います。
一度そういう事態になればみんな目が覚めるのでは、などと言う、その本人は大丈夫なのかと聞きたいです。
そういう事態になったときには、アメリカなど諸外国も危機に陥るでしょうが、
Python vs Ruby vs PHP vs Haskell プログラミング言語バトル part1
http://anond.hatelabo.jp/20120118220204
Rubyistってなんであんな小学校の図書室で毎日読書してそうな
顔面オジサン、オバサンばっかなの？
Scalaer: 鼻持ちならない、モヒカン
Lisper: マジキチ
Rubyist: ネクラ、オタク、キモメン、いじめられっこネクラチビメガネ、色黒、キモオタ、顔面オジサン、オバサン
Rubyのブロックが便利すぎて、Pythonをやめたくなった。
いちいちtemporaryな関数を作成してから目的の関数に渡していたのがばからしくなった。
リストやジェネレータ式の内包表記が便利過ぎて
どうせ廃れる。
609
＞リストやジェネレータ式の内包表記が便利過ぎて
おれもそう信じてたけど、Rubyの、メソッド呼び出しを続けて書けるほうが便利だわ。
まるでjQueryみたい。といってもjQueryのほうが後発だけど。
たとえば「xsから0以上のものを選んで、その二乗の和を求める」場合
sum([ x*x for x in xs if x > 0 ])
これだと、後ろから読まないといけないんだよね。でも
xs.select{|x| x > 0}.map{|x| x*x }.sum
これなら頭からひとつずつ読めばいいから、わかりやすいし、考えたとおりに書きやすい。
まさにスクリプトって感じがする。
Python: [[x,y] for x in xs for y in xs]
Ruby: xs.map{|x| xs.map{|y| [x,y] } }.flatten(1)
いっぽうメソッドチェーンは
orz.sage().hage().hoge().hige() タイプの問題には向いている
つまり向いている方向がちがう
(まあHaskellなら hige . hoge . hage . sage と書くだけだというのは置いといて）
強い弱いということで言うと、問題を解くのに必要な一番能力が弱い
（限定された）道具を使うという考え方があるようだよ
ベタ再帰は強い（汎用的）、がそれゆえ読むのに注意を必要とする
foldrは再帰よりは弱いが、foldrで表現可能な問題のクラス（原始再帰）はかなり
広いので、mapやfilterで済むならもちろんそのほうが望ましい
ではこの問題は弱いmapやfilterを結合させるほうがいいかというと、
俺はlist comprehensionのほうが集合表記そのもの=whatを表現していて好きだな
Pythonのlist comprehensionのsyntaxはあまり好きではないが
それは大きな問題じゃない
メソッドチェーンってバグをわかりにくくするだけだと思うなあ。もちろん性能面もあるし。linqとかは良いと思うけど。
同じメソッドチェーンでも、linqなら良いけどrubyなら悪い .....
一言で言うと「俺はRubyが大嫌いなんだぁーー」ということですな
内包表記は構文でサポートしないと難しい（マクロがあれば別だが）
メソッドチェーンが関数型の方法に比べて特に優れている点があるようには思えないが
パイプ順に書きたければ書けるし
680,663
Pythonには関数型として致命的な弱点があるから、メソッドチェーンでは簡潔なコードが書けない
たとえば「(1) Rubyは 条件判定が(文ではなく)式」だから以下のようなコードが書ける
if test
if test_1 then test_1_1 else test_1_2 end
else
if test_2 then test_2_1 else test_2_2 end
end
}
あるいは「(2) Rubyはブロック内で局所宣言が可能」だから上のコードを以下のように書き換えてもいい
cond_1 = if test_1 then test_1_1 else test_1_2 end
cond_2 = if test_2 then test_2_1 else test_2_2 end
if test then cond_1 else cond_2 end
}
関数型言語であれば「(1) 条件判定(if/case)が式」で「(2) 局所宣言(let .. in .. end)が可能」なの当たり前
ところが残念な事に、どちらもPythonには欠落しているから、上の例はストレートにコード化できない
だからPythonではメソッドチェーンは使われないし、「酸っぱい葡萄」に見える
Rubyでもリスト内包表記が言語として組み込まれてくれると嬉しい
だと思う
頭に浮かんだロジックをすばやくコード化するのはメソッドチェーンが適しているし、
じっくり腰を据えてコード設計するならリスト内包表記のほうが美しい
自分は、たぶんこのスレもRubyコアの中の人も見ているだろうから
そのうちRubyにもリスト内包表記が実装されるんじゃないかと期待しているw
メソッドチェーンは書き易い
内包表記は見た目が整ってて綺麗、最終的な型がわかり易い
いじょ。
Pythonの方が弄れる対象が多いのに、なんでウェブ系だとPHPの方が流行ってんだろ
端末からのテキスト処理も楽だし、数値計算周りのライブラリも充実しているのに
PHPが優遇されているのって歴史的な経緯以外に何か他の理由でもあるのか？
けどまぁ、情弱な文系SEが大半を占めているバカだらけの日本じゃ別にPHPで困ることもないか
数値計算や端末からのテキスト処理なんてWeb系じゃ大して使わないからなあ…
Pythonに関しては、ZopeさえコケていなければWebサーバ用LLとして大成功していたはずなのに、
Railsなんかが登場したおかげで、すっかり影が薄くなってしまいますた....
ってか、railsにインスパイアされたフレームワークって今じゃ幾らでもあるよね
djangoとかCakePHPとか。rubyってRoRを使いたいユーザを除くと、
pythonやPHPの方がユーザー数は圧倒的に多いと思うんだけど
本家のrailsって、他を遥かに越えるほど良いものなんだっけ？
44
Zopeが登場した当時、「RDB+PHPはもう古い、これからはOODB+ZopeがWebの中軸になる！」と
少なくとも自分はZopeからPythonという言語を知ったし、その時点でRubyは知らなかった
そして、その後のORM(RDB)+Railsの出現と華々しい革新性への注目は、誰もが知っているだろう
今でもZopeの開発は継続されてはいるが、結果的に当初の期待が大きく裏切られたという事実は動かしがたい
djangoとCakePHPについては実際に触っていないので憶測になるが、おそらく技術水準ではRailsと同等だろう
しかしRailsはRailsでコミュニティの活動が活発だし、その進化は異常に早い
Railsに何か致命的なトラブルが発生して開発が停滞する、あるいはdjangoやCakePHPから
何かのイノベーションが提示されでもされない限り、後発のdjangoやCakePHPがRailsに追いつくのは無理
Railsは決して技術的に完璧なWebフレームワークではないんだけどね....（たとえばSeaSideのような.... ）
だからこそ「もしもZopeが....だったなら」という「たら・れば」感はPythonコミュニティの潜在認識になっている
C a k e P H P は う ん こ
CakePHP使ってんの？
可哀そうにw
でもやっぱりいつもの使い慣れたLL(Python/Ruby)で
Webサービスを書きたいってのがある
求人数は
Ruby on Rails＞＞＞＞＞＞＞＞Django
http://www.indeed.com/jobtrends?q=django%2Cruby+on+rails&l=
どういうことなの？
求人数が多いのはそのためだと思うよ
なんかのミスかと思ったがアメリカでもRuby on Railsは人気があるのかなあ・・・
Pythonのほうが使いやすいと思うのだがフレームワークはRailsが優位なんだろうか
Djangoは周辺ライブラリが微妙だし本体も鈍くさい感じがする。
でも、FlaskはSinatraより好きだから、Pythonが嫌いってわけではない。むしろ好き。
ただ、いざ作り始めるとやっぱりRailsが楽だなあってなって、Railsを使い続けている。
同感だ
同じように思っている人が他にもいて安心した
PHPはフレームワークが乱立しすぎているから、RailsをPHPで実装してみようというやつが出てきた。
それに比べてPythonは、Zopeというデファクトスタンダードが既に存在していたけど、
ただ、どうやってもRailsもどきがRailsを超えることはできないのは間違いない。
パクリはオリジナルを超えられない(ｷﾘｯ って定型句だけど、
これってｷﾘｯって言いたいだけだと思う。
D言語って超えたって？
B言語って超えたって？
PHPで同じ事をできないわけではないだろうけど、Ruby on Railsほど簡潔にはできない
まあくだらねえWEBサービス作って喜んでる情弱は早く死ねって事だよ
そういう理由じゃなくてRailsのほうが単純に情報もプラグインも多いからでしょ
linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
わざわざ不合理で不完全な言語を使うなんて
もしも
＞linuxじゃデフォのツールなんだし、ツールとの連携を考えたらpython一択じゃん
真実であるのなら、今頃はdjangoの情報とプラグインが溢れかえっているはず
yumや、gdbとgnomeの拡張がpythonであるからといって、それをwebアプリでも使いたいと思う人は少ないというだけのこと。
ソースからインストールする必要があったとしても、web開発ではrubyを使いたいという人が多いというだけのこと。
というか、世界中のPythonプログラマが Remeber Zope!! を合い言葉に
打倒RailsたるWebフレームワークを開発しているはずだけど、
Railsも登場してから、かなりの年月が経過しているんだけどなぁ....
その間にもRailsはRails 3が登場して、REST/AJAXの強化等の進化が継続しているよ
Ruby では
ary.map {|x| x**2}
map(lambda x: x**2, ary)
となり、lambda の本体が1つの式では表現しきれなくなると
.....
と書き換える必要があります。
f = lambda x:(x and f(x-1)*x)or 1
RubyにはPythonのように「lambda本体は式でなければならない」という限定がありませんから、
f = lambda{|x|if x == 0 then 1 else x*f.call(x-1) end}
または
f = lambda{|x|x == 0 ? 1 : x*f.call(x-1)}
と書けます。lambda内でreturnが使えますから、書きたければ
f = lambda{|x|if x == 0 then return 1 else return x*f.call(x-1) end}
でもOKです。
348
これはPythonをdisっているように見せかけてRubyをdisっているのか？ と一瞬思ってしまったｗ
だってRubyのほうが長くない？CLのfuncallみたいなcall()がちょっとうざいし…
そしてどっちもlambda式の中で束縛変数の名前で再帰可能、と
print [x*2+100 for x in [1,2,3,4,5] if x > 2 and x < 5]
暗号のように見える。
puts [1,2,3,4,5].select{|i| i > 2 and i < 5}.map{|i| i*2+100}
思考の流れと、コードの流れが一致しているので書きやすい。
map(lambda x: x*2+100, filter(lambda x: x > 2 and x < 5, [1,2,3,4,5]))
pythonて可読性が高いのをうたってる割にはそこいまいちだよね
Rubyの場合には、左から右へと無名関数がデータフローあるいは
関数型プログラミングに不慣れな初心者でも、参照透明性のあるコードが自然に書ける
プログラマにとって優しい or プログラミングの楽しさを教えてくれるのがRuby
それと比較すると、Pythonのコードは、関数型プログラミングというものが
いかに高度で難解なものであるかという事をもったいぶってプログラマに押し付ける
もしもPythonしか知らないプログラマであれば、関数型 = 難解 という印象を持つだろう
階乗計算くらいだと単純すぎて、ナゼ重要なのかが分かりづらいと思うのでコードで示す
result_list = source_list.map { |elem|
x = foo(elem.x) # ここが局所宣言を書く部分
x + y # 最後に評価された式の値が、無名関数のリターン値になる
}
Rubyでは、map等に与える無名関数の中で局所的な環境(クロージャ)が作られるから、
x = foo(...) のような代入文がいくつでも(= 複雑な処理でも)書ける
このポイントは、実用的なプログラムを関数型風で書こうとした時に、威力を発揮する
余計分かりづらくなった
高卒ドカタなんだろうなぁと可哀想になる
集合の表記に似せてることが分かるから
355
＞map/filterはfor/ifと同じだと言っているだけだから、難解という印象は持たない。
関数型プログラミングに慣れた、あるいは得意な人であれば、そういった印象なんだろね
Rubyの魅力はこれから関数型プログラミングを学ぼうとする初心者、 あるいはそんな初心者へ教える立場から見た、優しさ or 分かりやすさなんだ
[1,4,3,2].sort.reverse.map{|x| x.to_s}.join('-')
Pythonだと読みにくい。
'-'.join(map(str, reversed(sorted([1,4,3,2]))))
Pythonでは思考の流れと一致しないばかりか、「カッコだらけ」のコードになると.....
カッコだらけのコードを分かりやすくする基本的な方法は静的単一代入じゃないか
Rubyのやり方は基本ではなく玄人のやり方だろ
Pythonでは組み込みの型でメソッドチェインはやって欲しくないな
似たようなコレクションtuple,deque,array,queue等にも同じメソッドが必要になってくるし。
372
外部のライブラリでも列挙可能なものは、たいていEnumerableモジュールをimportしてますね
Rubyユーザーは列挙可能なものはmapやselectできて当然だろって思ってる気がします
Pythonは「何かを便利に書くためのしわ寄せ」をはっきり寄せてくる
得意と不得意を言語レベルではっきり主張するのでメリケン好みと言えなくもない
Rubyは全方位になんとなく八方美人なので、全体的になんとなく書きやすくてなんとなくキモくて遅い
「書きにくいってことはその処理に向いてないってことだから諦めろ」を地で行く
無名関数が文を使うほど複雑なら名前を付けるのが Python 流と想像。
これを読みづらいと感じるのは、左から右に流れる
もしかしてアラビア語ネイティブな人からすると逆に読みやすいのか？
前記事
http://anond.hatelabo.jp/20120108211250
■「呪い」はツールで封じるべき
http://anond.hatelabo.jp/20120112030008
まとめると、はてブのコメントが偏りすぎると(はてな的に)困ったね、という話でした。
で、ここからがやっと本題です。じゃ、具体的にどうするのって話です。
まず、誰もがわかりきっていることですが、すでにはてなブックマークは価値ある情報を共有するブックマークとしての利用者ばかりではなく、記事やページに対するレビューというか批判や皮肉を投げ捨てる場として使うユーザーと混在している状態なわけです。「どうでもいい」と思っていることにすらブックマークしてひと言皮肉を言わずにはいられない人も世の中にはいるのです。宝箱とごみ箱がごっちゃになっているわけで、まずこの両者をはっきりと区別できるようにすべきです。
そこで、参考にしてほしいのはAmazonのレビューです。個人的にAmazonのレビューの情報設計の素晴らしいと思うところは、レビューそのものに対する「役に立ったかどうか」の評価軸の他に、商品に対する「評価の高いレビュー」と「評価の低いレビュー」を対立軸で並列させている点です。これをはてブにうまく適用すれば、その記事に対する否定的な意見と肯定的な意見のどちらが多いのか一目瞭然になる上、どちらの意見も有益な情報を拾えるようになるわけです。
つまり、
・現状はあまり機能していないページの評価に対するスターを改善し、「お気に入り度」のような形でブックマーク時に5段階でページを評価させるようにしておく。
→これで今まで曖昧だったページ自体の評価がはっきりする。
→デフォルトは★３つにしておけば、面倒な人は入力しないでいいが、全体のコメントには反映されにくい。
・ページへの評価が低いユーザーと高い評価のユーザーを並列でコメントの評価順に並べる。
・評価とコメントが矛盾しているようなユーザーも出てくるので、ユーザーコメントに対する評価やランク付けも今までより厳密に、匿名でプラス評価とマイナス評価で行う。
・さらにホッテントリは徐々にページ自体の評価を基準としてブックマーク数と合算してポイント制に移行すればいい。
基本的にはこれで全然違ってくると思う。まぁ、Twitterと同期させたことで、はてブも閉鎖されたコミュニティでなくなりつつあるので、新しい血を入れる、ということも引き続き進めていきつつ。あと、話がずれるけど、増田にツイートボタンやいいね！ボタンを置いたのもいい対策だと思う。増田に関して言えば、これではてブの偏りがより明確になった気がする。で、他のコミュニティにも拡散された後で、大勢が変わってくると、一部の「ズレた」ことに気づいた初期段階でコメントを残したはてブの人たちは、空気を読んで自分のコメントを消したりする非常に香ばしい状況も垣間見れたりするわけです。
これを増田に書いた意味については面倒なので問いたださないでください。
そんなわけで、はてなには引き続きがんばっていただきたいです。
そうなんだ、ちなみに、デフォルトはいくら？子供の場合最低金額になっていて、引き上げるために設定変更が必要ってことでいいのかな？
であれば、問題ないと思う。
いや、あのー、インカム重視でごりごり金稼ぐこと目的にできてるゲーセンシステムで本当に遊んだ時代があったのか？
あのバカスカ死にまくるゲームバランスで、プレイ回数の少ない慣れないプレイヤーはあっというまに残機なくしてコンティニュー。
リマインドしようにも、これを書いた人（＝自分）の学力だと読めない本だったから無理。無理ゲーだった。
第一章
1
意味論的に透明なシステムと結びついた心の概念および計算機モデルを意味する。
この主義の限界を
2
チューリングの形式化が持っている特徴
(1)物理的組織によってではなく、記号操作の形式的特性によるメカニズムの集合全体を包括
(2)そのメカニズムがいかにすれば十分に明確化された問題すべてに取り組むことができるか示している
(3)万能チューリングマシンを定義する方法を示している
⇒ 素材は重要ではなく、形式的特性が能力を原理的に保証している
フォン・ノイマンがコンピュータを設計し、1960s、ジョン・マッカーシーがLISP（プログラム言語）を開発。
⇒ 研究開発が可能に
A・ニューウェルとH・サイモンが物理記号システムという概念を提出
⇒理論的に自覚化・明確化される
3
・物理記号システム
①適切に操作可能なトークンに対して任意に意味を割り当てることができるシステムであり、
②正確にプログラミングすればこの割り当てられた意味論的内容と細かい点においても一致した仕方で行動すると信じられるようなシステム
by 1976 ニューウェル & サイモン
・強い物理記号システムの仮説
SPSS strong-physical-symbol-system
「標準的な記号アトムのフォン・ノイマン型の操作を行っている仮想機械は、一般的な知的行為を実現するための直接的かつ十分な手段を持っている」
①仮想機械
そのプログラムに我々が命令を与える機械を模倣させるような「機械」
・記号を割り当てる
・変数を束縛する
・記号列の複写、読みとり、修正
等々
③標準的な記号アトム
④一般的な知的行為を実現するための直接的で必要かつ十分な手段
そうした機械は、それを支えている特定のアーキテクチュア（その基盤になっている他の現実的もしくは仮想的機械から）まったく独立に真に知的でありうるのであり、逆に言えば他のアーキテクチュアや機械をシュミレートすることなく真に知的でありうる
４
このような主張（標準的なLISPのアトムのごちゃごちゃした操作が、知能や思考の本質を構成しうるという見解）が、ニューウェルとサイモンのものだとできる動かぬ証拠は、彼ら自身の実践。
彼らの仕事の特徴（例:BACON）
・規則あるいはヒューリスティックス（発見的手法）の直列的（経験則を用いたも多少は運が左右する⇔体系的）適用に依存している
・そうしたヒューリステイックスの大部分が、かなり高いレベルで意識的に内省可能
・選ばれた課題領域を扱う
BACON:一連のデータから科学的法則を帰納する（ケプラーの第三法則、オームの法則）
・BACONが取り組んだデータをフォーマット化下のは、人間の労苦
・BACONは十分に構造化された課題にしか取り組めない。
ケプラーの第三法則は見つけられても、ペトリシャーレのカビとバクテリアの関係からペニシリンを発見する事はできない
・BACONが展開する知識とヒューリスティックスは、人間のプロトコルや実験記録に大いに頼り、われわれが自分自身の思考について内省する思考のレベルからかなり直接的にコード化されたもの
⇒この種の思考は原初的で瞬間的なプロセスの上に後から被せられたもの。理解するということを具体的な例で説明する事には役に立たないであろう
サイモン等は、人間の思考のすべてがただ一つの種類の計算アーキテクチュアに依存すると信じている。
しかし、筆者は違う考えを持つ。サイモンとラングレイの仕事では、洞察のひらめきといったタイプの認識を表現できない。
心は、多くの仮想的アーキテクチュアからなる複雑なシステムであると考える
知的課題や、感覚運動的な課題のような、なめらかに無意識的に行われるものは無視されている
５
古典的システムは記号アトムの使用に頼り、コネクショニズムはこれを避ける。
古典主義者:意味論的に透明なシステムの構築に対して、方法論的にコミットしている人々
STS semanttically transparent system
「システムの振る舞いについての記号的な（概念レベルでの）意味論的記述と、システムの形式的な計算活動の内的に表現された対象についての投影可能な意味論的解釈との間にきちんとした写像関係の記述が可能な場合にのみ、そのシステムは意味論的に透明であるといえる」
きわめて大ざっぱにいえば、あるシステムかSTSと見なされるのは、そのアルゴリズムの記述（レベル2）における計算の対象が、概念的レベルの用語で表現されたその課題の分析の記述（レベル1）と同型である場合である。
（レベル１:計算理論:（高い抽象レベルにおいて）どのような関数が計算されるかについての考え
レベル２:表現とアルゴリズム:それを計算する（具体的な）方法
レベル３:インプリメンテーション:現実の機械において計算がいかにして肉体あるいはシリコンなどで実現されるか）
（１）古典的理論は――コネクショニズムはそうではないが――統語論と意味論を組み合わせた記号システムを仮定している
（２）もし何らかの種類の構造化された表現が利用可能であれば、それらの表現についての計算操作を、その構造に鋭敏に反応するかのような形で規定できる。
もしそのような構造が存在していなければ、（すなわち、どんな記号表現も存在していなければ、）計算操作を規定することはできない
◎要するに、古典的システムは、統語論的に構造化された記号的表現を仮定し、そうした表現の構造によって、それに適用される計算操作を規定するものである
第二章
１
ドレイファス:古典的認知主義の問題は、人間の常識的な知識を表象として再現し表現しようとする形式主義の妥当性
サール:形式的なものと志向的なものとの間に、あるいは統語論と意味論との間にギャップが認められる
この二つの種類の懸念について検討する。
２
「あなたの持っているのはそんなにいいボールじゃないわ。それを私にちょうだい。そしたら私、このキャンディーをあなたにあげるわ」
この言葉を理解するために、ミンスキーちとパペートは膨大な概念のリストをあげる。
ウィノブラードのSHRDLUでは不十分。
・フレームは、常識がうまく対処している偶発的出来事のすべてをカバーしているとは思えない（バースデーケーキに立つ黒いローソクに、フレームは対処できるか？）
・フレームからフレームへの移行を促す規則（メタフレーム？）をいつ適用すべきか、システムはどうやって知るのだろう？
ドレイファス:互いに関連しあった特徴や可能性のすべてを、文脈に依存しない事実や規則によって形式的に把握するという課題には際限がないのではないか
３
・ドレイファスの二つの主張
（１）身体問題
「このシャンプーが目に入らないようにご注意ください。もし入った場合は、ぬるま湯でよく洗ってください」
コンピュータは、身体、欲求、感情、共通言語や社会習慣も持たない。だからコンピュータは、この文章が何を洗うように言っているのか理解できない
（２）コード化
人間は自分たちを取り巻く状況がどんなものかを絶えず感じ取ることができる。
このノウハウは、何らかの知識表現言語によって、一種の知識として表現できるものなのだろうか？
AIプログラム（＝言語）が知識を表現する仕方が、現実の課題に対して根本的に不適合だと懸念する。
４
「強いAI仮説」を、サールは批判する
強いAI仮説:適切にプログラムされたコンピュータは、文字通り認知的な状態をとり、その際プログラムは人間の認知を説明するものとなる
Schank and Abelson 1977の、「ストーリーを理解するという志向的活動をシミュレートしているかに見える特別なプログラム」に対して、「中国語の部屋」を使うことで批判する。
サール:形式的に区別される要素に対する計算操作を行っているだけでは、どんなコンピュータも〈理解する〉ことはできない。したがって、そのような計算操作を規定するプログラムが、心の固有の性質について何かを示すこともあり得ない。
具体例:英語話者が英語を理解することと、中国語の部屋の操作者が中国語を「理解すること」の比較
「人間は何も理解していなくても形式的な原理に従うことができる」
以下、サールの誤りについて論じる
５
サールに対する仮想反論「脳シュミレーター説」
脳シュミレータ説：あるりプログラムが中国語を理解する実際の中国人の形式的な構造をモデル化したと仮定すると、そのときそのプログラムは間違いなく真の中国語の理解を構成したことになる
↑（サールの再反論）
（１）脳の形式的な性質は志向性を構成しない（三章にて説明）
（２）脳の形式的な性質が志向性を構成しないのは、ある種の素材だけが思考を支えることができるからである
↑（アナロジー）
光合成：光合成の形式的な記述を手に入れても、素材が違えば光合成は再現できない
では、思考をもたらすような脳の物理的性質とは？
：外因的および内因的な刺戟に対して脳に大規模な変動が引き起こされること
↑（コメント）
『中国語の部屋』が大規模な構造的変動を必要としないシステムなら、中国語の部屋による反論は無効
６
微視的機能主義
機能主義は、心的状態の本質を、
入力、内的状態の変換、出力からなるプロフィールと同一視した。
（適切なプロフィールを持つシステムはどんなものであれ、その規模や性質や構成要素にかかわれなく、当の心的状態を実現するであろう）
↑（批判）
（中国国家脳のような）心的状態を実現する見込みがないようなシステムも、「入力、内的状態の変換、出力」のプロフィールを持つシステムへと組織することは可能であるよように思われる。
こうした極端な寛大さは、機能主義の立場を掘り崩してしまいそう
・問題は、「入力、内的状態の変換、出力」の系列をどこに位置づけるか
×大まかなレベルに位置づけ
⇒感覚質の欠如、極端な寛大さ
△ライカンの「小人機能主義」
○微視的機能主義
・機能主義の批判はゲシュタルト盲に陥っているのでは Lycan 1981
：機能的な構成要素があまりにも大きい、極度に小さい、それらしくない等であるために、そうしたものからなるシステムに志向性を帰属させるという考えに抵抗するということ
（ライカン「小人機能主義」
：機能的な下位システムは、それがエージェントのために何をしているかということによって同定される）
微視的機能主義
内容や目的に関連づけからはかけ離れた用語で
記述しようとするもの
・諸関係が得られたとき、システムには大規模で柔軟な構造的変動が引き起こされ、またそれによってさまざまな創発敵的性質が得られるようになる
第三章
１
２
「民間心理学」
：自分や他人が、信じたり、希望したり、恐れたり、欲求したりしているということについての日常の理解
民間心理学は、行為・運動を説明するときに、信念や欲求という表現を用いる
「民間心理学は、人間の行動に先立つ内的原因についての素朴で原初的な科学」
３
（１）民間心理学は、偏狭な、特定の人々に限定されたような理解しか与えない。
民間心理学は、子供や狂人や外国人を前にすると、まごついてしまう
（２）民間心理学は停滞したまま、なにも生み出さず、長い間ほとんど変化も進化も発展もしていないところが他の諸科学と異なる
（３）民間心理学は、これまでのところ科学の主要部分にうまく統合されていくような徴候をまったく示していない。残念なことに民間心理学は自然を神経生理学的ないみで妥当な要素にまで分割することには関心がないようである
最近の分析哲学
：頭の状態に関する科学理論というゲームと、民間心理学というゲームを比較することが、そもそも不適当なのではないか
４
Daredevil believes that Electra is dead.
Mary hopes that Fermat's last theorem is true.
のthat以下を、心的状態の内容と言う。
心的状態が考えられる傾向
：われわれの心理学的状態が、本質的に、周囲の世界がどのような状態にあるのかということによって決まるのではなく、
われわれにとってどのように見えているかによって決まる
↓（言い換え）
我々の意識や無意識に何らかの形で影響を与えられないものはどんなものであれ、
本質的に我々の心的状態の正確な限定に関わることはあり得ない
⇒我々の心的状態が現に持っているような内容を持つものは、われわれ自身のあり方ゆえであって、
知られていないかもしれないような周囲世界の事実とは関わりがない……☆
・双生地球……☆に対して疑いを投げかける
双生地球で、「海に水がある」と発話される。
地球A：海にH2Oがある
地球B：海にXYZがある
この違い以外は同質だとする。
すると、
地球上の発話と双生地球の発話は、それぞれH2OがあるかXYZがあるかによってその真偽が決まる
（たとえば、地球Aの海にH2Oがなくて代わりにXYZがあるとしたら、地球Aでの発話は偽になる）
⇒
もし意味が真理条件を確定するのだとすれば、
自然種に関する表現（水、金、空気など）を含む陳述の意味は、
単に主体の限定的に規定可能な状態に言及するだけでは十分に説明できない……☆に反して
二つの選択肢
（１）心理学的な内的要素（地球の話し手と双生地球の話し手に共通）と、
世界関与的な外的要因（仮定上、二つの地球を越えて不変ではない（H2OとXYZ））の両方によって内容が決まるとする、意味と信念に関する合成説
（２）そういったケース（地球と双生地球のケース）は
〈心的状態の純粋に内的でまったく心理学的な要素（☆のこと）〉という観念にさえも疑いを抱かせるものであると考えることもできるだろう
プティ と マクダウェル
「頭の中にあるものが、心の状態と因果関係を持っていることは疑いがない。
しかし、
〈頭の中〉にあるものが心の状態に対して構成的関係にあると考え必要があるのだろうか？」
筆者
：あらゆる内容が根本的に世界に関与している（選択肢（２））ということが判明したとしても、
そのこと自体は必ずしも〈認知科学は心の理解に深く（ことによると構成的にではないかもしれないが）関わる研究である〉という主張を覆すものではない
その主張に対する仮想反論と、それに対する再反論をHornsbyは行った。
仮想反論
：「「行動傾向（心性はこれに随伴して生じるとされる）が二者の間で異なるためには、
内的構成に違いがなければならない。」
という考えを保持すべきである」とするならば、
心的内容は限定的に規定されねばならない（自然種を指示しない）
（「「行動傾向（心性はこれに随伴して生じるとされる）が二者の間で異なるためには、
内的構成に違いがなければならない。」
という考えを保持すべきである」までが、プティとマグダウェルの、「頭の中にあるものが、心の状態と因果関係を持っていることは疑いがない」に対応する。）
仮想反論の詳細
：仮定①：
二人の動作主の心的状態は、彼らの行動傾向に何らかの違いがある場合にのみ異なる
（そこに赤いボールがある、と信じなければ、ボールを投げようとは思わない）
仮定②：
行動が異なる（すなわち、行動が異なる）ためには、内的な物理的状態に何らかの違いかなければならない
結論：それゆえ、心的状態に対応する内的な物理的状態に何らかの違いがなければ、心的状態が異なるということはありえない
「（民間心理学的な心的状態を帰属させることは、限定的内容のみに関わることであるという）結論は、深刻な疑義にさらされることになる。
限定的内容といっても、それを妥当な概念として了解できるかは明らかではない」
なぜなら、
「民間心理学的な内容を（物理的状態に？）帰属させることは、身体的な動きを規定するような頭の状態についての独我論的な研究から引き出すことができるような切り口とは
まったく違った切り口で現実を切り取ることであるように思われる。
その具体的理由として、
ボールをひろうことは、「そこにボールがあると私は知っている」という心的状態と関連するが、そのときの細かな指の動きはそのような心的状態と関連するものではない。
５
筆者
：広域的内容を伴うによ伴わないにせよ、
頭の中で起こっていることに関することに関する科学的カテゴリーや分類に
きちんと還元されるなどということは
とてもあり得ないように思われる。
・民間心理学は、科学的心理学と同じゲームを行ってはいないかもしれない
→
世界を記述しない信念であり、なおかつ
ある人が同じ考えを抱いているといえるような別のケースに投影可能な述語が（科学的記述の上には）存在しないことも可能
６
民間心理学の道具立て（信念と欲求という概念によって、命題的態度を帰属せさるという道具立て）を用いて、心的状態を二者が互いに帰属させあうという日常の慣習（傍点）の目的は？
：
他人の頭の内的状態を追跡しようと試みることによって、
その人の身体の動きを予測し説明するための手段
民間心理学の主要な目的
：
世界の中で活動している仲間たちの行動を、（傍点開始）我々が（傍点終わり）理解できるようにすること
（予測したい対象であり主体である）われわれの仲間たちの四つの特徴
①世界に対する感受性、すなわち感覚や生得的な原書的概念の道具立てをわれわれと共有している
②世界をわれわれと共有している
③彼らは我々自身のもっとも根本的な関心と必要の大部分を共有している
④彼らの思考の有用性は、
（我々自身の思考と同様に、）
彼らが世界の実際の有様をたどっていることと関わっており、
彼らの思考作用が、世界の実際の有様に十分適応していると我々が（進化論的な理由から）考えるような目的と関わっている
この特徴があるので、
「～したい」という欲求さえ同じであれば、
・民間心理学は、脳の状態の違い（that かなり目の粗い、行動上の違いとしては現れてこないような）に対しては、敏感に対応しないように設計されている
・民間心理学は、個人の間の差異を覆い隠し、
さらには種の間の差異さえも覆い隠してしまう（長所であっても短所ではない）
７
筆者の見解
：私の見解では、われわれが信念を帰属させるのは、
行動の全体に一種の解釈の網をかぶせることによってである。
……関連する行動を可能にするものとしての、
根底にある物理的あるいは計算論的な構造がどのようなものであれ、
そうした構造における自然な区分に、網の結び目（すなわち信念と、欲求の特定の帰属）が
対応している必要はない。
――
ということは、Davidson（全体論者）に対するFordorの批判は、筆者の意見にも当てはまるのではないか？
<Fordor>
意識の全体論というのは、
「命題的態度の同一性――特に志向的内容――が、その認知的連関の全体によって決定される」
という考え方。
これに、Fordorは懐疑的。
（命題pの認知的連関というのは、主体がpの意味論的評価、すなわちその真偽の決定に関係するすべての命題のこと）
われわれは、信念や志向的状態を共有している。が、そのとき、すべての命題（認知的連関）を共有しているとは思えない。
信念は、その内容をそれぞれ別に持つ。
：信念がその状態を獲得するのは、脳の状態が逐一、世界と因果関係を結ぶことによってである。
「ある生物が『牛』という概念を持とうと持つまいと、その生物は『馬』という概念を持ちうる」
</Fordor>
筆者
：Fordorの間違い
全体論は、もしそうであれば、人間の心の理解が芋蔓式に進んでくれるのにという、いわば願望。
Fordorが軽蔑したものの通りに進んでくれるかは別問題。
Fordor：バラバラになったブロックを一つの全体に組み合わせるやり方が、全員同じになるはずがない。
筆者：一つのブロックの組み合わせ全体を理解するために、各人が別々のやり方でバラバラにしている
全体論という言葉の使い方が違うから、Fordorの批判は筆者には当てはまらない（という、批判をかわすための節）
７
一章３節での、チャーチランドによる民間心理学批判に、今では応答できる。
（3）に対して、
民間心理学の関心事は、他の主体の顕著の行動パターンだけを可能な限り効率的に分離することである。神経科学とつながることを目的とはしていない
（1）に対して、
民間心理学の道具としての適用範囲は、仲間。狂人の理解は、そもそも目標としていない
（2）に対して、
なので、その中核部分が時間的および地理的な次元を越えて相対的に恒常的であり続けてきたことは驚くべきことではない。
整理。
民間心理学には、きちんとした定義がある。
これまで「民間心理学」として使われてきた言葉の、新たな用語法：「素朴心理学」、「メンタリズム的な理解」
８
因果関係と、構成的関係の区別
構成的関係
：
研究の主題と何らかの形で密接に結びついているということ
因果的に関係
：
因果的に関係している様々な要素は、それほど密接に思考と結びついているわけではないので、
それらの要素を差し引いてもそれによって思考という観念そのものが存続しえなくなる
ということはない。
（チェス盤がなくなっても、チェスの続きは打てる。石を駒に見立てたり、口頭で）
９
・消去主義的唯物論：民間心理学が、心に関する科学に対して歪んだ影響を及ぼすのではないか。民間人は自分自身の心を知らないと、消去主義的唯物論は思っている
↑
（構成的関係）
↓
心
科学と心とを結びつける構成的関係。その得難さが二つのスタンスの対立を生んでいる。が、どちらの立場も同じく、認知という地形に同じ隆起とくぼみを見ている。
では、構成的関係とは何か。
構成的関係←→因果関係
構成的関係：研究の主題（この場合は心）と、何らかの形で概念上密接に結びついていること
因果的関係：因果的に関係している様々な要素は、それほど密接に思考と結びついているわけではないので、それらの要素を差し引いても、それによって思考という観念そのものが存続しえなくなるというひとはない
（駒はなくてもチェスは打てる）
Permalink | トラックバック(0) | 15:30
君は前提条件が間違ってるよ。
旦那への要求が高くて、で、妻になる貴女は何を提供できるの?って感じ
と言ってしまう男は大別すると次の二種類と思われる。 ・「働きもせず家事も育児もろくにせず介護なんて勿論せず夫の金でブランド物を買い漁り銀座でランチを食ってる主婦」と言う どこの漫画の悪役キャラだと言う「主婦像」が現実でも既婚女のデフォルトだと思っている。 ・妻が家政婦兼産む機械兼ベビーシッター兼介護士をしてもそれは「妻が夫に提供出来るもの」として扱わない。
私は嫁の家事に対しては都度「いつもありがとう」って言って抱きしめたり、体を撫で回したりする。ありがとう。
嫁に触るの好きだしね (嫁もくすぐったそうに、でもニマニマしてる)
もちろん私も洗濯、食後の食器洗い、水回りの掃除をする、嫁もありがとう、って言ってくれる。
給料日に手渡しで渡すときも嫁はありがとうございます、っていって受け取ってくれる。
その言葉でまだ頑張れる、より渡したいって思うよ。
私は『嫁には限りなく優しい』けど『全ての女性に優しい訳じゃない』のよ。
君はフェミニズム界隈の人かな? フェミニズムの人はよく「男性全体」を仮想敵としてしまう事がある。
例えばDV夫だったり、金を家に入れない男性だったり、女性を対等に見ない男性像を一般的と考えてしまう傾向があると思う。
でも、そうじゃない男性もいる。
女が結婚相手に金を求めるのは、結婚すれば夫の分の家事育児介護を担わされるからだ。 家政婦兼産む機械兼ベビーシッター兼介護士をする代わりにそれ相応の対価が欲しい、と言っているだけだ。
エロ絵だけのフィルタリングが欲しいっていうならエロ絵の方にタグつけるとかエロ絵専用ランキングとかを隔離して作ってもらうって方向性もあるわけじゃん。
なのに自分の好きなジャンルはタグなしでデフォルトでランキングに残せ、それ以外は排除しろって傲慢さが非難されてんでしょうよ。
ボツ部分。
この記事に書かれていることの一つ一つは特に革新的というわけではありません。((贈与や複数買いについてはオタクの基本行動として認知され始め、プロレスファンやEXILEファン、腐女子などの女性ファンの行動原理として顕著になり、映画館や喫茶店サービスとして応用されるなどの経緯を経て、AKB48で完成に至ったネタですね。 アメリカのIT企業等はこれをテクノロジとして実現しており、itune storeでも「紹介」や「プレゼントする」がデフォルト機能で存在したり、twittマーケティング用語でもAISASといったフレームワークやtwitter、SNSを用いた拡大が重要なテーマとして議論されています。 また成功しているDRMにおいては「メッセージを上から押し付ける」というブランドのたてかたがあることも、controversyが購買決定要因の一要素であることもすでに語られています))しかし、「もしドラ」は結果として大成功を収めました。何が違ったのでしょう。
基本的に上記で語られている要素は、「マス」で勝つための戦略ではなく、むしろそこから抜けだして「ニッチ」市場で戦うための戦術と言われていました。しかし、グレイトフルデッドにせよ、もしドラにせよ、AKBにせよ、「ニッチ」や「戦術」レベルのものが、現実に「マス」「戦略」レベルで勝利をおさめている、というところが非常に面白いです。少なくとも、上記のようなバリバリ「ニッチ」寄りなことを考えていた人が、その結果としてイノベーションをおこし、それがマスレベルまで到達した。このことがまるで物語的で面白いのです。
つまり、岩崎さんについては、ニッチの戦術を「本とは何か」というマスなテーマに、しかも自分にとって初めての本でいきなり適応しようとしたその度胸がものすごいと思うのです。岩崎さんを特別たらしめたのは、思考そのものではなく、その思考を疑わず実行に移せる主人公気質な部分だと思います。私はその点にこそ興味があります。この人のすごさは多分理論として語れないところにあるのであって、言葉で説明しようとすると今回のように陳腐な印象になってしまうのだと思います。
女が結婚相手に金を求めるのは、結婚すれば夫の分の家事育児介護を担わされるからだ。
家政婦兼産む機械兼ベビーシッター兼介護士をする代わりにそれ相応の対価が欲しい、と言っているだけだ。
と言ってしまう男は大別すると次の二種類と思われる。
・「働きもせず家事も育児もろくにせず介護なんて勿論せず夫の金でブランド物を買い漁り銀座でランチを食ってる主婦」と言う
どこの漫画の悪役キャラだと言う「主婦像」が現実でも既婚女のデフォルトだと思っている。
・妻が家政婦兼産む機械兼ベビーシッター兼介護士をしてもそれは「妻が夫に提供出来るもの」として扱わない。
これらは「妻がタダで担って当然の事」だと思っているので、プラスアルファが無い限り「妻は何もしていない」扱いをする。
前者はまさしく「現実と架空の区別がつかないオタ」そのまんまだが、こちらは現実に気付けば是正出来そうな分まだマシ。
後者は救いようがない。
で、増田はどちらなのか。
むしろ祝いをもらったらお返しをするのがデフォルト
いろんな挨拶が形骸化しつつある現代日本でさえ出産内祝いだの快気祝いだので検索するとかなりの確率で「お返し」についてが併せて引っかかる
インディアンの部族かどっかでは祝われたらより盛大に祝い返すのが常識だったせいで振る舞い合戦に持ち込んで相手の部族の財産食いつぶさせるみたいな戦略があったとかなかったとか
祝いをもらったら祝い返す、気遣ってもらったら気遣いを返す
だいたい祝いを返すってのはもらった祝いへの礼も兼ねてるんだから、「祝い返さなかったら相手に対して失礼」となる