Příspěvky

1816

Vývoj / Re:Rust vs. C++ (funkcionální vs. OOP)

« kdy: 23. 03. 2016, 22:39:26 »

Prakticky ano, když pošlete zprávu do nějakého objektu, neovlivní to objekt, který zprávu vyslal

Tak pokud ta zpráva nevrací výsledek (u klasických OOP jazyků věc nevýdaná), tak máte pravdu.
Stejně jako funkce, která je volána jinou funkcí není ovlivněná volanou funkcí.

třída z jiného objektu převezme jen stav, který umí zpracovat, cokoliv jiného vyvolá chybu.

ve FP je to stejné, funkce převezme jen parametry které umí zpracovat, cokoliv jiného vyvolá chybu.

A?

V FP při řetězení funkcí map, filter, reduce chyba častěji než u OOP projde do dalšího kroku, asi tak, jako když na montážním pásu, kde montují automobily, zapomenou namontovat kliku u dveří. V jednom kontextu to vadit nebude, v jiném ano.

Nedovedu si představit, proč by tento problém nemohl vzniknout při zřetězení objektů.

1817

Vývoj / Re:Rust vs. C++ (funkcionální vs. OOP)

« kdy: 23. 03. 2016, 22:31:55 »

Rozsah škod u FP bude ale větší právě proto, že funkce nejsou vázány na nějaký pevně daný kontext, není zachován řetěz dědičnosti, to která funkce uvnitř používá kterou funkci není nějak explicitně zaznamenáno, spontánně vzniklé struktury závislostí budou daleko složitější.

To je divný, nic z toho nepozoruji.

to která funkce uvnitř používá kterou funkci není nějak explicitně zaznamenáno

Hele, uvědomujete si, že základem FP je imutabilita, tudíž řešit něco takového je prostě absurdně zbytečné?

Když umíte tak šikovně popsat katastrofické scénáře které díky FP proběhnou, uveďte alespoň nějaký příklad toho, kdy by vámi uváděný problém mohl vzniknout.

1818

Vývoj / Re:Rust vs. C++ (funkcionální vs. OOP)

« kdy: 23. 03. 2016, 22:25:23 »

Ale použijete-li v rámci nějaké funkce jinou funkci, už na tom kontextu záleží, už to samo o sobě vytváří závislost, změnou té vnitřní funkce dojde ke změně chování té vnější funkce

To není specifikum FP.

a to se uhlídat nedá

Ale dá, existují na to různé přístupy, například testování. (Předpokládám, že narážíte na situaci, kdy někdo změní chování funkce.)
A opět, to není specifikum FP. V OOP je to taky, a mnohem horší, protože se tam toho musí hlídat mnohem více.

protože nikde nemáte uschovanou definici závislostí

máme, jmenuje se to closure

což u OOP koncetptu existuje (dědičnost, privátní proměnné).

což nesouvisí se závislostmi, ale s mutabilitou.

Pracně se to bude pak přepisovat do tříd, aby se alespoň rámcově vědělo, co s čím souvisí.

Blbé je, že čím více a více získávám zkušeností z praxe, tím více OOP ohejbám do FP. Takže vaše odvážné tvrzení nemohu potvrdit.

Mimochodem nejsou třídy jako třídy, viz Haskell :-P

1819

Vývoj / Re:Rust vs. C++ (funkcionální vs. OOP)

« kdy: 22. 03. 2016, 12:59:18 »

Nejspíš ze stejného důvodu, proč se prakticky nepoužívá čisté logické programování. Nehodí se na vše, procedurálně se často píše lépe.

Ale už se tak dobře nečte.

1820

Vývoj / Re:Rust vs. C++ (funkcionální vs. OOP)

« kdy: 22. 03. 2016, 11:56:45 »

Wirthovy snahy vybudovat jazyk, který by svou konstrukcí vedl k přehlednému programování v praxi taky vzaly za své, přehledné programování je výsledkem vnitřní disciplíny, ne jazyka, který používáte.

A není to poněkud škoda?

1821

Vývoj / Re:Rust vs. C++ (funkcionální vs. OOP)

« kdy: 22. 03. 2016, 11:55:05 »

Evidentně dědičnost nějak rozumně nahradit nejde a jestli ano, tak za cenu flexibility => ve výsledku nemá cenu na něco se složitým datovým modelem používat funkcionální jazyk tohohle typu. Souhlasíte?

Nesouhlasím.

Na složitý datový model je funkcionální jazyk naprosto vyhovující. (Zda Rust, je spíše otázka stability jeho samotného, než toho, že je funkcionální.)

Dokonce jsem nabyl dojmu, že objektové programování (tak jak jej známe) a dědičnost nejsou nijak zvláště užitečné, a neosvědčilo se to.

To soudím na základě zkušeností z projektů různých úrovní složitosti i různého skillu vývojářů, ke kterými jsem kdy přišel. Ono samozřejmě vytvářet nový projekt od základu je něco jiného. Tam je to fuk, protože si všechno pamatujete. Ale přijít k existujícímu projektu a zorientovat se v tom... OOP není nutně špatné, ale výceúrovňová dědičnost vysloveně zatemňuje.

1822

Vývoj / Re:Jak správně programovat v PHP / MySQL

« kdy: 07. 11. 2015, 03:28:07 »

... všechny změny průběžně zanášíte do repositáře zdrojových kódů (git, fossil, mercurial, ...)...

Ten fossil fakt používáš? Nebo znáš někoho, kdo ho používá?

1823

Vývoj / Re:Java a statické metody

« kdy: 23. 10. 2015, 23:30:44 »

Zádný přínos? Takže to že tímhle vytažením zviditelním a tím zabetonuju kus vnitřností nějaké třídy ničemu nevadí? Já si naopak nepamatuju situaci, kdy bych měl potřebu nějaké třídě kecat do toho, jak si uvnitř transformuje data.

No, tohle je za celé vlákno jediná zajímavá poznámka.

Je pravda, že do toho mohu vstříknout objekt, který bude mět sice naprosto stejnou signaturu, ale zcela jiné chování. Jenže, opravdu?

Funkce sin() vždycky vrátí číslo. Můžu nějak záviset na tom, zda to číslo bude platné? (Skutečnost, že díky neplatnému sin() nemůžu očekávat platné hodnoty volajícího je samozřejmá.)
Když mi bude funkce vracet pole, a to pole nebude obsahovat správné hodnoty, tak by mi signatura měla zajistit, že to celé nerozbije, ale, že to bude počítat špatně, to je očekávatelné. Součást signatury je neurčitelnost, kolik návratových hodnot mi to v tom poli vrátí. Takže to musím doladit ifama.

Na druhou stranu, pokud defaultní implementace je řešená s chybou, tak tu chybu nemohu opravit, protože tato třída na tom závisí, a já nemohu vědět, zda o té chybě volající ví, nebo ne.

Zajímavé.

1824

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 16. 09. 2015, 17:15:30 »

Prostě to kváká jako kachna, tak je to kachna. Co víc chtít?!

Todle mi třeba vadí:

Kód: [Vybrat]

interface Foo
{
    string quak();
}

interface Doo
{
    string quak();
}

class DuckFoo implements Foo { .. }
class DuckDoo implements Doo { .. }

print(? duck) {
   std.out.print(duck.quak())
}

print(new DuckFoo)
print(new DuckDoo)

1825

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 16. 09. 2015, 13:36:20 »

https://developer.apple.com/videos/wwdc/2015/?id=408

vypadá to jako Type Classes z Haskellu (které jsou prý nic proti Modules z OCamlu) nebo se mi to zdá?

Nezdá

Mě jako haskellistu by moc zajímali podrobnosti. Nemáš nějaký pěkný pokec o tom? Nebo to tu alespoň trochu rozveď.

1826

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 15. 09. 2015, 12:02:11 »

A FP jazyky ji mají přímo katastrofální.

Tak to určitě...

1827

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 14. 09. 2015, 21:29:14 »

... mladé nástroje, nevyzrálý ekosystém, ...

https://www.haskell.org/cabal/ bylo pro mě nádherné mlsání.

1828

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 14. 09. 2015, 15:30:30 »

Uzivaji se co nejefektivnejsi datove typy (tusim pole id bloku - primitivnich intu; overhead pri pouziti napr. Map[(Int,Int,Int),Int] by byl primo monstrozni).

Tady se moc nechytám co přesně myslíš. Navíc mám nezdravou důvěru v optimalizátor GHC :-) Asi by to chtělo konkrétní příklad.

Na entitach si to celkem predstavit jde (je jich pouze par, v pripade MC tak do stovky v okruhu viditelnosti), ale v pripade bloku? Mit stromy i pro bloky, napr. pro kazdy blok lavy (blok vyskytujici se v "prirode", tj. muze byt ve velkem mnozstvi soucasti sveta), ...

Mluvím-li o entitách, tak mluvím i o neživých věcech. Jako entitu jsem měl cokoliv, co mohlo reagovat s okolím. Aktivně, nebo jen klást odpor.

V zaveru mi z toho tedy vyplyva, ze by musela zustat stavajici reprezentace (pouzivat strom pro meshovani sveta si myslim rozumne nepujde) a paralelne udrzovat strom ovlivnitelnosti. Pomoci nej paralelizovat tick a z vysledneho seznamu zmen paralelne zpracovat vsechny chunky zaraz (prikazy pro 1 chunk tedy budou sekvencni, coz nevadi, maloktere (?) pouzivane cpu ma vice nez 400 jader). Je otazka, zda rezie spjata s udrzovanim/generovanim stromu a rozdelovanim prace (seznam zmen) nevyjde hur, nez stary jednodussi pristup (tyto zmeny se budou bezne provadet klidne nekolikrat do vteriny, pokud budou trvat dele nez jeden frame, tak se hra zacne "skubat"; anebo by se muselo zacit resit nejaky "shadow world" ala "shadow dom", to ale nevim, jestli by pametove fungovalo).

Možná si jen nerozumíme, protože mi přijde, že popisuješ to co jsem měl na mysli já. Plus-mínus :-)

1829

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 14. 09. 2015, 13:27:21 »

Nezapomínej, že to rozdělení musí být logické, ne adminstrativní.

Logicke rozdeleni to je z pohledu vykonu - pri kazde zmene chunku (napr. zniceni bloku) je treba znovu vytvorit mesh (3d "model" chunku, rendrovat blok po bloku to opravdu nejde, vytvori se jen model s viditelnymi stranami bloku), coz je draha operace a pri nevhodne velikosti to povede k vykonostnim problemum (velky chunk -> casteji a dlouho se generuje, maly chunk -> vice rezie).

A klidně to můžeš dělat i během života (postaví zeď atd).

Po pravde, az takto dynamicke rozdelovani sveta zni velmi narocne. Kdyz si vezmu, ze jen hloupy algoritmus pro svetlo (trivialni flood-fill, navic s podstatne nizsim polomerem nez je napr. dostrel luku) pusobi vykonostni problemy.

Chyba v úvaze je v tom, že předpokládáš, že ten objekt něco renderuje.

Logické rozdělení je to z pohledu toho, zda se mohou elementy ovlivňovat.

Zkus si představit jednoduché lineární pole objektů (pańáců a pomerančů). Pak můžeš mět jakýsi strom, který určuje, kde se které větve mohou ovlivňovat. Sourozence můžeš paralelizovat (když si to čtu, tak to zní děsivě, ale popisuji spíše potenciál, protože v praxi by to byl spíš takovej keř). A v každém ticku se ti v tom stromu provedou výpočty a v kořeni ti vypadne seznam všech změn, které musíš provést na scéně. Až tady máš to místo, kde budeš renderovat. A kde můžeš perfektně optimalizovat (zničení chunku, a vygenerování už finálního se všemi elementy, renderování jen viditelné scény, atd). A díky tomu, že mám seznam všech změn, mohu zkusit paralelizovat i to renderování.

Jak by se to dalo dělat lépe? JS navrhoval Monády, ale (pravděpodobně díky nedostatku zkušeností) bych se bál aby mi z toho nevylezl podobnej nepřehlednej mrdník, jaký obhajuje gamer u svého mutable řešení.

1830

Vývoj / Re:Omezená dědičnost (je něco lepšího než OOP?)

« kdy: 13. 09. 2015, 23:07:34 »

To zni zajimave, bohuzel si nejsem jisty, jestli to muze vsude fungovat - napr. ten zminovany Minecraft. Kdyz mam svet rozdeleny na casti (chunky - 16x16x256 bloku IIRC), tak hrac na kraji jednoho chunku zcela jiste muze (a casto bude) interagovat z blokem z jineho chunku. Mozna to rozsekat podle maximalniho mozneho dosahu jakekoliv interakce s prostredim, nebo podle dohlednosti? Co jsem kod videl posledne, tak se to proste neresilo - pro kazdy svet bylo vse serializovane (ticky bloku, entit, tile entit).

Nezapomínej, že to rozdělení musí být logické, ne adminstrativní. A za druhé, rozdělovat to můžeš a nemusíš. A klidně to můžeš dělat i během života (postaví zeď atd).