Vlákno názorů k článku Našeptávač: šikovný rádce, který má na práci 50 milisekund od Ondřej Novák - Hezky, těžko dokážu posoudit, zda pro tak jednoduchý...

Hezky, těžko dokážu posoudit, zda pro tak jednoduchý nástroj je takové řešení dostatečně (nebo až příliš moc) komplexní.

Co se mi "líbí" (píšu subjektivní názor) poslední dobou, je nadužívání "technologií" a někdy začínám mít obavu, že většina programátorů jsou obyčejní "skládači" existujících řešení. Takže když na mě někdo vyběhne se seznamem technologií, který má několik desítek řádek, mám z toho pocit, že jde spíš o montovače skříní z Ikea, než programátory (který umí udělat skříně na míru z dodaného dřeva). A pak se něco někde podělá a místo hledání chyb člověk jen bombarduje supporty správců těch technologií. (vlastní zkušenost)

Ale asi je to levnější.

Tak programování je právě o tom poznat, kde je vhodné použít existující technologie a které.

heh. Kuli tomu nejeden odesel z EE sveta bastlit drivery a radice. Nicmene spravně poslepovat spraveně zvolene techologie vyzaduje hodne zkusenosti a nebo extreme schopne vedeni ktere to dokaze z kazdeho zamestannce tu jeho zkusenost spraven extrahovat a zvazit.

To je dobře, že spousta základních věcí už je vytvořených a běžně dostupných, takže teď už na to může naběhnout spousta vývojářů a začít z těch základních kamenů skládat skládačky pro nejrůznější použití. Díky tomu může ty technologie používat mnohem víc lidí.

S tím bych neměl problém, kdybys často nestál před rozhodnutím, kdy potřebuješ jednu věc a je těžké najít technologii, která sice dělá tisíce několik věcí, ale tu jednu věc co potřebuješ ne tak jak bys potřeboval. A dostáváš se do situací, kdy vytváříš rovnáky a ohejbáky.

Každý problém je jedinečný. Na ty problémy, které už jsou vyřešené, nic programovat nemusíme

to ted vidavam docela casto.
jedna skupina programatoru se rozhodne, ze nebudou vynalezat kolo
a pouziji nejakou knihovnu.
druha skupina ma zase dojem, ze knihovna je moloch a tak si z ni vyextrahuji jen to co potrebuji a knihovnu zahodi.

Já mám zkušenost, že pokud je předpřipravené řešení "ne přesně tak, jak bych potřeboval", tak je to často proto, že člověk co psal zadání projevil příliš mnoho nezdravé kreativity a místo co by použil osvědčený design pattern, tak se pokusil vymyslet něco vlastního. Takže problém většinou vyřeší dotaz "A nemohlo by to být náhodou takhle?" následovaný odpovědí "No, vlastně proč ne." (Jedná se vesměs o oblast UI / UX)

8. 7. 2022, 09:23 editováno autorem komentáře

Skoro vsade sa len lepia zname technologie. Vynimka je Google, kde sa na urovni kniznic a infrastruktury robi nieco z velkej casti vlastne. Vyssie tiez uz len pouzivas infrastrukturu a pridavas k tomu trochu logiky.

Na psaní něčeho vlastního jsou potřeba ti nejlepší programátoři, takže nakonec to stojí obrovské peníze a efekt není až tak světoborný. Navíc v době cloud computingu a mikroslužeb se dá skutečně celkem úspěšně lepit z předpřipravených komponent. Akorát to pak zase chce někoho na DevOps atd.

Casto spatni programatori vymysli kolo, dobri pouziji knihovny.

Vymysleni kola ma smysl jen pokud je vase kolo lepsi nez vsechna predchozi.

Ti špatní většinou nic vymyslet nedokážou, takže asi tak...

Najlepsi nie, staci aby to neboli len lepci kodu a dokazali si nieco dostuovat. To plati v 90% pripadoch.

Zvysnych 10% su velmi domenovo specificke veci.

Vynimka je Google

Jojo, to je hodně velká výjimka... Jejich skvělá vlastní řešení mají jako typickou unikátní vlastnost asi nejhorší dokumentaci, jakou jsem kdy viděl. Např. u TensorFlow - když chceš rozjet cokoliv jiného, než demo příklady, tak se neuvěřitelně vytrápíš na nezdokumentovaných chybách, zpětné nekompatibilitě mezi verzemi, zcela chybějící dokumentaci konkrétních částí apod.

A o tom, jak takový vlastní vývoj vypadá na úrovni jejich produktů svědčí např. asi 5 let starý a nerealizovaný požadavek na doplnění elementárního formátování u zadání úkolů v Google Classroom. Nejvtipnější na tom je, že u komentářů k úkolům je možné použít na tučné písmo **, kurzívu // a podtržení __, ale nejde to používat v zadání...

Celý IT svět je postupně celý postavený z nějakých základních kamenů. Jinak bych musel pokaždé implementovat svůj vlastní algoritmus pro odmocninu místo jednoduchého math.sqrt(x).

S větší a větší abstrakcí šetříš (teoreticky) více a více svého času, ale samozřejmě taky postupně ztrácíš detailní kontrolu nad chováním daného kódu. Každý si může zvolit, jaká úroveň abstrakce je pro něho optimální.

Hezké přirovnání.
Jako vyučený truhlář ti mohu erudovaně ubezpečit, že žádný truhlář nebude dělat skříň ze surového dřeva, pokud k tomu nebude mít zatraceně dobrý důvod. Nevyplatí se to a nemá to žádnou výhodu.
Bude používat spárovky, nejlépe už nařezané na normovaný rozměr.
Bude používat rybičky a kolíky koupený v pytlíku. Bude používat lepidlo, co je fakt brutální chemie. O povrchové úpravě ani nemluvě.
Lišty se frézujou už desítky let stejné. Takže talíře mají několik základních profilů. Kování je samozřejmě taky koupený v pytlíku.

Jak říkám, pěkné přirovnání.

Měl jsem na stavbě truhláře, co fakt ze surového dřeva, lepil si spárovky, řezal si to podle potřeby.

Málokterý programátor začíná psát kód pro adresu 0x0000 a pak prostě nevyhnutelně používá "dlouhý seznam" na kterém jeho práce závisí.