Názory k článku Úvod do jazyka Reason: varianty, pattern matching a ošetřování chyb
-
koroptev (neregistrovaný)
trochu jsem se na to dival a krom toho ze ocaml je fajn jazyk a ze to tlaci facebook vidam jako selling point uvadeny dobry tooling a tomu uplne nerozumim: bucklescript neumi generovat spurce mapy, s debuggerem je clovek odkazany na veci pro js (a jen vygenerovany js kod), vscode (ide ktere je uvadene jako to na jehoz podpore se nejvic maka) neumi nastavit parametry pro refmt (sirka radku), plugin pro webstorm je jednoduse receno uplne v plenkach a trpi detskymi chorobami, pak je tu ta vec s ne 1:1 mapovanim nekterych primitiv ocamlu na primitiva js (objekty, retezce), coz komplikuje kod v reasonml, knihovny v js, pro ktere jeste nekdo nenapsal wrapper, se asi nedaji uplne primocare pouzit z reasonml, co je tedy TO neco, co reasonml ma a jine transpilery nemaji?
-
koroptev (neregistrovaný)
chlubi se dobrou korespondenci mezi reasonml kodem a generovanym js, ktery ma byt lidsky citelny, jak presne se tedy mohou projevit ony "dobre optimalizace"? (oproti rucne psanemu js nebo oproti typescriptu, ktery prakticky nema zadne konstrukty nad ramec js)
spolehlivost? oproti cemu? typescript je nespolehlivy?
rychlost a jazyk beru, ale bez sourcemap a pricetne moznosti debuggingu to je malo, resp kdyby aspon ty knihovny sly
-
Radek Miček (neregistrovaný)
chlubi se dobrou korespondenci mezi reasonml kodem a generovanym js
Myslím, že tohle neplatí. Už třeba kvůli tomu, že záznamy se nepřekládají na objekty, ale na pole. Dále pak kvůli tomu, že funkce jsou currifikované, a kvůli těm optimalizacím. BTW, kde se tím chlubí?
typescript je nespolehlivy?
Stačí se podívat do bugtrackeru TypeScriptu. Hlavní problém je v tom, že správné chování typového systému a typové inference není nikde definováno, proto se tam objevují podobné chyby znovu a znovu. Navíc typový systém je schválně nekorektní.
Příčinou problému je, že k TypeScriptu neexistuje formální teorie, na které by typový systém a typová inference byly postavené. Jazyky jako F#, Dotty (nová verze Scaly), Haskell a Reason/OCaml jsou na tom mnohem lépe.
-
Seriál je výborný. Také jsem zasvětil cca 10 let života hledání nejlepšího programovacího jazyka. Reason neušel mé pozornosti, ale hlouběji jsem ho zatím nezkoumal.
Aniž bych chtěl rozpoutávat flame, trochu mi to připomíná Elm. Výhoda bude asi to, že není omezen jen na kompilaci do js, tedy na použití v browseru jako Elm. Ale syntax Reasonu mě docela odrazuje a některým věcem nerozumím. K čemu třeba jsou vyjímky? Typ `Maybe`, případně `Result` by spolu s pattern matchingem nestačil?
Myslím, že je trochu škoda, že to Facebook nezačal stavět na Haskellu, ale na Occamlu. (subjektivní dojem)
-
Jo. Elm si vystačí s maybe což je v reasonu ten typ option. Rust take nema vyjimky. A reason je má ale když jsou v článku věty jako
Bohužel ve standardní knihovně je zatím velmi málo funkcí, jež v případě problému vrací option, většina funkcí vyhazuje výjimky.
Tak to vypadá že ten jazyk se vyvíjí poněkud chaoticky.
Jako v tom Elmu je to s tím maybe někdy opruz, i v tom rustu je s tím psaní navíc takže vyjimky možná nemusí být zlý nápad. Možná. Nevim. Když se s tím maybe naučí a přizpůsobí tomu styl programování tak to docela pomáhá.
Nemůžu se zbavit dojmu že reason je tak trochu zpatlanina. Nejen kvůli těm výjimkám
-
Radek Miček (neregistrovaný)
Bohužel, standardní knihovna je převzatá z OCamlu, kde mj. vzniklo několik vylepšených standardních knihoven (batteries, core, containers), jelikož ta skutečně standardní za moc nestojí. Jenže nejde říct, že by se mezi těmi vylepšenými standardními knihovnami nějaká dominovala. A teď navíc BuckleScript pracuje na nové standardní knihovně pro použití z Reasonu :-( Ideální by bylo, kdyby jedna z těch vylepšených standardních knihoven nahradila ostatní - jenže to se nestane.
-
Radek Miček (neregistrovaný)
Nemůžu se zbavit dojmu že reason je tak trochu zpatlanina. Nejen kvůli těm výjimkám
Otázkou je, na co přesně narážíte. Existuje řada krásných akademických jazyků, jenže bohužel nemají tooling, knihovny a někdy ani skutečný interpretr nebo kompilátor. Mně osobně přijdou jazyky Dotty (nová verze Scaly), F#, OCaml/Reason a Kotlin dobře použitelné v praxi a přitom poměrně čisté.
-
Nenapadlo mě, že když použiju větičku z autorova profilu, že to vyvolá takový flame. :-)
Čistě logicky je formulace "hledání nejlepšího jazyka" v pořádku. Nevyplývá z toho, zda hledáme nejlepší jazyk univerzální, což je hloupost, a souhlasím s tebou, že takový neexistuje. A nebo zda hledáme jazyk nejlepší na nějaký konkrétní účely, který ale pravda, není nikde uveden.
Z kontextu lze možná (nepřesně) usoudit, že nejvíc hledání je nejspíš věnováno nejlepšího jazyka na frontend. Tedy jazyka, který by nahradil javascript (respektive se do něj kompiloval). Ale není to úplně pravda. Reason má i jiné využití, než frontendový vývoj, mnou zmiňovaný Elm je naopak pouze na frontend a mnou zmiňovaný Rust je jazyk, který "konkuruje" jazykům jako C++, Java, případně (asi částečně) Go aj.
-
Kiwi (neregistrovaný)
Žádný HTML, žádný JavaScript, ale prostě jen nějaký bajtkód, který se transparentně stahuje a spouští na mém počítači, a velice primitvní protokol na přenos toho bajtkódu (+ cache a hash na ověření, zda je to vůbec nezbytné; formát dat mezi "klientem" a "serverem" by byla jejich vnitřní záležitost, pokud by byl v daném případě vůbec nutný jejich přenos). Jestli jen vytvoří aplikaci vypadající jako dnešní statická webová stránka, nebo se bude chovat jako plnohodnotná aplikace, či cokoli mezi tím, to už by záleželo čistě na autorovi takové internetové služby. Z jakého jazyka by se do toho bajtkódu překládalo nebo třeba i generovalo z nějakých programů, by taky bylo čistě na autorovi. Na straně "klienta" by nebylo třeba žádného prohlížeče, jen VM na stahování a spouštění toho bajtkódu + stáhnutelné cachované knihovny a konfigurátor, kde bych povoloval a zakazoval VM přístup k různým prostředkům na mém počítači apod. "Klient" v uvozovkách, protože by technicky šlo o peer2peer vztah. Jestli by šlo o server nebo o klienta nebo o obojí by záleželo jen na tom, jak by taková aplikace byla napsána.
Technicky jednoduché a ortogonální, neomezeně rozšiřitelné, podstatně omezující množství dat tekoucí sítí (kolik balastu v podobě nadbytečných a zbytečně ukecaných HTML tagů a JavaScriptu se každou sekundu naprosto zbytečně přelévá sem a tam internetem...), lépe využívající výpočetní výkon u klienta, žádné řešení statický/dynamický, stylů apod., žádné omezení plynoucí ze schopností prohlížeče - dynamická rozšiřitelnost založená na relativně bezpečných knihovnách v tom samém bajtkódu, nebo rizikovějších binárních knihovnách (včetně nějaké standardní knihovny náležející k VM, představující standardizované minimální API/UI) - možno řešit přes certifikáty, podobně jako dnes.
Vždyť celý počítač, který máš právě před sebou, ať už desktop, notebook nebo smartphone, je jeden velký prohlížeč + mnohem víc. Tak proč v něm spouštět ještě nějaký jiný prohlížeč (technicky/historicky vlastně jen grafický terminál) s omezenými schopnostmi, na který se pak složitě roubují různá rozšíření, která umožňují aspoň trochu se přiblížit schopnostem toho, na čem to celé běží? To je jak kdybych v bytě postavil bunkr z matraček a pak řešil, jak v tom bunkru udělat kuchyni, záchod, sprchu, druhé patro...
To, že někteří autoři a některé nejmenované firmy začali vzhled a chování normálních aplikací připodobňovat prohlížečům, považuji za vrchol perverze. -
Kiwi (neregistrovaný)
Přesně tak, ovšem s vyřazením prohlížeče. Browser je podle mě historický anachronismus, zbytečný mezičlánek. Na formátování textu, zobrazování obrázků, vytváření a organizaci oken, kreslení v nich, realizaci prvků GUI atd. přece žádný hypertextový prohlížeč nepotřebujeme. To vše umí samotný OS. A domnívám se, že to byla zbytečná věc už v době vzniku na začátku 90. let. Z tehdejšího pohledu to byl jen kosmeticky vylepšený gopher, v podstatě grafický teletext, zatímco bylo bývalo možné se inspirovat v té době už existujícím X.
Proč by web měl být založen na ze své podstaty pasivním formátu, historicky určenému k přípravě tisku na papír? Proč by to nemohl být normální program, využívající zdroje OS jako kterýkoli jiný program?
Docela se divím, že někomu asi připadá normální a správné (soudě dle těch minusů), když se zobrazovač hypertextu (jako je třeba také klasické unixové info) postupně obohacuje o funkce, jako je možnost zadávat data od uživatele a vyhodnocovat je, spouštět nějaké skripty, až je z toho vlastně takový virtuální systém, z podstaty své výše naznačené evoluce naprosto nemožně navržený, včetně komunikačního protokolu, který byl původně jen značkovacím jazykem filosoficky vycházejícím z něčeho jako troff.
Opravdu mi to připadá podobné, jako kdybych u koňského povozu postupně koně nahradil parním strojem a nakonec traktorem, s jehož řidičem komunikuji pomocí elektronického biče, hvízdátka a mlaskátka, a povoz vylepšoval o odpružení kol, čalouněné sedačky a klimatizaci, místo abych celou tu koncepci konečně zahodil a vytvořil normální auto.
-
Naopak web byl geniální - s minimem se udělalo maximum - a to, že to převálcovalo všechny další pokusy jen dokazuje, jak geniální to byl nápad. Naopak zpátečnická je představa lokálních virtuálních strojů a přelévajících se programů - to vlastně nikdy moc nefungovalo na nízké úrovni - ať už za tím byl DCOM nebo Java nebo něco jiného.
-
Kiwi (neregistrovaný)
Já na tom teda nic geniálního nevidím a podle mě je to přesně naopak, než říkáš - i velmi jednoduché věci se ve webových technologiích stávají dost komplikovanými.
Nejdřív degradovat počítač na terminál k prohlížení elektronické knihy a pak tento terminál pomocí různých rovnáků na ohejbáky zase postupně obohacovat zpátky na něco, co se chová jako virtuální stroj, a data a kód si s tím vyměňovat pomocí něčeho, co bylo určeno k zápisu té elektronické knihy - protože, jak už tu bylo poznamenáno, dnešní browser v podstatě představuje taky takový virtuální stroj, akorát neskutečně blbě koncipovaný, zbytečně složitý a šíleně neefektivní.
Že něco bylo převálcováno něčím jiným, nedokazuje vůbec nic. Betamax byl taky převálcován VHSkem, OS/2 MS-DOSem, Motorola Intelem...
V čem přesně má spočívat ta výhoda a genialita, že na použití webu potřebuji mimo OS ještě moloch zvaný prohlížeč, který chroustá turingovsky neúplný statický popis hypertextové stránky, který i přes svou značnou komplikovanost stejně není (a ze své podstaty nikdy nemůže být) ve svém standardu schopen vyhovět dnes již ani průměrným požadavkům na weby, pročež je nutné jej generovat dynamicky v serveru a rozšiřovat jej o všelijaké CSS, JavaScript apod., což není nic jiného než právě ty rovnáky na ohejbák, a k praktické realizaci pak tento prohlížeč stejně volá služby OS?
Třeba mi něco uniká, rád se nechám poučit, ale - nic ve zlém - vážně by mě zajímalo, jak něco tak debilního může být vnímáno za geniální.Jakou výhodu to má oproti tomu, když by např. tento portál byl tvořen programem, který všechny ty rámy, textboxy, tlačítka, labely, menu, reklamy, odkazy atd. zobrazí přímo, bez nějakého browseru, prostředky OS ve svém okně, při zadání URL by se akorát zkontroloval nějaký hash, jestli se ten program nezměnil a pokud ne, jen by se vytáhl z cache a ze serveru by si stáhl akorát konkrétní data v nějaké své proprietární binární podobě?
Prostě bych ten web naklikal podobně jako GUI kterékoli jiné aplikace ve svém oblíbeném designeru, dopsal kusy kódu ve svém oblíbeném jazyce (pokud by bylo vůbec nezbytné nějaký kód přidávat - u statických "stránek" asi ne), zkompiloval, zveřejnil, uživatel zadá URL, kód webu se stáhne (a jak tak koukám na zdroják těchto stránek, byl by ten bajtkód mnohonásobně kratší), dynamická data si dososne ve formátu a způsobem, který mu vyhovuje nejlépe - a hotovo. Na co browser, na co HTML, na co CSS, na co JavaScript, na co PHP...? Ani jedno na vytvoření takovéhoto portálu ve skutečnosti nepotřebuji. Nějaký statický popis stránky či stylu může být součástí dat nějakého programu. Ale aby byl program součástí statického popisu stránky - to je návrh principiálně broken by design. Asi jako bych si v OOP nejdříve vyrobil konkrétní třídu "hypertextová kniha" a pak se rozhodl z ní odvodit třídu "dynamická interaktivní aplikace". Ne že by to technicky nešlo, jen je to neskutečně blbý a po všech stránkách nešikovný postup. -
mmm (neregistrovaný)
"pročež je nutné jej generovat dynamicky v serveru........ Nějaký statický popis stránky či stylu může být součástí dat nějakého programu. Ale aby byl program součástí statického popisu stránky - to je návrh principiálně broken by design." - Četl jste článek, pod kterým diskutujeme? V Reactu je popis stránky generován programem na klientu.
"Na co browser, na co HTML, na co CSS, na co JavaScript, na co PHP...?" - javascript použít nemusíte. Diskutujeme pod článkem o Reasonu. Mezi mimifikovaným javascriptem a bytekódem je malý rozdíl.
"Prostě bych ten web naklikal podobně jako GUI kterékoli jiné aplikace ve svém oblíbeném designeru" - výstupem toho designéru bude pravděpodobně nějaký XML popis, stejně ukecaný jako HTML. GUI designéry existují i pro HTML, je to použitelné jen pro jednoduché statické formuláře.
-
Kiwi (neregistrovaný)
mmm:
Popis stránky generován programem na klientu... A proč vůbec něco generovat? Je to úplně zbytečný krok. Když zapomenu na celý ten koncept webové stránky a nahradím ho normální aplikací, tak přece nemusím nic generovat. Webová stránka je totiž speciálním typem aplikace (ve své původní variantě by se vlastně dala popsat programem print"Obsah stránky"). Proto je tak komplikované obohacovat webovou stránku o schopnosti, jež mají normální aplikace.
Ve skutečnosti by nebylo třeba použít nic z toho mnou jmenovaného.
Pro boha proč XML? To se tu opravdu nikdo nedokáže oprostit od všech těch příšerných stereotypů, na něž si zvykl, ale které ve skutečnosti k ničemu nepotřebuje? Když jsem psal, že browser look normálních aplikací je perverze, pak celé XML je podobná perverze. Výstupem toho designéru samozřejmě nebude žádné XML, ale normální bajtkód programu, který se spustí na klientovi. Co do velikosti bude podstatně menší, protože u XML na každý bajt informace připadá deset bajtů XML balastu. To se dá překousnout u lokálního popisu nějaké konfigurace, ale šoupat to smetí sem a tam internetem je šílenství!
No právě, že ty současné designéry jsou zcela zbytečně použitelné jen pro jednoduché statické stránky. Protože problém je v samotné podstatě - není problém něco, co je principálně dynamické, udělat statickým. Ale statickou věc dynamizovat, to je fuška. S obytným autem prostě nebudu jezdit, když nebudu chtít. To je jednoduché. Ale postavit si zděný domek a pak se rozhodnout, že bych vlastně chtěl, aby se mohl přemísťovat z místa na místo, to není úplně optimální a jednoduché. Jenže to je přesně ta cesta, po níž se vydaly webové technologie. Je to ze samotné podstaty slepá ulička, proto jakýkoliv rozvoj technologií nějak založených na tomto principu je ztrátou času - je to totiž celé od základu špatně. Podobně jako byly od základu špatně první elektromotory, inspirované principem parního stroje.Ale to bylo jen takové malé zamyšlení a povzdechnutí nad tím, jak je možné, že si toho všimlo tak málo lidí, a že si na tuto na hlavu postavenou věc všichni zvykli natolik (někteří ji dokonce považují za geniální), že si to ani jinak už neumějí představit a nadále se věnuje čas a energie do udržování tohoto mrtvě narozeného dítěte ve vegetativním stavu na přístrojích, za cenu neuvěřitelného plýtvání lidskými, výpočetními, síťovými a v důsledku energetickými zdroji.
Ze své strany bych to uzavřel. :) -
Radek Miček (neregistrovaný)
K čemu třeba jsou vyjímky? Typ `Maybe`, případně `Result` by spolu s pattern matchingem nestačil?
Souhlasím, že typ `option` by na mnoha místech standardní knihovny byl vhodnější než vyhazovat výjimku. Tohle je bohužel pozůstatek z OCamlu, kde jsou výjimky velmi rychlé a dříve byly rychlejší než obalovat výsledek do `Some`.
Myslím, že je trochu škoda, že to Facebook nezačal stavět na Haskellu, ale na Occamlu.
Myslím, že je celkem těžké implementovat efektivně non-strict sémantiku Haskellu v prohlížeči. Navíc FB hodně používá OCaml.
-
Mě se docela zalíbil Elm a myslel jsem si, že by Reason mohl být něco podobného, spíš lepší, tlačené Facebookem (což nemusí být výhoda, ale budiž)
Z Haskellu vyšel Elm. Zbavil se monad a nějakých složitostí. Některé věci se v něm dělají složitě, ale je to spíš typovou kontrolou, než návrhem jazyka jako takového.
Clojure, které vychází z Lispu, moc neznám, ale zdá se mi čistší.
Na Reasonu mi vadí ta nejasnost jako:
1) vyjímky vs.options (o tom už byla řeč)
2) dvě standartní knihovny (to jsem ani netušil)
3) dráždí mě některé věci v syntaxi (chlupaté závorky a středníky ve switch apod.)Ale jinak Reason vítám a jsem zvědavý, kam se to všechno posune.
-
vypadá podobně jako volání funkce, ale znovu opakuji, konstruktory žádné funkce nejsou
Můžeš prosím rozvést, proč tak zdůrazňuješ tuto skutečnost?
type contact =
| NoContact
| Address(string, string, string)
| Phone(string);
Doufám, že nebudu předbíhat: Jde nějak přidat omezení na ten string u Phone, že má být maximálně deset znaků dlouhý (například)? -
Radek Miček (neregistrovaný)
Můžeš prosím rozvést, proč tak zdůrazňuješ tuto skutečnost?
Jeden z rozdílů je v automatické generalizaci. Například tohle funguje
let id = (x) => x; let x = Some(id);
a
xmá očekávaný typoption(('a) => 'a). Zatímco tohle nefungujelet some(x) = Some(x); let x' = some(id);
x'dostane typoption(('_a) => '_a)a kompilátor vypisuje chybu This expression's type contains type variables that can't be generalized. Rozdíl je jen v tom, že jednou používáme konstruktorSomea podruhé funkcisome. Je to důsledkem relaxed value restriction, což je omezení, které dovoluje generalizovat pouze typy hodnot (a mezi hodnoty spadají konstruktory a nespadají tam volání funkcí). -
Radek Miček (neregistrovaný)
Jde nějak přidat omezení na ten string u Phone, že má být maximálně deset znaků dlouhý (například)?
Jde vytvořit typ, který uvnitř bude string, ale hodnoty tohoto typu půjde vytvářet pouze určitými funkcemi. Vynutit omezení na délku pak půjde uvnitř těch funkcí. Například
module Phone: { type t = pri string; let create: string => t; } = { type t = string; let create = (str) => if (String.length(str) > 10) { failwith("Blah") } else { str }; }; let p = Phone.create("1234"); /* Tohle hlasi chybu: This expression has type string but an expression was expected of type Phone.t let p': Phone.t = "1234"; */ /* Phone.t lze prevest na string. */ print_endline(p :> string);
