Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Mirek Prýmek

Stran: 1 ... 154 155 [156] 157 158 ... 618
2326
To stejné byste mohl napsat o každé technologii přidávající úroveň abstrakce. Když to používáte správně, ušetří vám to spoustu práce. Zejména pokud dlouhodobě pracujete se složitější databází a provádíte často podobné, ale ne úplně stejné dotazy. Kdybyste měl stále dokola zapisovat ty stejné joiny, tak byste se z toho zbláznil.
Ne. Problém není v abstrakci, problém je v abstrakci takového typu, že spousta jejich uživatelů nedokáže sestoupit o úroveň níž a říct, co přesně tohle udělá. Čili efektivně ztratí schopnost uvažovat nad vlastním kódem, což je ten problém.

Např. parametrizovaná fce, která zastupuje nějaký složitější dotaz, který ale má konkrétní účel a konkrétní, všem známou formu, je úplně v pohodě. To je abstrakce úplně jiného typu než když mám třeba ultramagický proxy objekt, který teprve při přístupu k atributu tahá data z DB, nikdo neví v jakém rozsahu a jak často, jakými joiny, s jakými náklady...

2327
JS je vzácný příklad jazyka, co není ani "čistý", ani pragmatický.
JS byl celkem pragmatický a relativně OK ve svém původním účelu: jednořádkový handler kliknutí někam. Že se z něj pak stal jazyk, ve kterém se budují dnešní webové jaderné elektrárny, je jiná věc, spíš historická nahodilost.

Mně spíš doteď není jasný, proč se výrobci prohlížečů nemůžou domluvit na nějakém bytecodu+standardizovaném VM typu CLR, aby se konečně toho JS dalo elegantně zbavit bez transpilace...

2328
Navíc když je někdo pablb, tak zprasí dotazy do DB i bez ORM.
Určitě. Ale ORM framework mu v tom mocně sekunduje a pěkně za ručičku vede do pekla ;) Čím jednodušší na použití, tím horší.

2329
Django nepoužívám, ale limit funguje normálně, joiny přes loop to neprovádí a pro efektivní save jde použít bulk_save. Má to mouchy, proto jsem přešel na SQLAlchemy. Ale to co píšete, není pravda.
O limitu jsem nic nepsal. Problém ORM frameworků je, že si člověk "snadno" kdekoliv v kódu šáhne pro cokoliv jako by to byla lokální proměnná a vůbec neřeší, jak ve skutečnosti budou vypadat ty dotazy, jaká s tím bude režie. V tom je ten ďábel v detailu.

2330
Neni nic zoufalejsiho naphled, nez uvidet v Oraclu hromadu hibernatem vygenerovaneho hnoje, po kazdem insertu zpetny select, aby hibernate videl autogenerovany klic, JSQL join  genialne implementovany pres java nested loop, indexy jsou sproste slovo, transakce zamykane na J2EE urovni, select limit implementovan stylem stahni vsech 10milonu zaznamu a z prostredka jich vyber 20, jeden by blil. Nebo kod idiotsky neustale tahajici data mezi tomcatem a oraclem jak kocka mlade, aby vusledkem byla jedna integer KPI metrika, kterou mohla spocist jednoducha PLSQL procedura a nemusely po siti litat megabajty dat resultsetu.
Spousta lidi kolem jawy nema sebemensi poneti o SQL/PLSQL a vysledek je otres.
...a kdyz misto "java" das "python" a misto "hibernate" "django", bude to uplne stejne pravde-podobny popis, takze bych z javy uplne nedelal obetniho beranka :)

2331
Odkladiště / Re:Podvod na linuxeshop.eu?
« kdy: 30. 05. 2017, 20:56:08 »
Tak v tom případě minimálně v tomto provozovatel lže. Když si dá název evokující uskupení firem které ve skutečnosti neexistuje a bůhví zda to není one man show.
Živnostník může pro obchodní účely používat "firmu" (název). A název může být cokoli, klidně Zlobiví vorvani, přestože v podniku ani jeden vorvaň nepracuje.

Nevymýšlej krávoviny, o žádnou lež se nejedná.

2332
„...i skladník ve šroubárně si může přečísti Vergilia v originále...“
Ale nikdo nebude tvrdit, že pochopení šroubárny do hloubky vyžaduje jeho znalost :)

2333
OOP není vůbec zvrácené. Pro ty, kteří ho zcela nepochopili, bývá často výhodnější FP, neboť v něm nemohou dělat chyby, kterých se dopouštěli v OOP.

Nevím, každopádně by to mnohé vysvětlovalo.
Problém je v tom, že OOP programátoři se ani mezi sebou neshodnou, co je chyba a co ne. A to nemluvím o nějakých hlupáčcích, ani špičky v oboru se neshodnou (viz třeba ten zmíněný Virius vs. Čada).

2334
A nepřijde ti, že přesně to jsem napsal? (jen trochu jinými slovymi  ;))
Jo. Však jsem taky nereagoval na tebe :)

2335
Vývoj / Re:Kontextový „bezkontextový“ jazyk
« kdy: 30. 05. 2017, 07:53:52 »
To asi není kontextový ne? Mohl bys pls naznačit jak by vypadal zásobníkový automat, který jej příjme?
Pokud tomu rozumím správně, zboj myslel bezkontextový jazyk a^k,b^l,v^m, k>0, l>0, m>0 plus podmínka k=l=m, která z něj udělá kontextový.

2336
Vývoj / Re:Kontextový „bezkontextový“ jazyk
« kdy: 30. 05. 2017, 07:48:59 »
Přečti si otázku. Je to příklad kontextového jazyka přijímaného bezkontextovou gramatikou s omezujícími podmínkami.
Ten pojem "bezkontextová gramatika s omezujícími podmínkami" je nějaký terminus technicus, nebo to myslíme jenom neformálně? Existuje nějaká definice, co ta omezující podmínka může být, jaký může mít tvar? (Jako odpověď mi stačí jenom nějaké klíčové slovo, co se dá vygooglit. Vůbec si totiž neuvědomuju, že bysme se o "bezkontextové gramatice s omezujícími podmínkami" někdy učili)

2337
Zedník umí stavět zdi, ale pouze ve známém prostředí. Nespočítá si už například vliv náhrady materiálu izolace na tepelné ztráty zdi.
Zedník nemá nic počítat. Zedník má postavit zeď tak, jak je to v projektu. A s běžným programátorem je to dost často stejně - přílišná invence, která není na místě, k ničemu dobrému nevede. Imho není ani tak důležité znát všechno, důležitější je znát svoje limity a nepouštět se do věcí, na který nemám.

2340
To se dělá, odkud myslíš, že se vzaly pojmy kovariantní a kontravariantní u generik? Právě z TK, a pak se tam pracuje s bifunktory, sliced functors etc.  ;)
No vidis - a OOPckarum to necpes ;)

Stran: 1 ... 154 155 [156] 157 158 ... 618