Názory k článku ML – funkcionální jazyk s revolučním typovým systémem
-
Tyjo pořád víc si říkám, kolik se někde mezi lety řekneme 1985-1990 udělalo v IT špatných rozhodnutí, za které platíme dodnes. Co to bylo u ML, že se neprosadilo? Možná neexistoval překladač pro PC? Ten koncept typů v ML a F# se mi strašně líbí, je to to nejlepší z obou světů. Ale vývoj šel jinam :(
-
Pavel TišnovskýZlatý podporovatelJo no. Ono se totiž ukázalo, že nejenom, že class-based OOP je někdy dost neintuitivní (když se všude tlačí dědičnost - viz ve své době slavný spor Virius vs Čada), ale že se problém, se kterým se vývojáři musí srovnat přesunul - už to (IMHO) není o modelování a převodu modelů do zdrojáků, ale o řízení mutable stavu aplikací. A tady různé funkcionální techniky hoodně pomůžou.
-
L.Stříbrný podporovatel
Pěkná archeologie :-) S odstupem času je to stále docela platné, snad jen ty funkce jako first class citizen by se v Javě dost hodily. Oni je tam nakonec nějak dolepili, ale prostě to není ono.
-
-
Pavel TišnovskýZlatý podporovatel
Pro kontext k tomu linku: to je série polemik, které postupně vycházely v Chipu (když ten časopis ještě za něco stál) jako reakce na recenzi Javv. Ta recenze tedy byla hodně divná ve stylu "Java neumí toto, C++ to umí -> Java je špatná".
-
Ta polemika je taky celkem divná. Ovšem nejzajímavější je, že v ní Čada za Javu “bojoval”, ale záhy otočil a začal ji vulgárně kritizovat a prosazovat jediné skvělé Objective-C (i když Java má smalltalkovské doesNotUnderstand, což u něj zásadně rozhoduje, jestli ten který jazyk za něco stojí).
Tolik širší kontext.
-
Popravdě po nějakých dvaceti letech v oboru to asi taky nechápu :-) Jde o to, CO to vlastně OOP je (neshodneme se ani na definici*). To co nás kdysi učili ve škole bylo class-based OOP. Přitom jsou jazyky, které jsou krásně OOP a třídy nepotřebují. A třeba multimetody to staví na hlavu už úplně :-)
* to stejné i pro FP
-
Pavel TišnovskýZlatý podporovatel
Osobní názor: IT obecně trpí dost jedním "zákonem", který zhruba říká: počet vývojářů se každých 5 let zdvojnásobí. V takovém prostředí se těžko předávají ty skutečně dobré myšlenky, protože i kdyby s nimi souhlasila řekněme polovina vývojářů, za 5 let z nich bude už jen malá skupina atd. atd.
Takže se v IT spíše postupovalo malými přískoky vpřed (někdy i úkroky stranou). Typicky je to vidět na Javě - jazyky navržený tak, aby na něj bylo možné relativně snadno přejít z tehdy dominantního C++. Dtto Kotlin - malá vylepšení v mezích zákona, postupné přidávání dalších featur.
O to víc mě překvapilo F#. Ne svojí existencí (MS research je v oblasti jazyků velmi dobrý*), ale že to nikdo ještě nezabalil s tím, že se pojede mainstream C#.
* fakt jsem MS pochválil? :-)
-
Problém (nejen) Microsoft Research je, že se moc nezabývají svými aktuálními praktickými technologiemi a ty pak mají malý inkrementální vývoj a stagnují. Prosadit nějaký výzkum týkající se třeba C# je skoro nemožné. Nehodné seriózního vědeckého bádání. Ono je hezké vymýšlet pořád nějaké revoluční technologie, ale ty se neprosadí, protože jsou moc revoluční a běžná praxe je pak desítky let pozadu.
-
No ono práveže najprv sa novinky dostávali skôr do F# (napr async expressions tam boli možno o 5 - 10 rokov skôr ako v C# async / await). Ale v poslednej dobe mi príde F# už dosť odladený a konzervatívny a prevratné novinky tam pridávajú ešte neskôr ako do C# a väčšinou tam pridávajú len drobné vylepšenia, ktoré si bežný programátor ani nevšimne (ja si what's new pri každej verzii prejdem lebo občas sa tam nájde niečo zaujímavé). F# je jednoducho dosť komplexný jazyk (je to také C++ medzi funkcionálnymi jazykmi s obrovským množstvom možností, kľúčových slov a podporovaných paradigiem) a novinky sa do neho pridávajú dosť ťažko a každá nová vlastnosť sa musí poriadne premyslieť aby bola spatne kompatibilná a preto sú často skôr v C#. Napríklad keď prišiel Swift od Apple, C#čko z neho okopoírovalo string interpolations zatiaľ čo do F# sa dostali až omnoho neskôr (cca o rok) https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/interpolated-strings, takže donedávna sme v F# (pri formátovaní reťazcov) ešte boli odkázaní na sprintf (ktoré ale typovo checkoval compiler). Mimochodom F# je spolu s inperatívnym C++ moj najobľúbenejší jazyk ale keď som si pozeral OCaml, tak ten mi prišiel omnoho konzistentnejší. OCaml má úplne inú OOP syntax, ktorá imho lepšie zapadá do prostredia jazykov z rodiny ML. (A má aj kopu ďalších vecí napríklad generické moduly, akurát žiaľ Ocaml má na druhej strane omnoho slabšie vývojárske tooly ako F#). F# musel kompletne prekopať OOP keďže musel robiť komromisy kôli .NETu a napriklad podpora interfaces je doslova divná. Ak chcem používať interface tak to musím pretypovať na interface typ čo je divné. Taktiež virtuálne metódy tam majú dosť divnú syntax treba si ich zadefinovať ako abstraktné atď.
-
S tymito vlastnostami som sa stretol v scale a uplne zmenili moj pohlad na programovanie. Je az neuveritelne ako velmi sa da "zhustit" kod bez toho, aby nejako vyrazne utrpela jeho citatelnost a som prekvapeny, ze paradigmy, ktore su take stare sa zacinaju do programovacich jazykov dostavat az teraz.
Pre mna velmi zaujimavy clanok - z pohladu scalistu porovnavam a zistujem ci nam v scale nieco nechyba ;-) - zatial je to az prekvapivo podobne.Dakujem za clanok a tesim sa na druhu cast.
-
Pavel TišnovskýZlatý podporovatel
Tyjo napsat článek, který Root ohodnotí na 30 minut čtení, není úplně jednoduché...
-
Je toho viac, namatkou napriklad Apache Spark je pomerne znamy a uspesny projekt v oblasti BigData. Myslim, ze hlavne vdaka nemu scala dost prerazila v tejto oblasti a je casto pouzivana na datovu analytiku (mam pocit, ze hned za pythonom, ale statistiky som nevidel).
Okrem toho je scala vynikajuca na tvorbu microservices - frameworky ako play, slick, akka, ZIO, http4s, quill, doobie,...Co sa tyka Kotlinu, jeho uspech je imho dany skor tym, ze je navrhnuty ako "lepsia" Java, cize javisti (a nielen oni) si ho vedia pomerne rychlo osvojit a zacat v nom pracovat, zatial co prechod z javy (prip. ineho podobneho jazyka) do scaly si vyzaduje trocha viac casu a zmenu myslenia (viem o com hovorim ;-)), co sa, zial, nie kazdemu uplne chce.
-
L.Stříbrný podporovatel
No, nevím, jsem Javista (i když poslední dobou spíš Typescriptista), teď muset budu dělat i v Kotlinu a moje reakce na Kotlin kód jsou.
WTF. WTF! WTF? WTF??? WTF?!?! W! T! F! ????
-
L.Stříbrný podporovatel
Jako, Kotlin mě připadá, že vznikl tak, že obepsali tisíc vývojářů s otázkou "Jakou featuru byste chtěli mít v programovacím jazyce?", pak vybrali 20 nejšílenějších odpovědí a ty implementovali.
-
L.Stříbrný podporovatel
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.
-
L.Stříbrný podporovatel
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.
-
L.Stříbrný podporovatel
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 (!!)
-
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.
-
Scala narazila na své limity z několika důvodů.
Zaprvé je ten jazyk velmi komplexní, je tam příliš mnoho fíčur. Kotlin na rozdíl od Scaly je ve stavu, kdy je silnější než Java, ale taky čitší a menší než Scala.
Druhý, možná ještě větší, problém je pomalost překladače. Jsou tam nějaké způsoby jak globálně měnit nebo přidávat metody k existujícím třídám, což dělá překlad komplikovaný a pomalý.
-
Skoro všechny jazyky, které mě v posledních cca 10-15 letech oslovily, vycházely do značné míry z ML - OCaml, Haskell, Clean, Scala, Rust. ML a jeho nástupci mi pomohli pochopit, že "geniální" věci, které jsem poznal do té doby, lze do značné míry vyjádřit jinak - jednodušeji, bezpečněji a přirozeněji.
-
Mně se moc líbí Elm, který myšlenkově vychází ze Standard ML, ale je takový učesanější (nezáleží na pořadí funkcí, žádná mutace...).
-
F# je môj top jazyk. Zobrať výsledok výpočtu, funkcie a poslať to cez pipu do inej funkcie, to je úplne iný vesmír.
Keď boli do Pythonu zavedené list comprehensions, tak som si pomyslel, aká super vec! Neskôr som narazil na F# jeho možnosti definovania kolekcií. To bolo precitnutie. Nielen že má F# prepracovanejšie list comprehensions, ale existuje x zabudovaných funkcií na efektívnu prácu s dátami a kolekciami dát. To mi raz a navždy znechutilo Javu a ostatné obmedzené jazyky.
https://fsharp.github.io/fsharp-core-docs/reference/fsharp-collections-listmodule.htmlZaujímavým faktom je, že F# je druhým najlepšie plateným programovacím jazykom, hneď za Clojure. (Kedysi kraľoval Perl.) Zrejme to súvisí s tým, že F# a Clojure sa uchytili vo finančnom sektore a tých vývojárov je celkovo pomenej.
Využitie F# v top finančných inštitúciách si všimli aj v MS, a odvtedy dostal F# od manažérov oveľa viac pozornosti. Vidno to na MS konferenciách, výukových kanáloch a dokumentácii. Zároveň C# prebral veľa od F# a mnohé ďalšie veci sa plánujú. (Napr. discriminated unions.) Takže o budúcnosť F# by som sa neobával.
https://insights.stackoverflow.com/survey/2021#section-top-paying-technologies-top-paying-technologiesKu skutočne reálne využiteľným jazykom z ML by som ku F#, Haskell, Ocalm, pridal ešte PureScript. Vyzerá naozaj zaujímavo.
https://www.purescript.org/ -
Pavel TišnovskýZlatý podporovatel
Vypadá to, že v oblasti Clojure a F# se uplatňuje "the Python paradox", jak o něm kdysi psal Paul Graham:
http://www.paulgraham.com/pypar.html (paradoxně je dneska Python mainstream, ale když to Paul psal, tak nebyl)
(mimochodem - platí to pro OCaml, viz přednášky lidí z Jane Street, jsou na Youtube)
ČLÁNKY DO MAILU