Ewa Drygalska, Anna Marjanowska: Jako filozof i medioznawca pracujesz na Wydziale Fizyki, Astronomii i Informatyki Stosowanej UJ, zajmując się kwestiami bardzo dynamicznie rozwijającej się rzeczywistości wirtualnej i rozszerzonej (virtual / augmented reality). Twój doktorat dotyczył software studies, czy mógłbyś rozjaśnić nieco ten termin?
Jan K. Argasiński: Software studies to „studia nad oprogramowaniem”, prowadzone z perspektywy filozoficznej, kulturoznawczej, nauk o społeczeństwie. Dziedzina badań, o której mowa, jest specyficzna, bo wbrew intuicji nie dotyczy technicznych problemów związanych z pisaniem i działaniem kodu (tym zajmuje się nauka ścisła, jaką jest informatyka, czyli computer science), lecz raczej jego kulturowych korzeni – zarówno w aspekcie historycznym, jak i z punktu widzenia zjawisk zachodzących współcześnie. Uprawianie jakiegokolwiek rodzaju studies nie jest rzeczą łatwą, ponieważ o ile np. informatyków interesuje przede wszystkim perspektywa „rozwojowa” (jak robić rzeczy szybciej, wydajniej, skuteczniej, dokładniej), o tyle studia nad oprogramowaniem obejmują swoim zakresem całościowy obraz zjawiska komputeryzacji: skąd się wziął hardware i software, jakie kulturowe i historyczne uwarunkowania doprowadziły do jego pojawienia się, czym on jest z punktu widzenia twórców i użytkowników oraz, co chyba najintensywniej eksplorowane przez fundatorów dziedziny, jakie są szeroko rozumiane skutki jego działania – nie tylko w wymiarze finansowo-technologicznym, ale społecznym, kulturowym, filozoficznym właśnie. Panuje tu bardzo duża różnorodność metodologiczna i merytoryczna. Wspólne jest zainteresowanie oprogramowaniem w perspektywie innej niż inżyniersko-matematyczna.
Jak w tym kontekście zdefiniować by można oprogramowanie?
Komputerowe oprogramowanie, czyli software, nie posiada, o ile mi wiadomo, ścisłej definicji. Znany teoretyk informacji Luciano Floridi pisał, że „jest to z grubsza wszystko to, co komputer potrafi zrobić”. Najczęściej spotkamy się ze stwierdzeniem, że programy to konkretne sformułowania abstrakcyjnych algorytmów, działające na określonych, ustrukturyzowanych danych.
Kiedy mamy do czynienia z pojęciem „oprogramowania”, natychmiast pojawia się interesujące napięcie między statycznym zapisem, kodem źródłowym a działaniem.
Programy bowiem ostatecznie służą raczej do tego, aby zostać uruchomionymi na sprzęcie, zrobić coś. Intuicja jest taka, że statyczny zapis kodu źródłowego to w takim samym stopniu oprogramowanie jak nieczytana przez nikogo, leżąca na półce książka to literatura. Analogia ta nie jest jednak doskonała – aby rzecz wyjaśnić, musielibyśmy powiedzieć co nieco o tym, skąd wziął się software i jak konkretnie on działa.
Jaka jest historyczna geneza oprogramowania i w jaki sposób maszyna ( „metal”) sprzęga się z kodem źródłowym?
Komputery to konkretne urządzenia. Bardzo upraszczając, można powiedzieć, że aby coś było komputerem w klasycznym rozumieniu tego słowa, musi realizować abstrakcyjny, matematyczny model działania nazywany od nazwiska swojego wynalazcy maszyną Turinga. Maszyna, a za nią urządzenia będące różnego rodzaju praktycznymi implementacjami zaproponowanego przez matematyka modelu komputacji, musi być w jakiś sposób zaprogramowana – tzn., że do działania potrzebuje pewnego zbioru instrukcji / poleceń / rozkazów opisujących, co ma zrobić, kiedy „natrafi” na jakiegoś rodzaju dane. W świecie abstrakcji, aby opisać program, wystarczy nam odpowiednia formuła matematyczna. Jeśli jednak zbudujemy fizyczny komputer, czyli przejdziemy do konkretu, to będziemy musieli go zaprogramować zgodnie z jego budową – jeżeli będzie miał on np. postać urządzenia mechanicznego, działającego na przekładniach i trybikach, to nasz kod stanie się sekwencją ustawień tych trybików i przekładni. Głównie z powodów wydajnościowych dzisiejsze komputery ewoluowały od urządzeń mechanicznych (jeszcze z czasów sprzed idei Turinga), przez elektryczne giganty, po współczesne zminiaturyzowane układy elektroniczne, które umożliwiają bardzo szybkie przetwarzanie dużych ilości danych. Skonstruowany komputer powinien też mieć jakąś architekturę, tzn., że przemyśleć należy kwestie związane z tym, gdzie przechowywać dane i jak je przetwarzać, a więc z komunikacją wewnątrz urządzenia.
Architektura wyraża sposób wewnętrznej organizacji maszyny. Czy kolejne modele komputerów będą miały zupełnie inną organizację, która może zmieniać się wraz z rozwojem technologii?
Wewnętrzna organizacja komputerów zmienia się nieustannie, sprzęt nie przestaje ewoluować. Trzeba pamiętać, że koncept Turinga jest ważną ideą teorii obliczeń, natomiast nie za dobrze opisuje działanie konkretnych, współczesnych komputerów, które są naprawdę bardzo złożonymi urządzeniami, przetwarzającymi i magazynującymi dane na niezliczoną ilość sposobów. Jedną z pierwszych architektur opracował w połowie lat 40. ubiegłego wieku John von Neumann. W zaproponowanym przez jego zespół systemie urządzenie miało składać się ze skończonej i funkcjonalnej listy rozkazów, mieć możliwość wprowadzania programu przez zewnętrzny interfejs i jego przechowywania w taki sam sposób jak wszystkich innych danych w pamięci komputera. Genialny pomysł! Program nie będzie wbudowany w jednostkę obliczeniową (co oznacza jej każdorazową „przebudowę”, a przynajmniej zmianę połączeń wewnątrz urządzenia za każdym razem, kiedy chcemy zmienić program), lecz będzie częścią danych. Podstawowe urządzenie musi tylko umieć czytać dane programu, a informacje na temat dalszego działania „doczyta” sobie w czasie pracy. W tym miejscu powinno już zacząć stawać się jasne, czym jest oprogramowanie – kod, informujący jednostkę obliczeniową o tym, jak ma działać, wraz z danymi, które ma przetworzyć. Stanowi on najczęściej implementację jakiegoś algorytmu – abstrakcyjnego, opisywalnego matematycznie sposobu na efektywne rozwiązanie danego problemu obliczeniowego.
Dlaczego zatem nazywamy językiem czy językami programowania coś, co ma typową matematyczną i mechanistyczną strukturę?
Współczesne tworzenie software’u w bardzo niewielkim stopniu przypomina matematyczne formuły opisujące maszyny Turinga czy pracę na „gołym” procesorze. Żeby to zrozumieć, trzeba przyjrzeć się temu, jak dzielą się współczesne języki programowania. Jeśli zbudujemy hierarchię opartą na kryterium swoiście rozumianej abstrakcyjności języka, to na samym dole będziemy mieć języki niskiego poziomu – na początku kod maszynowy, który ma postać praktycznie bezpośrednio wykonywalną przez procesor. Ponieważ dane na naszych komputerach przechowywane są w postaci najprostszej – binarnej, to będzie on miał formę zer i jedynek. Nie trzeba chyba podkreślać, że tak zapisany kod jest praktycznie nieczytelny dla człowieka, również ze względu na swoją długość. Należy pamiętać, że taki kod jest „przy metalu”, tzn. dopasowany do konkretnego urządzenia – tego, a nie innego rodzaju procesora.
Nieco wyżej w hierarchii abstrakcyjności znajdują się języki asemblera, gdzie elementarne operacje zostały zastąpione mnemonikami, co powoduje, że kod staje się nieco bardziej czytelny. Asemblery pozostają jednak nadal bardzo blisko sprzętu i pisanie w nich nie należy do czynności łatwych i przyjemnych, a powstające programy nie są uniwersalne (za to można uzyskać bardzo dobre rezultaty wydajnościowe i pisać kod „dedykowany” dla konkretnego urządzenia). Ogromna większość software’u jest jednak pisana wysokopoziomowo. Oznacza to, że do wyrażania poleceń używa się języka, który został opracowany w taki sposób, aby ułatwić pracę programistom. Dopiero po napisaniu kodu źródłowego jest on tłumaczony przez specjalny program (kompilator) na język maszynowy, który da się uruchomić na urządzeniu. Idea takiego sposobu pracy pojawiła się dość wcześnie, wraz z pierwszą falą przemysłowo-badawczych urządzeń komputerowych. Dzięki powstaniu języków wysokiego poziomu programiści mogą w znacznym stopniu abstrahować od sprzętu, na którym będzie uruchamiany rezultat ich pracy.
Języki wysokiego poziomu stają się więc czymś na kształt języków naturalnych – mają swoje wyrażenia, składnię, służą do komunikacji (również międzyludzkiej), mogą być środkiem ekspresji.
A programista może mieć swój styl pisania.
Jak ma się zatem „językowość” języków programowania do charakteru tych naturalnych? Czy relacja między nimi może być przyczynkiem do uruchomienia krytycznej, humanistycznej refleksji o konsekwencjach projektowania i zastosowania konkretnego oprogramowania? Czy kluczem do otworzenia nowej perspektywy może okazać się interdyscyplinarność badań prowadzonych zespołowo pomiędzy humanistami a przedstawicielami nauk ścisłych?
Rzecz jest bardzo interesująca. Jednym z historycznych źródeł, z którego wypływa informatyczny sposób myślenia o świecie, jest marzenie o języku uniwersalnym – takim, którym mogliby się posługiwać wszyscy ludzie, ale też – co dla nas ważniejsze – takim, który byłby jednoznaczny. Umberto Eco w wyśmienitej książce na ten temat (Poszukiwanie języka doskonałego w kulturze europejskiej) prezentuje możliwość wywiedzenia takiego sposobu myślenia od zarania człowieczeństwa z mitologicznego Raju (a być może i od aktu stworzenia świata), Neal Stephenson w kultowej Zamieci snuje opowieść o języku jako starożytnym wirusie z Babilonu… Można by o tym długo mówić, ale nie sięgajmy może tak daleko. Już u progu narodzin współczesnego światooglądu ludzie tacy jak John Wilkins czy Gottfried Leibniz marzyli o języku, który nadawałby się do „przetwarzania faktów”. Filozof z Lipska wyraził to wprost w idei characteristica universalis: języka, mającego działać na – jakbyśmy dziś powiedzieli – „frameworku” (calculus ratiocinator), rachunku umożliwiającym mechaniczne ( „komputacyjne”) wydobywanie prawd ze złożonych wyrażeń. Filozofowie, zamiast dyskutować, mieliby ustalać fakty, a następnie je obliczać. Calculemus! Wspaniała wizja.
Języki oprogramowania mają więc zakorzenienie w pewnym sposobie postrzegania świata. Jak już ustaliliśmy, możliwe jest dokonanie przejścia między tym, jak liczą maszyny, a tym, jak wyrażają swoje myśli ludzie, bez zerwania połączenia między tymi dwoma światami. Ogromna większość programistów pisze w językach wysokiego poziomu, czyli posługuje się tworem, który – zasadniczo – jest stworzony do tego, żeby ułatwić komunikację: zarówno między ludźmi (programistami), jak i człowiekiem a maszyną. Z tej perspektywy języki programowania wykazują pewne podobieństwo do języków naturalnych – to systemy reguł, które pozwalają tworzyć wyrażenia poprawne i sensowne. Są one oczywiście zwykle znacznie bardziej sformalizowane z tego powodu, że ostatecznie programy mają prawie zawsze służyć realizacji bardzo konkretnych, pragmatycznych celów. W pewnym sensie są one jednak takimi językami jak polski czy angielski. Takie postawienie sprawy może i powinno być punktem wyjścia do refleksji właściwej humanistom: sposoby i tryby mówienia, klasyfikowania, opisu zjawisk, język jako nośnik światopoglądu to przecież najbardziej klasyczne problemy badawcze humanistyki. Interdyscyplinarność wydaje się tu na miejscu ze względu na fakt, że zjawisko, o którym mówimy, ma genezę matematyczną, jest opracowywane przez inżynierów. Chcąc więc oddać mu sprawiedliwość, musimy dysponować kompetencjami (lub osobami kompetentnymi) w tym zakresie. Z tego m.in. wydaje się wypływać stwierdzenie kultowego medioznawcy Friedricha Kittlera, że współczesny kulturoznawca powinien znać przynajmniej jeden język programowania.
Wspomniałeś o oprogramowaniu jako formie ekspresji… Czy można już mówić o specyficznej estetyce software’u?To bardzo ważny wątek. Wielu ludzi, którzy związali swoje życie z tworzeniem oprogramowania, zauważa, że rozpatrywanie pisania kodu w kategoriach twórczości nie jest od rzeczy. Paul Graham, znana postać komputerowego świata, napisał…
