プログラミング言語は自然言語と本質から異なるのか

プログラミング 哲学

わたしは小説家になる以前、8年間ほどプログラマーとして働いていまして、こういう思考を始めると止まらないところがあります。コンピューター言語と小説の言語、自然言語は違うのか、という質問はよくされるのですが、これは本質的に異なります。プログラミング言語は人が機械を使役するためのものですから、すべてが命令形に則っています。

「～しろ」「～せよ」のみで、そこにコミュニケーションは存在しない。だから自然言語の対極の、さらに向こう側にあるとすら言っていいと思います。

だからコンピューターの言語が直接的に小説の言語に影響を及ぼすケースは考えにくいのですが、プログラマーとしての経験は、小説家としての自分に大いに役立っています。

http://wired.jp/2015/12/30/interview-yusuke-miyauchi/2/

命令もまたコミュニケーションの一形態であり、人間どうしのコミュニケーションとは大きく形態が異なるとはいえ、それが「本質的」差異だとはとても思えない。コンピューターというものが人間に使役される存在と見なされているにせよ、現に数多くのプログラミング言語には“対話型環境”が備えられてきたし、また、プログラムに誤りがあれば、機械は時に饒舌にそれを指摘してきた。人間どうしのコミュニケーションと形態こそ異なれども、そこにはある種のコミュニケーションが確かに存在していて、人間は機械と協働し、数多くのプログラムを作り上げている。

それに、プログラミング言語は命令形しか含まないという認識自体、正しくない。以前にも書いたが、〈プログラムとは命令文の並び〉という観点から行われるプログラミングは、数あるプログラミング観の一つに過ぎない。（プログラミングにおける〈式〉についての考察 - Ryusei’s Notes (a.k.a. M59のブログ)）論理型言語や関数型言語の系統を遡れば、分析哲学的な概念記述の試みにたどり着く。それは人間の言語を形式化したものであり、人間の営みとしての思考や計算の様式を記述するものだった。その流れを汲んでいるプログラミング言語は、確かに人間の言語と繋がりを持っているはずだ。

私は、プログラミング言語と自然言語を「本質的に差異のあるもの」として見るより「連続性を持ったもの」として見る言語観の方が好きだ。そして、その連続性を活用して、双方の言語の世界を広げ、あるいはコミュニケーションへの理解を深めていきたいと思っている。

〈式〉の考察 2

哲学 プログラミング

その1 ⇒ プログラミングにおける〈式〉についての考察 - Ryusei’s Notes (a.k.a. M59のブログ)

前回、式の望ましい性質として確定性・構成性・純粋性があるという話をした。これらの性質がなぜ望ましいのかを、実際に式を分析しながら詳しく見ていく。

式の構造

式は一般に、原子式と式の基本構造から再帰的に構成されている。

例えば、次の式1は、2つの式 ab, c (a + b)と、式の基本構造 \square + \squareから成り立っている。そして、各部分式もまた部分と基本構造に分解できる。

式1: a b + c (a + b)

式1の基本構造には次のものがある。

リスト1: 式1の基本構造

  • \square \square
  • \square + \square
  • ( \square )

リスト1は、式を構成する規則として見ることができる。すなわち、これらの基本構造の組み合わせで、さまざまな式を構成できるわけで、どのようなものが式であるかを決めるルールになっているということだ。

式の構成規則を構文という。構文に従って式を分解し、式の構造を明らかにすることを構文解析という。

式1を構文解析していくと、式1を構成する次のような式が得られる。

リスト2: 式1の部分式

  • a b + c (a + b)
  • a b
  • a
  • b
  • c (a + b)
  • c
  • (a + b)
  • a + b

構文解析の途中で得られた、元の式を構成する式を、部分式という。今後、部分式と言った時には、元の式自体も含めることにする。

また、部分式のうち、基本構造を使って1回分解して得られた部分式のことを、ここでは「直下の式」と呼ぶことにする。式1の直下の式は ab, c (a + b)の2つだ。

a, b, cのように、構文によってこれ以上分解できない式を、原子式という。

構文木

式1を構文解析した結果は、次の図1のように木構造として表現できる。この木構造を構文木と言う。

f:id:mandel59:20151129154749p:plain
図1: 式1の構文木

構文木の各ノードは、ある部分式と対応している。構文木の根は元の式と対応し、子ノードは直下の式と対応する。

曖昧な構文

式1は、 a b + cと (a + b)という式と \square \squareという基本構造からなりたっているとみて、図2のように構文解析することもできる。

f:id:mandel59:20151129160323p:plain
図2: 式1の別の構文木

構文解析の結果が1通りでない式がある構文を、曖昧な構文という。構文が曖昧だと、構文解析の結果次第で、式の意味が変わってしまうというようなことが起きる。それでは困るので、普通は構文解析の結果が1通りになるような規則が設けられている。そのような規則に、例えば、演算子の優先順位がある。今後、ここで扱う式は、数学における数式と同じルールで構文解析するということにする。

式の値の計算

式の構成性は、次の性質だ。（前回の記述から修正してある。）

構成性 (compositionality): 式の値は、式の基本構造の機能と、直下の式の値のみから一意に決定される。

基本構造の機能とは、基本構造が表している〈足し算〉や〈掛け算〉のような計算のことだ。

式に構成性がある場合、すべての原子式の値が分かっていて、基本構造の機能をすべて実際に計算できると、次の手続き1に従って式の値が計算できる。

手続き1: 式Eの値を計算する

  • 手順1: 式Eの部分式のうち、まだ値が分かっていない部分式の中から、その式の直下の式すべてについて値が分かっているような式を、どれでもいいので、1つ選ぶ。その式をE’とする。
  • 手順2: 式E’の直下の式の値と、基本構造の機能から、式E’の値を計算する。
  • 手順3: 式Eの値が分かるまで、手順1, 2を繰り返す。

基本構造の機能が計算できるというのは、たとえば \square + \squareの部分の機能は〈足し算〉で、それを実際に計算できるということを表している。

実際に、上の手順で次の式2の計算をしてみよう。

式2: 2 \times 3 + 4 \times 5

式2の部分式は、式2自体を含めて次のものがある。（構文解析は数学と同じルールと決めたので、 3 + 4などは部分式でないことに留意してほしい。）

  • 2 \times 3 + 4 \times 5
  • 2 \times 3
  • 4 \times 5
  • 2
  • 3
  • 4
  • 5

そのうち、原子式 2, 3, 4, 5は値が最初から分かっている。

手順1: 式2の部分式の中で、直下の式すべてについて値が分かっている式は 2 \times 3と 4 \times 5だ。ここでは 2 \times 3を選ぶとする。

手順2: 2 \times 3の直下の式の値 2, 3と基本構造の機能〈掛け算〉から、式の値を計算する。2と3を掛け算することで、 2 \times 3の値は 20だと分かる。

手順3: 同様に、 4 \times 5の値は 20だと分かる。すると 2 \times 3 + 4 \times 5の値も計算できて、6と20を足し算し、値は26だと分かる。

数式がどんなに複雑になっても、原理的には同じ方法で計算できる。もちろん、頭を使えばより効率的に計算することができる場合もあるが、とにかく機械的に式の値を計算することができる。

もし式に構成性がないと、手続き1は使えない。式の値が、直下の式の値と基本構造の機能だけから計算できないからだ。

プログラミングにおける〈式〉についての考察

プログラミング 哲学

「プログラムとは何か」という質問に対する、最も素朴な回答は「プログラムとは、機械に与える命令文の並びのことです」というものだ。命令文を解釈する機械が、プログラムに記された命令に従って、装置を制御し、計算処理を実行する。このようなことは、情報科学の基礎として学校で教えていると思う。

一方で、今日の高水準言語によるプログラミングでは、〈式〉という概念を理解していることがとても重要だ。特に、関数型プログラミングが注目されるようになった今日では、もはや単なる数式としての理解では十分でない。

しかし、プログラミング言語における〈式〉は〈サブルーチン〉や〈関数〉のような概念に比べると自明であるように思われているためか、あまり精緻な説明がなされないようだ。実際、Wikipediaにおける式 (プログラミング) - Wikipediaの記述の短さを見て欲しい。英語版であれば少しだけ記述が長いが、それでも十分な記述には程遠いものだろう。

プログラミングにおける〈式〉は、もっと語られてもいいはずだ。以下では、プログラミングにおける〈式〉の概念について、いくらか考察してみる。

プログラミング・パラダイムにおける式の観点の違い（概論）

以下、各プログラミング・パラダイムにおいて、式がどのような働きをしているかを考察する。各用語は、簡単な表現で説明できるように再定義しているため、巷での用法とは必ずしも一致しないことに注意を要する。「論理型プログラミング」や「関数型プログラミング」といった用語が、巷ではどのような意味で使われているかというのも興味深い話ではあるが、ここではその議論をしない。

命令型プログラミングにおける式

命令型プログラミングとは、〈プログラムとは命令文の並び〉という観点から行われるプログラミングのことだ。命令文を解釈する機械に命令を与えると、そのとおりに順次処理していくから、計算の仔細な手順（狭義のアルゴリズム）を、命令列によって与えれば、機械に計算を行わせることができる。

しかし、人間は大抵の場合、数学的な概念や計算を数式の形で記述ている。そのような数式を人間の手でアルゴリズムに変換するのは煩わしい。数式を与えると、その式の値を計算してくれる〈評価プログラム〉や、数式を与えると、その式の値を計算するための命令列を出力してくれる〈翻訳プログラム〉があると、楽で良い。〈プログラムとは命令文の並び〉という観点のプログラミング言語でも、高水準言語は当然のように〈数式〉を持っている。FORTRANの名の由来も「数式翻訳」“formula translation” だ。（FORTRAN - Wikipedia）

命令型プログラミングにおける式は、ポピュラーな数学におけるような、計算して値を求めるための数式だろう。

論理型プログラミングにおける式

命令型プログラミングが〈プログラムとは命令文の並び〉という観点でプログラムするが、論理型プログラミングは〈プログラムとは平叙文の集まり〉という観点でプログラムする。平叙文というのは、「今年の平均気温は昨年より1度高かった」だとか「晴れている日に軒先に何か洗濯物を吊るしておくと、その洗濯物は乾く」のような、世界に関する事実や法則を表現する文だ。これを論理式の形で表現したものを、表明 (assertion) という。

命令型プログラミングによるプログラムの実行方法は、ただ「実行せよ」という命令であるのに対し、論理型プログラミングによるプログラムは、疑問文の形をとる。たとえば「月曜日の掃除当番は誰ですか」というような疑問を、自由変項 (free variable) という、「誰」や「何」に相当する分からない部分を指す項を含んだ論理式の形で与える。この論理式を、ゴール (goal) という。そうすると、マシンはプログラムされている事実や法則と、数理論理学に基づいた汎用の推論アルゴリズムを使って、ゴールが成り立つような例を見つけ出し、「月曜日の掃除当番は お父さん です」のように疑問に回答するわけだ。

事実と法則を与えておくだけで疑問に答えてくれる、ということが実現できるなら、それは人工知能と呼べるのだけれども、論理型プログラミングで推論がうまくいくのは、ごく限られている場合だけだ。きちんと問題が解けるようにするには、推論アルゴリズムの性質を理解し、適切な形で知識と法則を与えなければならない。だから、論理型プログラミングは、ごく基本的な使い方をする分には難しくないが、高度な使い方をしようとすると、途端に難しくなる。

論理型プログラミングにおける式は、自由変項を含んだ論理式であり、これを充足する解を求めるためのものだ。

関数型プログラミングにおける式

命令型プログラミング、論理型プログラミングを「プログラムとは○○」の形で簡潔に表現してきた。その流れで、関数型プログラミングは〈プログラムとは関数の集まり〉という観点でプログラムすることだと定義する。（繰り返しになるが、世間一般の用法とずれることを厭わず、こう定義している。）

関数は式を抽象したものだ。ここで言う抽象とは、式の可変部分を仮引数 (parameter) によって表すような操作を指す。具体例を挙げると、 10 \times 4 + 2という式があるときに、これを抽象し、f(x, y) = 10 \times x + yという関数を抜き出すことができる。

この関数を使えば、元の式は、関数に実引数 (argument) を指定した f(4, 2)という式で表現できるし、また f(7, 5)という式で 10 \times 7 + 5という式を表現できる。

関数型プログラミングによるプログラムの実行は、関数を含む式の値を計算することだ。ここまでの説明だけでは、関数で複雑なプログラムを書くことが出来るということが想像しがたい。しかし、実践的な関数型プログラミングにおいては、式の値としてポピュラーな数だけではなく、より複雑な構造を持った数学的オブジェクトを扱うので、とても実用的で汎用的なプログラミング・スタイルとなっている。

より一般的な〈式〉概念の説明

ここでは、式とは何かをより包括的に考えられるように、一般的に通用する定義を与え、プログラミング言語における〈式〉概念について考察する。

式 (expression) とは、プログラムのうち、値 (value) を持つ部分を指す。

式の望ましい性質には、次のものがある。（各項目の見出しは、例によってここでの議論における命名であって、一般的な用語とは必ずしも一致しない。）

  • 確定性 (definiteness): 式の値は一意に存在している。
  • 構成性 (compositionality): 式の値は式の構造と部分式の値のみから決定される。
  • 純粋性 (purity): 式は式の値以外の意味を持たない。

確定性があることによって、式の意味が明確に定まる。純粋性と構成性があることによって、部分式を、同じ値を持つ別の式と交換しても、式全体の値や意味が変化しないと言える。このような性質は、式に接している時に暗に了解している性質だ。

しかし、これらの性質を満たしていない式も多く存在している。例えば、 \frac{0}{0}という式の値は不定で、確定性がない。System.currentTimeMillis()という式は評価される時刻によって値が決まるから、構成性がない。System.out.println("Hello")という式は、値以外に〈標準出力へ文字列“Hello”を出力する〉という意味を持ってしまっていて、純粋性がない。

あるプログラミング言語の式が確定性・構成性・純粋性を持たないとしても、式の値の考え方を変えると、これらの性質を持つようになる場合がある。たとえば、「 \frac{0}{0}という式の値は不定」とせず、「 \frac{0}{0}は〈不定値〉という値を持つ」と考えることで、言語の本質的な仕様を変えずとも、式に確定性を持たせることができる。場合によっては、言語全体で式の値についての考え方を大きく変えなければならない場合もあるが、この方法は大抵実践可能だ。更に言えば、文のように元来値を持たないプログラムの構成要素に対しても、値を与えることで式にできる。

文のような、本来値を持っていない構成要素を式にできる、と言われても、抵抗があるだろうと思う。なぜ抵抗があるかというと、文の値を考え、文を式とした場合、言語の本質的な仕様を変えないという前提の下では、本来文だった式とそうでない式との間で、不公平な仕様が残る場合があるからだ。具体的には、もとの言語の仕様が「式の値は変数に代入できるが、文には値がないので代入できない」という仕様であったとすると、文に値を与えたところで、本質的な仕様の変更なしには、文は相変わらず変数に代入可能ではないままだからだ。しかし、「式の値は変数に代入可能であるべきだ」のような、個々の言語において望ましいとされている性質は、ここでは議論せず、まずは上記の3つの性質に絞って議論したいと思う。

つづく。

Everybody Loves Somebody

プログラミング

述語論理に限定継続を追加して、everybodyやsomebodyを表す項を作ってみる。

以下、{\bf C}, \langle \cdot \rangle はそれぞれ shift0, reset0 とする。

{\displaystyle e = {\bf C}k. \forall x. k \hookleftarrow x \\ s = {\bf C}l. \exists y. l \hookleftarrow y }

{\displaystyle \langle L(e, a) \rangle \\ = \langle L( ({\bf C}k. \forall x. k \hookleftarrow x), a ) \rangle \\ \leadsto \forall x. \langle L( \square, a ) \rangle \hookleftarrow x \\ \leadsto \forall x. \langle L( x, a ) \rangle \\ \leadsto \forall x. L( x, a ) }

{\displaystyle \langle L(a, s) \rangle \\ = \langle L( a, ({\bf C}l. \exists y. l \hookleftarrow y) ) \rangle \\ \leadsto \exists y. \langle L( a, \square ) \rangle \hookleftarrow y \\ \leadsto \exists y. \langle L( a, y ) \rangle \\ \leadsto \exists y. L( a, y ) }

同時に複数使うと、引数を右から評価するか左から評価するかで継続が異なるため、結果が一意にならず、英語の表現と同様に曖昧になる。

左から評価すると：
{\displaystyle \langle L(e, s) \rangle \\ = \langle L( ({\bf C}k. \forall x. k \hookleftarrow x), ({\bf C}l. \exists y. l \hookleftarrow y) ) \rangle \\ \leadsto \forall x. \langle L( \square, ({\bf C}k. \exists y. k \hookleftarrow y) ) \rangle \hookleftarrow x \\ \leadsto \forall x. \langle L( x, ({\bf C}k. \exists y. k \hookleftarrow y) ) \rangle \\ \leadsto \forall x. \exists y. \langle L( x, \square ) \rangle \hookleftarrow y \\ \leadsto \forall x. \exists y. \langle L( x, y ) \rangle \\ \leadsto \forall x. \exists y. L( x, y ) }

右から評価すると：
{\displaystyle \langle L(e, s) \rangle \\ = \langle L( ({\bf C}k. \forall x. k \hookleftarrow x), ({\bf C}l. \exists y. l \hookleftarrow y) ) \rangle \\ \leadsto \exists y. \langle L( ({\bf C}k. \forall x. k \hookleftarrow x), \square ) \rangle \hookleftarrow y \\ \leadsto \exists y. \langle L( ({\bf C}k. \forall x. k \hookleftarrow x), y ) \rangle \\ \leadsto \exists y. \forall x. \langle L( \square, y ) \rangle \hookleftarrow x \\ \leadsto \exists y. \forall x. \langle L( x, y ) \rangle \\ \leadsto \exists y. \forall x. L( x, y ) }

以下、Racketでの実装。

#lang racket
(require racket/control)

(define (forall x f) (if (null? x) #t (if (f (first x)) (forall (rest x) f) #f)))
(define (exists x f) (if (null? x) #f (if (f (first x)) #t (exists (rest x) f))))

(define (every x) (shift0 k (forall x k)))
(define (some x) (shift0 k (exists x k)))

(reset0 (even? (every '(10 20 30))))
(reset0 (even? (every '(10 20 5))))
(reset0 (even? (some '(5 7 9))))
(reset0 (even? (some '(5 7 10))))

0の0乗

数学 哲学

はてなブックマークで、0の0乗についての記事がホットエントリーになっていた。

0の0乗の正解がネット検索しても見つからないので作成した。 | 子育ての達人 | 妊娠・出産・育児・子育ての毎日を楽しく

「いろんな言い分は多々見受けられましたが、正しい解答に言及しているサイト（ページ）は見つからなかった」というが、この記事自体に問題があると感じた。しかし、色々考えたけれども、あまりうまくまとめることができなかった。とりあえず、考えたことを以下にメモとして残しておく。

この記事では、一方で「なぜ2の0乗は1になる」と問うておきながら、マイナス乗については、「定義は定義としてすんなり受け入れなければいけません」と主張している。これはチグハグだ。

定義というのは、そこからの議論を厳密に行うために必要なものだ。数学で議論の対象になるもの（「数学的対象」という）は、無数に存在している。互いに似通った対象が多数存在するわけだから、数学では議論を始める前に定義を行い、どの言葉がどの対象を指しているかを決めておかなければならない。そうして、決めておいた定義や公理から推論して、様々な定理を導き出す。これが純粋に数学な議論だ。

「定義は定義としてすんなり受け入れなければいけません」という話は要するに「数学は定義が与えられて初めて議論が始められる」ということだ。マイナス乗をa^{-x} := \frac{1}{a^x}と定義するように、ゼロ乗もa^0 := 1 ~ (a \neq 0)などと定義して、数学的な議論を始めることができる。

しかし、件の記事の議論は違う。

累乗の説明が終わったので0乗の説明に行きます。ここまで来ると簡単です。

2^0=2^{1-1}=2^1 \times 2^{-1}=2/2=1

つまり、2の0乗というのは2/2（2÷2）なので1なのです。

例として2で進めましたが2以外の数でも同じです。従って、0の0乗とは、0/0（0÷0）のことです。

明らかに、これは定義から推論して法則を導き出す数学的な証明ではない。指数法則が成り立つように、a^0 := \frac{a}{a}と定義したいという、定義の動機の話だ。

「なぜ2の0乗は1になるか」「なぜ0の0乗は未定義になるか」という問いは、2通りに解釈できるということでもある。数学で「なぜPか」と言ったら、普通は「なぜPか、Pを証明して示せ」ということを意味している。しかし、2^0の定義がないうちには、「2^0 = 1を証明せよ」という純粋に数学的な問いは成り立たない。「なぜPか」という文のもう1つ、「なぜ数学者は（数学では）Pが成り立つような定義を採用するのか」を意味するだろう。これは数学者の動機の問題で、純粋に数学的な問題ではないし、コンセンサスも存在しない。

付録: なぜ私は2^0 = 1となるような定義を採用するのか

「定義の理由」にコンセンサスがあるわけではないけれども、「冪乗」と「指数関数」を使い分けて説明すると、理由を納得しやすいと思う。

掛け算の繰り返しで定義されている冪乗a^xには指数法則a^{x + y} = a^x \cdot a^yが成り立つ。一方で、別の方法で定義されている*1指数関数\exp_a xにも、指数法則\exp_a(x + y) = \exp_a{x} \cdot \exp_a{y}が成り立つ。xが正の整数であるときには指数関数と冪乗は一致し、\exp_a x = a^xとなる。だから、数学では多くの場合指数関数を冪乗と同じ記法で表しているし、同一視することもある。
この説明は、\exp_2 0 = 2^0 = 1となる理由を説明できるが、高校数学の範囲での指数関数は、底が0 < a \land a \neq 1の範囲でしか定義されていないから、0^xや1^xの定義には、別の説明が必要になる。考えが変わったので、取り消す。11月23日

定義の理由の理解がどのようであれ、定義自体が共有されているのであれば、数学的な議論を行う上で問題はない。

付録: 基数における冪の定義

濃度 (数学) - Wikipedia

集合Aの濃度を\#Aと書き、集合A, Bをそれぞれドメイン、コドメインとする写像の集合を{\rm Map}(A, B)と書く。基数 (cardinal number) a, bの冪はa^b := \#{\rm Map}(b, a)と定義され、この定義の下では0^0 = \#{\rm Map}(\emptyset, \emptyset) = 1となる。

*1:指数関数の定義は同値の定義が複数存在している

RDFa Liteのここが酷い

プログラミング

RDFa LiteはRDFa Coreのサブセットで、とても短い仕様なのだけれども、一点気に入らない。

なぜ、@aboutではなく@resourceを採用したのか。

RDFa 1.1 Primerによれば、@aboutと@resourceの違いは、同じ要素に@propertyが設定されている場合の意味の差だけだ。どう違うかというと……

  • @aboutは、いつでも関係の主体 (subject) を設定する。
  • @resourceは、@propertyが設定されていない場合は@aboutと同様関係の主体を設定する。@propertyが設定されている場合は@hrefと同様関係の客体 (resource object) を設定する。（ただし、hrefと違って、クリックできないリンクになる。）

属性名からも明らかなように、RDFa Coreの@resourceはリソースオブジェクトを設定するのが主用途だ。@propertyが設定されていない場合の意味は、「ついで」で決められていることに過ぎない。*1（これ自体センスがない仕様だ。意味が無い指定であれば未定義として残しておけばいいのであって、無理やり@aboutと同義にする必要がない。）

@resourceの唯一の意義であった「@hrefと違って、クリックできないリンクになる」という性質だって、今日のHTMLの仕様と組み合わせるのであれば、a要素の代わりにlink要素を使えば達成できるのだから、いよいよ@resourceの存在意義は無い。

@aboutを捨てて@resourceの方を選ぶというのは、全くセンスがない。他の属性が設定されているかどうかによって意味が変わる属性とか、ありえない。@propertyと@resourceを同じ要素に設定する“間違い”をしでかす人間は必ず出てくるし、仕様を策定する人間にセンスがないと、全世界に迷惑を掛ける。RDFa 1.1 Primerにその“間違い”を例示するぐらいだったら、最初から@aboutをプライマリとして採用してくださいよ。

*1:追記: subject、object両方とも、URIで指定されるのはresourceであり、resourceという名前がobjectを指しているという指摘は不当なので取り消す。しかし、場合によってsubjectの指定であったりobjectの指定であったりすることの筋の悪さに変わりはない。

schema.org/URLってダメ

プログラミング

（Poor schema.org/URL - Ryusei’s Notes (a.k.a. M59のブログ)の雑な日本語訳。というか、原文が雑な英語すぎるし、まとまってない。）

schema.org/URL というデータ型が定義されているんだけど、これって酷いよね。「この属性のデータ型って何？」「URL。」って、答えになってないじゃん。

URLってのは、単なる識別子だよ。これはURLだなんて分かってる。ウェブにあるモノってのは、だいたいそれを指すURLを持ってる。知りたいのは、それがURLってことじゃなくて、そのURLが指しているモノの型が何なのかってことなんだから。

URLは、schema.org/Textのサブタイプであるべきじゃない。ハイパーリンクとして指定されているURLは、モノがある場所として解釈されるべきで、URLそれ自体がモノとして解釈されるべきではない。

Poor schema.org/URL

プログラミング

schema.org/URL is one of data types defined for linked data. I hate it, because it is totally useless. “Hey, what is the data type of this attribute?” “URL.” That is nonsense.

An URL is just an identifier. That is URL, I know. Almost every thing on the web have an URL that denotes it. What I want to know is the data type of the thing that the URL stands for.

URL should not the subtype of schema.org/Text. The URL specified for a property as hyperlink should be interpreted as the location that the thing is. Not be the URL itself the thing.

ソースコードは基本設計図か

プログラミング

www.nikkei.com

用語ミニ解説として、オープンソースが「基本設計図である「ソースコード」が公に開示されているソフト」と解説されているのだけれども、ソースコードは基本設計図なのだろうか。

基本設計図というのは建築における用語だ。建築では、設計図には基本設計図と実施設計図とがある。建築工事に必要なのは、実施設計図だ。www.homes.co.jp

建築における基本設計図とソフトウェアにおけるソースコードの間には、重大な差異がある。基本設計図の段階ではまだ建物は建てられないのに対して、ソースコードは既にビルドできる状態のもので、ビルドすれば実働するソフトウェアが得られるという点だ。建築にたとえるなら、ソースコードはすでに「建築工事」に回せる段階のものだから、これはむしろ「実施設計図」に相当する。

コメント欄についてのコメントまとめ

哲学

Twitterのツイートをまとめました。

2012年


2014年1月17日

NATROMの日記のコメント欄が承認制になった時のコメントです。











2015年1月6日

Qiitaというウェブサイトのコメント欄が荒れた時のコメントです。

2015年7月28日

またQiitaのコメント欄が荒れていました。その時のコメントです。






2015年8月5日

コメント欄について議論する分野はどこなのかについての疑問です。



望ましいコメント欄の姿はなんだろう。

哲学

この記事は、イケダハヤト氏の記事に反応して書かれたものだ。コメント欄について、私は過去にもいくらか考えてきた。Twilogからコメント欄についてのコメントを拾い、あらためて自分の意見を確認した。

www.ikedahayato.com

この記事ではコメント欄を閉鎖する理由を「ゴミの掃き溜めです」、「建設的ではありません」と、説明している。一方で、「サイトコンテンツを拡充するという観点では、コメント欄は本来的には有意義」とも書いている。前者は、コメント欄につくコメントは無価値であると言っていて、しかし、後者はコメント欄が本来的に有価値であることを訴えている。

私もブログのコメント欄は閉鎖したほうがよい場合があると考えているが、それはコメント欄にゴミのようなコメントしか付かないから、議論が建設的でないから、といった理由ではない。だいたい「ゴミのような」だとか「建設的でない」のような判断は主観的な価値判断に過ぎないもので、ゴミのようなコメントが付いたり、建設的でない議論が繰り返されること自体から、何らかの意味を見出すこともできる。ゴミのようなコメントが付くコメント欄は十分有意義で、ただ記事の著者にとっては不都合・不愉快である場合があるというだけだ。

私が撤去したほうが良いと考えるコメント欄には、個々のコメントの管理の問題と、話題の管理の問題がある。

個々のコメント管理の問題というのは、社会的に問題のある発言を削除しなければならないということだ。もしコメント欄の管理を記事の著者自身で行っていると、コメント投稿者に、記事の著者にとって都合の悪い発言や反論が不当に削除・検閲されているのではないかという疑念を抱かせてしまう。最初から外部のサービスにコメント管理を委譲してしまい、著者自身で管理できないようにしてしまえば、著者は他人のコメントに何ら責任を負う必要がなく、とても気楽だ。

話題の管理の問題というのは、コメント欄が荒れることだ。はてなブログのコメント欄のように、コメントが一列のリストになっている場合、コメント欄の荒れが問題になりやすく、荒らしに脆弱だ。コメント欄が荒れて機能不全を起こすのは「記事に対するコメント」と「コメントに対するコメント」が区別されていないからで、スラドのようにツリー構造のコメント欄であれば、ツリーごとに異なる話題を続けられるから、ひとつの枝が荒れていても、他の枝に影響しづらい。あるいは、ツイッターのように、コメントどうしが勝手に参照しあうような構造でもよい。ツイッターのような構造は議論には向かなくなり、よりコメントらしい使い方になる。はてブのように、コメント量を制限しても、荒れることはない。

そういうわけで、撤去せずとも良いコメント欄は次の性質を持つ。

  • 著者自身が管理できない。個別のコメントの削除はコメントした人自身か、コメントサービス提供者が行う。記事の著者が他人のコメントに責任を負ってはいけない。
  • コメント欄の話題が1つにロックされない。複数の話題を持てるツリー型や、話題が存在しないツイート収集型、コメント量を制限するブックマークコメント型などにする。

Facebookコメント、Twitterの検索結果タイムライン、そしてこのブログにあるような、はてブコメント欄のどれも、この性質を満たしている。あとはコメント欄をブログに埋め込むかどうかは個々人の“衛生観念”の差で決まるもので、自分に対して批判的なコメントを読むのは精神に悪いからコメント欄を設置しないというのも、別にいいのではないかと思う。

CSSでヒラギノ角ゴシックのウェイトを指定する方法

※追記あります

Mac OS X El Capitanのヒラギノ角ゴシック — Medium

ヒラギノ角ゴシックは10ウェイトあるが、CSSでは9つ（100から900まで100間隔）でしか指定できない。しかも、具体的にどのウェイトで表示されるかが、ブラウザによって異なっているようだ。

f:id:mandel59:20151003203853p:plain:h411

font-weightと実際に使われるウェイトの対応の表:

CSS font-weight Firefox Chrome
100 W0 W0
200 W2 W1
300 W3 W3
400 W4 W4
500 W5 W5
600 W6 W6
700 W7 W7
800 W8 W8
900 W9 W9

また、normalとboldはそれぞれ400と700を指定するのと同じなのだが、今までのヒラギノ角ゴではW3とW6を使ってきたのだから、これでは少し太いかもしれない。こういう時は、@font-faceを使って、ウェイトと実際に使われるフォントの関係を直接指定してしまえばいい。

@font-face {
  font-family: "Hiragino Sans";
  src: local(HiraginoSans-W0);
  font-weight: 100;
}
@font-face {
  font-family: "Hiragino Sans";
  src: local(HiraginoSans-W1);
  font-weight: 200;
}
@font-face {
  font-family: "Hiragino Sans";
  src: local(HiraginoSans-W2);
  font-weight: 300;
}
@font-face {
  font-family: "Hiragino Sans";
  src: local(HiraginoSans-W3);
  font-weight: 400;
}
@font-face {
  font-family: "Hiragino Sans";
  src: local(HiraginoSans-W4);
  font-weight: 500;
}
@font-face {
  font-family: "Hiragino Sans";
  src: local(HiraginoSans-W5);
  font-weight: 600;
}
@font-face {
  font-family: "Hiragino Sans";
  src: local(HiraginoSans-W6);
  font-weight: 700;
}
@font-face {
  font-family: "Hiragino Sans";
  src: local(HiraginoSans-W7);
  font-weight: 800;
}
@font-face {
  font-family: "Hiragino Sans";
  src: local(HiraginoSans-W8);
  font-weight: 900;
}
@font-face {
  font-family: "Hiragino Sans W9";
  src: local(HiraginoSans-W9);
  font-weight: 900;
}
div {
  font-family: "Hiragino Sans";
  font-size: 20pt;
  line-height: 1.5em;
}

<div style="font-weight: 100">ヒラギノ角ゴシック W0</div>
<div style="font-weight: 200">ヒラギノ角ゴシック W1</div>
<div style="font-weight: 300">ヒラギノ角ゴシック W2</div>
<div style="font-weight: 400">ヒラギノ角ゴシック W3</div>
<div style="font-weight: 500">ヒラギノ角ゴシック W4</div>
<div style="font-weight: 600">ヒラギノ角ゴシック W5</div>
<div style="font-weight: 700">ヒラギノ角ゴシック W6</div>
<div style="font-weight: 800">ヒラギノ角ゴシック W7</div>
<div style="font-weight: 900">ヒラギノ角ゴシック W8</div>
<div style="font-family: 'Hiragino Sans W9'">ヒラギノ角ゴシック W9</div>

f:id:mandel59:20151003204830p:plain:h410

10月4日追記

上の方法だと、Firefoxでは正しく表示されるが、SafariやGoogle Chromeだと、W5が正しく表示されない。
f:id:mandel59:20151004131621p:plain:h406 Safariでの表示
本来boldでないW5にfont-weight: 600を指定していると、機械的にboldになってしまうようだ。
やはりfont-weightを使わず、直接指定するのが無難だろう。

指定例: A Pen by Captain Anonymous

GMailのリプライをスレッドにまとめる機能は完全にダメ

GMailのアプリは関連するメールを一つにまとめる機能があるけど、この仕様を把握していないせいで完全に失敗した。メールに新規の未読のリプライが付いても、それは既読のメールの下に表示されるわけで、これじゃあ未読のリプライの内容を読み逃してしまうに決まっているじゃないか。なんでこんな仕様なんだ。

f:id:mandel59:20151001142047p:plain

https://support.google.com/mail/answer/5900?hl=ja

■

人力検索はてなの質問をキャンセルしたら内容が消えてしまったので、こちらに残しておく。

昔読んだ数学の児童書を探しています。 内容は断片的にしか覚えていません。おそらく12年以上前に図書館で読んだ本です。 小説仕立ての本であり、ワープロのフロッピーディスクに、奇妙な外字で書かれた文書が保存されていて、それはコンピューターに住む未知の生命体の残した、未知の数学に関するメッセージだったというような話だったように思います。いくつかのトピックがあったと思いますが、そのひとつとして、p進数（p-adic number）に関連するようなトピックがありました。もしかしたら、大きめの判型の本で、上下で2冊分の本だったかもしれませんが、確かではありません。 少ない情報ですが、心当たりがあるかたはよろしくお願いします。

http://q.hatena.ne.jp/1443281726

www.amazon.co.jp

www.amazon.co.jp

ありがとうございました。