Programování je matematika

Když jsem byl mladší, interpretoval jsem vzdělávací a podvědomou spojitost programování a matematiky tak, že “programování je jako matematika” - čísla, exaktnost, logické myšlení a tak. Tato chyba byla následkem dvou drobností. 1. Nevěděl jsem, co je matematika a 2. Nevěděl jsem, co je programování. Teď, když po vysoké škole a 15 letech praxe začínám chápat základy obou oborů, mi pomalu dochází, že “programování je matematika”.

Čísla a počty

Matematiku se všemi jejími podobory, které mezi sebou mají na první pohled asi tolik společného jako papoušek z amazonského pralesa se skvrnami na slunci, jsem začal chápat, až když mě nekdo seznámil s konceptem matematiky jako vědy o modelování. Ne o modelování nějakého konkrétního aspektu reality, tomu se věnují všechny ostatní vědy, ale o modelování jako takovém, o metodách modelování samotných.

V tomto pojetí je jednoduché pochopit, že cíl algebry, analýzy, geometrie, topologie, teorie kategorií, grafů, informace, nebo množin je jedna a ta samá věc - vyvíjet myšlenkové nástroje pro modelování reality v naší hlavě. Realitu samotnou si do hlavy nacpat nemůžeme a proto potřebujeme koncepční rámce, se kterými naše hlava pracovat dokáže. Jelikož jsou takové rámce vždy pouze přibližné, můžeme jich vymyslet kolik chceme. Že tím má matematika mnohem blíže k filosofii než k účetnictví si pro její asociaci s čísly a počty ze základní školy bohužel uvědomuje málokdo.

Hlavní kritérium dobrého kódu

K nalezení esence programování jsem na rozdíl od matematiky došel sám, když jsem mnohokrát přemýšlel, co bych měl vlastně sledovat v code review. Jistě, ideální by bylo odškrtnout si všechny fajfky - code style a jiné lintery, DRY princip, design rozhraní, Linusovo “good taste”, literární principy… Ale jak při takovém množství éterických a často subjektivních hodnocení nesklouznout ke kodérskému fašismu? Vždyť i ten jednoduchý DRY princip může být validně zpochybněn. (Díky Lubošovi za český překlad.)

Zkusme příklad ambivalence DRY principu rozvinout dále. Podle jakého pravidla rozhodnout, zda je duplikace zbytečná a abstrahovat problém žádoucí nebo naopak? Existuje nějaké kritérium alespoň o trochu objektivnější, než “jednoduchost”, “pochopitelnost”, “čitelnost”, “přehlednost” nebo “flexibilita”, kterými se při code review běžně oháníme? Ano, existuje, pokud si uvědomíme, že program je modelem řešeného problému.

Obecně odpovídat na otázku, zda je abstrakce správná nebo předčasná je nesmysl. Je možné ji odpovědět pouze ve vztahu k realitě, kterou má modelovat. Abstrakce nemusí být předčasná i když má jen jedno použití a zároveň může být nesprávná i při deseti výskytech, jestliže je jejich podobnost v realitě pouze akcidentální. Že je takové rozhodování netriviální a zcela závislé na každé jednotlivé situaci vystihuje jedna z (hlavně javovských) základních pouček “prefer composition over inheritance”. Je to reakce na zjištění, že “zvíře” nemusí být jediná abstrakce, jak chceme nahlížet na “psa” i když to tak na první pohled vypadá.

Na podobných příkladech jsem si uvědomil, že fundamentální základ mojí snahy v code review je posoudit, zda je kód dobrým modelem zpracovávané reality. Čím lépe totiž model vystihuje realitu, tím méně hrozí, že nějakou nepředvídanou reálnou situaci nebudeme v modelu umět vyjádřit a budeme muset prasit. Z druhé strany zase platí, že čím lépe model vystihuje realitu, tím pravděpodobnější je, že pochopení získané díky jeho zjednodušením bude fungovat i zpátky v realitě. To je důležité pro obrovský přínos, který představují moderní vývojářské nástroje.

O modelování a jeho kvalitě jsme v programování zvyklí přemýšlet primárně v kontextu datového modelu a jeho normálních forem případně o něco šířeji v domain driven design, ale ve skutečnosti celý program, každé jeho slovo, je model. Doménové entity jsou modelem domény, ale program musí modelovat i svou podružnou realitu - uživatelské rozhraní, paralelismus, runtime životní cyklus svých částí, vývojový životní cyklus svých částí, exekuční plán a bambilión dalších. Pro všechny oblasti existuje spektrum modelovacích technik, programátor musí 1. vybrat techniku vhodnou pro danou situaci, 2. modely všech oblastí zintegrovat do jednoho celku.

Pracovat s modelem znamená myslet

Jak vytvořit, ohodnocovat a skládat modely reality? To umění se nazývá myšlení a právě matematika se jím zabývá už několik tisíc let a rozhodně to nevypadá jako vyřešený problém. Modelování začíná u slov identifikace a reflexe. Kdysi na škole jsem neměl nejmenší tušení, proč jejich vysvětlováním a diskuzí nad nimi ztratil profesor matematiky několik hodin bez zjevného užitku. Teď to začínám chápat a chtěl bych to předat dál: programování je matematika.

Diskuze

Několik lidí v diskuzi k tomuto článku poukázalo na rozdíl mezi popsanými vzletnými ideály a přízemní realitou.

nebo

https://twitter.com/mikealdo007: škoda, že nám víc podobných pohledů vůči realitě nenabídli profesoři na vejšce, kde jsem si pár semestrů říkal - "to je sice pěkný, umět na A4ku vyšvihnout řešení trojného integrálu, ale to reálné použití pro normálního smrtelníka je jako kde?". Motivace ke studiu by pak byla určitě větší. K tomu se člověk asi taky musí propracovat sám ...

Tento článek jsem nenapsal proto, že neznám realitu výuky matematiky, ale právě naopak. Chci všem připomenout souvislost matematiky a programování, kterou jsem já sám musel zjistit až na vlastní pěst. Dělám to s cílem připomenout tuto podstatu jak matematikům, tak programátorům, aby se ty obory přestaly vzdalovat ve jménu každodenní praktičnosti a selského rozumu, které tlačí průmyslová loby a amatérští hobisté (bez jakéhokoli pejorativního významu).

Mimochodem případ integrálů je exemplární v nesouladu mezi smyslem a populárním obrazem matematiky. Možná o to někdy zkusím tenhle článek rozšířit. Ale nejsem si jistý, jestli by to mělo smysl, protože nejlepší pokus o to, který jsem sám viděl, má rozměr celé divadelní hry: geniální kus Toma Stopparda Arkádie.

VALENTINE: It’s how you look at population changes in biology. Goldfish in a pond, say. This year there are x goldfish. Next year there’ll be y goldfish. Some get born, some get eaten by herons, whatever. Nature manipulates the x and turns it into y. Then y goldfish is your starting population for the following year. Just like Thomasina. Your value for y becomes your next value for x. The question is: what is being done to x? What is the manipulation? Whatever it is, it can be written down as mathematics. It’s called an algorithm.