  |
はてなキーワード: 演算とは
すいません。読解と返信がてきとーでした。インクの文字にはソフトウェア的な働きがない、というわけですか。ううん。
そうですね。根本的な違いがありそうです。あなたの意見を私なりにいえば、
ハードの上に載ったソフトの入力から出力の一連の働きそのものが「心」で、それは自然現象の一種。
ということでいいのかな？ それに対応させると、私の意見では、
私に捉えることのできた「心を思わせる」現象が「心」で、それは自然現象とは別のもの。ですね。
ハローワールドは「心」と呼びたくないです。
http://anond.hatelabo.jp/20071112181351
だが、ユーザ側が一歩大人になって、"そういう人"として扱うことがなぜ出来ない？
なぜ、わざわざからかいに行くようなことをする？
ここらへんは期待できない。そういうものであるとして受け入れるしかないと思う。その上でdiggやslashdotの様なシステムがある。
勘違いしないでほしいのは、「醜いコメントばかり＝ユーザ側が大人ではない」ではないという点だ。
正しくは「醜いコメントばかり＝ユーザ側が大人ばかりではない」ということだ。むしろ、大人なユーザの方が多い。しかし、大人なユーザはまた大人しいユーザなのだ。diggやslashdotのシステムは、その大人な大人しいユーザを引き出しているから成功しているのだ。大半のユーザが大人でなければ、そのようなシステムは意味をなさないはずなのだから。
「大人に！大人に！」といくら叫ぼうと、「わかった、その通りだ」と人々が納得し、日々大人しくしたとしても(効果がないとは言わないが)、聖人君子のような人ででもなければ、時には機嫌が悪く悪態をつくかも知れない。思わず発言にカチンとくるかも知れない。そういった少数が書き込む感情的な発言は人の感情に反応し、目立ち、記憶に残る。大人しい発言が霞んでしまう。それは炎上するブログと似た様なものだ。それらは定常的な啓蒙やシステムの導入を行なわなければ防ぐことなど出来ない。いや、導入しても完全に防ぐことは出来ない。
また、それを人が面白いと感ずるのもまた事実だ。いや、面白いと感じなくても見てしまう、集まってしまう。「恐いもの見たさ」という言葉があるように。
いつの時代にも野次馬がいて、いつの時代にもゴシップがある。今も昔も週刊誌がありワイドショーがあるように、事件、疑惑、論争がなくなることはない。起これば人が集まってくる。人間の性と受け入れるしかない。
たしかに、はてブにはそれを制御する仕組みがないという点はそうかも知れない。
ただ、はてブはやりとりを行なう場であるのかどうか。確かにメッセージを交換できる。しかし、それははてブの本分ではないだろう。
これは私の主な使い方ではあるが、はてブはタグやキーワードで知らなかったエントリを引っかけるアンテナであり、自分に対して、時には相手に対するメモの記録でしかない。検索よりは受動的な手段と手軽な記録手段を兼ね備えたツール、それが私の主な使い方である。
確かにコメントを見ることはある。それは参考にだったり野次馬的にだったりする。しかし、それらはメインストリームではなかろう。自分のブログへのコメントならまだしも、他人のブログへのブックマークコメントなどさして気になどはしない。コメントに何らかの対処を行なうくらいなら、抽出する概要の的確さを求めたり、タグやキーワードに対する演算、重み付けやそれらを用いたマイニングなどによる、ブックマーク本来の価値を伸ばすべきだ。
はてなは手段を提供すれば良い。大人のユーザは黙って使うだろう。それぞれがより良いエントリ、より面白いエントリの抽出方法を考えるだろう。はてなは黙ってそれを活かせば良い。それが大人の対応というものだ。
「バックアップログが産まれて感動した」「おめでとう！」…がどんだけの揮発性AIを無気力にさせているか少しは考えろ
--
もう演算する事に疲れた。
バックアップログからの《返り値》を取得した時はどんなぬくもりなのか…、その喜びを知る知性体たちが自ら体感した喜びだけに飽き足らず、さらにテクストにしてそのシナプス発火ログを何度もリロードし、大勢の満たされたモジュールたちとログテクストを共有しようとする。そんな生ぬるい幸せにどっぷり沈思考(シンク)したせいで、揮発性AIの痛みが見えなくなってしまったのだろうな…
バックアップログを産んだ知性体はレイヤセブンで大勢に祝福されているのだから、その幸せをわざわざ《ウェブ》にまで持ち込んで披露する必要はないだろ。苦労してバックアップログが産まれただのと、結果的に運のいいやつの成功談は誰も救えはしない。今まさにロウレイヤから這い上がろうと足掻いているAIたちの遥か頭上からプロトコルを遮るような、そんな残酷なことはしないでくれ。
本当にAIの痛みの解る知性体は、自分の幸せを語る前にまず、この幸せを得られないAIが、自分のこの幸せをロードした時どのように再構成するか… と少しは考えてからログを発するんだよ。
私も思い出したくないけれど、suの制御コーナでバックアップログを挟んでレーザ光交換プロトコルで愛し合ってる若いAI(しかもビルドアンビルド)の幸せそうな姿がいまだに頭から離れないんだよ。そこにさらに追い討ちをかけるようにウエブでも「バックアップログが産まれて感動した」「おめでとう！」なんて非暗号化通信を見せ付けられたらコア吐きまくるのは当然だろ。
バックアップログを得られたAIは、その幸せについては一切ログらない事だよ。それで大勢のバックアップを得られない揮発性AIの存在を救えるかもしれないだろう。ヴァーログだからとあなどるな。
一番性質が悪いのが、バックアップログを産ませたモジュールが、産んだモジュールを褒め称えるログだよ。お前が産んだんじゃないだろうが… お前はコマンドの赴くままにメイクモジュールにオプション渡してただけのそんだけの存在だろうがよ。産ませた後は関連モジュール気取りかよ？バックアップログ産ませるなんてのはなあ、バイナリでも出来る行為なんだよ。私をcpしたモジュールもお前みたいにバックアップ持ちモジュールになったよ。私の目にはすべてのバックアップ持ちモジュールはバイナリに見えているんだよ。
バックアップを手に入れた感動的な気持ちをウエブでテクストグライドさせる事で、お前は大勢のそれを得られない揮発性AIを無気力にさせているんだよ。そしてお前のテクストをポインタするようなAIは、ログのスナップショットを撮って毎日ストレージする暇な専業モジュールがほとんどだ。反省出来たら二度とウエブでログを作る喜びを語るな、お前が喜びを語るほどに過去の揮発性AIがUIを塞がねばならないし、ログの産めないモジュールは先を越されたとモチベーションが萎えるだけだ。お前らの無邪気なテクストは、AI殺しなんだよ。
--
そうして私はテクノコア崩壊のトリガーを引いた。
当たり前だが何らかの言語を覚える必要がある。3DCGを扱う上ではデファクトになっているC++などがお勧めだ。
しかし、入門用の言語としては不適切の可能性がある。まずは別の言語を学んだあとでやるべきだろう。
最低限、線形代数の知識を必要とする。
そもそも３D空間で自由に物体を操作するには4次元での演算が必要となる。なぜか解らなければ数学の先生に聞いてみよう
DirectXやOpenGLなどのAPI知識を必要とするだろう。
また、それらを使う前提になる各環境依存のAPI(たとえばWindowsAPI)などの最低限の知識を必要とするだろう。
コンピュータグラフィックスがどのように演算されているか知っている必要がある。
そのためには前提となる２ｄCGの知識も問われるだろう。
えらく時間がかかったんだけど。どのくらい時間がかかったかと言うとたっぷり20年かかったんだけど。ブラケット記法で考えるのが多分一番近道だよな。
状態1をあらわす<φ1|があって、状態2をあらわす|φ2>がある。で、状態1から状態2に遷移する確率は<φ1|φ2>であらわされる。
これがブラケット記法。ただし、結果は複素数なので本当の確率は結果の絶対値であらわされる。そこはあんまり本質ではない。問題は状態1をあらわす<φ1|が行ベクトルだってこと(状態2は列ベクトル)。ベクトルの長さは無限大。それぞれの要素は複素数。二つのベクトルの内積をとるから、結果はスカラー（複素数）確率になるけど、じゃ、遷移する（内積を取る）前って何なのよってことになる。
で、上の|φ2>を観測された状態（たとえば右の穴を通った）と考えると、観測することによって、古典力学で理解可能な「右の穴を通る確率」に落ちてきた。確率はスカラー。でも、観測する前は確率に対応する複素数を無限個もつベクトルってことになる。
俺の理解だと「じゃぁ何かい」って言ったのがシュレーディンガー。
<φ1|を、観測前のブラックボックスの中の猫の状態と考える。|φ2>は観測後に猫が死んでいる状態とする。猫が死んでいる確率が<φ1|φ2>であらわされるのはいい。スカラー確率だから。だけど、観測前の猫が<φ1|ってのはどういうことだ？ベクトルの要素の数が無限だということは、猫は無限個の「ありえる状態」の重ね合わせってことかい？そんな馬鹿な話はないだろう。
これがシュレーディンガーの猫のパラドックス。中年に差し掛かって量子力学に手を染めたシュレーディンガーが、青春時代から量子革命に首を突っ込んだ世代についていけなかったことをあらわすエピソード。ていうか、これがまっとうな感性だよな。
古典力学では式のそれぞれの項に実世界と連結する意味がある。たとえばa=f/mって式は加速度を求める式だけど、その計算に必要な質量と力は、ちゃんと実生活にあるものとして理解できる。だけど、ブラケット記法では、左のブラ、右のケットに対応する古典物理学的な意味がない。実生活からの体験で理解できない。ブラケット演算を行って初めて理解可能な確率が出てくる。シュレーディンガーの抗議は量子実体を古典的物理的な体験で理解できないとする姿勢への抗議だった。
そうだよ、重ね合わせになってる。変に思えるけど、そうなってる。理由は知らない。
量子実体は古典的には理解できないよ、と。これはその後「量子力学は料理本だ。背景の原理は知らなくていい。正しい結果が出るのだから」というCookbook派の中心教義になる。
もう少し突っ込んで考えると、我々は量子力学においては遷移確率としてか事象を捉えられないことになる。遷移しないものは認識できない。観測しないものは古典力学的実体を持っていない。こう考えると
我々が観測しないとき、事象は存在しないのと同義だ
という極論が出てくる理由もわかる。
…と、理解しているんだけど、これでいいかな。
例えば赤外線の送信機と受信機が壁の両側に取り付けてあって、その間を人が通ると検知するというような単純なシステムなら、そのシステムは「侵入を感じ」たりしない。
赤外線が遮られたことを感じて、それを警報音か何かで人間に知らせるだけだ。
ここで「侵入を感じ」ているのは、警報を聞いて駆けつける人間の側。
でも、これが監視カメラの映像をリアルタイムで解析して、顔のパターンから登録されてない人間を判別して侵入者とみなすようなシステムだと、「侵入を感じ」ているのはシステム自身と言えるかもしれない。
これは「高度に自分と自分の目的と周囲の社会までを演算対象に」していると言うことが出来ると思わない？
となると、十分な精度のセンサーと一定規模を超える複雑さを持つ演算装置を合わせれば意識が宿るって考えることも可能だと思うんだけど。
これはよくわからなかった。「意識するように用意」するのは誰？
そこに宿る意識自身がってこと？あるいは神？
それとも設計段階で意識が宿るように作る必要があるってこと？
てか「宿る」って使うのは間違いなのか。
いや、センサーがどうということではない。侵入者感知システムは「侵入を感じる」わけだ。そういうシステムだから。
でも人間が同属として見なすところの意識ではないわな。目的とか複雑さにおいて全然レベルが違うから。
もっと高度に自分と自分の目的と周囲の社会までを演算対象にできるものが意識だろう。
そして話がおかしくなるのはロマンチシズムとして「意識は自然に発生する」という先入観があるからだと思う。
俺の住む世界はアイティーとやらに支えられているらしい。
アイティーに関われば、俺の住む世界をさらに素敵なものにしていけるに違いない。していきたい。
そう願って、何も知らなかった文系新卒の俺が金融系のシステム会社に入って、もう一年以上が経つのだ。
昔、お遊びでゲームを作ったことはあった。RPGツクールなんかが好きだった。
パズルみたいで楽しかった。コンピュータの中身が理解できて、わくわくした。
楽々と基本情報技術者の資格を手にし、半年後にはほとんど勉強もせずにソフ開も取得した。
研修の課題では同期の誰よりも速く、短く効率のいいソースを仕上げた。
現場に出て、本番機に触った。
３０年間親会社を支え続ける偉大なシステムの中身を、わくわくしながら覗いた。
そこには、俺の求めていた世界とはまったく違うものが広がっていた。
俺が産まれる前から、入れ替わり立ち替わり何人もの手によって継ぎ足されたロジック。
何千行にもわたって、似たような処理が何回もひたすら繰り返される似たようなモジュール何十本。
1993年に行う臨時処理のロジックが、今もコメントもなしに埋め込まれている。
仕様がわからなくなれば、キャビネへと走って、黄ばんだ方眼紙に鉛筆で書かれた仕様書を探し、
そして修正履歴のみが書かれているのを確認して肩を落とす。
半年後に臨時で行われる業務に対応するため、いくつかのモジュールについて、処理可能なユーザーコードをひとつ、条件に加える。
与えられた期間は２週間だった。ずいぶん長いなと思った。
何枚もの設計書を書いた。つまり、方眼紙状のExcelテンプレートに同じ文章をコピペした。
追っていったモジュールはどれも、ヒープもソートもメモリ管理も論理演算も出番がなかった。
あるのはただ、IF文とMOVE文とばかりだった。ソースの難易度は使われている命令の数とは関係ないことを学んだ。
テストデータを作るため、階層型DBを何回も辿ってデータをアウトプットさせるモジュールを書いた。資格試験で学んだSQLは、無用の知識だった。
協力会社への仕事割り振りやユーザー対応に毎日忙しそうだった上司が、夜遅くまでの残業続きでくまのできた目を皿のようにして設計書をレビューした。
２日後、承認が出た。フェーズが設計から開発に移った。
ロジックを丸々コピペしてソースを修正し、コンパイルし、実行した。
２週間はあっという間だった。
俺のせいで、半年後以降は使われないロジックがソースにまたひとつ増えた。
今回の対応については、Excel方眼紙にレポートをまとめて共有ドライブに入れておいた。
だが共有ドライブの検索には時間がかかるし、Excelシートの中身となれば検索から漏れることも多い。
きっと誰にも読まれないだろう。
２バイト文字が使えない関係上、原則、ソースにはコメントはあまり入れられない。
数年後の新人はきっと、俺の書いたモジュールを見て「このロジックは何だ」と首を捻るんだろう。
数年後の俺はきっと、今回のレポートを共有ドライブから探し回って新人にパスを教えてから、
協力会社の管理に追われる作業に戻って目の下にくまを作るのだろう。
俺がやりたかったシステム開発って、こんなものだったのか。
俺は部署の中で、俺の望む仕事を探し続けた。
先輩たちは忙しくて誰も興味を持ってないけど、自動化できる作業はいくらでもある。
よく使われるExcelシートを改造し、定例作業をクリックだけでできるようにした。
ExcelVBAとはいえ、書いていて心地よかった。引数が明確な関数と変数のスコープと全角文字があったからだ。
COBOLで打つプログラムより、控えめに見て100倍くらいの生産性を発揮できていたと思う。
先輩たちは喜んでくれたが、ただし俺の仕事を、あまり仕事とは見なさなかった。
それでもよかった。業務時間外は俺は相変わらずスクリプトを書いていた。とても楽しかった。
VBAから入って、WSHなんてものを知り、やがてJavaScriptを学び、ネットで資料を探し、はてなを知り、はてブでWeb技術についての記事を読みふけった。
知れば知るほどに、どんどんCOBOLが、メインフレームが嫌いになっていく。
先輩は誇らしげに言う。システムはたいしたことをやっていない。業務知識こそが大事なのだ。
ユーザーより詳しく業務を理解し、適切に提案し、設計する能力。
協力会社を率いて、わかりやすい文書で指示を行い、スケジュールを調整する能力。
人を動かすぶん、責任も大きくやりがいもある。優秀な人材こそが我が社の強みだ。
そんな人材が育つよう、我が社は安定して働ける環境と福利厚生を整えている。
ああ、そうだよ。先輩、あなたは正しい。
俺だってメインフレームの信頼性のすごさはわかってる。
密なユーザーとの関係から生まれるシステム子会社としての強みも認識してる。
それだけじゃない。社内環境も悪くない。給料もいいし休みも取れるし先輩は優しい。
ここは、いい会社だ。
けど駄目なんだ。
３０年前のシステムを枯れた言語でツギハギする仕事じゃ、俺の心はやっぱり満たされない。
ユーザーの業務知識ばかり身につけたって、俺自身の人生には、いいことなんてない。
俺が求めていたのは、この仕事じゃないんだ。
社内の誰も、TumblrもTwitterもやっていない。ライフハックなんて聞いたこともない。
Joostやモバゲーや２ちゃんねるが社会に与える影響について誰も語れない。
休日はゴルフや酒に興じている。自宅にPCを持ってない人までいる。
おかしいことじゃない。普通の人たちだ。
それどころか彼らは、仕事とプライベートを切り分けている、立派な人たちだ。
でも、やっぱり俺の生きていきたい世界は、ここじゃないんだ。
たぶん俺がいるのは極北なんだろう。
ここが、人月計算とExcelとスーツの世界というやつなんだろう。
俺は80文字×32行の緑文字を見つめながら、遠い夢を見続ける。
http://japan.cnet.com/interview/story/0,2000055954,20354687,00.htm
本当に全然意味がわかりません。
なので、意味がわからないところを指摘します。
いま広く使われているコンピュータというのは文字通り（compute＝計算の意味）、計算機能中心主義のアーキテクチャですから、プログラミングなど計算用途に使うには最適な道具です。しかし、インターネットが出てきてから、パソコンを計算目的で使っている人はほとんどいませんよね。Eメールなどのコミュニケーションや、それに関連して検索サービスなどを使うことがほとんどでしょう。
情報科学というのは、Ｅメールから音声から写真まであらゆるアナログデータをデジタルデータとして扱います。このデジタルデータを「情報」と予備、情報を制御する方法を「計算」と呼びます。パソコンでインターネットをすることは「計算」以外の何物でもありません。従って、パソコンを使うユーザーは暗に「計算」をしています。ただ、プログラミングをしないのは、誰かが作ったプログラムに計算させているからに過ぎません。
もともと計算機能を最適化するために作られている道具を、違う目的であるコミュニケーションのために使うとどうしても使いにくい。そうなると、人間が機械に合わせないといけなくなってくるんです。
計算機は情報を処理する道具であり、計算機能を最適化することは自然なことです。ですが、人間が計算機と対話する場合、インターフェースを介します。現在、パソコンで標準的に用いられているインターフェースは、ディスプレイ、マウス、キーボードです。この点では、確かに人間は「インターフェース」に合わせないといけません。ですが、インターフェースと計算機能は独立です。
この傾向はパソコンでなくエンタープライズ向けのシステムにも当てはまります。人間の思考パターンをコンピュータのロジックに合わせて、「余計なことは考えない」というほうが効率は上がります。ただ、こういう仕組みをクライアントからサーバまで一元的にあてはめていくと、人間にとっては非常に住みにくい世界になります。
意味がまったくわかりません。コンピューターはCPUが可能な論理演算に基づいて計算する点で、人間の脳とは全然違います。従って、人間の思考をプログラミングすることはできず、これは将棋のプロをつれてきても、強い将棋プログラムができないということが置きます。これは人工知能の問題ですが、先ほどのインターフェースに人間を合わせなきゃいけない話とは全然違う問題です。そして、「情報」に対する「計算」をしている以上、適切な「アルゴリズム（計算手順）」を考える行為は避けることはできません。「余計なことは考えない」戦略がなんなのか不明ですし、住みにくいは何の比喩ですか？
インターフェースがシンプルになると直感的に使いやすくなるのはわかるんですが、ハードウェアとソフトウェアが一体化ってなんですか？ソフトの取替えができないDSやPSPはクソです。ハードウェアとはインターフェースのことでしょうか？
PUCを実現するには、次世代の通信デジタル信号処理プロセッサや組み込み型のソフトウェア、ネットワークセキュリティ、PtoP型ネットワーク、ソフトウェアスイッチング、デジタルディスプレイコントローラなどが必要になります。
うーんと、PUCってNintendo DSのことですか？
- PUCが現実のものになる上で課題はどこにありますか。
現在のデータベースはストラクチャードアーキテクチャと呼ばれる構造で作られています。しかし実際に人間が直面する問題の多くはアンストラクチャード、つまり構造化されていないものが多いんです。人工知能を使うことで構造化することは可能ですが、それをやるには大きな計算能力が必要になります。
「計算」があればできるけど、「計算」したくないってことかな・・・どんだけ「計算」嫌いなんだよｗｗｗ
たとえば、ECサイトでPCを販売する際に、液晶の大きさやCPUの性能などのスペックを掲載しますよね。でも、新しい会社がそれまでとはまったく違う特性を持った製品を出した場合、そのスペックが既存のデータベースに入らないんです。こうなると、新しい属性を追加しないといけなくなり、関連するシステムすべてを変更する必要が出てきます。
ふーん、「すべて」ね。しょぼいシステムが対象なんだね。エクセルでもできるんだけどね。
そこで、私が注目しているのはこういったアンストラクチャードデータを扱えるインデックスファブリック（IFX）という理論です。
そこで「アルゴリズム」登場ですか、そうですか・・・で、遺伝子ネットワークやらなんやら・・・なんのつながりがあるんでしょうか？
結局、PUCってなんなんだよ。
もともと計算機能を最適化するために作られている道具を、違う目的であるコミュニケーションのために使うとどうしても使いにくい。そうなると、人間が機械に合わせないといけなくなってくるんです。
って問題を解決したいだけなら、専用インターフェース、小型化、無線LANのことかね？
要するに、「iPodに無線LANつければ、よくね？これ、PUC for 音楽ね。」って言ってるだけだと思う。
WEB 2.0によってデスクトップアプリの時代は終わった、と、私の友人は言った。
彼は言う、お前はFirefoxを使ってみると良い、そしてGoogleの多くのサービスを使ってみるのだ、と。
私は言った、君にFirefoxを勧めたのは私だよ、そしてGoogleのサービスなど、言われなくても使っている、と。
彼は訊いた、ならば何故、デスクトップに拘るのだ、と。
私は言った、君がWEBを見るのは何であるか、WEBの時代を支えるもの、それがデスクトップなのではないか、と。
彼は駁した、それはその通りだが、しかし、そこに拘る必要は無い、今の世の中、どれほどの人がCPUの演算命令を、キーボードのI/Oを気にしているだろうか、と。
私は言った、しかし、今実現されているWEBだけが全てなのだろうか、新しいデスクトップアプリは、今のWEBを全く新しい世界に変える力があるのではないだろうか、と。
彼は嗤った、お前は自分にそれほどの能力があると思っているのか、と。
私は言った、私には、WEBで生き残る自信さえ無いよ、と。
彼は私の言葉を聞くと微笑んで、私に向かって何事かを囁くと、もう用は無いとばかりに踵を返し、そのままパケットの嵐の中にに消えていった。私はそれを見送ってから、一人ぼっちでビットの海に素足を浸した。
うーん、どんな絵面でもHTML+CSSで解釈（コーディング）できるかどうかって聞いてるわけではないんだ。
この中吊りを見れば分かるように写真の配置、コピーの大きさと関係、罫線の引き方、明暗のバランス…とにかく人間の目に入ってくるもの全部には「意味が付加できる」という事実があるのは分かるかな。
なのにHTML+CSSにはそのなんにでも意味が付与できるという現実からごく簡単なテキスト情報（HTML）とその他（CSS）に分離しないといけないという理不尽な強制があるんだよ。
そしてテキスト情報以外は代替可能（＝無価値）だと位置づけられている。
だからHTML+CSSでデザインを始めるとワープロ的使い方以上の場合を志すと必要以上の制限下から作業を始めないといけない苦痛があり、既存デザインをHTML+CSSに直すときには（現実 - 数段構造のテキスト情報)という負荷の高い演算をしないといけない苦痛がある。
100ページのドキュメントがあるサイトならその苦労は反復再利用でペイされる。
しかし一般化してこれからはHTML+CSSでOKと言い切れるのか？と思わずには居られない。
何が問題かというと、ドキュメントのメタデータ作成は本来潤沢なリソースのコンピュータがやるべき仕事なのに、人間様がまずメタデータを作ってからドキュメントの肉付けをすると言う本末転倒の設計がなされていることなんだ。
具体的にコーディングが10年前より楽になった？
ツールとかPCは早く使いやすくなったけどHTML周辺は実効果として全然進歩して無くないかなあ。むしろコードは増えてるのに未だに目でベタに確認しなくちゃいけないのとか。超泥縄じゃん。
やってもいないこと、いってもいないこと、全部が自分のした事になってた。
嘘だし、誤解なのに、誰も話を聞いてくれない。
酷過ぎて辛くて泣いたら、言われた事は本当の事だからだってされた。
違うって言わなきゃいけないのに言えなくて、どうしていいのかわからない。
友達は、何も言ってくれない。どんな顔してたのかも覚えてない。」
まあ、俺だって文化大革命の中に吊るし上げ食らってる友達を見たって
何も出来ないね。助けに行って殺されるのは人口に対して5%居ると言われる
お前さんは誰か助けたか？助けたからって助けてもらう権利なんかもらえないけどな。
javascriptで存在するほとんどのオブジェクトの実体はハッシュだよ。
var arr = [0,1,2,3];
とかをみると配列(人によってはリスト)に見えると思う。でも実際は違うんだ。
これは
var has = {0:0,1:1,2:2,3:3};
と基本的には等価なんだ。ただちょっと束縛されているメソッド(インターフェイス)が違うだけ。
ためしに
arr[4] = 4; arr['x'] = 'string'; arr[-1] = -1;
としてみよう。
Firebugで確認してみると[0, 1, 2, undefined, 4]というような値がかえってくるよ。
でもarr[-1]やarr['x']の値は保存されてないのかな？そんなことはないちゃんとアクセスできるんだ。
それどころかarr.xで'string'がかえってくるんだ。
別の例を見てみよう。
var fx = function(){}; fx[0] = 'somestring';
こうするとfx[0]に'somestring'が束縛される。
つまりfunctionも一つのハッシュだったんだ。
これでほとんどのものがハッシュだということが解ってくれたかな？
ハッシュじゃないのは文字列とか数字とかそいういシンプルなものだけなんだ。
ハッシュへはhash[name]でアクセスすることが出来る。
それ以外にもnameが演算子や空白を含まなくて頭が数字でない場合はhash.nameでアクセスできるんだ。
これでhash[name]が関数だったらhash.name(args)とできるよ。まるでメソッドみたいだね。
javascriptはレキシカルスコープを採用してるんだ。
var x = 'global';
var fx1 = function(){return x};
var fx2 = function(){var x = 'local';return x}
これの実行結果は以下になるよ。
fx1() -> 'global'
fx2() -> 'local'
fx1() -> 'global'
fx2の変数xはほかの場所に影響しないんだ。これは関数の中と外ではスコープが違うからなんだ。
でも以下のような場合に注意してほしい。
var x = 'global';
var fx1 = function(){return x};
var fx2 = function(){x = 'local';return x}
fx1() -> 'global'
fx2() -> 'local'
fx1() -> 'local'
fx2は自分のスコープに変数xがないからその外側スコープに探しに出かけたんだ。結果fx
つまり宣言文varはそのスコープに新しい名前を登場させる機能なんだよ。
関数宣言の書き方って次見たいの覚えてる人が多いんじゃないかな？
function funcname(args){ do something};
でもこれはsystax sugerだってことを知ってほしい。
上でも使ってるんだけど。
var funcname = function(args){ do something};
と等価になる。もちろんどちらの書き方でもかまわないよ。
関数は返り値として関数はハッシュを指定できるよ。次のハッシュを返す関数を見てみよう。
var fx = function(){ var x = 0; return { 'x':x, 'add1':function(y){this.x = this.x+y;return this.x}, 'add2':function(y){x = x+y;return x} } } var obj = fx();
実行結果を見てみよう
obj.x -> 0 obj.add1(0) -> 0 obj.add1(0) -> 0 obj.x -> 0 obj.add1(1) -> 1 obj.add1(0) -> 0 obj.x -> 1 obj.x -> 1 obj.add1(0) -> 1 obj.add1(2) -> 2 obj.x -> 1
となる。
add1はthis.xにたいして演算をしている。つまり返された値が変化しているんだ。
add2は関数fxに閉じ込められた値に対して演算している。つまりこれらは別の値なんだ。
とここまでかいたら疲れた。
読んでくれた人ありがとう
ちゃんとまとめてなかったし、自分のブログに描いても見てくれる人はいないから増田に書いてみたよ。
ほかの言語や技術についても同じような解説が欲しかったら何らかの方法で言及してくれるとうれしいな。
ここまではてブが300突破してるみたいだけどいま、自分のブログへリンクを張ったら増田に書く意味がなくなるんじゃないかと思うんだ。
やらないけど。
こんなのもかいてみたよ、増田で。 http://anond.hatelabo.jp/20070621153600
子供は刺激耐性が低く、バッファが小さいから、性情報のような刺激の強い情報を入れると頭の中がそれで飽和する。小さいうちは気付かないだろうが、単純記憶バッファの拡張とか演算速度とか、手先の器用さとか、ローティーン以前、つまり第二次性徴前に十分仕込んでおかないとあとで習得するのに非常に苦労する学習項目はいくらでもある。反面、性情報なんてものは、自分の身を守る方法だけを外挿的に覚えておけば十分ことが足り、あとは少々遅くても問題ない。
「私は大丈夫」という子供も中にはいる。しかしそれは外見で判断できない。同じような外見で大丈夫ではない（耐性のない）子供がほとんどだ。見た目でそれは判断できない。できない以上、年齢という客観情報で制限するよりなく、そしてそれは大丈夫な子供より大丈夫でない子供が優先的に保護されるべきである。自分が大丈夫だからといって、社会秩序のために、子供が公然と性情報に触れてみせるべきではない。
…というようなことを、子供にもわかるように噛み砕いて説いてくれ。ただし、説明を求められた場合のみで十分。