Van-e az informatikának hermeneutikája? Binzberger Viktor MTA-BME Tudományfilozófia és Tudománytörténet Kutatócsoport

A kérdés kognitív tudományi relevanciája A kortárs elmefilozófián belül a komputácionalizmus azt képviseli, hogy az elme ekvivalens egy szimbólum-manipulációt végző Turing-géppel. Amennyiben az elmét meg akarjuk érteni, ehhez az elme szimbolikus műveleteit kell megértenünk. Ennek a megértésnek a lehetősége ekvivalens az elme számítógépes modellálásának a lehetőségével.

A kérdés kognitív tudományi relevanciája Az informatikus az elme számítógép- metaforájának forrásául szolgáló számítógépes szimbólummanipuláció megalkotásával és megértésével foglalkozik. HA állítást teszünk arra vonatkozólag, hogy ő hogyan érti meg a számítógépes szimbólumokat ÉS osztjuk a komputácionalizmus tézisét, AKKOR állításunk egyidejűleg az elme megismerésére is vonatkozik.

A kérdés A címben szereplő kérdés Márkus György híres cikkének a parafrázisa: „Miért nincs a természettudományoknak hermeneutikája?” Azaz: hogyan lehetséges az, hogy a természettudomány jól funkcionál anélkül, hogy a szellemtudományok értelmezési gyakorlatához hasonló explicit, reflektált értelmezési gyakorlattal bírna?

Márkus György „A természettudományok »ideológiája« (ha ugyan puszta ideológiáról van szó) [...] szerint bármely elfogadható tudományos szöveg, jelentését tekintve, teljesen önálló (és ezért a megfelelően felkészült olvasók bármelyikének egyértelműen világos)” „Ténylegesen megvalósított hermeneutikai teljesítménye felől szemlélve a természettudomány igencsak »felsőrendűnek« tűnik a nagyfokú hermeneutikai öntudattal rendelkező humán tudományokhoz és a »lágy« társadalomtudományokhoz mérten.” Hogyan lehetséges ez?

Természettudományos szellemtudományi szövegek (Márkus) Természettud. szövegSzellemtud. szöveg Értelmezésük hallgatólagos háttérismereteket, kísérleti / kulturális készségeket igényel Az értelmezés háttere jól körülhatárolható, standard szakmai ismereteket / készségeket takar Az értelmezés háttere gyakran a kulturális közeg nagy részét átfogja, kevéssé standard Az instrumentális cselekvés, egy relatíve stabil (operacionalizálásra lehetőséget teremtő) hátteret ad Az örökké változó történeti- szellemi kontextusban újra és újra kell értelmezni az eredeti szöveget Az egyetlen „helyes” értelmezés, a „jó modell” elérése a cél Alternatív értelmezési tradíciók egymás mellett élése Az egyértelműség értékA pluralitás érték

Márkus válasza A természettudományt az az általános stratégia jellemzi, hogy a művelői megpróbálnak olyan szituációt teremteni, ahol nem kell hermeneutikai problémákkal bajlódni. Ezt oly módon érik el, hogy megpróbálják az intézményrendszert, a publikációs szokásokat eleve úgy szervezni, hogy az garantálja az egyértelműséget, kizárja a hermeneutikai probléma felléptét.

Márkus válasza Márkus a tudományos nyelv változását egy standardizálódási folyamatként rekonstruálja, amelyben az alternatív értelmezési lehetőségek kollektíve operatíven eldöntésre kerülnek, vagy specializált résztudományokká osztódást eredményeznek, vagy feladják őket, mint tudományosan eldönthető kérdést, de mindenesetre nem maradnak nyitottak. Márkus szerint ez a törekvés lényegében sikeres: a természettudományoknak nincsen szüksége hermeneutikára.

Az informatika esete Az informatika helyzete a fenti szempontból tekintve analóg a természettudományokéval. Itt is (formális) modellalkotás folyik Az értelmezői tevékenység itt is alárendelt az instrumentális cselekvéshez képest Az értelmezési problémák itt is kerülendőek Sőt: az instrumentális tevékenység itt szükségképpen együtt jár a teljeskörű szimbolikus formalizációval, ami a nyelv standardizációjának a határhelyzete Itt a márkusi program konzekvens végigvitelét láthatjuk Ha az analógiát elfogadjuk, akkor úgy tűnik, itt sincs szükség hermeneutikára.

A formalizáció megértése azonban mindig egy nem-formális megértési háttérbe ágyazódik A közhiedelemmel ellentétben a számítógépes nyelv nem a „számítógép nyelve”, hanem a programozóé. A programozók meglévő gyakorlatát tekintve a formális rendszer megértése nem azonos a formális szimbólumstruktúrák ismeretével. Példa: = (thedailywtf.com a nap vicce)

A formalizáció megértése azonban mindig egy nem- formális megértési háttérbe ágyazódik 1. A programozó a formális rendszert annak funkciója felől megközelítve érti meg. A funkció viszont nem pusztán a formális struktúra jellemzője, hanem a formális nyelv beágyazódásának teret adó társas világbeli kontextusban lép fel (externalista álláspont) Az, hogy egy programrészlet „mire való” / „mire alkalmas”, a lehetséges használati kontextusok fényében ítélhető meg. (pragmatista álláspont) 2. az elemi formális struktúrák metanyelvi bevezetésekor a megértés a köznyelvre, ill. már ismert tárgyakra és fogalmakra épülő metaforákra támaszkodik Példa: a memória doboz- ill. szalag-metaforája Mindkét esetben arról van szó, hogy egy véges megismerőképességgel rendelkező ember számára kell elgondolhatóvá, manipulálhatóvá tenni egy idegen területet.

Módszertani probléma: hermeneutikai kör (Habermas) A megértés kiépítése, az interpretáció során azt a szimbolikusan nem artikulált hátteret is meg kell érteni, amelynek az előterében a szimbolikus nyelvhasználat lezajlik Ezt azonban csak valamilyen már előzetesen megosztott háttérre támaszkodva lehet kivitelezni. A gyakorlatban az interpretáció során a hétköznapi nyelv egyes részeit metanyelvként, más részeket tárgynyelvként használjuk, majd megint más részekre támaszkodva ellenőrizzük az interpretációt, és utána további körökben pontosítjuk azt.

Milyen jellegzetes szituációkban szembesülnek a fejlesztők a hermeneutikai problémával? Két jellegzetes hermeneutikai szituáció a szoftverfejlesztés gyakorlatában: 1. A felhasználó „problémájának” a megértése 2. A más által írt formális rendszer megértése

1. A felhasználó problémájának a megértése Az informatikus által épített formális modell - szemben a term. tudóséval - általában nem egy embertől függetlenül létező természet reprezentációjára irányul, hanem a felhasználó „problémájának” a megoldására. Példa: egy cég ügyviteli folyamatainak a formalizálása eredetileg nincsenek expliciten artikulálva, hallgatólagos/procedurális ismeretek, tárgyak formájában egy meglévő emberi viszonyrendszerbe ágyazódik (hallgatólagos hatalmi hierarchiák, szokások) kezdetben köznyelvi fogalmakkal kerül artikulálásra, pontatlanul és részlegesen („rosszul definiált feladat”)

1. A felhasználó problémájának a megértése A szoftver konzulens / rendszertervező helyzete hasonló a terepmunkát végző szociológuséhoz: meg kell értenie a felhasználó gondolkodásmódját és a problémát le kell fordítania az ő saját formális nyelvére Ez egy hermeneutikai probléma! A különféle szoftverfejlesztési módszertanok (XP, RUP, stb.) reflektálnak erre a problémára és összhangban állítják, hogy ez a folyamat iteratív.

2. A más által írt formális rendszer megértése A program megértése a funkció megértését feltételezi, az viszont a lehetséges használati kontextusok megértésén alapul. A lehetséges használati kontextusokról való megértés viszont gyakran hallgatólagos előfeltevések, procedurális ismeretek, know-how formájában van jelen, nincsen artikulálva. Példa: egy adatbázis a valóság radikálisan egyszerűsített képe. Mi alapján gondolta vajon az eredeti író, hogy éppen ezeket az egyszerűsítéseket lehet megtenni és nem másokat?

2. A más által írt formális rendszer megértése Ahhoz tehát, hogy a programozó a más által írt formális rendszert megértse, bele kell helyezkednie abba a perspektívába, amelyből az eredeti író a használati kontextusokat, a funkciót elgondolta. A megértés eme hallgatólagos hátterének a rekonstrukciója gyakran arra támaszkodik, hogy a formális nyelvet már az eredeti író is a köznyelvbe ágyazódó nyelvként értette meg, ezért köznyelvi szavakat adott változó- és függvényneveknek, stb. A rekonstrukció további forrásai a dokumentáció, a kommentár, és a fejlesztők közötti kommunikáció.

A válasz a címben felvetett kérdésre A fenti két szituáció jelentős teret kap a szoftverfejlesztés módszereiről szóló diskurzusban. A dokumentáció, a specifikáció, a felhasználók és a programozók közötti hatékony interakció a szoftverfejlesztési módszertanok központi témája. Jellegzetes a módszertanok terén is a standardizáló tendencia: pl. az UML a tervdiagramok rajzolásának szabványosított módja. De létezik ezzel szemben az anarchista, „feyerabendi” modell is (eXtreme Programming), ami a közvetlen interperszonális kommunikáció fontosságát hangsúlyozza az elemző tervezés eluralkodásával szemben.

A válasz a címben felvetett kérdésre Szemben Márkussal, a szoftverfejlesztési módszertanok esetében azt láthatjuk, hogy a szoftverfejlesztés innovatív frontján van egy aktív, önreflexív diskurzus, amely a hermeneutikai problémákra fókuszál. Az informatikának tehát ebben az értelemben van hermeneutikája, noha a gyakorlói nem annak nevezik.

Visszatérve a kognitív tudományi relevanciára Ha előttünk lenne az „elme forráskódja”, azt még önmagában ugyanúgy nem értenénk, mint bármelyik másik forráskódot. Az elme megértése nem pusztán az elme formális modelljéből áll, mert 1. a formális modell beágyazódik azokról a lehetséges kontextusokról meglévő megértésünkbe, amelyekben az elme a környezetével interakcióba léphet. (Dewey értelmében vett lélektani funkció) 2. a formális modell metanyelvű definiálásakor ugyanúgy a meglévő ismereteinkre, a hétköznapi nyelvre, stb. kell támaszkodnunk, mint a programnyelvek esetében