Příspěvky

946

/dev/null / Re:Těžké OOP problémy

« kdy: 09. 11. 2019, 09:53:23 »

stejné klíčové slovo má v různých jazycích různý význam.

Můžeš uvést příklad takových dvou jazyků?

947

/dev/null / Re:Těžké OOP problémy

« kdy: 09. 11. 2019, 09:49:59 »

mohl bys ukázat příklad v tom jiném jazyku, kde je podle tebe await nebezpečné ve vícevláknovém prostředí?

To je přece triviální: jakýkoliv kód, který by byl chybný i bez async.

Bavili jsme se o await v JS.

Možná vy, já jsem mluvil obecně.

948

/dev/null / Re:Těžké OOP problémy

« kdy: 09. 11. 2019, 09:35:58 »

Používat a dobře rozumět jsou dvě odlišné věci. Zkus se třeba náhodně vybraného webaře zeptat, jak souvisí await s promisy a uvidíš, jak se v tom začne zamotávat

...anebo pokud bys měl o něm vysoké mínění, můžeš se ho zkusit zeptat, za jakých podmínek je podle něj bezpečné používat await v multivláknovém prostředí

No, vzhledem k tomu, že JS (webový i NodeJS) je single-thread, tak ta otázka poněkud nedává smysl ;-)

V té větě, na kterou reaguješ, ale "JS" vůbec není.

949

Vývoj / Re:Struktura projektu s mikroservisami

« kdy: 09. 11. 2019, 00:22:10 »

Rozdelenie podla jazykov sa mi paci, ale kde mate commitnuty compose-file, ak teda ho tam vobec mate? Motivacia mat to v jednom repo bola ta, ze mas v roote compose-file, a jednym prikazom si nahodis cely stack, okrem veci ktoru zrovna vyvijas.

Na vsechny veci souvisejici s ops mame dalsi repo (je to podstatne slozitejsi nez jeden compose file).

950

Vývoj / Re:Struktura projektu s mikroservisami

« kdy: 08. 11. 2019, 22:21:07 »

My to mame tak, ze mame samostatna repa podle programovacich jazyku. V kazdem repu jsou vsechny microservisy, ktere jsou napsane v tom kterem jazyce. Funguje to dobre. Samostatne repo na kazdou servisu bych teda udrzovat nechtel

951

/dev/null / Re:Těžké OOP problémy

« kdy: 08. 11. 2019, 16:58:57 »

Jo, ten Pike není blbec.

Ani Thompson. Toho tretiho neznam.

952

/dev/null / Re:Těžké OOP problémy

« kdy: 08. 11. 2019, 16:26:59 »

To ale nic nedokazuje - není to reprezenattivní skupina.

Však já jsem netvrdil, že to něco dokazuje. Řekl jsem jasně "kdyby si někdo dal práci...".

Začátečníci se budou přirozeně ptát víc a na triviálnější otázky, protože neznají ekosystém a tápou i v tom, odkud brát informace. Pokročilejší si častěji poradí sám a ptá se, až když je nutno.

Senioři zase obvykle neřeší triviality, takže by se se stejnou logikou měli ptát na těžší problémy. A pokud by poměr seniorů a juniorů byl vyvážený, neměly by pak ty triviální otázky drtivě převládat.

Ale to už vařím z vody, to je jasný. Nic než svůj dojem v ruce nemám a ani nemám moc motivaci se snažit něco lepšího získat (EDIT: docela totiž věřím tomu, že tohle si ten Pike a spol. zjistili docela dobře )

953

/dev/null / Re:Těžké OOP problémy

« kdy: 08. 11. 2019, 14:43:40 »

ti co to používají tomu rozumí minimálně stejně jako vy dva s Idrisem. Řekl bych, že lépe. Souvislost s Promisy je zřejmá, každému, kdo to viděl v praxi nebo si přečetl prvních pár řádků dokumentace. Vy dva Javascript znáte jen na úrovni pseudo-intelektuálního humoru o chování operátoru ==.

Abysme si rozuměli:

1. Já se ani náhodou nepovažuju za nějak dobrého programátora. Naopak vždycky zdůrazňuju, že jsem full time programování nikdy nedělal, nedělám a udělám všechno proto, abych ani nedělal. Je mi naprosto jasný, že si mě v pohodě namaže na chleba z jedné strany člověk, který celý život valí produkční kód, a z druhé strany teoretik, který má zase nimrání se v teoriích programovacích jazyků jako koníček.

2. Snažím se ale na věci dívat realisticky. Vím, s čím zápolí kolegové v práci, vím, na co se ptají lidi tady nebo na SO. Realita je taková, že programuje čím dál víc lidí, někteří i čistě jenom kvůli penězům, bez hlubšího zájmu o věc. Průměrné IQ programátora imho nebude moc nad stovkou.

Dobrá lekce je v tomhle právě Go. Autoři otevřeně říkají, že je jednoduché proto, aby ho zvládli junioři v Googlu. A to prosím tady máme mnohdy představu, že když se někdo dostane do Googlu, musí to být programátorský superhero...

3. Kdyby si někdo dal trochu práce, určitě by se výš napsané dalo ověřit relativně tvrdými daty.

Např.:
https://towardsdatascience.com/finding-the-real-top-stack-overflow-questions-aebf35b095f1
- seznamu vévodí triviální otázky jako "How to get the number of elements in a list in Python?"

https://stackoverflow.com/questions?sort=votes
- první striktně programátorská "jazyková" otázka je "What does the “yield” keyword do?"

https://www.quora.com/Im-having-difficulty-in-understanding-asynchronous-JavaScript-topics-like-callback-promise-and-async-await-is-there-any-easy-way-to-understand-these-topics

954

/dev/null / Re:Těžké OOP problémy

« kdy: 08. 11. 2019, 11:39:01 »

Používat a dobře rozumět jsou dvě odlišné věci. Zkus se třeba náhodně vybraného webaře zeptat, jak souvisí await s promisy a uvidíš, jak se v tom začne zamotávat

...anebo pokud bys měl o něm vysoké mínění, můžeš se ho zkusit zeptat, za jakých podmínek je podle něj bezpečné používat await v multivláknovém prostředí

955

/dev/null / Re:Těžké OOP problémy

« kdy: 08. 11. 2019, 11:35:36 »

neměl bych strach, většina webových vývojářů už to dávno používá, nemá s tím problém. Když v tom nehledáte teorii kategorií nebo co, tak je dokumentace docela stručná a srozumitelná.

Používat a dobře rozumět jsou dvě odlišné věci. Zkus se třeba náhodně vybraného webaře zeptat, jak souvisí await s promisy a uvidíš, jak se v tom začne zamotávat

956

/dev/null / Re:Těžké OOP problémy

« kdy: 08. 11. 2019, 11:13:26 »

Typový systém naopak “udržuje kód v mantinelech,” problém ovšem je, že kvalitativní hierarchie je vlastní typy -> generické typy -> higher kinded typy -> závislostní typy a 99% vývoje končí na generických. Až se rozšíří ty zbylé dvě kategorie, bude vznikat kvalitnější SW rychleji a spolehlivěji.

(Velice smutné je, že teď si jde drtivá většina čtenářů googlit, co to je higher kinded a závislostní typ.)

To máš sice pravdu, ale je tam ještě jedna potíž: pokud je těch "abstrahujících" konceptů v jazyce víc, začnou mít netriviální interakce a celková kognitivní zátěž může narůst nad úroveň pro BFP únosnou.

Třeba už jenom ty generické typy: pokud je jazyk OOP, bude mít podtypový polymorfismus, což v kombinaci s generiky vede na problém kovariance vs kontravariance a už jsme ve vodách, které budou pro spoustu programátorů nepřiměřeně hluboké (dobře je to imho vidět na Scale). A to jsme teprve na druhé úrovni té tvé "hierarchie kvality typového systému"...

Každý má limit chápání (abstrakcí i obecný) jinde. Monoid v kategorii endofunktorů je ultraužitečná abstrakce, ale kolik wannabe vývojářů ví, která bije? Přesně o tomto je myslím Go, které kašle na fancy abstrakce, Pike ho navrhnul - dle vlastních slov - pro absolventy bez zkušeností.

Jo, to je přesný. A není ani potřeba chodit tak daleko. Onehdá jsme se tady přece bavili o async/await a shodli se na tom, že máme pochybnosti o tom, kolik procent vývojářů bude dobře vědět, co se tam pod kapotou vlastně děje... Celkem podstatný tady je, jestli je možné abstrakci "bezpečně" používat i bez jají důkladné znalosti, na základě nějaké jednoduché poučky typu "když je někde uvnitř použité await, celá funkce musí být async".

957

/dev/null / Re:Těžké OOP problémy

« kdy: 08. 11. 2019, 08:47:00 »

Dobře zvolená abstrakce naopak nevyžaduje, abys někam skákal, prostě o sobě říká, co dělá a typicky se o vnitřek zajímat vůbec nemusíš.

Nemusím se o vnitřek starat, pokud jsem si dostatečně jistý tím, 1. co je výsledkem její činnosti (pokud je to funkce) 2. že neobsahuje žádnou chybu.

Implementaci knihovních funkcí typu map budu prolízat až jako poslední, protože je nejmenší šance, že chyba bude právě v ní. Naopak konstrukce, které napsali kolegové před půl rokem a jsou v kódu použité jenom dvakrát, prolízt musím, protože pravděpodobnost chyby je veliká. V případě, že jsou srozumitelné a snadno zapamatovatelné, prolezu je jednou. Jinak je musím prolízat pořád dokola, protože prostě nejsem schopný si zapamatovat nebo vůbec pochopit, co mají dělat.

958

/dev/null / Re:Těžké OOP problémy

« kdy: 08. 11. 2019, 08:31:43 »

dobře zvolená a napsaná abstrakce kód nemůže znepřehlednit.

S tím bych nesouhlasil. Dokonce bych spíš tvrdil skoro opak: každá abstrakce z definice přidává další indirekci v tom smyslu, že když sleduju flow programu a narazím na abstrakci, musím odskočit jinam (do souboru, kde je ta abstrakce definovaná).

Jediné, co rozhoduje, je, jestli převáží nevýhody použití nebo nepoužití abstrakce. Což je typicky počet abstrakcí (jestli jsem schopen si je zapamatovat a ušetřit si tak odskoky) a jejich srozumitelnost (po jednom přečtení chápu smysl abstrakce, nedělám to tak, že sleduju jenom ten jeden průchod, který zrovna řeším).

959

/dev/null / Re:Těžké OOP problémy

« kdy: 07. 11. 2019, 23:28:46 »

kdo zná jen a pouze IT, vnáší umělou složitost do kódu

Nevím, jestli bych to takhle spojoval. Např. my máme ve firmě šéfprogramátora, který jednoduchost a přímočarost docela tvrdě vyžaduje. Zrovna tenhle týden mi říkal, že za rule of thumb kritérium obhajitelnosti abstrakce považuje to, že je ta abstrakce použitá na třech různých místech. Psát abstrakce jenom tak z plezíru, s vidinou, že se to jednou bude hodit, je u něj no-go. A je to čistý informatik. Akorát má prostě dost zkušeností a je dost inteligentní.

Podle mě je ideální takového člověka v týmu mít. Když si člověk existenci každé abstrakce, kličky a nestandardnosti musí obhájit jasnými konkrétními argumenty, přestane mít chuť psát ty neobhajitelné

960

Vývoj / Re:Rust v ČR

« kdy: 07. 11. 2019, 14:26:32 »

Chtěl jsem najít kdo a odkud měl přednášku na pardubice.devfest.cz na Rust, ale jsi to ty 

Tak ještě Pavel Tišnovský, takže možná v RedHatu něco minimálně zvažují?

...pokud jim s tím teda IBM nezatne tipec a nepřesedlá je všechny povinně na Javu