Příspěvky

181

Vývoj / Re:Dědičnost dnes

« kdy: 01. 02. 2017, 19:19:46 »

V podstate se ocekava, ze programatori budou ten vzor sami rozeznavat (a pripadne aplikovat) v kodu. Ale to je hloupe, to co chces je naucit ten vzor pocitac (definovat urcitou abstrakci), aby to lide delat nemuseli, protoze lidska prace je draha a vede k chybam.

Tento argument naprosto nechápu. Ano, když nahradíme programátory umělou inteligencí, tak lidskou práci nahradíme. To je ale zatím jenom budoucnost a programátoři stále musí analyzovat problémy i kód a dělat rozhodnutí. Můžeme to hodně usnadňovat na všech stranách, hodně pomůže posunutí na vyšší úroveň (jako jsme se posunuli od návrhového vzoru "volání podprogramu"), ale právě to základní jádro (rozhodování, volba) tam stále je a počítač to naučit neumíme.
No dobře, trochu ano, ale nemyslím že by v tom FP nějak významně pomohlo.

Je to podobne prastene, jako kdyz Java nema makra (rekneme a la Lisp), protoze by to bylo "moc slozite", ale pak se podobne problemy resi generovanim kodu, coz je samozrejme horsi.

To je skutečně praštěné, protože Java nemá makra "a la C" aby to nebylo moc složité. Ten rozdíl mezi C makry a LISP makry je naprosto zásadní.
Pokud vím, Java nemá LISP makra z daleko prostšího důvodu: nepatří do "mainstream" imperativního jazyka s celkem konzervativní koncepcí.

182

Vývoj / Re:Dědičnost dnes

« kdy: 01. 02. 2017, 12:14:09 »

v té době ještě vývojáři sem tam potřebovali řešit algoritmy - dnes lze strávit úspěšnou kariéru jenom kombinací knihoven.

Řešit ve smyslu navrhovat nebo jen implementovat?

To je dobrá otázka. Myslím že i navrhovat, ale jsem moc mlád abych to pamatoval.

183

Vývoj / Re:Dědičnost dnes

« kdy: 01. 02. 2017, 11:00:49 »

Toto nebol zamer GoF. Navrhujem s k problematike nieco precitat. Nie clanky na zdrojaku typu Tomas Jouda - Navrhove vzory snadno a rychle. Ale pekne od zaciatku http://www.patternlanguage.com/bookstore/timeless-way-of-building.html

Hej, to je můj argument! Sorry, tady pláčeš na špatném hrobě, já naopak programově proti frflání vystupuji, protože mi celkem vadí "diskuse" kdy kritici i zastánci jsou úplně mimo.

Skor by to bolo mozne prirovnat k ludovej  a inej starsej architekture, kedy sa nepouzivali plany. Ale pre iste stavby boli v povedomi koncepty, ako sa ma nieco robit aby to bolo dobre. Ciel vzorov je presny opak, nez ste tu naznacili, je to  odburanie byrokracie.

Jenomže tady se už dostáváme na půdu hodně osobní interpretace... Já bych prostě řekl že cílem může být odbourat zbytečnou byrokracii, ale ne byrokracii úplně (tak by tomu bylo v ideálním světě, kde programátoři vytvářejí a skládají matematické abstrakce). Ale třeba jsem to opravdu pochopil špatně, to se asi jen tak nedozvím.

Možná je problém v tom, že používám pojem byrokracie, který je považován za zcela pejorativní a negativní. Přitom se jedná o základ civilizace a jedinou známou možnost jak může lidský druh (při našich počtech) fungovat.

Nejsmutnější je, že ješte pár příspěvků a lidé si mě začnou plést s Ivanem Novým... asi bych měl přidat nejakou tu poruchu osobnosti, třeba si mě spletou s blekem :-)

184

Vývoj / Re:Dědičnost dnes

« kdy: 01. 02. 2017, 09:23:56 »

Protože já stále vidím, že mícháte dva problémy: jak se dají řešit programátorské problémy a jak se dají řešit lidské problémy programátorů (tedy především domluva, respektive neschopnost se domluvit).
GOF naopak velmi správně naznali, že toto klasické řešení "jsme všichni fundovaní matematici, takže se domluvíme matematickými abstrakcemi" je naprosto nefunkční v době masové produkce SW.

Jestli tohle byl zamer GoF, tak o nich mam jeste horsi mineni. Vytvorenim dalsi zbytecne terminologie se komunikacni problem nevyresi.

No, nevím, tím bych si nebyl tak jist. Je to standardní byrokratický postup. A paradoxem byrokracie je, že přes zjevnou nefunkčnost a neefektivitu je v historickém měřítku neuvěřitelně úspěšná, takže funkční.

Mozna je problem v te predstave, ze produkce SW musi byt masova..
 Mozna kdyby se od toho ustoupilo, redukovalo by se to prave na dobre pasujici dilky (skrze typovy system) a nebylo by potreba tolik lidi.

Produkce SW prostě masová JE. Otázka zda musí nebo ne patří do oblasti (politické) ekonomie, nemá nic společného s matematikou nebo computer science.


Je ale pravda že v dnešní době už opravdu nazrál čas na to, aby někdo zorganizoval "FP GOF" a přišli s konceptem jak zasadit FP do korporátní byrokracie. Pokud se tak nestane, tak z toho zase nic nebude...

185

Vývoj / Re:Dědičnost dnes

« kdy: 31. 01. 2017, 11:02:02 »

Jinak existuji skutecne "design patterns" v FP. Jsou to veci jako treba funktor, nebo monada, nebo monoid, nebo traversable.. typicky (v Haskellu) definovany pres nejakou typovou tridu a zakony, ktere pro ne plati. Ale to uz je o necem trochu jinem, a v jistem smyslu je to mnohem zajimavejsi (protoze lepe definovane) nez design patterns z GoF book.

To nejsou vzory, ale normální matematické koncepty.

Rypes do toho pekne (zbytecne), ale jsou to vzory podle te puvodni Alexanderovy definice.

Kazdopadne, spis to byl povzdech nad tim, ze to co se nazyva "software design patterns" jsou triviality, ktere zpopularizovala GoF knizka, pritom lepe by bylo, kdyby doslo k tomu, ze si programatori uvedomi Howard-Curry korespondenci, a dojde jim, ze kazdy vzor v programovani ma svuj odraz v matematice a naopak. Neblamuji za to ani tak autory, ti proste sami moc nevedeli, co delaji (ja sam jsem o FP jeste pred par lety nic moc nevedel, na druhou stranu, ja aspon nepisu knihy, jak psat software a nestudoval jsem puvodne computer science), spis kolektivni nevedomi programatoru, ktere se vyse uvedenym prispevkem snazim napravit.

Máš nějaký reálný důvod myslet si že nevěděli co dělají, nebo to jenom tak dedukuješ?

Protože já stále vidím, že mícháte dva problémy: jak se dají řešit programátorské problémy a jak se dají řešit lidské problémy programátorů (tedy především domluva, respektive neschopnost se domluvit).
GOF naopak velmi správně naznali, že toto klasické řešení "jsme všichni fundovaní matematici, takže se domluvíme matematickými abstrakcemi" je naprosto nefunkční v době masové produkce SW. A to podle tehdejších měřítek, dnes je to mnohem horší; v té době ještě vývojáři sem tam potřebovali řešit algoritmy - dnes lze strávit úspěšnou kariéru jenom kombinací knihoven.

186

Vývoj / Re:Technologie pro webovou aplikaci

« kdy: 26. 01. 2017, 08:24:13 »

Výběr je skutečně velký a i když se zdá že můžete vybrat špatně, tak je to jen iluze - ve skutečnosti totiž záleží především na tom, jaké máte lidi a co oni umí.

Pokud máte vývojáře co jsou v něčem zkušení, vyberte to.
Pokud máte vývojáře a jsou natěšeni se něco učit, můžete to zvolit - ale bacha, je to riziko které ne všichni zvládnou ukočírovat.
Pokud vývojáře nemáte a teprve je chcete hledat podle zvolené technologie... tak máte docela velký problém a v podstatě nemůžete vybrat dobře.

187

Vývoj / Re:Dědičnost dnes

« kdy: 17. 01. 2017, 14:04:49 »

Proč si myslíte, že vizuální komponenty jsou nějak vhodnější nebo lepší pro OOP než nevizuální? Nevyplývá to z původní popularizátorské představy, že když je něco vidět, tak je to objekt?

Ne. Vizuální komponenty se uvádějí jako příklad úspěšné aplikace OOP z toho důvodu, že se tato kombinace reálně osvědčila a přinesla skutečné výsledky (ulehčení a zjednodušení práce, vyšší produktivitu).
Myslím že na to existují dokonce reálná data, ale ruku do ohně bych za to nedal.

188

Vývoj / Re:Dědičnost dnes

« kdy: 16. 01. 2017, 18:03:59 »

Jeden ze základních problémů používání OOP je snaha pomocí dědičnosti (class hierarchy) modelovat realitu (nebo obecně doménu).

Ano, byla to jedna ze základních tezí vedoucí k propagaci a rozšíření OOP. Ale po třiceti (čtyřiceti?) letech si můžeme přiznat, že tohle naprosto selhalo.

189

Vývoj / Re:Dědičnost dnes

« kdy: 16. 01. 2017, 09:04:00 »

Takže když někdo neumí používat dědičnost, tak je dědičnost špatná?

Já bych to řekl takhle: když někdo umí používat dědičnost, tak ji používá málo.
Když někdo používá dědičnost často, tak ji nejspíš používat neumí.

Ale pravdu bych se vyhnul ideologickým poučkám "dědičnost nepoužíváme, protože je to prasárna" - vždy je důležité hlavně vědět jaké konkrétní problémy vznikají.

190

Vývoj / Re:Dědičnost dnes

« kdy: 16. 01. 2017, 08:14:17 »

Používáte dnes v OOP často dědičnost? Není ta doba už pryč? Stále narážím na lidi, kteří milují dědičnost a používají ji třeba i na to, aby kód neměli duplicitní. Chápu ještě využití polymorfismu, ale to není až tak časté. Ale celkově to moc dnes nedává smysl, tak jsem chěl vědět názory zdejších odborníků. Třeba Kit by mohl něco zajímavého přinést.

Pouzitie dedicnosti na odstranenie duplicity kodu je fakt uchylnost, takym koderom treba nakopat zadok, zbytocne to zneprehladnuje kod a da sa to riesit aj inak

Já bych nebyl tak striktní - použití dědičnosti pro odstranění duplicity je v mnoha jazycích s tradičním OOP osmdesátých/devadesátých let (třeba Java) celkem v pohodě. Ale jenom pokud se jedná o čistě implementační záležitost (ideálně ani společný předek není veřejný). Problémy nastanou pokud někdo použije dědičnost jako součást API. To prakticky vždy znamená jámu do které někdo spadne...

Dedicnost pouzivam vtedy, ked potrebujem pouzit polymorfizmus.

Jenom pro úplnost: jsou jazyky kde je možný polymorfismus i bez dědičnosti.

191

/dev/null / Re:Existuje ve vesmíru inteligentní život?

« kdy: 10. 01. 2017, 11:55:48 »

Základní operací pro toto je dělení. Je to taky první operace, která má původ v sociologii skupiny, kdy docházelo k dělení kořisti. Násobení a sčítání bylo jistě odvozeno až později, když se skupina dopracovala k pojmu spravedlnosti.

Vskutku originální, musím smeknout. Myslím že pravicově-marxistická analýza elementárních algebraických operací je něco co skutečně lidstvu chybělo!

192

Studium a uplatnění / Re:Jsem javista a nechci pořád vyvíjet pro banky a korporace!

« kdy: 10. 01. 2017, 11:45:06 »

Frikulinske zmrdoviny: takmer vsetko v Docker svete preferuje Go, napr. Dropbox svoj Pocket Magic najprv napisal v Go ale nakoniec ho prepisal este raz do Rust. Spomenuty shell mi pride ako najvhodnejsi kandidat na frikulinske zmrdoviny.

Ty to tady moc nečteš, co? Že vůbec nejsi v obraze co se týče anti-hipsterské komunity. Pro antihipstery je docker naprostým ztělesním frikulínství a Dropbox je jedním z avatarů Cloudu, boha zmrdovin.

193

Vývoj / Re:Automatické uvolňování paměti v c++

« kdy: 10. 01. 2017, 07:55:39 »

Jenom taková myšlenka po ránu: existence kompilátoru který obecně dokáže říct kdy se uvolňí paměť na heapu - nedá se to náhodou převést na Halting problem?