Ekonomie automatizace

Hodně lidí v poslední době ohrnuje nos nad termínem abstrakce, takže bych rád věnoval jeden článek připomenutí toho, proč je vymýšlení abstrakcí při programování nezbytné, aby to programování vůbec mělo nějaký smysl.

Nejběžnější hřích technonadšenců a programátorů zvlášt je, když zapomínají, že udělat něco pomocí automatu je nezměrně těžší, než to udělat ručně. Místo přímočarého vyřešení nějakého problému je nejdřív potřeba vyrobit stroj na řešení problému a teprve pak vyřešit problém s jeho pomocí. O kolik je to pracnější prakticky nejde přehnat.

Důvod, proč to přesto děláme, je, že tu obrovskou pracnost navíc doufáme amortizovat ve velkém množství dalších problémů, které už pro nás automat vyřeší sám. Z podstaty automatu jako stroje je však potřeba, aby všechny takové problémy byly naprosto stejné.

Háček je v tom, že už ve starověku si lidé všimli, že žádné dvě situace na světě nejsou úplně stejné, což od té doby vyjadřuje často nepochopené Hérakleitovo rčení “Nevstoupíš dvakrát do stejné řeky.” Ačkoli si to explicitně neuvědomujeme, realita obsahuje tolik detailů, že pravděpodobnost, že budou ve dvou problémech všechny stejné, je prakticky nulová.

Z tohoto pohledu by se tedy automatizace teoreticky nikdy nemohla vyplatit. Trik, který to řeší, je právě abstrakce. Hodně lidí má problém to pochopit, protože abstrakci chápou jako synonymum pro “generalizaci”, ale ve skutečnosti jsou to v jistém smyslu antonyma. Tohoto omylu si všiml už legendární E. Dijkstra a upozorňoval:

Smyslem abstrakce není být vágní, ale definovat nový sémantický rámec, ve kterém je možné se vyjadřovat naprosto přesně.

(The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.)

Abstrakce je způsob, jak nahlížet různé situace v nějakém smyslu jako exaktně stejné. Abstrakce vymezuje klíčové detaily onoho pojmu “v nějakém smyslu”. Generalizace, ve smyslu “zobecnění”, naproti tomu detaily pouze ignoruje.

Abstrakce je tedy to, co dovoluje amortizovat šílenou pracnost automatizace. Jasně z toho vyplývá objektivně správná motivace designovat abstrakce co nejširší, aby se pracnost rozložila na co nejvíce řešených problémů, jen nás nesmí dovést až k té generalizaci, kdy ignorování detailů před abstraktním rozhraním vede jen k tomu, že je s nezmenšenou pracností musíme řešit až za ním.

Hodně se poslední dobou řeší, jestli máme v programování abstrakce málo nebo moc a jak to hodnotit. Moje odpověď je, že program musí v první řadě tvořit dobrý model řešeného problému a to se nedá hodnotit žádným jednoduchým pravidlem, stejně jako se to nedá posoudit z jednotlivostí třeba v sochařství. Jistě, přirozeným měřítkem může být doslovná podobnost modelu s realitou, ale jak se říká, nejlepším modelem kočky je kočka a nejlépe ta samá, jenže takový model je k ničemu, že? V tomto smyslu je programování podle vzoru sochařství skutečně uměním.