Vane az informatiknak hermeneutikja Binzberger Viktor MTABME Tudomnyfilozfia

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 l l l 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 l l Az informatikus az elme számítógépmetaforá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 l l l 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 l l l „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öveg Szellemtud. 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 Az értelmezés háttere gyakran a körülhatárolható, standard szakmai kulturális közeg nagy részét ismereteket / készségeket takar á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ék A pluralitás érték

Márkus válasza l l 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 l 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 l l l 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 l Az informatika helyzete a fenti szempontból tekintve analóg a természettudományokéval. l l l 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 l l 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: SET @int. User. Id = @@ROWCOUNT (thedailywtf. com - 2006. 01. 24. - a nap vicce)

A formalizáció megértése azonban mindig egy nemformális megértési háttérbe ágyazódik l l l 1. A programozó a formális rendszert annak funkciója felől megközelítve érti meg. l 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) l 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 l 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) l l l 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: l l 1. 2. A felhasználó „problémájának” a megértése A más által írt formális rendszer megértése

1. A felhasználó problémájának a megértése l l 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 l l l 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 l l l 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 l l l 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 l l l 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 l l l 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 (e. Xtreme 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 l l 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 l l 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