"který patří (alespoň podle skromného názoru autora tohoto článku) mezi trojici programovacích jazyků, které by měl alespoň rámcově znát každý programátor. " které jsou tedy ty další dva?
Jinak ML jazyky jsou hodně fajn. Třeba CAML nebo i OCaml, ale tam ty objekty přidávali asi jen proto, že to byla móda :-) V SML je přehledná definice funkcí přes "fun", to moc nevím, proč třeba v CAMLu nebo F# není. Haskell je na druhou stranu až moc akademický (IMHO).
tak do té trojice ještě určitě patří C (jako příčetný assembler :) a možná bych tam vrazil i něco z trojice LISP/Scheme/Clojure (těžko říct, který). Ale SML tam má své místo (někdo by mohl zvolit Haskell, ale ten je poměrně hodně pozicován do role čistě funkcionálního jazyka, těžko s ním začínat). SML umožňuje úplně obejít typy a třeba první půlrok se jimi vůbec nezabývat; teprve potom ukázat (opět: příčetný) typový systém; to aby se člověk hned na začátku nezkazil C#/Javou :-)
Zajímavé téma, ale přiznám se, že pro mě osobně poněkud děsivé. Už od dob LaTeX vs. TeX v dobách MSDOS se, alespoň podle mne, opakuje totiž stále stejný problém: překladače z jednoho jazyka do jiného fungují pouze jedním směrem. Takže pak nastane potíž, až se stane chyba a vy máte
Je v tomto za těch 30+ let nějaký pokrok? Jak se v praxi postupuje, nejlépe u nějakého většího projektu, kde chyby nemusí být vůbec triviální?
nevim jak v LunarML, ale treba v JS svete to resi source mapy.
(a TeX je dobrej priklad jazyka, ktery proste neni postaveny na podobne rozsirovani, jakym byl balicek LaTeX. Tam to proste vazne a vazne.)
Já s tím nemám zkušenosti, ale podle toho, co jsem našel, tak source mapy řeší jen poznámky o umístění kódu - takže se výborně hodí na překlad z toho samého jazyka do stejného (JS->JS), např. při minimalizaci a obfuskaci, co se dělá pro JS na weby. Ale pokud by to byly jazyky různé, tak je to podle mě mnohonásobně obtížnější úkol a je otázkou jestli vůbec obecně řešitelný, protože ty (runtime) chyby v jazyce2 vůbec nemusí mít jednoznačný předobraz v jazyce1, natož aby to vždy šlo nějak snadno pojmenovat terminologií jazyka1.
LaTeX jsem uváděl záměrně, protože tam mi to přišlo extrémní - snaží se před uživatelem ty low-level věci skrýt, mluví v mnohem vyšších pojmech jako 'prostředí' apod. a pak na uživatele vypadne chybová hláška: "hbox overful by 0.213pt" a jen nedostatečná česká lokalizace způsobuje, že za tím překladač nedodá oblíbené "Hledej, Šmudlo." :D Ale ono to bude podle mě podobné i tady, ne? Ve výsledném JS se za běhu objeví nějaká chyba nebo tiše něco funguje špatně - a jak se to namapuje na nějaký funkcionální jazyk a jeho konstrukty??
Proto jsem fakt upřímně zvědavý na další díl, když Pavel slibuje, že se runtime errors pověnuje :)
ano, to může nastat. V případě LunarML to je ale řešeno o hodně líp, než v LaTeXu (ale tam to prostě líp udělat nešlo, protože TeX nemá vhodné rozhraní). LunarML obecně nepouští chyby "dolů" do Luy nebo JavaScriptu. Samozřejmě teoreticky taková chyba nastat může, ale je to hodně limitováno. Runtime výjimky zkusím popsat příště.
PS: vím, že ML je dnes asi trošku ne-mainstream téma, ale ten jazyk si pozornost zaslouží. Je starý (věkem), ale ne zastaralý (sem patří některé jiné jazyky z mainstreamu :-).
Tyjo to by mě zajímalo víc do hloubky. Můžeš to prosím rozvést (jasně, pokud to není tajné)? Který překladač, jak řešíte balíčky (asi nijak) atd.
Diky za clanek.
Myslim, ze dalsim dobrym duvodem, proc se s timto jazykem seznamit, je i kniha "Purely Functional Data Structures" od Chris Okasaki.