Programovací jazyk nové degenerace

1.10.2013 21:36 | Přečteno: 2955× | Nápady, na které jsem líný | | poslední úprava: 1.10.2013 21:38

Nedávno jsem to znovu počítal, a ejhle, krize středního věku je tu! I já jsem patrně smrtelný a z toho vyplývá, že nebudu schopen zabývat se během života vším, čím bych si přál se zabývat.

Psychologické faktory jsou různé, v podstatě jde o kombinaci syndromu dítěte v cukrárně (rád poznávám nové, nesouvisející věci, naposledy laškuji s Haškellem) a syndromu analýzy paralýzou (tak dlouho jsem hledal vhodný parser pro subjekt tohoto článku, až jsem došel k závěru, že se na ten Parsec prosté podívat musím). Zkrátka, nejsem stvořen pro úspěch, ale koho to zajímá, když je všude kolem tolik čokolády?

Rozhodl jsem se tedy, že se podělím o některé nápady, většinou věci, které si podle mého soudu zaslouží vzniknout, ale na které bohužel nemám dost soustředění. Je to samozřejmě potupné, protože správný chlap si věci dělá sám, a pozná se podle činů, nikoli slov. Ale aspoň ta diskuse bude věcná (i po deseti letech na Ábíčku může člověk věřit..) A možná se najde (kde jinde než zde?) nějaký šikovný matfyzák, který z toho vyškrtá naivní hlouposti, přidá svoje vlastní podle chuti a především, bude ochoten překonat všechny související překážky, protože k úspěchu stvořen je.

A první z těch věcí je programovací jazyk. Je jich už tolik, kdo by nechtěl mít vlastní? V zásadě mi jde o propojení několika hru-měnících vzorců myšlení (integration of game-changing paradigms):

• Dialog s kompilátorem místo rozkazovacího monologu
• Typový adhoc adhoc-morfismus s dynamickou typovou analýzou
• Totální průhlednost díky instrumentaci a tlustý runtime
• Datová schémata a jejich kanonická forma, dotazovací jazyk v rámci jazyka
• Automatická volba datových struktur kompilátorem

Více tyto vlastnosti (a jak spolu souvisí) rozeberu dál. Jinak by šlo o jazyk:

• Vyšší úrovně, přibližně jako Python
• Multiparadigmatický, ideálně až k možnostem Common Lispu (makra atd.), vhodný pro obecné programování
• Podpora rychlého a špinavého programování (angl. rapid prototyping) - dost kontroverzní vlastnost..
• Sémantika bez výkonnostních kompromisů (s velkým ALE)
• Syntaxe patrně (spíše z pragmatických důvodů) rozšířená Lisp-2
• Eventuálně obsahující všemožné vynálezy (také se jim říká abstrakce) - to aby se zjistilo, jak interagují s těmi novými paradigmaty
• Ovšem tam, kde to jde, by se měl podporovat jeden, inženýrsky rozumný, způsob, jak věci dělat
• Vzhledem k výše uvedenému, experimentální, nikoli jazyk "průmyslové síly" (jinak řečeno, neexistující API a knihovny nejsou problém, ale výhoda)

Programovací jazyk je v podstatě uživatelské rozhraní pro programátora. Pokud chceme prozkoumat nové vzorce myšlení, nezbyde nám než přijmout poslední bod jako nutnost. Optimální uživatelské rozhraní je výsledek mnoha experimentů, a snaha zachovat kompatibilitu experimentům až nepříjemně brání.

Vlastnosti tohoto nového jazyka (nějak ho pracovně pojmenujme, třeba Crisp z anglického "CRazy lISP") vyžadují v mnoha směrech dynamickou analýzu programu na testovacích datech. Moje základní představa je taková, že se program nejprve přeloží obecněji, než by bylo nutné, ale s instrumentací, spustí se na testovacích datech, a výsledky měření nám dají informaci o tom, jak program více konkretizovat a lépe instrumentovat, a toto se opakuje ad nauseam, dokud nedostaneme rozumný program. Tím se dostáváme k první nové vlastnosti.

Dialog s kompilátorem

Nejprve syntaktická odbočka. Základní syntaxe by byla Lispová, tedy (spousty forem ((se spoustou) závorek)), ve formě (operátor argument1 argument2 ..). Operátory jsou tří druhů - speciální formy (vestavěné konstrukce), makra (byla-li by) a funkce. Jak operátory, tak argumenty mohou být další formy. Speciální formy mají vlastní pravidla vyhodnocení, funkce vyhodnocují všechny argumenty striktně (pokud nedojde k jiné magii). Oproti Lispu by byl rozdíl v tom, že syntaxe forem by nebyla speciální zápis S-výrazů (tedy formy s tečkou (a . b) by neexistovaly, tečka v Crispu by měla jiný význam). Nad tímhle lze vymyslet mnoho syntaktického cukru, nicméně pro tuto chvíli je podstatné ještě jedno rozšíření syntaxe - anotace (které by narozdíl od všeho dalšího nebyly jen syntaktický cukr, ale nezávislé větvení syntaktického stromu).

Ke každé formě či atomu by bylo totiž možné přidat jednu či více anotací ve tvaru (forma parametr1 parametr2) ^(anotace1 anotace2 ..), přičemž každá anotace by mohla být jak atom, tak forma, a na jejich pořadí by nezáleželo. Skrze anotace by programátor vyjadřoval například:

• předpokládané typy a další vlastnosti (povolené hodnoty) operandů
• způsob překladu (věci jako inline, volatile.. co já vím)
• požadavky na ladící body (vypisuj mi tuto proměnnou) a instrumentaci (zjisti mi, jakých hodnot může nabývat tato proměnná)
• testy a různý mocking (k této funkci patří tyto testy, zařiď, aby tato podmínka někdy selhala nebo zařiď, aby toto mělo jinou hodnotu)
• byrokracii (private, public, final, abstract..)
• dokumentační řetězce (proč nemít všechny komentáře rovnou jako dokumentační řetězce?)
• svou odpověď na pozorování provedená kompilátorem (ano, tato proměnná sice nikdy nebyla víc 32-bitů na testovacích datech, ale já ji přesto chci 64-bitovou)

Naopak, kompilátor by mohl také doplňovat určité druhy anotací (patrně jako odkaz na konkrétní sadu testů), a vyjadřovat tak:

• pozorované typy a další vlastnosti (typické a extrémní hodnoty) operandů
• navrhovaný způsob překladu (zde by bylo vhodné provést tuto optimalizaci, toto je zdá se vždy konstanta)
• informace o překladu, pro kontrolu (toto se bude inlinovat, tato rekurze se převede na iteraci)
• kontrolu pokrytí testy (tato podmínka nikdy nenastala)

Obecně by se dalo říct, že smyslem anotací je ukládat informace, které nemají vliv na to, co bude program dělat, ale jak to bude dělat, jak efektivně a s jakými nároky na zdroje, a pomáhat programátorovi programu porozumět. Samozřejmě, z výše uvedených příkladů je patrné, že to rozdělení nelze vést striktně a je otázkou citu; v zásadě by ale mělo platit, že program přeložený s odstraněním všech anotací by zůstal funkční. (Cílem částečně je oddělit anotace, které mohou být doménou různých utilit, od samotného programu, který ať si vypadá jak programátor chce.)

Prostřednictvím anotací by tedy probíhal onen slíbený dialog (po kterém všichni tolik toužíme) s kompilátorem. V první implementaci bych si představoval, že bude existovat IDE (říkejme mu třeba Emacs), které bude schopné

• Selektivně zabalovat a rozbalovat všechny anotace, aby se jimi zbytečně nezamořoval zdrojový kód během editace (proto je důležitá samostatná syntaxe anotací)
• Ukazovat některé anotace jako nápovědu (třeba typy a typické hodnoty proměnné)
• Pro některé anotace (viz příklad) umožnit snadné editování, například potvrzení či vyvrácení hypotéz kompilátoru, aby se tak "poskytoval prostor dialogu"

Zkusíme malý příklad v pseudo-Crispu:

(defun add (a b)
  (+ a b))

(print (add 2 2))

Toto by se přeložilo a spustilo. Na začátku kompilátor neví nic o typech parametrů a a b, takže volání funkce add přeloží totálně genericky, jako v dynamicky typovaném jazyce (dostane parametr každého typu jako součást hodnoty). Výsledkem (kromě výsledku) bude, že dostaneme modifikovaný zdroják (patrně po analýze runtime dat nějakým dalším nástrojem), vypadající nějak:

(defun add (a^(!?+Type:int) b^(!?+Type:int))
  (+ a b))

(print (add 2 2))

Přitom anotace u a a b budou skryté v IDE (bude vidět jen ^ indikující, že tam nějaká anotace je). K čemu ony "!?+" před jménem anotace? Vykřičník udává, že jde o tvrzení kompilátoru; další dva znaky pak souvisí s naším pohledem na tvrzení. První znak je názor programátora, ten zatím není známý, proto otazník. Druhý znak je názor kompilátoru. V tomto případě (řekněme) dospěl na základě dynamické analýzy, tedy pozorováním, že typem je vždy int. Pokud by k tomu pozorování dospěl na základě statické analýzy, tedy logickou úvahou, pak by tam byl jiný znak (dejme tomu "=").

Programátor může nyní anotaci otevřít a onu hypotézu potvrdit nebo vyvrátit; tím se první otazník změní na "+" nebo "-" podle toho, zda je hypotéza podle programátora pravdivá či nikoli. (Existují i další možnosti, programátor může například říct, je sice pravdivá, ale radši to vždycky za běhu otestuj. Nebo je nepravdivá, ale testy jsou špatně. A tak všelijak.) Takže se rozhodne udělat třeba změnu:

(defun add (a^(!++Type:int) b^(!++Type:int))
  (+ a b))

(print (add 2 2))
(print (add "Ahoj" "svete!"))

A.. program selže. Protože nyní funkce add očekává vždy typ int, ale dostane v druhém volání typ string (dejme tomu). Dostaneme pak zpět:

(defun add (a^(!+-Type:int) b^(!+-Type:int))
  (+ a b))

(print (add 2 2))
(print (add "Ahoj" "svete!"))

Druhý znak "-" v anotaci nyní indikuje, že tvrzení o typu bylo kompilátorem pozorováno jako nepravdivé (tedy není bez dalšího známo, jaký typ může parametr a nebo b nabýt). Jak je vidět, jakým způsobem se program přeloží závisí na kombinaci znaků u anotovaných tvrzení, především na tom prvním.

Pro hnípaly dodávám, že mi nešlo ani tak o přesnou sémantiku anotací tvrzení (sám to nemám moc rozmyšlené, bude to předmětem dalších úvah, a tyhle věci by právě chtělo spíš podrobit experimentování než úvahám), chci především ilustrovat, jak by probíhal onen dialog.

Na závěr trochu filozofie o korektnosti programu. Zastánci typových systémů si představují, že ideálně problém namodelujeme v typové doméně, a výsledkem překladu (kdy dojde k typové kontrole) bude sémanticky správný program. To je možné (teoreticky, v praxi typové systémy běžných jazyků nejsou dostatečně silné) díky něčemu, čemu ja nerozumím a říká se tomu Curry-Howard correspondence. Možná bychom ale mohli postupovat obráceně, z korektního (nebo částečně korektního) programu pozorováním určit typy, a na jejich základě program ověřit. Jazyk Crisp by nám takovou možnost dával.

Podobně, kompilátory většinou neprovádějí optimalizace, které nejsou podložené statickou analýzou (a tedy jistotou, že výsledný program bude běžet správně). Crispový kompilátor by se takto omezovat nemusel - dal by nám prostřednictvím dialogu na vědomí, kde provedl potenciálně nekorektní optimalizaci, a dovolil by nám ji otestovat, nebo prohlásit, že ve skutečnosti korektní je. Takto by bylo možné volit např. mezi rychlostí a robustností programu. (Ano, je to tenký led, ale zajímavě tenký.)

V příštím pokračování (snad - určitě mi pomůže, pokud projevíte zájem) budu pokračovat v popisu dalších vlastností jazyka.

P.S. Je mi jasné, že tahle celá myšlenka má asi dva miliony nedostatků. Pokud jsou zřejmé, není třeba sdělovat mi je v diskusi, pokud současně nemáte řešení.

       

Komentáře

[Josef Kufner]

Myslím, že se držíš příliš při zemi a zbytečně se svazuješ vymýšlením syntaxe pro popis. Takováhle věc nebude bez pořádného grafického editoru použitelná tak jako tak.

A dík za Curry–Howard correspondence. Docela se mi to hodí do krámu

Co si slibuješ od "dotazovacího jazyka v rámci jazyka"?

[JS1]

Myslím, že se držíš příliš při zemi a zbytečně se svazuješ vymýšlením syntaxe pro popis. Takováhle věc nebude bez pořádného grafického editoru použitelná tak jako tak.

No, napsal jsem to tak, jak bych k tomu pristoupil ja. Myslim, ze pouzit Emacs je schudnejsi nez psat si cele vlastni IDE (existuje takovy podobny pokus pro Clojure, ale ten ma jine cile nez ja). Ale mozna se pletu, mozna to nekdo udela v tom hnusnem Eclipse.

Jinak samozrejme nejakou syntax jsem pro ilustraci zvolit musel.

Co si slibuješ od "dotazovacího jazyka v rámci jazyka"?

Jde o to, ze bych rad nad daty v pameti pouzival stejne konstrukty, jako nad databazi, a mozna dokonce eliminoval tim potrebu mit treba embedded aplikacni databaze a tak. Druhy duvod je automaticka volba datovych struktur, ktera uz z principu vyzaduje vyssi uroven abstrakce (neni snadne toto delat na nespravne urovni abstrakce, kterou jsou v soucasnosti pouzivane slozene datove typy). Vice (i kdyz asi ne o moc) o tom jeste napisu.

[Josef Kufner]

Jde o to, ze bych rad nad daty v pameti pouzival stejne konstrukty, jako nad databazi, [...]

Tedy něco jako je LINQ v C# ?

[JS1]

Presne tak.

[deda.jabko]

To ale v jazycich typu LISP neni problem, na to staci par maker... :-]]

[JS1]

Pokud narazis na to, ze ten navrhovany jazyk pouziva Lispovou syntaxi, pak je to trefa do cerneho. Skutecne povazuji moznost mit makra za uzitecnou (ostatne, velka cast CL standardu se typicky jako makra implementuje), ale neni mi zatim zdaleka jasne, jak by ta makra interagovala s temi anotacemi. Je to jeden z obtiznych problemu (nastesti se ho da zbavit tim, ze se tam v prvnim priblizeni makra nedaji vubec nebo budou slabsi).

[deda.jabko]

Pokud narazis na to, ze ten navrhovany jazyk pouziva Lispovou syntaxi, pak je to trefa do cerneho

Narazel jsem na to, ze zavedeni takove funkcionality v LISPu neni problem, kdezto v C# kvuli LINQu zavadeli treba "var", coz mi u jazyku tohoto typu prijde jako zverstvo.

jak by ta makra interagovala s temi anotacemi. Je to jeden z obtiznych problemu

Makra s anotacemi mohou pracovat bez problemu. Z opacne strany je to horsi. Uzivatel by musel pracovat s expandovanymi makry, coz by bylo na ukor citelnosti a srozumitelnosti.

[JS1]

Narazel jsem na to, ze zavedeni takove funkcionality v LISPu neni problem, kdezto v C# kvuli LINQu zavadeli treba "var", coz mi u jazyku tohoto typu prijde jako zverstvo.

Uprimne, var mi az tak nevadi, zverstvo by bylo spis tam ten typ muset psat.

Z opacne strany je to horsi. Uzivatel by musel pracovat s expandovanymi makry, coz by bylo na ukor citelnosti a srozumitelnosti.

Ano, to je ten problem. Jak anotace relevantni k expandovanemu makru prednest zpet uzivateli? Leda, ze by to makro definovalo nejaky mechanismus, jakym ty anotace slucovat nebo transformovat. Ovsem to by byl zase problem, protoze pokud muzou byt anotace zcela obecne, pak by musely mit take moznost ten mechanismus ovlivnit. Chce to proste vyzkouset ruzne bezne pripady a na zaklade toho analyzovat, jak na to.

[deda.jabko]

Jak anotace relevantni k expandovanemu makru prednest zpet uzivateli? Leda, ze by to makro definovalo nejaky mechanismus, jakym ty anotace slucovat nebo transformovat

Tohle by mozna slo resit u hygienickych maker. Anotace by byly navazany u pravidel a tak by se resila komunikace makro <-> expandovane makro.

[xkucf03]

Uprimne, var mi az tak nevadi, zverstvo by bylo spis tam ten typ muset psat.

A co prosakování abstrakce? Můžu chtít použít obecnější typ.

[:::]

Myslim ze v praxi by to ztroskotalo na tom ze po par upravach bys mel program plny anotaci, ktery neodpovidaji realite...

[JS1]

Starnuti dat je samozrejme problem. Ale myslim, ze je to otazka workflow. V podstate muzeme pracovat ve dvou modech:

• Rapid-prototyping, kdy nas nejake typove (a dalsi) anotace nemusi prilis trapit. To je chvile, kdy se proste pise samotny kod, podobne jako v dynamicky typovanych jazycich. Toto je typicky udavana jejich vyhoda - snazsi puvodni vyvoj.
• Zmena vetsiho, uz napsaneho programu, a tam se to behem tech uprav da prezit. Naopak v mistech, ktera se neupravuji, jsou ty informace pomerne uzitecne. To je faze, kdy se program meni pomaleji, a tedy i starnuti dat predstavuje mensi problem.

Jelikoz jde o dynamickou analyzu, aby ten system k necemu fungoval, je samozrejme potreba mit testy. Nebo aspon ten program cas od casu na necem spustit.

Mozna narazis na refaktoring, nebo neco takoveho, ale muj nazor je, ze pokud je jazyk schopen provest prislusny refaktoring spravne, pak se mu pravdepodobne dalo uplne vyhnout vhodnou konstrukci jazyka.

Zkratka, nemyslim, ze to co delaji dnes IDE, totiz ze se snazi za kazdou cenu dat 100% spravne informace o typech v realnem case, je idealni. Myslim, ze kompromis v tomto smeru by nam otevrel jine moznosti.

Taky je otazka, proc to ukladat ve zdrojaku a ne nekde mimo. Hm.. podle Unixove tradice by mela byt konfigurace ulozena v textovych souborech, aby s ni bylo mozne pracovat i normalnimi utilitami. Takze nevidim ruzne kodove databaze jako lepsi cestu. (Ale mozna by to v nekterych pripadech anotaci lepsi bylo.)

[gsnak]

Tebe sa toto dobre cita?

(defun add (a^(!+-Type:int) b^(!+-Type:int))
  (+ a b))

Imho je toto prehladnejsie

function add (int a, int b) {
  return a + b;
}

Next-gen jazyk sa musi hlavne dobre citat.

[JS1]

V IDE by to bylo videt jako:

(defun add (a^ b^)
  (+ a b))

Samozrejme, muze se ti nelibit Lispovy zapis, ale ten ma prave tu vyhodu, ze lze tu anotaci umistit k libovolnemu uzlu syntaktickeho stromu (a konzistentne - tudiz je snadne napsat pravidla, ktera umozni tomu IDE to schovat).

Sice pises, ze se to musi hlavne dobre cist, ale v tomto smeru jsme uz myslim narazili na limit. Nejde provest dalsi prulom pokud se nejprve neslevi nekde jinde, to je povaha prulomovych technologii.

[xxxxxxxxxxx]

Já si zase rejpnu. Proč proboha lidi kteří umí programit se se soustředí na věci které nejsou důležité pro život. To je jako bych jako konstruktér pořád donekonečna vymejšlel nové šrouby. Proč bych to dělal když ty šrouby jsou už vymyšlený a hlavně slouží k tvorbě a ne kuli šroubům jako takovým. Řekl bych že je to jistý druh postižení programátorů. Kdyby jste radši naprogramili něco co je skutečně potřeba(pořádnej CAD) pro reálnej život a nebabrali jste se blbostech. ))

[mirec]

Načo vymýšľať koleso keď môžme jazdiť na hranatých hranoloch ;)

[Josef Kufner]

Ze stejného důvodu jako fyzikové, kteří pořád zkoumají elementární částice. Aby našli něco nového a umožnili tak dělat věci, které předtím možné nebyly. Postavíš se svým šroubem tohle?

[xxxxxxxxxxx]

Programovací jazyk je jenom způsob jak něco udělat. Vy tu řešíte pořád dokola jak to udělat a přitom Vám uniká to že to není udělaný. ) K tvé otázce, šrouby na to nemaj vliv a klidně bych ty věci spojil klasickými šrouby. Je to v podstatě idelání příklad. Je potřeba vymyslet tu aplikaci a čím to pospojuješ je v celku buřt, je to druhořadé stejně jako vyvíjet nové a nové jazyky. Nemá smysl řešit optimalizaci způsobu tvorby když jsi neudělal ten krok v podobě aplikace prototypu. Nemá smysl řešit formu protože obsah je důležitější.

[JS1]

No, sice jsem o tom uz napsal ty prvni dva odstavce, ale specialne pro tebe.

Tenhle zapis je spis naopak zpusob, jak si ulevit, a soustredit se na jine veci (ktere jsou ovsem jeste mene prakticke ). Realita je, ze nas nektere programatory tyhle veci napadaji, asi jako tebe napada, jak zlepsit CAD.

Kazdopadne, ja CADum nerozumim, a popravde receno, jelikoz uz mam tolik jinych zajmu, ani nechci rozumet (samozrejme, bylo by fajn jim rozumet, ale nijak to neresi ten problem, asi by ho to jen zvetsilo). I kdyz je pravda, ze bych radeji asi delal na CADu nez to co delam v praci, prestoze moje soucasna prace ma dost jinych vyhod.

[xxxxxxxxxxx]

jojo taky jsem napsal že si rejpnu. Je to asi způsobený tím že lidi se o práci v textu tak nějak prostě nebaví a spíše píšou o jiných věcech. Stejně jako já tu taky nepíšu o tom co jsem nakonstruoval ale bavím se o CADu... Sedí to?

[JS1]

Ano, to co konstruujes ti hlavne neprijde jako problem o kterem by sis mohl povidat verejne na foru. Ale vidis, ze bys byl s jinym CADem produktivnejsi (nebo jini lide, v tvem pripade), a proto to resis.

Stejne tak, v tomto pripade, me zarazi, proc se jeste programovani nevydalo smerem, ktery naznacuji. Jsem jediny, kdo to vidi jako moznou cestu?

[xxxxxxxxxxx]

Většina lidí prostě ten daný nástroj přijme a pracuje s ním. Málo kdo je schopen inovace protože to stojí furu času a energie přemýšlet o něčem co třebas ani nemůžeš změnit...

[Bystroushaak]

Stejně jako já tu taky nepíšu o tom co jsem nakonstruoval ale bavím se o CADu...

Zkus někdy napsat. Když k tom přidáš fotky, myslím že jednak zlepšíš názor na vlastní osobu a jednak tím ukážeš něco zajímavého.

[xxxxxxxxxxx]

Jo možná. Co si o mě myslí ostatní je mi jedno. Mám vyšší cíle než si honit pseudokarmu na abíčku.

[JS1]

Vzdyt se staci podivat na jeho stranky.. Jinak ja si myslim, ze jak se snazi financovat vyvoj podpurnych nastroju pro CAD, to je dobra vec.

[Bystroushaak]

Vzdyt se staci podivat na jeho stranky..

To je něco trochu jiného, než formou článku nějak popsat zajímavý projekt. Programátoři to dělají každou chvíli, tak nevím, proč by to nemohl udělat i strojař.

Jinak ja si myslim, ze jak se snazi financovat vyvoj podpurnych nastroju pro CAD, to je dobra vec.

Neříkám opak.

[xkomczax]

Vidíš, třeba jsi mohl vymyslet nějaký šroub z téhleté sbírky...

[xxxxxxxxxxx]

joo znám. Nejlepší je CIM 886 ten je boží!

[bambas]

Naco vymyslet paskvil? Co nabidne noveho dalsi programovaci jazyk? Novou syntaxi? Nejak nevidim prinos...

[JS1]

Napriklad automatickou volbu datovych struktur kompilatorem. To muze byt IMHO velky prinos. Ale bez dynamicke analyzy a dialogu s kompilatorem se to schudne zavest neda.

Pokud vnimas programovaci jazyk jen jako syntaxi, pak je to velmi, velmi kratkozraky pohled na vec.

[dad]

dve otzky:

To prvni navazuje tak trochu na to, co napsal Vlada - my technici potrebujeme nejake jasne zachytne body, proc neco budeme delat. Take nas napadaji ruzne veci co by bylo mozno zlepsit, ale vzdy to ma nejaky vztah uz k vytvorenemu.

V tech prvnich odstavcich jsem nabyl dojmu, ze za temi napady nemusi byt nejaky konkretni duvod, nejaka konkretni bolistka, kterou trpi stavajici programovaci prostredi, ale dost dobre si to nedovedu predstavit (mozna skutecne proto, ze jsem technik). Jestli tedy existuji nejake konkretni duvody, kvuli kterym se zamyslis, tak sem s nimi, mozna by to bylo pro nas srozumitelnejsi.

To druhe byla ta poznamka o tom IDE nebo neco graficky-podpurneho, jak pise pan Kufner. To je vec, u ktere jako technik okamzite zbystrim, protoze vsechna takova 'nezbytna' udelatka okamzite prerusi moznosti automatickeho zpracovani. A ja chapu IT vlastne jako prostredek k automatizaci. Jak je s timto novym jazykem. Muze byt pouzit bez dalsiho jinymi jazyky, automaty?

[JS1]

No, nevim, jestli je to az tak konkretni bolistka. To co me na tohle eventualne privedlo bylo to, ze treba v Pythonu (v kterem se programuje jinak skvele) jsem hodne casu travil praci s ruznymi adhoc datovymi strukturami. A v podstate kdykoli neco pisu, je to problem.

Proc si proste nemuzu definovat neco jako schema, a s tim pracovat, podobne jako s SQL? A proc kompilator nemuze sam prijit na to, jake datove struktury zvoli, na zaklade toho, jak s daty skutecne pracuji?

K tomu IDE. Prave proto by anotace byly syntakticky oddelene od zbytku kodu. Predpokladalo by se, ze automaticke nastroje mohou zasahovat do anotaci (definovanym zpusobem), ale nikoli do samotneho kodu. Tim by se tento system odlisoval od IDE, ktere typicky umi pracovat i se samotnym kodem.

Pouzit IDE by nebyla, striktne vzato, nutnost; bylo by uzitecne pouze na skryti/odhaleni tech anotaci.

[backinabag]

treba v Pythonu jsem hodne casu travil praci s ruznymi adhoc datovymi strukturami

Muzes dat nejaky priklad?

Osobne si nedokazu predstavit, jak by me volba dat. struktur kompilatorem pomohla, respektive jak by to realne vypadalo. Vetsinou delam v Jave a vyber datovych struktur je asi tak na 20. miste v seznamu veci, ktere mi delaji problemy.

[deda.jabko]

A ja vzdy zil v domeni, ze vyber vhodne datove struktury je vzdy na 1. miste, a proto mi ten napad prisel az prilis odvazny.

[JS1]

Odvazny urcite je. Nechci, aby to fungovalo pro vsechny datove struktury, ale tak pro minimalne 90% beznych pripadu. Asi jako ty SQL databaze.

[deda.jabko]

Nechci, aby to fungovalo pro vsechny datove struktury, ale tak pro minimalne 90% beznych pripadu

Nedokazu si moc dobre predstavit, jak by to melo fungovat. Protoze z datove struktury se odviji algoritmy. To mi spis prijde realnejsi, aby si prekladac upravoval algoritmy ze znalosti dat a datovych struktur.

Asi jako ty SQL databaze.

Toto neni moc dobry priklad. SQL ma pevne dane datove struktury a pak se na to snazi napasovat nejakou kombinaci dejme tomu 10 pevne danych algoritmu, ktere zna. K tomu se pouziva obrovska cerna magie souvisejici s odhadem, jak vypadaji data, jak ktera operace bude probihat, atd. Otazka je, jestli zkusebnim behem jdou sesbirat relevantni data.

[JS1]

No, asi nema smysl moc rozebirat, jak by to realne fungovalo, kdyz se o tom eventualne chystam napsat dalsi blogpost. Moc rozmyslene to sice nemam, ale snad to bude davat smysl.

Jinak tak ze zvedavosti, co je tech 19 veci predtim?

[backinabag]

Tech 19 veci samozrejme nebylo mysleno uplne doslova, ale ted z hlavy me napada:

• Pojmenovavani
• Vymysleni vnitrni architektury
• Osetrovani specialnich pripadu (vyjimky)
• Hledani co nejcitelnejsiho a nejjednodussiho zpusobu jak neco udelat
• Ruzne problemy spojene s externimi knihovnami
• Ruzne problemy souvisejici s buildem
• Vyber knihoven / technologii
• Vsechno co souvisi s paralelismem / asynchronim volanim
• Vykonostni problemy
• Obecne nedostatky konkretniho jazyka (Java - nema closures atd.)

[JS1]

No popravde, doufal jsem v trochu konkretnejsi odpoved. Takto sepsane se s tim nic co do automatizace delat neda. Aspon me nic nenapada.

[xxxxxxxxxxx]

hele nechceš radši přístup k mým opensource strojnickcým tabulkám(beta jako kráva)?

[Tom.š Ze.le.in]

Co to má umožňovat co už neumí třeba sbcl? (tedy najít chybějící optimizace a najít neplatné předpoklady?) A proč to má být součást *jazyka*, ne vývojového prostředí? Jde o tu syntaxi?

Návrh optimizací:

(locally (declare (optimize (speed 3)))
  (defun add (a b) (+ a b)))

=>

; in: DEFUN ADD
;     (+ A B)
; 
; note: unable to
;   optimize
; due to type uncertainty:
;   The first argument is a NUMBER, not a RATIONAL.
;   The second argument is a NUMBER, not a FLOAT.
; 
; note: unable to
;   optimize
; due to type uncertainty:
;   The first argument is a NUMBER, not a FLOAT.
;   The second argument is a NUMBER, not a RATIONAL.
; 
; note: unable to
;   optimize
; due to type uncertainty:
;   The first argument is a NUMBER, not a SINGLE-FLOAT.
;   The second argument is a NUMBER, not a DOUBLE-FLOAT.
; 
; note: unable to
;   optimize
; due to type uncertainty:
;   The first argument is a NUMBER, not a DOUBLE-FLOAT.
;   The second argument is a NUMBER, not a SINGLE-FLOAT.
; 
; note: forced to do GENERIC-+ (cost 10)
;       unable to do inline float arithmetic (cost 2) because:
;       The first argument is a T, not a DOUBLE-FLOAT.
;       The second argument is a T, not a DOUBLE-FLOAT.
;       The result is a (VALUES NUMBER &OPTIONAL), not a (VALUES DOUBLE-FLOAT
;                                                                &REST T).
;       unable to do inline float arithmetic (cost 2) because:
;       The first argument is a T, not a SINGLE-FLOAT.
;       The second argument is a T, not a SINGLE-FLOAT.
;       The result is a (VALUES NUMBER &OPTIONAL), not a (VALUES SINGLE-FLOAT
;                                                                &REST T).
;       etc.

Špatné optimizace:

(locally (declare (optimize (speed 3) (debug 2)))
  (defun add2 (a b)
    (declare (fixnum a b))
    (the fixnum (+ a b))))

(add2 most-positive-fixnum 1)

=>

The value 4611686018427387904 is not of type FIXNUM.
   [Condition of type TYPE-ERROR]

Bez kontrol:

(locally (declare (optimize (speed 3) (safety 0) (debug 0)))
  (defun add3 (a b)
    (declare (fixnum a b))
    (the fixnum (+ a b))))

(disassemble #'add3)

=> nic nekontrolující a rychlé

; disassembly for ADD3
; 02E37316:       84042500000021   TEST AL, [#x21000000]      ; no-arg-parsing entry point
;       1D:       4801FA           ADD RDX, RDI
;       20:       488BE5           MOV RSP, RBP
;       23:       F8               CLC
;       24:       5D               POP RBP
;       25:       C3               RET

[JS1]

Ano, jde o tu syntaxi. Ta syntaxe anotaci umoznuje syntakticky oddelit informace, ktere jsou dulezite pro pochopeni kodu od informaci, ktere pro to pochopeni dulezite nejsou.

Napr. ten treti zapis je idealni z hlediska vykonu, ale velmi spatne citelny. Specialni syntaxe anotaci by umoznila v IDE prepinat mezi obema zapisy. (A eventualne tak indikovat mnohe dalsi optimalizace, ktere z nejakeho duvodu nedokaze staticka analyza postihnout.)

Druha vec je, ze jelikoz jsou anotace oddelene od kodu, muze nejaky nastroj resit vyse uvedenou situaci automaticky. Tj. misto toho, aby nam jen vydal hlasku o tom, ze neco se nekde nepreklada optimalne, a my pak ten problem resili pridanim deklaraci, navrhne ty deklarace primo do zdrojoveho kodu, a programator je jenom schvali.

Common Lisp je uzasny jazyk, ale ma svuj vek. O CL jsem premyslel jako implementacnim jazyce, ale neni to ono. Nicmene, neni duvod proc to z toho noveho jazyka neprekladat napriklad do CL.

[Tom.š Ze.le.in]

A nestačí na to v emacsu mít toggle na schovávání the a declare? (hmm, to si možná udělám)

Ty hlášky jsou signal-ované noty daného typu, takže není problém je odchytávat a zpracovat - otázka je kam ty deklarace automaticky přidávat (pokud je třeba lambda v letu v casu/condu/ifu v defunu, kam má deklarace přijít?); ale to je problém principiální, který stejně budete muset řešit.

[JS1]

Ano, samozrejme, ze to vsechno lze zapsat jako jeden velky strom. Potiz je, ze automatickym pridavanim tech deklaraci do toho, co napsal programator, se uz zamlzuje puvodne cisty kod, ktery napsal. Proto se IMHO vyplati mit to jako samostatnou, syntakticky odlisnou vetev stromu. IDE by pak muselo definovat specialni pravidla o skryvani pro kazdy druh anotace; takto nemusi.

Jinak nastroj, ktery ty deklarace pridava, by samozrejme musel vedet, u ktereho mista v kodu jsou relevantni.

Konecne, k tomu odchytavani. Kdyz mluvim o "dialogu s kompilatorem", mluvim v sirsim smyslu. Zajimaji me take runtime data. Kompilator se rozhodne, co ma jak instrumentovat, a na zaklade runtime dat se pak pridaji vhodne anotace. Neni to jen o tom, ze by anotace automaticky pridal kompilator samotny. Proste odchytavani a automaticke dodavani anotaci pri prekladu neumoznuje ten dialog, ktery si predstavuji.

[Tom.š Ze.le.in]

Jinak svůj věk znamená mimo jiné i to, že v tom (zejména před tím než byl kodifikován jako common) zkoušeli spoustu úchylných a originálních věcí, které se dnes znovu objevují jako novinky jinde (včetně stejných chyb a problémů). Skoro bych se divil, kdyby v Interlispu nebo něčem stejného stáří funkce správy typu proměnné v editoru nebyla zkoušená :)

[JS1]

V tomto pripade je to spis narazka na to, ze podle meho nazoru stavebni bloky, ktere Common Lisp ma, nestaci na plnohodnotnou realizaci teto myslenky. (Samozrejme, dalo by se to udelat pres reader makra, ale o to nejde. Jde o to, kolik prace se usetri pouzitim CL misto aby se napsal novy jazyk. Tedy jestli se pak nebude narazet na nejake dalsi vlastnosti CL.)

Mozna nekdo neco podobneho uz zkousel - ja takovy pokus neznam.

[kralyk z abclinuxu]

Ty anotace se mi líbí. (Nejsem si jist, jestli je dobrý nápad do toho zahrnovat i tu byrokracii, no ale to je spíše detail.)

Jinak syntakticky podobou věc už má C++11, akorát se tomu říká attirbutes. Imho třeba takový Clang postupně spěje k použití těchto attributes podobným způsobem, jako jsi popsal v zápisku. Už teď se dají v Clangu použít na odhalování race conditions, ačkoli zatím teda pouze statickou analýzou. Přidání nějaké té dynamické analýzy by v rámci LLVM snad mohlo jít...

[JS1]

Diky.

Priznam se, ze mi atributy v C++11 unikly (C++ nepouzivam). Akorat tady by to nebylo zavisle na kompilatoru/toolchainu, ale definovane v jazyce. I kdyz eventualne nevidim duvod, proc by si uzivatel nemohl definovat vlastni atributy.

A muj jazyk samozrejme miri vys nez C++ (ve smyslu urovne).

[xkucf03]

Na ukázce s těmi primitivními typy to vypadá zajímavě¹ – ale co složitější struktury? Dejme tomu, že v systému budu chtít evidovat osoby a u nich jejich rodné číslo, jméno, příjmení atd. Jak teď zapíšu funkci, která má jako argument přijímat osobu (a odmítnout třeba zvíře nebo věc)?

A co ten dotazovací jazyk – fungoval by jen nad kolekcemi v paměti nebo i nad nějakým trvalým úložištěm?

_{[1] i když nevím, jestli bych chtěl tolik svazovat program s ukázkovými daty}

[JS1]

Co se tyka slozitejsich struktur, to je duvod, proc je potreba se s abstrakci posunout o uroven vys, od pouhych slozenych datovym typum, primo k datovemu modelu.

Jinak to co rikas dal s tim argumentem je samozrejme dobra otazka. Castecne na to odpovi dalsi kapitola, ktera bude popisovat typovy adhoc adhoc-morfismus (v podstate jde o adhoc polymorfismus, ktery je jeste trochu vic adhoc).

Idealne by nemel byt velky rozdil, jestli je kolekce v pameti nebo je vazana na trvale uloziste. Takze ano, mel by tak fungovat.

[deda.jabko]

V Schemiku mam neco podobneho. Ke kazdemu S-vyrazu si prekladac uklada dodatecne informace, priznaky, reprezentaci v IR, prelozeny kod, atd. semantikou se to podoba spis p-listum, coz mi prijde pohodlnejsi nez tve reseni, protoze se pak s tim da pracovat pomoci beznych funkci.

Do budoucna mam v planu udelat prekladac, ktery funguje na podobne bazi, co tu navrhujes, s tim rozdilem, ze pokud udela chybnou hypotezu o datovem typu a dostane neodpovidajici data, sam to rozezna a nove prekompiluje kod.

Ten napad s ^ a anotacemi se mi libi, asi si jej vypujcim. ;-]

[JS1]

Do budoucna mam v planu udelat prekladac, ktery funguje na podobne bazi, co tu navrhujes, s tim rozdilem, ze pokud udela chybnou hypotezu o datovem typu a dostane neodpovidajici data, sam to rozezna a nove prekompiluje kod.

Skvele!

Ten napad s ^ a anotacemi se mi libi, asi si jej vypujcim. ;-]

Do toho.

[backinabag]

Skryvani anotaci je dobry napad, o necem podobnem jsem taky premyslel.

Libilo by se mi, kdyby mi IDE defaultne skryvalo mene relevatni casti kodu jako:

• Komentare, dokumentace.
• Osetrovani vyjimek.
• Logovani.
• Mereni rychlosti.

Ted je problem v tom, ze ruzny casti zdrojovyho kodu jsou ruzne dulezite, ale vypadaji stejne. 90% casu pro me jsou komentare, logovani, vyjimky jenom rusive prvky, ktere musim odfiltrovat.

Reseni by bylo napriklad zobrazovat komentare / dokumentaci podobnym stylem jako komentare v Google Docs. A logovani, vyjimky, atd. treba defaultne sbalit nebo obarvit do seda.

Ted me napada, ze by bylo zajimave nejak reflektovat strukturu kodu po vizualni strance. Napriklad funkce by mohly byt zabalene do jakychsi boxu... no ale to se spatne vysvetluje.

[Bystroushaak]

A Whole New World, kdyby to někdo náhodou ještě neviděl. Pokud se vám nepřehrává to online video, doporučuji download button vlevo dole.

[JS1]

Dokumentaci bych klidne umistil do anotaci, jistou formu logovani taky (ani ne tolik na aplikacni urovni, anotace nemaji byt aspektove-orientovane programovani), mereni rychlosti taky (na tom by bylo castecne zalozene to hadani typu).

Ale vyjimky - chybove stavy musi zustat osetrene v normalnim programu. A jelikoz Crisp ma byt moderni jazyk, mel by signaly a la Common Lisp. Ale je pravda, ze chyby jsou obecne problem, a zatim nevim o dobre metodice, jak toto resit (myslim hlavne co do designu). Ale myslim, ze by bylo vhodne nejak oddelit 3 zasadni druhy chyb:

- Spatne argumenty nebo vstupy do funkce - napriklad argument je null - mohou v podstate nastat jen na konkretnim miste, a pokracovat se neda

- Interni logicke chyby - diky chybe v programu se stalo neco, s cim nikdo nepocital, treba nejaka datova struktura je nahle nekonzistentni - mohou nastat kdekoli, a je otazka, zda ma program vubec pokracovat a jak

- Chyby prostredi, typicky nedostatek nejakeho zdroje - treba selhani zapisu na disk - mohou nastat vicemene kdekoli, a typicky lze nejak pokracovat (zkusit znovu pozdeji apod.), a je treba je umet osetrit

Hezke by bylo mit konstrukt, neco jako "zkus toto a toto a toto", a pokud cokoli z toho selze, zapomen na to a stejnou cestou uvolni zdroje. Dalo by se na to udelat hezke makro, neco jako let, ale s tim, ze by kazda forma byla (promenna inicializace destrukce), kde pokud by promenna po inicializaci byla nil, pripadne na konci bloku, provedly by se prislusne destrukce.

Mohla by ale existovat obecna anotace, ktera by rikala, jak moc je ktera cast kodu dulezita. Nebo by mohlo byt mozne pustit program jen jednou, a nechat si zobrazit jen ty casti, ktere se skutecne provedly (tim by se odstranila velka cast kodu pro reseni chybovych stavu).

[Josef Kufner]

Takové množství informací bude značně neefektivní ukládat do zdrojového kódu. Co tam dát jen značku/referenci/unikátní ID a ukládat data vedle? Vem si, kolik dat vyleze například z profileru. To by s tím měl jakýkoliv editor značné problémy.

S myšlenkou dialogu se to nevylučuje, ale zdrojový kód by měl obsaohvat jen půlku. Ta druhá, od počítače, by měla být stranou a v podstatě jen nakešovaná, neboť se z té první půlky dá dopočítat.

[JS1]

Ano, nad tim jsem uvazoval. Zavery, ktere lze logicky dopocitat, a data z profileru (jako treba ty typicke hodnoty) by skutecne bylo lepsi davat stranou a odkazovat se nejakou referenci.

Jinak je to samozrejme kompromis. Mel by pocitac mit pravo upravovat zdrojovy kod, a jak moc? Oboji ma svoje vyhody a nevyhody - jak reseni, kdy jsou ta data zcela mimo, tak reseni, kdy jsou vsechna uvnitr.

[deda.jabko]

Mel by pocitac mit pravo upravovat zdrojovy kod, a jak moc?

Tohle je podle me slepa cesta, obzvlast v situaci, kdy vetsinu casu clovek stravi udrzbou stareho kodu. Predstava, ze do toho kodu jeste bude hrabat pocitac, je desiva.

[JS1]

To se hezky rekne, ale tezko udela. Pokud do toho kodu nebude zasahovat vubec (ani formou tech anotaci - coz je prave tak nejak system, ktery navrhuji), pak zase snadno vznikne nekonzistence mezi tim, co je v kodu a co je v nejakem externim souboru. Oboji ma svoje pro a proti. Minimalne ty vnejsi odkazy (jak nekde navrhoval Josef Kufner) by tam asi mely byt. Optimalni implementace muze vypadat jinak - chtelo by to experimentovat.

A mimochodem prave pro udrzbu stareho kodu by myslim bylo skvele vedet, jake jsou napriklad typicke hodnoty promennych.

[backinabag]

Nejvic se mi libi jak resi vyjimky Go, pomoci vice navratovych hodnot.

Spatne argumenty nebo vstupy do funkce

Interni logicke chyby

Vyjimky, jejichz vyvolani znamena chybu v kodu, bych normalne vubec neosetroval. Myslel jsem spis vyjimecne stavy okolniho prostredi, jako prave selhani disku nebo network timeout.

Nebo by mohlo byt mozne pustit program jen jednou, a nechat si zobrazit jen ty casti, ktere se skutecne provedly (tim by se odstranila velka cast kodu pro reseni chybovych stavu).

Tohle mi uprimne receno prijde strasne fragilni, mozna ze by to vetsinou fungovalo, ale nebudu mit jistotu. Pripomina mi to programovani stylem ze neco rychle napisu, zkusim jestli to funguje, pokud ne, neco nahodne zmenim, zkusim zase atd.

[JS1]

Nejvic se mi libi jak resi vyjimky Go, pomoci vice navratovych hodnot.

Vice navratovych hodnot je samozrejme uzitecna vlastnost. Ale trochu jina nez signaly.

Vyjimky, jejichz vyvolani znamena chybu v kodu, bych normalne vubec neosetroval. Myslel jsem spis vyjimecne stavy okolniho prostredi, jako prave selhani disku nebo network timeout.

A kdyz nastane chyba pri zpracovani pozadavku, znamena to, ze se shodi cely server na neosetrenou vyjimku?

Tohle mi uprimne receno prijde strasne fragilni, mozna ze by to vetsinou fungovalo, ale nebudu mit jistotu. Pripomina mi to programovani stylem ze neco rychle napisu, zkusim jestli to funguje, pokud ne, neco nahodne zmenim, zkusim zase atd.

Javisti chteji mit porad jistotu. Ale o tom to prece je - takhle by melo programovani vypadat. Akorat tady ti kompilator da zpetnou vazbu, jestli co jsi napsal dava smysl, takze po tom, co se to vyrobi se to da prohlednout na dalsi mozne chyby.

Ja vidim statickou analyzu jako diminishing returns. Radsi bych, kdyby se proste pocitalo s tim, ze to neni jiste, a lide byli diky tomu ostrazitejsi proti chybam, nez aby se 100% spolehali na analyzu, ktera beztak nikdy 100% neni. Jeste se k tomu vratim v dalsich blogpostech.

(Kazdopadne, ja reagoval na zpusob, jak detekovat, rekneme pro prvni cteni, ktere casti kodu jsou dulezite a ktere ne.)

[backinabag]

A kdyz nastane chyba pri zpracovani pozadavku, znamena to, ze se shodi cely server na neosetrenou vyjimku?

Tady bych pouzil stejny pristup jako v Jave - tenhle typ vyjimek (v Jave RuntimeException) by programator za normalnich okolnosti neosetroval, ale mel by moznost to udelat. Takze napriklad kontejner ve kterem bezi webova sluzba by tyto vyjimky osetroval.

Ale o tom to prece je - takhle by melo programovani vypadat. Akorat tady ti kompilator da zpetnou vazbu, jestli co jsi napsal dava smysl, takze po tom, co se to vyrobi se to da prohlednout na dalsi mozne chyby.

Tak v tomhle se vubec neshodneme

Ja vidim statickou analyzu jako diminishing returns.

Staticka analyza je u netrivialnich projektu strasne uzitecna, hlavne pri refaktorovani.

[JS1]

Myslel jsem spis vyjimecne stavy okolniho prostredi, jako prave selhani disku nebo network timeout.

Jinak me pripada, ze by ani nebyl problem tyto veci automaticky metodicky resit (aspon tedy v jazyce, ktery umi treba makra apod.).

Potiz je v tom, ze vetsinou chceme v techto situacich informovat uzivatele, a musime mu smysluplne sdelit, v jakem stavu se program nachazi, a na jakou prekazku v praci narazil. A prave tohle prevadeni do lidske reci je na tom to pracne; protoze to zadny kompilator sam od sebe neudela (protoze nechape relevantni kontext cele situace).

[Josef Kufner]

A v tomhle jsou krásné klasické výjimky, kdy se chyba nechá odbublat pryč a kód, který ji ukáže uživateli může být až na okraji tohoto kontextu a společný pro velkou část chyb.

[JS1]

A to je taky nekdy duvod, proc to tak hezke neni.. Je to proste slozity problem, ale hlavne pro ten lidsky faktor.

[Ondrej 'SanTiago' Zajicek]

K syndromu ditete v cukrarne a k syndromu analyzy paralyzou (nebo spis paralyzy analyzou) se taky hlasim.

Nad podobnyma anotacema jsem take premyslel, ale me uvahy sly trochu jinym smerem: Krome samotneho programovaciho jazyka by existoval jeste druhy jazyk urceny na metaprogramovani. Narozdil od Lispu, kde se na metaprogramovani/makra pouziva stejny jazyk, tak tady by slo o jazyk podstatne odlisny, a to nejaky ryze logicky jazyk (a la Prolog). Anotace by pak byly jen tvrzeni v onom metajazyce o jednotlivych syntaktickych entitach v programu. V danem metajazyce by byla implementovana i podstatna cast bezne funkcionality jazyka (napr. typovy system a reprezentace objektu v pameti). V typovem systemu pak nema smysl uvazovat o zbytecnych konceptech jako jsou tridy a dedicnost, kdyz stejnou funkci plni anotacni predikaty a implikace mezi nima. Podobne by fungoval i compile-time ad-hoc polymorfismus, coz by fungovalo jako obecny dispatch na zaklade automatickeho dokazovani v metajazyce (pri volani pretizene funkce by se vybrala ta implementace, jiz pozadovane axiomy by byly splenene v miste volani, kde typ argumentu je jen jeden z mnoha moznych uziti).

Druha, ale vicemene nesouvisejici, myslenka k tematu, je to, ze by mela existovat faze pred-prekladu, kterou by provadel vyvojar pred distribuci softwaru v podobe zdrojoveho kodu. V teto fazi by doslo napr. k resolvovani jmen v ramci ruznych namespace na absolutni jmeno, takze by pak nemohlo dojit ke kolizi v dusledku toho, ze zavedenim noveho jmena do namespace napr. nejake vyuzivane knihovny dojde ke kolizi. V kontextu predchozi myslenky by asi v ramci teto faze probehlo dokazovani v metajazyce a vysledky by se ulozily.

[JS1]

To prvni je vynikajici napad. Muj pristup byl spis pragmaticky, rad bych ten jazyk proste mel, nez si udelal PhD (tim to nechci shodit - bylo by naopak velmi dobre, kdyby tomu nekdo dal vic formalni podobu, ja bych asi postupoval vic adhoc). Ale urcite by se dala udelat specialni anotace obsahujici tato metatvrzeni (i kdyz je otazka, jestli by pro tu dynamickou analyzu stacila ciste logicka dedukce). Myslim, ze je to take blizke myslenkam reprezentovat ruzne funkcni invarianty, preconditions, postconditions.

S temi typy a reprezentaci v pameti souhlasim, v podstate je to neco, o cem chci psat v pokracovani tohoto blogpostu.

Tomu pred-prekladu moc nerozumim. Mozna bys to mohl trochu rozvest. Znamena to, ze by se ten zdrojovy kod nejak permanentne poznamenal?

[Kvakor]

Tomu pred-prekladu moc nerozumim. Mozna bys to mohl trochu rozvest. Znamena to, ze by se ten zdrojovy kod nejak permanentne poznamenal?

Nevím, jestli jsem to pochopil správně, ale myslím, že se zdrojovýk kódem by se nic nedělalo, výsledek by byl analogický např. prohnáním zdrojového kódu v C preprocesorem, kde se expandují všechna makra, tedy až na to, že by se převedla všechna jména z relativcních jmenných prostorů na absolutní (podobně jako je kanonizace cesty v souborovém systíému) a otestovala, jestli jsou unikátní v globálnímu jmennému (nad)prostoru zahrbnujícím všechny použité knihovny a "netřískají se" navzájem. Takže vlastně by to bylo něco úplně jiného než expanze maker preprocesorem v C, ale výsledkem by také nejspíš byl nový sobvor, protože mít ve zdrojáku jména všecho v absolutní podobě by nejen nepohodlné, ale vypadalo to hůř než Win32 API na tripu

[JS1]

Tomu nerozumim. Pokud ta jmena lze kanonizovat, proc by nemela byt unikatni? Aby treba nekdo pozdeji nevolal stejny modul ze dvou ruznych modulu, a ta jmena mela jiny vyznam? To bylo ale mohlo byt i uzitecne.. nevim.

[Ondrej 'SanTiago' Zajicek]

Protoze mohou jit kanonizovat na systemu programatora, ale kdyz si uzivatel stahne zdrojaky a bude mit novejsi verzi knihoven, kde doslo k pridani novych jmen, tak uz tam muzou byt kolize. Bez neceho podobneho v podstate nelze zajistit kompatibilni rozsireni rozhrani knihovny, protoze jakekoliv rozsireni rozhrani muze zpusobit kolizi pri pouziti nekanonizovanych jmen.

Ukladat by to melo smysl do samostatnych souboru (spolu s dalsima informacema vytazenyma z daneho zdrojaku).

[JS1]

Aha, uz chapu, o co ti jde. Napriklad programator si rozsiri externi knihovnu materialu o nejakou tridu Gold. V dalsi verzi bude knihovna obsahovat jinou, vlastni implementaci tridy Gold. V takovem pripade, na stroji nekoho z budoucnosti, build selze. Takhle by se reklo - ale ja myslim to svoje Gold, ne to cizi Gold, a vsechno by bylo v poradku.

To zni rozumne, i kdyz si nejsem jisty, jak moc je to problem pri rozumne navrzenem systemu balicku/modulu (co mivaji moderni jazyky - specialne se mi libi Go, ktere ma krasne vyresene public/private pomoci jmenne konvence).

[xkucf03]

Na to přece stačí jmenné prostory a zásada, že každý přidává struktury jen do svých jmenných prostorů, jinak riskuje konflikt, ne?

Nepřijde mi, že by v tom byl nějaký problém – v Javě třeba běžně implementuješ cizí rozhraní nebo rozšiřuješ cizí třídy, ale svůj kód dáváš do svých balíčků.

A taky bych rozlišoval balíčky a moduly. Balíčky vytvářejí hierarchii jmenných prostorů, tříd/rozhraní a zajišťují globální jedinečnost. Modul pak může zastřešovat související funkcionalitu z různých jmenných prostorů a od různých autorů.

[JS1]

Musim rict, ze povazuji hierarchii jmennych prostoru za zbytecnou hruzu (a to je asi castecne problem, na ktery narazi Ondrej). Je to jen pro dobry pocit z vyssi abstrakce, jinak to zadny prakticky smysl nema. Common Lisp a Go (tusim) hierarchicke jmenne prostory nemaji a funguje to bez problemu.

V Crispu by system modulu (Crisp by nemel tridy) patrne fungoval podobne jako v CL nebo Go. Je to jednoduche a ucinne.

[xkucf03]

Já v tom tedy smysl vidím. Ten jmenný prostor má vlastně dvě části: organizaci/autora a produkt/komponentu:

1. Část NS, která označuje organizaci/výrobce/autora, by měla být globálně unikátní, aby nemohlo docházet ke konfliktům (např. dva autoři jménem Franta, dvě firmy Foo). A to se dá řešit pomocí nějakého zvláštního registru (jako třeba enterprise numbers od IANA) nebo to lze odvodit od internetové domény (cz.frantovo.…).
2. Část NS, která označuje produkt daného výrobce nebo jeho část, komponentu, subkomponentu, která je unikátní v rámci té první části NS.

Už jen tohle vyžaduje minimálně dvouúrovňovou hierarchii. Jasně, šlo by sice hierarchii formálně nemít, NS by byl jen textový řetězec oficiálně bez vnitřního členění. A pak by se používala nějaká konvence – třeba oddělovat části podtržítkem. Ale pak by to museli dělat všichni stejně a konvenci dodržovat, aby ti např. IDE mohlo ukazovat hezký strom balíčků a neměl jsi to všechno nasypané na jedné hromadě.

A zvlášť, když se vymýšlí nový jazyk, tak by se to mělo udělat pořádně, mít podporu hierarchie rovnou v něm, nějakým standardním způsobem a ne to tam dodatečně dobastlovat pomocí nějaké konvence – to se hodí leda pro legacy prostředí, kde se na to v době návrhu zapomnělo a teď už to tam pořádně dodělat nejde.

[JS1]

Ja chapu, ze by se ti Crisp asi nelibil, ale pristupem by to byl spis liberalni nez konzervativni jazyk. (Asi spis dost liberalni, protoze by se dost spolehalo na cely ten byznys s dynamickou analyzou.)

Podivej se jak to funguje v Go. Tam (aspon jak to chapu ja, v Go jsem delal akorat tutorial par mesicu nazpet) v ramci jednoho modulu ma kazdy importovany modul jedno jmeno, a import specifikuje jeho cestu (relativni nebo absolutni). Pokud dojde ke konfliktu, lze to jedno jmeno pod jakym se to naimportovalo zmenit na neco jineho, a odkazovat se tak na ten modul. Takze jmena maji nejvys jeden kvalifikator - lokalni jmeno toho modulu.

Zadny globalni registrator neni potreba. Jako programatorovi modulu, co je mi po tom, ktera instituce to vydala a jak si to vnitrne zorganizovala? Ja jen potrebuji zvenci videt to, co je v tom modulu definovane, a mechanismus, jakym resit konflikty (protoze jsou nevyhnutelne - obcas se napriklad hodi naimportovat dve ruzne verze teze knihovny).

Je to v souladu s Crispovou filozofii - nejak to nabouchat, nechat si od pocitace sdelit, ze to asi takhle nemuze fungovat, a pak teprve ten problem vyresit (misto toho se snazit vyresit ho jeste nez prijde, kdyz vetsinou neprijde). Samozrejme, v Crispu by to asi fungovalo malicko jinak, protoze by nebyl tak staticky jako Go. Ale ja jsem tam nad moduly zatim prilis nepremyslel.

[Ondrej 'SanTiago' Zajicek]

Neco takoveho, vystiznejsi priklad by byl asi tenhle:

Pouzivam dve knihovny A a B a funkci/tridu A::xxx. Importuju vsechny symboly z A i B a na A::xxx se odkazuji jen jako na xxx. V okamziku, kdy knihovna B take zavede funkci/tridu xxx, tak to prestane byt jednoznacne. Bud bych musel vsude pouzivat A::xxx, nebo explicitne specifikovat, ze importuju xxx z A, oboje je zbytecna byrokracie, pokud ke konfliktu nedochazi.

[Josef Kufner]

Pokud máš Ablablalba a Bblebleble, tak udělat import Ablablalba → A, Bblebleble → B. A pak máš jen A::xxx a B::xxx. Odstraňovat zcela odkud třída pochází zhoršuje čitelnost programu po delší době, nebo pokud čtenář nezná importované knihovny a autor není poruce.

V PHP je tohle udělané tak, že musíš importovat všechny použité třídy ručně, nelze importovat celý namespace, neboť dokud se třída neimportuje, tak PHP neví, že existuje. A pokud by se jen použila, tak neví, kde ji hledat. Takže pak máš v kódu jen xxx, ale na začátku máš jasně napsáno, že třída xxx je z A.