Ideálny programovací jazyk

[Jiří Havel]

Takže nakonec to přece jenom bude JavaScript? ;-) (Spread operátor na objektových literálech v ECMAScript 2018.)

JS není špatný v principu, ale v tom, že se tam doprasilo co mohlo. Lua je "JS done right", nezaznamenal jsem, že by s ní kdokoli měl problém. Ne že by to byl jazyk, ve kterém bych nějak zvlášť chtěl dělat, ale je to jazyk hodný respektu.

S Luou občas dělám. Ta kombinace minimalismu a síly je opravdu výjimečná. Dost lidí se na ní AFAIK nelíbí indexování polí od jedničky, ale to je podle mě detail.
Co mi na ní opravdu vadí je dynamické kachní typování. I hodně stupidní překlepy odhalím až k nim program dojde. A ne všechno se dá otestovat pomocí malých a rychlých testů. Takže to občas vypadá tak, že dlouho čekám, pak opravím nějakou blbost a to celé několikrát dokola.

[Reklama]

[Mirek Prýmek]

Smysl to dávalo, neměl jsem možnost to pořádně prozkoumat praxí. A dráždí mě tam ta evidentní ukecanost.

Podle me tech domen, ktere skutecne jdou modelovat hierarchii bez jakychkoli cyklu (treba i "weak linku"), je naprosty minimum. Zavadet kvuli nim vec, ktera jazyk netrivialne zesloziti (kovariance, kontravariance, ...) proste a jednoduse nestoji za to

Ano. Psal jsem o traitech a mixinech. To považuji za vhodného kadidáta.

Jj. Ale dabel je v detailu. O Go jsem si myslel, ze jde presne spravnou cestou, dokud jsem ho nezacal pouzivat a nenapsal v nem neco aspon trochu abstraktniho, coz bylo dost utrpeni

Na vztahy jsem uvažoval v duchu Prologu. Ale zatím jsem nic nevymyslel :-)

Hlavne s tim nic nevymyslej, abys promatkuprirodu nahodou nevymyslel neco, co byse mohlo chytnout!

Prolog je uzasnej jako "inteligentni databaze". Ale programovat v tom "imperativne" je jak zvykat si jazyk do krve a strilet se pri tom do nohy, to cely za zvuku TV Slagr.

Docela se mi na jednom pokusu osvedcila kombinace normalni jazyk na logiku a "control" + embeddovany prolog na rozhodovani. To bylo celkem poteseni s tim delat, protoze obe casti delaly, co umi nejlip, a ani jednu jsem neznasilnoval k necemu, do ceho se ji moc nechce...

[Mirek Prýmek]

Co mi na ní opravdu vadí je dynamické kachní typování. I hodně stupidní překlepy odhalím až k nim program dojde. A ne všechno se dá otestovat pomocí malých a rychlých testů. Takže to občas vypadá tak, že dlouho čekám, pak opravím nějakou blbost a to celé několikrát dokola.

Njn, to je dan za dynamicnost. Proto rikam, ze bych s ni (neco vylozene vaznyho) moc delat nechtel.

[Mirek Prýmek]

Nic mi nedokážete, všechno popřu.

[BoneFlute]

Ano. Psal jsem o traitech a mixinech. To považuji za vhodného kadidáta.

Jj. Ale dabel je v detailu. O Go jsem si myslel, ze jde presne spravnou cestou, dokud jsem ho nezacal pouzivat a nenapsal v nem neco aspon trochu abstraktniho, coz bylo dost utrpeni

Něco konkrétnějšího by nebylo?

Na vztahy jsem uvažoval v duchu Prologu. Ale zatím jsem nic nevymyslel :-)

Hlavne s tim nic nevymyslej, abys promatkuprirodu nahodou nevymyslel neco, co byse mohlo chytnout!

Slibuju. Až to vymyslím, tobě to natruc neřeknu.

Prolog je uzasnej jako "inteligentni databaze". Ale programovat v tom "imperativne"

Protože od toho Prolog není. Právě proto píšu, že na vztahy.

[Reklama]

[Mirek Prýmek]

Něco konkrétnějšího by nebylo?

Uz jsem tady o tom nekdy psal, nechci se opakovat. A hlavne to byly takovy veci, ktery se tezko vysvetluji, aniz bych popsal celej problem a pulku zdrojaku Proste jsem z toho jazyka byl zklamanej, no. A nejkonkretnejsi uroven, na ktere se mi to chce rozebirat je asi tahle: prijde mi, ze ten jazyk ma strasne nizkou schopnost vyjadrovat abstraktni myslenky. Nejvic asi kvuli chybejicim generikum, ale nejenom. Ja tam nekolik takovych veci, ktery samy o sobe vypadaji jako drobnost (napr. https://forum.root.cz/index.php?topic=21149.msg310682#msg310682 ), ale jako celek mi to proste pro cokoli abstraktniho nevoni. Zas ale na jednoduche, predem zname a dobre analyzovane problemy, je to docela dobrej jazyk (z tech dost mainstreamovych, aby je davalo smysl pouzivat).

Takove celkem slusne nizkoprahove centrum pro deti a mladez

Slibuju. Až to vymyslím, tobě to natruc neřeknu.

Fair enough!

Protože od toho Prolog není. Právě proto píšu, že na vztahy.

Jj, ale to uz pak nemas jazyk jako takovy, spis nejaky jeho doplnek - modul, databazi, subsystem... Jo, v takove roli mi Prolog dava smysl skvele.

[Idris]

K tématu:

Uvažoval jsem, že některé vlastnosti OOP se moc neosvědčili. Dědičnost a abstraktní třídy, vzor template method. Místo toho mixiny, nebo traity. Tedy znovupoužitelné fragmenty kódu, bez zanášení typu. Jestli ponechat dědičnost na úrovni rozhraní, nebo ani v tomto případě ne?

Jop, type classy z Haskellu a traity z Rustu jsou asi nejlepší přístup k polymorfismu, co jsem zatím potkal. Koncepty v novém C++ se tím hodně inspirovaly, takže vypadají taky až překvapivě dobře.

Dědičnost bych nezavrhoval úplně, ale souhlasím že pro intuitivní implementaci vztahu "is-a" se moc nehodí. I když se tak často prezentuje.

Typové třídy bohužel vyžadují higher kinded types, kteréžto má z mainstreamu (částečně) jen C++.

[Kit]

Jestli ponechat dědičnost na úrovni rozhraní, nebo ani v tomto případě ne?

Co dobrého a netriviálního by podle tebe přineslo to mít? Já mám pocit, že dědičnost kdekoli dělá víc škody než užitku*.

To úplně tak promyšlený nemám. Jednou jsem si hrál s něčím takovým:
Article
ArticleIdentification <- Article
ArticleSlugIdentification <- ArticleIdentification
ArticleIdIdentification <- ArticleIdentification
ArticleFullIdentification <- ArticleIdentification
ArticlePreview <- Article, ArticleIdentification
ArticleDetail <- Article, ArticleIdentification
ArticleModify <- Article, ArticleIdentification, Command
ArticleCreate <- Article, Command

Smysl to dávalo, neměl jsem možnost to pořádně prozkoumat praxí. A dráždí mě tam ta evidentní ukecanost.

Smysl to nedává, protože už u "ArticleIdentification <- Article" je porušeno zmíněné pravidlo "is-a". Následující identifikátory na tom nejsou lépe.

[gill]

Něco konkrétnějšího by nebylo?

Uz jsem tady o tom nekdy psal, nechci se opakovat. A hlavne to byly takovy veci, ktery se tezko vysvetluji, aniz bych popsal celej problem a pulku zdrojaku Proste jsem z toho jazyka byl zklamanej, no. A nejkonkretnejsi uroven, na ktere se mi to chce rozebirat je asi tahle: prijde mi, ze ten jazyk ma strasne nizkou schopnost vyjadrovat abstraktni myslenky. Nejvic asi kvuli chybejicim generikum, ale nejenom. Ja tam nekolik takovych veci, ktery samy o sobe vypadaji jako drobnost (napr. https://forum.root.cz/index.php?topic=21149.msg310682#msg310682 ), ale jako celek mi to proste pro cokoli abstraktniho nevoni. Zas ale na jednoduche, predem zname a dobre analyzovane problemy, je to docela dobrej jazyk (z tech dost mainstreamovych, aby je davalo smysl pouzivat).

existuji alternativy

https://crystal-lang.org/

[Mirek Prýmek]

Typové třídy bohužel vyžadují higher kinded types, kteréžto má z mainstreamu (částečně) jen C++.

Ono by (aspoň teoreticky) šlo mít i typové třídy jenom prvního řádu, ne? Nešlo by pak definovat takové třídy jako Functor, ale šlo by udělat Vector[T], kde T je proper type. To by možná mohlo z praktického/pragmatického hlediska celkem i stačit, ne? Java to tak má/měla, ne?

[Mirek Prýmek]

existuji alternativy

https://crystal-lang.org/

Jo, jazyků je bambilion. V tom problém není. Problém je tradeoff mezi rozumností jazyka a dostatečným rozšířením a supportem.

[gill]

existuji alternativy

https://crystal-lang.org/

Jo, jazyků je bambilion. V tom problém není. Problém je tradeoff mezi rozumností jazyka a dostatečným rozšířením a supportem.

https://github.com/veelenga/awesome-crystal

[Mirek Prýmek]

https://github.com/veelenga/awesome-crystal

Jde spis o lidi nez o knihovny...

[Idris]

Typové třídy bohužel vyžadují higher kinded types, kteréžto má z mainstreamu (částečně) jen C++.

Ono by (aspoň teoreticky) šlo mít i typové třídy jenom prvního řádu, ne? Nešlo by pak definovat takové třídy jako Functor, ale šlo by udělat Vector[T], kde T je proper type. To by možná mohlo z praktického/pragmatického hlediska celkem i stačit, ne? Java to tak má/měla, ne?

To pak ale nic moc neřeší. 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.

P.S. (mírně OT) V souvislosti s tímto se mi do ruky nedávno dostal nový výukový text o monádách a myslím, že trefili funktor na hlavičku.

[Mirek Prýmek]

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).

P.S. (mírně OT) V souvislosti s tímto se mi do ruky nedávno dostal nový výukový text o monádách a myslím, že trefili funktor na hlavičku.

Horim zvedavosti Mas odkaz? (pripadne muzes poslat PM?)