Ideálny programovací jazyk

[Idris]

To pak ale nic moc neřeší.

Ale jo. Resi to tu nejvetsi (z myho pohledu) bolest Go: mam neco, co chci implementovat pro ruzne typy, a nemusim mit jak dement v interfejsu bambilion uplne stejnych funkci pro jednotlive typy (treba tohle https://godoc.org/go.uber.org/zap#Field je proste k zbliti, jinak se to neda nazvat). Jenom tohle mi prijde, ze pokryva 90% "abstraktniho programovani" ve skutecne praxi.

Bohatě by stačilo, kdyby typové třídy nad HKT používala standarní knihovna (třeba Swift k tomu směřuje), běžný Jouda pak jen použije typ z knihovny, aniž by musel rozumět sofistikované vnitřní implementaci.

Jo, to by asi nebylo uplne blby. Gocko ma uzivatelske typy jenom nulteho radu a v stdlib ma par prvniho radu. Tohle posunout o uroven vys (uzivatelske prvniho radu a v stdlib HKT) by mohlo byt zajimavy. Pokud by to teda slo vymyslet tak, aby to fakt bezny franta programator pobral (tj. aby to nezkomplikovalo typovy system natolik, ze by se v nem nevyznal).

Běžný Franta vůbec nemá co psát typy, pro něj je typová inference. S těmi knihovnami to je také jednoduché, někdo na úrovni prostě napíše supersofistikovaný kód (hezký příklad: http://ericniebler.com/2013/07/16/f-algebras-and-c/) a běžný Franta ho jen přímo používá, aniž by si nad ním musel lámat hlavu. Takto jdou napsat třeba obecné monády v C++ (stejně jako v Haskellu) a pak jen implementovat konkrétní třídy, třeba seznam nebo kontinuaci, přičemž join dostanu zadarmo z bind, nebo fmap apod. Bohužel tohle mainstream moc neumí, ani Java, ani C#, ani Swift. A v tom C++ to sice jde, ale hnusně.

U toho Go - teď trochu odbočuju - vidím jednu velkou výhodu v jednotné volací konvenci. Z praxe - píšu knihovnu pro HPC využívající AVX-512. Normálně bych musel mít i pro amd64 pro různé OS různé verze funkcí v asembleru kvůli odlišným volacím konvencím. V Go rozhoduje jen CPU, pro amd64 napíšu jeden asembler pro všechny OS.

[Reklama]

[Jiří Havel]

Běžný Franta vůbec nemá co psát typy, pro něj je typová inference.

Vetšinou ne, ale občas mi přijde explicitně napsaný typ jako skvělý způsob dokumentace, komentáře a zpřehlednění kódu obecně.

S těmi knihovnami to je také jednoduché, někdo na úrovni prostě napíše supersofistikovaný kód (hezký příklad: http://ericniebler.com/2013/07/16/f-algebras-and-c/) a běžný Franta ho jen přímo používá, aniž by si nad ním musel lámat hlavu.

V ideálním případě by to tak šlo. Ale občas ten Franta narazí na případy kdy se musí skrz ten supersofistikovaný kód prokrokovat. Nebo třeba udělá nějakou obskurnější chybu a bude hledat, co se vůbec stalo. Pokud ten supersofistikovaný kód může vidět, tak musí být schopný mu i _přiměřeně_ rozumět. To, že by to nebyl schopný napsat, je druhá věc.

Takto jdou napsat třeba obecné monády v C++ (stejně jako v Haskellu) a pak jen implementovat konkrétní třídy, třeba seznam nebo kontinuaci, přičemž join dostanu zadarmo z bind, nebo fmap apod. Bohužel tohle mainstream moc neumí, ani Java, ani C#, ani Swift. A v tom C++ to sice jde, ale hnusně.

Zrovna u monád je to "hnusně" docela vážný zádrhel. Monády mi přijdou jako vzor, který je sice všudypřítomný ale vlastně dělá malé věci. Takový druh vzoru jako byla třeba subrutina, než se to usadilo tak, že už o tom ani neuvažujeme jako o vzoru. Takže ty hnusné kousky kódu se pak vyskytují všude. Není to kýbl hnusu, který by se dal zabalit do nějakého modulu, jako jsou třeba windows.h.

U toho Go - teď trochu odbočuju - vidím jednu velkou výhodu v jednotné volací konvenci. Z praxe - píšu knihovnu pro HPC využívající AVX-512. Normálně bych musel mít i pro amd64 pro různé OS různé verze funkcí v asembleru kvůli odlišným volacím konvencím. V Go rozhoduje jen CPU, pro amd64 napíšu jeden asembler pro všechny OS.

Tak tohle mě zaujalo. Proč je to třeba psát v asm? Co brání použití intrinsik?

[Idris]

Běžný Franta vůbec nemá co psát typy, pro něj je typová inference.

Vetšinou ne, ale občas mi přijde explicitně napsaný typ jako skvělý způsob dokumentace, komentáře a zpřehlednění kódu obecně.

S těmi knihovnami to je také jednoduché, někdo na úrovni prostě napíše supersofistikovaný kód (hezký příklad: http://ericniebler.com/2013/07/16/f-algebras-and-c/) a běžný Franta ho jen přímo používá, aniž by si nad ním musel lámat hlavu.

V ideálním případě by to tak šlo. Ale občas ten Franta narazí na případy kdy se musí skrz ten supersofistikovaný kód prokrokovat. Nebo třeba udělá nějakou obskurnější chybu a bude hledat, co se vůbec stalo. Pokud ten supersofistikovaný kód může vidět, tak musí být schopný mu i _přiměřeně_ rozumět. To, že by to nebyl schopný napsat, je druhá věc.

Takto jdou napsat třeba obecné monády v C++ (stejně jako v Haskellu) a pak jen implementovat konkrétní třídy, třeba seznam nebo kontinuaci, přičemž join dostanu zadarmo z bind, nebo fmap apod. Bohužel tohle mainstream moc neumí, ani Java, ani C#, ani Swift. A v tom C++ to sice jde, ale hnusně.

Zrovna u monád je to "hnusně" docela vážný zádrhel. Monády mi přijdou jako vzor, který je sice všudypřítomný ale vlastně dělá malé věci. Takový druh vzoru jako byla třeba subrutina, než se to usadilo tak, že už o tom ani neuvažujeme jako o vzoru. Takže ty hnusné kousky kódu se pak vyskytují všude. Není to kýbl hnusu, který by se dal zabalit do nějakého modulu, jako jsou třeba windows.h.

U toho Go - teď trochu odbočuju - vidím jednu velkou výhodu v jednotné volací konvenci. Z praxe - píšu knihovnu pro HPC využívající AVX-512. Normálně bych musel mít i pro amd64 pro různé OS různé verze funkcí v asembleru kvůli odlišným volacím konvencím. V Go rozhoduje jen CPU, pro amd64 napíšu jeden asembler pro všechny OS.

Tak tohle mě zaujalo. Proč je to třeba psát v asm? Co brání použití intrinsik?

Ano, máte pravdu, já jsem to napsal zkratkovitě, samozřejmě je lepší, když uživatel knihovny aspoň zběžně tuší, jak to funguje pod kapotou. Ta hranice není ostrá, je dobře, že to berete s nadhledem.

K tomu SIMD: Intrinsics mají určitou režii (překladač si pořád řídí proměnné, cykly apod.), v asembleru mám absolutní kontrolu. Navíc v tom Go žádné intrinsics nejsou.