Názory k článku Mercury: Programování s pomocí instalatéra

to záleží na vkusu, já radši programuju s klempířem ;-)

Pokud tam jde volat kod v cemkoli jinym (v C) tak staci nevinna funkce jako treba strcpy nebo strcat a buffer overrun je na svete ;)

Imho to funguje obráceně (teda jestli jsem to dobře pochopil). Tj. produktem kompilatoru je kod v Ccku, kterej se dale kompiluje, takze imho není možný volat Cčkovej kod, ale jde začlenit produkt do Cčkovýho kodu. Pak bude pochopitelně nehavarovatelnej jenom ten začleněnej kus...

Spíš vidím jinou (potencionální) slabinu. Celé to snad využívá Cčkový kompilátor a právě tohle může být ono slabý místo (netvrdím, že je...může být...).

Navíc, každý kod je sestřelitelný hardwarovou chybou, čím více je kod odpoután od hardwaru, tím větší je pravděpodobnost, že se to povede (aneb, pokud píšu něco v assembleru pro nějakej jednočip, dává mi to dost příležitostí řešit výskyt hardwarových chyb, ne pochopitelně všech).

Osobně spatřuji smysl toho jazyka v něčem jiným (a kvůli tomu má smysl se tím zabývat). Nějaké řídící zařízení, v kterém musí probíhat nějaký poměrně komplikovaný výpočet. (Například sledování družice antenou...) Pravděpodobnost toho, že bych něco podělal na úrovni řízení polohy té antény je malá, dá se to poměrně snadno všechno odzkoušet, jestli to dělá to, co to dělat má, ale výpočet polohy družice je věc komplikovanější a pokud se někde udělá chyba, bude to s největší pravděpodobností právě tady. Myslím si, že smyslem toho jazyka je použít ho právě na takový místa. Ale mohu se koneckoncu mýlit ;-)

Na výpočet dráhy družic je Fortran

Protoze vypocet drahy druzit delaji Opravdovi Programatori ;-) Ale co az dojdou?

Nedojdou, Fortran se na VS (minimalne na jedne) uci. Je to vyborny jazyk.

Ano, jde volat kód v čemkoli jiném. V Mercury ho obalíte stejnou deklarací: tohle přijímá, tohle vrací a nemůže selhat (Mercury prověří váš zbývající mercuryovský kód předpokládaje, že mu nelžete). Pokud si v tom jiném jazyce natlučete, Mercury už s tím nic neudělá.

A co kdyz program deli nulou, jak se s tim Mercury vyrovna? Pokud pokracuje dal, tak je to chyba, pokud zhavaruje, tak neplati ta teze o nezhavarovatelnosti :-)

Nezhavarovatelnost je otázka definice havárie. Když někdo pěje chválu na nějaký vyšší programovací jazyk, že nemůže segfaultnout, dělá z vás blbce -- protože může-li něco segfaultnout, tak je to nízkoúrovňový jazyk...

Jde o to, jak se v daném jazyce propagují výjimky, tj. to např. dělení nulou, čtení neexistujícího souboru nebo klidně vybrání prvku z prázdného seznamu. Prakticky všechno, co pracuje s daty z vnějšku, může nějak selhat. Všechno, co používá něco, co může selhat, může selhat také (aspoň jsem to tak pochopil z článku). Ale jak to selhání vypadá v praxi (tj. jak po něm pokračuje běh programu) a čím se tak liší od výjimek v jiných jazycích, to jsem zatím nepochopil.

IMHO každej kompilační programovací jazyk, kterej mě nechá pracovat s ukazateli může vyrobit kod, kterej spáchá sebevraždu sigsegv. Tento jazyk to řeší tak, že mě
1. nenechá používat takové nástroje
2. poskytne mi takové prostředí, abych je používat nemusel

A co treba Java? Tam segfault nehrozi, maximalne nektera z velke rady exceptions, ktere ale jdou odchytit :o)

SIce se v mercury zabrani tomu aby program hodil segv, ale to, ze se programator u konstanty uklepne o jednu nulu a druzice skonci misto na obezne draze nekde v oceanu se stat muze i tam

To uz se pry jednou v NASA stalo, ze se programator uklep a program byl sice syntakticky spravne, ale delal neco co nemel ... a bylo po druzici

Myslim, ze to doslo k prepsani jedne carky jednou teckou a vzhledem, ze ten programovaci jazyk (IMHO Fortran nebo Cobol) byl spatne navrzeny, tak to kompilator nezjistil a raketa shorela pri startu.

nekde kolem roku 2k kvuli chybe ve vertifikaci modulu pri konstrukci rakety Ariane 5 na zaklade softwaru z Ariane 4 se stalo to same.

V Mercury jsou také výjimky, které je možné podle potřeby vyhazovat a chytat. A konkrétně dělení v základní knihovně je deklarováno jako deterministické (aby člověk nemusel opravdu každé lomítko ve svém kódu explicitně oifovávat) a pro nulu vyhazuje výjimku. Nechtěl jsem o výjimkách ale mluvit z pedagogických pohnutek. Osobně se mi více osvědčilo "nepříjemné" situace v kódu ošetřovat explicitně, řádnou úvahou nad každým selháním (a tady Mercury pomůže), než vyhazováním a chytáním výjimek (na to je expert Java). Mám obavu, že při hojném užívání výjimek člověk snadno vyrobí kód špagetový ještě v jednom rozměru navíc: kde se která výjimka produkuje a kde se která výjimka chytá. A tak radši o výjimkách mlčím, aby si lidé nezvykli tyhle špagety zamotávát.

Správně jste pochopil, že všechno, co volá selhatelné, může selhat také. Výjimky jsou zavedeny proto, aby něco bylo z logického hlediska neselhatelné, ale v nárazu na skutečný svět přece jen nějak havarovalo. Osobně programy člením do dvou částí: v první fázi se vypořádám se vstupem a dostanu ho do struktur (pak už řetězec používám opravdu jako řetězec a nikdy ne jako seznam čárkou oddělených hesel, na to si zavedu seznam řetězců). Selhání (za běhu, např. výjimkou) na špatný vstup je tedy oznámeno brzo. Ve druhé fázi už vyhazuju prakticky jenom výjimku typu "Pro lenost nedoimplementováno.", a případně to dělení nulou, pokud jsem nějak nesprávně použil nějakou matematiku.

Když tedy budete uvažovat jen to řádné selhání predikátu (a nikoli selhání za běhu), rozdíl je právě v tom, že o tomhle logickém selhání Mercury umí dopředu ověřit, zda může či nemůže nastat. Např. budete tvrdit, že vezmete první prvek seznamu, ale Mercury vám řekne: a co když je seznam prázdný, tohle přece může selhat. Takže vás donutí přidat explicitní kontrolu, jestli je seznam neprázný. A pro tu neplánovanou větev můžete pro začátek klidně říct "Pro lenost nedoimplementováno." Většinou ale podobná pobídka kompilátoru stojí za úvahu: ušetřím si čas s pozdějšími problémy, když to pořádně doimplementuju už teď?

je to pomerne jednoduche: operacia delenia je semidet a teda:
- bud vrati vysledok
- alebo zlyha
v kode sa s tym treba nejak vyrovnat, inak kompilator zahlasi nieco podobne ako v tom priklade s nedeterminizmom a teda program sa nepodari spustit

OK.

"U pouhé syntaktické podobnosti to ale také zůstane"
No, nevim, me to tedy Prolog pripomina docela dost, rozhodne nejenom syntakticky. Zakladni rozdil bych videl spis v interpretaci&terminologii. A samozrejme ty novinky jako determinismus, atd. Skoro bych ale rekl, ze by to prinejmensim castecne slo emulovat primo v Prologu.
(Tohle vse je prvni dojem, tenhle jazyk jsem nikdy predtim nevidel...)

Hlavní rozdíl proti Prologu vidím v tom, že Mercury je čistý logický jazyk, zejména tam není řez nebo jiná podobná prasárna. Když se k tomu přidá typování, determinismus, výjimky a pár dalších vymožeností, jedná se opravdu o úplně jiný jazyk než Prolog.

Mercury bylo v počátcích svého vývoje napsáno v Prologu, postupem času ale bylo kompletně přepsáno do Mercury. Emulace v Prologu by podle mě dnes nebyla o nic jednodušší než třeba v Lispu, s výjimkou zpracování syntaxe.

Syntaxe Mercury bohužel zůstala prologovská. To považuji za největší a fatální nedostatek Mercury. Přestože je Mercury jinak vynikající jazyk, kde člověk tráví skutečně jen minimum času laděním, pro jeho syntaxi jsem jej zavhrl. Na orientaci ve změti všelijakých značek a zohledňování rozdílů mezi závorkou s mezerou a bez mezery, jsem už dávno ztratil chuť.

no, komercni Komodo dela furu kontrol pri psani kodu, takze nektery problemy co resi tady ten jazyk resi Komodo uz dnes, navic v prijemnym gui.

Predikát není procedura. Za takové tvrzení by autor článku propadl z logického programování na kterékoliv slušné škole na zeměkouli. Nanejvýš lze říci, že logický deterministický predikát VYPADÁ jako procedurální funkce. Problém podvojného myšlení programátorů v Mercury je možná způsoben tím, ža na rozdíl od Prologu Mercury není striktně deklarativní jazyk. Striktní typování je proti duchu logického programování a to je pravou příčinou, proč je Mercury v komunitě LP tak málo oblíben. U opravdických logických struktur může totiž problém jejich determinismu za chodu programu vypadat jinak než při překladu (např. expertní systémy)

Jak definujete "proceduru"? `main' je svým způsobem procedurální, neboť od většiny programů chceme obsáhlejší výstup, než jen ano/ne.

Co myslíte pojmem "striktně deklarativní"? Podle mě Prolog není deklarativní vůbec, protože záleží na pořadí vyhodnocování klauzulí a podcílů a je tam řez.

Co se týká typování a determinismu, tak je pravdou, že Mercury nemá `assert', ale v kolika programech to *rozumně* potřebujete? Žádný jazyk není vhodný úplně na všechno, ale záběr Mercury je *mnohem* širší než u Prologu, právě díky determinismu a typování. Ale na tvorbu dynamických programů se opravdu nehodí.

> kompilátor to prověří a případně ukáže prstem
> na místo

Podla tohto by sa mohlo zdat, ze kompilator sa snazi "dokazat program". Ak si vsak dobre pamatam z Teorie programovania, tak dokazat cyklus/rekuziu s trivialnou podmienkou nie je zrovna jednoducha zalezitost. Ako sa kompilator vysporiada s tymto ?
Narazam na problem urcenia ci dany program skonci alebo nie.

> Tzn. že vždy uspěje (nemůže selhat, nemůže
> nevrátit žádné řešení) a vždy vrátí právě jedno
> řešení.
Predpokladam, ze by malo byt : Ak skonci, tak vrati prave jedno riesenie.

Nepletu-li se, tak v Mercury se při překladu používají heuristiky, které někdy nekonečnou rekurzi odhalí a někdy ne. Jinak `det' opravdu znamená, co autor napsal (programátor, který `det' uvede, se ovšem může mýlit).

Dokazat cyklus je trivialni, pokud ti nevadi ze to bude trvat nekonecne dlouho :-).

Je vhodne k takovym clankum take uvest odkaz na zdroje, kde se clovek docte podstatne vice a kde jsou k dostani nastroje a eventualne, zda dany jazyk podporuje i nejaka korporace a nejen parta nadsenych vyvojaru. Resit NEKTERE problemy pomoci PL je pomerne zajimava vec, takze budu muset pouzit sluzby nejake vyhledavaci sluzby(GOOGLE:-)).

Take by me zajimalo jake programy jste v MERCURY vytvoril - to ze nepouziji debuger 2 roky jeste moc neznamena.

Napsal jsem lingvistický modul do školního projektu. V systému "robůtků" běhajících po domě tenhle modul zajišťuje, že robot rozumí větám typu "Seber červenou knihu." "Dej ji na polici v knihovně." Pokud nelze z udaného popisu předmět určit, robot se zeptá: "Kterou červenou knihu, tu v pokoji nebo tu v kuchyni?" A správně rozumí odpovědi "Tu v kuchyni.".

Pak jsem napsal interpret vlastního jazyka na výběr "jednoduchých vět" (jeden typ "jednoduchých vět" jsou skutečně věty jednoduché, ale můžete napsat skriptík na výběr něčeho jiného) z textu. Základním stavebním kamenem jsou sestavy rysů a regulární výrazy nad sestavami rysů.

Pak jsem napsal kompilátor vlastního jazyka na přípravu tabulek do Perlu. Ten jazyk lze charakterizovat takto: popíšete cílovou tabulku jako slepeninu tabulek podsebou a vedle sebe, lepíte jakkoli se vám hodí, ale aby lepení bylo možné, tj. počet řádků/sloupců musí souhlasit. Dále popíšete, kde se berou vstupní data, např. SQL dotaz, a jak se vstupní data pro účely tabulky transformují. Pikantní na té transformaci je eliminace for-cyklů, speciálně vnořených. Když budu mít proměnnou seznam_cisel a v ní jednotlivá čísla uchovaná v položce cislo, tak se např. podíl jednotlivých čísel na součtu nechá vypočítat takto:

seznam_cisel {
cislo,
podil_cisla_na_souctu = cislo / ..:soucet
},
soucet = sum(seznam_cisel, cislo)

A pro kontrolu, že nám podíly sčítají do jedničky, můžeme přidat jeden řádek:
pro_kontrolu_soucet_do_1 = sum(seznam_cisel, podil_cisla_na_souctu).

Zmíněný kompilátor vyřeší všechny závislosti mezi proměnnými, přidá potřebné for-cykly a uloží program v Perlu, který tabulku generuje (např. ze zmíněných SQL dotazů.)

A pak ještě řadu drobností.

Citaci jsem posílal souběžně s článkem do redakce. Omlouvám se, že jsem nezkontroloval, že se nevytratila. A ona se vytratila.

http://www.cs.mu.oz.au/research/mercury/