Vlákno názorů k článku ML – funkcionální jazyk s revolučním typovým systémem od dizzy - S tymito vlastnostami som sa stretol v scale...

Buď konkrétní, zajímalo by mě to.

Ještě jsem do něj tak úplně nepronikl, ale co zatím potkal:

- Možnost vrátit se jedním returnem o několik úrovní výš (return@neco)

- Možnost nadefinovat interface, pak tomuhle interfacu (!) v úplně jiném a nesouvisejícím souboru dodefinovat implementaci metody (!) a tu následně volat. Myslím, že se snad dá dodělat i implementace co je viditelná pouze v rámci jedné třídy (?)

- Companion objekty asi OK, ale že se metody objektu vnořeného do třídy objeví na třídě samotné je za hodně WTF

- Když dávám lambdu, tak jako parametr nějaké funkce, tak někdy (!) napíšu tu funkci ale bez (), naopak za její jméno napíšu složenatky {} a do nich tu lambdu.

- Když má funkce jeden parametr, tak ho nemusím deklarovat, ale můžu na něj odkázat pomocí "it".

Třeba tady je takový "hezký" kousek kódu:

something.fold({ it }) { return@synchronized Result.error(it) }

(Pokud to dobře chápu) tak ve skutečnosti jsou to ve složenatkách dva parametry pro tu funkci, akorát jeden z nich je v závorkách a druhý je napsaný jako že je za funkcí, ale vlastně je to stále její paraetr (WTF?!) Používá se magické "it", v prvním případě se nějak magicky vrátí bez nutnosti napsat tam explicitně return, ve druhé případě je ale return asi nutný (a navíc je to varianta co vyskakuje o několik úrovní výš).

8. 2. 2022, 14:39 editováno autorem komentáře

“tak ve skutečnosti jsou to ve složenatkách dva parametry pro tu funkci, akorát jeden z nich je v závorkách a druhý je napsaný jako že je za funkcí, ale vlastně je to stále její paraetr (WTF?!)”

Hehe, to je vskutku matoucí, ale má to i Swift nebo Julia (ta dává za volání funkce první argument, ne poslední, because why not…). To s těmi “dalekými” návraty má tuším Smalltalk a Ruby to má taky nějak divně. Je to prostě jakoby výjimka s unwindingem zásobníku, jen to není spojené s žádnou chybou.

vetsinu z toho bych uvital i v javascriptu/ty­pescriptu

Já tedy ne. Naopak, Typescript považuji za prakticky dokonalý (*) jazyk pro to, co v něm dělám, protože je mocný a přitom jednoduchý a přímočarý.

*) Krom legacy featur typu automatické konverze typů, jejichž nepoužívání kontrolujeme lintem. A krom prototype-based inheritance, ale já stejně inklinuji spíš k funkcionálnímu stylu, třídy vlastně aktivně nepoužívám.

BTW, teď jsem přišel na jednu takovou zajímavou věc. Pokud mám nullable variable, tak u kódu:

if (someObject == null) {
// something
} else {
// else
someObject.whatever
}

v else větvi Typescript ví, že proměnná je not null a tedy je ji možno bezpečně dereferencovat, Kotlin to ale z nějakého důvodu nechápe a vyžaduje před dereferencováním ještě assertion (!!)

Jo, tohle je hezké, Julia to má taky u věcí jako Union{T,Nothing}. Aserce jsou občas vopruz :)

typescript v teto situaci funguje pouze jako linter

Kotlin toto dělá také (říka tomu smart casting), ale pouze pro read-only proměnné (val), pro mutable proměnné (var), si to (obecně) nemůže dovolit, protože hrozí, že hodnotu proměnné změní jiné vlákno.

Kotlin tohle očividně nepotřebuje, typy ctí a má na to idiomy, které nullable typ řeší, např. něco jako

val s: String? = "String"

s?.let { s ->
    println("$s")
} ?: run {
    println("NULL")
}

Dost otřesná syntax, kam na to ty lidi choděj? :|

To je tak, když někdo odvrhne osvědčené řešení - zde konkrétně klasický pattern matching a Option/Maybe. Hezké to moc není, ale jde o zvyk...

No jo, v podstatě by stačilo ML s backendem pro JVM.

Ano, ale i to co chtěl L. výše v Kotlinu funguje bez !!, pokud je someObject val (ne var, viz výše)

val someObject: SomeObject?
// initialize someObject
if (someObject == null) {
    // something
} else {
    // else
    someObject.whatever // <-- smart cast SomeObject? na SomeObject
}

Pochopil jsem, ten lajk, co Ti tam visí, máš ode mě.

Dík za odpověď. Tyhle "zkratky" taky nemusím. Nevidím moc důvod chovat se k jednomu parametru jinak než ke dvěma, resp. důvod chápu, ale ztráta konzistence a ortogonality mi za to nestojí. A ten multi-level return mi taky přijde jako slušný antipattern. Tyhle věci se naštěstí dají pořešit vnitřními pravidly ve firmě. Stejně (jakkoli se JVM nezabývám) bych ale asi pořád dal Kotlinu přednost před Javou.

Je to jen zkrášlení callbacku.

umoznuje to tzv buildery

https://kotlinlang.org/docs/type-safe-builders.html

multilevel return je uzitecna vec, pokud pouzivate napriklad forEach namisto smycky

Přesně z tohoto důvodu to dali do Smalltalku, ten ani klasické smyčky nemá, pokud si dobře vzpomínám.

Tedy takové nové C++?