Příspěvky

1246

Vývoj / Re:Ideálny programovací jazyk

« kdy: 11. 05. 2019, 11:01:42 »

Teď to neber špatně, ale když jsme tu diskutovali o JavaScriptu, tak standard ani dokumentace nebyly směrodatné, tak mě překvapuje, že máš potřebu to psát do dokumentace.

To je nepochopení. Já jsem to vnímal tak, že ty argumentuješ, že "když je to v dokumentaci, tak to není problém - prostě RTFM!". Můj argument byl, že to je kontraintuitivní zhovadilost a to, že to je v dokumentaci, na tom nic nemění.

Makra jsou na některé specialitky velice užitečný nástroj. Zároveň jsou ale nebezpečná v tom, že běžný Franta programátor bude jejich silou tak omámen, že je začne používat na věci, kde reálně potřeba nejsou, a kód se tím objektivně strašně znečitelní a zprasí (odstrašující příklad je Ruby). Tohle nebezpečí se dá snížit váhou manuálu a názoru komunity. Např. v Elixir komunitě tohle povědomí je a ta hrůza, ke které došlo v Ruby světě, se tam neděje.

Souhlasím. Co takové std::optional v C++ ? To je taky "option navíc", nebo je to trošku dál?

Nevím, C++ (už) neznám, ale obecně si myslím, že pokud Option není jediný způsob řešení "prázdných hodnot", tak jako by nebyl vůbec.

Ad 2: Při překladu nebo za běhu?

Ideálně kompletně už při překladu. Ale neumím od stolu tvrdit, že nejsou nějaká zákoutí, která je potřeba aspoň částečně řešit za běhu. Pokud by nebyla, byl by to z mýho pohledu ideální stav.

1247

Vývoj / Re:Ideálny programovací jazyk

« kdy: 11. 05. 2019, 10:18:07 »

ale to, co jsi psal, prostě celkem přesně sedí

P.S. já osobně bych od moderního jazyka chtěl spíš věci jako:

1. má dobře vyřešenou správu balíčků a jejich závislostí
2. má aspoň nějakou formu generik nebo jiný mocný mechanismus psaní abstraktního kódu
3. má homoikonická makra (ale v dokumentaci je palcovým písmem napsáno, že se nemají zneužívat tam, kde opravdu nejsou potřeba)
4. má pattern matching
5. překladač se snaží seč může odhalit chyby při překladu (a jazyk mu v tom jde naproti)
6. vůbec nemá null, místo něj je Option
7. má alespoň jednoduché algebraické typy

...což jsou přesně painpointy Gočka...

Příklad pokročílé vlastnosti ad 1: Elm umí sám detekovat změnu API a vynutí povýšení sémantické verze při pushnutí balíčku.

ad 5: například relativně jednoduchá, ale strašně užitečná featura překladače, je kontrola vyčerpávajícnosti pattern matchingu (např. když matchuju enum, musím pokrýt všechny zadefinované varianty).

ad 6: Option "navíc", jako možnost, což u některých jazyků je, je k ničemu - pokud je null "občas někde", musím ho čekat všude a tímpádem Option ztrácí význam.

ad 7: stačí jednoduché sum a product types (sorry, nevím, jak se "product type" překládá do češtiny). Praktické hlavně pro jednoduché použití silně typovaných tuples. Praktičnost vylítne do nebes ve spojení s pattern matchingem.


...takže mi do toho sedí spíš Rust než Go

1248

Vývoj / Re:Ideálny programovací jazyk

« kdy: 11. 05. 2019, 10:04:24 »

Na to jsem myslel, proto jsem měl napsat, že jediná správná syntax je prefixová, čili

Kód: [Vybrat]

int i = 0

Z dokumentace zrovna vidim

Kód: [Vybrat]

var i, j int = 1, 2

vždyť to je strašný.

Vůbec to není strašný, je to jenom ze začátku nezvyk, který ale člověk rychle překoná. Rozhodně je to nekonečně lepší syntax než céčkový "zápis do spirály" (šnekfixový zápis? ), což je naprostá zhůvěřilost, která nikdy neměla vzniknout.

Dále už bylo mnoho napsáno o řešení výjimečných stavů v go...

Go má spoustu ujetostí a v praktickém používání mě hodně zklamalo, ale to, co jsi psal, prostě celkem přesně sedí

1249

Vývoj / Re:Ideálny programovací jazyk

« kdy: 11. 05. 2019, 09:57:59 »

Myslim, ze to je v Rustu, i kdyz jsem o rom cetl jen letmo, ze = pro objekty je automaticky move. To se mi libi oproti c++.

Jo, ale jenom pokud pro typ není definován trait Copy.

Viz https://doc.rust-lang.org/std/marker/trait.Copy.html a https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html - hlavně část "Ways Variables and Data Interact: Move" a následující.

1250

Vývoj / Re:Ideálny programovací jazyk

« kdy: 10. 05. 2019, 17:06:23 »

Syntaxe by se měla držet osvědčených zvyků ohledně operátorů, závorek atd., některé nové jazyky to zbytečně prohazují. Dál základní OOP, funkcionální prvky, aby stačilo říct "co" místo "jak". Takže streamy (ale jednodušší než v javě), lambdy, konstantní objekty...

Rozhodně musí mít GC, ruční správa paměti je ve většině případů špatná věc. Stejně tak by se programátor neměl starat o to, zda budou data na stacku nebo heapu, tohle zvládne překladač či runtime dost dobře sám. C++11 jasně ukazuje, že je špatný nápad tím prasit jazyk a že z toho cesta nevede. Smart pointery, move semantika atd. to ve výsledku ještě zhorší.

A bylo by hezké, kdyby měl nějak snadno zvládnuto ORM, JSON, HTTP, prostě napojení na běžné okolní prostředí.

Skoro přesně jsi popsal Go

1251

Vývoj / Re:Jak funguje Call/CC?

« kdy: 10. 05. 2019, 15:12:09 »

to neni, nepamatuje si stav programu a neumoznuje se vratit zpet na misto sveho vytvoreni.

Jak myslíš, nemám potřebu se hádat.

Cemu ty rikas kontinuace, je databazovy kurzor.

Neříkám tomu tak já, ale autoři Erlangu.

1252

Vývoj / Re:Jak funguje Call/CC?

« kdy: 10. 05. 2019, 15:03:39 »

to nema s kontinuaci, o ktere tu diskutujeme, nic spolecneho.

Je to přesně to, co jsi citoval z té Wikipedie:

a continuation is an abstract representation of the control state of a computer program. A continuation reifies the program control state, i.e. the continuation is a data structure that represents the computational process at a given point in the process's execution

https://en.wikipedia.org/wiki/Continuation

1253

Vývoj / Re:Ideálny programovací jazyk

« kdy: 10. 05. 2019, 14:56:59 »

Ok, už asi trochu tuším, o co jde Dík.

1254

Vývoj / Re:Ideálny programovací jazyk

« kdy: 10. 05. 2019, 10:30:27 »

Měl jsem na mysli hlavně velikost známou až v runtimu. Jedna věc jsou dočasné proměnné. Ty jsou v pohodě, i když najednou nutně potřebujeme registr pro frame pointer. Druhá věc je ale vracení objektu neznámé velikosti hodnotou. Volající neví kolik paměti vyhradit a volaný to taky nezvládne alokovat bez větších problémů. Musel by ten zásobník přeskládat. Neznám žádné volací konvence, které by něco takového uměly.

Já ty lowlevel detaily dobře neznám a C++ jsem viděl naposledy tak před deseti lety, takže mi asi spousta věcí uniká, ale čistě od stolu mě překvapuje, že je to problém. Přijde mi, že by stačily dvě čísla na začátku: velikost Derived a offset Base v rámci Derived. Pokud potřebuju Derived někam zkopírovat, vím jeho velikost a víc nepotřebuju. Pokud potřebuju šahat do Base, vím jeho offset, což je taky všechno, co potřebuju.

1255

Vývoj / Re:Ideálny programovací jazyk

« kdy: 10. 05. 2019, 10:06:41 »

Pak je otázka, jestli se taky člověk bez takovéhoto embeddingu obejde.

Jasně, to je legitimní otázka. A odpověď jsem už naťukl: v C se bez něj obejdeš, protože Base je skutečně explicitně embeddovaný - je to prostě field v Derived. Čili podle mě je to v Go čistě syntaktický cukr, kdy místo d.Base napíšeš d a překladač to pochopí. Z toho vyvozuju, že všechno by mohlo zůstat jak je, jenom bys musel psát d.Base. Neumím si představit cokoli, o co by tím jazyk přišel.

1256

Vývoj / Re:Ideálny programovací jazyk

« kdy: 10. 05. 2019, 09:49:46 »

taky nebudu kritizovat Porsche Carrera, že s ním nemůžu orat pole, na základě toho, že jsem si myslel, že to jde.

Janže ono to jde a není to žádná obezlička, je to jasná součást jazyka - Derived můžu předat do funkce, která očekává Base. Nepředávám d.Base, předávám d. Je to nejspíš jediná situace, kde se v Go může předávat jiný typ než očekávaný.

A protože to není intuitivní, vyžaduje to explicitní vysvětlení:

There's an important way in which embedding differs from subclassing. When we embed a type, the methods of that type become methods of the outer type, but when they are invoked the receiver of the method is the inner type, not the outer one. In our example, when the Read method of a bufio.ReadWriter is invoked, it has exactly the same effect as the forwarding method written out above; the receiver is the reader field of the ReadWriter, not the ReadWriter itself.

https://golang.org/doc/effective_go.html#embedding

Není to ani čisté skládání (jako v C), ani subtyping. Je to takové divné "něco mezi" s vlastnostmi, které si člověk musí pamatovat, protože nikde jinde to tak nefunguje (naštěstí jich není moc).

1257

Vývoj / Re:Ideálny programovací jazyk

« kdy: 10. 05. 2019, 09:37:07 »

Když takhle napíšu Base, jde o kompozici. Jak jinak by to asi mělo fungovat?

Problém je v tom, že se to na první pohled tváří jako subtypový polymorfismus (Derived můžu předat do funkce, která očekává Base), ale ve skutečnosti to tak není. Protože to může běžného frantu programátora zmást, možná by neškodilo víc explicitnosti:

Kód: [Vybrat]

func f(b Base) {
 ...
}

...

d := Derived{...}

// ok
f(d.Base)
// err
f(d)

- pokud by to bylo takhle, bylo by na první pohled jasné, že do f předávám jenom část d.

...ale nechci autorům Go radit, chtěl jsem jenom říct, že taková nepříjemná zákoutí nejsou jenom v C++, ale bohužel i v Go, které jinak lidi mají za dost čistý a konzistentní jazyk.

1258

Vývoj / Re:Ideálny programovací jazyk

« kdy: 10. 05. 2019, 08:50:46 »

Navíc ten kód není zrovna idiomatický.

Ten kód jenom ukazuje, co se tam děje. Jinak to ukázat najde (AFAIK), takže tuhle výhradu neberu.

Jedním slovem: non-issue.

Může to být issue pro lidi, kteří mají subtypový polymorfismus pod kůží, chtějí nadesignovat kód tak, jak jsou zvyklí (předám někam Derived jako Base, něco se s tím děje, pak to dostanu zpátky a přetypuju si zase na Derived), a ejhle: ono to v Go takhle nejde

Jasně, správný Go řešení je použít interfaces, o tom se nehádám, jenom říkám, že to může být pro někoho docela překvapení. Mně osobně tenhle "supersilnej nominalismus" ("objekt" se chová ne podle toho čím je, ale podle toho, jaký typ je v kódu u něj napsaný) mně osobně moc nevyhovuje.

1259

Vývoj / Re:Ideálny programovací jazyk

« kdy: 10. 05. 2019, 08:16:16 »

Aby volající kód mohl kopírovat neznámý odvozený typ, musel by mít k dispozici něco jako "virtuální kopírovací konstruktor" + podporu objektů neznámého typu na zásobníku.

To by bylo možná lepší řešení - na způsob Copy traitu v Rustu.

Co si mám představit pod "podporu objektů neznámého typu na zásobníku"? Funkce s těmi daty nic nemusí dělat, musí je umět jenom zkopírovat a vědět, kde začínají data, kterým rozumí. Ostatní může v klidu ignorovat, ne?

1260

Vývoj / Re:Ideálny programovací jazyk

« kdy: 10. 05. 2019, 08:02:36 »

Jenom tak na okraj: v Go se slicing dělá i s pointery, je to jedna z věcí, které mě na Go fakt štvou. Při volání se prostě předá ukazatel opravdu jenom na ten typ, ktery v hlavičce je (tj. jenom embedded struct Base). Je to sice konzistentnější při jednom použití (volání odkazem i hodnotou se chová stejně), ale zase je nekonzistentní, že když tu samou funkci volám přímo na structu a nebo až uvnitř funkce, kam jsem struct předal, výsledek je jiný (tím voláním funkce se "vyřízne" jenom embedded struct):

https://play.golang.org/p/MCmwySyPQpl