Jinak ještě k DRY. Ono je rozdíl copy pastovat a inlinovat výpočetní funkce alá potřebuju z cesty extrahovat file extension, spočítat kořeny kvadratický mocniny apod. Prostě něco, co je daná logická operace a výsledek bude vždycky stejný. Tady kopie jen trochu nafukuje zdroják nic moc horšího se neděje.

A pak jsou věci jako třeba visuální komponenty, kde je účelný mít jednodtný vzhled a chovaná. Takhle jsme měli v jednom projektu rozkopírovaný určitě vic než 10x kód pro Modal dialog. Markup pro title, close button a css k tomu. A bylo to docela neškovný. A sjednotit se to nikomu dlouho nechtělo protože ten copy paste nebyl jen copy paste, ale občas v tom byla nějaký změna. Příliš komplikovaný to řešit v rámci tasku a sahat na různý místa v aplikaci co potřeboval další modal. Takže ho člověk zase zkopíroval :)

Když to tady probíráte, tak já si teda Copilota nemůžu vynachválit. Dělám primárně Python, kde Copilot výrazně usnadňuje takový nějaký prototypování (vhodně pojmenuju funkci a on ji prostě vymyslí), případně refactoring, různý mechanický činnosti (třeba nejaký enumy - začnu, napíšu první dvě položky a on vygeneruje zbytek), dobře mu jde naopak i dokumentace už existujícího kódu i překlady v .po souborech...

Je toho dost, ale snažím se ho usměrňovat i opravovat, on se z toho poučí a pak na konkrétním projektu funguje líp a líp. Plus celkem fajn funguje na různých konfigurákách, to jsem byl docela překvapenej a hodně to používám. Kdo si má všechny ty opšny pamatovat :-)

Takže za mě dobrý pomocník, jo a máme nějakou takovou tu placenou verzi.

JARDABEREZA: když vís co chceš psát tak je to super a zrychluje to práci. V tohle má junior trochu nevýhodu.

Já nevím co s tím děláte vy, ale mě mě to na kontrolu vstupních parametrů nebo psaní chybových hlášek funguje dobře. U těch 1-3 řádkových věcí to často doplní stejnou věc, co bych dělal já. Občas i lepší. A když ne... stejně to píšu ručně, tak to dopíšu.

Zrovna včera jsem si třeba říkal: "To je blbost v tom CLI argumentu přeci musí být mezera, je to typo, dám jí tam". No a nebylo, když jsem jí smazal tak to začalo fungovat :-D

Na React a Redux mi to přijde dost dobrý... těch patternů je plný GitHub.

Ale třeba UXP je bída... Adobe k tomu nenapsalo ani pořádnou dokumentaci a fora jsou plná otázek, kde se ptají proč tenhle kod nefunguje, ale správných odpovědí je méně :-D

A jako někdo, kdo nikdy nedělal s C++ to bylo super. Potřeboval jsem jenom poslepovat pár hotových knihoven dohromady a ušetřilo mi to hodiny/dny času. Např. co kde nastavit ve Visual Studiu atd.

JARDABEREZA:

No zrovna u těch programovacích asistentů to je spíš vývoj od "wow" k "to jsem rád, že za tenhle shit platí fabrika a ne já".

LUDWIG_: Ono je to strašně zrádné ty odhady. Lidi jsou naučení posuzovat pokrok lineárně. Když dneska postavím jeden metr zdi, tak zítra to jsou dva metry, za týden 7, a za měsíc 30 metrů. Ale v technologiích jde vývoj spíše exponenciálně než lineárně.

Tři roky zpět jsem generoval první obrázky ve Stable Diffusion 1.0 a ty lidi vypadali většinou jako mutanti a nízký rolišení. Fakt špatný. Pak jsme s smáli, že mají deformované končetiny. Potom prsty a text. A dneska to kolikrát člověk nepozná jestli to je fotka nebo ne.

To samé pozoruji u videí. 2025 bude pro filmaře hodně zajímavý. To co tenhle týden ukazuje Sora jsem čekal o pár let později.

JARDABEREZA:
To jsou dve otazky: s tim videem ohledne problemu soucasnych abstrakci v programovani souhlasim. Odkazovany https://dl.acm.org/doi/abs/10.1145/3563836.3568723 je docela zajimavy smer.

Ohledne toho, jestli AI nahradi programatory: Pred 1-2 lety bych rekl, ze do par let mozna tak juniory. Po tom, co jsem zkousel
https://githubnext.com/projects/copilot-workspace ,
mohu rict, ze i junior programatori muzou byt v dohledne dobe v klidu :)

VOY: Jo jo, ja mam soukromy projekt "copycat" kde mam presne ty ruzne kousky (nekdy i cele tridy) co pak nekam jen pastnu a mam vymalovano :-)

VOY: jj, duplicitni kod nemusi byt nutne zlo; v linux kernelu taky je.
Pamatuji si, ze byly studie ohledne dopadu duplicitniho kodu jako https://dl.acm.org/doi/10.1155/2012/938296

Muze se treba stat, ze je duplicitni kod v ruznych castech slozity codebase; za pul roku je potreba zmenit neco v jedne casti a paradoxne muze byt jednodusi zmenit duplicitni kod v jedny casti, nez kdyby se to menilo v abstrahovany spolecny casti, co pak bude muset pokryvat ty budouci zmeny specificke pro nesouvisejici casti systemu.

Tim neobhajuji duplicitni kod jako takovy; v hodne pripadech je to spis prasarna a usetri cas to sloucit. Jen rikam, ze jsou vyjimky ci je to pripad od pripadu.

AMBIENTIUM: a bit of copy paste is sometimes better than a lot of dependency.

AMBIENTIUM: Videl bych tam urcitou miru volnosti. Proste uz tolik neziju nabozenstvim toho, ze zadny blok kodu se nesmi opakovat a vsechno musi byt odabstrahovany. Nekdy se to lip cte kdyz to tam proste inlinujes. To je taky hodnota. Zvlast ted s LLM bude, myslim si, mozny si v tomhle vic dovolit. Your mileage may vary.

VOY: Není spíš smysluplný porušit dry jen v momentě, kdy nechceš, aby ty dva kódy byly závislý na tom společným a byly upravovatelný a rozšiřitelný nezávisle na sobě?

Zaroven si uz taky uplne nemyslim, ze vsechno musi byt DRY. Nekdy je proste lepsi se radeji opakovat nez furt neco zobecnovat a abstrahovat.

TOOMIX: I to ovsem stoji na to, ze se tam kazdy podiva a vi o tom. To je proste uskali toho, ze mas na neco nejaky vylesteny tridy a helpery, musis mit tym kde je dobra komunikace a vsichni to vedou v patrnosti. Nevim o nastroji nebo metode co by tohle dovedla vynutit.

JARDABEREZA: na tohle máme sepsanou konvenci kde je tohle všechno popsaný (a pravidelně aktualizovaný). Když to je nějaká novinka co tam nestojí dávat, ale i tak život ulehčí, máme to v YouTracku v Knowledge base