Prolog nezmizel. Jeho hlavní myšlenku dnes potkáváme v nástrojích, které se Prologu na první pohled nepodobají: v CodeQL pro analýzu kódu, v Rego pro policy-as-code, v Z3 pro práci s omezeními a v Leanu pro formální důkazy. Každý řeší jiný problém, ale všechny připomínají totéž: někdy je lepší popsat vztahy, pravidla, omezení nebo tvrzení než vrstvit další if.
Většina AI agentů v roce 2026 vám nabízí pohodlí výměnou za kontrolu — běží na cizí infrastruktuře, ukládají vaše data neznámo kam a fungují jen tak, jak je jejich tvůrci navrhli. Hermes od Nous Research jde opačným směrem: je open-source, nainstalujete si ho na vlastní server za pár dolarů měsíčně, připojíte k libovolnému LLM a necháte ho, aby si sám psal vlastní schopnosti podle toho, co od něj potřebujete. Výsledek? Agent, který skutečně patří vám a po pár týdnech používání rozumí vašemu setupu lépe než kterýkoli komerční asistent. Podívejme se, co Hermes umí, jak ho rozjet a pro koho dává smysl.
Robots.txt zůstává základní signál pro slušné crawlery, ale už neumí popsat hlavní problém: stejný veřejný obsah může sloužit klasickému vyhledávání, AI odpovědím, tréninku modelů i načtení na pokyn uživatele. Provozovatel webu proto musí oddělit účel přístupu, ověřovat identitu botů, měřit dopad na infrastrukturu a u hodnotného obsahu řešit i vynucení pravidel mimo samotný robots.txt.
Timhle by se mel ridit kazdy programator, nejen javascriptar.
http://en.wikipedia.org/wiki/Cargo_cult_programming
Tezko zaklad uspechu, ale rekl bych, ze kvalita kodu souvisi mimo jine s kratkymi funkcemi. Tezko z deseti radku udelat pevne pravidlo, ale jak je celkem pekne ukazano v knize Clean code, neni od veci se o deset (osm, dvanact, vyberte si sam) radku snazit. A nebo jeste jinak: kazda funkce nad deset radku je misto, kde by se programator mel zamyslet: Delam tu jen jednu vec? Neni cas na refactoring? Neujizdi mi zanoreni podminek a cyklu uz moc doprava?
V zásadě s vámi souhlasím, jen upozorňuji, že je tam implikace, nikoliv ekvivalence. Pokud si vezmete dobrý kód, pak zjistíte, že funkce jsou buď krátké, nebo se jedná o strukturovaný kód (špagetový kód kde se nic neopakuje a neskáče se dozadu ani dopředu je tím nejlepším, co vás mohlo potkat). Čili dobrý kód je krátký, v tom s vámi bezvýhradně souhlasím. Jenže s opačným tvrzením, že krátký kód je dobrý, nesouhlasím. Bohužel odkazovaný článek je napsán stylem „chcete psát lepší kód? Tak piště kratší funkce!“, což je dle mého názoru a zkušeností nesmysl. Pokud špatný kód rozkouskujete tak stále zůstane špatným kódem. Právě proto jsem uvedl odkaz na Cargo Cult, protože právě tohle je krásný příklad – lidé, kteří věří, že jejich program bude lepší jen tím, že bude z krátkých funkcí. To je mylné přesvědčení a následování tohoto kultu naopak problém zhoršuje, protože ho skrývá. Pokud vás programování samo nepřivede k psaní krátkých funkcí, pak násilné kouskování jen přidělává chyby a problémy. Program se totiž musí členit logicky a přirozeně, nikoliv po 10 řádcích. Pokud někdo program dělit neumí, tak ať ho raději nedělí.
…čirou náhodou nástroje speciálně pro JavaScript, které z deseti tisíc řádků udělají řádek jeden? ;-))
To s tím vůbec nesouvisí, jde o čitelnost kódu pro programátora a jeho snadnější pochopení a následné provádění přesných a lokalizovaných změn.
Sám se snažím o to, aby funkce (metody) dělali jen jednu věc a pokud ta věc nejde udělat jednoduše (10 – 15 příkazů, volání), tak ji rozdělím na více dílčích částí (klasická analýza) a tu pak zase řeším jednoduše. To samé v objektovém návrhu, pokud potřebuje objekt ke svému životu enormě velké množství informací, je dobré jej rozdělit na několik dílčích objektů. Většinou se dostanete tak do max. 1. a 2. úrovně zanoření v objektovem modelu a při voláni funkcí (metod) max. do 3. az 4 úrovně.