De Filosofie Van De Informatica

Inhoudsopgave:

De Filosofie Van De Informatica
De Filosofie Van De Informatica
Video: De Filosofie Van De Informatica
Video: #TeleŞcoala: Filosofie clasa a XII-a - Filosofie şi viaţă. Omul (@TVR2) 2023, Februari
Anonim

Dit is een bestand in de archieven van de Stanford Encyclopedia of Philosophy. Info over auteur en citaat | Vrienden PDF Preview | InPho Zoeken | PhilPapers bibliografie

De filosofie van de informatica

Voor het eerst gepubliceerd op 12 december 2008

De filosofie van de informatica (PCS) houdt zich bezig met filosofische kwesties die voortkomen uit reflectie op de aard en praktijk van de academische discipline van de informatica. Maar wat is dat laatste? Het is zeker niet alleen programmeren. Veel mensen die programma's schrijven zijn immers geen informatici. Zo doen natuurkundigen, accountants en scheikundigen het. Informatica zou inderdaad beter omschreven kunnen worden als betrokken bij de meta-activiteit die geassocieerd wordt met programmeren. Meer in het algemeen, en meer precies, houdt het zich bezig met het ontwerpen, ontwikkelen en onderzoeken van de concepten en methodologieën die de specificatie, ontwikkeling, implementatie en analyse van computersystemen vergemakkelijken en ondersteunen. Voorbeelden van deze activiteit zijn het ontwerpen en analyseren van programmeertalen, specificatie- en architectuurtalen;de constructie en optimalisatie van compilers, tolken, stellingproeven en type gevolgtrekkingen; de uitvinding van logische kaders en het ontwerp van embedded systemen, en nog veel meer. Veel van de centrale filosofische vraagstukken van de informatica omringen en ondersteunen deze activiteiten, en veel ervan concentreren zich op de logische, ontologische en epistemologische kwesties die ermee verband houden. Uiteindelijk is informatica echter wat informatici doen, en geen exacte formule-definitie kan dienen als een leidraad voor de discussie die volgt. De hoop is dat inderdaadVeel van de centrale filosofische vraagstukken van de informatica omringen en ondersteunen deze activiteiten, en veel ervan concentreren zich op de logische, ontologische en epistemologische kwesties die ermee verband houden. Uiteindelijk is informatica echter wat informatici doen, en geen exacte formule-definitie kan dienen als een leidraad voor de discussie die volgt. De hoop is dat inderdaadVeel van de centrale filosofische vraagstukken van de informatica omringen en ondersteunen deze activiteiten, en veel ervan concentreren zich op de logische, ontologische en epistemologische kwesties die ermee verband houden. Uiteindelijk is informatica echter wat informatici doen, en geen exacte formule-definitie kan dienen als een leidraad voor de discussie die volgt. De hoop is dat inderdaadPCS zal uiteindelijk bijdragen aan een dieper begrip van de aard van de informatica.

Maar het in kaart brengen van het filosofische landschap van de informatica is geen gemakkelijke taak. Gelukkig kunnen traditionele filosofietakken intellectuele en structurele begeleiding bieden. In de filosofieën van wiskunde en natuurkunde staan ​​bijvoorbeeld centrale vragen over de aard van de behandelde voorwerpen, wat is kennis en de middelen om die kennis te verkrijgen. De taalfilosofie roept vragen op over de inhoud en vorm van een semantische theorie voor natuurlijke taal. Het brengt de onderliggende ontologische en epistemologische veronderstellingen van de semantische onderneming naar voren. Ontologie geeft aan wat voor soort dingen er zijn, hoe ze kunnen worden geïndividualiseerd en hun rol bij het inlijsten van onze conceptuele schema's.De filosofie van de logica geeft een overzicht en analyse van verschillende soorten logische systemen en hun rol in het alledaagse en gespecialiseerde discours. Analogieën en overeenkomsten van deze en andere takken van de filosofie zouden nuttig moeten zijn bij het identificeren en verduidelijken van enkele van de centrale filosofische zorgen van de informatica. De bestaande invloed van deze disciplines opPCS zal verschijnen terwijl we doorgaan. Met name het tweede, derde en vierde deel zullen de impact van ontologie en de filosofieën van taal en wiskunde weerspiegelen.

  • 1. Enkele centrale problemen
  • 2. Bestaan ​​en identiteit

    • 2.1 Het dubbele karakter van programma's
    • 2.2 Programma's en algoritmen
    • 2.3 Programma's en specificaties
  • 3. Semantiek

    • 3.1 Denotationele en operationele semantiek
    • 3.2 Implementatie en semantische interpretatie
    • 3.3 Semantiek, gelijkheid en identiteit
  • 4. Bewijzen en programma's

    • 4.1 Bewijzen in de informatica
    • 4.2 Bewijzen in de wiskunde
    • 4.3 Fysieke en abstracte correctheid
  • 5. Berekenbaarheid

    5.1 De kerkelijke beproeving

  • 6. Programmeren en programmeertalen

    • 6.1 Abstractie
    • 6.2 Typen en ontologie
  • 7. Juridische en ethische vragen

    • 7.1 Auteursrechten, patenten en identiteit
    • 7.2 Juistheid en verantwoordelijkheid
  • 8. Nieuwe wendingen of nieuwe problemen?
  • Bibliografie
  • Andere internetbronnen
  • Gerelateerde vermeldingen

1. Enkele centrale problemen

Om te beginnen zullen we opsommen wat we beschouwen als enkele van de centrale kwesties en vragen. Dit zal de lezer een snel overzicht geven van zaken die een aanvulling zullen zijn op de volgende meer gedetailleerde discussie. Hoewel veel van hen niet rechtstreeks in de literatuur zijn behandeld en enige opheldering behoeven, illustreren deze vragen het soort problemen waarmee we het PCS bezighouden.

  1. Wat zijn programma's? Zijn ze abstract of concreet? (Moor 1978; Colburn 2004)
  2. Wat zijn de verschillen tussen programma's en algoritmen? (Rapaport 2005a)
  3. Wat is een specificatie? En wat wordt er gespecificeerd? (Smith 1985; Turner 2005)
  4. Zijn specificaties fundamenteel anders dan programma's? (Smith 1985)
  5. Wat is een implementatie? (Rapaport 2005b)
  6. Wat onderscheidt hardware van software? Bestaan ​​er programma's in zowel fysieke als symbolische vormen? (Moor 1978; Colburn 2004)
  7. Wat voor soort dingen zijn digitale objecten? Hebben we een nieuwe ontologische categorie nodig om ze te huisvesten? (Allison et al.2005)
  8. Wat zijn de doelstellingen van de verschillende semantische theorieën van programmeertalen? (White 2004; Turner 2007)
  9. Hoe verhouden vragen in de filosofie van programmeertalen zich tot parallelle vragen in de taalfilosofie? (Wit 2004)
  10. Heeft het modulariteitsbeginsel (bijv. Dijkstra 1968) betrekking op de conceptuele vraagstukken van volledige abstractie en compositie?
  11. Wat zijn de onderliggende conceptuele verschillen tussen de volgende programmeerparadigma's: gestructureerd, functioneel, logisch en objectgericht programmeren?
  12. Wat zijn de rollen van typen in de informatica? (Barandregt 1992; Pierce 2002)
  13. Wat is het verschil tussen operationele en denotationele semantiek? (Turner 2007)
  14. Wat betekent het dat een programma correct is? Wat is de epistemologische status van correctheidsbewijzen? Zijn ze fundamenteel anders dan bewijzen in de wiskunde? (DeMillo et al.1979; Smith 1985)
  15. Wat bewijzen de juistheidsbewijzen? (Fetzer 1988; Fetzer 1999; Colburn 2004)
  16. Wat is abstractie in de informatica? Hoe verhoudt het zich tot abstractie in de wiskunde? (Colburn & Shute 2007; Fine 2008; Hale & Wright 2001)
  17. Wat zijn formele methoden? Wat is formeel aan formele methoden? Wat is het verschil tussen een formele en een informele methode? (Bowen & Hinchey 2005; Bowen & Hinchey 1995)
  18. Wat voor soort discipline is informatica? Wat zijn de rollen van wiskundige modellering en experimenten? (Minsky 1970; Denning 1980; Denning 1981; Denning et al. 1989; Denning 1985; Denning 1980b; Hartmanis 1994; Hartmanis 1993; Hartmanis 1981; Colburn 2004; Eden 2007)
  19. Moeten programma's worden beschouwd als wetenschappelijke theorieën? (Rapaport 2005a)
  20. Hoe wordt wiskunde gebruikt in de informatica? Worden wiskundige modellen beschrijvend of normatief gebruikt? (White 2004; Turner 2007)
  21. Bevat de Church-Turing-stelling de wiskundige notie van een effectieve of mechanische methode in logica en wiskunde? Registreert het de berekeningen die door een mens kunnen worden uitgevoerd? Is het toepassingsgebied van toepassing op fysieke machines? (Copeland 2004; Copeland 2007; Hodges 2006)
  22. Is het idee van computationeel denken bestand tegen filosofisch onderzoek? (Wing 2006)
  23. Wat is de juiste logica om te redeneren over de juistheid en beëindiging van het programma? (Hoare 1969; Feferman 1992) Hoe is de logica afhankelijk van de onderliggende programmeertaal?
  24. Wat is informatie? (Floridi 2004; Floridi 2005) Werpt dit idee licht op enkele van de hier vermelde vragen?
  25. Waarom zijn er zoveel programmeertalen en programmeerparadigma's? (Krishnamurthi 2003)
  26. Hebben programmeertalen (en paradigma's) de aard van wetenschappelijke theorieën? Wat veroorzaakt een verschuiving in het programmeerparadigma? (Kuhn 1970)
  27. Levert software-engineering filosofische problemen op? (Eden 2007)

In wat volgt zullen we enkele van deze vragen nader invullen.

2. Bestaan ​​en identiteit

Hoe categoriseren en individualiseren we de entiteiten en concepten van informatica? Wat voor soort dingen zijn ze en wat bepaalt hun identiteit? Sommige zijn bijvoorbeeld duidelijk concrete fysieke objecten (bijv. Chips, routers, laptops, grafische kaarten) en andere niet (bijv. Formele grammatica's, abstracte machines, stellingproeven, logische kaders, procesalgebra's, abstracte gegevenstypen). Maar de karakterisering van enkele van de centrale begrippen zoals programma's en gegevens is problematischer geweest. Met name de ontologische status van programma's is niet geheel rechttoe rechtaan, en evenmin de kwestie van hun identiteitscriteria.

2.1 Het dubbele karakter van programma's

Veel auteurs (Moor 1978; Rapaport 2005b; Colburn 2004) bespreken de zogenaamde dubbele aard van programma's. Op het eerste gezicht lijkt een programma zowel een tekstuele als een mechanische of procesachtige gedaante te hebben. Als tekst kan een programma worden bewerkt. Maar de manifestatie ervan op een machineleesbare schijf lijkt heel andere eigenschappen te hebben. Het kan met name op een fysieke machine worden uitgevoerd. Dus volgens het principe van de onzichtbaarheid van identieken (§3.3), kunnen de twee gedaantes niet dezelfde entiteit zijn. Natuurlijk is iedereen die door deze dualiteit wordt overtuigd, verplicht iets te zeggen over de relatie tussen deze twee schijnbare bestaansvormen.

Een onmiddellijke suggestie is dat de ene manifestatie van een programma een implementatie is van de andere, dat wil zeggen, de fysieke manifestatie is een implementatie van de tekstuele. Maar zelfs binnen de grenzen van de informatica is het niet meteen duidelijk dat het woord implementatie naar slechts één begrip verwijst. Vaak wordt het gebruikt om te verwijzen naar het resultaat van een compilatieproces waarbij een programma in een taal op hoog niveau (de broncode) wordt omgezet in machinetaal (de objectcode). Maar even vaak wordt het gebruikt om te verwijzen naar het proces waarbij de broncode op de een of andere manier rechtstreeks wordt gerealiseerd in hardware (bijvoorbeeld een concrete implementatie in halfgeleiders). En vermoedelijk is dit het relevante idee. Maar zonder een meer gedetailleerde filosofische analyse van het begrip implementatie (§3.2) zelf (Rapaport 2005b),het is onduidelijk hoe dit de discussie bevordert; we lijken alleen de relatie tussen de twee schijnbare bestaansvormen te hebben genoemd. Anderen hebben op vergelijkbare wijze de relatie tussen de programmatekst en het programmaproces beschreven als vergelijkbaar met die tussen een plan en de manifestatie ervan als een reeks fysieke acties. Maar dit lijkt niet helemaal analoog aan de programmaproceskoppeling: we zijn niet geneigd om naar het plan en het fysieke proces te verwijzen als verschillende manifestaties van hetzelfde. Zijn we bijvoorbeeld geneigd om een ​​plan om te gaan wandelen en de daadwerkelijke wandeling te beschouwen als verschillende facetten van hetzelfde?anderen hebben de relatie tussen de programmatekst en het programmaproces beschreven als vergelijkbaar met die tussen een plan en de manifestatie ervan als een reeks fysieke acties. Maar dit lijkt niet helemaal analoog aan de programmaproceskoppeling: we zijn niet geneigd om naar het plan en het fysieke proces te verwijzen als verschillende manifestaties van hetzelfde. Zijn we bijvoorbeeld geneigd om een ​​plan om te gaan wandelen en de daadwerkelijke wandeling te beschouwen als verschillende facetten van hetzelfde?anderen hebben de relatie tussen de programmatekst en het programmaproces beschreven als vergelijkbaar met die tussen een plan en de manifestatie ervan als een reeks fysieke acties. Maar dit lijkt niet helemaal analoog aan de programmaproceskoppeling: we zijn niet geneigd om naar het plan en het fysieke proces te verwijzen als verschillende manifestaties van hetzelfde. Zijn we bijvoorbeeld geneigd om een ​​plan om te gaan wandelen en de daadwerkelijke wandeling te beschouwen als verschillende facetten van hetzelfde?komen we in de verleiding om een ​​plan om te gaan wandelen en de daadwerkelijke wandeling als verschillende facetten van hetzelfde te beschouwen?komen we in de verleiding om een ​​plan om te gaan wandelen en de daadwerkelijke wandeling als verschillende facetten van hetzelfde te beschouwen?

Misschien kunnen zaken het beste worden beschreven door te zeggen dat programma's, als tekstuele objecten, mechanische processen veroorzaken? Het idee lijkt te zijn dat het tekstuele object op de een of andere manier het mechanische proces fysiek veroorzaakt. Maar dit lijkt een nogal zorgvuldige analyse van de aard van zo'n oorzakelijk verband te vergen. Colburn (2004) ontkent dat de symbolische tekst het causale effect heeft; het is de fysieke manifestatie (het ding op de schijf) dat zo'n effect heeft. Software is een concrete abstractie met een beschrijvingsmedium (de tekst, de abstractie) en een uitvoeringsmedium (bijvoorbeeld een concrete implementatie in halfgeleiders).

Een iets ander perspectief op deze kwesties begint bij de kwestie van programma-identiteit. Wanneer zijn twee programma's hetzelfde? Dergelijke problemen doen zich bijvoorbeeld voor bij pogingen om de juridische identiteit van een stuk software te bepalen. Als we een programma identificeren met zijn tekstuele manifestatie, dan is de identiteit van een programma gevoelig voor veranderingen in zijn uiterlijk (bijvoorbeeld het veranderen van het lettertype). Het is duidelijk dat niet alleen de tekst ons een filosofisch interessant idee geeft over programma-identiteit. Om tot een weloverwogen identiteitscriterium te komen, moeten we meer rekening houden met semantiek en implementatie. We komen hierop terug in §3 en §6.

2.2 Programma's en algoritmen

Welke kijk we ook hebben op programma's, het onderscheid tussen algoritmen en programma's heeft ook behoefte aan verdere conceptuele verduidelijking. Algoritmen worden vaak beschouwd als wiskundige objecten. Als dit waar is, behoren veel van de filosofische kwesties die daarmee verband houden ook tot de filosofie van de wiskunde. Algoritmen zijn echter waarschijnlijk centraler in de informatica dan in de wiskunde en verdienen meer filosofische aandacht dan ze hebben gekregen. Hoewel er een aanzienlijke wiskundige studie is geweest van algoritmen in de theoretische informatica en wiskundige logica (bijv. Moschovakis 1997; Blass & Gurevich 2003), is er niet veel filosofische discussie geweest over de aard van algoritmen en de verschillen tussen algoritmen en programma's.

Zijn algoritmen abstracte objecten in de zin van Rosen (2001), terwijl programma's concreet zijn? Om precies te zijn, zijn algoritmen de abstracte wiskundige tegenhanger van een tekstueel object dat het programma is? Dit beeld leent zich op natuurlijke wijze voor een vorm van ontologisch platonisme (Shapiro 1997) waar algoritmen ontologische prioriteit hebben en programma's de taalkundige middelen verschaffen om ze te bereiken. Volgens deze opvatting kunnen algoritmen worden gebruikt om de semantiek (§3) van programmeertalen te verschaffen. Uiteraard erft dit beeld alle voordelen en problemen met zo'n platonisch perspectief (Shapiro 1997).

Een minder platonische opvatting is dat algoritmen de ideeën bevatten die in een programma zijn uitgedrukt. Dit is volgens de wet de reden dat algoritmen, in tegenstelling tot programma's, niet auteursrechtelijk beschermd zijn (§7.1). Natuurlijk vereist de term idee verdere filosofische analyse. Er zou zelfs kunnen worden beweerd dat het naakte idee van algoritme veel minder behoefte heeft aan verduidelijking dan het standaardverslag van ideeën en de daarmee samenhangende noties van abstractie (Rosen 2001).

Ten slotte is het bijna een folkloreopvatting dat Turing-machines ons een formele analyse van ons begrip algoritme bieden. Maar past dit in de hedendaagse notie die wordt gebruikt in de moderne informatica met zijn geavanceerde noties van representatie en controle? Moschovakis (1997) biedt een analyse die het iets beter doet.

2.3 Programma's en specificaties

Een ander populair onderscheid dat het onderwerp van enige kritische analyse zou moeten zijn, doet zich voor met betrekking tot programma's en specificaties. Wat zijn specificaties en hoe verschillen ze van programma's? Hoewel er in de filosofische literatuur weinig directe discussie is over dit onderwerp (maar zie Smith 1985), is de aard van specificaties een fundamenteel probleem voor de conceptuele grondslagen van de informatica.

Een mening, die veel voorkomt in leerboeken over formele specificatie, is dat programma's gedetailleerde machine-instructies bevatten, terwijl (functionele) specificaties alleen de relatie tussen de input en output beschrijven. Een voor de hand liggende manier om dit uit te pakken is in termen van het imperatieve / beschrijvende onderscheid: programma's zijn noodzakelijk en beschrijven hoe het door de specificatie beschreven doel kan worden bereikt. Zeker, in het imperatieve programmeerparadigma lijkt dit een inhoudelijk verschil te vangen. Maar het is niet voor iedereen geschikt. Zo worden logische, functionele en objectgeoriënteerde programmeertalen er niet duidelijk door beheerst: op het eerste gezicht bestaan ​​programma's die in dergelijke talen zijn gecodeerd uit opeenvolgingen van definities, niet uit 'instructies'. Bovendienniet-functionele specificaties kunnen niet worden verwoord als uitspraken over de relatie tussen input en output, omdat ze eisen stellen aan het ontwerp en aan het soort instructies dat in een programma kan worden opgenomen.

Een andere mening is dat het verschil tussen specificaties en programma's moet worden gelokaliseerd in termen van het idee van implementatie, dat wil zeggen, kan het worden samengesteld en uitgevoerd? Maar wat wordt daarmee bedoeld? Is het bedoeld in de zin van een bestaande compiler? Deze interpretatie is nogal oppervlakkig omdat ze geen conceptueel onderscheidingscriterium biedt, maar een contingent. Tijdens de eerste vijf generaties programmeertalen (2e helft 20e eeuw) zijn recursieve, modulaire, functionele en objectgeoriënteerde specificaties van de ene generatie onder de aandacht gebracht als programma's in de volgende, dat wil zeggen de huidige specificatietalen worden vaak de programmeertalen van morgen.

Een andere opvatting suggereert dat programmeertalen die talen zijn die in principe een implementatie hebben, terwijl specificatietalen die talen zijn die dat niet kunnen. En vermoedelijk is de reden dat ze dat niet kunnen, dat specificatietalen het mogelijk maken om begrippen uit te drukken die niet Turing-berekenbaar zijn. Dit onderscheid past bij veel bestaande specificatietalen die zijn gebaseerd op de verzamelingenleer van Zermelo-Fraenkel en logica van hogere orde. Het lijkt echter vreemd dat wat een specificatietaal zou moeten kenmerken, het feit is dat het niet-berekenbare eigenschappen en relaties kan uitdrukken. Zijn deze niet-berekenbare eisen in de praktijk echt nodig (Jones & Hayes 1990; Fuchs 1994)?

De diversiteit van deze opvattingen suggereert dat de traditionele, binaire scheiding tussen specificaties en programma's een voorbeeld is van een probleem in PCS dat meer aandacht verdient, niet alleen voor conceptuele verduidelijking, maar ook omdat het implicaties kan hebben voor het ontwerp van toekomstige programmeer- en specificatietalen.

3. Semantiek

De grammatica van een programmeertaal bepaalt alleen wat syntactisch legitiem is; het informeert ons niet over de beoogde betekenis van zijn constructies. De grammatica van een programmeertaal bepaalt dus op zichzelf niet wat mensen programmeren. In plaats daarvan wordt de grammatica verrijkt met een semantisch verslag (formeel of informeel). De semantiek is bedoeld om de programmeur, de samensteller en de theoreticus te informeren die geïnteresseerd is in het verkennen van de eigenschappen van de taal. Er wordt inderdaad vaak beweerd dat om te voldoen aan de verschillende vereisten van de programmeur en compiler-schrijver, verschillende semantische accounts op verschillende abstractieniveaus vereist zijn. En de taak van de theoreticus is om hun relatie te onderzoeken.

Dit is het standaardbeeld dat naar voren komt in de semantische literatuur. Maar veel hiervan heeft behoefte aan conceptuele verduidelijking. In deze sectie bespreken we enkele van de problemen die voortkomen uit deze activiteit.

3.1 Denotationele en operationele semantiek

Een van de belangrijkste verschillen in semantiek van programmeertalen draait om het onderscheid tussen operationele en denotationele semantiek. Een operationele semantiek (Landin 1964; Plotkin 1981) biedt een interpretatie van een programmeertaal in termen van een of andere abstracte machine. Om precies te zijn, het is een vertaling van uitdrukkingen in de programmeertaal in de instructies of programma's van de abstracte machine. Programma 1 wordt bijvoorbeeld uitgepakt in een reeks abstracte machinebewerkingen zoals "a ← 0" en push. Operationele semantiek kan ook worden opgevat als algoritmische semantiek, vooral wanneer de onderliggende machine is gericht op het karakteriseren van het begrip algoritme (bijv. Moschovakis 1997).

Een denotationele semantiek (Milne & Strachey 1977) biedt daarentegen een interpretatie in wiskundige structuren zoals verzamelingen of categorieën. In de klassieke benadering vormen sets in de vorm van volledige roosters en continue functies daarop bijvoorbeeld het wiskundige raamwerk.

Maar is er een significant conceptueel verschil tussen beide? Is het dat denotationele semantiek, die expliciet is gebaseerd op wiskundige structuren zoals verzamelingen, wiskundig is, terwijl operationele semantiek dat niet is? Turner (2007) stelt niet: ze bieden allemaal wiskundige interpretaties.

Of is operationele semantiek meer machine-achtig in de zin dat het een abstracte machine vormt, terwijl er bij denotationele semantiek, die in verzameltheoretische termen wordt gegeven, geen sprake is van een abstracte machine? Dergelijke verschillen zijn echter conceptueel niet significant gebleken, omdat denotationele semantische rekeningen allemaal kunnen worden gezien als structuren die een abstracte machine vormen met staten en operaties die erop opereren. Operationele rekeningen zijn ook niet dichter bij de implementatie: denotationele benaderingen (Milne & Strachey 1977) zijn ook erg flexibel en kunnen verschillende niveaus van implementatiedetails weerspiegelen.

Een ander mogelijk onderscheid betreft het compositorische (of anderszins) karakter van de semantiek. Losjes gesproken wordt een semantiek als compositorisch beschouwd (Szabó 2007) als de semantische waarde van een complexe uitdrukking een functie is van de semantische waarden van zijn delen. Compositionaliteit wordt beschouwd als een cruciaal criterium van semantiek, omdat het nodig lijkt om de productiviteit van ons taalkundig begrip te verklaren: het zou uitleggen hoe we complexe programma's begrijpen en construeren. Maar biedt het ons een wig om operationele en denotationele semantiek te scheiden? Helaas lijkt dit niet het geval te zijn: hoewel denotationele definities bedoeld zijn om compositorisch te zijn, is het zeker niet zo dat alle operationele semantiek niet compositorisch is.

Ten slotte verschillen sommige versies van semantiek wat betreft het bestaan ​​van een recursief model, dat wil zeggen een interpretatie in Turing-machines of Gandy-machines (§5.1). Maar zelfs dit komt niet precies overeen met de traditionele operationele / denotationele kloof. Sommige denotationele definities hebben een recursief model en andere niet.

Het lijkt erg moeilijk om dit onderscheid vast te stellen. Op het eerste gezicht lijkt er geen scherp conceptueel onderscheid te bestaan ​​tussen operationele en denotationele semantiek.

3.2 Implementatie en semantische interpretatie

Wat is het verschil tussen een semantische interpretatie en een implementatie? Wat is bijvoorbeeld het conceptuele verschil tussen het compileren van een programma in machinecode en het een denotationele semantiek te geven? Volgens Rapaport (2005b) wordt een implementatie het best gezien als semantische interpretatie, waarbij de laatste wordt gekenmerkt door een mapping tussen twee domeinen: een syntactische en een semantische. En beide worden bepaald door regels van een beschrijving. Zo is de gecompileerde code (in combinatie met de regels die de semantiek ervan beheersen) het semantische account van de broncode.

In een algemeen begrip van de term 'implementatie' wordt het semantische domein geleverd door een fysieke machine. Met andere woorden, de fysieke machine zelf (de 'implementatie') bepaalt wat het programma betekent. In programmeertalen komt dit bijvoorbeeld overeen met de bewering dat de semantiek voor de programmeertaal C ++ wordt bepaald door de computer van Bjarne waarop zijn C ++ -compiler draait. Maar deze verklaring is duidelijk ontoereikend: als we aannemen dat de machine van Bjarne de betekenis van C ++ -programma's bepaalt, is er geen idee van storing of verkeerde interpretatie: wat de computer van Bjarne ook doet, is ipso facto, de betekenis van het programma. Maar een elektrische storm kan er zeker voor zorgen dat de machine fout gaat. Maar wat kunnen we bedoelen met fout gaan? Vermoedelijk dat de (defecte) machine niet de bedoelde betekenis heeft. Maar,op zijn beurt lijken we deze zin alleen te kunnen begrijpen op basis van een machine-onafhankelijke karakterisering van de betekenis. En op een bepaald niveau moet dit worden gegeven via een onafhankelijke semantische beschrijving. Dit suggereert dat de notie van een kale implementatie geen adequate notie van semantiek biedt. (Vergelijk met: Kripke 1982; Wittgenstein 1953).

3.3 Semantiek, gelijkheid en identiteit

We sloten onze discussie over gelijkheid van programma's (§2.1) af met de belofte om semantiek in beeld te brengen. Elk semantisch verslag van een programmeertaal bepaalt een idee van gelijkheid voor programma's, namelijk dat twee programma's gelijk zijn als ze dezelfde semantische waarde hebben, dwz

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

waar || P || is de semantische waarde van het programma P. In die zin bepaalt dus elk semantisch verslag een criterium van gelijkheid. Eén versie van denotationele semantiek zou bijvoorbeeld wegtrekken van alle computationele stappen en programma's gelijkstellen die in zekere zin dezelfde wiskundige functie berekenen. De volgende twee programma's worden bijvoorbeeld door dit criterium als gelijk beschouwd:

functie Factor (n: geheel getal): geheel getal

begint

als n = 0

dan Factor: = 1;

anders

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

einde;

Programma 1

functie Factor (n: geheel getal): geheel getal

var

x, y: geheel getal;

begin

y: = 1;

x: = 0;

terwijl x <n beginnen

x: = x +1;

y: = y * x;

einde

Factor: = y;

einde;

Programma 2

Aan de andere kant zou een meer operationeel beeld, dat verwijst naar de stappen van de berekening, niet betekenen dat programma 1 en programma 2 gelijk zijn. In het licht van §3.1 kunnen we inderdaad semantische rekeningen opstellen die elk niveau van implementatiedetail weerspiegelen. Verschillende semantische rekeningen bepalen verschillende noties van gelijkheid die verschillende conceptuele en praktische doelen kunnen dienen. Maar welke moet dan worden genomen om de taal te bepalen? Gelukkig zijn er enkele desiderata die kunnen worden toegepast; we kunnen de opties beperken: sommige semantische accounts geven ons een logisch bevredigend idee van identiteit, en andere niet.

De onzichtbaarheid van identieke elementen is een principe dat is ingebouwd in de gewone predikatenlogica. Er staat dat als twee objecten gelijk zijn, ze alle eigenschappen delen. Het omgekeerde principe, de identiteit van onzichtbare zakenstelt dat als voor elke eigenschap F, object x F heeft als en alleen als object y F heeft, dan is x identiek aan y. De identiteit van niet-waarneembare impliceert dat als x en y verschillend zijn, er ten minste één eigenschap is die x heeft en y niet. Soms staat de combinatie van beide principes bekend als de wet van Leibniz (Forrest 2006). De wet van Leibniz wordt vaak als essentieel beschouwd voor elke notie van gelijkheid. Deze wetten zijn meestal geformuleerd in logische theorieën zoals logica van de tweede orde. Maar we zullen het meest geïnteresseerd zijn in hun vermogen om onderscheid te maken tussen verschillende soorten programmeertaalsemantiek. De wet van Leibniz is inderdaad een van de centrale noties van de moderne semantische theorie. Het criterium van identiteit wordt uitgewerkt in termen van observationele gelijkwaardigheid.

Twee programma's M en N zijn waarneembaar equivalentals en alleen als, in alle contexten C […] waar C [M] een geldig programma is, is het zo dat C [N] ook een geldig programma is met dezelfde semantische waarde. We zeggen bijvoorbeeld dat Oracle en DB2 (programma's die relationele databases manipuleren) qua observatie equivalent zijn volgens een semantisch overzicht van bewerkingen op relationele databases, en alleen als ze worden uitgevoerd in "dezelfde" context (besturingssysteem, machine-architectuur, invoer, enz.).) levert de "zelfde" database op. Natuurlijk moet de term observationeel equivalent worden ingenomen met een snufje zout. We kunnen het gedrag van een programma duidelijk niet in alle contexten waarnemen. Observationele gelijkwaardigheid weerspiegelt echter een onderliggende conceptuele vraag die voortkomt uit de principes van ononderscheidbaarheid van identicals en uit de identiteit van indiscernibles.

Als alle waarneembaar onderscheiden programma's in de semantiek verschillende semantische waarden hebben, wordt de semantiek als gezond beschouwd. Een degelijke semantiek voldoet dus aan het volgende principe:

|| P || = || Q || impliceert dat voor alle contexten C, || C [P] || = || C [Q] ||

Het moet duidelijk zijn dat het idee van identiteit dat wordt veroorzaakt door een solide semantiek, voldoet aan de onzichtbaarheid van identieke elementen.

Een semantiek zou compleet zijn als twee programma's met verschillende semantische waarden waarneembaar verschillen. Meer specifiek voldoet een complete semantiek aan het volgende:

Voor alle contexten C, || C [P] || = || C [Q] || impliceert || P || = || Q ||

Nogmaals, het moet duidelijk zijn dat een volledige semantiek voldoet aan het identiteitsbeginsel van onzichtbare zaken.

Ten slotte zou semantiek volledig abstract zijn als het degelijk en compleet is. Bijgevolg voldoet een volledig abstracte semantiek aan de wet van Leibniz.

Deze logische achtergrond vormt de filosofische rechtvaardiging voor de ontwikkeling van volledig abstracte semantiek. Het biedt ons dus een manier om semantische accounts te selecteren die filosofisch aanvaardbare noties van gelijkheid bieden. Het bepaalt natuurlijk geen enkel begrip. Het biedt alleen een hulpmiddel om degenen te verwerpen die een conceptueel aanvaardbare niet kunnen opleveren. Veel zogenaamde denotationele semantiek zijn niet volledig abstract, terwijl veel operationele dat wel zijn. Inderdaad, een van de centrale onderwerpen in de recente geschiedenis van semantiek heeft betrekking op het zoeken naar volledig abstracte definities die worden gegoten binnen de klasse van semantische definitietechnieken die worden gebruikt om een ​​denotationele semantiek te leveren.

Semantiek speelt een normatieve of bepalende rol in de informatica. Zonder semantische definities hebben talen en structuren geen inhoud die verder gaat dan die wordt geleverd door hun syntactische beschrijvingen. En deze laatste zijn nauwelijks voldoende voor praktische of filosofische doeleinden. Hoewel we een begin hebben gemaakt met de analyse van de centrale zorgen, hebben we alleen het oppervlak bekrast.

4. Bewijzen en programma's

Specificaties (§2.3) wekken een bepaald idee van correctheid op. Volgens de abstracte interpretatie van dit begrip wordt een programma geacht correct te zijn ten opzichte van een (functionele) specificatie als de relatie die het uitsteekt tussen de input en output voldoet aan die bepaald door de specificatie. Meer specifiek, als p een programma is, voldoet het aan een specificatie R, die wordt beschouwd als een relatie over het ingangstype I en het uitgangstype O, als het volgende geldt:

Voor alle inputs voldoet i van type I, het paar (i, p (i)), aan de relatie R

waarbij p (i) het resultaat is van het uitvoeren van het programma p op de ingang i. Hier wordt R uitgedrukt in een specificatietaal en p in een programmeertaal. De eerste is meestal een variant van (getypte) predikaatlogica en bewijzen van juistheid (dat wil zeggen dat bewering (1) geldt) worden uitgevoerd in het bewijssysteem van de logica. Hoare-logica (Hoare 1969) wordt bijvoorbeeld vaak gebruikt, waarbij bewijzen van correctheid de vorm aannemen van gevolgtrekkingen tussen triples, geschreven

B {P} A

waar P een programma is en B en A beweringen (de 'voor' en 'na' staten van het programma) uitgedrukt in een of andere versie van de predikaatlogica met kenmerken die de expressie van de waarden die aan de programmavariabelen zijn gekoppeld vergemakkelijken.

Een filosofische controverse rond de kwestie van correctheid is gebaseerd op de aard van dergelijke bewijzen; de andere uitdagingen wat zulke bewijzen opleveren.

4.1 Bewijzen in de informatica

Zijn bewijzen van juistheid van het programma echte wiskundige bewijzen, dat wil zeggen, zijn dergelijke bewijzen vergelijkbaar met standaard wiskundige bewijzen? DeMillo et al. (1979) beweren dat omdat correctheidsbewijzen lang en wiskundig oppervlakkig zijn, ze in tegenstelling tot bewijzen in de wiskunde zijn die conceptueel interessant en boeiend zijn en de aandacht trekken van andere wiskundigen die willen studeren en daarop willen voortbouwen. Een bewijs in Hoare-logica dat programma 2 de faculteit-functie berekent, zou bijvoorbeeld details bevatten over het onderliggende staatsbegrip, een inductief argument gebruiken en redeneren over lusinvariantie.

Maar zulke bewijzen zouden veel langer zijn dan het programma zelf. Bovendien zou het niveau waarop de redenering is gecodeerd in Hoare-logica de expressie en representatie vereisen van veel details die normaal gesproken impliciet zouden blijven. Het zou vervelend zijn en, in het geval van de meeste programma's, conceptueel triviaal.

Dit argument komt overeen met de begrijpelijkheidsargumenten in de filosofie van de wiskunde (bijv. Tymoczko 1979; Burge 1988). De kern is epistemologische zorgen: bewijzen die te lang, omslachtig en oninteressant zijn, kunnen niet de dragers zijn van het soort zekerheid dat wordt toegeschreven aan standaard wiskundige bewijzen. De aard van de kennis verkregen uit correctheidsbewijzen wordt beweerd anders te zijn dan de kennis die kan worden verkregen uit bewijzen in de wiskunde [1].

Men moet ook dit in wezen sociologische perspectief op bewijzen onderscheiden van het standpunt dat beweert dat bewijzen goed of fout zijn op een manier die onafhankelijk is van dergelijke epistemologische oordelen. Het is mogelijk om vast te houden aan de meer realistische positie volgens welk een bepaald bewijs juist of onjuist is zonder de eis op te geven dat bewijsmateriaal, om te worden opgenomen en gevalideerd, moet kunnen worden begrepen.

Je zou kunnen proberen wat terrein te winnen door te pleiten dat correctheidsbewijzen door een computer moeten worden gecontroleerd in plaats van door een mens. Maar natuurlijk is de proof-checker zelf aan controle toe. Arkoudas en Bringsjord (2007) stellen dat als er maar één correctheidsbewijs hoeft te worden gecontroleerd, namelijk dat van de proofchecker zelf, de kans op fouten aanzienlijk wordt verkleind.

4.2 Bewijzen in de wiskunde

Wiskundige bewijzen zoals het bewijs van Gödel's onvolledigheidsstelling zijn ook lang en gecompliceerd. Maar wat ze door de wiskundige gemeenschap transparant, interessant en begrijpelijk ('overzichtelijk') maakt, is het gebruik van modulariteitstechnieken (bv. Lemma's) en het gebruik van abstractie in het proces van wiskundige creatie. Door de introductie van nieuwe concepten kan een proef geleidelijk worden opgebouwd, waardoor de proeven beter grijpbaar worden. Wiskunde vordert door nieuwe wiskundige concepten uit te vinden die de constructie van hogere niveaus mogelijk maken en meer algemene bewijzen die zonder deze veel complexer en zelfs onmogelijk zouden zijn. De exponentnotatie maakt het bijvoorbeeld mogelijk om berekeningen uit te voeren die verder gaan dan de complexiteit van vermenigvuldiging - en te discussiëren over de resultaten. Aan het andere uiterste,de uitvinding van de categorietheorie vergemakkelijkte de verklaring en het bewijs van zeer algemene resultaten over algebraïsche structuren die automatisch van toepassing zijn op een hele reeks van dergelijke. Wiskunde gaat niet alleen over bewijs; het omvat ook de abstractie en creatie van nieuwe concepten en notatie. Op het eerste gezicht maken formele correctheidsbewijzen in het algemeen geen gebruik van de creatie van nieuwe concepten of raken ze niet betrokken bij het proces van wiskundige abstractie. Abstractie in de informatica (§6.1) is daarentegen geconcentreerd in de begrippen die nodig zijn voor het ontwerpen van programma's. Maar hoe verhouden deze twee noties van abstractie zich tot elkaar? We zullen hier later iets meer over zeggen.het omvat ook de abstractie en creatie van nieuwe concepten en notatie. Op het eerste gezicht maken formele correctheidsbewijzen in het algemeen geen gebruik van de creatie van nieuwe concepten of raken ze niet betrokken bij het proces van wiskundige abstractie. Abstractie in de informatica (§6.1) is daarentegen geconcentreerd in de begrippen die nodig zijn voor het ontwerpen van programma's. Maar hoe verhouden deze twee noties van abstractie zich tot elkaar? We zullen hier later iets meer over zeggen.het omvat ook de abstractie en creatie van nieuwe concepten en notatie. Op het eerste gezicht maken formele correctheidsbewijzen in het algemeen geen gebruik van de creatie van nieuwe concepten of raken ze niet betrokken bij het proces van wiskundige abstractie. Abstractie in de informatica (§6.1) is daarentegen geconcentreerd in de begrippen die nodig zijn voor het ontwerpen van programma's. Maar hoe verhouden deze twee noties van abstractie zich tot elkaar? We zullen hier later iets meer over zeggen.

4.3 Fysieke en abstracte correctheid

Zelfs als we deze epistemologische zorgen terzijde schuiven, stelt een tweede en schijnbaar meer verwoestende kritiek op correctheid de vraag wat er feitelijk door hen is vastgesteld. Blijkbaar biedt een bewijs van juistheid alleen correctheid tot aan de tekstuele weergave van het programma. Geen enkele vorm van formeel werk kan ons voorbij de abstracte / fysieke barrière brengen: we kunnen nooit garanderen dat een bepaalde uitvoering van het programma op een fysieke machine daadwerkelijk zal verlopen zoals verwacht (Fetzer 1988; Fetzer 1999; Colburn 2004).

Maar wat betekent het dat programma p correct is? Stel dat we een specificatie van het programma hebben en dat het formeel of informeel kan zijn. Stel dat we vervolgens een reeks testruns uitvoeren om te controleren of het programma aan de specificaties voldoet. Als ze slagen, hebben we empirisch bewijs dat de fysieke tegenhanger van het tekstuele programma inderdaad correct is omdat het functioneert volgens de specificatie. In deze visie werd de fysieke tegenhanger getest; niet het tekstuele programma.

Deze analyse suggereert dat er een dualiteit is in het begrip correctheid van programma's. In overeenstemming met het dubbele karakter van programma's, zouden we kunnen zeggen dat het tekstuele programma onderhevig is aan wiskundige correctheid, terwijl de fysieke tegenhanger onderworpen is aan empirische verificatie.

5. Berekenbaarheid

Computability is een van de oudste onderwerpen die als PCS kunnen worden bestempeld. Het is echter het onderwerp van verschillende SEP-vermeldingen (bijv. Barker-Plummer 2004) en daarom zullen we slechts een paar onderwerpen en hun verband met de rest van deze vermelding noemen.

5.1 De kerkelijke beproeving

Een van de centrale kwesties is de Church-Turing Thesis. En hier zijn er twee geschillen, een historische en een empirische. Ze concentreren zich op de volgende twee mogelijke interpretaties van het proefschrift:

  1. Turingmachines kunnen alles doen wat omschreven kan worden als "vuistregel" of "puur mechanisch".
  2. Alles wat door een machine kan worden berekend (werken aan eindige gegevens in overeenstemming met een eindig programma van instructies) is Turing machinaal berekenbaar.

Interpretatie I is bedoeld om de notie van een effectieve of mechanische methode in logica en wiskunde vast te leggen. Het is bedoeld om de informele notie van algoritme impliciet in wiskunde weer te geven en naar voren gebracht door het Hilbert's programma. Interpretatie II is bedoeld om fysieke machines te besturen. Inderdaad, (Gandy 1980) kan worden gezien als een verdere uitpak van II. Gandy stelt vier principes voor die bedoeld zijn om berekening door een fysieke machine te karakteriseren. Hij laat zien dat dergelijke machines precies overeenkomen met de karakterisering van Turing (Gandy's Theorem). In verband met onze bespreking van verschillende semantische paradigma's, is het duidelijk dat veel van de machines die ten grondslag liggen aan denotationele semantiek (§3.1) niet kwalificeren als Gandy-machines. Ze werken meestal met extensieve functieruimten van hogere orde,en deze kunnen niet worden beschouwd als eindige gegevens en voldoen niet aan Gandy's voorwaarden.

Sommigen beweren (Copeland 2004; Copeland 2008) dat het proefschrift zoals voorgesteld door Church en Turing alleen betrekking heeft op interpretatie I en geen limiet stelt aan machines in het algemeen. Hodges (2007) is het daar niet mee eens. Hij stelt dat Church en Turing geen onderscheid maakten tussen de twee interpretaties. Dit is het historische geschil.

Het fysieke geschil betreft de mogelijkheden van werkelijke machines (interpretatie II.) Velen nemen aan dat de stelling van Church-Turing de feitelijke fysieke berekening kenmerkt en voorschrijft. Dit lijkt bijvoorbeeld de impliciete aanname te zijn in de reguliere informatica. Het is zeker zo dat elk programma dat in een bestaande geïmplementeerde programmeertaal is geschreven Turing berekenbaar is en omgekeerd, dat alle algemene programmeertalen Turing compleet zijn, dat wil zeggen dat ze alle besturingsconstructies bevatten die nodig zijn om een ​​universele Turing-machine te simuleren.

Copeland (2007) stelt dat Gandy's karakterisering van een discreet deterministisch mechanisch apparaat te smal is, en dat er bijgevolg voorbeelden zijn van mogelijke fysieke machines waarvan de mogelijkheden verder gaan dan de klasse van berekenbare Turing-functies. Veel van deze vereisen een oneindige versnelling, waarbij een oneindig aantal berekeningen in een eindige tijd fysiek kan worden uitgevoerd. Quantum computing is genoemd als mogelijk voorbeeld voor dergelijke machines, maar dit wordt betwist (Hodges 2007; Hagar 2007).

Hodges houdt zich ook bezig met de toepasbaarheid van standaard wiskundige argumentatie in de natuurkunde op die gevallen waar oneindige precisie een rol speelt. Dit suggereert dat dit geschil niet eenvoudig empirisch is. Er zijn inderdaad mensen die zich afvragen of het fysiek mogelijk is om oneindig veel taken in een eindige tijd te voltooien. Dummett (2006) vraagt ​​zich af of het idee van een oneindige taak die in het fysieke rijk moet worden uitgevoerd, niet alleen een fysieke onmogelijkheid is, maar ook een conceptuele. Het geschil is dus niet alleen een empirische maar het raakt de kern van ons begrip van de relatie tussen onze wiskundige modellen en de fysieke realiteit.

6. Programmeren en programmeertalen

Het ontwerpen van programma's en programmeertalen is een van de traditionele activiteiten van de informatica. Ze worden omringd door tal van conceptuele vragen (§ 1), waarvan er veel geen filosofische aandacht hebben gekregen. Hier zullen we twee van deze problemen kort bespreken.

6.1 Abstractie

Abstractie is een van de conceptuele hoekstenen van de informatica. Het is een integraal onderdeel van programmaontwerp en -constructie en vormt een kernmethodologie voor het ontwerp van programmeertalen. Het stimuleert inderdaad de creatie van nieuwe programmeerparadigma's. Het ligt ten grondslag aan begrippen als procedurele en functionele abstractie, polymorfisme, is=" consistent=" with=" its=" declaration.=" in="" this="" way="" type="" systems="" provide="" a="" level="" of="" syntactic="" analysis="" that="" goes="" beyond="" supplied="" by="" context="" free="" grammar.="" but="" still="" seems="" like="" grammatical="" role.<="" p="">

Maar typen spelen ook een correctiefunctie die normaal niet in syntactische termen zou worden beschreven. Het doet dit door het traditionele fysieke begrip van dimensionale analyse uit te breiden tot een veel rijker typen systeem. Het verkrijgen van de juiste typestructuur voor een programma helpt de juistheid ervan te waarborgen. En dit wordt bepaald door de structuur die typen opleggen aan een taal. Typen repareren de soorten dingen die er zijn in een programmeertaal. Dus bijvoorbeeld elke programmeertaal die cijfers, producten en klassen toelaat, en niets anders, legt de programmeur een conceptueel kader op waarin ze moet werken. Problemen moeten worden gearticuleerd en oplossingen moeten worden gevonden binnen de representatiemiddelen die door het typensysteem worden geleverd. Zodra de typestructuur van een programmeertaal is vastgesteld, is een groot deel van de ontologische setting ervan hersteld.

Of toch? Misschien moeten we een stap terug doen en eerst vragen hoe de ontologische verbintenissen van een taal moeten worden bepaald. Bepaalt de semantiek zaken (Turner & Eden 2007)? Een lange traditie die uit Frege voortkomt, zou dat suggereren (Dummett 1991). Aannemende dat de analogie met natuurlijke talen legitiem is, wordt de ontologie van een taal bepaald door de structuren die nodig zijn om haar semantische domeinen te verschaffen. Maar welke semantische theorie moeten we hanteren? Hoewel elke semantiek rekening moet houden met typen, zou de semantisch bepaalde ontologie deze overstijgen en de betrokken semantische domeinen weerspiegelen, en deze zouden het implementatiedetail weerspiegelen dat in de semantiek is opgenomen. Daarom bepalen, net als bij gelijkheid, verschillende semantische interpretaties verschillende ontologieën.Hieruit volgt dat het niet verstandig is om te spreken over de ontologie van een programmeertaal, maar over meerdere ontologieën die afhangen van het abstractieniveau dat betrokken is bij de semantiek. De ontologie kan bijvoorbeeld ook gedeeltelijk worden bepaald door het programmeerparadigma.

7. Juridische en ethische vragen

Sommige aspecten van computerethiek behoren tot het PCS, omdat de activiteit van het bouwen en gebruiken van software ethische vragen oproept. Velen zijn echter niet specifiek voor informatica in de enge zin van dit artikel; ze raken het geheel van informatietechnologie en computertoepassingen (Bynum 2001). We zullen er daarom maar twee noemen die centraal staan ​​in de informatica.

7.1 Auteursrechten, patenten en identiteit

Copyrights bieden enige bescherming voor software, maar ze kunnen de semantische kern niet beschermen. En we nemen aan dat dit laatste moet worden bepaald door een semantisch verslag (§3) van de programmeertaal waarin het programma is geschreven. Vermoedelijk betreft de essentie van deze kwestie het probleem van de programma-identiteit (§3.3). Maar als er veel mogelijke semantische noties van identiteit zijn, welke is dan geschikt voor juridische toepassing?

Een informeel semantisch verslag dat vaak in de wet wordt geciteerd, identificeert het programma met de ideeën die erin zijn uitgedrukt, meestal beschouwd als het onderliggende algoritme. Maar niet alleen is het vaak moeilijk om precies te zeggen wat dit algoritme is, maar ook, zoals bij wiskundige stellingen, kunnen algoritmen niet auteursrechtelijk beschermd zijn. En hetzelfde lot wacht elk formeel semantisch verslag, aangezien een dergelijk bepaald zou worden door een wiskundig begrip, of het nu algoritmen zijn of een idee van bediening of wiskundige functie.

Maar zelfs als we een semantisch account zouden kunnen vinden dat zou voldoen aan de copyrightwetten, zou het juridische plaatje niet compleet zijn. Inbreuk op het auteursrecht hangt vaak niet alleen af ​​van een of andere identiteit, maar ook van de vraag of het aannemelijk is dat iemand hetzelfde programma zou bedenken. Zodat opzettelijke overwegingen het frame binnenkomen. Met andere woorden, zelfs als twee programma's volgens ons semantische criterium als gelijkwaardig worden beschouwd, zou er geen inbreuk op het auteursrecht zijn als het aannemelijk kan worden geacht dat ze onafhankelijk zijn samengesteld.

Patenten (met name utiliteitspatenten) zijn niet beter. Ze zijn nog moeilijker te krijgen voor software, omdat je geen mentale processen, abstracte ideeën en algoritmen kunt patenteren. En het zijn eerder algoritmen dan de broncode die vaak de nieuwe ideeën bevatten. Maar nogmaals, het zijn de identificatie- en identiteitskwesties die de centrale filosofische zorg zijn. En deze omvatten zowel semantische als opzettelijke overwegingen.

7.2 Juistheid en verantwoordelijkheid

Is het juist dat software wordt verkocht met weinig garantie op doelgerichtheid? (Coleman 2008) is gewijd aan deze vraag. Dit is een bijzonder relevante vraag voor veiligheidskritische systemen, bijvoorbeeld systemen die medische omstandigheden bewaken, kerncentrales bedienen en communiceren met ruimteveren. Hier lijkt het handhaven van strengere tests en bewijzen van juistheid essentieel. Maar is het in ethisch opzicht anders voor een programmeur die zijn programma niet analyseert en test dan voor een civiel ingenieur die de vereiste wiskundige modellering en tests op een bouwconstructie niet uitvoert? De morele verplichtingen lijken op elkaar.

Een manier waarop ze verschillend kunnen zijn, heeft betrekking op de complexiteit van software (Brooks 1987), die de complexiteit van elk ander soort menselijk artefact met een orde van grootte overtreft. Velen zouden beweren dat het niet haalbaar is om een ​​dergelijke garantie van correctheid te bieden (DeMillo et al. 1979); software is zo complex dat het proces van rigoureus wiskundig bewijs en het testen van software onhaalbaar is. En vermoedelijk kan men alleen een (morele of juridische) verplichting hebben om een ​​haalbaar proces uit te voeren.

Maar hoe kan men de beproevings- en testaspecten van softwareontwikkeling afwegen tegen het beoogde gebruik van de software? Moet software die is ontwikkeld voor entertainment worden onderworpen aan dezelfde mate van rigoureus bewijs en testen als software die cruciaal is voor de veiligheid? Waarschijnlijk niet, maar we zouden nog steeds in de verleiding kunnen komen om te vragen: zijn deze nieuwe ethische problemen of verschaffen ze ons gewoon meer casestudy's van bestaande ethische dilemma's? Zelfs beveiligingsproblemen in software die in de entertainmentindustrie wordt gebruikt, kunnen bijvoorbeeld financiële boetes met zich meebrengen.

8. Nieuwe wendingen of nieuwe problemen?

Zelfs dit nogal korte overzicht van PCSmoet de lezer ervan overtuigen dat informatica interessante en veeleisende filosofische kwesties opwerpt. Een van de belangrijkste indrukken is inderdaad dat het substantiële banden heeft met de meeste traditionele takken van de filosofie. Er zijn duidelijke verbanden met ontologie, ethiek, epistemologie en de filosofieën van wiskunde, natuurkunde en taal. Onze eerste lijst met vragen roept inderdaad veel meer thema's op die verband houden met andere filosofische gebieden. Er is met name een substantiële literatuur over de toepassingen van informatica. Kunstmatige intelligentie en cognitieve wetenschap leveren filosofische vragen op die tot de filosofie van de geest behoren (McLaughlin 2004). Veel hiervan komt natuurlijk uit Turing (1950). Andere toepassingen van informatica op traditionele wetenschapsgebieden, de zogenaamde computationele wetenschap,vraagstukken creëren voor de wetenschapsfilosofie: wat is de epistemologische impact van computersimulaties, vooral waar dit de enige levensvatbare vorm van experimenteren is? De computationele wending in de ontologie brengt nieuwe technieken met zich mee voor de structuur van elke vorm van conceptuele ontologie. De filosofie van de logica wordt verrijkt door een massa materiaal: er zijn grote aantallen nieuwe logische systemen ontstaan ​​met het oog op representatie en redenering over computersystemen.grote aantallen nieuwe logische systemen zijn ontstaan ​​met het oog op representatie en redenering over computationele systemen.grote aantallen nieuwe logische systemen zijn ontstaan ​​met het oog op representatie en redenering over computationele systemen.

Hoewel het duidelijk is dat informatica veel significante wendingen naar traditionele filosofische zorgen oproept, is het minder duidelijk of het echt nieuwe filosofische zorgen oproept: zijn er vragen in PCS die geen parallel hebben in een andere tak van de filosofie?

Bibliografie

  • Allison, A., Currall, J., Moss, M. en Stuart, S., 2005, "Digital identity Matters", Journal of American Society Information Science and Technology 56 (4): 364–372.
  • Arkoudas, K. en Bringsjord, S., 2007, "Computers, rechtvaardiging en wiskundige kennis", Minds and Machines 17 (2): 185-202.
  • Barendregt, HP, 1993, "Lambda calculi with types", in: 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 (red.), URL = .
  • Bishop, Errett, 1977, Foundations of constructive analysis, McGraw-Hill.
  • Blass, Andreas en Gurevich, Yuri, 2003, "Algorithms: A Quest for Absolute Definitions", Bulletin van de European Association for Theoretical Computer Science (EATCS) No.81: 195-225.
  • Bowen, JP en Hinchey, MG, 1995, 'Tien geboden van formele methoden', IEEE Computer 28 (4): 56-63.
  • Bowen, JP en Hinchey, MG, 2005, 'Tien geboden van formele methoden: tien jaar later', 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, "Computer Proof, A Priori Knowledge, and Other Minds", Philosophical Perspectives 12: 1–37.
  • Bynum, T., 2001, "Computer Ethics: Basic Concepts and Historical Overview", The Stanford Encyclopaedia of Philosophy (Winter 2001 Edition), Edward N. Zalta (red.), URL =
  • Colburn, T., 2004, "Methodology of Computer Science", The Blackwell Guide to the Philosophy of Computing and Information, Luciano Floridi (red.), Malden: Blackwell, pp. 318–326.
  • Colburn, T., en 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 (red.), URL = .
  • Copeland, B. Jack, 2008, "The Church-Turing Thesis", The Stanford Encyclopedia of Philosophy (Fall 2008 Edition), Edward N. Zalta (red.), URL = .
  • Copeland, B. Jack, 2004, "Computation", The Blackwell Guide to the Philosophy of Computing and Information, Luciano Floridi (red.), Malden: Blackwell, pp. 3–17.
  • Coquand, Thierry, 2006, "Type Theory", The Stanford Encyclopedia of Philosophy (Winter 2006 Edition), Edward N. Zalta (red.), URL = .
  • DeMillo, RA, Lipton, RJ en Perlis, AJ, 1979, "Sociale processen en bewijzen van stellingen en programma's", Communicatie van de ACM 22 (5): 271–280.
  • Denning, PJ, 1980, “On Folk Theorems and Folk Myths”, Communications of the ACM 23 (9): 493–494.
  • Denning, PJ, 1980b, "Wat is experimentele informatica?" Mededelingen van de ACM 23 (10): 534–544.
  • Denning, PJ, 1981, "Performance Analysis: Experimental Computer Science as its Best", Communicatie van de ACM 24 (11): 725–727.
  • Denning, PJ, 1985, "The Science of Computing: Wat is informatica?" Amerikaanse wetenschapper 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. "Ga naar verklaring beschouwd als schadelijk", Mededelingen van de ACM 11 (3): 147–148.
  • Dummett, M., 1991, "The Logical Basis of Metaphysics", Harvard University Press.
  • Dummett, M., 2006, "Thought and Reality", Oxford University Press.
  • Eden, Amnon, 2007, 'Three Paradigms in Computer Science', Minds and Machines 17 (2): 135–167.
  • Feferman, S., 1992, "Logica voor beëindiging en correctheid van functionele programma's", Logica voor informatica: 95–127, MSRI Pubs. vol. 21, New York, NY: Springer-Verlag.
  • Fetzer, JH, 1988, "Program Verification: The Very Idea", Communicatie van de ACM 31 (9): 1048-1063.
  • Fetzer, JH, 1999, "The Role of Models in Computer Science", The Monist 82 (1): 20–36.
  • Fine, K., 2008, "The Limits of Abstraction". Oxford: Oxford University Press.
  • Floridi, Luciano, 2004. "Informatie", The Blackwell Guide to the Philosophy of Computing and Information, Luciano Floridi (red.), Malden: Blackwell, pp. 40–62.
  • Floridi, Luciano 2007, "Semantic Conceptions of Information", The Stanford Encyclopedia of Philosophy (Spring 2007 Edition), Edward N. Zalta (red.), URL = .
  • Forrest, P., 2006, "The Identity of Indiscernibles", The Stanford Encyclopedia of Philosophy (Fall 2008 Edition), Edward N. Zalta (red.), Aanstaande URL =. >.
  • Fuchs, NE, 1992, "Specificaties zijn (bij voorkeur) uitvoerbaar". Software Engineering Journal 7 (5): 323–334.
  • Gandy, R., 1980, "Thesis en principes van de kerk voor mechanismen", The Kleene symposium, Barwise, J., Keisler, HJ en Kunen, K. (redactie), Amsterdam: Noord-Holland.
  • Hagar, Amit, 2007, "Quantum-algoritmen: filosofische lessen", geesten en machines 17 (2): 233–247.
  • Hale, B. en Wright, C., 2001, "The Reason's Proper Study: Essays towards Neo-Fregean Philosophy of Mathematics", Oxford Scholarships on Line, Oxford: Oxford University Press.
  • Hartmanis, J., 1993, 'Some Observations about the Nature of Computer Science', Lecture Notes in Computer Science 761, Shyamasundar, RK (red.): 1–12.
  • Hartmanis, J., 1994, 'Turing Award Lecture: On Computational Complexity and the Nature of Computer Science', Communications of the ACM 37 (10): 37–43.
  • Hoare, CAR, 1969, "Een axiomatische basis voor computerprogrammering". Mededelingen van de ACM 12 (10): 576–585. [Herdruk online beschikbaar]
  • Hodges, A., 2006, "Had Church and Turing een scriptie over machines?", Church's Thesis after 70 years Olszewski, Adam (red.)
  • Hodges, A., 2007: "Kan quantum computing klassiek onoplosbare problemen oplossen?"
  • Horsten, L., 2008, "Philosophy of Mathematics", The Stanford Encyclopedia of Philosophy (Fall 2008 Edition), Edward N. Zalta (red.), URL = .
  • Immerman, N., 2006, "Computability and Complexity", The Stanford Encyclopedia of Philosophy (Fall 2006 Edition), Edward N. Zalta (red.), URL = .
  • Irvine, AD, 2003, "Russell's Paradox", The Stanford Encyclopedia of Philosophy (Fall 2006 Edition), Edward N. Zalta (red.), URL =
  • Jones, CB en Hayes, IJ, 1990, "Specificaties zijn niet (noodzakelijkerwijs) schadelijk", Software Engineering Journal 4 (6): 330–339.
  • Krishnamurthi, S., 2003. Programmeertalen: toepassing en interpretatie,
  • Kreisel, G., Gandy, RO, 1975, "Enkele redenen om de recursietheorie te generaliseren." The Journal of Symbolic Logic 40 (2): 230–232.
  • Kripke, S., 1982, Wittgenstein over regels en privétaal. Harvard University Press.
  • Kuhn, TS, 1970, The Structure of Scientific Revolutions, 2e. red., Chicago: Univ. van Chicago Press.
  • Landin, PJ, 1964, "De mechanische evaluatie van uitdrukkingen", Computer Journal 6 (4): 308-320.
  • Milne, R. en Strachey, C., 1977, A Theory of Programming Language Semantics, 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 (red.) 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, "On founding the theory of algoritms", Truth in Mathematics Dales, Harold G. en Oliveri, Gianluigi (red.), Oxford: Oxford University Press.
  • Pierce, Benjamin C., 2002, Typen en programmeertalen, Cambridge, MA: MIT Press.
  • Plotkin, GD, 1981, "A Structural Approach to Operational Semantics", Tech. Rep. DAIMI FN-19, Computer Science Department, Aarhus University, Aarhus, Denemarken.
  • Rapaport, WJ, 2005a, "Philosophy of Computer Science: An Introductory Course", Teaching Philosophy 28 (4): 319–341.
  • Rapaport, WJ, 2005b, "Implementatie is semantische interpretatie: verdere gedachten." Journal of Experimental and Theoretical Artificial Intelligence 17 (4): 385–417.
  • Rosen, Gideon, 2001. "Abstract Objects", The Stanford Encyclopedia of Philosophy (Fall 2001 Edition), Edward N. Zalta (red.), URL = .
  • Shapiro, S., 1997, Philosophy of Mathematics: Structure and Ontology, Oxford: Oxford University Press.
  • Sieg, Wilfried, 2008, "Church without Dogma: Axioms for Computability", New Computational Paradigms, Lowe, B., Sorbi, A. en Cooper, B. (redactie), Springer-Verlag, 139–152.
  • Smith, BC, 1996, "Limits of Correctness in Computers", Computerization and Controversy, Kling, R. (red.), Morgan Kaufman, pp. 810–825.
  • Szabó, ZG, 2007, “Compositionaliteit”, The Stanford Encyclopedia of Philosophy (editie voorjaar 2007), Edward N. Zalta (red.), URL = .
  • Thomason, R., 2005, "Logic and Artificial Intelligence", The Stanford Encyclopedia of Philosophy (editie zomer 2005), Edward N. Zalta (red.), URL = .
  • Turner, Raymond en Eden, Amnon H., 2007, "Towards Programming Language Ontology", Computation, Information, Cognition-The Nexus and the Liminal, Dodig-Crnkovic, Gordana and Stuart, Susan (red.), Cambridge, VK: Cambridge Scholars Press, pp. 147–159.
  • Turner, Raymond, 2005, "The Foundations of Specification", Journal of Logic Computation 15: 623–662.
  • Turner, Raymond, 2007, "Programmeertalen begrijpen". Minds and Machines 17 (2): 129-133
  • Tymoczko, T., 1979, "Het vierkleurenprobleem en zijn filosofische betekenis", Journal of Philosophy 76 (2): 57–83.
  • White, G., 2004, "The Philosophy of Computer Languages", The Blackwell Guide to the Philosophy of Computing and Information, Floridi, Luciano (red.), Malden: Blackwell, pp. 318–326.
  • Wing, JM, 2006, 'Computational Thinking', Communications of the ACM, 49 (3): 33–35.
  • Wittgenstein, L., 1953. Filosofische onderzoeken. Blackwell Publishing.
  • Wright, Crispin, 1983, Frege's Conception of Numbers as Objects, Aberdeen University Press.

Andere internetbronnen

  • Filosofie van de informatica aan de Essex University
  • Internationale vereniging voor informatica en filosofie

Populair per onderwerp