Příspěvky

1861

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

« kdy: 08. 11. 2019, 11:55:02 »

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 

1862

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

« kdy: 08. 11. 2019, 11:30:24 »

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

1863

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

« kdy: 08. 11. 2019, 11:27:18 »

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.

1864

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

« kdy: 08. 11. 2019, 10:47:57 »

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

Jenže kolik vývojářů ví, co je monoid a co endofunktor? To znají jen ti, kteří studovali teorii kategorií a těch není mnoho.

Alert! Nadsázka 

1865

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

« kdy: 08. 11. 2019, 10:11:25 »

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

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

1866

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

« kdy: 08. 11. 2019, 10:07:10 »

Je to také hodně o použitých nástrojích. Není problém napoprvé napsat konkrétní řešení, při druhém použití je mírně přiohnout a až při třetím použití pořádně zrefaktorovat do více úrovní abstrakce, když se člověk může spolehnout na použitý jazyk a nástroje. V pythonu či JS se taková věc dělá hodně pracně, v javě s generiky a kvalitním IDE je to hotové rychle a spolehlivě (pokud tam nejsou čuňárny typu přetypování natvrdo, reflexe se stringovými názvy apod.).

Toto je přínosný příspěvek - ano, do značné míry záleží na jazyku, typová kontrola při překladu posouvá proces vývoje na vyšší úroveň nejen kvůli odchytu chyb, ale i jako dokumentace a umožňuje automatickou analýzu a refaktorizaci. Jak tu správně zaznělo, efektivní použití abstrakce do určité míry záleží na tom, kolik toho člověk udrží v paměti, než se ztratí. 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.)

1867

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

« kdy: 07. 11. 2019, 23:43:12 »

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é

To je přesně ono, jeden z padesáti čistých informatiků je určitě dost zkušený a inteligentní na to, aby si to uhlídal. Takového by měli vyvažovat zlatem. Ale co ten zbytek, který nad sebou žádnou kontrolu nemá?

1868

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

« kdy: 07. 11. 2019, 22:33:26 »

No já si taky postěžuju k tématu:

V rámci pracovní náplně se starám o údržbu, opravu chyb a rozvoj několika různých webových aplikací psaných v ASP .NET.
Jde o různé druhy - některé jsou napsané jako Website ještě ve Visual Basicu, něco jsou takové klasické MVC aplikace v c#, zbytek pak "moderně" pojaté MVC aplikace se spoustou frameworků, továren, fasád, s podporou NodeJS.
Autoři aplikací jsou také různí, něco pochází od vývojáře u zákazníka, který se o to už nechtěl starat, něco je osiřelá aplikace napsaná a následně opuštěná konkurenční firmou, zbytek pochází od kolegů programátorů, kteří na jejich údržku a rozvoj nemají čas, protože píšou zase jiné nové aplikace.
Vče jsou to aplikace podobného rozsahu a složitosti. Žádnou z těch aplikací jsem od začátku nepsal, přicházím vždu k cizímu hotovému.

A já mám největší problémy s údržbou a opravami aplikací pocházejících od vlastních kolegů (některých).
Jejich aplikace jsou na můj vkus totiž "příliš programátorské, příliš příručkoidní, příliš OOP" - vše je skryté pod několika vrstvami abstrakce, všude jsou implementované interfejsy, automatické mappery, časté je dědění tříd a přepis metod, JS kód je obvykle někde dynamicky generovaný jako součást něčeho a jednoduše nedebugovatelný.
Můj pocit z jejich kódu je, že se snaží vždy všechno napsat co nejvíc "elegantně", aby se velká část činnosti nevykonávala ve viditelném kódu vlastních tříd, ale někde skrytě na pozadí. Taková trošku programátorská onanie, čím menší vrabec, tím větší kanón. 
A když mám v takové aplikaci něco opravit nebo vylepšit, tak tím často strávím několik dní než se skrz ten balast prokoušu k podstatě, často jen odhadem a zkusmo. Většinou také proto, že přijde nějaký požadavek na funkčnost mimo rámec toho jejich "elegantního" řešení a já to musím nějak násilně ohýbat, pokud to nechci celé přepsat po svém.
Přitom se paralelně starám i o ostatní aplikace od jiných autorů a tam takové problémy nepociťuju - vše je skoro vždy tam, kde to čekám, když něco změním, reaguje to dle očekávání, změny jsou hotové za hodinu nebo dvě. Jsou prostě napsané přímočařeji a jednodušeji, složitější konstrukce si šetří jen tam, kde to opravdu dává smysl (= skoro nikde, neřešíme teorii relativity, ale třeba logistiku, správu vozového parku, apod).
 
Takže teď nevím, zda mám hledat nedostatky u sebe nebo u kolegů - z mého hlediska je jejich "dokonalý" kód hodně neefektivní na občasné změny a opravy. Místo aby vše šlo snadněji a rychleji, tak je to naopak časově náročnější - minimálně pro mně.

Kdo to dočetl až sem, má u mě velké bezvýznamné plus. 

To je klasika, přesně o čem jsem psal, kdo zná jen a pouze IT, vnáší umělou složitost do kódu. Kdo píše kód k vyřešení problému z jiné domény, napíše ho co nejjednodušší, aby prostě řešil, co má, bez padesáti rovin abstrakce.

1869

Vývoj / Re:Rust v ČR

« kdy: 07. 11. 2019, 17:06:46 »

Já dělám v Rustu asi poslední rok a půl, ne-GUI část drážního měřicího a vyhodnocovacího SW v malé firmě. Když jsem nastupoval, řekl jsem, že to budu dělat buď v Rustu nebo vůbec (už jsme se znali předtím, takže jsem si to mohl dovolit), a rozhodně nelituju. Předtím se o to párkrát pokoušeli různí C++kaři a vždycky to bylo nestabilní, zabugovaný a ošklivě napsaný (pokud v C++ nedělá opravdu špičkový programátor, řekl bych že to tak dopadá poměrně často), teď to docela funguje.

On Rust má svoje přednosti, oproti C++ rozhodně.

1870

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

« kdy: 07. 11. 2019, 14:49:29 »

Ano, velmi zlehka. Ruku na srdce, každý z nás pár astrofyziků zná, oder?

Já ne

To byla ironie

1871

Vývoj / Re:Rust v ČR

« kdy: 07. 11. 2019, 14:48:27 »

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

To se stalo Lighthousu

1872

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

« kdy: 07. 11. 2019, 14:19:14 »

To je pravda, ale v zápětí jsem psal, že ta laťka může být jinde, prostě jsem si dovolil nadsázku 

Jak říká klasik: "Trochu jsem si zapřeháněl"

Ano, velmi zlehka. Ruku na srdce, každý z nás pár astrofyziků zná, oder?

1873

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

« kdy: 07. 11. 2019, 14:18:08 »

Tak ale ty sám jsi zmínil “amatérskou lingvistiku.”

Já vím, napsal jsem to zmateně. Chtěl jsem říct "když už se bavíme o významech slov". Byla to narážka na předchozí ""normálně" neříkáme "objekt" skoro ničemu."

To už je ale slovíčkaření. Do filosofie bych se teď nerad pouštěl, a už vůbec ne té kontinentální.

1874

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

« kdy: 07. 11. 2019, 14:11:08 »

Já tvrdím, že OOP koncepty lidem matou hlavy.

Ani ne. Jen tvrdím, že když má někdo PhD z astrofyziky, nějaký zcestný koncept ho nezmate

Doktoři astrofyziky budou uvnitř "lidí" tvořit dost zanedbatelné procento

To je pravda, ale v zápětí jsem psal, že ta laťka může být jinde, prostě jsem si dovolil nadsázku 

1875

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

« kdy: 07. 11. 2019, 14:10:07 »

Mimochodem, když už jsme u té amatérské lingvistiky, tak ve filosofii se "objekt" odlišuje od "subjektu" právě tím, že je aktérem, původcem děje. A proto má i ta žárovka konat autonomně. Kdyby byla pasivní, nebyla by "objektem", ale "subjektem"

Tos těžce netrefil, subjekt/objekt jsou pojmy z oblasti syntaxe

Asi ste chceli poukazat na tranzitivnost/netranzitivnost slovies

Oba jste to pochopili příliš lingvisticky, já jsem myslel spíš https://en.wikipedia.org/wiki/Object_(philosophy)
...ale jak jsem u toho psaní dělal ještě něco jinýho, tak jsem to omylem otočil, takže jsem dodal argument proti tomu, co říkám (že "objekt" má být "konatel")

Tak ale ty sám jsi zmínil “amatérskou lingvistiku.”