Filosofia Informaticii

2023 Autor: Noah Black | [email protected]. Modificat ultima dată: 2023-08-25 04:39

Acesta este un fișier din arhivele Enciclopediei de Filozofie din Stanford. Informații despre autor și citare | Prieteni PDF Previzualizare | Căutare InPho | Bibliografie PhilPapers

Filosofia informaticii

Publicat pentru prima dată vineri 12 decembrie 2008

Filosofia informaticii (PCS)) este preocupat de problemele filozofice care decurg din reflecția asupra naturii și practicii disciplinei academice a informaticii. Dar ce este acesta din urmă? Cu siguranță, nu este doar programare. La urma urmei, mulți oameni care scriu programe nu sunt informaticieni. De exemplu, fizicieni, contabili și chimiști. Într-adevăr, informatica ar fi mai bine descrisă ca fiind preocupată de meta-activitatea care este asociată cu programarea. Mai general, și mai precis, este ocupat cu proiectarea, dezvoltarea și investigarea conceptelor și metodologiilor care facilitează și ajută la specificarea, dezvoltarea, implementarea și analiza sistemelor de calcul. Exemplele acestei activități pot include proiectarea și analiza limbajelor de programare, specificații și descrieri arhitecturale;construcția și optimizarea compilatoarelor, interpreților, a teoremelor și a sistemelor de inferență de tip; inventarea cadrelor logice și proiectarea sistemelor încorporate și multe altele. Multe dintre problemele filozofice centrale ale informaticii înconjoară și stau la baza acestor activități, iar multe dintre ele se concentrează asupra problemelor logice, ontologice și epistemologice care îl privesc. Cu toate acestea, la final, informatica este ceea ce fac oamenii de informatică și nicio definiție formulă exactă nu poate acționa mai mult decât un ghid al discuției care urmează. Într-adevăr, speranța este aceeaMulte dintre problemele filozofice centrale ale informaticii înconjoară și stau la baza acestor activități, iar multe dintre ele se concentrează asupra problemelor logice, ontologice și epistemologice care îl privesc. Cu toate acestea, la final, informatica este ceea ce fac oamenii de informatică și nicio definiție formulă exactă nu poate acționa mai mult decât un ghid al discuției care urmează. Într-adevăr, speranța este aceeaMulte dintre problemele filozofice centrale ale informaticii înconjoară și stau la baza acestor activități, iar multe dintre ele se concentrează asupra problemelor logice, ontologice și epistemologice care îl privesc. Cu toate acestea, la final, informatica este ceea ce fac oamenii de informatică și nicio definiție formulă exactă nu poate acționa mai mult decât un ghid al discuției care urmează. Într-adevăr, speranța este aceea PCS va contribui în cele din urmă la o mai bună înțelegere a naturii informaticii.

Dar identificarea peisajului filosofic al informaticii nu este o sarcină ușoară. Din fericire, ramurile tradiționale ale filozofiei pot oferi orientări intelectuale și structurale. De exemplu, în filozofiile matematicii și fizicii, există întrebări centrale cu privire la natura obiectelor tratate, ce constituie cunoașterea și mijloacele de obținere a acestei cunoștințe. Filosofia limbajului ridică întrebări despre conținutul și forma unei teorii semantice pentru limbajul natural. El aduce în prim-plan presupunerile ontologice și epistemologice de bază ale întreprinderii semantice. Ontologia indică tipurile de lucruri existente, cum să le individualizăm și rolul lor în încadrarea schemelor noastre conceptuale. Filosofia logicii oferă o relatare și o analiză a diferitelor tipuri de sisteme logice și rolul lor în discursul cotidian și specializat. Analogiile și asemănările din aceste și alte ramuri ale filozofiei ar trebui să se dovedească utile în identificarea și clarificarea unora dintre preocupările filozofice centrale ale informaticii. Influența existentă a acestor discipline asupra PC-urile vor apărea pe măsură ce vom continua. În special, a doua, a treia și a patra secțiune vor reflecta impactul ontologiei și filozofiile limbajului și ale matematicii.

• 1. Câteva probleme centrale

• 2. Existență și identitate

  • 2.1 Natura dublă a programelor
  • 2.2 Programe și algoritmi
  • 2.3 Programe și specificații

• 3. Semantica

  • 3.1 Semantica denotațională și operațională
  • 3.2 Implementarea și interpretarea semantică
  • 3.3 Semantica, egalitatea și identitatea

• 4. Probe și programe

  • 4.1 Dovezi în informatică
  • 4.2 Dovezi în matematică
  • 4.3 Corectitudinea fizică și abstractă

• 5. Calculabilitate

  5.1 Teza Bisericii

• 6. Limbi de programare și programare

  • 6.1 Abstracție
  • 6.2 Tipuri și ontologie

• 7. Întrebări legale și etice

  • 7.1 Drepturi de autor, brevete și identitate
  • 7.2 Corectitudinea și responsabilitatea
• 8. Noutăți noi sau probleme noi?
• Bibliografie
• Alte resurse de internet
• Intrări conexe

1. Câteva probleme centrale

Pentru început vom enumera ceea ce considerăm că sunt unele dintre problemele și întrebările centrale. Acest lucru va oferi cititorului o prezentare rapidă a problemelor care vor completa discuțiile mai detaliate. Deși multe dintre ele nu au fost abordate direct în literatura de specialitate și au nevoie de unele clarificări, aceste întrebări ilustrează tipurile de probleme cu care ne ocupăm PCS.

1. Ce fel de lucruri sunt programe? Sunt abstracte sau concrete? (Moor 1978; Colburn 2004)
2. Care sunt diferențele dintre programe și algoritmi? (Rapaport 2005a)
3. Ce este o specificație? Și ce se specifică? (Smith 1985; Turner 2005)
4. Specificațiile sunt în mod fundamental diferite de programe? (Smith 1985)
5. Ce este o implementare? (Rapaport 2005b)
6. Ce distinge hardware-ul de software? Există programe atât în forme fizice, cât și în cele simbolice? (Moor 1978; Colburn 2004)
7. Ce fel de lucruri sunt obiecte digitale? Avem nevoie de o nouă categorie ontologică pentru a le adăposti? (Allison și colab., 2005)
8. Care sunt obiectivele diferitelor teorii semantice ale limbajelor de programare? (Alb 2004; Turner 2007)
9. Cum se raportează întrebările din filosofia limbajelor de programare la cele paralele din filosofia limbajului? (Alb 2004)
10. Principiul modularității (de exemplu, Dijkstra 1968) se referă la problemele conceptuale ale abstracției complete și compoziționalității?
11. Care sunt diferențele conceptuale de bază între următoarele paradigme de programare: programare structurată, funcțională, logică și orientată pe obiect?
12. Care sunt rolurile tipurilor în informatică? (Barandregt 1992; Pierce 2002)
13. Care este diferența dintre semantica operațională și cea denotațională? (Turner 2007)
14. Ce înseamnă pentru un program să fie corect? Care este starea epistemologică a probelor de corectitudine? Sunt fundamental diferite de dovezile din matematică? (DeMillo et al. 1979; Smith 1985)
15. Ce stabilesc dovezile de corectitudine? (Fetzer 1988; Fetzer 1999; Colburn 2004)
16. Ce este abstracția în informatică? Cum este legat de abstractizarea în matematică? (Colburn & Shute 2007; Fine 2008; Hale & Wright 2001)
17. Care sunt metodele formale? Ce este formal despre metodele formale? Care este diferența dintre o metodă formală și una informală? (Bowen & Hinchey 2005; Bowen & Hinchey 1995)
18. Ce fel de disciplină este informatica? Care sunt rolurile modelării și experimentării matematice? (Minsky 1970; Denning 1980; Denning 1981; Denning și colab. 1989; Denning 1985; Denning 1980b; Hartmanis 1994; Hartmanis1993; Hartmanis 1981; Colburn 2004; Eden 2007)
19. Programele ar trebui considerate ca teorii științifice? (Rapaport 2005a)
20. Cum se utilizează matematica în informatică? Sunt utilizate modele matematice într-un mod descriptiv sau normativ? (Alb 2004; Turner 2007)
21. Teza Bisericii Turing surprinde noțiunea matematică a unei metode eficiente sau mecanice în logică și matematică? Captează calculele care pot fi efectuate de un om? Domeniul său de aplicare se aplică mașinilor fizice? (Copeland 2004; Copeland 2007; Hodges 2006)
22. Noțiunea de gândire computațională poate rezista scrutinului filosofic? (Aripă 2006)
23. Care este logica adecvată cu care să argumentăm corectitudinea și încheierea programului? (Hoare 1969; Feferman 1992) Cum depinde logica de limbajul de programare de bază?
24. Ce este informația? (Floridi 2004; Floridi 2005) Această noțiune aruncă lumină asupra unora dintre întrebările enumerate aici?
25. De ce există atât de multe limbaje de programare și paradigme de programare? (Krishnamurthi 2003)
26. Limbile de programare (și paradigmele) au natura teoriilor științifice? Ce provoacă o schimbare a paradigmei de programare? (Kuhn 1970)
27. Ingineria software ridică probleme filozofice? (Eden 2007)

În ceea ce urmează, vom pune niște carne la câteva dintre aceste întrebări.

2. Existență și identitate

Cum clasificăm și individualizăm entitățile și conceptele de informatică? Ce fel de lucruri sunt și ce determină identitatea lor? De exemplu, unele sunt obiecte fizice în mod clar concrete (de exemplu, cipuri, routere, laptopuri, carduri grafice) și altele nu (de exemplu, gramatici formale, mașini abstracte, probatori de teoreme, cadre logice, algebre de proces, tipuri de date abstracte). Dar caracterizarea unora dintre noțiunile centrale, cum ar fi programe și date, a fost mai problematică. În special, starea ontologică a programelor a fost considerată a nu fi în întregime simplă și nu a pus problema criteriilor de identitate ale acestora.

2.1 Natura dublă a programelor

Mulți autori (Moor 1978; Rapaport 2005b; Colburn 2004) discută așa-numita natură duală a programelor. În fața acestuia, un program pare să aibă atât o textură, cât și un aspect mecanic sau asemănător unui proces. Ca text, un program poate fi editat. Dar manifestarea sa pe un disc care poate fi citit de mașină pare să aibă proprietăți destul de diferite. În special, poate fi executat pe o mașină fizică. Deci, conform principiului indiscernibilității identicilor (§3.3), cele două aspecte nu pot fi aceeași entitate. Desigur, oricine este convins de această dualitate are obligația de a spune ceva despre relația dintre aceste două forme aparente de existență.

O sugestie imediată este că o manifestare a unui program este o implementare a celuilalt, adică manifestarea fizică este o implementare a celei textuale. Cu toate acestea, chiar și în limitele de informatică, nu este clar imediat că implementarea cuvântului se referă la o singură noțiune. Adesea este folosit pentru a face referire la rezultatul unui proces de compilare în care un program într-un limbaj la nivel înalt (codul sursă) este transformat în limbajul mașinii (codul obiect). Dar la fel de des este folosit pentru a face referire la procesul în care codul sursă este într-un fel direct realizat în hardware (de exemplu, o implementare concretă în semiconductori). Și, probabil, aceasta este noțiunea relevantă. Dar fără o analiză filosofică mai detaliată a noțiunii de implementare (§3.2) în sine (Rapaport 2005b),nu este clar modul în care acest lucru avansează discuția; parcă am numit doar relația dintre cele două forme aparente ale existenței. Într-o linie similară, alții au descris relația dintre programul-text și procesul-program ca fiind similară cu cea dintre un plan și manifestarea acestuia ca o serie de acțiuni fizice. Dar acest lucru nu pare a fi destul de analog cu împerecherea proces-program: nu suntem tentați să ne referim la plan și la procesul fizic ca fiind manifestări diferite ale aceluiași lucru. De exemplu, suntem tentați să ne gândim la un plan de a merge la plimbare și la plimbarea propriu-zisă ca diferite fațete ale aceluiași lucru?alții au descris relația dintre programul-text și procesul-program ca fiind similară cu cea dintre un plan și manifestarea acestuia ca o serie de acțiuni fizice. Dar acest lucru nu pare a fi destul de analog cu împerecherea proces-program: nu suntem tentați să ne referim la plan și la procesul fizic ca fiind manifestări diferite ale aceluiași lucru. De exemplu, suntem tentați să ne gândim la un plan de a merge la plimbare și la plimbarea propriu-zisă ca diferite fațete ale aceluiași lucru?alții au descris relația dintre programul-text și procesul-program ca fiind similară cu cea dintre un plan și manifestarea acestuia ca o serie de acțiuni fizice. Dar acest lucru nu pare a fi destul de analog cu împerecherea proces-program: nu suntem tentați să ne referim la plan și la procesul fizic ca fiind manifestări diferite ale aceluiași lucru. De exemplu, suntem tentați să ne gândim la un plan de a merge la plimbare și la plimbarea propriu-zisă ca diferite fațete ale aceluiași lucru?suntem tentați să ne gândim la un plan de a merge la o plimbare și la mersul efectiv ca diferite fațete ale aceluiași lucru?suntem tentați să ne gândim la un plan de a merge la o plimbare și la mersul efectiv ca diferite fațete ale aceluiași lucru?

Poate că problemele sunt descrise cel mai bine spunând că programele, ca obiecte textuale, provoacă procese mecanice? Ideea pare să fie că într-un fel obiectul textual provoacă fizic procesul mecanic. Dar acest lucru pare să ceară o analiză destul de atentă a naturii unei astfel de relații cauzale. Colburn (2004) neagă faptul că textul simbolic are efectul cauzal; manifestarea sa fizică (lucrul de pe disc) are un astfel de efect. Software-ul este o abstracție concretă care are un mediu de descriere (textul, abstractizarea) și un mediu de execuție (de exemplu, o implementare concretă în semiconductori).

O perspectivă ușor diferită asupra acestor probleme pornește de la problema identității programului. Când se iau două programe la fel? Astfel de probleme apar, de exemplu, în încercările de a determina identitatea juridică a unui software. Dacă identificăm un program cu manifestarea textuală a acestuia, atunci identitatea unui program este sensibilă la modificările apariției sale (de exemplu, schimbarea fontului). Evident, nu este textul singur care ne oferă nicio noțiune filosofică interesantă de identitate a programului. Mai degrabă, pentru a atinge un criteriu de identitate informat, trebuie să luăm mai mult în considerare semantica și implementarea. Vom reveni la acest subiect în §3 și §6.

2.2 Programe și algoritmi

Oricare ar fi punctul de vedere al programelor, distincția dintre algoritm-program are, de asemenea, nevoie de clarificări conceptuale suplimentare. Algoritmele sunt adesea considerate obiecte matematice. Dacă acest lucru este adevărat, multe dintre problemele filozofice care le privesc aparțin și filosofiei matematicii. Cu toate acestea, algoritmii sunt, în mod cert, mai central pentru informatică decât pentru matematică și merită mai multă atenție filosofică decât li s-a acordat. Cu toate că s-a făcut un studiu matematic considerabil al algoritmilor în informatică teoretică și logică matematică (de exemplu, Moschovacie 1997; Blass și Gurevich 2003), nu a existat o mare discuție filosofică care este centrată pe natura algoritmilor și diferențele dintre algoritmi și programe.

Este că algoritmii sunt obiecte abstracte, în sensul oferit de Rosen (2001), în timp ce programele sunt concrete? Mai precis, algoritmii sunt contrapartida matematică abstractă a unui obiect textual care este programul? Această imagine se pretează în mod natural la o formă de platonism ontologic (Shapiro 1997) în care algoritmii au prioritate ontologică și programele furnizează mijloacele lingvistice de a ajunge la ele. În această privință, ar putea fi adoptați algoritmi pentru a furniza semantica (§3) a limbajelor de programare. Desigur, această imagine moștenește toate avantajele și problemele cu o astfel de perspectivă platonică (Shapiro 1997).

O viziune mai puțin platonică arată că algoritmii conțin ideile exprimate într-un program. În drept, acest lucru a fost considerat motivul pentru care algoritmii, spre deosebire de programe, nu sunt autorizabili (§7.1). Desigur, termenul de idee necesită o analiză filosofică suplimentară. Într-adevăr, s-ar putea susține că noțiunea goală de algoritm are mult mai puțin nevoie de clarificări decât relatarea standard a ideilor și a noțiunilor sale de abstractizare (Rosen 2001).

În cele din urmă, este aproape o perspectivă folclorică faptul că mașinile Turing ne oferă o analiză formală a noțiunii noastre de algoritm. Dar aceasta se potrivește cu noțiunea contemporană folosită în informatica modernă cu noțiunile sale sofisticate de reprezentare și control? Moschovakis (1997) oferă o analiză care merge ceva mai bine.

2.3 Programe și specificații

O altă distincție populară care ar trebui să fie subiectul unor analize critice apare în ceea ce privește programele și specificațiile. Care sunt specificațiile și cum sunt acestea diferite de programe? Deși există puține discuții directe despre această problemă în literatura filozofică (dar a se vedea Smith 1985), natura specificațiilor este o problemă fundamentală pentru fundamentele conceptuale ale informaticii.

O viziune, care se găsește în mod obișnuit în manualele despre specificațiile formale, este că programele conțin instrucțiuni detaliate ale mașinii, în timp ce specificațiile (funcționale) descriu doar relația dintre intrare și ieșire. Un mod evident de a despacheta acest lucru este în ceea ce privește distincția imperativă / descriptivă: programele sunt imperative și descriu modul de realizare a scopului descris de specificație. Cu siguranță, în paradigma de programare imperativă, aceasta pare să surprindă o diferență substanțială. Dar nu este potrivit pentru toți. De exemplu, limbajele de programare logice, funcționale și orientate pe obiect nu sunt guvernate în mod evident de acesta: luate la valoarea nominală, programele codate în astfel de limbaje constau din secvențe de definiții, nu din „instrucțiuni”. În plus,specificațiile nefuncționale nu pot fi articulate ca declarații despre relația dintre intrare și ieșire, deoarece impun cerințe asupra proiectării și a tipului de instrucțiuni care pot fi incluse în orice program.

O altă perspectivă insistă asupra faptului că diferența dintre specificații și programe trebuie să fie localizată în termenii noțiunii de implementare, adică poate fi compilată și executată? Dar ce se înțelege prin asta? Este în sensul de a avea un compilator existent? Această interpretare este mai degrabă superficială, deoarece nu oferă un criteriu conceptual de distincție, ci unul contingent. De exemplu, în primele cinci generații de limbaje de programare (a doua jumătate a secolului XX), specificațiile recursive, modulare, funcționale și orientate spre obiect ale unei generații au ajuns să fie articulate ca programe în următoarele, adică limbaje de specificații de astăzi devin frecvent limbaje de programare de mâine.

O altă perspectivă sugerează că limbajele de programare sunt acele limbi care au o implementare în principiu, în timp ce limbajele de specificare sunt cele care nu pot. Și, probabil, motivul pentru care nu se poate este faptul că limbajele de specificație permit unuia să exprime noțiuni care nu sunt computabile. Această distincție respectă multe limbaje de specificații existente care se bazează pe teoria seturilor Zermelo-Fraenkel și logica de ordin superior. Cu toate acestea, pare ciudat că ceea ce ar trebui să caracterizeze un limbaj de specificații este faptul că poate exprima relații și proprietăți care nu pot fi calculate. Există într-adevăr unele dintre aceste cerințe care nu sunt calculabile în practică (Jones și Hayes 1990; Fuchs 1994)?

Diversitatea acestor opinii sugerează că diviziunea binară tradițională între specificații și programe este un exemplu de problemă în PCS care merită mai multă atenție, nu numai pentru clarificări conceptuale, ci și pentru că ar putea avea implicații asupra proiectării viitoarelor limbaje de programare și specificații..

3. Semantica

Gramatica unui limbaj de programare determină doar ceea ce este legitim sintactic; nu ne informează despre sensul intenționat al construcțiilor sale. Astfel, gramatica unui limbaj de programare nu determină, de la sine, lucrul în care oamenii programează. În schimb, gramatica este îmbogățită cu un cont semantic (formal sau informal) care este luat pentru a face acest lucru. Semantica este menită să informeze programatorul, scriitorul compilator și teoreticianul interesat să exploreze proprietățile limbii. Într-adevăr, se afirmă adesea că pentru a îndeplini diferitele cerințe ale programatorului și scriitorului compilator, sunt necesare conturi semantice diferite, la diferite niveluri de abstractizare. Iar meseria teoreticianului este să exploreze relația lor.

Aceasta este imaginea standard care apare în literatura semantică. Dar o mare parte din aceasta are nevoie de clarificări conceptuale. În această secțiune avem în vedere câteva dintre problemele care apar din această activitate.

3.1 Semantica denotațională și operațională

Una dintre cele mai importante distincții în semantica limbajelor de programare se face după distincția dintre semantica operațională și cea denotațională. O semantică operațională (Landin 1964; Plotkin 1981) oferă o interpretare a unui limbaj de programare în termeni de o mașină abstractă. Mai precis, este o traducere a expresiilor din limbajul de programare în instrucțiunile sau programele mașinii abstracte. De exemplu, Programul 1 va fi împachetat într-o secvență de operații abstracte ale mașinilor, cum ar fi „un ← 0” și apăsare. Semantica operațională poate fi, de asemenea, concepută ca o semantică algoritmică, în special atunci când mașina de bază are ca scop caracterizarea însăși a noțiunii de algoritm (de exemplu, Moschovakis, 1997).

În schimb, o semantică denotațională (Milne și Strachey 1977) oferă o interpretare în structuri matematice precum seturi sau categorii. De exemplu, în abordarea clasică, seturile - sub formă de grilaje complete și funcții continue pe acestea - oferă cadrul matematic.

Există însă vreo diferență conceptuală semnificativă între ele? Este faptul că semantica denotațională, bazată explicit pe structuri matematice precum seturi, este matematică, în timp ce semantica operațională nu? Turner (2007) nu susține că: toate oferă interpretări matematice.

Sau este că semantica operațională este mai asemănătoare cu mașina, în sensul de a constitui o mașină abstractă, în timp ce cu semantica denotațională, care este dată în termeni teoretici, nu există niciun indiciu al unei mașini abstracte? Totuși, astfel de distincții nu s-au dovedit semnificative conceptual, deoarece conturile semantice denotative pot fi văzute ca structuri care constituie o mașină abstractă cu stări și operații care operează pe ele. Nici conturile operaționale nu sunt mai apropiate de punerea în aplicare: abordările denotaționale (Milne și Strachey 1977) sunt, de asemenea, foarte flexibile și sunt capabile să reflecte diverse niveluri de detaliere a implementării.

O altă posibilă distincție se referă la natura compozițională (sau altfel) a semanticii. În mod slab, se consideră că o semantică este compozițională (Szabó 2007) dacă valoarea semantică a unei expresii complexe este o funcție a valorilor semantice ale părților sale. Compoziționalitatea este considerată un criteriu crucial al semanticii, deoarece se pare că este necesar să explice productivitatea înțelegerii noastre lingvistice: se spune că explicăm modul în care înțelegem și construim programe complexe. Dar ne oferă o pană de separare a semanticii operaționale și denotative? Din păcate, se pare că nu face acest lucru: deși definițiile denotaționale sunt concepute pentru a fi compoziționale, cu siguranță nu este cazul că toate semanticele operaționale nu sunt compoziționale.

În sfârșit, unele versiuni de semantică diferă în ceea ce privește existența unui model recursiv, adică o interpretare în mașinile Turing sau în mașinile Gandy (§5.1). Cu toate acestea, chiar și acest lucru nu se aliniază exact cu decalajul operațional / denotativ tradițional. Unele definiții denotative au un model recursiv, iar altele nu.

Pare foarte greu să distingi această distincție. În această privință, nu apare nicio distincție conceptuală acută între semantica operațională și cea denotativă.

3.2 Implementarea și interpretarea semantică

Care este diferența dintre o interpretare semantică și o implementare? De exemplu, care este diferența conceptuală între compilarea unui program în codul mașinii și oferirea acestuia de o semantică denotațională? Conform Rapaport (2005b), o implementare este cel mai bine privită ca o interpretare semantică, unde aceasta din urmă este caracterizată printr-o mapare între două domenii: unul sintactic și unul semantic. Și ambele sunt determinate de reguli ale unei anumite descrieri. De exemplu, codul compilat (în combinație cu regulile care îi guvernează semantica) este contul semantic al codului sursă.

Într-o înțelegere comună a termenului „implementare”, domeniul semantic este furnizat de o mașină fizică. Cu alte cuvinte, mașina fizică însăși („implementarea”) determină ce înseamnă programul. De exemplu, în limbajele de programare, acest lucru este echivalent cu afirmația că semantica pentru limbajul de programare C ++ este determinată de computerul Bjarne care rulează compilatorul său C ++. Dar această explicație este în mod evident inadecvată: dacă presupunem că mașina lui Bjarne determină sensul programelor C ++, atunci nu există nicio noțiune de defecțiune sau interpretare greșită: orice face computerul Bjarne este, ipso facto, sensul programului. Dar, cu siguranță, o furtună electrică poate determina mașina să meargă greșit. Dar ce am putea însemna greșind? Se presupune că mașina (funcționarea defectuoasă) nu întruchipează sensul dorit. Dar,la rândul nostru, par să putem înțelege doar această frază pe baza unor caracterizări independente de mașină a sensului. Și la un anumit nivel, acest lucru trebuie dat printr-o descriere semantică independentă. Acest lucru sugerează că noțiunea de implementare goală nu oferă o noțiune adecvată de semantică. (Comparați cu: Kripke 1982; Wittgenstein 1953).

3.3 Semantica, egalitatea și identitatea

Am încheiat discuția noastră despre egalitatea programelor (§2.1) cu o promisiune de a aduce semantică în imagine. Fiecare cont semantic al unui limbaj de programare determină o noțiune de egalitate pentru programe și anume, două programe sunt considerate egale dacă au aceeași valoare semantică, adică,

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

unde || P || este valoarea semantică a programului P. Deci, în acest sens, fiecare relatare semantică determină un criteriu de egalitate. De exemplu, o versiune a semanticii denotaționale ar elimina toate etapele de computație și echivalează programele care într-un anumit sens calculează aceeași funcție matematică. De exemplu, următoarele două programe ar fi considerate egale după acest criteriu:

funcție Factorial (n: număr întreg): întregul începe dacă n = 0 atunci Factorial: = 1; altul Factorial: = (n) * Factorial (n -1); Sfârșit;

Programul 1

funcție Factorial (n: număr întreg): integer var x, y: întreg; începe y: = 1; x: = 0; în timp ce x <n încep x: = x +1; y: = y * x; Sfârșit Factorial: = y; Sfârșit;

Programul 2

Pe de altă parte, o viziune mai operațională, care face trimitere la etapele calculului, nu ar trebui să fie egale Programul 1 și Programul 2. Într-adevăr, având în vedere §3.1 putem elabora conturi semantice care să reflecte orice nivel de detaliu al implementării. Conturile semantice diferite determină noțiuni de egalitate diferite care pot servi scopurilor conceptuale și practice diferite. Dar atunci care ar trebui să fie luat pentru a determina limba? Din fericire, există câteva deziderate care pot fi aplicate; putem reduce opțiunile: unele conturi semantice ne oferă o noțiune logică de identitate satisfăcătoare, iar altele nu.

Indiscernibility de identicals este un principiu construit în logica predicatelor ordinare. Acesta afirmă că dacă două obiecte sunt egale, atunci acestea împărtășesc toate proprietățile. Principiul invers, identitatea incontestabilăafirmă că dacă, pentru fiecare proprietate F, obiectul x are F dacă și numai dacă obiectul y are F, atunci x este identic cu y. Identitatea indiscernibilelor implică faptul că dacă x și y sunt distincte, atunci există cel puțin o proprietate pe care x are și y nu. Uneori, conjuncția ambelor principii este cunoscută sub numele de Legea lui Leibniz (Forrest 2006). Legea lui Leibniz este adesea considerată esențială pentru orice noțiune de egalitate. Aceste legi sunt de obicei formulate în teorii logice precum logica de ordinul doi. Dar ne va interesa cel mai mult capacitatea lor de a discrimina între diferite tipuri de semantică a limbajului de programare. Într-adevăr, legea lui Leibniz este una dintre noțiunile centrale ale teoriei semantice moderne. Criteriul identității este concretizat în termeni de echivalență observațională.

Două programe M și N sunt definite a fi echivalente observaționaldacă și numai dacă, în toate contextele C […] în care C [M] este un program valid, se întâmplă ca C [N] să fie și un program valid cu aceeași valoare semantică. De exemplu, spunem că Oracle și DB2 (programe care manipulează baze de date relaționale) sunt echivalent observațional în funcție de un cont semantic al operațiunilor pe baze de date relaționale dacă și numai dacă le execută în același context (sistem de operare, arhitectură mașină, intrare etc.) cedează baza de date „aceeași”. Desigur, termenul echivalent observațional trebuie luat cu un vârf de sare. În mod clar, nu putem observa comportamentul unui program în toate contextele. Cu toate acestea, echivalența observațională reflectă o cerere conceptuală de bază care emană de la principiile indiscernibilității identicilor și din identitatea indiscernelilor.

În semantică, dacă toate programele vizibil distincte au valori semantice distincte, se spune că semantica este sonoră. În consecință, o semantică solidă îndeplinește următorul principiu:

|| P || = || Q || implică faptul că pentru toate contextele C, || C [P] || = || C [Q] ||

Ar trebui să fie clar că noțiunea de identitate indusă de o semantică sonoră satisface indiscernibilitatea identicilor.

Se spune că o semantică este completă dacă există două programe cu valori semantice distincte. Mai precis, o semantică completă satisface următoarele:

Pentru toate contextele C, || C [P] || = || C [Q] || implică || P || = || Q ||

Din nou, ar trebui să fie evident că o semantică completă satisface principiul identității indiscernibile.

În cele din urmă, se spune că semantica este pe deplin abstractă dacă este sănătoasă și completă. În consecință, o semantică complet abstractă satisface Legea lui Leibniz.

Acest fundal logic oferă justificarea filosofică pentru dezvoltarea unei semantice complet abstracte. Astfel, ne oferă o modalitate de selectare a conturilor semantice care oferă noțiuni filosofice acceptabile de egalitate. Desigur, nu determină nicio noțiune. Acesta oferă doar un instrument pentru respingerea celor care nu pot furniza unul acceptabil conceptual. Multe așa-numite semantice denotative nu sunt pe deplin abstracte, în timp ce multe sunt operaționale. Într-adevăr, unul dintre subiectele centrale din istoria recentă a semanticii a implicat căutarea unor definiții complet abstracte, care sunt incluse în clasa tehnicilor de definire semantică care sunt luate pentru a da o semantică denotativă.

Semantica joacă un rol normativ sau definitoriu în informatică. Fără definiții semantice, limbile și structurile nu au conținut peste și furnizat de descrierile lor sintactice. Iar acestea din urmă sunt cu greu suficiente pentru scopuri practice sau filozofice. În timp ce am început o analiză a preocupărilor centrale, am zgâriat doar suprafața.

4. Probe și programe

Specificațiile (§2.3) induc o noțiune particulară de corectitudine. Conform interpretării abstracte a acestei noțiuni, un program este considerat corect în raport cu o specificație (funcțională) dacă relația pe care o realizează între intrare și ieșire satisface cea prevăzută de caietul de sarcini. Mai exact, dacă p este un program, atunci acesta îndeplinește o specificație R, care este considerată a fi o relație peste tipul de intrare I și tipul de ieșire O, dacă urmează:

Pentru toate intrările, i de tip I, perechea (i, p (i)), satisface relația R

unde p (i) este rezultatul rulării programului p pe intrarea i. Aici R este exprimat într-un limbaj de specificație și p într-un limbaj de programare. Prima este, de obicei, o variantă a logicii predicate (tipate) și dovezi de corectitudine (adică acea afirmație (1) deține) sunt efectuate în sistemul de dovezi al logicii. De exemplu, logica Hoare (Hoare 1969) este frecvent utilizată, în care Dovada corectitudinii ia forma inferențelor între tripluri, scrise

B {P} A

unde P este un program și B și A sunt afirmații (stările „înainte” și „după” ale programului) exprimate într-o versiune a logicii predicatului cu caracteristici care facilitează exprimarea valorilor atașate variabilelor programului.

O controversă filosofică care înconjoară problema corectitudinii se bazează pe natura acestor dovezi; celelalte contestă ceea ce oferă astfel de dovezi.

4.1 Dovezi în informatică

Dovezile privind corectitudinea programului sunt adevărate dovezi matematice, adică sunt asemenea dovezi la fel cu cele matematice standard? DeMillo și colab. (1979) susțin că, deoarece dovezile de corectitudine sunt lungi și puțin adânci din punct de vedere matematic, acestea sunt spre deosebire de dovezile din matematică care sunt conceptual interesante, convingătoare și atrag atenția altor matematicieni care doresc să le studieze și să se bazeze pe ele. De exemplu, o dovadă în logica lui Hoare în sensul că Programul 2 calculează funcția factorială ar conține detalii despre noțiunea de stat care stă la baza, să folosească un argument inductiv și ar implica raționamente despre invarianța buclelor.

Dar astfel de dovezi ar fi mult mai lungi decât programul în sine. În plus, nivelul la care raționamentul este codat în logica lui Hoare ar necesita exprimarea și reprezentarea multor detalii care, în mod normal, ar fi lăsate implicite. Ar fi un lucru obositor și, în cazul majorității programelor, conceptual trivial.

Acest argument, este în paralel cu argumentele de înțelegere făcute în filosofia matematicii (de exemplu, Tymoczko 1979; Burge 1988). La baza ei se află îngrijorari epistemologice: dovezi prea lungi, greoaie și neinteresante nu pot fi purtătoare ale tipului de certitudine care este atribuit dovezilor matematice standard. Natura cunoștințelor obținute din dovezile de corectitudine se pretinde a fi diferită de cunoștințele care pot fi obținute din dovezi în matematică ^[1].

Trebuie, de asemenea, să distingem această perspectivă esențială sociologică asupra dovezilor de cea care susține că dovezile sunt corecte sau greșite într-un mod care este independent de astfel de judecăți epistemologice. Este posibil să se mențină la o poziție mai realistă conform căreia orice dovadă este corectă sau incorectă, fără a renunța la cererea de care trebuie să se înțeleagă dovezile, pentru a fi luate și validate.

S-ar putea încerca să câștige un motiv susținând că probele de corectitudine ar trebui verificate de un computer și nu de un om. Dar, desigur, verificatorul de dovezi are în sine nevoie de verificare. Arkoudas și Bringsjord (2007) susțin că, dacă există o singură dovadă de corectitudine care trebuie verificată, și anume cea a verificatorului de probă în sine, atunci posibilitatea greșelilor este semnificativ redusă.

4.2 Dovezi în matematică

Dovezi matematice, cum ar fi dovada teoremei incompletitudinii lui Gödel sunt, de asemenea, lungi și complicate. Dar ceea ce le face transparente, interesante și înțelegătoare („analizate”) de către comunitatea matematică este utilizarea tehnicilor de modularitate (de exemplu, lemne) și utilizarea abstracției în actul creației matematice. Introducerea de noi concepte permite o dovadă de a fi construită treptat, făcând astfel dovada mai inteligibilă. Matematica progresează inventând noi concepte matematice care permit construirea unor dovezi de nivel superior și mai generale, care ar fi mult mai complexe și chiar imposibile fără ele. De exemplu, notația exponenților face posibilă efectuarea calculului dincolo de complexitatea înmulțirii - și să se argumenteze despre rezultate. La cealaltă extremă,invenția teoriei categoriilor a facilitat enunțarea și dovedirea rezultatelor foarte generale despre structuri algebice care se aplică automat la o serie întreagă de astfel de. Matematica nu înseamnă doar o dovadă; ea implică, de asemenea, abstractizarea și crearea de noi concepte și notație. În această privință, dovezile formale de corectitudine nu utilizează, în general, crearea de noi concepte și nici nu se implică în procesul de abstractizare matematică. În schimb, abstracția în informatică (§6.1) este concentrată în noțiunile necesare pentru proiectarea programului. Dar cum se leagă aceste două noțiuni de abstractizare? Vom spune mai multe despre acest lucru mai târziu.ea implică, de asemenea, abstractizarea și crearea de noi concepte și notație. În această privință, dovezile formale de corectitudine nu utilizează, în general, crearea de noi concepte și nici nu se implică în procesul de abstractizare matematică. În schimb, abstracția în informatică (§6.1) este concentrată în noțiunile necesare pentru proiectarea programului. Dar cum se leagă aceste două noțiuni de abstractizare? Vom spune mai multe despre acest lucru mai târziu.ea implică, de asemenea, abstractizarea și crearea de noi concepte și notație. În această privință, dovezile formale de corectitudine nu utilizează, în general, crearea de noi concepte și nici nu se implică în procesul de abstractizare matematică. În schimb, abstracția în informatică (§6.1) este concentrată în noțiunile necesare pentru proiectarea programului. Dar cum se leagă aceste două noțiuni de abstractizare? Vom spune mai multe despre acest lucru mai târziu.

4.3 Corectitudinea fizică și abstractă

Chiar dacă lăsăm deoparte aceste griji epistemologice, o a doua și aparent mai devastatoare critică a corectitudinii dovedește ceea ce este stabilit de fapt de către ei. Aparent, o dovadă a corectitudinii oferă corectitudine numai până la reprezentarea textuală a programului. Nicio cantitate de muncă formală nu ne poate trece dincolo de bariera abstractă / fizică: nu putem garanta niciodată că vreo execuție specială a programului pe o mașină fizică va avea loc efectiv așa cum era de așteptat (Fetzer 1988; Fetzer 1999; Colburn 2004).

Dar ce înseamnă pentru programul p să fie corect? Presupunem că avem o specificație a programului și că acesta poate fi formal sau informal. Apoi, să presupunem că efectuăm o serie de teste pentru a verifica dacă programul respectă specificațiile sale. Dacă reușesc, avem dovezi empirice că omologul fizic al programului textual este într-adevăr corect, deoarece funcționează în conformitate cu specificația. În această privință, omologul fizic care a fost testat; nu programul textual.

Această analiză sugerează că există o dualitate în noțiunea de corectitudine a programelor. În concordanță cu natura duală a programelor, am putea spune că programul textual este supus corectitudinii matematice, în timp ce omologul său fizic este supus verificării empirice.

5. Calculabilitate

Calculabilitatea este unul dintre cele mai vechi subiecte care pot fi etichetate ca PCS. Cu toate acestea, este subiectul mai multor înregistrări SEP (de exemplu, Barker-Plummer 2004) și, prin urmare, vom menționa doar câteva subiecte și conexiunile lor cu restul prezentului articol.

5.1 Teza Bisericii

Una dintre problemele centrale este Teza Bisericii-Turing. Și aici există două dispute, una istorică și una empirică. Ele se bazează pe următoarele două interpretări posibile ale tezei:

1. Mașinile de întărire pot face orice poate fi descris ca „regulă generală” sau „pur mecanic”.
2. Orice poate fi calculat de către o mașină (care lucrează la date finite, în conformitate cu un program finit de instrucțiuni) este Turing computerizabil.

Interpretarea I este destinată să surprindă noțiunea unei metode eficiente sau mecanice în logică și matematică. Este menit să reflecte noțiunea informală de algoritm implicit în matematică și adusă în prim plan de programul Hilbert. Interpretarea II este menită să guverneze mașinile fizice. Într-adevăr, (Gandy 1980) poate fi văzută ca o dezambalare suplimentară a II. Gandy propune patru principii care sunt destinate să caracterizeze calculul de către o mașină fizică. El arată că astfel de mașini sunt exact în acord cu caracterizarea lui Turing (Teorema lui Gandy). În legătură cu discuția noastră despre diferite paradigme semantice, este clar că multe dintre mașinile care stau la baza semanticii denotaționale (§3.1) nu se califică ca mașini Gandy. Cel mai adesea funcționează cu spații funcționale de ordin superior,și acestea nu pot fi considerate date finite și nu satisfac condițiile lui Gandy.

Unii susțin (Copeland 2004; Copeland 2008) că teza propusă de Church și Turing privește doar interpretarea I și nu stabilește o limită pentru mașini în general. Hodges (2007) nu este de acord. El susține că Biserica și Turingul nu au făcut distincția între cele două interpretări. Aceasta este disputa istorică.

Disputa fizică privește capacitățile mașinilor actuale (interpretarea II.) Mulți consideră că teza Bisericii Turing caracterizează și prescrie calculul fizic real. De exemplu, aceasta pare a fi presupunerea implicită în informatică mainstream. Cu siguranță este cazul că fiecare program scris într-un limbaj de programare deja implementat este Turing calculabil și invers, că toate limbajele de programare cu scop general sunt Turing complete, adică conțin toate construcțiile de control necesare pentru a simula o mașină Turing universală.

Copeland (2007) susține că caracterizarea lui Gandy a unui dispozitiv mecanic determinant discret este prea restrânsă și, în consecință, există exemple de posibile mașini fizice ale căror capabilități depășesc clasa funcțiilor computere Turing. Multe dintre acestea necesită o viteză infinită, prin care un număr infinit de calcule pot fi efectuate fizic într-un timp finit. Calculul cuantic a fost citat ca un posibil exemplu pentru astfel de mașini, dar acest lucru a fost contestat (Hodges 2007; Hagar 2007).

De asemenea, Hodges este preocupat de aplicabilitatea argumentării matematice standard în fizică la acele cazuri în care este implicată o precizie infinită. Acest lucru sugerează că această dispută nu este una simplă empirică. Într-adevăr, există cei care se întreabă dacă este posibil fizic să finalizeze un număr infinit de sarcini într-un timp finit. Dummett (2006) se întreabă dacă noțiunea de sarcină infinită care trebuie îndeplinită pe tărâmul fizic nu este doar o imposibilitate fizică, ci și una conceptuală. Deci disputa nu este doar una empirică, ci merge în centrul înțelegerii noastre a relației dintre modelele noastre matematice și realitatea fizică.

6. Limbi de programare și programare

Proiectarea programelor și a limbajelor de programare este una dintre activitățile tradiționale ale informaticii. O serie de întrebări conceptuale le înconjoară (§1), multe dintre ele nu au primit nicio atenție filosofică. Aici vom analiza pe scurt două dintre aceste probleme.

6.1 Abstracție

Abstracția este unul dintre pietrele fundamentale conceptuale ale informaticii. Este o parte integrantă a proiectării și construcției programelor și constituie o metodologie de bază pentru proiectarea limbajelor de programare. Într-adevăr, conduce la crearea de noi paradigme de programare. Acesta este la baza invenției noțiuni precum abstracție procedurală și funcțională, polimorfism, abstractizare de date, obiecte și clase, modele de proiectare, stiluri arhitecturale, subtip și moștenire. Multe ramuri ale ingineriei software (de exemplu, modelarea software, înțelegerea programelor, vizualizarea programelor, inversarea și reinginerie) sunt preocupate în principal de investigarea mecanismelor adecvate pentru abstractizarea programelor. Și o mare parte din progresele ingineriei software au fost obținute datorită introducerii de noi mecanisme de abstractizare.

Dar care este natura abstractizării în informatică? Care este explicația filozofică care stă la baza ei? Din păcate, în general, însăși ideea de abstractizare este problematică din punct de vedere filosofic. Conform concepției tradiționale, care își are originile în psihologia filozofică, abstractizarea este un proces mental în care se formează concepții noi prin luarea în considerare a mai multor obiecte sau idei și omiterea trăsăturilor care le deosebesc. (Rosen 2001). Dar această abordare are câțiva susținători filosofici contemporani, dacă este cazul,.

O abordare mai logică a analizei abstractizării, care are o susținere puternică (Wright 1983; Hale 1987). Dar nu este clar dacă aceste idei, care au fost dezvoltate pentru abstractizarea matematică, sunt aplicabile informaticii. În mod clar, unele dintre noțiunile de abstractizare în informatică au fost fie inspirate sau cercetate prin abstractizări în matematică. Dar care este relația conceptuală între abstractizare în aceste discipline? Sunt fundamental diferite? Din păcate, deși există o literatură substanțială pe bazele filozofice ale abstracției matematice (vezi Wright 1983; Hale 1987; Fine 2002), investigația conceptuală a abstracției în informatică este încă de la început. Colburn (2007) sugerează că distincția dintre abstracție în matematică și abstracție în informatică constă în faptul că, în matematică, abstracția este o neglijare a informației, în timp ce, în informatică, se ascunde informația. Adică abstracțiile din matematică ignoră ceea ce se consideră irelevant (de exemplu, culoarea triunghiurilor similare). În schimb, în informatică, toate detaliile care sunt ignorate la un nivel de abstractizare (de exemplu, programatorii Java nu trebuie să-și facă griji cu privire la locația precisă în memoria asociată cu o anumită variabilă) nu trebuie ignorate de unul dintre nivelurile inferioare (de exemplu, virtualul aparatul gestionează toate alocările de memorie).abstracțiile în matematică ignoră ceea ce se consideră irelevant (de exemplu, culoarea triunghiurilor similare). În schimb, în informatică, toate detaliile care sunt ignorate la un nivel de abstractizare (de exemplu, programatorii Java nu trebuie să-și facă griji cu privire la locația precisă în memoria asociată cu o anumită variabilă) nu trebuie ignorate de unul dintre nivelurile inferioare (de exemplu, virtualul aparatul gestionează toate alocările de memorie).abstracțiile în matematică ignoră ceea ce se consideră irelevant (de exemplu, culoarea triunghiurilor similare). În schimb, în informatică, toate detaliile care sunt ignorate la un nivel de abstractizare (de exemplu, programatorii Java nu trebuie să-și facă griji cu privire la locația precisă în memoria asociată cu o anumită variabilă) nu trebuie ignorate de unul dintre nivelurile inferioare (de exemplu, virtualul aparatul gestionează toate alocările de memorie).

Dar este aceasta bazată pe o noțiune de abstractizare prea simplistă în matematică? Există doar un fel de noțiune? De exemplu, informațiile care se ascund în analiza lui Bishop (Bishop 1970) sunt cu totul diferite de noțiunea de abstractizare a lui Wright - într-adevăr, este destul de similară cu cea de informatică.

6.2 Tipuri și ontologie

Limbile de programare sunt în mare parte limbi tipizate, unde noțiunea modernă de tip își are originile în Frege și Russell și în special în teoria simplă a tipurilor de Russell (Irvine 2003). Desigur, Russell a fost motivat de paradoxurile logice și semantice, iar această caracteristică nu este centrală pentru aplicarea tipurilor la informatică. Pe de altă parte, pentru tipurile Russell sculptăm universul discursului în moduri care au atât importanță gramaticală cât și semantică. Și această idee a trecut la informatică. Într-adevăr, teoriile tipului au fost inspirate și îmbogățite de informatică. De exemplu, teoria tipurilor lui Russell, deși puternică din punct de vedere matematic, este oarecum sărăcită în puterea sa expresivă în comparație cu teoriile tipurilor limbajelor moderne de calculator (Coquand 2006; Pierce 2002). În afară de o serie de tipuri de bază, cum ar fi numerele și Booleanele, limbajele de programare conțin o colecție de constructori de tip (modalități de construire a tipurilor noi din cele vechi). De exemplu, acestea includ capacitatea de a forma un fel de produs cartezian și seturi finite. În multe limbaje de programare orientate pe obiecte, tipurile (clasele) pot importa (și înlocui) operațiuni de la alte tipuri și oferă constructori mai sofisticați care susțin formarea de tipuri de date abstracte și diverse forme de polimorfism.tipurile (clasele) pot importa (și înlocui) operațiuni de la alte tipuri și oferă constructori mai sofisticați care susțin formarea de tipuri de date abstracte și diverse forme de polimorfism.tipurile (clasele) pot importa (și înlocui) operațiuni de la alte tipuri și oferă constructori mai sofisticați care susțin formarea de tipuri de date abstracte și diverse forme de polimorfism.

În informatică, tipurile joacă un rol care este la jumătatea distanței dintre sintaxă și semantică. În primul rând, ele extind noțiunea noastră normală de gramatică fără context. Unele caracteristici ale limbii, în special cele care permit fixarea tipului unei variabile în funcție de context (adică declarații ale limbii) necesită o formă de gramatică mai flexibilă decât cea standard. Așa numitele gramatici la două niveluri, deși adecvate din punct de vedere tehnic, nu surprind modul în care variabilele sunt alocate tipurilor lor în limbile moderne. Și sunt foarte stângace de folosit. De asemenea, nu se adaptează cu ușurință la sistemele de tip polimorf din multe limbi. Sistemele de tip modern merg mai bine: variabilelor li se atribuie tipurile prin intermediul declarațiilor, de exemplu, x: Boolean. Ulterior, un compilator poate verifica tipul programului, de ex.se poate asigura că apariția unei variabile în enunțurile ulterioare (de exemplu, x

Dar tipurile joacă, de asemenea, un rol de corectitudine care, în mod normal, nu ar fi descris în termeni sintactici. Face acest lucru prin extinderea noțiunii tradiționale fizice de analiză dimensională la un sistem de tipuri mult mai bogat. Obținerea unei structuri potrivite de tip pentru un program oferă o modalitate de a asigura corectitudinea acestuia. Și acest lucru este determinat de structura pe care tipurile o impun unei limbi. Tipurile fixează tipurile de lucruri existente într-un limbaj de programare. Deci, de exemplu, orice limbaj de programare care admite numere, produse și clase și nimic altceva, impune un cadru conceptual programatorului pe care trebuie să-l funcționeze. Problemele trebuie articulate și soluțiile găsite în mijloacele de reprezentare furnizate de sistemul tip. Odată ce structura tipului unui limbaj de programare a fost stabilită, o mare parte din setarea sa ontologică a fost fixată.

Sau are? Poate că trebuie să facem un pas înapoi și să ne întrebăm mai întâi cum trebuie determinate angajamentele ontologice ale unei limbi. Semantica este cea care determină problemele (Turner & Eden 2007)? O lungă tradiție care emană de la Frege ar sugera așa (Dummett 1991). Presupunând că analogia cu limbajele naturale este legitimă, ontologia unei limbi este determinată de structurile necesare pentru furnizarea domeniilor sale semantice. Dar ce teorie semantică ar trebui să adoptăm? Deși orice semantică trebuie să țină cont de tipuri, ontologia determinată semantic ar depăși ele și ar reflecta domeniile semantice implicate, iar acestea ar reflecta detaliile de implementare care sunt incluse în semantică. În această privință, ca și în cazul egalității, interpretări semantice diferite determină ontologii diferite. Rezultă că nu este sensibil să vorbim despre ontologia unui limbaj de programare, ci despre ontologii multiple care depind de nivelul de abstractizare implicat în semantică. De exemplu, ontologia poate fi, de asemenea, parțial determinată de paradigma de programare.

7. Întrebări legale și etice

Unele probleme legate de etica computerului aparțin PCS prin faptul că activitatea de a construi și utiliza software ridică întrebări de ordin etic. Cu toate acestea, multe nu sunt specifice informaticii în sensul restrâns al acestei intrări; ele afectează ansamblul tehnologiilor informaționale și aplicațiilor informatice (Bynum 2001). În consecință, vom menționa doar două care par centrale în informatică.

7.1 Drepturi de autor, brevete și identitate

Drepturile de autor oferă o oarecare protecție pentru software, dar nu sunt în măsură să-și protejeze nucleul semantic. Și considerăm că acesta din urmă trebuie să fie determinat de un cont semantic (§3) al limbajului de programare în care este scris programul. Probabil, esența acestei probleme se referă la problema identității programului (§3.3). Dar dacă există multe noțiuni semantice posibile de identitate, care este potrivită pentru aplicarea legală?

Un raport semantic informal care este adesea citat în lege identifică programul cu ideile exprimate în el, cel mai adesea fiind considerat algoritmul său de bază. Dar nu numai că este adesea greu de spus exact ce este acest algoritm, dar, la fel ca și în cazul teoremelor matematice, algoritmii nu pot fi protejați de drepturi de autor. Și cam aceeași soartă așteaptă orice relatare semantică formală, deoarece orice astfel de lucru ar fi determinat de o anumită noțiune matematică, fie că este vorba de algoritmi sau de o anumită noțiune de operare sau funcție matematică.

Dar chiar dacă am putea localiza un cont semantic care să răspundă legilor drepturilor de autor, imaginea juridică nu ar fi completă. Încălcarea drepturilor de autor se bazează adesea nu doar pe un anumit cont de identitate, ci și dacă este posibil să presupunem că cineva ar veni cu același program. Deci, că considerente intenționate intră în cadru. Cu alte cuvinte, chiar și în cazul în care două programe sunt considerate echivalente în funcție de criteriul nostru semantic, dacă s-ar putea vedea că este plauzibil că acestea au fost construite independent, nu ar exista nicio încălcare a dreptului de autor.

Brevetele (în special brevetele de utilitate) nu sunt mai bune. Acestea sunt și mai greu de obținut pentru software, deoarece nu se pot breveta procese mentale, idei abstracte și algoritmi. Și mai degrabă este vorba de algoritmi decât de codul sursă care conține deseori ideile noi. Dar încă o dată, problemele de identificare și identitate sunt preocuparea filosofică centrală. Și acestea implică atât considerații semantice, cât și intenționale.

7.2 Corectitudinea și responsabilitatea

Este corect ca software-ul să fie vândut cu puțină garanție de fitness pentru scop? (Coleman 2008) este dedicat acestei întrebări. Aceasta este o întrebare deosebit de pertinentă pentru sistemele critice pentru siguranță, de exemplu, sistemele care monitorizează condițiile medicale, operează centrale nucleare și comunică cu navele spațiale. Aici aplicarea unor teste mai riguroase și dovezi de corectitudine ar părea esențiale. Dar, în termeni etici, este cazul unui programator care nu reușește să-și analizeze și să-și testeze programul în mod diferit de cel al unui inginer civil care nu reușește să modeleze și să facă teste matematice necesare pentru o construcție a clădirii? Obligațiile morale par similare.

Un fel în care acestea ar putea fi diferite se referă la complexitatea software-ului (Brooks 1987), care depășește complexitatea oricărui alt tip de artefact uman prin ordinele de mărime. Mulți ar pretinde că nu este posibilă oferirea unei astfel de garanții de corectitudine (DeMillo și colab., 1979); software-ul este atât de complex, încât procesul de probă matematică riguroasă și testare software este infaosibil. Și, probabil, nu putem avea decât o obligație (morală sau legală) de a duce la îndeplinire un proces fezabil.

Dar cum se echilibrează aspectele doveditoare și de testare a dezvoltării de software cu utilizarea prevăzută a software-ului? Software-ul dezvoltat pentru divertisment ar trebui să fie supus aceluiași grad de dovadă și testare riguroasă ca și software-ul care este critic pentru siguranță? Probabil că nu, dar am putea fi încă tentați să ne întrebăm, sunt aceste noi probleme de etică sau ne oferă doar alte studii de caz asupra dilemelor etice existente? De exemplu, chiar și problemele de securitate din software-urile utilizate în industria divertismentului pot aduce penalități financiare.

8. Noutăți noi sau probleme noi?

Chiar și această privire de ansamblu destul de sumară asupra PC-urilorar trebui să convingă cititorul că informatica ridică probleme filozofice interesante și solicitante. Într-adevăr, una dintre impresiile imperative este că are legături substanțiale cu majoritatea ramurilor tradiționale ale filozofiei. Există conexiuni clare cu ontologia, etica, epistemologia și filozofiile matematicii, fizicii și limbajului. Într-adevăr, lista noastră inițială de întrebări ridică multe alte teme care se conectează cu alte domenii ale filozofiei. În special, există o literatură substanțială despre aplicațiile informaticii. Inteligența artificială și știința cognitivă dau întrebări filozofice care aparțin filozofiei minții (McLaughlin 2004). Desigur, o mare parte din acestea rezultă din Turing (1950). Alte aplicații ale informaticii în domenii tradiționale ale științei, așa-numitele științe computationale,creați probleme pentru filozofia științei: care este impactul epistemologic al simulărilor computerizate, în special acolo unde acestea sunt singura formă viabilă de experimentare? Virajul computațional în ontologie aduce noi tehnici care să suporte structura oricărui tip de ontologie conceptuală. Filosofia logicii este îmbogățită de o masă de materiale: au apărut un număr mare de noi sisteme logice în scopul reprezentării și raționării despre sistemele de calcul.un număr mare de noi sisteme logice au apărut în scopul reprezentării și raționării sistemelor de calcul.un număr mare de noi sisteme logice au apărut în scopul reprezentării și raționării sistemelor de calcul.

Cu toate că este clar că informatica ridică multe rasturnări semnificative la preocupările filozofice tradiționale, ceea ce este mai puțin clar este dacă generează preocupări filosofice cu adevărat noi: există întrebări în PC-uri care nu au nicio paralelă în nicio altă ramură a filozofiei?

Bibliografie

• Allison, A., Currall, J., Moss, M. și Stuart, S., 2005, „Probleme de identitate digitală”, Journal of American Society Science Information and Technology 56 (4): 364–372.
• Arkoudas, K. și Bringsjord, S., 2007, „Calculatoare, justificare și cunoștințe matematice”, Minds and Machines 17 (2): 185–202.
• Barendregt, HP, 1993, „Lambda calculi cu tipuri”, în: Manual de logică în informatică, vol. 2, New York, NY: Oxford University Press Inc.
• Barker-Plummer, D., 2008, „Turing Machines”, The Stanford Encyclopedia of Philosophy (Ediția toamnă 2008), Edward N. Zalta (ed.), URL = .
• Bishop, Errett, 1977, Fundațiile analizei constructive, McGraw-Hill.
• Blass, Andreas și Gurevich, Yuri, 2003, „Algoritmii: o căutare a definițiilor absolute”, Buletinul Asociației Europene pentru Teoretica Calculatoarelor (EATCS) nr. 81: 195-225.
• Bowen, JP și Hinchey, MG, 1995, „Zece porunci ale metodelor formale”, IEEE Computer 28 (4): 56–63.
• Bowen, JP și Hinchey, MG, 2005, „Zece porunci ale metodelor formale: zece ani mai târziu”, IEEE Computer 39 (1): 40–48.
• Brooks, FP, 1987, „Fără bulgăre de argint: esența și accidentele ingineriei software”, IEEE Computer 20 (4): 10-19.
• Burge, T., 1998, „Proof Computer, A Priori Knowledge and Other Minds”, Perspective filozofice 12: 1–37.
• Bynum, T., 2001, „Etica computerului: concepte de bază și prezentare istorică”, The Stanford Encyclopaedia of Philosophy (Winter Edition 2001), Edward N. Zalta (ed.), URL =
• Colburn, T., 2004, „Metodologia informaticii”, The Blackwell Guide to the Philosophy of Computer and Information, Luciano Floridi (ed.), Malden: Blackwell, pp. 318–326.
• Colburn, T. și Shute, G., 2007, „Abstracția în informatică”, Minți și mașini 17 (2): 169-184.
• Coleman, KG, 2008, „Informatică și responsabilitate morală”, Enciclopedia Stanford of Philosophy (Ediția toamna 2008), Edward N. Zalta (ed.), URL = .
• Copeland, B. Jack, 2008, „The The Church-Turing Thesis”, The Stanford Encyclopedia of Philosophy (Fall Edition 2008 Edition), Edward N. Zalta (ed.), URL = .
• Copeland, B. Jack, 2004, „Calcul”, The Blackwell Guide to the Philosophy of Computing and Information, Luciano Floridi (ed.), Malden: Blackwell, p. 3–17.
• Coquand, Thierry, 2006, „Theory Type”, The Stanford Encyclopedia of Philosophy (Ediția de iarnă 2006), Edward N. Zalta (ed.), URL = .
• DeMillo, RA, Lipton, RJ și Perlis, AJ, 1979, „Procese sociale și dovezi ale teoremelor și programelor”, Comunicări ale ACM 22 (5): 271-280.
• Denning, PJ, 1980, „Pe teoreme populare și mituri populare”, Comunicările ACM 23 (9): 493–494.
• Denning, PJ, 1980b, „Ce este informatică experimentală?” Comunicări ale ACM 23 (10): 534–544.
• Denning, PJ, 1981, „Analiza performanței: Știința informatică experimentală ca fiind cea mai bună”, Comunicări ale ACM 24 (11): 725–727.
• Denning, PJ, 1985, „Știința calculului: Ce este știința computerelor?” Savant american 73 (1): 16–19.
• Denning, PJ (ed.), Et al., 1989, „Calcularea ca disciplină”, Comunicări ale ACM 32 (1): 9–23.
• Dijkstra, E., 1968. „Mergeți la declarația considerată dăunătoare”, Comunicări ale ACM 11 (3): 147–148.
• Dummett, M., 1991, „Bazele logice ale metafizicii”, Harvard University Press.
• Dummett, M., 2006, „Gândirea și realitatea”, Oxford University Press.
• Eden, Amnon, 2007, „Trei paradigme în informatică”, Minți și mașini 17 (2): 135–167.
• Feferman, S., 1992, „Logica pentru încetarea și corectitudinea programelor funcționale”, Logic for Computer Science: 95–127, MSRI Pubs. vol. 21, New York, NY: Springer-Verlag.
• Fetzer, JH, 1988, „Verificarea programului: ideea însăși”, Comunicările ACM 31 (9): 1048–1063.
• Fetzer, JH, 1999, „Rolul modelelor în informatică”, Monist 82 (1): 20–36.
• Fine, K., 2008, „Limitele abstracției”. Oxford: Oxford University Press.
• Floridi, Luciano, 2004. „Informații”, The Blackwell Guide to the Philosophy of Computing and Information, Luciano Floridi (ed.), Malden: Blackwell, p. 40–62.
• Floridi, Luciano 2007, „Concepții semantice ale informației”, Enciclopedia Stanford of Philosophy (Ediția de primăvară 2007), Edward N. Zalta (ed.), URL = .
• Forrest, P., 2006, „The Identity of Indiscernibles”, The Stanford Encyclopedia of Philosophy (Ediția toamna 2008), Edward N. Zalta (ed.), URL-ul viitoare =. >.
• Fuchs, NE, 1992, „Specificațiile sunt (de preferință) executabile”. Jurnalul de inginerie software 7 (5): 323–334.
• Gandy, R., 1980, „Teza și principiile Bisericii pentru mecanisme”, simpozionul Kleene, Barwise, J., Keisler, HJ și Kunen, K. (eds.), Amsterdam: Olanda de Nord.
• Hagar, Amit, 2007, „Algoritmi cuantici: lecții filozofice”, minți și mașini 17 (2): 233–247.
• Hale, B. și Wright, C., 2001, „The Reason's Proper Study: Essays spre Neo-Fregean Philosophy of Mathematics”, Burse Oxford pe linie, Oxford: Oxford University Press.
• Hartmanis, J., 1993, „Câteva observații despre natura informaticii”, Note de lectură în informatică 761, Shyamasundar, RK (ed.): 1–12.
• Hartmanis, J., 1994, „Turing Award Lecture: On Computational Complexity and the Nature of Computer Science”, Communications of ACM 37 (10): 37–43.
• Hoare, CAR, 1969, „O bază axiomatică pentru programarea computerului”. Comunicări ale ACM 12 (10): 576–585. [Reimprimare disponibil online]
• Hodges, A., 2006, „Biserica și Turingul au avut o teză despre mașini?”, Teza Bisericii după 70 de ani Olszewski, Adam (ed.)
• Hodges, A., 2007, „Calculul cuantic poate rezolva probleme de nerezolvat clasic?”
• Horsten, L., 2008, „Filosofia matematicii”, Enciclopedia lui Stanford a filozofiei (Ediția toamna 2008), Edward N. Zalta (ed.), URL = .
• Immerman, N., 2006, „Calculabilitate și complexitate”, Enciclopedia lui Stanford a filozofiei (Ediția toamna 2006), Edward N. Zalta (ed.), URL = .
• Irvine, AD, 2003, „Russell’s Paradox”, The Stanford Encyclopedia of Philosophy (Ediția toamna 2006), Edward N. Zalta (ed.), URL =
• Jones, CB și Hayes, IJ, 1990, „Specificațiile nu sunt (neapărat) nocive”, Software Engineering Journal 4 (6): 330–339.
• Krishnamurthi, S., 2003. Limbi de programare: aplicație și interpretare,
• Kreisel, G., Gandy, RO, 1975, „Câteva motive pentru teoria generalizării recursiunii.” Journal of Symbolic Logic 40 (2): 230–232.
• Kripke, S., 1982, Wittgenstein on Rules and Private Language. Harvard University Press.
• Kuhn, TS, 1970, Structura revoluțiilor științifice, a 2-a. ed., Chicago: Univ. din Chicago Press.
• Landin, PJ, 1964, „Evaluarea mecanică a expresiilor”, Computer Journal 6 (4): 308–320.
• Milne, R. și Strachey, C., 1977, A Theory of Programming Language Semantics, New York, NY: Halsted Press.
• McLaughlin, B., 2004, „Computaționalismul, conexionismul și filozofia minții”, Ghidul Blackwell pentru filosofia computerei și informației, Floridi, Luciano (ed.) Malden: Blackwell, pp. 135-152.
• Minsky, M., 1970, „ACM Turing Lecture: Form and Content in Computer Science”, Journal of the Association for Computing Machinery 17 (2): 197–215.
• Moor, JH, 1978, „Three Myths of Computer Science”, The British Journal for the Philosophy of Science 29 (3): 213–222.
• Moschovakis, YN, 1998, „La fondarea teoriei algoritmilor”, Adevărul în Matematica Dales, Harold G. și Oliveri, Gianluigi (eds.), Oxford: Oxford University Press.
• Pierce, Benjamin C., 2002, Tipuri și limbaje de programare, Cambridge, MA: MIT Press.
• Plotkin, HG, 1981, „O abordare structurală a semanticii operaționale”, tehn. Rep. DAIMI FN-19, Departamentul de Informatică, Universitatea Aarhus, Aarhus, Danemarca.
• Rapaport, WJ, 2005a, „Filozofia informaticii: un curs introductiv”, predarea filosofiei 28 (4): 319–341.
• Rapaport, WJ, 2005b, „Implementarea este interpretarea semantică: alte gânduri.” Journal of Experimental and Theoretical Artificial Intelligence 17 (4): 385–417.
• Rosen, Gideon, 2001. „Obiecte abstracte”, Enciclopedia Stanford of Philosophy (Ediția toamnă 2001), Edward N. Zalta (ed.), URL = .
• Shapiro, S., 1997, Filosofia matematicii: structură și ontologie, Oxford: Oxford University Press.
• Sieg, Wilfried, 2008, „Biserica fără dogmă: Axiome pentru computabilitate”, Noile paradigme computationale, Lowe, B., Sorbi, A. și Cooper, B. (eds.), Springer-Verlag, 139-152.
• Smith, BC, 1996, „Limitele corectitudinii în calculatoare”, Computerization and Controversy, Kling, R. (ed.), Morgan Kaufman, p. 810–825.
• Szabó, ZG, 2007, „Compoziționalitatea”, Enciclopedia lui Stanford a filozofiei (Ediția de primăvară 2007), Edward N. Zalta (ed.), URL = .
• Thomason, R., 2005, „Logic and Intelligence Artificial”, Enciclopedia Stanford of Philosophy (Ediția de vară 2005), Edward N. Zalta (ed.), URL = .
• Turner, Raymond și Eden, Amnon H., 2007, „Spre programarea limbajului ontologic”, Calcul, informație, Cognition-The Nexus and the Liminal, Dodig-Crnkovic, Gordana și Stuart, Susan (eds.), Cambridge, Marea Britanie: Cambridge Scholars Press, pp. 147-159.
• Turner, Raymond, 2005, „Bazele specificației”, Journal of Logic Computation 15: 623-662.
• Turner, Raymond, 2007, „Înțelegerea limbajelor de programare”. Minți și mașini 17 (2): 129-133
• Tymoczko, T., 1979, „The Four-Color Problem and its Philosophical Significance”, Journal of Philosophy 76 (2): 57–83.
• White, G., 2004, „Filosofia limbajelor computerizate”, Ghidul Blackwell pentru filozofia computerei și informațiilor, Floridi, Luciano (ed.), Malden: Blackwell, pp. 318–326.
• Aripă, JM, 2006, „Gândire computațională”, Comunicări ale ACM, 49 (3): 33–35.
• Wittgenstein, L., 1953. Investigații filozofice. Blackwell Publishing.
• Wright, Crispin, 1983, Concepția lui Frege a numerelor ca obiecte, Aberdeen University Press.

Alte resurse de internet

• Filosofia informaticii, la Universitatea Essex
• Asociația Internațională pentru Calcul și Filosofie