Těžké OOP problémy

[gill]

Abstrakce je užitečná, jen pokud zobecňuje několik konkrétních případadů a zkrátí kód. Overengineering je psaní abstrakcí, které použijete jen jednou. Mluvím o psaní vlastních abstrakcí, ne o používání knihoven.

[Reklama]

[Mirek Prýmek]

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".

[gill]

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".

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á.

[Idris]

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"...

To je pravda, variance typů už je pro naprostou většinu nepřekonatelné WTF.

[Idris]

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".

Přinejmenším zde se ukázalo, že naprostá většina neví, jak async/await funguje, ani pod kapotou, ani nad...

Jo, tohle je klíč, bezproblémová abstrakce je jen ta transparentní, o které člověk neví.

[Reklama]

[Ink]

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.

No a teď jsme myslím u toho - abstrakce jsou OK, když jsou dobře navržené a odladěné. Tudíž asi nechceme, aby je psal "kdokoli", ale pustíme na to člověka, který to umí, děláme review kódu a pak máme rozumnou jistotu, že ten vnitřek funguje a "pojídači koláčů" nasekají co nejméně chyb a ty jsou dobře viditelné. Je to jiný přístup, než když všichni "jedí z jedné mísy" - neříkám, že jediný možný, neříkám, že vždy optimální, ale podle mě dost užitečný a s úspěchem aplikovaný.

[Mirek Prýmek]

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

[Mirek Prýmek]

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í

[gill]

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

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 ==.

[Idris]

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

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 ==.

A tady vidíš, milý Mirku, Dunning-Krugera v praxi, jako na talíři 

[Kit]

Abstrakce je užitečná, jen pokud zobecňuje několik konkrétních případadů a zkrátí kód. Overengineering je psaní abstrakcí, které použijete jen jednou. Mluvím o psaní vlastních abstrakcí, ne o používání knihoven.

Občas napíši abstrakci i tam, kde ji použiji jen jednou. Vlastně to dělám stále. Jen je třeba vědět, kterou abstrakci v daném místě použít.

[hawran diskuse]

Zásadně píši jen vysoce abstraktní programy.
Konkrétní je jen absolutní cesta ke zdrojovému souboru.

[Mirek Prýmek]

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

[Idris]

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 ==.

Průměrné IQ programátora imho nebude moc nad stovkou.

Pak se divíte, že kdokoliv s VŠ, i kdyby to bylo třeba Mennonite studies, píše o řád lepší kód než kdejaký jirsák z fóra.

Abychom ale diskutovali vážně, prvotní otázka je, kdo je vlastně programátor. Je překvapivě těžká, protože nemáme amatérské chirurgy nebo stíhače, ale PC má dnes každý a copy paste z SO zvládne i giloidní puberťák s půlkou mozku. Kdybychom definici zúžili na aspoň někdo s Bc., hned by bylo veseleji.

[Idris]

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

To s tím Go je zajímavé, Google nabírá jen špičku, ale přesto se snaží Go maximálně držet při zemi.