La Philosophie De L'informatique

Table des matières:

La Philosophie De L'informatique
La Philosophie De L'informatique

Vidéo: La Philosophie De L'informatique

Vidéo: La Philosophie De L'informatique
Vidéo: Philosophie de l'action et langage de l'informatique, par Michel Volle (26 sept. 2013) 2024, Mars
Anonim

Ceci est un fichier dans les archives de l'Encyclopédie de Stanford de Philosophie. Informations sur l'auteur et la citation | Aperçu PDF d'amis | Recherche InPho | Bibliographie PhilPapers

La philosophie de l'informatique

Première publication ven.12 décembre 2008

La philosophie de l'informatique (PCS) s'intéresse aux questions philosophiques qui découlent d'une réflexion sur la nature et la pratique de la discipline universitaire de l'informatique. Mais quel est ce dernier? Ce n'est certainement pas seulement de la programmation. Après tout, de nombreuses personnes qui écrivent des programmes ne sont pas des informaticiens. Par exemple, les physiciens, les comptables et les chimistes le font. En effet, l'informatique serait mieux décrite comme étant concernée par la méta-activité associée à la programmation. Plus généralement, et plus précisément, il s'occupe de la conception, du développement et de l'investigation des concepts et des méthodologies qui facilitent et aident à la spécification, au développement, à la mise en œuvre et à l'analyse des systèmes informatiques. Des exemples de cette activité pourraient inclure la conception et l'analyse de langages de programmation, de spécification et de description architecturale;la construction et l'optimisation de compilateurs, interprètes, prouveurs de théorèmes et systèmes d'inférence de types; l'invention de cadres logiques et la conception de systèmes embarqués, et bien plus encore. Bon nombre des questions philosophiques centrales de l'informatique entourent et sous-tendent ces activités, et nombre d'entre elles sont centrées sur les questions logiques, ontologiques et épistémologiques qui la concernent. Cependant, en fin de compte, l'informatique est ce que font les informaticiens, et aucune définition de formule exacte ne peut servir de plus qu'un guide pour la discussion qui suit. En effet, l'espoir est queBon nombre des questions philosophiques centrales de l'informatique entourent et sous-tendent ces activités, et nombre d'entre elles sont centrées sur les questions logiques, ontologiques et épistémologiques qui la concernent. Cependant, en fin de compte, l'informatique est ce que font les informaticiens, et aucune définition de formule exacte ne peut servir de plus qu'un guide pour la discussion qui suit. En effet, l'espoir est queBon nombre des questions philosophiques centrales de l'informatique entourent et sous-tendent ces activités, et nombre d'entre elles sont centrées sur les questions logiques, ontologiques et épistémologiques qui la concernent. Cependant, en fin de compte, l'informatique est ce que font les informaticiens, et aucune définition de formule exacte ne peut servir de plus qu'un guide pour la discussion qui suit. En effet, l'espoir est que PCS contribuera à terme à une compréhension plus approfondie de la nature de l'informatique.

Mais cartographier le paysage philosophique de l'informatique n'est pas une tâche facile. Heureusement, les branches traditionnelles de la philosophie peuvent fournir des conseils intellectuels et structurels. Par exemple, dans les philosophies des mathématiques et de la physique, il y a des questions centrales concernant la nature des objets traités, ce qui constitue la connaissance et les moyens d'obtenir cette connaissance. La philosophie du langage soulève des questions sur le contenu et la forme d'une théorie sémantique du langage naturel. Il met en évidence les hypothèses ontologiques et épistémologiques sous-jacentes de l'entreprise sémantique. L'ontologie indique les types de choses qui existent, comment les individualiser et leur rôle dans l'élaboration de nos schémas conceptuels. La philosophie de la logique fournit un compte rendu et une analyse des différents types de systèmes logiques et de leur rôle dans le discours quotidien et spécialisé. Les analogies et les similitudes de ces branches et d'autres de la philosophie devraient s'avérer utiles pour identifier et clarifier certaines des préoccupations philosophiques centrales de l'informatique. L'influence existante de ces disciplines sur PCS émergera au fur et à mesure que nous avancerons. En particulier, les deuxième, troisième et quatrième sections refléteront l'impact de l'ontologie et les philosophies du langage et des mathématiques.

  • 1. Quelques problèmes centraux
  • 2. Existence et identité

    • 2.1 La double nature des programmes
    • 2.2 Programmes et algorithmes
    • 2.3 Programmes et spécifications
  • 3. Sémantique

    • 3.1 Sémantique dénotationnelle et opérationnelle
    • 3.2 Mise en œuvre et interprétation sémantique
    • 3.3 Sémantique, égalité et identité
  • 4. Preuves et programmes

    • 4.1 Preuves en informatique
    • 4.2 Preuves en mathématiques
    • 4.3 Exactitude physique et abstraite
  • 5. Calculabilité

    5.1 La thèse de Church-Turing

  • 6. Programmation et langages de programmation

    • 6.1 Abstraction
    • 6.2 Types et ontologie
  • 7. Questions juridiques et éthiques

    • 7.1 Droits d'auteur, brevets et identité
    • 7.2 Exactitude et responsabilité
  • 8. Nouveaux rebondissements ou nouveaux problèmes?
  • Bibliographie
  • Autres ressources Internet
  • Entrées connexes

1. Quelques problèmes centraux

Pour commencer, nous énumérerons ce que nous considérons comme certaines des questions et questions centrales. Cela fournira au lecteur un bref aperçu des questions qui complèteront la discussion plus détaillée à venir. Bien que bon nombre d'entre eux n'aient pas été directement abordés dans la littérature et nécessitent des éclaircissements, ces questions illustrent les types de problèmes auxquels nous considérons que le SCP s'intéresse.

  1. Quels types de choses sont des programmes? Sont-ils abstraits ou concrets? (Maure 1978; Colburn 2004)
  2. Quelles sont les différences entre les programmes et les algorithmes? (Rapaport 2005a)
  3. Qu'est-ce qu'une spécification? Et qu'est-ce qui est spécifié? (Smith 1985; Turner 2005)
  4. Les spécifications sont-elles fondamentalement différentes des programmes? (Smith 1985)
  5. Qu'est-ce qu'une implémentation? (Rapaport 2005b)
  6. Qu'est-ce qui distingue le matériel du logiciel? Les programmes existent-ils sous des formes physiques et symboliques? (Maure 1978; Colburn 2004)
  7. Quels types de choses sont des objets numériques? Avons-nous besoin d'une nouvelle catégorie ontologique pour les héberger? (Allison et al.2005)
  8. Quels sont les objectifs des différentes théories sémantiques des langages de programmation? (Blanc 2004; Turner 2007)
  9. Comment les questions de la philosophie des langages de programmation se rapportent-elles aux questions parallèles de la philosophie du langage? (Blanc 2004)
  10. Le principe de modularité (par exemple, Dijkstra 1968) est-il lié aux problèmes conceptuels de l'abstraction totale et de la compositionnalité?
  11. Quelles sont les différences conceptuelles sous-jacentes entre les paradigmes de programmation suivants: programmation structurée, fonctionnelle, logique et orientée objet?
  12. Quels sont les rôles des types en informatique? (Barandregt 1992; Pierce 2002)
  13. Quelle est la différence entre la sémantique opérationnelle et dénotationnelle? (Turner 2007)
  14. Qu'est-ce que cela signifie pour un programme d'être correct? Quel est le statut épistémologique des preuves d'exactitude? Sont-ils fondamentalement différents des preuves en mathématiques? (DeMillo et al. 1979; Smith 1985)
  15. Qu'est-ce que les preuves d'exactitude établissent? (Fetzer 1988; Fetzer 1999; Colburn 2004)
  16. Qu'est-ce que l'abstraction en informatique? Comment est-ce lié à l'abstraction en mathématiques? (Colburn et Shute 2007; Fine 2008; Hale et Wright 2001)
  17. Quelles sont les méthodes formelles? Qu'est-ce que les méthodes formelles sont formelles? Quelle est la différence entre une méthode formelle et informelle? (Bowen et Hinchey 2005; Bowen et Hinchey 1995)
  18. Quel genre de discipline est l'informatique? Quels sont les rôles de la modélisation mathématique et de l'expérimentation? (Minsky 1970; Denning 1980; Denning 1981; Denning et al.1989; Denning 1985; Denning 1980b; Hartmanis 1994; Hartmanis1993; Hartmanis 1981; Colburn 2004; Eden 2007)
  19. Les programmes doivent-ils être considérés comme des théories scientifiques? (Rapaport 2005a)
  20. Comment les mathématiques sont-elles utilisées en informatique? Les modèles mathématiques sont-ils utilisés de manière descriptive ou normative? (Blanc 2004; Turner 2007)
  21. La thèse de Church-Turing capture-t-elle la notion mathématique d'une méthode efficace ou mécanique en logique et en mathématiques? Capture-t-il les calculs qui peuvent être effectués par un humain? Son champ d'application s'applique-t-il aux machines physiques? (Copeland 2004; Copeland 2007; Hodges 2006)
  22. La notion de pensée computationnelle peut-elle résister à un examen philosophique? (Aile 2006)
  23. Quelle est la logique appropriée pour raisonner sur l'exactitude et la fin du programme? (Hoare 1969; Feferman 1992) Comment la logique dépend-elle du langage de programmation sous-jacent?
  24. Qu'est-ce que l'information? (Floridi 2004; Floridi 2005) Cette notion éclaire-t-elle certaines des questions énumérées ici?
  25. Pourquoi y a-t-il tant de langages de programmation et de paradigmes de programmation? (Krishnamurthi 2003)
  26. Les langages de programmation (et paradigmes) ont-ils la nature de théories scientifiques? Qu'est-ce qui cause un changement de paradigme de programmation? (Kuhn 1970)
  27. Le génie logiciel soulève-t-il des problèmes philosophiques? (Éden 2007)

Dans ce qui suit, nous allons concrétiser quelques-unes de ces questions.

2. Existence et identité

Comment catégoriser et individualiser les entités et les concepts de l'informatique? De quel genre de choses s'agit-il et qu'est-ce qui détermine leur identité? Par exemple, certains sont des objets physiques clairement concrets (par exemple, des puces, des routeurs, des ordinateurs portables, des cartes graphiques) et d'autres non (par exemple des grammaires formelles, des machines abstraites, des prouveurs de théorèmes, des cadres logiques, des algèbres de processus, des types de données abstraits). Mais la caractérisation de certaines des notions centrales telles que les programmes et les données a été plus problématique. En particulier, le statut ontologique des programmes a été considéré comme n'étant pas tout à fait simple, pas plus que la question de leurs critères d'identité.

2.1 La double nature des programmes

De nombreux auteurs (Moor 1978; Rapaport 2005b; Colburn 2004) discutent de la soi-disant double nature des programmes. À première vue, un programme semble avoir à la fois une apparence textuelle et mécanique ou semblable à un processus. Sous forme de texte, un programme peut être édité. Mais sa manifestation sur un disque lisible par machine semble avoir des propriétés assez différentes. En particulier, il peut être exécuté sur une machine physique. Ainsi selon le principe de l'indiscernabilité des identiques (§3.3), les deux apparences ne peuvent pas être la même entité. Bien entendu, quiconque est persuadé par cette dualité est dans l'obligation de dire quelque chose sur la relation entre ces deux formes apparentes d'existence.

Une suggestion immédiate est qu'une manifestation d'un programme est une mise en œuvre de l'autre, c'est-à-dire que la manifestation physique est une mise en œuvre du texte. Cependant, même dans les limites de l'informatique, il n'est pas immédiatement clair que le mot implémentation renvoie à une seule notion. Souvent, il est utilisé pour désigner le résultat d'un processus de compilation où un programme dans un langage de haut niveau (le code source) est transformé en langage machine (le code objet). Mais tout aussi souvent, il est utilisé pour désigner le processus où le code source est en quelque sorte directement réalisé dans le matériel (par exemple une implémentation concrète dans les semi-conducteurs). Et probablement, c'est la notion pertinente. Mais sans une analyse philosophique plus détaillée de la notion d'implémentation (§3.2) elle-même (Rapaport 2005b),on ne sait pas comment cela fait avancer la discussion; il semble que nous n'ayons nommé que la relation entre les deux formes apparentes d'existence. Dans le même ordre d'idées, d'autres ont décrit la relation entre le texte-programme et le processus-programme comme étant similaire à celle entre un plan et sa manifestation comme une série d'actions physiques. Mais cela ne semble pas être tout à fait analogue au couple programme-processus: nous ne sommes pas tentés de désigner le plan et le processus physique comme étant des manifestations différentes de la même chose. Par exemple, sommes-nous tentés de penser à un plan de promenade et à la marche réelle comme des facettes différentes de la même chose?d'autres ont décrit la relation entre le texte-programme et le processus-programme comme étant similaire à celle entre un plan et sa manifestation comme une série d'actions physiques. Mais cela ne semble pas être tout à fait analogue au couple programme-processus: nous ne sommes pas tentés de désigner le plan et le processus physique comme étant des manifestations différentes de la même chose. Par exemple, sommes-nous tentés de penser à un plan de promenade et à la marche réelle comme des facettes différentes de la même chose?d'autres ont décrit la relation entre le texte-programme et le processus-programme comme étant similaire à celle entre un plan et sa manifestation comme une série d'actions physiques. Mais cela ne semble pas être tout à fait analogue au couple programme-processus: nous ne sommes pas tentés de désigner le plan et le processus physique comme étant des manifestations différentes de la même chose. Par exemple, sommes-nous tentés de penser à un plan de promenade et à la marche réelle comme des facettes différentes de la même chose?Sommes-nous tentés de penser à un plan de promenade et à la marche proprement dite comme des facettes différentes de la même chose?Sommes-nous tentés de penser à un plan de promenade et à la marche proprement dite comme des facettes différentes de la même chose?

Peut-être que les choses sont mieux décrites en disant que les programmes, en tant qu'objets textuels, provoquent des processus mécaniques? L'idée semble être que d'une manière ou d'une autre, l'objet textuel provoque physiquement le processus mécanique. Mais cela semblerait exiger une analyse assez minutieuse de la nature d'une telle relation causale. Colburn (2004) nie que le texte symbolique ait un effet causal; c'est sa manifestation physique (la chose sur le disque) qui a un tel effet. Le logiciel est une abstraction concrète qui a un moyen de description (le texte, l'abstraction) et un moyen d'exécution (par exemple, une implémentation concrète dans les semi-conducteurs).

Une perspective légèrement différente sur ces questions part de la question de l'identité du programme. Quand deux programmes sont-ils considérés comme identiques? De tels problèmes se posent, par exemple, lors des tentatives de détermination de l'identité juridique d'un logiciel. Si nous identifions un programme avec sa manifestation textuelle, alors l'identité d'un programme est sensible aux changements dans son apparence (par exemple, changer la police). De toute évidence, ce n'est pas le texte seul qui nous fournit une notion philosophiquement intéressante de l'identité du programme. Au contraire, pour atteindre un critère d'identité éclairé, nous devons tenir davantage compte de la sémantique et de la mise en œuvre. Nous reviendrons sur ce sujet aux §3 et §6.

2.2 Programmes et algorithmes

Quelle que soit la vision que nous avons des programmes, la distinction algorithme-programme nécessite également une clarification conceptuelle supplémentaire. Les algorithmes sont souvent considérés comme des objets mathématiques. Si cela est vrai, nombre des questions philosophiques les concernant appartiennent également à la philosophie des mathématiques. Cependant, les algorithmes sont sans doute plus au cœur de l'informatique que des mathématiques et méritent plus d'attention philosophique qu'ils ne l'ont été. Bien qu'il y ait eu une étude mathématique considérable des algorithmes en informatique théorique et en logique mathématique (par exemple, Moschovakis 1997; Blass & Gurevich 2003), il n'y a pas eu beaucoup de discussions philosophiques centrées sur la nature des algorithmes et les différences entre algorithmes et programmes.

Est-ce que les algorithmes sont des objets abstraits, au sens proposé par Rosen (2001), alors que les programmes sont concrets? Plus précisément, les algorithmes sont-ils la contrepartie mathématique abstraite d'un objet textuel qu'est le programme? Cette image se prête naturellement à une forme de platonisme ontologique (Shapiro 1997) où les algorithmes ont une priorité ontologique et les programmes fournissent les moyens linguistiques pour y parvenir. Dans cette optique, les algorithmes pourraient être considérés comme fournissant la sémantique (§3) des langages de programmation. Bien sûr, cette image hérite de tous les avantages et problèmes d'une telle perspective platonicienne (Shapiro 1997).

Une vision moins platonicienne veut que les algorithmes contiennent les idées exprimées dans un programme. En droit, cela a été considéré comme la raison pour laquelle les algorithmes, par opposition aux programmes, ne sont pas protégés par le droit d'auteur (§7.1). Bien entendu, le terme idée nécessite une analyse philosophique plus approfondie. En effet, on pourrait soutenir que la notion pure d'algorithme a beaucoup moins besoin d'être clarifiée que le compte rendu standard des idées et des notions d'abstraction qui lui sont associées (Rosen 2001).

Enfin, c'est presque une vision folklorique que les machines de Turing nous fournissent une analyse formelle de notre notion d'algorithme. Mais cela correspond-il à la notion contemporaine employée dans l'informatique moderne avec ses notions sophistiquées de représentation et de contrôle? Moschovakis (1997) propose une analyse qui fait un peu mieux.

2.3 Programmes et spécifications

Une autre distinction populaire qui devrait faire l'objet d'une analyse critique concerne les programmes et les spécifications. Que sont les spécifications et en quoi sont-elles différentes des programmes? Bien qu'il y ait peu de discussions directes sur cette question dans la littérature philosophique (mais voir Smith 1985), la nature des spécifications est une question fondamentale pour les fondements conceptuels de l'informatique.

Un point de vue, communément trouvé dans les manuels sur la spécification formelle, est que les programmes contiennent des instructions détaillées sur la machine alors que les spécifications (fonctionnelles) ne décrivent que la relation entre l'entrée et la sortie. Une manière évidente de décortiquer ceci est en termes de distinction impératif / descriptif: les programmes sont impératifs et décrivent comment atteindre l'objectif décrit par la spécification. Certes, dans le paradigme de la programmation impérative, cela semble saisir une différence de fond. Mais cela ne convient pas à tous. Par exemple, les langages de programmation logiques, fonctionnels et orientés objet ne sont pas évidemment régis par celui-ci: pris au pied de la lettre, les programmes encodés dans de tels langages consistent en des séquences de définitions et non en des «instructions». En outre,Les spécifications non fonctionnelles ne peuvent pas être articulées comme des déclarations sur la relation entre l'entrée et la sortie parce qu'elles imposent des exigences sur la conception et sur le type d'instructions qui peuvent être incluses dans tout programme.

Un autre point de vue insiste sur le fait que la différence entre les spécifications et les programmes doit être localisée en termes de notion d'implémentation, c'est-à-dire peut-elle être compilée et exécutée? Mais qu'entend-on par là? Est-ce que cela veut dire avoir un compilateur existant? Cette interprétation est plutôt superficielle car elle n'offre pas un critère conceptuel de distinction mais un critère contingent. Par exemple, au cours des cinq premières générations de langages de programmation (2e moitié du 20e siècle), les spécifications récursives, modulaires, fonctionnelles et orientées objet d'une génération en sont venues à être articulées en tant que programmes dans la suivante, c'est-à-dire les langages de spécification actuels. deviennent fréquemment les langages de programmation de demain.

Un autre point de vue suggère que les langages de programmation sont les langages qui ont une implémentation en principe alors que les langages de spécification sont ceux qui ne le peuvent pas. Et vraisemblablement, la raison pour laquelle ils ne le peuvent pas est que les langages de spécification permettent d'exprimer des notions qui ne sont pas calculables par Turing. Cette distinction est conforme à de nombreux langages de spécification existants basés sur la théorie des ensembles de Zermelo-Fraenkel et la logique d'ordre supérieur. Cependant, il semble étrange que ce qui devrait caractériser un langage de spécification soit le fait qu'il puisse exprimer des propriétés et des relations non calculables. Certaines de ces demandes non calculables sont-elles vraiment nécessaires dans la pratique (Jones et Hayes 1990; Fuchs 1994)?

La diversité de ces points de vue suggère que la division binaire traditionnelle entre les spécifications et les programmes est un exemple d'un problème dans PCS qui mérite plus d'attention, non seulement pour la clarification conceptuelle, mais aussi parce qu'il pourrait avoir des implications pour la conception des futurs langages de programmation et de spécification..

3. Sémantique

La grammaire d'un langage de programmation ne détermine que ce qui est syntaxiquement légitime; il ne nous informe pas de la signification voulue de ses constructions. Ainsi, la grammaire d'un langage de programmation ne détermine pas par elle-même la chose dans laquelle les gens programment. C'est plutôt la grammaire enrichie d'un compte sémantique (formel ou informel) qui est prise pour le faire. La sémantique est destinée à informer le programmeur, le rédacteur du compilateur et le théoricien intéressé par l'exploration des propriétés du langage. En effet, on prétend souvent que pour répondre aux différentes exigences du programmeur et du rédacteur du compilateur, différents comptes sémantiques, à différents niveaux d'abstraction, sont nécessaires. Et le travail du théoricien est d'explorer leur relation.

C'est l'image standard qui se dégage de la littérature sémantique. Mais une grande partie de cela nécessite une clarification conceptuelle. Dans cette section, nous examinons quelques-uns des problèmes qui découlent de cette activité.

3.1 Sémantique dénotationnelle et opérationnelle

L'une des distinctions les plus importantes dans la sémantique des langages de programmation est centrée sur la distinction entre la sémantique opérationnelle et dénotationnelle. Une sémantique opérationnelle (Landin 1964; Plotkin 1981) fournit une interprétation d'un langage de programmation en termes de machine abstraite. Plus précisément, il s'agit d'une traduction d'expressions du langage de programmation dans les instructions ou programmes de la machine abstraite. Par exemple, le programme 1 serait décompressé dans une séquence d'opérations abstraites de la machine comme «a ← 0» et push. La sémantique opérationnelle peut également être conçue comme une sémantique algorithmique, en particulier lorsque la machine sous-jacente vise à caractériser la notion même d'algorithme (eg, Moschovakis 1997).

En revanche, une sémantique dénotationnelle (Milne & Strachey 1977) fournit une interprétation dans des structures mathématiques telles que des ensembles ou des catégories. Par exemple, dans l'approche classique, les ensembles - sous la forme de réseaux complets et de fonctions continues sur eux - fournissent le cadre mathématique.

Mais y a-t-il une différence conceptuelle significative entre eux? Est-ce que la sémantique dénotationnelle, étant explicitement basée sur des structures mathématiques telles que les ensembles, est mathématique alors que la sémantique opérationnelle ne l'est pas? Turner (2007) soutient que non: ils fournissent tous des interprétations mathématiques.

Ou est-ce que la sémantique opérationnelle ressemble davantage à une machine, dans le sens de constituer une machine abstraite, alors qu'avec la sémantique dénotationnelle, qui est donnée en termes de théorie des ensembles, il n'y a pas de signe de machine abstraite? Cependant, de telles distinctions ne se sont pas avérées significatives sur le plan conceptuel, car les comptes sémantiques dénotationnels peuvent tous être considérés comme des structures qui constituent une machine abstraite avec des états et des opérations opérant sur eux. Les comptes opérationnels ne sont pas non plus plus proches de la mise en œuvre: les approches dénotationnelles (Milne & Strachey 1977) sont également très flexibles et sont capables de refléter différents niveaux de détail de mise en œuvre.

Une autre distinction possible concerne la nature compositionnelle (ou non) de la sémantique. En gros, une sémantique est considérée comme compositionnelle (Szabó 2007) si la valeur sémantique d'une expression complexe est fonction des valeurs sémantiques de ses parties. La compositionnalité est considérée comme un critère crucial de la sémantique puisqu'elle semble nécessaire pour expliquer la productivité de notre compréhension linguistique: on dit qu'elle explique comment nous comprenons et construisons des programmes complexes. Mais cela nous fournit-il un coin pour séparer la sémantique opérationnelle et dénotationnelle? Malheureusement, il ne semble pas le faire: alors que les définitions dénotationnelles sont conçues pour être compositionnelles, il n'est certainement pas vrai que toutes les sémantiques opérationnelles ne sont pas compositionnelles.

Enfin, certaines versions de la sémantique diffèrent concernant l'existence d'un modèle récursif, c'est-à-dire une interprétation dans les machines de Turing ou de Gandy (§5.1). Cependant, même cela ne correspond pas exactement à la fracture opérationnelle / dénotationnelle traditionnelle. Certaines définitions dénotationnelles ont un modèle récursif et d'autres pas.

Il semble très difficile de cerner cette distinction. À première vue, il n'apparaît pas de distinction conceptuelle nette entre la sémantique opérationnelle et la sémantique dénotationnelle.

3.2 Mise en œuvre et interprétation sémantique

Quelle est la différence entre une interprétation sémantique et une implémentation? Par exemple, quelle est la différence conceptuelle entre compiler un programme en code machine et lui donner une sémantique dénotationnelle? Selon Rapaport (2005b), une implémentation est mieux vue comme une interprétation sémantique, où cette dernière est caractérisée par un mappage entre deux domaines: un syntaxique et un sémantique. Et les deux sont déterminés par des règles d'une certaine description. Par exemple, le code compilé (en combinaison avec les règles qui régissent sa sémantique) est le compte sémantique du code source.

Dans une compréhension commune du terme «implémentation», le domaine sémantique est fourni par une machine physique. En d'autres termes, la machine physique elle-même (la «mise en œuvre») détermine ce que signifie le programme. Par exemple, dans les langages de programmation, cela équivaut à l'affirmation selon laquelle la sémantique du langage de programmation C ++ est déterminée par l'ordinateur de Bjarne exécutant son compilateur C ++. Mais cette explication est évidemment insuffisante: si nous supposons que la machine de Bjarne détermine le sens des programmes C ++ alors il n'y a aucune notion de dysfonctionnement ou de mauvaise interprétation: quoi que fasse l'ordinateur de Bjarne, c'est ipso facto le sens du programme. Mais il est certain qu'un orage électrique peut provoquer un dysfonctionnement de la machine. Mais que pourrions-nous dire par une erreur? Vraisemblablement, que la machine (défectueuse) n'incarne pas le sens voulu. Mais,à son tour, il semble que nous ne soyons capables de comprendre cette phrase que sur la base d'une certaine caractérisation de la signification indépendante de la machine. Et à un certain niveau, cela doit être donné via une description sémantique indépendante. Cela suggère que la notion d'implémentation nue n'offre pas une notion adéquate de sémantique. (Comparer avec: Kripke 1982; Wittgenstein 1953).

3.3 Sémantique, égalité et identité

Nous avons conclu notre discussion sur l'égalité des programmes (§2.1) par la promesse d'introduire la sémantique dans l'image. Chaque compte sémantique d'un langage de programmation détermine une notion d'égalité pour les programmes, c'est-à-dire que deux programmes sont considérés comme égaux s'ils ont la même valeur sémantique, c'est-à-dire

P = Q ssi || P || = || Q ||

où || P || est la valeur sémantique du programme P. Donc, en ce sens, chaque récit sémantique détermine un critère d'égalité. Par exemple, une version de la sémantique dénotationnelle ferait abstraction de toutes les étapes de calcul et assimilerait les programmes qui, dans un certain sens, calculent la même fonction mathématique. Par exemple, les deux programmes suivants seraient considérés comme égaux selon ce critère:

fonction Factorielle (n: entier): entier

commence

si n = 0

alors Factorielle: = 1;

else

Factorielle: = (n) * Factorielle (n -1);

fin;

Programme 1

fonction Factorielle (n: entier): entier

var

x, y: entier;

commencer

y: = 1;

x: = 0;

tandis que x <n commencez

x: = x +1;

y: = y * x;

fin

Factorielle: = y;

fin;

Programme 2

En revanche, une vue plus opérationnelle, qui fait référence aux étapes du calcul, ne prendrait pas le programme 1 et le programme 2 pour être égaux. En effet, à la lumière du §3.1, nous pouvons concevoir des comptes sémantiques qui reflètent n'importe quel niveau de détail d'implémentation. Différents comptes sémantiques déterminent différentes notions d'égalité qui peuvent servir différentes fins conceptuelles et pratiques. Mais alors lequel faut-il prendre pour déterminer la langue? Heureusement, certaines desiderata peuvent être appliquées; nous pouvons réduire les options: certains comptes sémantiques nous fournissent une notion d'identité logiquement satisfaisante, d'autres non.

L' indiscernabilité des identiques est un principe intégré à la logique ordinaire des prédicats. Il déclare que si deux objets sont égaux, ils partagent toutes les propriétés. Le principe inverse, l' identité des indiscernablesdéclare que si, pour chaque propriété F, l'objet x a F si et seulement si l'objet y a F, alors x est identique à y. L'identité des indiscernables implique que si x et y sont distincts, alors il y a au moins une propriété que x a et y n'a pas. Parfois, la conjonction des deux principes est connue sous le nom de loi de Leibniz (Forrest 2006). La loi de Leibniz est souvent considérée comme essentielle pour toute notion d'égalité. Ces lois sont généralement formulées dans des théories logiques telles que la logique du second ordre. Mais nous serons plus intéressés par leur capacité à faire la distinction entre les différents types de sémantique du langage de programmation. En effet, la loi de Leibniz est l'une des notions centrales de la théorie sémantique moderne. Le critère d'identité est étoffé en termes d'équivalence observationnelle.

Deux programmes M et N sont définis comme étant équivalents sur le plan d'observationsi et seulement si, dans tous les contextes C […] où C [M] est un programme valide, c'est le cas que C [N] est aussi un programme valide avec la même valeur sémantique. Par exemple, on dit qu'Oracle et DB2 (programmes manipulant des bases de données relationnelles) sont équivalents du point de vue observationnel selon un certain compte sémantique des opérations sur les bases de données relationnelles si et seulement si les exécutant dans le «même» contexte (système d'exploitation, architecture de machine, entrée, etc.) donne la «même» base de données. Bien sûr, le terme équivalent sur le plan d'observation doit être pris avec une pincée de sel. Nous ne pouvons clairement pas observer le comportement d'un programme dans tous les contextes. Cependant, l'équivalence observationnelle reflète une demande conceptuelle sous-jacente qui émane des principes d'indiscernibilité des identiques et de l'identité des indiscernables.

En sémantique, si tous les programmes observablement distincts ont des valeurs sémantiques distinctes, la sémantique est dite solide. Par conséquent, une sémantique solide satisfait au principe suivant:

|| P || = || Q || implique que pour tous les contextes C, || C [P] || = || C [Q] ||

Il doit être clair que la notion d'identité induite par une sémantique sonore satisfait l'indiscernabilité des identiques.

Une sémantique est dite complète si deux programmes avec des valeurs sémantiques distinctes sont observablement distincts. Plus précisément, une sémantique complète satisfait ce qui suit:

Pour tous les contextes C, || C [P] || = || C [Q] || implique || P || = || Q ||

Encore une fois, il doit être évident qu'une sémantique complète satisfait au principe d'identité des indiscernables.

Enfin, la sémantique est dite totalement abstraite si elle est solide et complète. Par conséquent, une sémantique totalement abstraite satisfait la loi de Leibniz.

Ce contexte logique fournit la justification philosophique du développement d'une sémantique totalement abstraite. Il nous offre ainsi un moyen de sélectionner des comptes sémantiques qui fournissent des notions d'égalité philosophiquement acceptables. Il ne détermine bien sûr aucune notion unique. Il ne fournit qu'un outil pour rejeter ceux qui ne peuvent pas en fournir un conceptuellement acceptable. De nombreuses sémantiques dites dénotationnelles ne sont pas totalement abstraites, alors que de nombreuses sémantiques opérationnelles le sont. En effet, l'un des sujets centraux de l'histoire récente de la sémantique a impliqué la recherche de définitions entièrement abstraites qui sont moulées dans la classe des techniques de définition sémantique qui sont prises pour fournir une sémantique dénotationnelle.

La sémantique joue un rôle normatif ou déterminant en informatique. Sans définitions sémantiques, les langages et les structures n'ont pas de contenu en plus de celui fourni par leurs descriptions syntaxiques. Et ces derniers sont à peine suffisants à des fins pratiques ou philosophiques. Bien que nous ayons commencé l'analyse des préoccupations centrales, nous n'avons fait qu'effleurer la surface.

4. Preuves et programmes

Les spécifications (§2.3) induisent une notion particulière d'exactitude. Selon l'interprétation abstraite de cette notion, un programme est considéré comme correct par rapport à une spécification (fonctionnelle) si la relation qu'il établit entre l'entrée et la sortie satisfait à celle établie par la spécification. Plus précisément, si p est un programme, alors il répond à une spécification R, qui est considérée comme une relation entre le type d'entrée I et le type de sortie O, si ce qui suit est vrai:

Pour toutes les entrées, i de type I, le couple (i, p (i)), satisfait la relation R

où p (i) est le résultat de l'exécution du programme p sur l'entrée i. Ici, R est exprimé dans un langage de spécification et p dans un langage de programmation. La première est généralement une variante de la logique de prédicat (typée) et les preuves d'exactitude (c'est-à-dire que l'énoncé (1) est vrai) sont effectuées dans le système de preuve de la logique. Par exemple, la logique de Hoare (Hoare 1969) est fréquemment utilisée, dans laquelle les preuves d'exactitude prennent la forme d'inférences entre triplets, écrites

B {P} A

où P est un programme et B et A sont des assertions (les états «avant» et «après» du programme) exprimées dans une version de la logique des prédicats avec des fonctionnalités qui facilitent l'expression des valeurs attachées aux variables du programme.

Une controverse philosophique qui entoure la question de l'exactitude se concentre sur la nature de telles preuves; les autres défis ce que ces preuves fournissent.

4.1 Preuves en informatique

Les preuves de l'exactitude des programmes sont-elles de véritables preuves mathématiques, c'est-à-dire, ces preuves sont-elles sur un pied d'égalité avec les preuves mathématiques classiques? DeMillo et coll. (1979) affirment que parce que les preuves d'exactitude sont longues et mathématiquement superficielles, elles sont différentes des preuves en mathématiques qui sont conceptuellement intéressantes, convaincantes et attirent l'attention d'autres mathématiciens qui veulent les étudier et les développer. Par exemple, une preuve dans la logique de Hoare à l'effet que le programme 2 calcule la fonction factorielle contiendrait des détails sur la notion sous-jacente d'état, utiliserait un argument inductif et impliquerait un raisonnement sur l'invariance de boucle.

Mais de telles preuves seraient beaucoup plus longues que le programme lui-même. En outre, le niveau auquel le raisonnement est codé dans la logique Hoare exigerait l'expression et la représentation de nombreux détails qui seraient normalement laissés implicites. Ce serait fastidieux et, dans le cas de la plupart des programmes, conceptuellement trivial.

Cet argument est parallèle aux arguments de saisissabilité avancés dans la philosophie des mathématiques (par exemple, Tymoczko 1979; Burge 1988). En son cœur se trouvent des inquiétudes épistémologiques: des preuves trop longues, lourdes et inintéressantes ne peuvent pas être porteuses du genre de certitude qui est attribuée aux preuves mathématiques classiques. On prétend que la nature des connaissances obtenues à partir des preuves d'exactitude est différente des connaissances qui peuvent être glanées à partir des preuves en mathématiques [1].

Il faut également distinguer cette perspective essentiellement sociologique des preuves de celle qui soutient que les preuves sont bonnes ou mauvaises d'une manière indépendante de tels jugements épistémologiques. Il est possible de conserver la position plus réaliste selon laquelle toute preuve donnée est soit correcte, soit incorrecte sans renoncer à l'exigence que les preuves, pour être acceptées et validées, doivent être saisissables.

On pourrait tenter de gagner du terrain en préconisant que les preuves d'exactitude soient vérifiées par un ordinateur plutôt que par un humain. Mais bien sûr, le vérificateur d'épreuve a lui-même besoin d'être vérifié. Arkoudas et Bringsjord (2007) soutiennent que s'il n'y a qu'une seule preuve d'exactitude à vérifier, à savoir celle du vérificateur de preuve lui-même, alors la possibilité d'erreurs est considérablement réduite.

4.2 Preuves en mathématiques

Les preuves mathématiques telles que la preuve du théorème d'incomplétude de Gödel sont également longues et compliquées. Mais ce qui les rend transparents, intéressants et saisissables («enquêtables») par la communauté mathématique est l'utilisation de techniques de modularité (par exemple les lemmes) et l'utilisation de l'abstraction dans l'acte de création mathématique. L'introduction de nouveaux concepts permet de construire progressivement une preuve, rendant ainsi les preuves plus compréhensibles. Les mathématiques progressent en inventant de nouveaux concepts mathématiques qui permettent la construction de preuves de plus haut niveau et plus générales qui seraient bien plus complexes et même impossibles sans elles. Par exemple, la notation exposant permet d'effectuer des calculs au-delà de la complexité de la multiplication - et d'argumenter sur les résultats. À l'autre extrême,l'invention de la théorie des catégories a facilité l'énoncé et la preuve de résultats très généraux sur les structures algébriques qui s'appliquent automatiquement à toute une gamme de telles. Les mathématiques ne sont pas seulement une question de preuve; cela implique également l'abstraction et la création de nouveaux concepts et de nouvelles notations. À première vue, les preuves formelles d'exactitude n'emploient pas, en général, la création de nouveaux concepts ou ne s'impliquent pas dans le processus d'abstraction mathématique. En revanche, l'abstraction en informatique (§6.1) se concentre sur les notions nécessaires à la conception de programmes. Mais comment ces deux notions d'abstraction sont-elles liées? Nous en dirons un peu plus plus tard.cela implique également l'abstraction et la création de nouveaux concepts et de nouvelles notations. À première vue, les preuves formelles d'exactitude n'emploient pas, en général, la création de nouveaux concepts ou ne s'impliquent pas dans le processus d'abstraction mathématique. En revanche, l'abstraction en informatique (§6.1) se concentre sur les notions nécessaires à la conception de programmes. Mais comment ces deux notions d'abstraction sont-elles liées? Nous en dirons un peu plus plus tard.cela implique également l'abstraction et la création de nouveaux concepts et de nouvelles notations. À première vue, les preuves formelles d'exactitude n'emploient pas, en général, la création de nouveaux concepts ou ne s'impliquent pas dans le processus d'abstraction mathématique. En revanche, l'abstraction en informatique (§6.1) se concentre sur les notions nécessaires à la conception de programmes. Mais comment ces deux notions d'abstraction sont-elles liées? Nous en dirons un peu plus plus tard.

4.3 Exactitude physique et abstraite

Même si nous mettons de côté ces inquiétudes épistémologiques, une seconde critique apparemment plus dévastatrice des preuves de l'exactitude remet en question ce qu'elles établissent réellement. Apparemment, une preuve d'exactitude n'apporte l'exactitude que jusqu'à la représentation textuelle du programme. Aucune quantité de travail formel ne peut nous faire passer la barrière abstraite / physique: nous ne pouvons jamais garantir qu'une exécution particulière du programme sur une machine physique se déroulera réellement comme prévu (Fetzer 1988; Fetzer 1999; Colburn 2004).

Mais que signifie le fait que le programme p soit correct? Supposons que nous ayons une spécification du programme - et qu'elle puisse être formelle ou informelle. Supposons ensuite que nous effectuions une série de tests pour vérifier que le programme répond à ses spécifications. S'ils réussissent, nous avons des preuves empiriques que la contrepartie physique du programme textuel est en effet correcte car elle fonctionne selon la spécification. De ce point de vue, c'est la contrepartie physique qui était testée; pas le programme textuel.

Cette analyse suggère qu'il existe une dualité dans la notion d'exactitude des programmes. Conformément à la double nature des programmes, on pourrait dire que le programme textuel est soumis à l'exactitude mathématique, tandis que son homologue physique est soumis à une vérification empirique.

5. Calculabilité

La calculabilité est l'un des sujets les plus anciens pouvant être qualifiés de PCS. Cependant, il fait l'objet de plusieurs entrées SEP (par exemple, Barker-Plummer 2004) et nous ne mentionnerons donc que quelques sujets et leurs liens avec le reste de la présente entrée.

5.1 La thèse de Church-Turing

L'une des questions centrales est la thèse de Church-Turing. Et ici, il y a deux conflits, l'un historique et l'autre empirique. Ils se concentrent sur les deux interprétations possibles suivantes de la thèse:

  1. Les machines de Turing peuvent faire tout ce qui pourrait être décrit comme une «règle empirique» ou «purement mécanique».
  2. Tout ce qui peut être calculé par une machine (travaillant sur des données finies selon un programme fini d'instructions) est calculable par machine de Turing.

L'interprétation I vise à saisir la notion de méthode efficace ou mécanique en logique et en mathématiques. Il est censé refléter la notion informelle d'algorithme implicite en mathématiques et mise en avant par le programme de Hilbert. L'interprétation II est censée régir les machines physiques. En effet, (Gandy 1980) peut être vu comme un déballage supplémentaire de II. Gandy propose quatre principes destinés à caractériser le calcul par une machine physique. Il montre que de telles machines s'accordent exactement avec la caractérisation de Turing (Théorème de Gandy). En relation avec notre discussion sur les différents paradigmes sémantiques, il est clair que bon nombre des machines qui sous-tendent la sémantique dénotationnelle (§3.1) ne sont pas qualifiées de machines de Gandy. Ils fonctionnent le plus souvent avec des espaces de fonctions d'extension d'ordre supérieur,et ceux-ci ne peuvent être considérés comme des données finies et ne satisfont pas aux conditions de Gandy.

Certains affirment (Copeland 2004; Copeland 2008) que la thèse proposée par Church et Turing ne concerne que l'interprétation I et ne fixe pas de limite aux machines en général. Hodges (2007) n'est pas d'accord. Il soutient que Church et Turing n'ont pas fait de distinction entre les deux interprétations. C'est le différend historique.

Le différend physique concerne les capacités des machines réelles (interprétation II.) Beaucoup tiennent pour acquis que la thèse de Church-Turing caractérise et prescrit le calcul physique réel. Par exemple, cela semble être l'hypothèse implicite de l'informatique traditionnelle. Il est certain que chaque programme écrit dans un langage de programmation implémenté existant est Turing calculable et inversement, que tous les langages de programmation à usage général sont Turing complets, c'est-à-dire qu'ils contiennent toutes les constructions de contrôle nécessaires pour simuler une machine de Turing universelle.

Copeland (2007) soutient que la caractérisation par Gandy d'un dispositif mécanique déterministe discret est trop étroite, et par conséquent il existe des exemples de machines physiques possibles dont les capacités dépassent la classe des fonctions calculables de Turing. Beaucoup de ceux-ci nécessitent une accélération infinie, grâce à quoi un nombre infini de calculs peut être effectué physiquement en un temps fini. L'informatique quantique a été citée comme un exemple possible pour de telles machines, mais cela a été contesté (Hodges 2007; Hagar 2007).

Hodges s'intéresse également à l'applicabilité de l'argumentation mathématique standard en physique aux cas où une précision infinie est impliquée. Cela donne à penser que ce différend n'est pas une simple question empirique. En effet, il y a ceux qui se demandent s'il est physiquement possible d'accomplir un nombre infini de tâches en un temps fini. Dummett (2006) se demande si la notion même d'une tâche infinie qui doit être effectuée dans le domaine physique n'est pas seulement une impossibilité physique mais aussi une notion conceptuelle. Le différend n'est donc pas seulement empirique mais va au cœur de notre compréhension de la relation entre nos modèles mathématiques et la réalité physique.

6. Programmation et langages de programmation

La conception de programmes et de langages de programmation est l'une des activités traditionnelles de l'informatique. Une foule de questions conceptuelles les entoure (§1), dont beaucoup n'ont reçu aucune attention philosophique. Nous passerons ici brièvement en revue deux de ces problèmes.

6.1 Abstraction

L'abstraction est l'une des pierres angulaires conceptuelles de l'informatique. Il fait partie intégrante de la conception et de la construction de programmes et constitue une méthodologie de base pour la conception de langages de programmation. En effet, il conduit à la création de nouveaux paradigmes de programmation. Il sous-tend l'invention de notions telles que l'abstraction procédurale et fonctionnelle, le polymorphisme, l'abstraction de données, les objets et les classes, les modèles de conception, les styles architecturaux, le sous-typage et l'héritage. De nombreuses branches du génie logiciel (par exemple, la modélisation de logiciels, la compréhension de programmes, la visualisation de programmes, la rétro-ingénierie et la réingénierie) sont principalement concernées par l'étude des mécanismes appropriés pour l'abstraction des programmes. Et une grande partie des progrès de l'ingénierie logicielle a été réalisée grâce à l'introduction de nouveaux mécanismes d'abstraction.

Mais quelle est la nature de l'abstraction en informatique? Quelle est son explication philosophique sous-jacente? Malheureusement, en général, l'idée même d'abstraction est philosophiquement problématique. Selon la vision traditionnelle, qui a ses origines dans la psychologie philosophique, l'abstraction est un processus mental dans lequel de nouvelles conceptions sont formées en considérant plusieurs objets ou idées et en omettant les caractéristiques qui les distinguent. (Rosen 2001). Mais, cette approche a peu, voire aucun, partisans philosophiques contemporains.

Une approche plus logique de l'analyse de l'abstraction, qui bénéficie d'un solide plaidoyer (Wright 1983; Hale 1987). Mais on ne sait pas si ces idées, qui ont été développées pour l'abstraction mathématique, sont applicables à l'informatique. De toute évidence, certaines des notions d'abstraction en informatique ont été inspirées ou étudiées au moyen d'abstractions en mathématiques. Mais quelle est la relation conceptuelle entre l'abstraction dans ces disciplines? Sont-ils fondamentalement différents? Malheureusement, s'il existe une littérature substantielle sur les fondements philosophiques de l'abstraction mathématique (voir Wright 1983; Hale 1987; Fine 2002), l'investigation conceptuelle de l'abstraction en informatique n'en est qu'à ses débuts. Colburn (2007) suggère que la distinction entre l'abstraction en mathématiques et l'abstraction en informatique réside dans le fait qu'en mathématiques l'abstraction est une négligence de l'information alors qu'en informatique, c'est une dissimulation de l'information. Autrement dit, les abstractions en mathématiques ignorent ce qui est jugé non pertinent (par exemple la couleur de triangles similaires). En revanche, en informatique, tous les détails ignorés à un niveau d'abstraction (par exemple, les programmeurs Java n'ont pas à se soucier de l'emplacement précis en mémoire associé à une variable particulière) ne doivent pas être ignorés par l'un des niveaux inférieurs (par exemple le virtuel machine gère toutes les allocations de mémoire).les abstractions en mathématiques ignorent ce qui est jugé non pertinent (par exemple, la couleur de triangles similaires). En revanche, en informatique, tous les détails ignorés à un niveau d'abstraction (par exemple, les programmeurs Java n'ont pas à se soucier de l'emplacement précis en mémoire associé à une variable particulière) ne doivent pas être ignorés par l'un des niveaux inférieurs (par exemple le virtuel machine gère toutes les allocations de mémoire).les abstractions en mathématiques ignorent ce qui est jugé non pertinent (par exemple, la couleur de triangles similaires). En revanche, en informatique, tous les détails ignorés à un niveau d'abstraction (par exemple, les programmeurs Java n'ont pas à se soucier de l'emplacement précis en mémoire associé à une variable particulière) ne doivent pas être ignorés par l'un des niveaux inférieurs (par exemple le virtuel machine gère toutes les allocations de mémoire).

Mais est-ce basé sur une notion trop simpliste d'abstraction en mathématiques? Y a-t-il juste un type de notion? Par exemple, l'information cachée dans l'analyse de Bishop (Bishop 1970) est assez différente de la notion d'abstraction de Wright - en fait, elle est assez similaire à celle de l'informatique.

6.2 Types et ontologie

Les langages de programmation sont principalement des langages typés, où la notion moderne de type trouve ses origines dans Frege et Russell et en particulier dans la théorie simple des types de Russell (Irvine 2003). Bien sûr, Russell était motivé par les paradoxes logiques et sémantiques et cette fonctionnalité n'est pas centrale dans l'application des types à l'informatique. D'un autre côté, pour les types de Russell, les types de Russell découpent l'univers du discours d'une manière qui a une importance à la fois grammaticale et sémantique. Et cette idée s'est propagée à l'informatique. En effet, les théories des types ont été inspirées et enrichies par l'informatique. Par exemple, la théorie des types de Russell, bien que mathématiquement puissante, est quelque peu appauvrie dans son pouvoir expressif par rapport aux théories des types des langages informatiques modernes (Coquand 2006; Pierce 2002). Outre une gamme de types de base tels que les nombres et les booléens, les langages de programmation contiennent une collection de constructeurs de types (moyens de construire de nouveaux types à partir des anciens). Par exemple, ceux-ci incluent la possibilité de former une sorte de produit cartésien et d'ensembles finis. Dans de nombreux langages de programmation orientés objet, les types (classes) peuvent importer (et remplacer) les opérations d'autres types et offrir des constructeurs plus sophistiqués qui prennent en charge la formation de types de données abstraits et diverses formes de polymorphisme.types (classes) peuvent importer (et surcharger) des opérations d'autres types et offrir des constructeurs plus sophistiqués qui prennent en charge la formation de types de données abstraits et diverses formes de polymorphisme.types (classes) peuvent importer (et surcharger) des opérations d'autres types et offrir des constructeurs plus sophistiqués qui prennent en charge la formation de types de données abstraits et diverses formes de polymorphisme.

En informatique, les types jouent un rôle à mi-chemin entre la syntaxe et la sémantique. Premièrement, ils étendent notre notion normale de grammaire sans contexte. Certaines fonctionnalités du langage, en particulier celles qui permettent de fixer le type d'une variable par le contexte (c'est-à-dire les déclarations de la langue) nécessitent une forme de grammaire plus flexible que la standard. Les grammaires dites à deux niveaux, bien que techniquement adéquates, ne capturent pas la manière dont les variables sont affectées à leurs types dans les langues modernes. Et ils sont très maladroits à utiliser. Ils ne s'adaptent pas non plus facilement aux systèmes de types polymorphes de nombreux langages. Les systèmes de types modernes font mieux: leurs types sont affectés aux variables via des déclarations, par exemple x: Boolean. Par la suite, un compilateur peut vérifier le type du programme, par exemple,il peut garantir que l'occurrence d'une variable dans les instructions suivantes (par exemple x

Mais les types jouent également un rôle d'exactitude qui ne serait normalement pas décrit en termes syntaxiques. Pour ce faire, il étend la notion physique traditionnelle d'analyse dimensionnelle à un système de types beaucoup plus riche. Obtenir la bonne structure de type pour un programme permet de garantir son exactitude. Et cela est déterminé par la structure que les types imposent à une langue. Les types corrigent les types de choses qui existent dans un langage de programmation. Ainsi, par exemple, tout langage de programmation qui admet des nombres, des produits et des classes, et rien d'autre, impose un cadre conceptuel au programmeur dans lequel elle doit travailler. Les problèmes doivent être articulés et les solutions trouvées dans les moyens de représentation fournis par le système de types. Une fois que la structure de type d'un langage de programmation a été définie, une grande partie de son cadre ontologique a été corrigée.

Ou l'a-t-il? Peut-être faut-il prendre du recul et se demander d'abord comment les engagements ontologiques d'une langue doivent être déterminés. Est-ce la sémantique qui détermine les choses (Turner & Eden 2007)? Une longue tradition qui émane de Frege le suggère (Dummett 1991). En supposant que l'analogie avec les langues naturelles est légitime, l'ontologie d'un langage est déterminée par les structures nécessaires pour fournir ses domaines sémantiques. Mais quelle théorie sémantique faut-il adopter? Alors que toute sémantique doit prendre en compte les types, l'ontologie déterminée sémantiquement les dépasserait et refléterait les domaines sémantiques impliqués, et ceux-ci refléteraient les détails de mise en œuvre inclus dans la sémantique. De ce fait, comme pour l'égalité, différentes interprétations sémantiques déterminent différentes ontologies. Il s'ensuit qu'il n'est pas sensé de parler de l'ontologie d'un langage de programmation mais de plusieurs ontologies qui dépendent du niveau d'abstraction impliqué dans la sémantique. Par exemple, l'ontologie peut également être partiellement déterminée par le paradigme de programmation.

7. Questions juridiques et éthiques

Certaines questions d'éthique informatique relèvent du PCS dans la mesure où l'activité de construction et d'utilisation de logiciels pose des questions éthiques. Cependant, beaucoup ne sont pas spécifiques à l'informatique au sens étroit de cette entrée; ils empiètent sur l'ensemble des technologies de l'information et des applications informatiques (Bynum 2001). Par conséquent, nous n'en mentionnerons que deux qui semblent au cœur de l'informatique.

7.1 Droits d'auteur, brevets et identité

Les droits d'auteur offrent une certaine protection aux logiciels, mais ils ne peuvent pas protéger son noyau sémantique. Et nous supposons que ce dernier est à déterminer par un compte sémantique (§3) du langage de programmation dans lequel le programme est écrit. Vraisemblablement, l'essence de cette question concerne le problème de l'identité des programmes (§3.3). Mais s'il existe de nombreuses notions sémantiques possibles de l'identité, laquelle est appropriée pour une application juridique?

Un récit sémantique informel souvent cité en droit identifie le programme avec les idées qui y sont exprimées, le plus souvent considéré comme son algorithme sous-jacent. Mais non seulement il est souvent difficile de dire exactement ce qu'est cet algorithme, mais aussi, comme pour les théorèmes mathématiques, les algorithmes ne peuvent pas être protégés par le droit d'auteur. Et à peu près le même sort attend tout récit sémantique formel puisque tout tel serait déterminé par une notion mathématique, que ce soit des algorithmes ou une notion d'opération ou de fonction mathématique.

Mais même si nous pouvions localiser un compte sémantique conforme aux lois sur le droit d'auteur, l'image juridique ne serait pas complète. La violation du droit d'auteur dépend souvent non seulement d'une certaine identité, mais aussi du fait qu'il est plausible de supposer que quelqu'un proposerait le même programme. Alors que des considérations intentionnelles entrent dans le cadre. En d'autres termes, même lorsque deux programmes sont considérés comme équivalents selon notre critère sémantique, s'il pouvait être considéré comme plausible qu'ils aient été construits indépendamment, il n'y aurait pas de violation du droit d'auteur.

Les brevets (en particulier les brevets d'utilité) ne valent pas mieux. Ils sont encore plus difficiles à obtenir pour les logiciels car on ne peut pas breveter les processus mentaux, les idées abstraites et les algorithmes. Et ce sont les algorithmes plutôt que le code source qui contiennent souvent les nouvelles idées. Mais encore une fois, ce sont les enjeux d'identification et d'identité qui sont au cœur des préoccupations philosophiques. Et ceux-ci impliquent à la fois des considérations sémantiques et intentionnelles.

7.2 Exactitude et responsabilité

Est-il juste que le logiciel soit vendu avec peu de garanties d'aptitude à l'emploi? (Coleman 2008) est consacré à cette question. Cette question est particulièrement pertinente pour les systèmes critiques pour la sûreté, par exemple les systèmes qui surveillent les conditions médicales, exploitent des centrales nucléaires et communiquent avec les navettes spatiales. Dans ce cas, il semblerait essentiel d'appliquer des tests plus rigoureux et des preuves d'exactitude. Mais sur le plan éthique, le cas d'un programmeur qui ne parvient pas à analyser et à tester son programme est-il différent de celui d'un ingénieur civil qui ne parvient pas à effectuer la modélisation mathématique et les tests requis sur un bâtiment? Les obligations morales semblent similaires.

L'une des façons dont ils pourraient être différents concerne la complexité du logiciel (Brooks 1987) qui dépasse de plusieurs ordres de grandeur la complexité de tout autre type d'artefact humain. Beaucoup diront qu'il n'est pas possible d'offrir une telle garantie d'exactitude (DeMillo et al. 1979); le logiciel est si complexe que le processus de preuve mathématique rigoureuse et de test logiciel est impossible. Et, vraisemblablement, on ne peut avoir qu'une obligation (morale ou légale) de mener à bien un processus réalisable.

Mais comment équilibrer les aspects de vérification et de test du développement logiciel par rapport à l'utilisation prévue du logiciel? Les logiciels développés pour le divertissement devraient-ils être soumis au même degré de preuves et de tests rigoureux que les logiciels critiques pour la sécurité? Probablement pas, mais nous pourrions encore être tentés de demander, s’agit-il de nouveaux problèmes éthiques ou nous fournissent-ils simplement d’autres études de cas sur les dilemmes éthiques existants? Par exemple, même les problèmes de sécurité dans les logiciels utilisés dans l'industrie du divertissement peuvent entraîner des sanctions financières.

8. Nouveaux rebondissements ou nouveaux problèmes?

Même cet aperçu assez bref de PCSdevrait convaincre le lecteur que l'informatique soulève des questions philosophiques intéressantes et exigeantes. En effet, l'une des impressions dominantes est qu'il a des liens substantiels avec la plupart des branches traditionnelles de la philosophie. Il existe des liens clairs avec l'ontologie, l'éthique, l'épistémologie et les philosophies des mathématiques, de la physique et du langage. En effet, notre liste initiale de questions soulève de nombreux autres thèmes en lien avec d'autres domaines de la philosophie. En particulier, il existe une littérature substantielle sur les applications de l'informatique. L'intelligence artificielle et les sciences cognitives soulèvent des questions philosophiques qui appartiennent à la philosophie de l'esprit (McLaughlin 2004). Bien sûr, une grande partie de cela émane de Turing (1950). D'autres applications de l'informatique aux domaines traditionnels de la science, dite science computationnelle,créer des enjeux pour la philosophie des sciences: quel est l'impact épistémologique des simulations informatiques, surtout là où elles sont la seule forme d'expérimentation viable? Le virage informatique de l'ontologie amène de nouvelles techniques à agir sur la structure de tout type d'ontologie conceptuelle. La philosophie de la logique s'enrichit d'une masse de matériaux: un grand nombre de nouveaux systèmes logiques ont émergé à des fins de représentation et de raisonnement sur les systèmes informatiques.un grand nombre de nouveaux systèmes logiques ont vu le jour à des fins de représentation et de raisonnement sur les systèmes informatiques.un grand nombre de nouveaux systèmes logiques ont vu le jour à des fins de représentation et de raisonnement sur les systèmes informatiques.

S'il est clair que l'informatique soulève de nombreux rebondissements significatifs par rapport aux préoccupations philosophiques traditionnelles, ce qui est moins clair est de savoir si elle génère des préoccupations philosophiques véritablement nouvelles: y a-t-il des questions en PCS qui n'ont aucun parallèle dans aucune autre branche de la philosophie?

Bibliographie

  • Allison, A., Currall, J., Moss, M. et Stuart, S., 2005, «Questions d'identité numérique», Journal of American Society Information Science and Technology 56 (4): 364–372.
  • Arkoudas, K. et Bringsjord, S., 2007, «Ordinateurs, justification et connaissances mathématiques», Minds and Machines 17 (2): 185–202.
  • Barendregt, HP, 1993, «Lambda calculi with types», dans: Handbook of logic in computer science, Vol. 2, New York, NY: Oxford University Press Inc.
  • Barker-Plummer, D., 2008, «Turing Machines», The Stanford Encyclopedia of Philosophy (Fall 2008 Edition), Edward N. Zalta (éd.), URL = .
  • Bishop, Errett, 1977, Fondements de l'analyse constructive, McGraw-Hill.
  • Blass, Andreas et Gurevich, Yuri, 2003, «Algorithmes: une quête de définitions absolues», Bulletin de l'Association européenne pour l'informatique théorique (EATCS) n ° 81: 195-225.
  • Bowen, JP et Hinchey, MG, 1995, «Dix commandements de méthodes formelles», IEEE Computer 28 (4): 56–63.
  • Bowen, JP et Hinchey, MG, 2005, «Dix commandements de méthodes formelles: dix ans plus tard», IEEE Computer 39 (1): 40–48.
  • Brooks, FP, 1987, «No Silver Bullet: Essence and Accidents of Software Engineering», IEEE Computer 20 (4): 10-19.
  • Burge, T., 1998, «Preuve informatique, connaissances a priori et autres esprits», Perspectives philosophiques 12: 1–37.
  • Bynum, T., 2001, «Computer Ethics: Basic Concepts and Historical Overview», The Stanford Encyclopaedia of Philosophy (Winter 2001 Edition), Edward N. Zalta (ed.), URL =
  • Colburn, T., 2004, «Méthodologie de l'informatique», The Blackwell Guide to the Philosophy of Computing and Information, Luciano Floridi (ed.), Malden: Blackwell, pp. 318–326.
  • Colburn, T., et Shute, G., 2007, «Abstraction in Computer Science», Minds and Machines 17 (2): 169–184.
  • Coleman, KG, 2008, «Computing and Moral Responsibility», The Stanford Encyclopedia of Philosophy (Fall 2008 Edition), Edward N. Zalta (ed.), URL = .
  • Copeland, B. Jack, 2008, «The Church-Turing Thesis», The Stanford Encyclopedia of Philosophy (Fall 2008 Edition), Edward N. Zalta (ed.), URL = .
  • Copeland, B. Jack, 2004, «Computation», Le Guide Blackwell de la philosophie de l'informatique et de l'information, Luciano Floridi (éd.), Malden: Blackwell, pp. 3–17.
  • Coquand, Thierry, 2006, «Théorie des types», The Stanford Encyclopedia of Philosophy (Winter 2006 Edition), Edward N. Zalta (éd.), URL = .
  • DeMillo, RA, Lipton, RJ et Perlis, AJ, 1979, «Processus sociaux et preuves de théorèmes et programmes», Communications de l'ACM 22 (5): 271–280.
  • Denning, PJ, 1980, «Sur les théorèmes populaires et les mythes populaires», Communications de l'ACM 23 (9): 493–494.
  • Denning, PJ, 1980b, «Qu'est-ce que l'informatique expérimentale?» Communications de l'ACM 23 (10): 534-544.
  • Denning, PJ, 1981, «Analyse des performances: l'informatique expérimentale comme son meilleur», Communications de l'ACM 24 (11): 725–727.
  • Denning, PJ, 1985, «La science de l'informatique: qu'est-ce que l'informatique?» American Scientist 73 (1): 16–19.
  • Denning, PJ (ed.), Et al., 1989, «Computing as a Discipline», Communications of the ACM 32 (1): 9–23.
  • Dijkstra, E., 1968. «Aller à la déclaration considérée comme nuisible», communications de l'ACM 11 (3): 147-148.
  • Dummett, M., 1991, «La base logique de la métaphysique», Harvard University Press.
  • Dummett, M., 2006, «Pensée et réalité», Oxford University Press.
  • Eden, Amnon, 2007, «Trois paradigmes en informatique», Minds and Machines 17 (2): 135–167.
  • Feferman, S., 1992, «Logiques pour la terminaison et l'exactitude des programmes fonctionnels», Logic for Computer Science: 95-127, MSRI Pubs. vol. 21, New York, NY: Springer-Verlag.
  • Fetzer, JH, 1988, «Vérification du programme: l'idée même», Communications de l'ACM 31 (9): 1048–1063.
  • Fetzer, JH, 1999, «Le rôle des modèles en informatique», The Monist 82 (1): 20–36.
  • Fine, K., 2008, «Les limites de l'abstraction». Oxford: Presse d'université d'Oxford.
  • Floridi, Luciano, 2004. «Information», Le Guide de Blackwell sur la philosophie de l'informatique et de l'information, Luciano Floridi (éd.), Malden: Blackwell, pp. 40–62.
  • Floridi, Luciano 2007, «Conceptions sémantiques de l'information», The Stanford Encyclopedia of Philosophy (Spring 2007 Edition), Edward N. Zalta (éd.), URL = .
  • Forrest, P., 2006, «The Identity of Indiscernibles», The Stanford Encyclopedia of Philosophy (Fall 2008 Edition), Edward N. Zalta (ed.), URL à paraître =. >.
  • Fuchs, NE, 1992, «Les spécifications sont (de préférence) exécutables». Journal de génie logiciel 7 (5): 323–334.
  • Gandy, R., 1980, «La thèse de l'Église et les principes des mécanismes», Le symposium de Kleene, Barwise, J., Keisler, HJ et Kunen, K. (éd.), Amsterdam: North-Holland.
  • Hagar, Amit, 2007, «Algorithmes quantiques: leçons philosophiques», Minds and Machines 17 (2): 233–247.
  • Hale, B. et Wright, C., 2001, «L'étude appropriée de la raison: essais vers la philosophie néo-frégéenne des mathématiques», Oxford Scholarships on Line, Oxford: Oxford University Press.
  • Hartmanis, J., 1993, «Quelques observations sur la nature de l'informatique», Notes de cours en informatique 761, Shyamasundar, RK (éd.): 1–12.
  • Hartmanis, J., 1994, «Conférence Turing Award: On Computational Complexity and the Nature of Computer Science», Communications of the ACM 37 (10): 37–43.
  • Hoare, CAR, 1969, «Une base axiomatique pour la programmation informatique». Communications de l'ACM 12 (10): 576–585. [Réimpression disponible en ligne]
  • Hodges, A., 2006, «Church et Turing avaient-ils une thèse sur les machines?», Thèse de Church après 70 ans Olszewski, Adam (éd.)
  • Hodges, A., 2007, «L'informatique quantique peut-elle résoudre des problèmes classiquement insolubles?»
  • Horsten, L., 2008, «Philosophie des mathématiques», The Stanford Encyclopedia of Philosophy (Fall 2008 Edition), Edward N. Zalta (éd.), URL = .
  • Immerman, N., 2006, «Computability and Complexity», The Stanford Encyclopedia of Philosophy (Fall 2006 Edition), Edward N. Zalta (ed.), URL = .
  • Irvine, AD, 2003, «Russell's Paradox», The Stanford Encyclopedia of Philosophy (Fall 2006 Edition), Edward N. Zalta (éd.), URL =
  • Jones, CB et Hayes, IJ, 1990, «Les spécifications ne sont pas (nécessairement) nuisibles», Software Engineering Journal 4 (6): 330–339.
  • Krishnamurthi, S., 2003. Langages de programmation: application et interprétation,
  • Kreisel, G., Gandy, RO, 1975, «Quelques raisons de généraliser la théorie de la récursivité». Le Journal of Symbolic Logic 40 (2): 230–232.
  • Kripke, S., 1982, Wittgenstein sur les règles et le langage privé. Presse universitaire de Harvard.
  • Kuhn, TS, 1970, La structure des révolutions scientifiques, 2e. éd., Chicago: Univ. de Chicago Press.
  • Landin, PJ, 1964, «L'évaluation mécanique des expressions», Computer Journal 6 (4): 308–320.
  • Milne, R. et Strachey, C., 1977, Une théorie de la sémantique du langage de programmation, New York, NY: Halsted Press.
  • McLaughlin, B., 2004, «Computationalism, Connectionism, and the Philosophy of Mind», The Blackwell Guide to Philosophy of Computing and Information, Floridi, Luciano (ed.) Malden: Blackwell, pp. 135–152.
  • Minsky, M., 1970, «Conférence ACM Turing: Forme et contenu en informatique», Journal de l'Association for Computing Machinery 17 (2): 197–215.
  • Moor, JH, 1978, «Trois mythes de l'informatique», The British Journal for the Philosophy of Science 29 (3): 213-222.
  • Moschovakis, YN, 1998, «Sur la fondation de la théorie des algorithmes», Truth in Mathematics Dales, Harold G. et Oliveri, Gianluigi (éds.), Oxford: Oxford University Press.
  • Pierce, Benjamin C., 2002, Types et langages de programmation, Cambridge, MA: MIT Press.
  • Plotkin, GD, 1981, «Une approche structurelle de la sémantique opérationnelle», Tech. Rep. DAIMI FN-19, Département d'informatique, Université d'Aarhus, Aarhus, Danemark.
  • Rapaport, WJ, 2005a, «Philosophie de l'informatique: un cours d'introduction», Philosophie d'enseignement 28 (4): 319–341.
  • Rapaport, WJ, 2005b, «La mise en œuvre est l'interprétation sémantique: réflexions supplémentaires.» Journal d'Intelligence Artificielle Expérimentale et Théorique 17 (4): 385–417.
  • Rosen, Gideon, 2001. «Objets abstraits», The Stanford Encyclopedia of Philosophy (Fall 2001 Edition), Edward N. Zalta (éd.), URL = .
  • Shapiro, S., 1997, Philosophie des mathématiques: structure et ontologie, Oxford: Oxford University Press.
  • Sieg, Wilfried, 2008, «Église sans dogme: axiomes pour la calculabilité», New Computational Paradigms, Lowe, B., Sorbi, A. et Cooper, B. (éd.), Springer-Verlag, 139–152.
  • Smith, BC, 1996, «Limites de l'exactitude des ordinateurs», Computerization and Controversy, Kling, R. (ed.), Morgan Kaufman, pp. 810–825.
  • Szabó, ZG, 2007, «Compositionality», The Stanford Encyclopedia of Philosophy (Spring 2007 Edition), Edward N. Zalta (éd.), URL = .
  • Thomason, R., 2005, «Logic and Artificial Intelligence», The Stanford Encyclopedia of Philosophy (Summer 2005 Edition), Edward N. Zalta (éd.), URL = .
  • Turner, Raymond et Eden, Amnon H., 2007, «Towards Programming Language Ontology», Computation, Information, Cognition-The Nexus and the Liminal, Dodig-Crnkovic, Gordana and Stuart, Susan (eds.), Cambridge, UK: Cambridge Scholars Press, pp. 147–159.
  • Turner, Raymond, 2005, «Les fondements de la spécification», Journal of Logic Computation 15: 623–662.
  • Turner, Raymond, 2007, «Comprendre les langages de programmation». Esprits et machines 17 (2): 129-133
  • Tymoczko, T., 1979, «Le problème à quatre couleurs et sa signification philosophique», Journal of Philosophy 76 (2): 57–83.
  • White, G., 2004, «La philosophie des langages informatiques», Le guide Blackwell de la philosophie de l'informatique et de l'information, Floridi, Luciano (éd.), Malden: Blackwell, pp. 318–326.
  • Wing, JM, 2006, «Computational Thinking», Communications of the ACM, 49 (3): 33–35.
  • Wittgenstein, L., 1953. Enquêtes philosophiques. Blackwell Publishing.
  • Wright, Crispin, 1983, Conception de Frege des nombres comme objets, Aberdeen University Press.

Autres ressources Internet

  • Philosophie de l'informatique, à l'Université d'Essex
  • Association internationale pour l'informatique et la philosophie

Recommandé: