Die Philosophie Der Informatik

2023 Autor: Noah Black | [email protected]. Zuletzt bearbeitet: 2023-11-26 16:05

Dies ist eine Datei im Archiv der Stanford Encyclopedia of Philosophy. Autoren- und Zitierinfo | Freunde PDF Vorschau | InPho-Suche | PhilPapers Bibliographie

Die Philosophie der Informatik

Erstveröffentlichung am 12. Dezember 2008

Die Philosophie der Informatik (PCS) befasst sich mit philosophischen Fragen, die sich aus der Reflexion über die Natur und Praxis der akademischen Disziplin der Informatik ergeben. Aber was ist letzteres? Es ist sicherlich nicht nur Programmierung. Schließlich sind viele Leute, die Programme schreiben, keine Informatiker. Zum Beispiel Physiker, Buchhalter und Chemiker. In der Tat würde die Informatik besser als sich mit der mit der Programmierung verbundenen Metaaktivität befasst. Allgemeiner und genauer gesagt befasst es sich mit dem Entwurf, der Entwicklung und der Untersuchung von Konzepten und Methoden, die die Spezifikation, Entwicklung, Implementierung und Analyse von Computersystemen erleichtern und unterstützen. Beispiele für diese Aktivität könnten das Entwerfen und Analysieren von Programmier-, Spezifikations- und Architekturbeschreibungssprachen sein;die Konstruktion und Optimierung von Compilern, Interpreten, Theoremprüfern und Typinferenzsystemen; die Erfindung logischer Frameworks und das Design eingebetteter Systeme und vieles mehr. Viele der zentralen philosophischen Fragen der Informatik umgeben und untermauern diese Aktivitäten, und viele von ihnen konzentrieren sich auf die logischen, ontologischen und erkenntnistheoretischen Fragen, die sie betreffen. Letztendlich ist Informatik jedoch das, was Informatiker tun, und keine genaue formelhafte Definition kann mehr als ein Leitfaden für die folgende Diskussion sein. In der Tat ist die Hoffnung dasViele der zentralen philosophischen Fragen der Informatik umgeben und untermauern diese Aktivitäten, und viele von ihnen konzentrieren sich auf die logischen, ontologischen und erkenntnistheoretischen Fragen, die sie betreffen. Letztendlich ist Informatik jedoch das, was Informatiker tun, und keine genaue formelhafte Definition kann mehr als ein Leitfaden für die folgende Diskussion sein. In der Tat ist die Hoffnung dasViele der zentralen philosophischen Fragen der Informatik umgeben und untermauern diese Aktivitäten, und viele von ihnen konzentrieren sich auf die logischen, ontologischen und erkenntnistheoretischen Fragen, die sie betreffen. Letztendlich ist Informatik jedoch das, was Informatiker tun, und keine genaue formelhafte Definition kann mehr als ein Leitfaden für die folgende Diskussion sein. In der Tat ist die Hoffnung das PCS wird schließlich zu einem tieferen Verständnis der Natur der Informatik beitragen.

Die Darstellung der philosophischen Landschaft der Informatik ist jedoch keine leichte Aufgabe. Glücklicherweise können traditionelle Bereiche der Philosophie eine intellektuelle und strukturelle Anleitung bieten. Zum Beispiel gibt es in den Philosophien der Mathematik und Physik zentrale Fragen bezüglich der Natur der behandelten Objekte, was Wissen ausmacht und wie man dieses Wissen erhält. Die Sprachphilosophie wirft Fragen nach Inhalt und Form einer semantischen Theorie für die natürliche Sprache auf. Es bringt die zugrunde liegenden ontologischen und erkenntnistheoretischen Annahmen des semantischen Unternehmens in den Vordergrund. Die Ontologie zeigt die Art der Dinge auf, wie sie individualisiert werden können, und ihre Rolle bei der Gestaltung unserer konzeptuellen Schemata. Die Philosophie der Logik bietet eine Darstellung und Analyse verschiedener Arten von logischen Systemen und ihrer Rolle im alltäglichen und spezialisierten Diskurs. Analogien und Ähnlichkeiten aus diesen und anderen Bereichen der Philosophie sollten sich als hilfreich erweisen, um einige der zentralen philosophischen Anliegen der Informatik zu identifizieren und zu klären. Der bestehende Einfluss dieser Disziplinen auf PCS wird im weiteren Verlauf entstehen. Insbesondere der zweite, dritte und vierte Abschnitt werden die Auswirkungen der Ontologie und der Philosophien der Sprache und Mathematik widerspiegeln.

• 1. Einige zentrale Probleme

• 2. Existenz und Identität

  • 2.1 Die duale Natur von Programmen
  • 2.2 Programme und Algorithmen
  • 2.3 Programme und Spezifikationen

• 3. Semantik

  • 3.1 Denotations- und Operationssemantik
  • 3.2 Implementierung und semantische Interpretation
  • 3.3 Semantik, Gleichheit und Identität

• 4. Beweise und Programme

  • 4.1 Beweise in der Informatik
  • 4.2 Beweise in der Mathematik
  • 4.3 Physische und abstrakte Korrektheit

• 5. Berechenbarkeit

  5.1 Die kirchliche These

• 6. Programmierung und Programmiersprachen

  • 6.1 Abstraktion
  • 6.2 Typen und Ontologie

• 7. Rechtliche und ethische Fragen

  • 7.1 Urheberrechte, Patente und Identität
  • 7.2 Richtigkeit und Verantwortung
• 8. Neue Wendungen oder neue Probleme?
• Literaturverzeichnis
• Andere Internetquellen
• Verwandte Einträge

1. Einige zentrale Probleme

Zunächst werden wir einige der zentralen Themen und Fragen aufzählen, die wir für wichtig halten. Auf diese Weise erhält der Leser einen kurzen Überblick über die Themen, die die künftige ausführlichere Diskussion ergänzen. Obwohl viele von ihnen in der Literatur nicht direkt angesprochen wurden und einer Klärung bedürfen, veranschaulichen diese Fragen die Art der Probleme, mit denen wir uns mit dem PCS befassen müssen.

1. Was sind Programme? Sind sie abstrakt oder konkret? (Moor 1978; Colburn 2004)
2. Was sind die Unterschiede zwischen Programmen und Algorithmen? (Rapaport 2005a)
3. Was ist eine Spezifikation? Und was wird spezifiziert? (Smith 1985; Turner 2005)
4. Unterscheiden sich Spezifikationen grundlegend von Programmen? (Smith 1985)
5. Was ist eine Implementierung? (Rapaport 2005b)
6. Was unterscheidet Hardware von Software? Gibt es Programme sowohl in physischer als auch in symbolischer Form? (Moor 1978; Colburn 2004)
7. Was sind digitale Objekte? Benötigen wir eine neue ontologische Kategorie, um sie unterzubringen? (Allison et al. 2005)
8. Was sind die Ziele der verschiedenen semantischen Theorien von Programmiersprachen? (White 2004; Turner 2007)
9. In welcher Beziehung stehen Fragen in der Philosophie der Programmiersprachen zu parallelen Fragen in der Philosophie der Sprache? (White 2004)
10. Bezieht sich das Prinzip der Modularität (z. B. Dijkstra 1968) auf die konzeptuellen Fragen der vollständigen Abstraktion und Kompositionalität?
11. Was sind die zugrunde liegenden konzeptionellen Unterschiede zwischen den folgenden Programmierparadigmen: strukturierte, funktionale, logische und objektorientierte Programmierung?
12. Welche Rolle spielen Typen in der Informatik? (Barandregt 1992; Pierce 2002)
13. Was ist der Unterschied zwischen operativer und denotationaler Semantik? (Turner 2007)
14. Was bedeutet es für ein Programm, korrekt zu sein? Wie ist der erkenntnistheoretische Status von Korrektheitsnachweisen? Unterscheiden sie sich grundlegend von Beweisen in der Mathematik? (DeMillo et al. 1979; Smith 1985)
15. Was begründen Korrektheitsnachweise? (Fetzer 1988; Fetzer 1999; Colburn 2004)
16. Was ist Abstraktion in der Informatik? Wie hängt es mit der Abstraktion in der Mathematik zusammen? (Colburn & Shute 2007; Fine 2008; Hale & Wright 2001)
17. Was sind formale Methoden? Was ist formal an formalen Methoden? Was ist der Unterschied zwischen einer formellen und einer informellen Methode? (Bowen & Hinchey 2005; Bowen & Hinchey 1995)
18. Was für eine Disziplin ist Informatik? Welche Rolle spielen mathematische Modellierung und Experimente? (Minsky 1970; Denning 1980; Denning 1981; Denning et al. 1989; Denning 1985; Denning 1980b; Hartmanis 1994; Hartmanis 1993; Hartmanis 1981; Colburn 2004; Eden 2007)
19. Sollten Programme als wissenschaftliche Theorien betrachtet werden? (Rapaport 2005a)
20. Wie wird Mathematik in der Informatik eingesetzt? Werden mathematische Modelle beschreibend oder normativ verwendet? (White 2004; Turner 2007)
21. Erfasst die Church-Turing-These den mathematischen Begriff einer effektiven oder mechanischen Methode in Logik und Mathematik? Erfasst es die Berechnungen, die von einem Menschen ausgeführt werden können? Gilt der Geltungsbereich für physische Maschinen? (Copeland 2004; Copeland 2007; Hodges 2006)
22. Kann der Begriff des rechnerischen Denkens einer philosophischen Prüfung standhalten? (Flügel 2006)
23. Was ist die geeignete Logik, um über die Richtigkeit und Beendigung des Programms nachzudenken? (Hoare 1969; Feferman 1992) Wie hängt die Logik von der zugrunde liegenden Programmiersprache ab?
24. Was sind Informationen? (Floridi 2004; Floridi 2005) Wirft dieser Begriff Licht auf einige der hier aufgeführten Fragen?
25. Warum gibt es so viele Programmiersprachen und Programmierparadigmen? (Krishnamurthi 2003)
26. Haben Programmiersprachen (und Paradigmen) die Natur wissenschaftlicher Theorien? Was verursacht einen Programmierparadigmenwechsel? (Kuhn 1970)
27. Wirft Software-Engineering philosophische Fragen auf? (Eden 2007)

Im Folgenden werden wir einige dieser Fragen etwas näher erläutern.

2. Existenz und Identität

Wie kategorisieren und individualisieren wir die Entitäten und Konzepte der Informatik? Was sind das für Dinge und was bestimmt ihre Identität? Einige sind beispielsweise eindeutig konkrete physische Objekte (z. B. Chips, Router, Laptops, Grafikkarten) und andere nicht (z. B. formale Grammatiken, abstrakte Maschinen, Theoremprüfer, logische Rahmenbedingungen, Prozessalgebren, abstrakte Datentypen). Die Charakterisierung einiger zentraler Begriffe wie Programme und Daten war jedoch problematischer. Insbesondere wurde der ontologische Status von Programmen als nicht ganz einfach angesehen, ebenso wenig wie die Frage nach ihren Identitätskriterien.

2.1 Die duale Natur von Programmen

Viele Autoren (Moor 1978; Rapaport 2005b; Colburn 2004) diskutieren die sogenannte duale Natur von Programmen. Auf den ersten Blick scheint ein Programm sowohl eine textuelle als auch eine mechanische oder prozessähnliche Gestalt zu haben. Als Text kann ein Programm bearbeitet werden. Die Manifestation auf einer maschinenlesbaren Festplatte scheint jedoch ganz andere Eigenschaften zu haben. Insbesondere kann es auf einer physischen Maschine ausgeführt werden. Nach dem Prinzip der Ununterscheidbarkeit von Identitäten (§3.3) können die beiden Gestalten also nicht dieselbe Einheit sein. Natürlich ist jeder, der von dieser Dualität überzeugt ist, verpflichtet, etwas über die Beziehung zwischen diesen beiden offensichtlichen Existenzformen zu sagen.

Ein unmittelbarer Vorschlag ist, dass eine Manifestation eines Programms eine Implementierung der anderen ist, dh die physische Manifestation ist eine Implementierung der textuellen. Selbst innerhalb der Grenzen der Informatik ist jedoch nicht sofort klar, dass sich das Wort Implementierung nur auf einen Begriff bezieht. Oft wird es verwendet, um auf das Ergebnis eines Kompilierungsprozesses zu verweisen, bei dem ein Programm in einer höheren Sprache (dem Quellcode) in die Maschinensprache (den Objektcode) umgewandelt wird. Genauso oft wird es verwendet, um sich auf den Prozess zu beziehen, bei dem der Quellcode irgendwie direkt in Hardware realisiert wird (z. B. eine konkrete Implementierung in Halbleitern). Und vermutlich ist dies der relevante Begriff. Aber ohne eine detailliertere philosophische Analyse des Begriffs der Umsetzung (§3.2) selbst (Rapaport 2005b),es ist unklar, wie dies die Diskussion vorantreibt; wir scheinen nur die Beziehung zwischen den beiden scheinbaren Existenzformen benannt zu haben. In ähnlicher Weise haben andere die Beziehung zwischen dem Programmtext und dem Programmprozess als ähnlich wie die zwischen einem Plan und seiner Manifestation als eine Reihe von physischen Handlungen beschrieben. Dies scheint jedoch nicht ganz analog zur Programm-Prozess-Paarung zu sein: Wir sind nicht versucht, den Plan und den physischen Prozess als unterschiedliche Manifestationen derselben Sache zu bezeichnen. Sind wir zum Beispiel versucht, uns einen Plan für einen Spaziergang und den tatsächlichen Spaziergang als verschiedene Facetten derselben Sache vorzustellen?andere haben die Beziehung zwischen dem Programmtext und dem Programmprozess als ähnlich wie die zwischen einem Plan und seiner Manifestation als eine Reihe von physischen Handlungen beschrieben. Dies scheint jedoch nicht ganz analog zur Programm-Prozess-Paarung zu sein: Wir sind nicht versucht, den Plan und den physischen Prozess als unterschiedliche Manifestationen derselben Sache zu bezeichnen. Sind wir zum Beispiel versucht, uns einen Plan für einen Spaziergang und den tatsächlichen Spaziergang als verschiedene Facetten derselben Sache vorzustellen?andere haben die Beziehung zwischen dem Programmtext und dem Programmprozess als ähnlich wie die zwischen einem Plan und seiner Manifestation als eine Reihe von physischen Handlungen beschrieben. Dies scheint jedoch nicht ganz analog zur Programm-Prozess-Paarung zu sein: Wir sind nicht versucht, den Plan und den physischen Prozess als unterschiedliche Manifestationen derselben Sache zu bezeichnen. Sind wir zum Beispiel versucht, uns einen Plan für einen Spaziergang und den tatsächlichen Spaziergang als verschiedene Facetten derselben Sache vorzustellen?Sind wir versucht, uns einen Plan für einen Spaziergang und den tatsächlichen Spaziergang als verschiedene Facetten derselben Sache vorzustellen?Sind wir versucht, uns einen Plan für einen Spaziergang und den tatsächlichen Spaziergang als verschiedene Facetten derselben Sache vorzustellen?

Vielleicht lässt sich die Sache am besten beschreiben, indem man sagt, dass Programme als Textobjekte mechanische Prozesse verursachen? Die Idee scheint zu sein, dass das Textobjekt den mechanischen Prozess irgendwie physisch verursacht. Dies scheint jedoch eine ziemlich sorgfältige Analyse der Natur eines solchen Kausalzusammenhangs zu erfordern. Colburn (2004) bestreitet, dass der symbolische Text die kausale Wirkung hat; Es ist seine physische Manifestation (das Ding auf der Festplatte), die einen solchen Effekt hat. Software ist eine konkrete Abstraktion, die ein Beschreibungsmedium (den Text, die Abstraktion) und ein Ausführungsmedium (z. B. eine konkrete Implementierung in Halbleitern) aufweist.

Eine etwas andere Perspektive zu diesen Themen beginnt bei der Frage der Programmidentität. Wann werden zwei Programme als gleich angesehen? Solche Probleme treten beispielsweise bei Versuchen auf, die rechtliche Identität einer Software zu bestimmen. Wenn wir ein Programm mit seiner Textmanifestation identifizieren, reagiert die Identität eines Programms empfindlich auf Änderungen in seinem Erscheinungsbild (z. B. Ändern der Schriftart). Offensichtlich liefert uns nicht nur der Text einen philosophisch interessanten Begriff der Programmidentität. Um ein fundiertes Identitätskriterium zu erreichen, müssen wir vielmehr die Semantik und Implementierung stärker berücksichtigen. Wir werden in §3 und §6 auf dieses Thema zurückkommen.

2.2 Programme und Algorithmen

Unabhängig von der Sichtweise der Programme bedarf die Unterscheidung zwischen Algorithmus und Programm einer weiteren konzeptionellen Klärung. Algorithmen werden oft als mathematische Objekte angesehen. Wenn dies zutrifft, gehören viele der sie betreffenden philosophischen Fragen auch zur Philosophie der Mathematik. Algorithmen sind jedoch wohl zentraler für die Informatik als für die Mathematik und verdienen mehr philosophische Aufmerksamkeit als sie gegeben wurden. Während es einige beträchtliche mathematische Untersuchungen von Algorithmen in der theoretischen Informatik und der mathematischen Logik gegeben hat (z. B. Moschovakis 1997; Blass & Gurevich 2003), gab es nicht viele philosophische Diskussionen, die sich auf die Natur von Algorithmen und die Unterschiede zwischen diesen konzentrieren Algorithmen und Programme.

Sind Algorithmen abstrakte Objekte im Sinne von Rosen (2001), während Programme konkret sind? Sind Algorithmen das abstrakte mathematische Gegenstück zu einem Textobjekt, das das Programm ist? Dieses Bild eignet sich natürlich für eine Form des ontologischen Platonismus (Shapiro 1997), bei dem Algorithmen ontologische Priorität haben und Programme die sprachlichen Mittel liefern, um an sie heranzukommen. Aus dieser Sicht könnten Algorithmen verwendet werden, um die Semantik (§3) von Programmiersprachen zu liefern. Natürlich erbt dieses Bild alle Vorteile und Probleme einer solchen platonischen Perspektive (Shapiro 1997).

Eine weniger platonische Ansicht besagt, dass Algorithmen die in einem Programm ausgedrückten Ideen enthalten. Nach dem Gesetz ist dies der Grund dafür, dass Algorithmen im Gegensatz zu Programmen nicht urheberrechtlich geschützt sind (§7.1). Natürlich erfordert der Begriff Idee eine weitere philosophische Analyse. In der Tat könnte argumentiert werden, dass der bloße Begriff des Algorithmus viel weniger einer Klärung bedarf als die Standarddarstellung von Ideen und die damit verbundenen Begriffe der Abstraktion (Rosen 2001).

Schließlich ist es fast eine folkloristische Sichtweise, dass Turing-Maschinen uns eine formale Analyse unseres Begriffs des Algorithmus liefern. Aber passt dies zu dem zeitgenössischen Begriff, der in der modernen Informatik mit seinen ausgefeilten Vorstellungen von Repräsentation und Kontrolle verwendet wird? Moschovakis (1997) bietet eine Analyse an, die etwas besser abschneidet.

2.3 Programme und Spezifikationen

Eine weitere beliebte Unterscheidung, die Gegenstand einer kritischen Analyse sein sollte, betrifft Programme und Spezifikationen. Was sind Spezifikationen und wie unterscheiden sie sich von Programmen? Während es in der philosophischen Literatur wenig direkte Diskussion zu diesem Thema gibt (siehe jedoch Smith 1985), ist die Art der Spezifikationen ein grundlegendes Thema für die konzeptionellen Grundlagen der Informatik.

Eine Ansicht, die häufig in Lehrbüchern zur formalen Spezifikation zu finden ist, ist, dass Programme detaillierte Maschinenanweisungen enthalten, während (Funktions-) Spezifikationen nur die Beziehung zwischen Eingabe und Ausgabe beschreiben. Ein offensichtlicher Weg, dies auszupacken, ist die Unterscheidung zwischen Imperativ und Deskriptiv: Programme sind zwingend erforderlich und beschreiben, wie das in der Spezifikation beschriebene Ziel erreicht werden kann. Im imperativen Programmierparadigma scheint dies sicherlich einen wesentlichen Unterschied zu erfassen. Aber es ist nicht für alle geeignet. Zum Beispiel werden logische, funktionale und objektorientierte Programmiersprachen nicht offensichtlich davon bestimmt: Zum Nennwert genommen, bestehen Programme, die in solchen Sprachen codiert sind, aus Sequenzen von Definitionen, nicht aus 'Anweisungen'. Außerdem,Nichtfunktionale Spezifikationen können nicht als Aussagen über die Beziehung zwischen Eingabe und Ausgabe formuliert werden, da sie Anforderungen an das Design und an die Art von Anweisungen stellen, die in einem Programm enthalten sein können.

Eine andere Ansicht besteht darauf, dass der Unterschied zwischen Spezifikationen und Programmen in Bezug auf den Begriff der Implementierung zu lokalisieren ist, dh kann er kompiliert und ausgeführt werden? Aber was ist damit gemeint? Ist es im Sinne eines vorhandenen Compilers gemeint? Diese Interpretation ist eher oberflächlich, da sie kein konzeptionelles, sondern ein bedingtes Unterscheidungskriterium bietet. Beispielsweise wurden in den ersten fünf Generationen von Programmiersprachen (2. Hälfte des 20. Jahrhunderts) rekursive, modulare, funktionale und objektorientierte Spezifikationen einer Generation als Programme in den nächsten, dh den heutigen Spezifikationssprachen, artikuliert werden häufig die Programmiersprachen von morgen.

Eine andere Ansicht legt nahe, dass Programmiersprachen diejenigen Sprachen sind, die im Prinzip implementiert sind, während Spezifikationssprachen diejenigen sind, die dies nicht können. Und vermutlich können sie dies nicht, weil die Spezifikationssprachen es erlauben, Begriffe auszudrücken, die nicht berechenbar sind. Diese Unterscheidung steht im Einklang mit vielen bestehenden Spezifikationssprachen, die auf der Zermelo-Fraenkel-Mengenlehre und der Logik höherer Ordnung basieren. Es scheint jedoch seltsam, dass das, was eine Spezifikationssprache charakterisieren sollte, die Tatsache ist, dass sie nicht berechenbare Eigenschaften und Beziehungen ausdrücken kann. Sind diese nicht berechenbaren Anforderungen in der Praxis wirklich notwendig (Jones & Hayes 1990; Fuchs 1994)?

Die Verschiedenartigkeit dieser Ansichten legt nahe, dass die traditionelle binäre Trennung zwischen Spezifikationen und Programmen ein Beispiel für ein Problem in PCS ist, das mehr Aufmerksamkeit verdient, nicht nur zur konzeptionellen Klärung, sondern auch, weil es Auswirkungen auf das Design zukünftiger Programmier- und Spezifikationssprachen haben könnte.

3. Semantik

Die Grammatik einer Programmiersprache bestimmt nur, was syntaktisch legitim ist. es informiert uns nicht über die beabsichtigte Bedeutung seiner Konstrukte. Die Grammatik einer Programmiersprache bestimmt also nicht von sich aus, in was programmiert wird. Stattdessen wird die Grammatik verwendet, die mit einer semantischen Berücksichtigung (formal oder informell) angereichert ist. Die Semantik soll den Programmierer, den Compilerautor und den Theoretiker informieren, die daran interessiert sind, die Eigenschaften der Sprache zu untersuchen. In der Tat wird oft behauptet, dass zur Erfüllung der unterschiedlichen Anforderungen des Programmierers und Compilers unterschiedliche semantische Konten auf unterschiedlichen Abstraktionsebenen erforderlich sind. Und die Aufgabe des Theoretikers ist es, ihre Beziehung zu untersuchen.

Dies ist das Standardbild, das in der semantischen Literatur auftaucht. Vieles davon bedarf jedoch einer konzeptionellen Klärung. In diesem Abschnitt werden nur einige der Probleme betrachtet, die sich aus dieser Aktivität ergeben.

3.1 Denotations- und Operationssemantik

Eine der wichtigsten Unterscheidungen in der Programmiersprachen-Semantik betrifft die Unterscheidung zwischen operativer und denotationaler Semantik. Eine operationelle Semantik (Landin 1964; Plotkin 1981) liefert eine Interpretation einer Programmiersprache in Bezug auf eine abstrakte Maschine. Genauer gesagt handelt es sich um eine Übersetzung von Ausdrücken in der Programmiersprache in die Anweisungen oder Programme der abstrakten Maschine. Zum Beispiel würde Programm 1 in eine Folge von abstrakten Maschinenoperationen wie "a ← 0" und Push entpackt. Operative Semantik kann auch als algorithmische Semantik verstanden werden, insbesondere wenn die zugrunde liegende Maschine darauf abzielt, den Begriff des Algorithmus zu charakterisieren (z. B. Moschovakis 1997).

Im Gegensatz dazu liefert eine Denotationssemantik (Milne & Strachey 1977) eine Interpretation in mathematische Strukturen wie Mengen oder Kategorien. Beispielsweise bilden im klassischen Ansatz Mengen in Form von vollständigen Gittern und stetigen Funktionen auf ihnen den mathematischen Rahmen.

Aber gibt es einen signifikanten konzeptionellen Unterschied zwischen ihnen? Ist es so, dass die Denotationssemantik, die explizit auf mathematischen Strukturen wie Mengen basiert, mathematisch ist, während die operative Semantik dies nicht ist? Turner (2007) argumentiert nicht: Sie alle liefern mathematische Interpretationen.

Oder ist die operative Semantik eher maschinenähnlich im Sinne einer abstrakten Maschine, während bei der satztheoretischen Denotationssemantik kein Hinweis auf eine abstrakte Maschine vorliegt? Solche Unterscheidungen haben sich jedoch als konzeptionell nicht signifikant erwiesen, da denotationale semantische Konten alle als Strukturen angesehen werden können, die eine abstrakte Maschine mit darauf operierenden Zuständen und Operationen darstellen. Operative Konten sind auch nicht näher an der Implementierung: Denotationsansätze (Milne & Strachey 1977) sind ebenfalls sehr flexibel und können verschiedene Detailebenen der Implementierung widerspiegeln.

Eine weitere mögliche Unterscheidung betrifft die kompositorische (oder anderweitige) Natur der Semantik. Eine Semantik wird grob gesagt als kompositorisch angesehen (Szabó 2007), wenn der semantische Wert eines komplexen Ausdrucks eine Funktion der semantischen Werte seiner Teile ist. Kompositionalität wird als ein entscheidendes Kriterium der Semantik angesehen, da dies erforderlich zu sein scheint, um die Produktivität unseres Sprachverständnisses zu erklären: Es soll erklären, wie wir komplexe Programme verstehen und konstruieren. Aber bietet es uns einen Keil, um operative und denotationale Semantik zu trennen? Leider scheint dies nicht der Fall zu sein: Während Bezeichnungsdefinitionen kompositorisch gestaltet sind, ist es sicherlich nicht so, dass nicht alle operativen Semantiken kompositorisch sind.

Schließlich unterscheiden sich einige Versionen der Semantik hinsichtlich der Existenz eines rekursiven Modells, dh einer Interpretation in Turing- oder Gandy-Maschinen (§5.1). Selbst dies stimmt jedoch nicht genau mit der traditionellen operativen / denotationalen Kluft überein. Einige Bezeichnungsdefinitionen haben ein rekursives Modell, andere nicht.

Es scheint sehr schwer zu sein, diese Unterscheidung festzuhalten. Auf den ersten Blick scheint es keine scharfe konzeptionelle Unterscheidung zwischen operativer und denotationaler Semantik zu geben.

3.2 Implementierung und semantische Interpretation

Was ist der Unterschied zwischen einer semantischen Interpretation und einer Implementierung? Was ist beispielsweise der konzeptionelle Unterschied zwischen dem Kompilieren eines Programms in Maschinencode und dem Geben einer denotationalen Semantik? Nach Rapaport (2005b) wird eine Implementierung am besten als semantische Interpretation angesehen, wobei letztere durch eine Zuordnung zwischen zwei Domänen charakterisiert wird: einer syntaktischen und einer semantischen. Und beide werden durch Regeln einer Beschreibung bestimmt. Beispielsweise ist der kompilierte Code (in Kombination mit den Regeln, die seine Semantik regeln) das semantische Konto des Quellcodes.

Nach einem allgemeinen Verständnis des Begriffs "Implementierung" wird die semantische Domäne von einer physischen Maschine bereitgestellt. Mit anderen Worten, die physische Maschine selbst (die "Implementierung") bestimmt, was das Programm bedeutet. In Programmiersprachen entspricht dies beispielsweise der Behauptung, dass die Semantik für die C ++ - Programmiersprache von Bjarnes Computer bestimmt wird, auf dem sein C ++ - Compiler ausgeführt wird. Diese Erklärung ist jedoch offensichtlich unzureichend: Wenn wir davon ausgehen, dass die Maschine von Bjarne die Bedeutung von C ++ - Programmen bestimmt, gibt es keine Vorstellung von Fehlfunktionen oder Fehlinterpretationen: Was auch immer der Computer von Bjarne tut, ist ipso facto die Bedeutung des Programms. Aber sicherlich kann ein Gewitter dazu führen, dass die Maschine schief geht. Aber was können wir damit meinen, dass wir falsch liegen? Vermutlich verkörpert die (fehlerhafte) Maschine nicht die beabsichtigte Bedeutung. Aber,im Gegenzug scheinen wir diesen Satz nur auf der Grundlage einer maschinenunabhängigen Charakterisierung der Bedeutung verstehen zu können. Und auf einer bestimmten Ebene muss dies über eine unabhängige semantische Beschreibung erfolgen. Dies deutet darauf hin, dass der Begriff einer bloßen Implementierung keinen angemessenen Begriff der Semantik bietet. (Vergleiche mit: Kripke 1982; Wittgenstein 1953).

3.3 Semantik, Gleichheit und Identität

Wir haben unsere Diskussion über Programmgleichheit (§2.1) mit dem Versprechen abgeschlossen, die Semantik ins Bild zu bringen. Jede semantische Darstellung einer Programmiersprache bestimmt einen Begriff der Gleichheit für Programme, dh zwei Programme werden als gleich angesehen, wenn sie den gleichen semantischen Wert haben, dh

P = Q iff || P || = || Q ||

wo || P || ist der semantische Wert des Programms P. In diesem Sinne bestimmt jede semantische Darstellung ein Gleichheitskriterium. Zum Beispiel würde eine Version der Denotationssemantik von allen Rechenschritten abstrahieren und Programme gleichsetzen, die in gewissem Sinne dieselbe mathematische Funktion berechnen. Zum Beispiel würden die folgenden zwei Programme nach diesem Kriterium als gleich angesehen:

Funktion Faktoriell (n: Ganzzahl): Ganzzahl beginnt wenn n = 0, dann Faktoriell: = 1; sonst Faktoriell: = (n) * Faktoriell (n -1); Ende;

Programm 1

Funktion Faktoriell (n: Ganzzahl): Ganzzahl var x, y: Ganzzahl; begin y: = 1; x: = 0; während x <n beginnt x: = x +1; y: = y * x; Ende Faktoriell: = y; Ende;

Programm 2

Andererseits würde eine operativere Ansicht, die sich auf die Schritte der Berechnung bezieht, nicht annehmen, dass Programm 1 und Programm 2 gleich sind. In der Tat können wir im Lichte von §3.1 semantische Konten erstellen, die jede Ebene der Implementierungsdetails widerspiegeln. Unterschiedliche semantische Konten bestimmen unterschiedliche Vorstellungen von Gleichheit, die unterschiedlichen konzeptuellen und praktischen Zwecken dienen können. Aber welches sollte dann genommen werden, um die Sprache zu bestimmen? Glücklicherweise gibt es einige Desiderata, die angewendet werden können; Wir können die Optionen einschränken: Einige semantische Konten liefern uns einen logisch zufriedenstellenden Begriff von Identität, andere nicht.

Die Ununterscheidbarkeit von Identitäten ist ein Prinzip, das in die gewöhnliche Prädikatenlogik eingebaut ist. Wenn zwei Objekte gleich sind, haben sie alle Eigenschaften gemeinsam. Das umgekehrte Prinzip, die Identität von Ununterscheidbarengibt an, dass wenn für jede Eigenschaft F das Objekt x genau dann F hat, wenn das Objekt y F hat, x mit y identisch ist. Die Identität von Ununterscheidbaren impliziert, dass wenn x und y verschieden sind, es mindestens eine Eigenschaft gibt, die x hat und y nicht. Manchmal ist die Verbindung beider Prinzipien als Leibniz'sches Gesetz bekannt (Forrest 2006). Das Leibnizsche Gesetz wird oft als wesentlich für jeden Begriff der Gleichheit angesehen. Diese Gesetze werden normalerweise in logischen Theorien wie der Logik zweiter Ordnung formuliert. Wir werden jedoch am meisten an ihrer Fähigkeit interessiert sein, zwischen verschiedenen Arten der Semantik von Programmiersprachen zu unterscheiden. In der Tat ist das Leibnizsche Gesetz einer der zentralen Begriffe der modernen semantischen Theorie. Das Identitätskriterium wird in Bezug auf die Beobachtungsäquivalenz konkretisiert.

Zwei Programme M und N sind als beobachtungsäquivalent definiertgenau dann, wenn in allen Kontexten C […], in denen C [M] ein gültiges Programm ist, C [N] auch ein gültiges Programm mit demselben semantischen Wert ist. Zum Beispiel sagen wir, dass Oracle und DB2 (Programme, die relationale Datenbanken manipulieren) gemäß einer semantischen Darstellung von Operationen in relationalen Datenbanken genau dann beobachtungsmäßig äquivalent sind, wenn sie nur im „gleichen“Kontext (Betriebssystem, Maschinenarchitektur, Eingabe usw.) ausgeführt werden.) ergibt die "gleiche" Datenbank. Natürlich muss der Begriff Beobachtungsäquivalent mit einer Prise Salz genommen werden. Wir können das Verhalten eines Programms eindeutig nicht in allen Kontexten beobachten. Die Beobachtungsäquivalenz spiegelt jedoch eine zugrunde liegende konzeptionelle Forderung wider, die sich aus den Prinzipien der Ununterscheidbarkeit von Identitäten und aus der Identität von Ununterscheidbaren ergibt.

Wenn in der Semantik alle beobachtbar unterschiedlichen Programme unterschiedliche semantische Werte haben, wird die Semantik als solide bezeichnet. Folglich erfüllt eine solide Semantik das folgende Prinzip:

|| P || = || Q || impliziert, dass für alle Kontexte C, || C [P] || = || C [Q] ||

Es sollte klar sein, dass der durch eine solide Semantik induzierte Identitätsbegriff die Ununterscheidbarkeit von Identitäten befriedigt.

Eine Semantik gilt als vollständig, wenn zwei Programme mit unterschiedlichen semantischen Werten beobachtbar unterschiedlich sind. Genauer gesagt erfüllt eine vollständige Semantik Folgendes:

Für alle Kontexte C, || C [P] || = || C [Q] || impliziert || P || = || Q ||

Auch hier sollte klar sein, dass eine vollständige Semantik das Prinzip der Identität von Ununterscheidbaren erfüllt.

Schließlich wird die Semantik als vollständig abstrakt bezeichnet, wenn sie solide und vollständig ist. Folglich erfüllt eine vollständig abstrakte Semantik das Leibnizsche Gesetz.

Dieser logische Hintergrund liefert die philosophische Rechtfertigung für die Entwicklung einer vollständig abstrakten Semantik. Es bietet uns somit eine Möglichkeit, semantische Konten auszuwählen, die philosophisch akzeptable Vorstellungen von Gleichheit liefern. Es bestimmt natürlich keinen einzelnen Begriff. Es bietet nur ein Tool zum Ablehnen von Personen, die kein konzeptionell akzeptables liefern können. Viele sogenannte Denotationssemantiken sind nicht vollständig abstrakt, während viele operative semantisch sind. In der Tat war eines der zentralen Themen in der jüngeren Geschichte der Semantik die Suche nach vollständig abstrakten Definitionen, die innerhalb der Klasse der semantischen Definitionstechniken gegossen werden, um eine denotationale Semantik zu liefern.

Die Semantik spielt in der Informatik eine normative oder bestimmende Rolle. Ohne semantische Definitionen haben Sprachen und Strukturen keinen Inhalt, der über den Inhalt ihrer syntaktischen Beschreibungen hinausgeht. Und letztere reichen für praktische oder philosophische Zwecke kaum aus. Während wir mit der Analyse der zentralen Anliegen begonnen haben, haben wir nur die Oberfläche zerkratzt.

4. Beweise und Programme

Spezifikationen (§2.3) führen zu einem bestimmten Begriff der Korrektheit. Nach der abstrakten Interpretation dieses Begriffs wird ein Programm in Bezug auf eine (funktionale) Spezifikation als korrekt angesehen, wenn die Beziehung, die es zwischen Eingabe und Ausgabe herstellt, der in der Spezifikation festgelegten entspricht. Genauer gesagt, wenn p ein Programm ist, dann erfüllt es eine Spezifikation R, die als Beziehung über den Eingabetyp I und den Ausgabetyp O angenommen wird, wenn Folgendes gilt:

Für alle Eingaben erfüllt i vom Typ I, das Paar (i, p (i)), die Beziehung R

Dabei ist p (i) das Ergebnis der Ausführung des Programms p am Eingang i. Hier wird R in einer bestimmten Spezifikationssprache und p in einer bestimmten Programmiersprache ausgedrückt. Ersteres ist normalerweise eine Variante der (typisierten) Prädikatenlogik, und Korrektheitsnachweise (dh die Aussage (1) gilt) werden im Beweissystem der Logik ausgeführt. Beispielsweise wird häufig die Hoare-Logik (Hoare 1969) verwendet, bei der Korrektheitsnachweise in Form von Schlussfolgerungen zwischen Dreiergruppen geschrieben werden

B {P} A.

Dabei ist P ein Programm und B und A Aussagen (die Vorher- und Nachher-Zustände des Programms), die in einer Version der Prädikatenlogik mit Merkmalen ausgedrückt werden, die den Ausdruck der an die Programmvariablen angehängten Werte erleichtern.

Eine philosophische Kontroverse, die das Problem der Korrektheit umgibt, dreht sich um die Natur solcher Beweise; die anderen Herausforderungen, was solche Beweise liefern.

4.1 Beweise in der Informatik

Sind Beweise für die Programmkorrektheit echte mathematische Beweise, dh sind solche Beweise den mathematischen Standardbeweisen ebenbürtig? DeMillo et al. (1979) behaupten, dass Korrektheitsbeweise, weil sie lang und mathematisch flach sind, im Gegensatz zu Beweisen in der Mathematik stehen, die konzeptionell interessant und überzeugend sind und die Aufmerksamkeit anderer Mathematiker auf sich ziehen, die sie studieren und darauf aufbauen wollen. Zum Beispiel würde ein Beweis in der Hoare-Logik, dass Programm 2 die Fakultätsfunktion berechnet, Details über den zugrunde liegenden Zustandsbegriff enthalten, ein induktives Argument verwenden und Überlegungen zur Schleifeninvarianz beinhalten.

Aber solche Beweise wären viel länger als das Programm selbst. Darüber hinaus würde die Ebene, auf der die Argumentation in der Hoare-Logik codiert ist, den Ausdruck und die Darstellung vieler Details erfordern, die normalerweise implizit bleiben würden. Es wäre mühsam und bei den meisten Programmen konzeptionell trivial.

Dieses Argument entspricht den in der Philosophie der Mathematik vorgebrachten Greifbarkeitsargumenten (z. B. Tymoczko 1979; Burge 1988). Im Zentrum stehen erkenntnistheoretische Sorgen: Beweise, die zu lang, umständlich und uninteressant sind, können nicht die Art von Gewissheit tragen, die mathematischen Standardbeweisen zugeschrieben wird. Es wird behauptet, dass sich die Art des Wissens, das aus Korrektheitsnachweisen gewonnen wird, von dem Wissen unterscheidet, das aus Beweisen in der Mathematik gewonnen werden kann ^[1].

Man muss diese im Wesentlichen soziologische Perspektive auf Beweise auch von der unterscheiden, die behauptet, dass Beweise in einer Weise richtig oder falsch sind, die von solchen erkenntnistheoretischen Urteilen unabhängig ist. Es ist möglich, an der realistischeren Position festzuhalten, nach der ein bestimmter Beweis entweder richtig oder falsch ist, ohne die Forderung aufzugeben, dass Beweise, um aufgenommen und validiert zu werden, greifbar sein müssen.

Man könnte versuchen, etwas Boden gut zu machen, indem man befürwortet, dass Korrektheitsnachweise eher von einem Computer als von einem Menschen überprüft werden sollten. Aber natürlich muss der Proof-Checker selbst überprüft werden. Arkoudas und Bringsjord (2007) argumentieren, dass die Möglichkeit von Fehlern erheblich verringert wird, wenn nur ein Korrektheitsnachweis geprüft werden muss, nämlich der des Beweisprüfers selbst.

4.2 Beweise in der Mathematik

Mathematische Beweise wie der Beweis von Gödels Unvollständigkeitssatz sind ebenfalls lang und kompliziert. Was sie jedoch für die mathematische Gemeinschaft transparent, interessant und verständlich ("vermessbar") macht, ist die Verwendung von Modularitätstechniken (z. B. Deckspelzen) und die Verwendung von Abstraktion im Akt der mathematischen Schöpfung. Durch die Einführung neuer Konzepte kann ein Beweis schrittweise erstellt werden, wodurch die Beweise leichter verständlich werden. Die Mathematik schreitet voran, indem sie neue mathematische Konzepte erfindet, die die Konstruktion höherer und allgemeinerer Beweise ermöglichen, die ohne sie weitaus komplexer und sogar unmöglich wären. Zum Beispiel ermöglicht die Exponenten-Notation, Berechnungen durchzuführen, die über die Komplexität der Multiplikation hinausgehen - und über die Ergebnisse zu streiten. Im anderen ExtremfallDie Erfindung der Kategorietheorie ermöglichte die Aussage und den Nachweis sehr allgemeiner Ergebnisse über algebraische Strukturen, die automatisch für eine ganze Reihe solcher Strukturen gelten. In der Mathematik geht es nicht nur um Beweise. es beinhaltet auch die Abstraktion und Schaffung neuer Konzepte und Notationen. Auf den ersten Blick werden bei formalen Korrektheitsnachweisen im Allgemeinen keine neuen Konzepte erstellt oder in den Prozess der mathematischen Abstraktion einbezogen. Im Gegensatz dazu konzentriert sich die Abstraktion in der Informatik (§6.1) auf die Begriffe, die für die Programmgestaltung benötigt werden. Aber wie hängen diese beiden Begriffe der Abstraktion zusammen? Wir werden später etwas mehr darüber sagen.es beinhaltet auch die Abstraktion und Schaffung neuer Konzepte und Notationen. Auf den ersten Blick werden bei formalen Korrektheitsnachweisen im Allgemeinen keine neuen Konzepte erstellt oder in den Prozess der mathematischen Abstraktion einbezogen. Im Gegensatz dazu konzentriert sich die Abstraktion in der Informatik (§6.1) auf die Begriffe, die für die Programmgestaltung benötigt werden. Aber wie hängen diese beiden Begriffe der Abstraktion zusammen? Wir werden später etwas mehr darüber sagen.es beinhaltet auch die Abstraktion und Schaffung neuer Konzepte und Notationen. Auf den ersten Blick werden bei formalen Korrektheitsnachweisen im Allgemeinen keine neuen Konzepte erstellt oder in den Prozess der mathematischen Abstraktion einbezogen. Im Gegensatz dazu konzentriert sich die Abstraktion in der Informatik (§6.1) auf die Begriffe, die für die Programmgestaltung benötigt werden. Aber wie hängen diese beiden Begriffe der Abstraktion zusammen? Wir werden später etwas mehr darüber sagen.

4.3 Physische und abstrakte Korrektheit

Selbst wenn wir diese erkenntnistheoretischen Sorgen beiseite lassen, stellt eine zweite und scheinbar verheerendere Kritik an Korrektheitsbeweisen die Frage, was sie tatsächlich begründet haben. Scheinbar liefert ein Korrektheitsnachweis die Korrektheit nur bis zur Textdarstellung des Programms. Keine formale Arbeit kann uns über die abstrakte / physische Barriere bringen: Wir können niemals garantieren, dass eine bestimmte Ausführung des Programms auf einer physischen Maschine tatsächlich wie erwartet verläuft (Fetzer 1988; Fetzer 1999; Colburn 2004).

Aber was bedeutet es, dass Programm p korrekt ist? Angenommen, wir haben eine Spezifikation des Programms - und diese kann formell oder informell sein. Nehmen wir dann an, wir führen eine Reihe von Testläufen durch, um zu überprüfen, ob das Programm seiner Spezifikation entspricht. Wenn sie erfolgreich sind, haben wir empirische Beweise dafür, dass das physikalische Gegenstück des Textprogramms tatsächlich korrekt ist, da es gemäß der Spezifikation funktioniert. Aus dieser Sicht wurde das physische Gegenstück getestet. nicht das Textprogramm.

Diese Analyse legt nahe, dass der Begriff der Korrektheit von Programmen eine Dualität aufweist. In Übereinstimmung mit der dualen Natur von Programmen können wir sagen, dass das Textprogramm der mathematischen Korrektheit unterliegt, während sein physikalisches Gegenstück einer empirischen Überprüfung unterzogen wird.

5. Berechenbarkeit

Die Berechenbarkeit ist eines der ältesten Themen, die als PCS bezeichnet werden können. Es ist jedoch Gegenstand mehrerer SEP-Einträge (z. B. Barker-Plummer 2004), weshalb wir nur einige Themen und ihre Zusammenhänge mit dem Rest des vorliegenden Eintrags erwähnen werden.

5.1 Die kirchliche These

Eines der zentralen Themen ist die Church-Turing-These. Und hier gibt es zwei Streitigkeiten, eine historische und eine empirische. Sie konzentrieren sich auf die folgenden zwei möglichen Interpretationen der These:

1. Turingmaschinen können alles tun, was als „Faustregel“oder „rein mechanisch“bezeichnet werden kann.
2. Was auch immer von einer Maschine berechnet werden kann (Arbeiten an endlichen Daten gemäß einem endlichen Befehlsprogramm), ist Turing maschinenberechnbar.

Interpretation I soll den Begriff einer effektiven oder mechanischen Methode in Logik und Mathematik erfassen. Es soll den informellen Begriff des Algorithmus widerspiegeln, der in der Mathematik impliziert und durch das Hilbert-Programm in den Vordergrund gerückt ist. Interpretation II soll physische Maschinen regeln. In der Tat kann (Gandy 1980) als weiteres Auspacken von II angesehen werden. Gandy schlägt vier Prinzipien vor, die die Berechnung durch eine physikalische Maschine charakterisieren sollen. Er zeigt, dass solche Maschinen genau mit Turings Charakterisierung übereinstimmen (Gandys Theorem). Im Zusammenhang mit unserer Diskussion verschiedener semantischer Paradigmen ist klar, dass viele der Maschinen, die der Denotationssemantik (§3.1) zugrunde liegen, nicht als Gandy-Maschinen gelten. Sie arbeiten meistens mit erweiterten Funktionsräumen höherer Ordnung.und diese können nicht als endliche Daten angesehen werden und erfüllen nicht Gandys Bedingungen.

Einige behaupten (Copeland 2004; Copeland 2008), dass die von Church and Turing vorgeschlagene These nur die Interpretation I betrifft und Maschinen im Allgemeinen keine Grenzen setzt. Hodges (2007) ist anderer Meinung. Er argumentiert, dass Church und Turing nicht zwischen den beiden Interpretationen unterschieden haben. Dies ist der historische Streit.

Der physische Streit betrifft die Fähigkeiten tatsächlicher Maschinen (Interpretation II.). Viele halten es für selbstverständlich, dass die Church-Turing-These die tatsächliche physische Berechnung charakterisiert und vorschreibt. Zum Beispiel scheint dies die implizite Annahme in der Mainstream-Informatik zu sein. Es ist sicherlich der Fall, dass jedes Programm, das in einer vorhandenen implementierten Programmiersprache geschrieben ist, Turing berechenbar ist und umgekehrt, dass alle universellen Programmiersprachen Turing vollständig sind, dh sie enthalten alle Steuerungskonstrukte, die zur Simulation einer universellen Turing-Maschine erforderlich sind.

Copeland (2007) argumentiert, dass Gandys Charakterisierung eines diskreten deterministischen mechanischen Geräts zu eng ist, und folglich gibt es Beispiele für mögliche physikalische Maschinen, deren Fähigkeiten über die Klasse der berechenbaren Turing-Funktionen hinausgehen. Viele davon erfordern eine unendliche Beschleunigung, wobei eine unendliche Anzahl von Berechnungen physikalisch in einer endlichen Zeit durchgeführt werden kann. Quantum Computing wurde als mögliches Beispiel für solche Maschinen angeführt, dies wurde jedoch bestritten (Hodges 2007; Hagar 2007).

Hodges befasst sich auch mit der Anwendbarkeit der mathematischen Standardargumentation in der Physik auf Fälle, in denen es um unendliche Präzision geht. Dies legt nahe, dass es sich bei diesem Streit nicht um einen einfachen empirischen Streit handelt. In der Tat gibt es diejenigen, die sich fragen, ob es physikalisch möglich ist, eine unendliche Anzahl von Aufgaben in einer endlichen Zeit zu erledigen. Dummett (2006) stellt die Frage, ob die Vorstellung einer unendlichen Aufgabe, die im physischen Bereich ausgeführt werden soll, nicht nur eine physische, sondern auch eine konzeptionelle Unmöglichkeit ist. Der Streit ist also nicht nur ein empirischer, sondern geht zum Kern unseres Verständnisses der Beziehung zwischen unseren mathematischen Modellen und der physikalischen Realität.

6. Programmierung und Programmiersprachen

Die Gestaltung von Programmen und Programmiersprachen ist eine der traditionellen Aktivitäten der Informatik. Sie sind von einer Vielzahl konzeptioneller Fragen umgeben (§ 1), von denen viele keine philosophische Aufmerksamkeit erhalten haben. Hier werden wir kurz auf zwei dieser Probleme eingehen.

6.1 Abstraktion

Abstraktion ist einer der konzeptionellen Eckpfeiler der Informatik. Es ist ein wesentlicher Bestandteil der Programmgestaltung und -konstruktion und bildet eine Kernmethode für die Gestaltung von Programmiersprachen. In der Tat treibt es die Schaffung neuer Programmierparadigmen voran. Es liegt der Erfindung von Begriffen wie prozeduraler und funktionaler Abstraktion, Polymorphismus, Datenabstraktion, Objekten und Klassen, Entwurfsmustern, Architekturstilen, Subtypisierung und Vererbung zugrunde. Viele Bereiche des Software-Engineerings (z. B. Softwaremodellierung, Programmverständnis, Programmvisualisierung, Reverse- und Re-Engineering) befassen sich hauptsächlich mit der Untersuchung geeigneter Mechanismen für die Programmabstraktion. Ein Großteil des Fortschritts der Softwareentwicklung wurde durch die Einführung neuer Abstraktionsmechanismen erzielt.

Aber was ist die Natur der Abstraktion in der Informatik? Was ist die zugrunde liegende philosophische Erklärung? Leider ist die Idee der Abstraktion im Allgemeinen philosophisch problematisch. Nach der traditionellen Auffassung, die ihren Ursprung in der philosophischen Psychologie hat, ist Abstraktion ein mentaler Prozess, bei dem neue Konzepte gebildet werden, indem mehrere Objekte oder Ideen betrachtet und die Merkmale, die sie unterscheiden, weggelassen werden. (Rosen 2001). Dieser Ansatz hat jedoch nur wenige, wenn überhaupt, zeitgenössische philosophische Befürworter.

Ein logischerer Ansatz zur Analyse der Abstraktion, der eine starke Befürwortung hat (Wright 1983; Hale 1987). Es ist jedoch unklar, ob diese Ideen, die für die mathematische Abstraktion entwickelt wurden, auf die Informatik anwendbar sind. Es ist klar, dass einige der Begriffe der Abstraktion in der Informatik entweder von Abstraktionen in der Mathematik inspiriert oder mittels Abstraktionen in der Mathematik untersucht wurden. Aber wie ist die konzeptionelle Beziehung zwischen Abstraktion in diesen Disziplinen? Unterscheiden sie sich grundlegend? Obwohl es umfangreiche Literatur zu den philosophischen Grundlagen der mathematischen Abstraktion gibt (siehe Wright 1983; Hale 1987; Fine 2002), steckt die konzeptionelle Untersuchung der Abstraktion in der Informatik leider noch in den Kinderschuhen. Colburn (2007) schlägt vor, dass die Unterscheidung zwischen Abstraktion in der Mathematik und Abstraktion in der Informatik in der Tatsache liegt, dass Abstraktion in der Mathematik Vernachlässigung von Informationen ist, während es in der Informatik das Verstecken von Informationen ist. Das heißt, Abstraktionen in der Mathematik ignorieren das, was als irrelevant eingestuft wird (z. B. die Farbe ähnlicher Dreiecke). Im Gegensatz dazu dürfen in der Informatik Details, die auf einer Abstraktionsebene ignoriert werden (z. B. müssen sich Java-Programmierer nicht um die genaue Position im Speicher kümmern, die einer bestimmten Variablen zugeordnet ist), von einer der unteren Ebenen (z. B. der virtuellen) nicht ignoriert werden Maschine handhabt alle Speicherzuordnungen). Abstraktionen in der Mathematik ignorieren, was als irrelevant eingestuft wird (z. B. die Farbe ähnlicher Dreiecke). Im Gegensatz dazu dürfen in der Informatik Details, die auf einer Abstraktionsebene ignoriert werden (z. B. müssen sich Java-Programmierer nicht um die genaue Position im Speicher kümmern, die einer bestimmten Variablen zugeordnet ist), von einer der unteren Ebenen (z. B. der virtuellen) nicht ignoriert werden Maschine handhabt alle Speicherzuordnungen). Abstraktionen in der Mathematik ignorieren, was als irrelevant eingestuft wird (z. B. die Farbe ähnlicher Dreiecke). Im Gegensatz dazu dürfen in der Informatik Details, die auf einer Abstraktionsebene ignoriert werden (z. B. müssen sich Java-Programmierer nicht um die genaue Position im Speicher kümmern, die einer bestimmten Variablen zugeordnet ist), von einer der unteren Ebenen (z. B. der virtuellen) nicht ignoriert werden Maschine handhabt alle Speicherzuordnungen).

Aber basiert dies auf einem zu simplen Begriff der Abstraktion in der Mathematik? Gibt es nur eine Art von Vorstellung? Zum Beispiel sind die Informationen, die sich in Bishops Analyse (Bishop 1970) verstecken, ganz anders als Wrights Begriff der Abstraktion - tatsächlich sind sie dem der Informatik ziemlich ähnlich.

6.2 Typen und Ontologie

Programmiersprachen sind meist typisierte Sprachen, bei denen der moderne Typbegriff seinen Ursprung in Frege und Russell und insbesondere in Russells einfacher Typentheorie hat (Irvine 2003). Natürlich war Russell von den logischen und semantischen Paradoxien motiviert, und diese Funktion spielt bei der Anwendung von Typen in der Informatik keine zentrale Rolle. Auf der anderen Seite zerlegen Russell-Typen das Universum des Diskurses auf eine Weise, die sowohl grammatikalische als auch semantische Bedeutung hat. Und diese Idee hat sich auf die Informatik übertragen. In der Tat wurden Typentheorien von der Informatik inspiriert und bereichert. Zum Beispiel ist Russells Typentheorie, obwohl sie mathematisch mächtig ist, in ihrer Ausdruckskraft im Vergleich zu den Typentheorien moderner Computersprachen etwas verarmt (Coquand 2006; Pierce 2002). Neben einer Reihe grundlegender Typen wie Zahlen und Booleschen Werten enthalten Programmiersprachen eine Sammlung von Typkonstruktoren (Möglichkeiten zum Erstellen neuer Typen aus alten). Dazu gehört beispielsweise die Fähigkeit, eine Art kartesisches Produkt und endliche Mengen zu bilden. In vielen objektorientierten Programmiersprachen können Typen (Klassen) Operationen aus anderen Typen importieren (und überschreiben) und komplexere Konstruktoren anbieten, die die Bildung abstrakter Datentypen und verschiedener Formen des Polymorphismus unterstützen. Typen (Klassen) können Operationen von anderen Typen importieren (und überschreiben) und komplexere Konstruktoren anbieten, die die Bildung abstrakter Datentypen und verschiedener Formen des Polymorphismus unterstützen. Typen (Klassen) können Operationen von anderen Typen importieren (und überschreiben) und komplexere Konstruktoren anbieten, die die Bildung abstrakter Datentypen und verschiedener Formen des Polymorphismus unterstützen.

In der Informatik spielen Typen eine Rolle, die auf halbem Weg zwischen Syntax und Semantik liegt. Erstens erweitern sie unseren normalen Begriff der kontextfreien Grammatik. Einige Sprachfunktionen, insbesondere diejenigen, mit denen der Typ einer Variablen durch den Kontext festgelegt werden kann (dh Deklarationen der Sprache), erfordern eine Grammatikform, die flexibler ist als die Standardform. Sogenannte zweistufige Grammatiken erfassen zwar technisch angemessen, erfassen jedoch nicht die Art und Weise, in der Variablen in modernen Sprachen ihren Typ zugewiesen bekommen. Und sie sind sehr ungeschickt zu bedienen. Sie passen sich auch nicht leicht an die polymorphen Typsysteme vieler Sprachen an. Moderne Typsysteme machen es besser: Variablen werden ihre Typen über Deklarationen zugewiesen, z. B. x: Boolean. Anschließend kann ein Compiler das Programm typüberprüfen, z.es kann sicherstellen, dass das Auftreten einer Variablen in nachfolgenden Anweisungen (z. B. x

Typen spielen aber auch eine Korrektheitsrolle, die normalerweise nicht syntaktisch beschrieben wird. Dies geschieht, indem der traditionelle physikalische Begriff der Dimensionsanalyse auf ein viel umfangreicheres Typensystem ausgedehnt wird. Das Erhalten der richtigen Typstruktur für ein Programm trägt dazu bei, dessen Richtigkeit sicherzustellen. Und dies wird durch die Struktur bestimmt, die Typen einer Sprache auferlegen. Typen korrigieren die Art der Dinge, die es in einer Programmiersprache gibt. So legt beispielsweise jede Programmiersprache, die Zahlen, Produkte und Klassen und nichts anderes zulässt, dem Programmierer einen konzeptionellen Rahmen auf, in dem sie arbeiten muss. Probleme müssen artikuliert und Lösungen innerhalb der vom Typensystem bereitgestellten Darstellungsmittel gefunden werden. Sobald die Typstruktur einer Programmiersprache festgelegt wurde, wurde ein Großteil ihrer ontologischen Einstellung festgelegt.

Oder hat es? Vielleicht müssen wir zurücktreten und zuerst fragen, wie die ontologischen Verpflichtungen einer Sprache bestimmt werden sollen. Ist es die Semantik, die die Dinge bestimmt (Turner & Eden 2007)? Eine lange Tradition, die von Frege ausgeht, würde dies nahe legen (Dummett 1991). Unter der Annahme, dass die Analogie mit natürlichen Sprachen legitim ist, wird die Ontologie einer Sprache durch die Strukturen bestimmt, die zur Bereitstellung ihrer semantischen Domänen erforderlich sind. Aber welche semantische Theorie sollten wir übernehmen? Während jede Semantik Typen berücksichtigen muss, würde die semantisch bestimmte Ontologie darüber hinausgehen und die beteiligten semantischen Domänen widerspiegeln, und diese würden die Implementierungsdetails widerspiegeln, die in der Semantik enthalten sind. Aus diesem Grund bestimmen wie bei der Gleichheit unterschiedliche semantische Interpretationen unterschiedliche Ontologien. Daraus folgt, dass es nicht sinnvoll ist, über die Ontologie einer Programmiersprache zu sprechen, sondern über mehrere Ontologien, die von der Abstraktionsebene der Semantik abhängen. Beispielsweise kann die Ontologie auch teilweise durch das Programmierparadigma bestimmt werden.

7. Rechtliche und ethische Fragen

Einige Fragen der Computerethik gehören zum PCS, da die Erstellung und Verwendung von Software ethische Fragen aufwirft. Viele sind jedoch nicht spezifisch für die Informatik im engeren Sinne dieses Eintrags; Sie wirken sich auf die gesamte Informationstechnologie und Computeranwendungen aus (Bynum 2001). Folglich werden wir nur zwei erwähnen, die für die Informatik von zentraler Bedeutung zu sein scheinen.

7.1 Urheberrechte, Patente und Identität

Urheberrechte bieten einen gewissen Schutz für Software, können jedoch ihren semantischen Kern nicht schützen. Und wir gehen davon aus, dass letzteres durch eine semantische Darstellung (§3) der Programmiersprache bestimmt wird, in der das Programm geschrieben ist. Vermutlich betrifft das Wesentliche dieses Problems das Problem der Programmidentität (§3.3). Aber wenn es viele mögliche semantische Vorstellungen von Identität gibt, welche ist für die rechtliche Anwendung geeignet?

Eine informelle semantische Darstellung, die häufig im Gesetz zitiert wird, identifiziert das Programm mit den darin zum Ausdruck gebrachten Ideen, die am häufigsten als zugrunde liegender Algorithmus angesehen werden. Es ist jedoch nicht nur oft schwierig, genau zu sagen, was dieser Algorithmus ist, sondern auch, wie bei mathematischen Theoremen, können Algorithmen nicht urheberrechtlich geschützt werden. Und fast das gleiche Schicksal erwartet jede formale semantische Darstellung, da eine solche durch einen mathematischen Begriff bestimmt würde, sei es durch Algorithmen oder einen Begriff von Operation oder mathematischer Funktion.

Aber selbst wenn wir ein semantisches Konto finden könnten, das den Urheberrechtsgesetzen entspricht, wäre das rechtliche Bild nicht vollständig. Eine Urheberrechtsverletzung hängt oft nicht nur von der Identität ab, sondern auch davon, ob es plausibel ist anzunehmen, dass jemand das gleiche Programm entwickeln würde. Damit kommen absichtliche Überlegungen in den Rahmen. Mit anderen Worten, selbst wenn zwei Programme nach unserem semantischen Kriterium als gleichwertig angesehen werden, würde es keine Urheberrechtsverletzung geben, wenn es als plausibel angesehen werden könnte, dass sie unabhängig voneinander erstellt wurden.

Patente (insbesondere Gebrauchsmuster) schneiden nicht besser ab. Sie sind für Software noch schwieriger zu bekommen, da man mentale Prozesse, abstrakte Ideen und Algorithmen nicht patentieren kann. Und es sind eher Algorithmen als der Quellcode, die häufig die neuen Ideen enthalten. Aber auch hier sind die Identifizierungs- und Identitätsprobleme das zentrale philosophische Anliegen. Und diese beinhalten sowohl semantische als auch absichtliche Überlegungen.

7.2 Richtigkeit und Verantwortung

Ist es richtig, dass Software mit geringer Garantie für die Gebrauchstauglichkeit verkauft wird? (Coleman 2008) widmet sich dieser Frage. Dies ist eine besonders relevante Frage für sicherheitskritische Systeme, z. B. Systeme, die den medizinischen Zustand überwachen, Kernkraftwerke betreiben und mit Raumfähren kommunizieren. Hier erscheint es unerlässlich, strengere Tests und Korrektheitsnachweise durchzusetzen. Aber unterscheidet sich der Fall eines Programmierers, der sein Programm nicht analysiert und testet, in ethischer Hinsicht von dem eines Bauingenieurs, der die erforderlichen mathematischen Modelle und Tests an einem Hochbau nicht durchführt? Die moralischen Verpflichtungen scheinen ähnlich.

Eine Art und Weise, wie sie unterschiedlich sein könnten, betrifft die Komplexität von Software (Brooks 1987), die die Komplexität jeder anderen Art von menschlichem Artefakt um Größenordnungen übersteigt. Viele würden behaupten, dass es nicht machbar ist, eine solche Garantie für die Richtigkeit anzubieten (DeMillo et al. 1979); Software ist so komplex, dass der Prozess strenger mathematischer Beweise und Softwaretests nicht durchführbar ist. Und vermutlich kann man nur eine (moralische oder rechtliche) Verpflichtung haben, einen machbaren Prozess durchzuführen.

Aber wie vergleicht man die Test- und Testaspekte der Softwareentwicklung mit dem Verwendungszweck der Software? Sollte für Unterhaltungszwecke entwickelte Software denselben strengen Prüfungen und Tests unterzogen werden wie sicherheitskritische Software? Vermutlich nicht, aber wir könnten immer noch versucht sein zu fragen, ob es sich um neue ethische Probleme handelt oder ob sie uns nur weitere Fallstudien zu bestehenden ethischen Dilemmata liefern. Beispielsweise können selbst Sicherheitslücken in Software, die in der Unterhaltungsindustrie verwendet wird, finanzielle Sanktionen nach sich ziehen.

8. Neue Wendungen oder neue Probleme?

Auch dieser eher kurze Überblick über PCSsollte den Leser davon überzeugen, dass die Informatik interessante und anspruchsvolle philosophische Fragen aufwirft. In der Tat ist einer der wichtigsten Eindrücke, dass es wesentliche Verbindungen zu den meisten traditionellen Zweigen der Philosophie hat. Es gibt klare Zusammenhänge mit Ontologie, Ethik, Erkenntnistheorie und den Philosophien der Mathematik, Physik und Sprache. In der Tat wirft unsere anfängliche Liste von Fragen viel mehr Themen auf, die mit anderen Bereichen der Philosophie in Verbindung stehen. Insbesondere gibt es eine umfangreiche Literatur zu den Anwendungen der Informatik. Künstliche Intelligenz und Kognitionswissenschaft werfen philosophische Fragen auf, die zur Philosophie des Geistes gehören (McLaughlin 2004). Natürlich stammt ein Großteil davon aus Turing (1950). Andere Anwendungen der Informatik auf traditionelle Bereiche der Wissenschaft, sogenannte Computerwissenschaften,Probleme für die Wissenschaftsphilosophie schaffen: Welche erkenntnistheoretischen Auswirkungen haben Computersimulationen, insbesondere wenn dies die einzig praktikable Form des Experimentierens ist? Die rechnerische Wende in der Ontologie bringt neue Techniken mit sich, die sich auf die Struktur jeder Art von konzeptueller Ontologie auswirken. Die Philosophie der Logik wird durch eine Masse von Material bereichert: Eine große Anzahl neuer logischer Systeme ist zum Zwecke der Darstellung und Argumentation von Computersystemen entstanden. Es ist eine große Anzahl neuer logischer Systeme entstanden, um Computersysteme darzustellen und zu argumentieren. Es ist eine große Anzahl neuer logischer Systeme entstanden, um Computersysteme darzustellen und zu argumentieren.

Während es klar ist, dass die Informatik viele bedeutende Wendungen zu traditionellen philosophischen Anliegen aufwirft, ist weniger klar, ob sie wirklich neue philosophische Bedenken hervorruft: Gibt es in PCS Fragen, die in keinem anderen Bereich der Philosophie eine Parallele haben?

Literaturverzeichnis

• Allison, A., Currall, J., Moss, M. und Stuart, S., 2005, „Digital Identity Affairs“, Journal of American Society, Informationswissenschaft und Technologie 56 (4): 364–372.
• Arkoudas, K. und Bringsjord, S., 2007, „Computer, Rechtfertigung und mathematisches Wissen“, Minds and Machines 17 (2): 185–202.
• Barendregt, HP, 1993, "Lambda-Kalküle mit Typen", in: Handbook of Logic in Computer Science, Vol. 3, No. 2, New York, NY: Oxford University Press Inc.
• Barker-Plummer, D., 2008, "Turing Machines", The Stanford Encyclopedia of Philosophy (Ausgabe Herbst 2008), Edward N. Zalta (Hrsg.), URL = .
• Bishop, Errett, 1977, Grundlagen der konstruktiven Analyse, McGraw-Hill.
• Blass, Andreas und Gurevich, Yuri, 2003, „Algorithmen: Eine Suche nach absoluten Definitionen“, Bulletin der Europäischen Vereinigung für Theoretische Informatik (EATCS) Nr. 81: 195-225.
• Bowen, JP und Hinchey, MG, 1995, „Zehn Gebote formaler Methoden“, IEEE Computer 28 (4): 56–63.
• Bowen, JP und Hinchey, MG, 2005, „Zehn Gebote formaler Methoden: Zehn Jahre später“, IEEE Computer 39 (1): 40–48.
• Brooks, FP, 1987, "No Silver Bullet: Essenz und Unfälle der Softwareentwicklung", IEEE Computer 20 (4): 10-19.
• Burge, T., 1998, „Computer Proof, A-priori-Wissen und andere Köpfe“, Philosophical Perspectives 12: 1–37.
• Bynum, T., 2001, „Computerethik: Grundlegende Konzepte und historischer Überblick“, The Stanford Encyclopaedia of Philosophy (Ausgabe Winter 2001), Edward N. Zalta (Hrsg.), URL =
• Colburn, T., 2004, „Methodology of Computer Science“, Der Blackwell-Leitfaden zur Philosophie des Rechnens und der Information, Luciano Floridi (Hrsg.), Malden: Blackwell, S. 318–326.
• Colburn, T. und Shute, G., 2007, „Abstraction in Computer Science“, Minds and Machines 17 (2): 169–184.
• Coleman, KG, 2008, "Computing and Moral Responsibility", Stanford Encyclopedia of Philosophy (Ausgabe Herbst 2008), Edward N. Zalta (Hrsg.), URL = .
• Copeland, B. Jack, 2008, "The Church-Turing Thesis", Stanford Encyclopedia of Philosophy (Ausgabe Herbst 2008), Edward N. Zalta (Hrsg.), URL = .
• Copeland, B. Jack, 2004, „Computation“, Der Blackwell-Leitfaden zur Philosophie des Rechnens und der Information, Luciano Floridi (Hrsg.), Malden: Blackwell, S. 3–17.
• Coquand, Thierry, 2006, "Type Theory", Stanford Encyclopedia of Philosophy (Ausgabe Winter 2006), Edward N. Zalta (Hrsg.), URL = .
• DeMillo, RA, Lipton, RJ und Perlis, AJ, 1979, „Soziale Prozesse und Beweise von Theoremen und Programmen“, Mitteilungen des ACM 22 (5): 271–280.
• Denning, PJ, 1980, „Über Volkstheoreme und Volksmythen“, Mitteilungen der ACM 23 (9): 493–494.
• Denning, PJ, 1980b, "Was ist experimentelle Informatik?" Mitteilungen des ACM 23 (10): 534–544.
• Denning, PJ, 1981, „Leistungsanalyse: Experimentelle Informatik als das Beste“, Mitteilungen des ACM 24 (11): 725–727.
• Denning, PJ, 1985, "The Science of Computing: Was ist Informatik?" American Scientist 73 (1): 16–19.
• Denning, PJ (Hrsg.), Et al., 1989, „Computing as a Discipline“, Communications of the ACM 32 (1): 9–23.
• Dijkstra, E., 1968. „Gehe zu einer als schädlich angesehenen Erklärung“, Mitteilungen des ACM 11 (3): 147–148.
• Dummett, M., 1991, "The Logical Basis of Metaphysics", Harvard University Press.
• Dummett, M., 2006, "Denken und Wirklichkeit", Oxford University Press.
• Eden, Amnon, 2007, „Drei Paradigmen in der Informatik“, Minds and Machines 17 (2): 135–167.
• Feferman, S., 1992, „Logik für die Beendigung und Korrektheit von Funktionsprogrammen“, Logic for Computer Science: 95–127, MSRI Pubs. vol. 21, New York, NY: Springer-Verlag.
• Fetzer, JH, 1988, „Program Verification: The Very Idea“, Mitteilungen des ACM 31 (9): 1048–1063.
• Fetzer, JH, 1999, „Die Rolle von Modellen in der Informatik“, The Monist 82 (1): 20–36.
• Fine, K., 2008, "The Limits of Abstraction". Oxford: Oxford University Press.
• Floridi, Luciano, 2004. „Information“, Der Blackwell-Leitfaden zur Philosophie des Rechnens und der Information, Luciano Floridi (Hrsg.), Malden: Blackwell, S. 40–62.
• Floridi, Luciano 2007, "Semantische Informationskonzepte", Stanford Encyclopedia of Philosophy (Ausgabe Frühjahr 2007), Edward N. Zalta (Hrsg.), URL = .
• Forrest, P., 2006, "Die Identität der Ununterscheidbaren", The Stanford Encyclopedia of Philosophy (Ausgabe Herbst 2008), Edward N. Zalta (Hrsg.), Kommende URL =. >.
• Fuchs, NE, 1992, "Spezifikationen sind (vorzugsweise) ausführbar". Software Engineering Journal 7 (5): 323–334.
• Gandy, R., 1980, "These und Prinzipien der Kirche für Mechanismen", Kleene-Symposium, Barwise, J., Keisler, HJ und Kunen, K. (Hrsg.), Amsterdam: Nordholland.
• Hagar, Amit, 2007, „Quantenalgorithmen: Philosophische Lektionen“, Minds and Machines 17 (2): 233–247.
• Hale, B. und Wright, C., 2001, "The Reason's Proper Study: Essays zur neofregeanischen Philosophie der Mathematik", Oxford Scholarships on Line, Oxford: Oxford University Press.
• Hartmanis, J., 1993, „Einige Beobachtungen über die Natur der Informatik“, Lecture Notes in Computer Science 761, Shyamasundar, RK (Hrsg.): 1–12.
• Hartmanis, J., 1994, „Turing Award Lecture: Über Computerkomplexität und die Natur der Informatik“, Communications of the ACM 37 (10): 37–43.
• Hoare, CAR, 1969, "Eine axiomatische Basis für die Computerprogrammierung". Mitteilungen des ACM 12 (10): 576–585. [Nachdruck online verfügbar]
• Hodges, A., 2006, „Hatten Church und Turing eine These über Maschinen?“, These der Kirche nach 70 Jahren Olszewski, Adam (Hrsg.)
• Hodges, A., 2007, "Kann Quantencomputer klassisch unlösbare Probleme lösen?"
• Horsten, L., 2008, "Philosophie der Mathematik", The Stanford Encyclopedia of Philosophy (Ausgabe Herbst 2008), Edward N. Zalta (Hrsg.), URL = .
• Immerman, N., 2006, "Computability and Complexity", Stanford Encyclopedia of Philosophy (Ausgabe Herbst 2006), Edward N. Zalta (Hrsg.), URL = .
• Irvine, AD, 2003, "Russell's Paradox", Stanford Encyclopedia of Philosophy (Ausgabe Herbst 2006), Edward N. Zalta (Hrsg.), URL =
• Jones, CB und Hayes, IJ, 1990, „Spezifikationen sind nicht (notwendigerweise) schädlich“, Software Engineering Journal 4 (6): 330–339.
• Krishnamurthi, S., 2003. Programmiersprachen: Anwendung und Interpretation,
• Kreisel, G., Gandy, RO, 1975, "Einige Gründe für die Verallgemeinerung der Rekursionstheorie." The Journal of Symbolic Logic 40 (2): 230–232.
• Kripke, S., 1982, Wittgenstein über Regeln und Privatsprache. Harvard University Press.
• Kuhn, TS, 1970, Die Struktur wissenschaftlicher Revolutionen, 2.. Hrsg., Chicago: Univ. von Chicago Press.
• Landin, PJ, 1964, „Die mechanische Bewertung von Ausdrücken“, Computer Journal 6 (4): 308–320.
• Milne, R. und Strachey, C., 1977, A Theory of Programming Language Semantics, New York, NY: Halsted Press.
• McLaughlin, B., 2004, „Computationalism, Connectionism and the Philosophy of Mind“, Der Blackwell-Leitfaden zur Philosophie des Rechnens und der Information, Floridi, Luciano (Hrsg.) Malden: Blackwell, S. 135–152.
• Minsky, M., 1970, „ACM Turing Lecture: Form und Inhalt in der Informatik“, Journal der Association for Computing Machinery 17 (2): 197–215.
• Moor, JH, 1978, „Drei Mythen der Informatik“, British Journal for the Philosophy of Science 29 (3): 213–222.
• Moschovakis, YN, 1998, "Über die Gründung der Theorie der Algorithmen", Truth in Mathematics Dales, Harold G. und Oliveri, Gianluigi (Hrsg.), Oxford: Oxford University Press.
• Pierce, Benjamin C., 2002, Typen und Programmiersprachen, Cambridge, MA: MIT Press.
• Plotkin, GD, 1981, "Ein struktureller Ansatz zur operativen Semantik", Tech. Rep. DAIMI FN-19, Institut für Informatik, Universität Aarhus, Aarhus, Dänemark.
• Rapaport, WJ, 2005a, „Philosophie der Informatik: Ein Einführungskurs“, Teaching Philosophy 28 (4): 319–341.
• Rapaport, WJ, 2005b, „Implementierung ist semantische Interpretation: Weitere Gedanken.“Journal of Experimental and Theoretical Artificial Intelligence 17 (4): 385–417.
• Rosen, Gideon, 2001. "Abstract Objects", Stanford Encyclopedia of Philosophy (Ausgabe Herbst 2001), Edward N. Zalta (Hrsg.), URL = .
• Shapiro, S., 1997, Philosophie der Mathematik: Struktur und Ontologie, Oxford: Oxford University Press.
• Sieg, Wilfried, 2008, „Kirche ohne Dogma: Axiome für die Berechenbarkeit“, New Computational Paradigms, Lowe, B., Sorbi, A. und Cooper, B. (Hrsg.), Springer-Verlag, 139–152.
• Smith, BC, 1996, „Grenzen der Korrektheit in Computern“, Computerisierung und Kontroverse, Kling, R. (Hrsg.), Morgan Kaufman, S. 810–825.
• Szabó, ZG, 2007, „Kompositionalität“, Stanford Encyclopedia of Philosophy (Ausgabe Frühjahr 2007), Edward N. Zalta (Hrsg.), URL = .
• Thomason, R., 2005, "Logik und künstliche Intelligenz", The Stanford Encyclopedia of Philosophy (Ausgabe Sommer 2005), Edward N. Zalta (Hrsg.), URL = .
• Turner, Raymond und Eden, Amnon H., 2007, "Towards Programming Language Ontology", Berechnung, Information, Kognition - Der Nexus und das Liminal, Dodig-Crnkovic, Gordana und Stuart, Susan (Hrsg.), Cambridge, Großbritannien: Cambridge Scholars Press, S. 147–159.
• Turner, Raymond, 2005, „The Foundations of Specification“, Journal of Logic Computation 15: 623–662.
• Turner, Raymond, 2007, „Programmiersprachen verstehen“. Minds and Machines 17 (2): 129-133
• Tymoczko, T., 1979, „Das Vierfarbenproblem und seine philosophische Bedeutung“, Journal of Philosophy 76 (2): 57–83.
• White, G., 2004, „Die Philosophie der Computersprachen“, The Blackwell Guide to the Philosophy of Computing and Information, Floridi, Luciano (Hrsg.), Malden: Blackwell, S. 318–326.
• Wing, JM, 2006, „Computational Thinking“, Mitteilungen des ACM, 49 (3): 33–35.
• Wittgenstein, L., 1953. Philosophische Untersuchungen. Blackwell Publishing.
• Wright, Crispin, 1983, Freges Konzeption von Zahlen als Objekte, Aberdeen University Press.

Andere Internetquellen

• Philosophie der Informatik an der Essex University
• Internationale Vereinigung für Informatik und Philosophie