Geniusze i idioci

Utworzono: środa, 08 luty 2012 08:57

Poprawiono: środa, 24 sierpień 2022 10:57

Odsłony: 43340

Od kiedy zacząłem zajmować się informatyką, co nastąpiło z początkiem lat 1960., miałem poczucie, że o informatyce można mówić w sposób zrozumiały. Zawsze też byłem przeciwny takim kwalifikacjom jak „komputerowy geniusz” — na określenie ludzi, którzy nie potrafią mówić o informatyce w sposób jasny, lub też „komputerowy idiota” — odnoszący się do ludzi, którzy komputerowych geniuszy nie rozumieją.

Informatyka nie jest ani trudniejsza, ani łatwiejsza od mechaniki, elektroniki czy chemii, a posługiwanie się będącymi w powszechnym użytku narzędziami informatycznymi w rodzaju edytorów tekstu, arkuszy kalkulacyjnych, systemów obróbki zdjęć czy choćby telefonów komórkowych, nie jest trudniejsze od prowadzenia samochodu, czy żeglowania po Mazurach. Jednakże, podobnie jak w przypadku samochodu i żaglówki, aby się tymi urządzeniami posługiwać, trzeba się tego nauczyć. Tymczasem wśród użytkowników „codziennej informatyki” od lat obserwuję dwa sprzeczne ze sobą stanowiska:

• ja się tego nigdy nie nauczę,
• nie będę czytał podręcznika, sam sobie jakoś poradzę.

Czy ktoś mógłby sobie wyobrazić przyszłego kierowcę, który uważając, że prowadzenia samochodu nigdy nie opanuje, jednocześnie siada do niego i wybiera się na ruchliwą autostradę? Pewnie byłoby to trudne, jednakże dokładniejsza analiza takiego zachowania na gruncie informatyki stosowanej wskazuje, że nie jest ono do końca irracjonalne, gdyż zostało wymuszone przez następujący stan rzeczy:

• podręczniki systemów komputerowych są równie grube co nieczytelne,
• systemy komputerowe są nam niezbędne do pracy.

Osoby, które wierzą, że świat dzieli się na komputerowych geniuszy i komputerowych idiotów sądzą zapewne, że podręczniki, o których mowa, są niezrozumiałe jedynie dla idiotów. Zapewniam więc te osoby, że mimo iż informatykę zgłębiam od lat pięćdziesięciu, niewiele podręczników byłem w stanie przeczytać ze zrozumieniem. I niezależnie od tego, czy był to podręcznik edytora tekstu, czy zaawansowanego języka programowania, czy opisywał on produkt komercyjny, czy też dostępny w domenie publicznej, najczęściej charakteryzowało go zjawisko, które Anglicy określają w niezbyt elegancki sposób jako „rozwolnienie mowy przy zatwardzeniu myśli”. Mówiąc mniej alegorycznie, był niezwykle rozwlekły, a przy tym bardzo nieprecyzyjny i — co jeszcze dziwniejsze — przy swej rozwlekłości również dalece niekompletny. Aby wyjaśnić to zjawisko w sposób obrazowy posłużę się analogią z zakresu kuchmistrzostwa. Podręcznik gotowania obejmuje zwykle trzy rodzaje wiedzy:

• wiedzę o surowcach, a więc o składnikach, z których tworzy się potrawy,
• wiedzę o potrawach, a więc o tym, czym one są i jakie powinny mieć cechy,
• wiedzę o narzędziach i sposobach tworzenia potraw z surowców.

Autor podręcznika zakłada też zwykle, że jego czytelnik przeszedł już szkolne kursy botaniki, chemii i fizyki, więc wie, na przykład, czym się różni liść od korzenia, co to jest sól i woda i po czym poznać, że woda się gotuje. W swoim podręczniku zawiera więc jedynie tę wiedzę, która wykracza poza podstawową oraz — co bardzo ważne — pisze o gotowaniu, a nie o „posługiwaniu się kuchnią”, albo — co jeszcze gorzej — o „obsłudze kuchni”.

W odróżnienia od mistrza kucharskiego, mistrz (geniusz) komputerowy pisze swój podręcznik przy założeniu, że jego czytelnik nie wie nic ani o składowych produktów, które będzie tworzył, a także nie rozumie do końca jakie tworzy produkty. Wie jedynie jak wyglądają one na monitorze komputera. Geniusz komputerowy wychodzi dodatkowo z założenia, że swojego czytelnika (oczywiście komputerowego idioty) i tak żadnych podstaw nie nauczy, wypełnia więc podręcznik listami ruchów, jakie należy wykonać, aby osiągnąć określony obrazek na monitorze. Opisuje sekwencje kliknięć nie troszcząc się o to, by jego czytelnik wiedział, co tak na prawdę robi. Zresztą niejednokrotnie odnoszę wrażenie, że sam autor, ma o tym dość blade pojęcie.

Dla przykładu, w większości podręczników języków programowania, które czytałem, każdy element programu nazywany jest „instrukcją”, bez względu na to, czy jest to rzeczywiście instrukcja, czy też deklaracja lub wyrażenie. I dotyczy to nie tylko podręczników takich pospolitaków jak Basic, ale też i takich arystokratów jak Delphi. Kiedyś przekopałem największą akademicką księgarnię w Nowym Jorku w poszukiwaniu napisanego profesjonalnie i dla profesjonalistów podręcznika języka Delphi, i takiego podręcznika nie znalazłem. A były tam podręczniki Delphi liczące po dwa tysiące stron!

Innym razem tworzyłem dla mojej firmy bazodanowy system obsługi logistyki dostaw. Obserwując własne zmagania ze służącym mi do tego narzędziem oceniłem, że około 60% czasu poświęcałem nie na projektowanie architektury systemu, ale na mocowanie się ze składnią języka, która nigdzie nie była jasno opisana. O tym jaka jest dowiadywałem się jedynie z przykładów, które jednak nigdy nie wyjaśniały ogólnej zasady. Podejrzewałem nawet, że być może takiej zasady w ogóle nie było! Bo czym wytłumaczyć fakt, że w jednych instrukcjach parametry oddziela się od siebie przecinkami, a w innych — średnikami. Chyba tylko tym, że jedną instrukcję zaprojektował John, a drugą Bob. O tym, aby składnię języka opisać — jak w latach 1960. — gramatyką bezkontekstową, oczywiście nie mogło być mowy. Myślę też, ani John ani Bob w ogóle o takich narzędziach nie słyszeli.

Z opisem semantyki (znaczenia) przy pomocy przykładów też nie było lepiej. Tu z kolei przypominała mi się anegdota o kimś, kto starał się wyjaśnić zasady języka niemieckiego w sposób następujący:

Posłuchaj — mówił — język niemiecki jest bardzo prosty. Na przykład „dzień dobry” to „guten Tag”, a „do widzenia” to „auf Wiedersehen”. No i tak dalej.

Gdy kupiłem pierwszą wersję edytora Word, spędziłem wiele dni na kilkakrotnym czytaniu podręcznika użytkownika, by wśród powodzi historyjek o klikaniu znaleźć to, co istotne. Znakomicie pomogła mi w tym znajomość profesjonalnych systemów składu komputerowego TeX i LaTeX, których używałem już od kilku lat. Kiedy odcedziłem ziarno od plew, postanowiłem zapisać tę wiedzę w krótkim podręczniku komputerowej edycji dokumentów. Napisałem go nie tylko dla siebie, ale przede wszystkim dla pracowników firmy A.Blikle. Postawiłem sobie wyzwanie napisania podręcznika dla odbiorcy, który co prawda odróżnia myszkę od klawiatury, ale nie ma żadnej głębokiej wiedzy informatycznej.

Podręcznik istnieje do dziś, zawiera około 60 stron tekstu w formacie A4 i obejmuje wszystkie najważniejsze narzędzia Worda służące do edycji dokumentów elektronicznych. A rozpoczyna się od wyjaśnienia czym jest dokument (produkt) i czym są tzw. style (główne narzędzia) oraz jak z tych narzędzi korzystać. Ta wiedza, przekazana moim pracownikom, pozwoliła na wprowadzenie jednolitego standardu dla wszystkich tworzonych w firmie dokumentów. Było to możliwe, gdyż dzięki stylom postać graficzna dokumentu (wielkość i krój czcionek, odstępy pionowe i poziome, kształt tabelek itp.) jest w dużej mierze automatycznie utrzymywana przez system przy niewielkiej jedynie ingerencji piszącego.

W ciągu ostatnich blisko dwudziestu lat widziałem tysiące nieporadnie pod względem typograficznym napisanych dokumentów i jedynie może kilkadziesiąt napisanych poprawnie. W tych kilkudziesięciu używano stylów w sposób świadomy. W pozostałych, autorzy nie mieli o stylach zielonego pojęcia.

Więcej o moim podręczniku piszę na stronie Komputerowa edycja dokumentów. Tam można go też pobrać.