Ideálny programovací jazyk

Idris

  • *****
  • 2 286
    • Zobrazit profil
    • E-mail
Re:Ideálny programovací jazyk
« Odpověď #105 kdy: 11. 05. 2019, 10:38:58 »
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 ;)
Ad 2: Při překladu nebo za běhu?


Re:Ideálny programovací jazyk
« Odpověď #106 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.

Re:Ideálny programovací jazyk
« Odpověď #107 kdy: 11. 05. 2019, 11:08:46 »
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í.

Ok, tak jsem to určitě nemyslel.

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.

Ono je to dejme tomu jako Maybe v Haskellu. Je to sám o sobě typ, tj. to svým způsobem vynutí s tím "Maybe" pracovat správně. Ale ano, null u pointerů se tím člověk nevyhne, a není to třeba tak hezké jako v tom Haskellu.

Re:Ideálny programovací jazyk
« Odpověď #108 kdy: 11. 05. 2019, 11:17:20 »
Ono je to dejme tomu jako Maybe v Haskellu. Je to sám o sobě typ, tj. to svým způsobem vynutí s tím "Maybe" pracovat správně. Ale ano, null u pointerů se tím člověk nevyhne, a není to třeba tak hezké jako v tom Haskellu.
Z mýho pohledu nemusí být Option nějak zvlášť "hezký". Je to prostě parametrizovaný sum type jako jakýkoliv jiný (který v jazyce tak jako tak chci - tj. Option je speciální jenom v tom, že je ve standardní knihovně a používá se všude).

Za nutný ale považuju, aby byl všude, protože jenom tak má smysl - protože za hlavní smysl Option považuju striktní oddělení kódu, kde null může být a kde už ne (už jsem ho ošetřil, dál nemohl probublat). Pokud je Option optional ( ;) ), tak typový systém neumí tyhle dvě situace odlišit, čili nemá informaci, kterou by (snadno) mít mohl a úplně zbytečně ztrácí sílu.

Stejnýho efektu se dá dosáhnout i nějakým atributem "nullable", ale to mi přijde jako zbytečný zaplevelování syntaxe, protože parametrizované sum types chceme tak jako tak...

Re:Ideálny programovací jazyk
« Odpověď #109 kdy: 11. 05. 2019, 11:24:01 »
Jo, ještě jedna podstatná věc: raději bych viděl strukturální než nominální typování. Mj. proto, že nominální se dá v případě potřeby snadno simulovat právě pomocí product types, ale naopak ne (když mám nominální typování, jsem ve zlaté kleci, ze které není úniku ;) ).


Idris

  • *****
  • 2 286
    • Zobrazit profil
    • E-mail
Re:Ideálny programovací jazyk
« Odpověď #110 kdy: 11. 05. 2019, 11:31:31 »
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.
Jsou taková zákoutí, ale IMHO v běžném kódu to jde řešit při překladu. Na šablony v C++ nikdo nenadává.

Re:Ideálny programovací jazyk
« Odpověď #111 kdy: 11. 05. 2019, 11:39:01 »
Na šablony v C++ nikdo nenadává.
To je velice smělé tvrzení! ;)

Idris

  • *****
  • 2 286
    • Zobrazit profil
    • E-mail
Re:Ideálny programovací jazyk
« Odpověď #112 kdy: 11. 05. 2019, 11:47:28 »
Na šablony v C++ nikdo nenadává.
To je velice smělé tvrzení! ;)
Nevím o vážně míněné oprávněné kritice. Neberu argument, že jsou pro BF moc složité ;)

Re:Ideálny programovací jazyk
« Odpověď #113 kdy: 11. 05. 2019, 11:50:30 »
Nevím o vážně míněné oprávněné kritice.
Já za nejpádnější považuju tohle: https://codegolf.stackexchange.com/questions/1956/generate-the-longest-error-message-in-c :))

...ale nechci se do C++ moc navážet, jak říkám, rozešli jsme se před nejmíň deseti lety a nepotřebuju se k téhle epizodě  z mládí vracet :)

gill

  • ****
  • 270
    • Zobrazit profil
    • E-mail
Re:Ideálny programovací jazyk
« Odpověď #114 kdy: 11. 05. 2019, 12:01:06 »
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).

už ti tu několikrát vysvětlili, že v Ruby makra nejsou*. Proč to pořád opakuješ?

* teoreticky AST makra jsou možná, ale nikdo je nepoužívá. Narozdíl od Crystalu nebo Elixiru.
« Poslední změna: 11. 05. 2019, 12:06:33 od gill »

Re:Ideálny programovací jazyk
« Odpověď #115 kdy: 11. 05. 2019, 12:38:56 »
už ti tu několikrát vysvětlili, že v Ruby makra nejsou*. Proč to pořád opakuješ?

* teoreticky AST makra jsou možná, ale nikdo je nepoužívá. Narozdíl od Crystalu nebo Elixiru.
Odstrašující je to, jak se používají obraty, které by se v jiném jazyce dělaly makry (DSLka apod.) - tj. všechno, co umožňuje napsat krátký "hezký" kód, u kterého je ale děsně komplikované zjistit, co a jak vlastně dělá.

Makra slouží ke generování kódu před překladem. U jazyka, který se nepřekládá, samozřejmě striktně vzato neexistují, ale existují obraty, pomocí kterých se dosahuje stejného efektu (kód generuje kód, akorát ne před překladem, který tam prostě není).

Idris

  • *****
  • 2 286
    • Zobrazit profil
    • E-mail
Re:Ideálny programovací jazyk
« Odpověď #116 kdy: 11. 05. 2019, 12:39:25 »
Nevím o vážně míněné oprávněné kritice.
Já za nejpádnější považuju tohle: https://codegolf.stackexchange.com/questions/1956/generate-the-longest-error-message-in-c :))

...ale nechci se do C++ moc navážet, jak říkám, rozešli jsme se před nejmíň deseti lety a nepotřebuju se k téhle epizodě  z mládí vracet :)
Fakt sorry, ale koukni na datum. Clang (a pod tlakem konkurence pak i GCC) mají normální chybové hlášky. MSVC moc ne, no, ale to je Microsoft...

Idris

  • *****
  • 2 286
    • Zobrazit profil
    • E-mail
Re:Ideálny programovací jazyk
« Odpověď #117 kdy: 11. 05. 2019, 12:41:07 »
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).


už ti tu několikrát vysvětlili, že v Ruby makra nejsou*. Proč to pořád opakuješ?

* teoreticky AST makra jsou možná, ale nikdo je nepoužívá. Narozdíl od Crystalu nebo Elixiru.
“Narozdíl” se píše “na rozdíl”, když už chceš machrovat.

Re:Ideálny programovací jazyk
« Odpověď #118 kdy: 11. 05. 2019, 14:40:05 »
Nemyslím to v situacích, kde by šel shared_ptr nahradit pomocí unique nebo move apod. Já se s tím běžně setkávám u grafových algoritmů, kde prostě není jeden vlastník objektu, ale je jich víc rovnocenných. V takovém případě buď použiju shared a daný objekt zmizí s posledním vlastníkem nebo bych si to musel evidovat někde bokem.

Tak je otázkou, jestli by se měly vrcholy vlastnit mezi sebou... U stromů to není problém, ale tam není problém použít unique_ptr. U jiných grafů si dovedu představit, že si je všechny držím v nějaké struktuře a mezi sebou mají jen pointery, nebo seznam id ostatních vrcholů. Se shared_ptr by mohl být problém např. u cyklů, když nad tím přemýšlím...

Představ si to třeba jako když polygony vlastní své nody (a ty jsou sdíleny mezi sousedními polygony). Pokud bych měl evidenci (a tím i životnost) nodů řešit bokem tak to je přesně ten argument, který jsem dal na začátku. S GC mi stačí řešit přímo daný problém a VM se postará o výkon i paměť. V C++ mám na výběr - buď si ten GC musím pro každý algoritmus odsimulovat bokem abych se dostal na úroveň JVM, nebo využiju těch super vlastností C++11, ale poběží to třeba 10x pomaleji. To je ta údajná možnost volby. A tohle se v menší či větší míře děje všude, kde není k dispozici GC. Za to dostanu deterministickou dealokaci, kterou po mě v praxi ještě nikdo nechtěl.

Korektně musim dodat, že JVM přitom sežere násobně víc paměti, ale to mi přijde jako dobrý kompromis. Čas programátora a čas CPU jsou dražší než RAM.

Re:Ideálny programovací jazyk
« Odpověď #119 kdy: 11. 05. 2019, 15:12:37 »
Nemyslím to v situacích, kde by šel shared_ptr nahradit pomocí unique nebo move apod. Já se s tím běžně setkávám u grafových algoritmů, kde prostě není jeden vlastník objektu, ale je jich víc rovnocenných. V takovém případě buď použiju shared a daný objekt zmizí s posledním vlastníkem nebo bych si to musel evidovat někde bokem.

Tak je otázkou, jestli by se měly vrcholy vlastnit mezi sebou... U stromů to není problém, ale tam není problém použít unique_ptr. U jiných grafů si dovedu představit, že si je všechny držím v nějaké struktuře a mezi sebou mají jen pointery, nebo seznam id ostatních vrcholů. Se shared_ptr by mohl být problém např. u cyklů, když nad tím přemýšlím...

Představ si to třeba jako když polygony vlastní své nody (a ty jsou sdíleny mezi sousedními polygony). Pokud bych měl evidenci (a tím i životnost) nodů řešit bokem tak to je přesně ten argument, který jsem dal na začátku. S GC mi stačí řešit přímo daný problém a VM se postará o výkon i paměť. V C++ mám na výběr - buď si ten GC musím pro každý algoritmus odsimulovat bokem abych se dostal na úroveň JVM, nebo využiju těch super vlastností C++11, ale poběží to třeba 10x pomaleji. To je ta údajná možnost volby. A tohle se v menší či větší míře děje všude, kde není k dispozici GC. Za to dostanu deterministickou dealokaci, kterou po mě v praxi ještě nikdo nechtěl.

Korektně musim dodat, že JVM přitom sežere násobně víc paměti, ale to mi přijde jako dobrý kompromis. Čas programátora a čas CPU jsou dražší než RAM.

Ze se ale za tu RAM vzdycky tolik plati, kdyz si nekde porizujes virtualni server. Porovnej treba hostingy PHP vs Java :) No nevim nevim, do jake miry to porekadlo s vykonem a ram plati.

Ja jeste doted zadny svuj virtualni server nemam - protoze delam v Jave a stalo by me to tak moc penez, si neco jen tak ze srandy koupit...

Kdybych delal v PHP, tak mam hosting lusknutim prstu, protoze to stoji par slupek.
« Poslední změna: 11. 05. 2019, 15:16:25 od PetrK »