「The Philosophy of Computer Science」 翻訳

原文：https://stanford.library.sydney.edu.au/entries/computer-science/

スタンフォード哲学大辞典のページの翻訳です。いつか要約します。

コンピューター科学の哲学

コンピュータ科学哲学は、コンピュータ科学の学問分野やソフトウェア開発の実践から生じる存在論（オントロジー）的、方法論的、倫理的な問題に関心を持っています。そして、コンピュータ科学哲学は、数学の哲学や生物学の哲学や社会科学の哲学のような科学哲学の多くのサブフィールドと同じ哲学的な目標を共有しています。また、コンピュータ科学哲学は、計算機の人工物、つまり人間が作った計算機システムの分析を行い、その設計、仕様、プログラミング、検証、実装、テストに関わる方法にも焦点を当てています。コンピュータプログラムの抽象的な性質と、その結果として実装される人工物の複雑さは、コンピュータ科学の技術的な野望と相まって、コンピュータ科学哲学の概念的な問題の多くが、数学哲学、経験科学哲学、技術哲学に類似したものであることを確実にしています。その他の問題は、計算機科学の哲学を特徴づけるものでしかありません。ここでは、コンピュータ科学哲学の骨格となっている3つの関連性の高いトピックに焦点を当ててみたいと思います。第一に、以下の第1節から第5節では、計算機科学の成果物のオントロジー的分析に関連した話題を取り上げます。第二に、ソフトウェア開発の方法論と認識論に関わる話題について、以下の第6節から第9節で議論します。第三に、コンピュータ科学の実践から生じる倫理的な問題について、以下の第10節で議論します。第11節では、コンピュータ科学の応用について簡単に考察します。

1. コンピュータアーティファクト

コンピュータアーティファクトは、私たちのFacebookページを支え、世界中の航空交通を制御し、雪が降っても驚かないように働きます。これらは代数学、自動車製造、レーザー手術、銀行、ガストロノミー、天文学、占星術などに応用されています。実際、それらの応用によって、根本的に変化し強化されていない生活の分野を見つけるのは難しいです。しかし、応用されているのは何でしょうか？そのような応用に実体を与えるものとは何でしょうか？簡潔な答えは、コンピュータ科学者が構築した実体、コンピュータ科学の成果物、いわば計算の成果物です。コンピュータ科学の哲学の多くは、その性質、仕様、設計、構築に関係しています。

1.1 二元性

昔から、計算の成果物はハードウェアとソフトウェアの2つの陣営に分類されると言われています。おそらくソフトウェアにはコンパイラや自然言語理解システムが含まれ、ラップトップやタブレットがハードウェアであるのに対して、ソフトウェアにはコンパイラや自然言語理解システムが含まれます。しかし、この区別はどのように行われているのでしょうか。私たちがソフトウェアとみなすものとハードウェアとみなすものをどうやって区別するのでしょうか？

標準的な方法では、この区別を抽象的なものと物理的なものとして識別しますが、残念ながら、これは正しくないようです。Moor (1978)が指摘しているように、この抽象的な特徴付けの下では通常はソフトウェアとみなされるが、実際のプログラムは物理的なデバイスである可能性もあります。特に、プログラムはかつて、物理的なレバーの引きや押しのシーケンスで識別されていました。この観察に対する反応は様々です。いくつかは、区別がないことを示唆しています。特に、Suber (1988)は、ハードウェアはソフトウェアの特殊なケースであると主張し、Moor (1978)は、その区別は存在論的に重要ではないと主張しています。一方、Duncan (2011) は、重要な違いはあるが、それは単純な抽象物理的なものよりも細かい区別をサポートする存在論的な枠組みの中でのみ可能なものであると主張しています(例: B. Smith 2012)。Irmak(2012)も、ソフトウェアとハードウェアは異なるものであると次のように考えています。「ソフトウェアは抽象的な人工物であるが、時間的な性質を持っているため、どうやら標準的なものではないようだ。」

ソフトウェアとハードウェアの区別を実質的なものにすることができるかどうかは別として、プログラムは抽象的なものとして捉えることができるが、物理的な操作のシーケンスとしてキャッシュアウトされることもあるという点では、ほとんどの作家が同意しています。その結果、彼ら(例えば、Colburn 2000; Moor 1978)は、プログラムは抽象的なものと物理的なものの両方を持つという二重の性質を持っていると主張しています。実際、一旦このことが認められると、それは大多数のコンピュータアーティファクトに適用されるように思われます。

ただ一方で、抽象的な装いをしているために、物理的な表現とは無関係に、それらについての考察や推論を可能にしているように思えますし、これは確かに抽象データ型にも当てはまります(Cardelli & Wegner 1985)。例えば、リスト抽象データ型は、キャリア型とリストの形成と操作をサポートする操作から構成されています。明示されていなくても、これらの操作は、その特性を固定化するいくつかの公理によって決定されます。例えば、リストの先頭に要素を追加して新しいリストを形成し、その後先頭を削除すると、古いリストが返されます。同様に、抽象スタックは、プッシュ操作とポップ操作を制御する公理によって決定されます。このような性質を使えば、具体的な実装とは無関係に、数学的な方法でリストやスタックについて推論することができますし、その必要は大きいです。このような推論なしにはプログラムを設計することはできませんし、プログラムで何をしようとしているのかを推論せずに正しいプログラムを構築することはできません。もしこれが正しいとすれば、コンピュータアーティファクトは、物理的な実現や実装とは切り離された抽象的な装いを持っていることになります。実際、物理的なものについての推論をサポートするために抽象的な装置を用意しなければならないというこの要件は、コンピュータ科学に特有のものではありません。

一方で、それらは物理的な世界のものとして使用できるような物理的な実装を持っていなければなりません。これは機械にも明らかに当てはまりますが、プログラムにも同様のことが言えます。プログラマーは物理的なデバイスを制御するためのプログラムを書きます。物理的に実現されていないプログラムや抽象的な機械は、人間の手に負えない計算を行うための実用的な装置としては、ほとんど意味がありません。例えば、心拍数を監視するプログラムは、実際にタスクを実行する物理デバイスに支えられていなければなりません。コンピュータ科学者のダイクストラは次のように述べています。

プログラマーは、機械的な実行を意図したアルゴリズムを設計し、既存の、あるいは考えられるコンピュータ装置を制御することを意図している。(Dijkstra 1974: 1)

二元論では、コンピュータ科学は物理世界から独立した抽象的な数学的な学問ではありません。使用されるためには、これらのものは同時に物理的な実体を持たなければなりません。そして、この観察がなされると、技術哲学の中心的な概念（Kroes 2010; Franssen et al.）と明確にリンクします。

1.2 テクニカルアーティファクト

テクニカルアーティファクトには、トイレ、ペーパークリップ、タブレット、犬の首輪など、日常生活でよく使われるものがすべて含まれます。それらは意図的に生産されたもので、このことは、テクニカルアーティファクトであることの本質的な部分です。例えば、偶然に算術を行う物理的な物体は、それ自体が電卓ではありません。このようなテレロジカルな側面が、他の物理的な物体との違いであり、哲学者たちは、テクニカルアーティファクトは、機能的特性と構造的特性という 2 つの特性によって固定された二重の性質を持っていると主張するようになりました（例：Kroes 2010; Meijers 2001; Thomasson 2007; Vermaas & Houkes 2003）。

機能的特性とは、人工物が何をするかということです。例えば、やかんはお湯を沸かすためのものであり、自動車は移動のためのものです。一方、構造的特性は、その物理的構成に関わるものです。これは、重量、色、大きさ、形状、化学的性質などです。例えば、「私たちの車は赤い車で、白いシートが付いている」などということです。

テクニカルアーティファクトの概念は、コンピュータ科学の哲学における中心的な疑問や問題のいくつかを概念化し、整理するのに役立つでしょう。私たちは、それらの活動の多くを支えている概念、つまり、機能的特性の最初の表出から見ていきます。

2. 仕様と機能

コンピュータ科学では、アーティファクトの機能は最初に（機能的な）仕様書の中に示され（Sommerville 2016 [1982]; Vliet 2008）、実際、最終的なデバイスに至るまでの過程で、抽象度の異なる一連の仕様とアーティファクトのペアが存在します。仕様、実装、および正しさの活動は、重複する概念的な疑問と問題の集合を提起することになります(B.C. Smith 1985; Turner 2011; Franssen et al. 2010)。

2.1 定義

仕様書は、日常的な言葉を含めて様々な方法で表現されています。しかし、コンピュータサイエンスのトレンドは、より形式的で正確な表現へと向かっています。実際、主にプログラム仕様のために設計された言語（VDM, Jones 1990 [1986]; Z, Woodcock & Davies 1996; B, Abrial 1996; B, Abrial 1996）やUML（Fowler 2003）のような広い範囲の言語から、アーキテクチャ記述を目的とした専門的な言語（Rapide, Luckham 1998; Darwin, Distributed Software Engineering 1997; Wright, Allen 1997）まで、専門的な言語が開発されてきました。これらは、その基礎となるオントロジーと要件を明確にする手段が異なります。

Z は述語論理と集合理論に基づき、主に、個々のプログラムモジュールや単純なデバイスの仕様の組み合わせとして使用されています。UML（Fowler 2003）には、非常に豊富なオントロジーと多種多様な表現メカニズムがあります。例えば、クラス言語では、ソフトウェアのパターンを指定することができます（Gamma et al）。 一般に、アーキテクチャ記述言語は、ソフトウェアシステムのアーキテクチャを正確に指定するために使用されます(Bass et al. 2003 [1997])。典型的に、これらの言語は、コンポーネント、コネクタ、インターフェース、構成などの概念を含むオントロジーを採用しています。特に、Rapide、Darwin、またはWrightで書かれたアーキテクチャの記述は、基礎となる数学的意味論を使って定義された形式論の中で正確に表現されています。

しかし、これらの言語の表現の論理的な機能とは何でしょうか？一見すると、それらは形式言語の表現にすぎません。しかし、基礎となるオントロジーが明示されると、これらの言語のそれぞれは、それ自体が形式的なオントロジーであることを明らかにし、型論として自然に問うことができるかもしれません(Turner 2009a)。この解釈では、これらの表現は規定的な定義です(Gupta 2012)。このように、それぞれの表現は、そのシステムの形式的オントロジーの中で新しい抽象オブジェクトを定義します。

2.2 仕様としての定義

しかし、定義はそれ自体が何かの仕様である必要はなく、数学的な探求の一部を形成しているだけかもしれません。では、定義はいつ仕様書として機能するのでしょうか？おそらく、定義がそれ自体を超えて人工物の構築を指すように取られた場合です。単なる定義を仕様書に変えてしまうのは、デバイスやシステムの特性に対して定義の統治権を与えるという意図的な行為です。そして、定義は、デバイスやシステムが正しく構築されているかどうかを決定し、正しさと誤動作の基準を提供すします。この観点から、仕様の役割は規範的なものです。デバイスが動作するかどうかを問う場合、デバイスが動作するかどうかを教えてくれるのは、仕様書として機能する定義であり、実際、定義がなければ、その質問は無意味でしょう。抽象化のどのレベル（§8.1参照）でも、正しさと誤動作の基準を提供するという仕様の論理的な役割は常に同じです。これは、Turner (2011)が主張している視点です。実際、この規範的な役割は、機能の一般論の一部であると考えられています(Kroes 2012)。

これが理想論であることは言うまでもありません。仕様書は、設計と構築のプロセスを通して固定されているわけではないためです。クライアントが要件を変更すると、それは変更されなければならないかもしれません。さらに、様々な理由で途中でアーティファクトを作ることが不可能であることが判明することもあります。根底的な物理法則が問題を阻止していたり、構築を妨げるコストの制限があったりするかもしれません。加えて、基礎となる定義が論理的に不条理である場合もあります。このような場合には、現行の仕様はあきらめざるを得ません。しかし、それでも仕様書の中心的な規範的役割はそのまま残っています。

機能記述とは異なり、仕様書はアーティファクトの構築に先立って規定されていると考えられています。このことは、仕様書のより実質的な役割、すなわち成果物を構築するための方法を提供することを示唆していると受け取られるかもしれません。しかし、成果物に到達するための方法は、その仕様とは別の問題です。仕様にはそのような方法は含まれず、機能的仕様と機能的記述はどちらも正しさの基準を与えるという意味で論理的な違いはありません。

2.3 抽象的アーティファクト

ソフトウェアは、抽象度が低下する一連の層で生産され、初期の層では仕様と成果物の両方が抽象化されています（Brooks 1995; Sommerville 2016 [1982]; Irmak 2012）。例えば、論理的記法で書かれた仕様書は、言語プログラムの仕様書と見なされるかもしれません。さらに、その言語プログラムは、それに関連するセマンティクスとともに、物理デバイスの仕様と見なされるかもしれません。言い換えれば、抽象的な実体をアーティファクトとして認めるということです。これがソフトウェア開発の特徴です（Vliet 2008）。これは、一般的な技術とは区別されますし、ソフトウェア開発において抽象的な中間アーティファクトの導入は不可欠です（Brooks 1995; Sommerville 2016 [1982]）。それらがなければ、論理的に複雑なコンピュータアーティファクトを構築することは不可能となります。

では、二元論はどうなるのでしょうか？それは今でも健在ですが、構造記述は必ずしも物理的な特性を提供するのではなく、別の抽象的なデバイスを提供するようになりました。例えば、抽象的なスタックは、より具体的なものの仕様として機能することができますが、それは現在、プログラミング言語で配列として構造記述が与えられています。しかし、配列はそれ自体は物理的なものではなく、抽象的なものです。その構造記述は物理的な性質ではなく、抽象的なもの、つまり公理を使っています。もちろん、最終的には、配列は物理的なストアに実装されることになりますが、配列をデータ型とするプログラミング言語でスタックを実装しようとしている実装者の立場からすると、ファーティファクトはプログラミング言語の抽象配列です。したがって、二元論は抽象的なアーティファクトを可能にするために一般化されなければなりません。

2.4 機能の理論

私たちの世界の物理的な概念化と意図的な概念化がどのように関連しているのかは、哲学における心と体の問題の長い歴史が証明しているように、いまだに厄介な問題である。この状況は、テクニカルアーティファクトに対する私たちの理解にも影響を与えている。それらの物理的側面と意図的（機能的）側面を組み合わせた概念的枠組みはいまだに欠けている。(Kroes & Meijers 2006: 2)

テクニカルアーティファクトに関する文献（例えば、Kroes 2010; Meijers 2001; Thomasson 2007; Vermaas & Houkes 2003）には、この 2 つの概念がどのように関連しているかについて、主に 2 つの理論があります。

因果役割理論は、実際の物理的能力が機能を決定すると主張します。Cumminsの機能分析理論（Cummins 1975）は、そのような理論の影響力のある例です。この理論の根底にある直観は、物理的なものとその実際の特性がなければ、アーティファクトは存在し得ないということです。これらの理論に対する主な批判は、あらゆる正しさの基準の位置に関するものです。物理的な装置だけがあるのであれば、正しさの独立した尺度はありません（Kroes 2010）。機能は、デバイスが実際に何をするかによって固定されています。

因果的役割理論は機能を実際の物理的能力と一致させる傾向がある。つまり構造と機能はほぼ同じになる。このアプローチの主な欠点は、テクニカルアーティファクトの誤作動を説明できないことである。アーティファクトに関連する意図は、機能の帰属には無関係になってしまったのである。（Kroes 2010: 3）

この批判は、Kripke (1982)がルール・フォロワーに関する議論の中で行ったものと同じ趣向を持っています。

意図的理論は、人工物に機能を付与するのはエージェントであると主張します。物体とその構成要素は、それらが目標の実現に貢献する限りにおいてのみ機能を持ちます。このアプローチの好例は、McLaughlin（2001）やSearle（1995）です。

しかし、機能はエージェントの欲望によって正確にどのように固定化されるのでしょうか。ある解釈では、機能はエージェント、すなわちテクニカルアーティファクトの設計者や利用者の精神状態によって決定されるとされています。その粗野な形式では、このような理論は、アーティファクトである実際のものにどのような制約を課すのかを説明するのは困難です。

一方で、機能が主に精神状態のパターンとして捉えられ、いわばアーティファクトの設計者や利用者の頭の中にしか存在しないとすれば、機能が特定のアーティファクトの物理的な基質とどのように関係しているのかは、いささか不可解なものとなる。（Kroes 2010: 2）

例えば、どのようにしてエージェントの精神状態は、足し算を行うことを意図した装置の機能を固定することができるのでしょうか？この質問は、Kripkeによってかなり異なる文脈で提起されています。

私の心の歴史の中のすべてのものが、私が「plus」を意味するという結論と、私が「quus」を意味するという結論の両方に適合することを考えると、懐疑的な挑戦が認識論的なものではないことは明らかである。それは、過去の行動に関する私の心の歴史の中には何もないことを示そうとする。しかし、それでは、私が「quus」ではなく「plus」を意味していたことを構成するような事実は、私については何もなかったことになるように思われる。(Kripke 1982: 21)

もちろん、アーティファクトが実際に仕様に合致していると主張することもできるかもしれませんが、機能の表現がエージェントの精神状態にしか位置していない場合には、これは何の役にも立ちません。意図論のこのバージョンは、実際には、エージェントの頭が機能が配置されている物理的な装置であるという因果論の特殊なケースです。

しかし、意図的アプローチには別の解釈があります。意図的に行動するというWittgensteinの概念についての彼の解説（Wittgenstein1953）において、David Pearsは、意図的に行動する人は誰でも二つのことを知っていなければならないことを示唆しています。第一に、ある人は自身が従事している活動が何であるかを知っていること、第二に、彼女はいつそれが成功したかを知っていなければならないことです(Pairs 2006)。この視点によれば、正しさを確立することは、外部から観察可能な、ルールに基づいた活動となります。定義とアーティファクトとの関係は、定義を装置の正しさの規範として使用することに現れています。それが機能すると考える理由を正当化できなければなりません。このように、「それが機能するかどうか」と問われたら、抽象的な定義を参照して、それが機能することを正当化できなければなりません。機能の内容は抽象定義の中にレイアウトされていますが、それを仕様として受け取ろうとする意図は、それを一つのものとして使うことに現れています（§2.2）。

3. 実装

広く言えば、実装とは仕様の実現です。例えば、JavaでのUML仕様の実装、C言語でのプログラムとしての抽象アルゴリズムの実装、Mirandaでの抽象データ型の実装、あるいはプログラミング言語全体の実装などが挙げられます。さらに、実装は物理的な基盤の前に多くの段階を含む間接的なプロセスであることが多く、仕様と成果物のペアリングと実装の概念を含んでいます。しかし、実際の実装とは何でしょう？一つの概念だけか、それとも多くの概念があるのでしょうか？

3.1 実装とは何か

実装の最も詳細な哲学的研究はRapaport(1999, 2005)によって与えられました。彼は、実装には2つの領域があると主張しています。それは、構文的なもの(抽象化)と意味的なもの(実体化)です。実際、彼は、この概念を完全に説明するためには、第三の隠された用語、実装の媒体が必要であることを示唆しています。IがMを媒体とするAの実装とします。ここでIは意味的コンポーネント、Aは抽象、Mは解釈の媒体です。ここでRapaportは対象媒体が抽象的であっても物理的であってもよいとしています。これは、人工物が抽象的であっても具体的であってもよいという主張と一致しています。

表面的には、これは正しいようです。引用されたすべての例において、実装である実際のものを切り取る実装媒体があります。おそらく最も明確な例は、プログラミング言語の実装でしょう。ここでは、構文領域は実際の言語であり、意味領域は抽象的なマシン（解釈の媒体）上での解釈です。彼は、アルゴリズムをコンピュータプログラミング言語で表現するときに実装し、抽象的なデータ型を具体的なものとして表現するときに実装することを提案しています。彼が言及していない例としては、Javaで実装されているUMLのデザインパターンの定義があるかもしれません（Gamma et al. 1994）。

彼はさらに、どのドメインが意味的で、どのドメインが構文的であるかに本質的な違いはないと主張しています。これは、実装マッピングの非対称性によって決定されます。例えば、プログラムを実装する物理的なコンピュータプロセスは、言語プログラムに対して意味領域の役割を果たすが、同じ言語プログラムはアルゴリズムに対して意味領域の役割を果たすことができます。この非対称性は、仕様とアーティファクトの結びつきと平行しています。表面的には、反論の余地はほとんどありません。それは、実装という言葉の実際の使用方法を端的に説明したものであるからです。しかし、あまり明確ではないけれども、ある追加の概念的主張があります。

3.2 意味解釈としての実装

このように、意味領域は、その名が示すように、常に構文的なものの意味的な表現であると考えられています。これは、構文領域がその意味を提供する別の領域を参照しているという意味論の参照的な見方です。実際、コンピュータ科学の分野では、参照的意味論や表示的意味論を基本とする強い伝統があります(Stoy 1977; Milne & Strachey 1976; Gordon 1979)。この主張については、プログラミング言語の意味論をより詳細に検討する際に、後ほど検討することにします(§4)。今のところ、我々は意味論の中心的な役割にのみ関心を持っています。

意味論の一つの見方は，意味論は規範的でなければならないと主張していることです。規範的制約（Glüer & Wikforss 2015; Miller & Wright 2002）の正確な形は議論されていますが、意味論的な説明は「表現を正しく使うこととはどういうことであるか」を規定しなければならないという最低限の要件については、多くの合意があります。

式が何かを意味するという事実は、その式を使った私の行動についての規範的な真理の全体セットがあることを意味している。意味の規範性とは、言い換えれば、意味を真理論的に考えるか言明論的に考えるかにかかわらず、意味のある表現には正しい使用の条件があるという身近な事実の新しい名前であることが判明したのである。Kripkeの洞察は、この観察が意味の決定の理論上の妥当性の条件に変換される可能性があることを理解することであった。表現が意味を持つことによって得られる性質の候補は、意味の「規範性」を根拠づけるようなものでなければならない。(Boghossian 1989: 513)

この最小要件はなんらかの意味論でも満たされなければならないという仮定のもとでは、実装は常に、あるいは今までも意味解釈なのでしょうか。また、この二つの概念は互いに対立しているのでしょうか？

実装の標準的な例の一つは、ある言語を別の言語で解釈することに関係しています。ここでは、抽象と意味領域は両方の言語です。残念ながら、これは対象言語の意味論をすでに確定していない限り、正しさの基準にはなりません。言語間の翻訳は実装であり、確かにパラダイムケースであると考えられますが、現在の基準では意味解釈ではありません。それは、対象言語が独立して与えられた正しさの概念を持っている場合にのみ、正しさの基準を満たします。これは非公式な方法でも数学的な方法でも達成されるかもしれませんが、それは別の解釈されない言語で終わってはいけません。したがって、この実装のパラダイムケースは、意味解釈に必要な規範的制約を満たしていないように見えます。一方、Rapaport（1995）は、再帰的な実装の定義を提供するには、ベースケースが必要であり、それは、プロセスが解釈されていない言語で終わらなければならないということを論じています。しかし、そのような言語は、各シンボルをそれ自体にマッピングしたり、その言語の異なるシンボルにマッピングしたりして、それ自体で解釈することができます。

次に、抽象化の対象が言語であり、意味論の媒体が集合論である場合を考えます。これは、表示的意味論（Stoy 1977）の場合でしょう。これは正しさの概念を提供します。我々が共有し、合意した集合論の理解がこれを提供しています。ただ残念ながら、これは通常、実装とはみなされないでしょう。もし実装が最終的に物理的に実現可能なものであるならば、そうではないでしょうが。

ここで、構文的な要素が抽象的なスタックであり、意味的な要素が配列である場合を考えてみよう。ここでは、実装が正しいと言うことが何を意味するのかを問わなければなりません。配列という媒体はスタックの正しい使い方を固定しているのでしょうか？そうではないように思われます。配列は、スタックのための正しい公理を持っているかどうか、あるいは特定のアプリケーションでスタックを正しく使ったかどうかを判断する基準を提供していません。むしろ、スタックは配列である実装の正しい基準を提供しています。その代わりに、公理は構成要素の基本的な意味を提供しています。配列はスタックの実装ではありますが、配列に正しさの概念を提供しているわけではありません。馬車と馬は入れ替わっています。

最後に、意味領域が物理的な機械であり、構文領域が抽象的な機械であるとします。この提案は、物理的な機械が抽象的な機械の意味的解釈を提供していることを示唆しています。しかし、意味的解釈は、正しさと誤動作の概念を提供しなければならず、これに反対するやむを得ない議論があります。この問題は，プログラミング言語の意味論を検討するセクション(§4)でより注意深く検討されます。

言語の意味論的な説明が正しさの基準を提供しなければならないこと、そして意味論という言葉が何らかの意味を持たなければならないことを考えると、これらは実装が意味論的解釈であるという見解にとって深刻な障害となります。ここにおいて、いくつかの現象が一つにまとめられています。これらの反論が正しい線に沿ったものであれば、ソースとターゲットの関係は意味解釈ではありません。もちろん、意味論の正しさの要件に反論することで、これらすべてに反論することができます。

3.3 仕様と実装

実装に関する代替的な分析は、Turner (2014, 2012)が暗示しています。有限集合のデータ型がリストのデータ型に実装されている場合を考えるとします。これらの構造は、いくつかの簡単な公理によって支配されます。実装では、有限集合をリストとして表し、集合に対する和演算をリスト連結として表し、集合間の等号性をリスト上の拡張等号性として表します。これは、集合に対する公理がアーティファクトの仕様として機能する数学的関係であり、この場合はリストという媒体で実装されています。この2つの間の論理的なつながりは，仕様とアーティファクトの関係であると思われます。このマッピングは直接的なものである必要はなく、単純な操作と操作の対応関係がある必要はありません。標準的な数学的用語では、リスト媒体は集合公理の数学的モデル（モデル理論の意味、W. Hodges 2013）を提供しなければなりません。ある言語が別の言語で実装されている場合も同様であり、2つの言語の意味的定義によって肉付けされます。

最後に、実装の媒体が物理デバイスである場合、例えば、抽象スタックが物理デバイスとして実装されている場合を考えてみましょう。繰り返しになりますが、抽象スタックは物理デバイスの正しさの基準を提供しなければなりません。これが実際に起こることです。物理的な操作がスタックの公理で与えられた抽象的な要求を満たすかどうかをチェックします。ここでは、この正しさの概念の妥当性に関係する問題があります。これらの問題については、コンピュータサイエンスの正しさの概念(§7.4)をより注意深く検討するときに議論することにします。

この分析が正しいとすれば、実装は仕様とアーティファクトの関係として最もよく表現されます。実装は意味的解釈ではありません。実際、実装の正しさの概念を定式化するためには、独立した意味的説明が必要です。では、コンピュータサイエンスでは、何が意味解釈とされるのでしょうか？

4. 意味論

プログラミング言語の意味論的説明はどのように与えられるべきでしょうか？また意味論的領域を取り巻く主な概念的問題は何でしょうか？文献の中には多くの異なる意味論の候補があります(Gordon 1979; Gunter 1992; Fernández 2004; Milne & Strachey 1976)。ある最も重要な区別として、操作的意味論と表示的意味論の違いに焦点を当てています（Turner 2007; White 2003）。

4.1 2種類の意味論

操作的意味論は、Landin (1964)から始まりました。その論理的な装い(Fernández 2004)では、それは評価のメカニズムを提供し、最も単純な形では、評価関係は次のように表されます。

これは、プログラムPがcで与えられた正準形に収束するという考えを表現しています。このような還元過程の古典的なケースはラムダ微積分で発生しますが、ここでは還元は微積分の還元規則によって与えられ、正準形はその正規形、すなわち還元規則のいずれも適用されない形です。以下に簡単な例を示します。

これは通常、ビッグステップ意味論と呼ばれています。これは通常、複雑なプログラムの評価をその部分の評価の観点から提供するルールで与えます。例えば、シーケンシング(°)のための単純なルールは次のような形になります。

これらの正準形や正規形は、与えられた規則によってさらに縮小することができないそのプログラミング言語の用語です。しかし、結局、それらはその言語の用語です。このことで、この操作的アプローチはしばしば不満足だと言われています。批判によれば，解釈の過程のある時点で，形式言語の意味論は数学的なものでなければならないとされます。

そのような言語の一つにラムダ計算があるが、ここからわかるように、それは構文的な変換ルールを持つ形式的なシステムとしてのみ提示することができる...しかし、このような作業をするとき、私たちがやっていることは記号を操作することだけであることを覚えておかなければならない。実際の問題を解決するためには、何らかの意味的解釈を与えなければならない。例えば、「これらの記号は整数を表している」と言わなければならない。(Stoy 1977: 9)

このことに対して、操作的意味論は構文的なものとされています。特に、片方が正準形であっても、関係P⇓cは構文オブジェクトを関連付けます。これでは、私たちが話していることを理解できません。言語の定数がそれ自体が独立して与えられた数学的意味を持っていない限り、このプロセスでは意味論的基盤に到達することはできません。このことによって、より数学的なアプローチが要求されるようになります。

明らかに、プログラミング言語は、構文的なものではなく、抽象的な数学的なオブジェクトを参照している（あるいは、そのための表記法である）ようです（Strachey 2000; McGettrick 1980; Stoy 1977）。特に、表示的意味論は、構文的なオブジェクトPに数学的な意味を与えることができます。さらに、一般的には構築的な方法でこれを行います。つまり複雑なプログラムは、その構文部分の表示的観点から、その表示的意味が固定されています。これらの数学的オブジェクトは、集合論的、圏論的、あるいは型論的であるかもしれません。しかし、いずれの方法が選択されたとしても、プログラムは抽象的な数学を参照しているとみなされます。しかし、この立場は、構文的なものと数学的なものを明確に区別することに依存しています。

4.2 公理論としてのプログラミング言語

集合論や圏論などの数学的理論は公理論です。そして、それらを数学的なものにしているのは、このことでしょう。これは、ヒルベルト(1931)によって奨励され、(Bourbaki 1968)によって支持された数学の現代的な公理論的扱いに暗黙のうちにあります。公理的な説明は、それが正確であり、数学的推論を支持するものである限り、形式的である必要はないことを指摘する価値があります。これを数学的地位のための必要条件として受け入れるならば，運用的なアカウントを排除することになるのでしょうか？一見するとそのように思われます。どうやら，プログラムは公理的な定義を持たない正準定数に還元されているようです。しかし，Turner (2009b, 2010) は，これは公理化の場所を間違えていると主張しています。つまり後者は解釈定数ではなく、評価の規則、すなわち、公理関係⇓によって与えられる還元の理論の中に存在するということです。

表示的意味論と操作的意味論の両方が公理的に問題を定義していることを考えると、言語を形式的な数学的理論として定義するためにどちらを取るかは問題ではないはずです。残念ながら、両者は常に一致しているわけではないのです。操作的意味論によって提供される等質性の概念は、表示的意味論によって保存されるものの、しばしばより細かい粒度のものになります。このことが、ゲームに基づいた非常に特殊な形の表示的意味論につながっているのです(Abramsky & McCusker 1995; Abramsky et al. 1994)。しかし、実際の労働者が操作的意味論を基本としていることは明らかであり、操作的意味論と一致するような表示的意味論を考案しようとしていることがそれを物語っています。

集合論的記述と操作的記述の間には形而上学的な違いがないだけでなく、後者が決定的な記述であると考えられています。このようなプログラミング言語観は、理論計算機科学の視点です。プログラミング言語は、その操作的定義を介して、計算の数学的理論となります。

しかし、プログラミング言語は本質的に非常に組み合わせ的なものです。プログラミング言語は作業ツールであって、エレガントな数学的理論ではありません。それが数学的理論であることの妨げになっているのでしょうか？この問題については文献ではほとんど議論されていませんが、Turner (2010)とStrachey (2000)は例外です。Stracheyは、その表面上、それらを純粋で単純な数学的対象として見ています。Turnerはもう少し慎重で、実際のプログラミング言語は、しばしば複雑すぎて数学的理論として探求することができませんが、計算の核となる理論が含まれており、それを言語全体に保守的に拡張することができると主張しています。

4.3 プログラミング言語の実装

しかし、Turner (2014)はさらに、プログラミング言語は、その中核をなすものであっても、単なる数学的なオブジェクトではないと主張しています。彼は、プログラミング言語は技術的なアーティファクトとして最もよく概念化されていると主張しています。その公理的定義が機能を提供する一方で、実装を必要とします。技術的アーティファクトの言語では、言語の構造的な記述は、これがどのようにして実現されるかを述べなければなりません。言語の構成要素がどのように実装されるかを説明しなければなりません。最も単純なケースを説明するために，代入命令を考えてみましょう。

物理的な実装は次のような形になるかもしれません。
- E の値を物理的に計算する。
- 置き換えるべき値の任意の既存のトークンを x という名前の物理的な場所に E の値の（物理的な）トークンを配置する。

これは、どのように代入が物理的に実現されるかを記述したものです。つまり評価のプロセスを物理的に記述したものです。もちろん、完全な記述はより多くのことを説明しますが、実際のマシンが何でできているのかはおそらくわかりません。構造記述の仕事は、同様に構造化された物理マシンの組での実装プロセスを記述することだけです。これをベースに、言語の複雑な構造がどのように実装されるかを規定します。例えば、コマンドを順番に実行するために、それらを配置する物理スタックを追加することができます。もちろん、問題はこれほど単純ではありません。反復や再帰のような構造は、より洗練された処理を必要とします。実際、解釈やコンパイルには多くのレイヤーやプロセスが必要になるかもしれません。しかし、最終的には、物理的な機械という媒体への解釈が存在しなければなりません。Turner（2014）は、プログラミング言語は、構造としての実装とともに、構文と意味論（関数）の複雑なパッケージであると結論づけています。

また、物理的な実装が実際には言語の意味論を定義しているという意見もあります。実際、これはコンピュータサイエンス哲学の文献では一般的な見解です。Rapaport (1999)が実装を意味論的解釈として捉えていることはすでに見てきました。Fetzer(1988)は、プログラムは異なる意味的な意味を持っていると観察しています。特に彼はこのように述べます。

プログラムは、定理が欠けているように見える意味論的意義を持っていると考えられている。プログラムを構成する行の列は、機械によって実行可能な操作や手続きを表すように意図されているのに対し、証明を構成する行の列はそうではないからである(Fetzer 1988: 1059)。

これは、実装の物理的性質が、その言語で書かれたプログラムの意味に貢献していると言っているようです。Colburn(2000)は，彼が単純な代入文A:=13×74が我々が与えた抽象的な説明のようなものと、次のように与えられた物理的なものとの間で意味的に曖昧であると書くとき、より明示的です。

物理的なメモリの位置Aは、物理的に計算した値を 13 回 74 を受け取る。(Colburn 2000: 134)

「物理的に計算する」という表現は、物理的な機械が実際に行うことが意味的に重要であること、すなわち、実際に行うことが代入の意味を決定したり、貢献したりすることを暗示しているように思われます。これは、代入の意味を固定するためには、物理的な計算を行わなければならないということを暗示していると解釈されるのでしょうか？しかし、もし実際の物理的な機械が言語の構成要素の意味に何らかの形で貢献していると考えられるならば、その意味は物理的な装置の偶発性に依存していることになります。特に、単純な代入文の意味は、デバイスの物理的な状態や、言語の意味論とは無関係な偶発性、例えば停電などによって変化する可能性があります。この解釈では、乗算は乗算を意味するのではなく、物理的な機械が乗算をシミュレートするときに実際に何をするかを意味します。この批判は，関数の因果理論（§2.4）に対する批判と類似しています。

5. プログラムのオントロジー

プログラムの性質は、哲学的、法的な考察の対象となってきました。では、プログラムとはどのようなものなのでしょうか？それは抽象的な(数学的あるいは象徴的な)物体なのか、それとも具体的な物理的なものなのか。実際、法的な文献には、プログラムが新しい種類の(法的な)実体を構成するという示唆さえ含まれています(§10.1)。

コンピュータ・プログラムの正確な性質を決定することは困難である。一方では、それらは技術的な問題に関連しており、他方、それらは通常のタイプの発明とはほとんど比較できない。物理的な性質のプロセスや製品ではなく、組織や管理の方法を伴うものであるからだ。したがって、それらは機械に対処されているにもかかわらず、文学作品を彷彿とさせる。工業所有権法も著作権法も、伝統的な役割におけるプログラムの保護には適切な手段ではないように思われる。コンピュータ・プログラムのユニークな性質は、sui generis法の創設を広く支持することにつながっている(Loewenheim 1989: 1: 1)。

このことは、プログラムの不思議な法的地位を浮き彫りにしています。実際、プログラムとソフトウェアの性質については、トリッキーな存在論的な疑問が投げかけられています。本節では、プログラムとソフトウェアの性質に関する哲学的な問題のいくつかを検討します。

5.1 数学オブジェクトとしてのプログラム

プログラムは数学的なオブジェクトであるという主張の内容は何でしょうか。法的な文献では、プログラムは形式的に操作できる象徴的なオブジェクトであるという考え方が議論の中心となっているようです(Groklaw 2012a, 2012b-see Other Internet Resources)。実際、形式言語理論と呼ばれる理論的コンピュータ科学の一分野があり、文法を数学的研究の対象として扱います(Hopcroft & Ullman 1969)。これは主張にある程度の実体を与えますが、プログラムが数学的であるという最も重要な意味ではありません。これは，プログラム言語が公理的な理論であるとされる意味論に関係しています(§4.2)．この観点は、プログラムを計算理論の中の要素として位置づけることになります(Turner 2007, 2010)。

5.2 技術的アーティファクトとしてのプログラム

プログラムが抽象的な装いを持っていることには同意しますが、哲学的な文献の多く(例えば、Colburn 2000; Moor 1978)では、プログラムはまた、物理的な機械の計算の原因としての使用を容易にする具体的な物理的表現を持っているとされています。例えば、ムーアは次のように述べています。

コンピュータプログラムは、物理的なレベルだけでなく、記号的なレベルでも理解できることを覚えておくことが重要である。初期のデジタルコンピュータのプログラミングは、ワイヤーを差し込んだり、スイッチを投げたりすることで行われるのが一般的であった。アナログコンピュータの中には、今でもこの方法でプログラミングされているものもある。結果として得られるプログラムは、明らかに物理的なものであり、他の部分と同様にコンピュータシステムの一部である。今日のデジタルマシンは、通常、プログラムの実行を高速化するために、内部的にプログラムを格納している。そのような形式のプログラムは確かに物理的であり、コンピュータシステムの一部である。(Moor 1978: 215)

以下はより最近のもので、ソフトウェアには抽象的な姿と物理的な姿の両方があるという主張の中で、二元性のテーゼをより明確に説明しています。

多くの哲学者やコンピュータ科学者は、ソフトウェアには二重の性質があるという直感を共有している（Moor 1978; Colburn 2000）。ソフトウェアは、アルゴリズムであり、命令セットであり、具体的な物体や物理的な因果関係のプロセスであると考えられています(Irmak 2012: 3)。

5.3 抽象と具体

プログラムの抽象的・物理的二元性に説得された人は誰でも、これら二つの存在形態の間の関係について何かを言う義務があります。これは哲学的に大きな関心事であり、一般的には技術的なアーティファクトに対する疑問と類似しています。

一つの直接的な提案は、テキストオブジェクトとしてのプログラムは、機械的なプロセスを引き起こすということです。この考えは、何らかの形でテキストオブジェクトが物理的に機械的プロセスを引き起こすというものであるように思われます。Colburn (2000, 1999) は、象徴的なテキスト自体が何らかの因果関係を持っていることを否定しています。彼にとってソフトウェアとは、記述の媒体（テキスト、抽象化）と実行の媒体（例えば、半導体における具体的な実装）を持つ具体的な抽象化です。この二元性は、物理的な装置が抽象的なものの意味的解釈として捉えられるという、心の哲学に見られるもの（二元論のエントリを参照）と平行した方法で紐解かれています。これはRapaport (1999)の視点に近いです。しかし、私たちはすでにこのアプローチの問題点を指摘しています（§3.3）。

少し異なる説明は、Fetzer (1988)にあります。彼は、抽象的なプログラムは科学的な理論のようなものだと提案しています。プログラムはその物理的な実装の理論として見られるべきであり、プログラムは因果モデルとして見られるべきであるということです。特に、単純な代入文とその意味論は、物理的なストアとそれがどのように振る舞うかについての理論です。これが正しく、プログラムがその実装である物理装置の正確な記述でないことが判明した場合、プログラムは変更されなければなりません。プログラムに内包されている理論が物理装置に適合しない場合、それは変更されるべきです。しかし、これは実際にはそうではないようです。プログラムは変更されなければならないかもしれないが、それは物理的な実現との調和の欠如によって引き起こされるのではなく、代入のための独立した抽象的な意味論によって引き起こされます。これが正しいとすれば、抽象的な意味論は、その具体的な実装の理論ではないように見えます。

代替案としては、抽象的なプログラム（その意味論によって決定される）がアーティファクトの機能を提供し、物理的なアーティファクト（というよりはその記述）がその構造を提供するというものがあります。物理的な実装を固定化し、正しさと誤動作の基準を提供するのは、意味論で表現されたプログラムの機能です。計算アーティファクトとしてのプログラムは、それが何をするかを何らかの形で修正する抽象的な側面と、それが物理的なことを引き起こすことを可能にする物理的な側面の両方を持っています。

5.4 プログラムと仕様

プログラミングと仕様書の違いとはなんでしょうか？1つの示唆は、仕様書は実際にそれをどのように行うかを言わずに、何を行うかを教えてくれるものだということです。例えば、以下はVDMで書かれた仕様です (Jones 1990 [1986])。

入力が正であることを前提とした平方根関数の指定です。これは、それがどのように達成されなければならないかを言わずに、何をしなければならないかを述べているという点で、機能的な記述です。このWhat-howの違いを説明する一つの方法は、記述的命令的区別の観点から説明することです。プログラムは命令的で、どのようにして目標を達成するかを述べますが、仕様書は宣言的で、意図されたプログラムの入出力の動作を記述するだけです。確かに、命令的プログラミングのパラダイムでは、これは実質的な違いを捉えているように見えます。しかし、これはすべてに適しているわけではありません。例えば、論理型や関数型プログラミング言語(Thompson 2011)は、明らかにこのパラダイムに支配されているわけではありません。問題は、プログラミング言語が、この区別を記述する方法が、プログラミング言語のスタイルやパラダイムによってマークされないところまで進化してきたということです。実際、実際には、Haskellで書かれたプログラム(Thompson 2011)は、Cで書かれたプログラムの仕様書として機能します(Huss 1997, Other Internet Resources)。

より根本的な違いは、ガバナンスの方向性、すなわち、関係の中でどちらが規範的なパートナーで、どちらが従順なパートナーなのかということに関係しています。平方根関数の仕様の場合、アーティファクトは言語プログラムです。プログラムを仕様とすると、アーティファクトは次のレベルのコードであり、そうして具体的な実装に至ります。これは、Rapaport (2005)や彼の「実装の非対称性」という概念と一致しています。

6.検証

ソフトウェア開発プロセスの重要な部分の一つに検証があります。計算アーティファクトが指定され、高レベルのプログラミング言語にインスタンス化され、ハードウェアに実装された後、開発者は、与えられたプログラムの仕様に対して、その成果物が正しいかどうかを評価する活動に参加します。正しさの評価方法は、大きく分けて形式検証とテストの 2 つに分類されます。形式的検証(Monin 2003)は数学的な正しさの証明を伴うのに対し、ソフトウェアテスト(Ammann & Offutt 2008)は、実装されたプログラムを実行し、実行された実行がプログラムの動作に関する高度な仕様に準拠しているか、準拠していないかを観察することを意味しています。多くの実用的なケースでは、形式的な手法とテストが検証目的で併用されています（例えば、Callahan et al.）

6.1 モデルと理論

形式的な検証方法には、プログラム仕様書のセットに対して検証されるソフトウェアの表現を構築することが含まれます。定理証明（Van Leeuwen 1990参照）では、プログラムは公理系とプログラムの遷移条件の推論規則の集合で表現されます。モデル検査(Baier & Katoen 2008)では、プログラムを状態遷移系で表現し、プログラムの特性仕様を時間的論理式(Kröger & Merz 2008)で表現し、正しさの証明は、状態遷移系の時間的論理式が保持されているかどうかを確認する深さ優先探索アルゴリズムによって達成されます。

表現された計算アーティファクトの実行が、その仕様で規定された動作に適合するか否かを評価するために用いられる公理系や状態遷移系は、表現されたシステムの将来の動作を予測し説明するために用いられるという意味で、表現されたシステムの理論として理解することができます。特に、モデル検査における状態遷移システムは、方法論的には、経験科学における科学的モデルと比較することができます(Angius & Tamburrini 2011)。例えば、Kripke構造は、科学的モデルを、対象となる経験的システムの実験によって収集されたデータのモデルと適切なマッピング関係を確立する集合理論的な構造であると定義したSuppes(1960)の定義に準拠しています(科学におけるモデルに関するエントリも参照のこと)。クリプケ構造 M=(S, S0, R, L)は空ではない状態の集合からなる集合理論モデルです。
Sと，空ではない初期状態の集合 S0、全状態遷移関係 R⊆S×Sと関数 L:S→2APの各状態をラベル付けします。これはSを原子命題APの集合の部分集合としたものです。

形式的な検証手法で利用されるKripke構造やその他の状態遷移システムは、しばしばシステム仕様と呼ばれます。これらは、プロパティ仕様とも呼ばれる共通仕様とは区別されます。後者は、エンコードされるアーティファクトがインスタンス化しなければならないいくつかの必要な動作特性を指定するのに対し、前者は（原則として）すでにエンコードされたプログラムのすべての潜在的な実行を指定し、その痕跡をアルゴリズムでチェックすることを可能にします（Clarke et al. この目標を達成するために、システム仕様は、プログラムのコードと許容される状態遷移に基づいて、ターゲットとなる計算成果物の潜在的な実行のセットを仮定する帰納的な構造と考えられる(Angius 2013b)。実際、モデル化されたKripke構造が保持されるかどうかを時間的論理式がチェックされると、表現されたプログラムはチェックされた式に対応する動作特性に対して経験的にテストされ、モデル仮説が対象となる計算アーティファクトの適切な表現であるかどうかが評価されます。したがって、プロパティ仕様とシステム仕様は、その意図的なスタンスも異なる（Turner 2011）。プロパティの仕様は、以下のような要件である。
符号化されるプログラムは、システム仕様は、(仮想的な)符号化されたプログラムです。モデル検査における状態遷移システムの記述的かつ帰納的な特性は、状態遷移システムを科学的モデルと同等のものにするための追加的かつ本質的な特徴です。

6.2 テストと実験

ソフトウェア開発におけるいわゆる「アジャイル手法」は、実装された計算アーティファクトの信頼性を評価するために、ソフトウェアテストを広く利用しています。テストとは、プログラムを起動し、その実行を観察して、プログラムが提供されたプロパティの仕様に準拠しているかどうかを評価する、より「経験的」なプロセスです。哲学者や哲学志向のコンピュータ科学者たちは、科学的発見における伝統的な方法論的アプローチ（Snelting 1998; Gagliardi 2007; Northover et al. 2008; Angius 2014）に照らしてソフトウェアテストの手法を分析し、ソフトウェアテストがプログラムの正しさを評価する科学的実験として認められるかどうかを疑問視しました（Schiaffonati & Verdicchio 2014; Schiaffonati 2015; Tedre 2015）。

ダイクストラのよく知られた口語「プログラムテストはバグの存在を示すためには使えるが、バグが存在しないことを示すためには決して使えない」(Dijkstra 1970: 7)は、ポッパー(1959)の改ざん可能性の原則をコンピュータサイエンスに導入しています(Snelting 1998)。あるプログラムをある一定の時間間隔で高度なプロパティ仕様に照らしてテストすると、いくつかの失敗を示すかもしれませんが、実行中のプログラムを観察している間に失敗が実行されなければ、そのプログラムが正しいと結論づけることはできません。不正確な実行が、次のシステムのテストで観察されるかもしれません。その理由は、テスターは、潜在的なプログラムの入力セットの有限のサブセットと有限の時間間隔でしかプログラムを起動することができないからです。このため、ソフトウェアテストの目的は、プログラムの欠陥を検出することであり、欠陥がないことを保証することではありません(Ammann & Offutt 2008: 11)。プログラムは、テストによってそれを明らかにすることができるという点で、改ざん可能です(Northover et al. 2008)。計算アーティファクトと特性の仕様が与えられると、テストは科学実験のようなもので、システムの動作を観察することで、興味のある仕様に関してプログラムが正しいという仮説を偽装しようとします。

しかし、科学的実験を特徴づける他の方法論的・認識論的特徴がソフトウェアテストには共有されていないことに注意しなければなりません。最初の方法論的な区別は、科学的な仮説を検定する場合のように、改竄検定が仮説ではなくアーティファクトの修正につながるという点で認識できます。これは、科学における仕様書と経験的仮説の意図的なスタンスの違いによるものです（Turner 2011）。仕様とは、プログラムが仕様の正しいインスタンス化になるまで、その違反がプログラムの修正を要求する要件です。

したがって、経験科学の哲学によって伝統的に検討されてきたような科学的実験の概念は、ソフトウェアのテスト活動に適用するためには、何らかの形で「引き伸ばされる」必要があります（Schiaffonati 2015）。実験科学の大部分を特徴づける理論主導型の実験は、実際のコンピュータサイエンスの実践には対応するものがありません。実際、テストが形式的な方法と組み合わされている場合を除外すると、ソフトウェアエンジニアによって実行されるほとんどの実験は、むしろ探索的なものです。実験は、それが以下のことを「探求する」ことを目的としている場合には、探求的なものとなります。

適切な理論や理論的背景がない場合のアーティファクトの機能と環境との相互作用に関連する可能性の領域。(Schiaffonati 2015: 662)

ソフトウェアのテスト担当者は、実行する実験について理論的なコントロールができないことが多く、ユーザーや環境と相互作用する人工物の挙動を探索することで、観察された挙動に関する理論的な一般化をテスト担当者に提供することになります。コンピュータサイエンスにおける探索的実験の特徴は、テスト者がユーザの役割を果たし、実環境に近い環境でプログラムがテストされることが多いことにもあります。しかし、実験者が実施される実験に参加しないことは、理論主導型実験の本質的な特徴であります。

その結果、いくつかのソフトウェアテスト活動は、1つの経験的な科学で見つける実験的な活動に近いですが、いくつかの他のものは、むしろソフトウェア開発プロセスに属していることが判明した実験の新しい類型論を定義します。実験の5つの類型は、コンピューティングアーティファクトを指定、実装、および評価のプロセスで区別することができます(Tedre 2015)。実現可能性実験は、関心のある成果物がユーザーや利害関係者によって指定された機能を実行するかどうかを評価するために実行されます。トライアル実験は、初期条件のいくつかのセットを与えられたシステムの分離された機能を評価するために実施されるより具体的な実験です。このように、実験は、評価の対象となる理論的な仮説に基づいて実施されるという点で、科学的な理論主導型の実験と同等のものです。

6.3 説明

ソフトウェアテストは、誤計算が検出されたときに成功したとみなされます(100%正しい計算結果がないと仮定します)。次のステップは、実行が正しいのではなく不正確なものになった原因を見つけ出すこと、つまり、障害（より身近なところでは「バグ」と呼ばれています）を追跡することであり、デバッグ段階に進み、システムを再度テストする前に、その原因を突き止めることです。言い換えれば、観測された誤演算の説明を進めようということです。

科学哲学の中で練り上げられた説明の異なるモデルに関連して、計算機科学における説明の分析に努力が費やされてきました（Piccinini 2007; Piccinini & Craver 2011; Piccinini 2015; Angius & Tamburrini forthcoming）。特に、計算説明は、計算プロセスがメカニズムとして分析できる限り、メカニストの説明の特定の種類として理解することができます(Glennan 1996; Machamer et al. 2000; Bechtel & Abrahamsen 2005)(Piccinini 2007, 2015; 物理システムにおける計算に関するエントリも参照)。メカニズムは、「開始または設定から終了または終了条件までの規則的な変化を生産するように組織された実体と活動」(Machamer et al. 2000: 3)の観点から定義することができ、言い換えれば、経験的な現象をもたらすことを可能にする構成要素、その機能的能力、およびそれらの組織のセットとして定義することができます。そして、このような現象の機械論的説明は、その現象をもたらすメカニズムの記述、すなわち、関与する構成要素と機能的組織の記述であることが判明しました。計算機構とは、その機能組織が計算過程をもたらす機構と定義されています。ここでいう計算プロセスとは、一般的には、入力文字列から出力文字列に至る文字列の操作であり、中間の文字列に対する操作によって、入力文字列から出力文字列に至るものと理解されます。

ある命令を実行するプロセッサを考えてみましょう。このプロセスは、関連するハードウェア仕様（レジスタの仕様、算術論理ユニットの仕様など）で規定された機能をインスタンス化したプロセッサの状態要素と組み合わせ要素を構成要素とし、それらが観察された実行を実行することができるように構成されたメカニズムとして理解することができます。したがって、このようなメカニズムの記述を提供すること、言い換えれば、ハードウェア構成要素の機能的な構成を記述することは、観測された計算の機械論的な説明、例えば、操作上の誤動作の説明を進めることと同じことになります。

7.5節で定義されているすべてのタイプの誤計算に対して、対応する機械論的説明は、適切な抽象化レベルで、その抽象化レベルを特徴づける仕様のセットに関して定義することができます。実際、メカニズムの抽象的な記述は、「既知の構成要素と活動の記述で埋めることができるメカニズムの切り捨てられた抽象的な記述」と定義されたメカニズムスキーマの形でメカニストの説明を提供しています(Machamer et al. 2000: 15)。例えば、スリップス§7.5と呼ばれる構文エラーを含むプログラムを実行することによって、計算機がミスコンピュートを起こすという非常に一般的なケースを考えてみましょう。計算機は、プログラム仕様書によって提供された機能要件を正しく実装することができない。しかし、説明のためには、ハードウェア構成要素とその機能構成の詳細な記述を進めて、発生したスリップの説明を抽象度の高いハードウェアレベルで提供することは冗長です。このような場合、十分な説明は、プログラムのコードが提供されたプログラム仕様の正しいインスタンス化ではないことを示すことで成り立つかもしれません(Angius & Tamburrini forthcoming)。これらのケースでは、発生した誤計算を機械的に説明するためには、計算メカニズムの残りの部分を抽象化して、不正なプログラムの記述を提供することで十分かもしれません(Piccinini & Craver 2011)。抽象化は、ソフトウェア開発や仕様書だけでなく、計算アーティファクトの動作の説明においても美徳となります。

7. 正しさ

コンピュータサイエンスにおける最も初期の哲学的論争の一つは、プログラムの正しさの本質を中心にしています。全体的な論争は2つの論文(De Millo et al. 1979; Fetzer 1988)によって開始され、ACMの議論フォーラム(例えば、Ashenhurst 1989; Technical Correspondence 1989)で進められました。重要な問題は、プログラムの二重性に由来しており、何が正しいと主張されているのか、何に対して何が正しいと主張されているのかということです。おそらく、もしプログラムが数学的なものとみなされるならば、それは数学的な性質を持っているだけです。しかし、技術的なアーティファクトとして見れば、それは物理的なものを持っています。

7.1 数学的な正しさ

つまり、正しさは数学的な問題であり、プログラムが仕様に対して正しいことを証明するには、数学的な証明しか必要ないということです。

コンピュータプログラミングは、プログラムのすべての特性と、与えられた環境でプログラムを実行したときのすべての結果が、原理的には、純粋に演繹的推論によって、プログラムのテキストから見つけることができるという点で、正確な科学である(Hoare 1969: 576)。

平方根関数の仕様を考えてみましょう。これはプログラムにとってどのような意味があるのでしょうか？平方根関数の仕様を考えてみましょう。これはプログラムにとってどのような意味があるのでしょうか？プログラムPを満足させるためにはどうすればよいのでしょうか？おそらく、その抽象的なセマンティクスに関連して、すべてのプログラム(P)は縁を切り開く縁を切り開くR(P)とその入力と出力の間の関係、つまり拡張子です。正しさの条件は、この関係が上記の仕様を満たすことを主張します。すなわちその入力と出力の間の関係、つまり拡張子です。正しさの条件は、この関係が上記の仕様を満たすことを主張します。

これは、その言語の意味的解釈によって決定される抽象プログラムが仕様を満たすことを要求します。文(C)は2つの抽象的なオブジェクト間の数学的な主張なので、原理的にはその正しさは数学的に確立されるかもしれません。この種の数学的関係は確かにHoareが念頭に置いているものであり、プログラムの抽象的な装いという点では、異論の余地はほとんどありません。しかし、ここにはいくつかの懸念があります。1つは現代のソフトウェアの複雑さ（複雑さの挑戦）、もう1つは物理的な正しさの性質（経験的な挑戦）です。

7.2 複雑さへの挑戦

プログラマーは常に複雑さに囲まれており、それを避けることはできない。私たちのアプリケーションが複雑なのは、コンピュータをより洗練された方法で使いたいという野心があるからである。プログラミングが複雑なのは、私たちのプログラミングプロジェクトのそれぞれについて、多数の相反する目的があるからである。もし私たちの基本的なツールであるプログラムを設計し、コード化する言語が複雑であれば、言語自体が解決策の一部ではなく、問題の一部になってしまう(Hoare 1981: 10)。

適切な数学的枠組みの中で、言語プログラムの仕様に対する正しさを証明することは理論的には可能です。しかし、実際のソフトウェアは複雑です。このような場合、正しさを証明することは現実的には不可能かもしれません。古典的な正しさの証明は定理プローバによって行われるべきであり、少なくともその過程のどこかで定理プローバが使われるべきだと主張することで、ある程度の根拠を得ることができるかもしれません。しかし、後者はそれ自体が正しいことを証明しなければなりません。これは、正しさの問題を単一のプログラムの正しさの問題に減らすことができるかもしれませんが、大きなプログラムの正しさの問題が残ることを意味します。さらに、これ自体は問題を完全に解決するものではありません。理論的な理由と実際的な理由の両方から、実際には人間の関与が完全に排除されるわけではありません。ほとんどの場合、証明はインタラクティブな証明システムの助けを借りて手作業で構築されます。それでも、厳密な正しさの証明が得られることはほとんどありません。個々の正しさの証明を人間ではなくコンピュータでチェックすることを要求するだけかもしれません。しかし、もちろん、証明チェッカーはそれ自体をチェックする必要があります。ArkoudasとBringsjord (2007)は、チェックする必要のある正しさ証明が1つだけ、つまりプルーフチェッカー自身の証明だけなので、間違いの可能性が大幅に減ると主張しています。

これは非常に実用的な問題です。しかし、もっと深い概念的な問題もあります。プログラムの正しさの証明は本物の数学的証明なのか、すなわち、そのような証明は標準的な数学的証明と同等のものなのか、ということです。(De Millo et al. 1979)は、正しさの証明は数学の証明とは異なると主張しています。後者は概念的に興味深く、説得力があり、それを研究し、その上に構築しようとする他の数学者の注目を集めます。この主張は、数学の哲学で行われている把握可能性の主張と類似しています。長くて、面倒で、面白くない証明は、標準的な数学的証明に見られるような確実性の担い手にはなり得ません。正しさの証明から得られる知識の性質は、数学の標準的な証明から得られる知識とは異なると言われています。取り込まれるためには、証明は把握可能でなければならない。実際、ウィトゲンシュタインは、把握できない証明は規範として機能せず、数学的証明ではないとしています（Wittgenstein 1956）。
ゲーデルの不完全性定理の証明のような数学的証明も長くて複雑です。しかし、それらは把握することができます。このような複雑な証明を透明で面白く、把握しやすいものにしているのは、モジュール化技術（例えば、レマ）の使用と、数学的創造の行為における抽象化の使用です。新しい概念を導入することで、証明を徐々に構築することができ、それによって証明を調査可能なものにすることができます。数学は，新しい数学的概念を発明することによって進歩し，それがなければはるかに複雑であり，不可能でさえある証明の構築を容易にします。数学は証明だけではなく、新しい概念や記法を抽象化して作成することも含まれています。これに対して、形式的な正しさの証明は、新しい概念や記法の作成を伴わないようです。コンピュータサイエンスには抽象化が含まれていますが、同じような方法ではありません。
複雑さの問題に対処する1つの方法は、ゲームの性質を変えることです。古典的な正しさの概念は、プログラムの形式的な仕様をその形式的な意味表現に結びつけます。それは数学的なスペクトルの一端にあります。しかし、抽象度の異なる仕様と成果物のペアリングの連鎖は、異なる正しさの概念によって支配されています。例えば、オブジェクト指向のアプローチでは、UML 仕様書と Java プログラムの間の接続は、型のチェックに過ぎません。正しさの基準には、構造的な類似性と同一性が含まれます(Gamma et al. 1994)。ここでは、ある無限の数学的関係が別の関係によって拡張的に支配されることを要求しません。抽象度の高いレベルでは，構造の接続だけが存在するかもしれません。これらは，やはり数学的関係です。しかし、このような方法は、作業が少なく、自動的に検証されるかもしれませんが、確立するものははるかに少ないです。

7.3 経験的な挑戦

プログラムの検証という概念は、一見すると、そのような矛盾に基づいて取引されているように見える。論理構造としてのアルゴリズムは、演繹的検証の対象として適切である。プログラムは、それらの構造の因果モデルとしては、そうではない。プログラムの性能を保証するための一般的に適用可能で完全に信頼できる方法としてのプログラム検証が成功するかどうかは、 理論的な可能性すらない（Fetzer 1988: 1）。

実際、この問題は、フェッツァーが正しさに対するホアレの数学的スタンスを特徴づけるために使用したテキストの中で、ホアレによって言及されています。

プログラムの正しさ、そのコンパイラ、コンピュータのハードウェアのすべてが数学的な確実性をもって確立されたとき、プログラムの結果に大きな信頼を置くことが可能になり、電子機器の信頼性によってのみ制限された自信をもって、その特性を予測することができるようになるだろう。(Hoare 1969: 579)

計算システムは底辺の物理システムであり、因果関係があるために予測不可能な振る舞いが生じる可能性があることは、すべての人が同意しているように思われた。実際、定理証明や証明チェッカを使っても、結果は経験的な知識しか得られない。証明判定機は、物理マシン上で動作するプログラムです。これは、実装されたプログラムであり、その結果は物理的な計算に依存しています。したがって、あるレベルでは、いくつかの物理マシンの操作がその仕様を満たしていることを示す必要があります。テストと検証は、経験的な証拠を得ることしかできないように思われます。実際、プログラム証明の複雑さから、プログラマは物理テストを抽象的なプログラムが仕様を満たしている証拠とみなすようになりました。ここでは、基礎となる実装が正しいという前提があります。しかし、それは経験的な証拠にすぎません。

これとは明らかに対照的に、Burge (1998)は、このようなコンピュータ証明の知識は、先験的知識として捉えることができると主張しています。Burgeによれば、先験的知識は、その正当化のために、いかなる感覚的経験にも依存しない。例えば、赤が色であるという知識は、その知識を持つためには赤の感覚的経験が必要であるにもかかわらず、先験的知識である可能性があるとしています。これが正しければ、コンピュータ支援による正しさ証明に関する先験的な主張と事後的な主張との間のギャップは解消されるが、経験的な主張が前者のカテゴリーに入ることができるように、先験的な知識と事後的な知識との境界を再描画することによってのみ、このギャップは解消さまする。数学的証明におけるコンピュータの使用の性質については、Hales 2008; Harrison 2008; Tymoczko 1979, 1980を参照のこと。
残念なことに、実際にはここまでには至っていないことが多いのです。一般的に、ソフトウェアエンジニアは古典的な正しさの証明を手で、あるいは自動的に構築することはありません。ソフトウェアの仕様に対するテストは、一連のテストケースに基づいて行うのが一般的には最善の方法です。もちろん、これは決して数学的な意味での正しさをもたらすものではありません。テストケースは決して網羅的ではありません(Dijkstra 1974)。さらに、基礎となる実装が正しいという隠れた前提があります。せいぜい、これらの経験的手法はシステム全体について何かを教えてくれます。実際、システムの状態空間の大きさは非常に大きく複雑であるため、直接テストすることさえ不可能な場合があります。実際には、複雑なシステムの振る舞いを近似した数理モデルを構築することが、私たちができる最善の方法です。
ACMのフォーラム(例えば、Ashenhurst 1989; Technical Correspondence 1989)で行われた全体的な正しさの議論は、プログラムが技術的なアーティファクトとみなされるときに、いくつかの視点に置かれます。しかし、これはもう一つの話題を残します。物理的な構造に到達したとき、正しいという概念はどのように動作するのでしょうか?

7.4 物理的な正しさ

物理的なデバイスがその仕様を満たすためには何が必要でしょうか？正しい物理的な実装であるためには何が必要なのでしょうか？多くの現代的な分析の出発点は、しばしば単純なマッピングのアカウントと呼ばれています。
単純なマッピングのアカウントによると、(i)物理システムSは抽象仕様の正しい実装として実行されます。Cに代入された状態からのマッピングがある場合に限ります。抽象的な仕様で定義された状態に物理的な記述によって(ii)物理状態間の状態遷移が抽象状態間の状態遷移を反映するように。(ii)項は、次のような形式の抽象的な状態遷移に対して、次のように要求する。s1→s2に対応する物理的な状態にある場合はs1にマッピングされた物理的な状態になります。単純なマッピングの計算が何を意味するのかを説明するために，抽象的なマシンの例を考えてみましょう(§2.1)．そしてその後、可能な状態は、(0, 0)、(0, 1)、(1, 1)、(1, 1)、(1, 0)の4つしかありません。更新操作の計算テーブルは、手で簡単に計算でき、入出力のペアを持つテーブルの形をしています。例えば、更新(r,1)は状態(0,0)を状態(0,1)に送ります。単純なマッピングの説明は、抽象的な状態遷移が物理的なバージョンで複製されるような方法で、物理的なシステムを抽象的なシステムにマッピングすることができることを要求するだけです。
残念ながら、そのような装置は簡単に手に入ります。物理的な状態の役割を果たすのに十分なものがあれば、ほとんどのものが、実装とは何であるかというこの非常に弱い要求を満たすことができます。例えば、更新テーブルとして配置された色石の任意のコレクションは、テーブルを実装するために取られます。単純な写像勘定では、拡張的な一致を要求しているに過ぎません。それは事実上の要求である。これは、ほぼすべての物理システムが任意の計算を実装するパン計算主義の形態につながります。
パン計算主義の危険性は、何人かの著者(D.J. Chalmers 1996; Egan 1992; Sprevak 2012)を駆り立て、可能な解釈のクラスを何らかの形で制限する実装の説明を提供しようとしています。特に、ある著者(D.J. Chalmers 1996; Copeland 1996)は、そのような解釈に因果的制約を課そうとしている。1つの提案は、物質的条件(システムが物理的状態にある場合)に置き換えることであす。s1を対事実上のものに置き換えることができます対照的に、意味論では、ある計算は、その計算が何を達成しようとしているかを特定する意味的な側面と関連づけられなければならないと主張しています(Sprevak 2012)。例えば、物理的なデバイスは、ANDゲートやORゲートと解釈することができます。これは、何をデバイスの定義とするかに依存しているように思われます。このような定義がなければ、人工物が何であるかを固定する方法はありません。統語的な説明では、統語的であるとみなされる物理的な状態だけが計算記述にマッピングされ、それによって計算状態であるとみなされることを要求しています。 もちろん、何が構文的な状態としてカウントされるかについては、まだ見ていません。その概要は、(Piccinini 2015; 物理システムにおける計算のエントリも参照のこと)にある。。
このように、抽象的な構造と物理的な構造は、単に一致しているだけでなく、前者を後者に 対して規範的なガバナンスを持っていると見なす意図によってもリンクしていると、Turner (2012)は主張しています。このアカウントでは、計算は抽象的な仕様によって機能が固定化された技術的なアーティファクトです。この関係は、理論と物理的対象の関係でも、構文的なものと意味的解釈の関係でもありません。
しかし、ここには曖昧さがあり、それは意味解釈を主張する者（Sprevak 2012）と反対する者（Piccinini 2008）の間の議論に反映されています。プログラムを考えてみましょう。プログラムの機能とは何か？それは意味的解釈によって固定されているのか、それとも仕様によって固定されているのか。ここでの曖昧さは、プログラミング言語の一部としてのプログラムの機能なのか、より大きなシステムの一部としての役割なのかに関係しています。言語のプログラムとしては、言語全体の意味論によって固定されています。しかし、より大きなシステムの一部としてプログラムを使うためには、プログラムが何をするのかを知る必要があります。より大きなシステムの一部としてのプログラムの機能は、その仕様によって与えられます。仕様書によって計算が選択された場合、プログラムがどのように仕様書を達成するかは、システム設計者には無関係です。仕様はインタフェースとして機能し、システム設計者が採用する抽象化のレベルが中心となります。

7.5 誤計算

これまで述べてきたことから、実装されたプログラムの正しさが、自動的に計算アーティファクトの機能性を確立するわけではないことがわかります。チューリング(1950)はすでに機能のエラーと結論のエラーを区別しています。前者は、ある高レベルの言語プログラムの命令を実行できない欠陥のある実装によって引き起こされます。結論の誤りは、正しい抽象機械を特徴づけますが、それにもかかわらず、それが達成することになっていたタスクを実行することができません。これは，プログラムが正しくインスタンス化されている仕様が，そのようなプログラムに対するユーザの要求を適切に表現していない場合に起こるかもしれません。どちらの場合でも、正しいプログラムを実装しているマシンは、ミスコンピュートと言うことができます。
チューリングの機能エラーと結論エラーの区別は、ミスコンピュテーションの完全な分類法に拡張されました(Fresco & Primiero 2013)。提供された分類は、ソフトウェア開発プロセスで識別できる抽象度の多くの異なるレベルに基づいて確立されています。機能仕様レベルでは、計算成果物が満たすべき機能要件を指し、ユーザ、企業、ソフトウェアアーキテクト、または実現すべきシステムの許容される動作に対する制約を表現する他の一般的な利害関係者によって進められます。設計仕様レベルでは、これらの要件は、システムの状態とそれらの状態間の遷移を可能にする条件を詳細に記述したシステム設計記述の観点から、より正式に表現されます。設計仕様レベルの仕様は、アルゴリズム設計レベルで、通常は高レベルのプログラミング言語を使用して、適切なアルゴリズムでインスタンス化されます。アルゴリズム実装レベルでは、アルゴリズムは、アセンブリ言語とマシンコード命令によって、ソフトウェアに実装することができますが、ハードウェアに直接実装することもできます。最後に、アルゴリズム実行レベルとは、実行時の実行を指します。
エラーには、概念的なもの、物質的なもの、実行可能なものがあります。概念的なエラーは、命題の接続法正規形で表現された仕様の整合性を要求する妥当性条件に違反し、物質的なエラーは、その仕様の集合に関するプログラムの正しさの要求に違反し、実行可能なエラーは、何らかの欠陥のある実装ハードウェアによって物理的な制約が破られた場合に発生します。
実行可能なエラーは明らかにアルゴリズムの実行レベルでのみ発生し、Turingの機能エラー(1950)に対応します。概念的なエラーと物質的なエラーは、機能仕様レベルからアルゴリズムの実装レベルに至るまで、抽象化されたどのレベルでも発生する可能性があります。概念的なエラーは間違いを引き起こしますが、物質的なエラーは失敗を誘発します。たとえば、 機能仕様レベルでのミスは一貫性のない要件セットで構成され、 アルゴ リ ズ ム実装レベルでは無効なハー ド ウ ェ ア設計に対応する可能性があります （真理関数接続のための ロ ジ ッ ク ゲー ト の選択など）。また、設計仕様レベルで発生する失敗は、機能仕様レベルで表現された機能要件のセットに関して不完全であるとみなされる設計に起因する場合があり、アルゴリズム設計レベルでの失敗は、プログラムがその仕様を満たしていないことが判明した頻繁なケースで発生します。誤り、失敗、および運用上の誤動作を超えて、スリップはアルゴリズム実装レベルでの誤計算の原因となります。スリップは、アルゴリズムのソフトウェア実装における構文上の欠陥や意味上の欠陥に起因する概念的なエラーや物質的なエラーである可能性があります。概念的なスリップは、プログラミング言語の構文的な規則に違反しているすべてのケースに現れ、物質的なスリップは、変数が使用されているが初期化されていない場合など、プログラミング言語の意味的な規則に違反していることを含みます。

抽象的な機械は［...］機能のエラーを起こすことができない。この意味で、「機械は決して間違いを犯すことができない」と言える。結論の誤りは，機械からの出力信号に何らかの意味が付加されている場合にのみ生じる。(Turing 1950: 449)

チューリングの発言に基づいて、技術的成果物の機能不全と誤動作を区別することができます(Floridi, Fresco, & Primiero 2015)。ソフトウェアは誤動作しかできないが、機能不全になることはない。アーティファクトトークンは、それが設計されたタスクを実行できない場合に機能不全を起こし、アーティファクトトークンは、それが要求されたタスクを実行することができるが、いくつかの望ましくない副作用を明らかにする傾向がある場合に機能不全を起こします。
ソフトウェア開発は、他のどの人工物の生産サイクルよりも多くの抽象化レベルで特徴づけられています。典型的なアーティファクトの生産は、機能仕様レベルと設計仕様レベルのみを含み、設計後、技術的な成果物は物理的に実装されます。上で見たように、ソフトウェア開発はまた、アルゴリズムの実装レベルによって特徴づけられる、すなわち、設計されたアルゴリズムは、ハードウェア実装の前に、何らかの高レベルの言語プログラムでインスタンス化されなければなりません。アーティファクト・トークンは、物理的な実装が機能仕様や設計仕様を満たさない場合に機能不全を起こすことがあります。このような機能不全は単一のトークンにのみ適用され、トークンが機能不全を起こすのは、実装された機能に関して同じ型の他のトークンと同じように動作しないからです。このため、機能仕様レベルと設計仕様レベルには機能障害は適用されません。これに対して、同じ型のトークンが実装された機能を実行できるかどうかの比較に依存しないため、人工物の型とトークンの両方が誤動作する可能性があります。このような場合には、「Together」を使用することで、「Together」は「Together」と「Together」の両方の機能を持つことになります。
ソフトウェアトークンは、機能仕様レベルと設計仕様レベルで指定された機能を全く同じ方法で実装しているため、機能不全に陥ることはありません。これは、それらの機能がアルゴリズム実行レベルで実行される前に、アルゴリズム実装レベルで実装されているという事実に起因しています。正しく実装された場合、すべてのトークンはアルゴリズム実行レベルで正しく動作します（運用上の誤動作が発生しない限り）。誤動作するソフトウェアタイプは、その機能を正しく実行することができますが、望ましくない副作用を引き起こす可能性があります。

8. 抽象化

抽象化はコンピュータサイエンスを容易にします。抽象化がなければ、数値アルゴリズムのプログラミングから、航空管制システム、インタラクティブな証明開発フレームワーク、コンピュータゲームなどのソフトウェアの高度化へと発展することはなかったでしょう。それは、現代のプログラミング言語や仕様言語の豊かな型構造に現れており、抽象化のメカニズムを内蔵したこれらの言語の設計を支えています。これが、ポリモーフィズム、データ抽象化、クラス、スキーマ、デザインパターン、継承などの概念の発明を推進してきました。しかし、コンピュータサイエンスにおける抽象化の本質とは何でしょうか？それは一つの形だけなのでしょうか？それは数学で見られるのと同じ概念なのでしょうか？

8.1 コンピュータサイエンスにおける抽象化

コンピュータサイエンスの抽象化には様々な形があります。ここでは、これらを体系的に説明しようとはしません。しかし、Goguen (Goguen & Burstall 1985)は、このような多様な形態のいくつかを記述しており、以下の例はその例です。

1つの種類は、繰り返しコードという考え方を含んでいます。プログラムのテキストには、おそらくパラメータが与えられ、名前が与えられます（手続き的抽象化）。スケンプの用語では、手続きは、構造の類似性が共通のコードであるところに新しい概念をもたらします。形式的には、これはラムダ微積分の抽象化です（ラムダ微積分のエントリを参照してください）。パラメータは型でさえあるかもしれないし、これは多相性の様々なメカニズムにつながり、二次ラムダ微積分のような数学理論で形式化されるかもしれません（Hankin 2004）。

再帰は、操作やメカニズムの抽象化の初期の例です。これは、基礎となるマシンのメカニズムから抽象化します。これにより、機械の操作を意識することなく複雑な問題を解決することができます。例えば、再帰はスタックなどのデバイスに実装されていますが、再帰の利用者は原則としてこれを知る必要はありません。

プログラミング言語や仕様言語の型構造は、その言語のオントロジー、つまり表現や問題解決のために自由に使える実体の種類を決定します。多くの場合、型は言語の抽象度を決定します。型のコンストラクタの豊富なセットは、表現の表現システムを提供します。抽象型と再帰型が一般的な例です。

オブジェクト指向設計では、パターン(Gamma et al. 1994)は、ソフトウェアシステムに見られる共通の構造から抽象化されている。ここでは、抽象化はインターフェイスの手段である。それは、オブジェクトの実装をその仕様から切り離します。例えば、抽象クラスは、そのメソッドの型構造以外は何も提供しないことで、インターフェイスとして機能します。

さらに、数学（Mitchelmore & White 2004）、コンピュータサイエンス、哲学（Floridi 2008）にも抽象化のレベルがあります。数学における抽象化は、より多くの抽象的な概念を求めて終わりのない探索の中で、互いに重ね合わされている。同様に、コンピュータ科学では、抽象度のレベルを下げていくアーティファクトのシーケンスを含む複雑なプロセスを経て、実際の物理的なデバイスに到達するまでのアーティファクトの設計と構築を扱っています。

8.2 情報の隠蔽

数学では、一度抽象化が確立されると、物理的なデバイスは取り残されます。そのため、抽象化は自己完結的です。抽象的な数学的オブジェクトは、それが定義されているシステムからのみ意味を得ます。唯一の制約は、新しいオブジェクトが、以前の意味を参照することなく操作できる一貫したシステム内で互いに関連していることです。自己完結が最も重要です。例外なく。

少なくともこの点では、コンピュータサイエンスの抽象化は数学の抽象化とは根本的に異なると主張する人もいます(Colburn & Shute 2007)。彼らは、計算の抽象化は実装の痕跡を残さなければならないと主張しています。情報は隠されているが、破壊されてはいません。ある抽象化レベルでは無視される詳細な情報（例えば、プログラマーは特定の変数に関連付けられたメモリ内の正確な位置を気にする必要はない）は、低い抽象化レベルでは無視されてはなりません（例えば、仮想マシンがすべてのメモリ割り当てを処理する）。すべてのレベルにおいて、計算のアーティファクトは実装の存在に決定的に依存します。例えば、クラスは抽象的なものを除いて、メソッドの実装の詳細を隠していても、実装を持たなければなりません。これは，計算アーティファクトには機能と構造の両方があるという考え方と一致しています。計算抽象は，抽象的な装いと実装の両方を持っています．

しかし、問題はそれほどクリーンカットではありません。数学における抽象化が、その関係性によって意味が定義されるオブジェクトを生成するのは事実ですが、コンピュータサイエンスにおいても同じことが言えます。抽象的な概念は、そのような独立した意味を持たない限り、規範的な機能を持つことはできません。さらに、ある種の構成的数学は、実装トレースが存在しなければならないという点で、コンピュータサイエンスに似ています。すなわち行間を読むことによって、証明から実装情報を常に回復することができなければなりません。もちろん，これは古典数学の場合ではありません．

さらに、多くの人は、数学的抽象化は物理的なルーツを完全には残していないと主張するでしょう。

数学の有用性の一つの側面は、計算ができる機能である。買い物代を計算するためにコインを交換する必要はないし、ロケットを発射しなくてもロケットの旅をシミュレーションすることができる。ますます強力になった数学理論（コンピュータは言うまでもなく）は、効率と信頼性を着実に向上させている。しかし、計算機能は、結果が現実を予測しなければ意味がない。予測は、数学的モデルが現実の側面を適切なものとし、それが適切かどうかは経験によって検証できる範囲で成功する。(Mitchelmore & White 2004: 330)

公理主義的方法がこのように成功しているのはなぜだろうか？その答えは，大部分が，公理が実際に意味のある正しいパターンを捉えているからである。... 誰もが任意の定理のリストを書き留めて，そこから定理を証明することを妨げるものは何もない。しかし，それらの定理が実用的に応用できる可能性は本当に低い。... 多くの基本的な数学的対象（特に数やその演算のようなより初歩的なもの）は，明らかに現実をモデル化している。後の発展 (組合せ論や微分方程式など) は、これらの基本的な考えの上に構築されているので、間接的であっても現実を反映している。したがって、すべての数学は現実と何らかのリンクを持っている。(Devlin 1994: 54-55)

コンピュータサイエンスの抽象化と数学の抽象化の違いは、それほど鋭くはないように見えます。しかし、重要な概念的な違いがあるように見えます。ターナー(2011)が正しいとすれば、コンピュータサイエンスでは、抽象化された相手が関係の中で支配的な存在です。それが正しさを決定します。数学は世界をモデル化するために存在し、それを正確にモデル化しなければなりません。コンピュータサイエンスでは、抽象化とそのソースとの関係は、仕様とアーティファクトの関係であり、数学では、一方ではモデルや理論、他方では現実との関係です。物事がうまくいかないときの責任の所在は、コンピュータサイエンスではアーティファクトにありますが、数学ではモデルにあります。

9. コンピュータサイエンスの認識論的地位

コンピュータ・サイエンスの認識論的地位を定義する問題は、コンピュータ・サイエンスが1960年代から1970年代にかけて数学とは異なる独立した学問分野となってからすぐに生じました(Tedre 2011)。1970年代以降、コンピュータサイエンスは、数学的、経験的、工学的な方法を利用する限り、部分的には数学的な規律として、部分的には科学的な規律として、部分的には工学的な規律として考えられなければならないことが明らかになっています(Tedre & Sutien 2008)。それにもかかわらず、コンピュータサイエンスを大部分が数学的規律として捉えるべきなのか、工学の一部門として捉えるべきなのか、それとも科学的規律として捉えるべきなのか、という点で議論が行われました。

9.1 数学的規律としてのコンピュータサイエンス

コンピュータサイエンスの各認識論的特徴付けは、存在論的、方法論的、認識論的なコミットメント、すなわち、計算成果物の性質、ソフトウェア開発プロセスに関与する方法、およびそれによって関与する推論の種類についての仮定に基づいています。
コンピュータ科学の数学的性質の保持者は、プログラムが数学的実体であり、理論的コンピュータ科学の形式的方法によって提供される純粋に演繹的推論を追求することができるものであると仮定しています。4.2節と5.1節で検討したように、ダイクストラ (1974)とホア (1986)は、プログラムの命令が数学的な文として認められることと、プログラミング言語の形式的な意味論が公理系で与えられることを明快に述べています (Hoare 1969)。プログラムの仕様が形式言語で進められ、プログラムのコードが同じ形式言語で表現されていれば、形式的意味論は正しさを証明する手段を提供します。したがって、計算アーティファクトの振る舞いに関する知識は、数学的な正しさの証明に関わる演繹的推論によって得られます。
計算システムについて知ることができることについてのこのような合理主義的楽観主義(Eden 2007)の根底にある理由は、計算システムが人工物、つまり人間が作ったシステムであり、そのようなものとして、その動作を確実に予測することができるということです(Knuth 1974b)。
計算の数学的分析の元々の動機は、数学的論理学から来ています。その起源は、述語微積分の決定可能性に関するヒルベルトの疑問（Hilbert & Ackermann 1928）にあります。論理の任意の文が証明可能かどうかを決定するためのアルゴリズム、手順は存在するのでしょうか（The Entscheidungsproblem）？この問題に対処するためには、論理学や数学における効果的な方法や機械的な方法という非公式な概念の厳密なモデルが必要でした。これを実現するには，まず第一に数学的な努力が必要です。
理論計算機科学の中心的な関心事ではありますが、計算可能性と複雑性の話題は、「チャーチ・チューリングのテーゼ」、「計算的複雑性理論」、「再帰関数」に関する既存のエントリでカバーされています。

9.2 工学分野としてのコンピュータサイエンス

1970年代には、プログラムの複雑さの増大、日常的な文脈でのソフトウェアシステムの応用の増加、そしてそれに伴う市場の需要の急増により、学者と実務家の両方のコンピュータ科学者の関心は、プログラムの正しさの証明から、それらのシステムの複雑さを管理し、その信頼性を評価する方法へと逸脱していきました(Wegner 1976)。実際、モジュラープログラムの形式的な仕様を提供したり、非常に複雑なプログラムを同じ形式言語で表現したり、組み込みが多く、ユーザと対話するシステムの入力を提供したりすることは、現実的には不可能でした。正しさを数学的に証明することは、ほとんど実現不可能であることが判明しました。コンピュータ科学の研究は、むしろ、プログラムのコードのエラーの分布を推定するという意味で、信頼性と呼ばれる、正しいことの統計的評価を提供できるテスト技術に向かって発展していきました(Littlewood & Strigini 2000)。
コンピュータ科学は、土木工学が橋梁や航空宇宙工学が飛行機の信頼性を評価するのと同じように、コンピューティングシステムの信頼性を評価します(DeMillo et al. 1979)。特に、経験的科学が存在するものを調べるのに対し、コンピュータ科学は存在しうるもの、すなわち成果物をどのように生成するかに焦点を当てており、それゆえに「数学の工学」として認められるべきです(Hartmanis 1981)。同様に、科学的な問いかけが研究される現象に関する法則の発見に関与しているのに対し、コンピュータ科学の実践では、後者の方がむしろ研究される現象の生成、すなわち計算アーティファクトに関する法則に関与しているため、適切な法則を特定することはできません（Brooks 1996）。

9.3 科学的規律としてのコンピュータサイエンス

ソフトウェアテストや信頼性測定技術は、それにもかかわらず、コードの欠陥がないことを保証することができないことで知られています(Dijkstra 1970)。多くの場合、特に、いわゆる安全性が要求されるシステム（飛行機、ロケット、原子力発電所などの制御装置など）の評価においては、形式的な方法と経験的な試験の両方が、計算アーティファクトの正確性と信頼性を評価するために使用されています。計算機科学は、演繹的推論と帰納的確率論的推論の両方を利用して計算アーティファクトを検証するという点で、 科学的な学問であると理解できます（Denning et al. 1981; Denning 2005, 2007; Tichy 1998; Colburn 2000）。実際、§6で検討されているように、検証とテストの方法は、実装されたコンピューティングシステムの動作に関する仮説を推し進め、それらの仮説を支持する証拠を(アルゴリズム的または経験的に)提供することに、しばしば共同で関与しています。
コンピュータ科学は方法論的には経験科学と同等であるというテーゼは、Newell, Perlis, Simon の 1967 年の『Science』への書簡（Newell et al. 1975年のターニング賞の講演では、ニューウェルとサイモンは次のように主張しています。

コンピュータ科学は経験的な学問である。私たちはこれを実験科学と呼んでいるが、天文学や経済学、地学のように、観測や経験のユニークな形のいくつかは、実験的方法という狭いステレオタイプには当てはまらない。それにもかかわらず、それらは実験である。新しい機械が作られるたびに、それは実験である。実際に機械を構築することは自然に質問を投げかけることであり、私たちは機械の動作を観察し、利用可能なすべての分析・測定手段を用いてそれを分析することによって、その答えを聞くのである。(ニューウェル及びサイモン1976: 114)

ニューウェルとサイモンのチューリング賞受賞講演以来、コンピュータ科学は経験的な科学ではあるが、特別な種類の科学として理解されることが明らかになってきました。実際、コンピュータ科学の認識論的地位に関する現在の議論の多くは、それがどのような科学であるかを定義する問題（Tedre 2011）、特にコンピュータ科学における実験の性質（Schiaffonati & Verdicchio 2014）、コンピューティングにおける法則や定理の性質（もしあるとすれば）、コンピュータ科学とソフトウェア工学の間の方法論的な関係（Gruner 2011）に関係しています。

10. コンピュータ倫理

コンピュータ倫理とは、コンピュータ技術の性質と社会的影響の分析、およびそのような技術の倫理的利用のための政策の対応する策定と正当化のことである（Moor 1985: 266）。

コンピュータ倫理学は、情報技術の広範な応用から生じる倫理的、社会的、政治的問題に関する情報倫理学のサブフィールドです（コンピュータ倫理学と情報倫理学の分析については、コンピュータ倫理学と情報倫理学のエントリを参照）。コンピュータ倫理学は、ノーバート・ウィーナーの著書『サイバネティクス』（1948年）にルーツを持ち、応用倫理学の緊急かつ著名なサブフィールドとして急速に発展しました（コンピュータ倫理学の歴史的発展の概要については、Bynum 2008を参照）。興味深いことに、ウィーナーの著書『神とゴーレム』（1964年）では、現在議論されているコンピュータ倫理のトピックのほとんどが、セキュリティ、プログラマーの責任、情報ネットワークなど、すでに提唱されていました。その他の問題としては、プライバシー、ソーシャルネットワーク、ソフトウェアの所有権などが挙げられます。
コンピュータ倫理学は、応用倫理学やコンピュータ科学哲学とは異なる独立した学問として発展してきました。このセクションでは、コンピュータ倫理学の中の2つのトピックを分析します。特に、ソフトウェアシステムのオントロジーは、プログラムの所有権に関する議論に影響を与え、ソフトウェア開発の方法論は、開発者の道徳的責任を明確にし、区別するのに役立ちます。

10.1 計算アーティファクトの知的財産権

コンピュータ倫理学における主要かつ進行中の議論の一つは、ソフトウェアの所有権の倫理的、社会的、法的側面に関するもので、プログラマーやソフトウェア会社が計算成果物に対して知的財産権を行使できるかどうか、そのような所有権をどのように保護できるか、すなわち、著作権か特許か、著作権や特許制度はソースコードの再利用やコピーをどのようにどの程度認めるべきか、ソフトウェアは自由であるべきか、著作権で保護されていないべきかといった問題を扱っています。
財産は知的実体にも拡大すべきであり、物理的な商品だけに限定すべきではないという主張は、3つの主要な議論がなされてきました（Moore 2001, 2008）。人格に基づく議論は、ヘーゲルの『権利哲学』を想起し、肉体的または知的労働の生産物は、労働者の感情、性格、能力の実現であると主張しています。感情、性格、能力が労働者によって所有されている限り、知的生産物におけるそれらの外部化は、詩であれ、歌であれ、コンピュータ・プログラムであれ、労働者によって所有されています(Moore 2008: 108-110)。パーソナリティに基づく議論の批判者は、著作者の感情や能力の外部化は知的製品の使用権を移転するが、財産権は移転しないと主張します。
「ルール・ユーティタリアン」の議論は、コンピュータ・プログラムを著作権や特許制度で保護することで、新製品の増加やイノベーション、それに対応する社会的有用性がもたらされるというものです(Moore 2008: 110-119)。知的財産権に対するルール・ユーティタリアンなアプローチの反対者は、ソフトウェアの著作権や特許がイノベーションと生産を促進するというテーゼに異議を唱えています。第一に、彼らは、イノベーションは、学術レベルでも産業レベルでも、政府が研究プロジェクトに資金を提供したり、報酬モデルによって直接的に支援することができると主張しています(Shavell & Ypersele 2001)。第二に、ソフトウェアの著作権と特許はしばしば企業の独占を可能にしており、これは独占を維持するためにイノベーションを促進するのではなく、むしろ阻害しています。
ソフトウェアの知的財産権に関する議論のほとんどは、『政府に関する第二条約』（Locke 1690年、John Lockeに関するエントリも参照してください）で示されたJohn Lockeの財産権に関する議論に焦点を当てています。ロックは、自然の状態では、すべての自然財は共通のものであり、共通の財を自分の労働に混ぜることで、そのような財の所有権を主張することができると主張したことで有名です。ロックの哲学は、西欧諸国の自由主義の伝統の基礎となっています。物質的なものと知的なものの主な違いの一つは、後者のものは複製が可能であるということであり、これはソフトウェアについては特にそうである。哲学者の中には、ロックの議論がソフトウェアの知的財産権を正当化すると主張する人もいれば、ロックの哲学はむしろフリーソフトウェアの見解を支持すると主張する人もいます。ロックの哲学では、物質的財の所有権は労働によって正当化されますが、「十分な量があり、他の人のために残されたように良いものがある場合」(Locke 1690: Section 27)、所有者は他の人に損失を与えることなく取得から利益を得ることができます(Moore 2008: 119-128)。知的実体の所有は、物質的実体の所有と同様、排他的なものではありません。数学関数やプログラムの仕様書のような知的対象物は、多くの人が同時に所有することができるのに対し、ある人が車を所有している場合、同じ車を隣人が所有することはできません。したがって、たとえば高度な言語プログラムを所有していても、他人にとっては損をすることにはならず、ロックの「他人のために十分に、そして良いものが残されている」という条件は常に満たされています。
一方、ロックによれば、物質的実体は有限であり、誰もが好きなものを所有することは不可能であるため、物質的財の所有は正当化されるとしています（Kimpa 2005）。しかし、知的所有物は、多くの人が同時に共有することができ、その誰もが奪われることはありません(Kinsella 2001)。ソフトウェアは販売することができますが、一度購入すると、購入者はソフトウェアを所有し、そのソフトウェアを自由にコピーしたり、改変したりすることも含めて、彼女が望むことは何でもできるのです(Free Software Foundation 1996 in Other Internet Resourcesを参照してください)。実際、ソフトウェアは知的財産であることから、所有者の誰にも損失を与えることなく共有することができます。
ソフトウェアの財産保護、すなわち、著作権法や特許法による保護について推論するときに問題が生じます。米国の法律では、著作権は、文学、音楽、演劇、視覚芸術、建築物の分野で、有形の形式（文章、描写、彫刻、建築物など）で表現されたオリジナルの作品の作者を保護しています。著作権は、著作者および前者の許可を得た者に、複製、複製、上演、販売または複製物を共有する権利、および保護された原著作物に基づく著作物を創作する権利を付与するものである。アイデア、理論、手順、および方法は、著作権の保護から除外されます。特許は、発明者を保護し、他人が発明を販売、使用、製造することを禁止します。特に、実用新案特許には、プロセス、機械、製造物の保護が含まれ、意匠特許には、製造物の新しいデザインやオリジナルのデザインが含まれ、植物特許には、植物の新しい品種の生産が含まれます。
著作権は、著作者に与えられたテキストをコピーする権利を与えます。アイデアには著作権がありませんが、テキストに表現されたアイデアには著作権があります。ある人によると、著作権はソフトウェアの所有権を保護するための最も適切なツールであると言われています(Mooers 1975)。アルゴリズムが抽象的な数学的なアイデアであるのに対し、高レベル言語プログラムはそのアルゴリズムをテキストで表現したものであり、著作権の対象となります。このような主張はあまりにも単純であり、ソフトウェアの適切なオントロジーを考慮していないという反論もあります（Rapaport 2016, See Other Internet Resources）。実際、計算アーティファクトは、仕様-実装の階層として、抽象度の多くのレベルで検討することができます。ここでの主な問題は、何が著作権的に可能なのかを理解することであり、関数なのか、アルゴリズムなのか、プログラムなのか、プログラムの機械実装なのか、ということです。例えば、アルゴリズム自体は、それが実装する関数の表現と考えることができ、結果的に著作権の対象となります。もう一つの問題は、著作権侵害に関するものです。プログラムがアルゴリズムの保護された表現とみなされる場合、著作権侵害は類似したプログラムコードの場合にのみ発生します。しかし、異なるアルゴリズムをインスタンス化した異なるプログラムを実装して得られた2つのプログラムが動作的に等価（または類似）である場合を考えてみましょう。ソフトウェアの著作権に関するMooersのアプローチによれば、このような場合には侵害は発生しないとされています（Rapaport 2016: 第13章、その他のインターネットリソースを参照）。
特許についても同様の問題が生じます。Allen Newell (1986)はソフトウェア特許に反対しました。彼は、数学的な記述や物理法則が特許にならないのと同じ理由で、アルゴリズムは特許にならないと主張しています。特許を取得できるのは、プロセスとそれを実行する計算機だけです。しかし、あるアーティファクトを定義する階層における抽象度は、アルゴリズムをプログラムや実装と区別できるとは限りません。これは、例えば、特別な目的の機械で直接実行可能なアルゴリズムの場合に当てはまります。

10.2 コンピューティング実務者の道徳的責任

コンピュータサイエンスは、道徳的に中立な学問とは考えられません(Gotterbarn 1991, 2001)。環境内で相互作用する計算アーティファクトによって誤計算が表示されると、開発者はしばしば、適切な仕様を開発者に提供できなかったクライアントを非難したり、ソフトウェアのテストではエラーがないことを保証できないという事実を訴えたり、より一般的にはプログラムの複雑さを非難したりすることがあります。いずれにしても、コンピューティングの実務家は責任を認めません。そうすることで、彼らは、ソフトウェアを開発する過程で、単に仕様をインスタンス化してプログラムを実装するだけではなく、さらに社会にサービスを提供していることを認識することができません。負の責任と正の責任の間には、区別することができます(Ladd 1988)。負の責任は、非難や法的責任を回避し、そのアーティファクトが社会に与える潜在的な影響や影響を考慮することなく、正しいアーティファクトの開発を追求するソフトウェア開発者を特徴づけます。対照的に、積極的な責任は、開発されたマシンがユーザの間で持つかもしれない結果を考慮します。正しい計算機システムは、クライアントから提供された仕様のセットによっていくつかの望ましくない動作が抑制されていない場合には、依然として有害である可能性があり、肯定的な責任を持つプログラマは、そのひとがそれらの欠陥を認識している場合には、クライアントと一緒にそれらの仕様を後退させる義務を感じなければなりません。
責任は、コンピューティングの実践者の道徳的な行動を規制するのに十分ではありません(Edgar 2003 [1997]: ch. 10)。実際、法律を破ったことを誰かのせいにするには、「因果関係の条件」と「意図の条件」が必要です。因果関係の条件には、違法な出来事を引き起こした人物（引き金を引いた殺人者など）を特定することが含まれ、意図の条件には、そのような人物の意図（引き金を引いた人物が被害者を殺すことを意図していたかどうか）を把握することが要求されます。計算上、両方の条件を満たすことは困難です。コンピューティング・アーティファクトを誤演算させて一部の人に危害を加えたことについては、一人の人間も責められることはない。7.5節の誤計算の定義から、クライアント、設計者、プログラマー、エンジニアを含む多くの人々が有害な誤計算をもたらす因果の連鎖に関与していることがわかります。また，誰かを特定することは困難であり，もしそうならば，その中の誰が有害なアーティファクトを開発することを意図していたのかを特定することは困難です。特に、実務家が開発したシステムが後に悪意を持って使用された場合、実務家は法的に非難されることはありませんが、そのアーティファクトの悪意の可能性を認識していた場合には責任があるかもしれません。
コンピューティングの専門家の道徳的責任には、さまざまなグループの人々に対する責任が含まれます(Loi & Miller 2008)。クライアントとユーザに対する責任は、正確で信頼できるだけでなく、ユーザに望ましくない影響を与えない(または与えられない)ようなアーティファクトを実装することを必要とします。雇用者に対する責任は、あるタスクを割り当てる際に、雇用者がコンピューティングの専門家と共有する可能性のある（個人的、政治的、市場関連の）秘密情報を利用しないことを要求します。他の専門家に対する責任には、チームで仕事をするときに専門的な基準を満たすことと、同僚の仕事を尊重することが含まれます。最後に、公共に対する責任は、すべての計算アーティファクトが社会の福祉を目的としており、公共の福祉に影響を与える潜在的に危険な人工物の構築が、雇用者から要求された場合でも、専門家によって妨げられることを要求します(例えば、データシステムから個人情報を得ることができるプログラムをエンコードすることを要求されるようなものです)。
コンピューティングの専門家のこれらと他の道徳的責任は、複数のソフトウェア工学の「倫理規定」に成文化されています。例えば、ACMとIEEE Computer Societyによって開発された「Software Engineering Code of Ethics and Professional Practice」（その他のインターネットリソースを参照）は、具体的な状況でどのようにこれらの原則を満たすかを表現した8つの原則と条項を示しています(Gotterbarn, Miller, & Rogerson 1997)。

1 公共：コンピューティングの専門家は、常に「公共の安全、健康、および福祉と一貫した方法でのみ行動する」。
2 クライアントと雇用者：専門家は、クライアントと雇用者に対して忠実で信頼できる存在でなければならない。
3 製品：コンピューティングの専門家は、可能な限りエラーのない高品質の製品を提供することを約束する。
4 判断: 専門家は「専門家としての判断の独立性と評判の両方を守る」ことを約束する。
5 マネジメント: リーダーは、「公正に行動し、自らの義務と集団的義務を果たすために指導する者を奨励すべきである」としている。
6 専門職: コンピューティングの専門家は、その評判を維持し、向上させるべきである。
7同僚：チームワークが積極的にサポートされるべきである。
8 自己：コンピューティングの専門家のための継続的な教育は、常に自分の能力を向上させるために必要である。

倫理のコードを適用することは、具体的な状況では、原則がお互いにトレードオフ（Gotterbarn & Miller 2009）であることを見つけることができるので、簡単ではありません。一般的なケースとしては、エラーがないことを保証するために所定の成果物をテストするのに必要な時間がありますが、これは、市場のタイミングを満足させようとするクライアントや雇用主の圧力と衝突する可能性があり、あるいは、所定のコンピューティングシステムを実装するためのクライアントや雇用主の要求が公共の安全、健康、または福祉と衝突する、よりデリケートなケースがあります。8つの原則は、優先順位の階層に従ってリストアップされているので、コードは、場合によっては、競合する道徳原則の間の競合を解決するためのガイドラインを提供することができます。特に、「公共」がリストの一番上にあるということは、コンピューティングの実務者は、公共の利益に反するかもしれない成果物を実現するために、クライアントや雇用者の要求を常に拒否することを道徳的に約束されていることを意味します(Gotterbarn & Miller 2009)。
ここで言及する価値のある最後の問題は、デザイン・アプローチにおける価値観である（Nissenbaum 1998）。計算人工物は、共通の機能要件とともに道徳的価値を満たすべきです。正しさ、信頼性、安全性のほかに、計算システムは、正義、自律性、自由、信頼、プライバシー、セキュリティ、友情、自由、快適さ、平等などの道徳的価値をインスタンス化する必要があります。例えば、平等を満たさないシステムは、偏ったプログラム、つまり、「特定の個人または個人のグループを、他の人に有利になるように体系的かつ不当に差別する」アーティファクトです（例えば、航空会社をアルファベット順にリストアップするフライト予約システムは、リストの一番上にある会社を有利にすることが示されています）(Friedman & Nissenbaum 1996: 332)。誰もが、コンピューティングのアーティファクトがこれらの道徳的価値を満たすべきであることに同意するでしょうが、設計における価値観は、これらの価値観がソフトウェア開発における機能要件と同等に扱われるべきであることを保持しています(Flanagan, Howe, & Nissenbaum 2008)。このためには、(i) アーティファクトが使用される社会文化的文脈を考慮して、与えられたアーティファクトが満たすべき道徳的価値観を特定し、(ii) それらの価値観を設計仕様書に形式化し、その後実装することができるように定義し、(iii) 実装されたアーティファクトが指定された価値観を満たしているかどうかを、一般的なソフトウェアテスト技術、特に開発者間の内部テスト、制限された環境でのユーザーテスト、またはプロトタイプ、インタビュー、調査を使用して検証する必要があります。

11. コンピュータサイエンスの応用

ここでは、コンピュータサイエンスという学問の中核をなす哲学的な関心事に焦点を当ててきました。この分野の実際の応用についてはほとんど何も述べていませんが、多くの人がこの分野に可能性を与えていると主張する応用については、ほとんど何も述べていません。その応用とは、原子力発電所を動かすシステムやミサイルを目標に導くシステムなどの技術的なものだけでなく、計算生物学、認知科学、心の計算理論などの科学的なものも含まれています。しかし、これらのアプリケーションがどれだけ有用で素晴らしいものであっても、その目的は非常に特殊なものです。おそらく、計算生物学の目的は生物学的なものであり、認知科学の目的は心理学的なものであると思われます。これに対して、計算機科学の哲学の核心は、特定のアプリケーションの目標を持たない。それは、コンピュータをプログラミングするという一般的な活動に関係しています。

しかし、1つの応用は、しばしば主題の中核の一部であると見なされるほど中心的なものであます。それは人工知能です。それ自体は、LispやPrologなどのプログラミング言語の設計など、コアの発展に多くの貢献をしてきました。さらに、心の哲学や認知科学と強いつながりを持つ多くの哲学的な関心事を提起しています。実際、人工知能の哲学的な関心事には、はるかに古い歴史があります(Copeland 1993; Fetzer 1990)。このエントリでは、この分野の一般的な活動に専念しているため、この項目に含めるべき材料が多すぎます。幸いなことに、すでに人工知能における論理の役割に専念したエントリがあり、その主題は人工知能の哲学の将来のエントリの主題となる予定です。