C++0x - rádi bychom měli x decimální :-)

16.8.2007 08:51 | Přečteno: 1458× | Ani zbla

Tak jsem zkoukl Stroustrupovu přednášku o budoucnosti C++ inzerovanou ve zprávičce. V prvé řadě to byla ukázka, jak nemožně může být americký vědec oblečený, to už je mnohem lepší Stallman se starým diskem na hlavě.

Přednáška celkem dobrá, bohužel zvuk převážně na levém kanálu. Nové fíčury v C++ přinášejí takové "novinky" jako například možnost inicializovat kontejner literálem. Bohužel kvůli tomu přidali asi padesátou možnost, jak něco inicializovat. Zkrátka vždycky když Bjarne hovořil o něčem, co úžasně zpřehlední kód, problesklo mi hlavou, jak elegantně je to vyřešeno v Pythonu/Ruby.

C++ umí generovat výborný nativní kód z dost vysokoúrovňového popisu (šablony...), to je jeho killer feature. Nicméně má to dost daleko k tomu, aby programátor psal, co chce opravdu udělat, místo toho musí psát kód, jehož sideefect je to, co chce opravdu udělat. Přidáváním nových vlastností s nutným zachováním zpětné kompatibility ale situaci příliš neprospívá.

Demokratický postup tvorby standardu mě taky neohromil, nesnáším Design by Commettee, ale jinak se to udělat asi nedá.

C++ je obrovský, nepřehledný jazyk plný temných koutů a chyb v kompilátorech. A bude větší a míň přehledný. Ale na velkou množinu problémů je to to nejlepší, co máme.

       

Komentáře

[msk]

Ja som to teda necital, ale musim za seba prehlasit, ze kedykolvek musim napisat nieco v pythone, vstavaju mi z toho vlasy na hlave. Priserna syntax, riadenie toku kodu indentom ( co za blba toto vymyslelo! ) ...

Prekopirovat fragment kodu z ineho scriptu - peklo na zemi. Pridat/ubrat vetvu v kode - peklo na zemi. Jedna whitespace omylom vlozena niekde do kodu - zahadne chovanie scriptu. Syntakticka chyba niekde v utrobach kodu - dozviem sa o nej za 2 roky, az ked sa pokusi vykonat.

Aj napriek nespornym vyhodam pythonu ( dost obsiahla "stdlib" ) su toto atributy, ktore ho podla mna znacne degraduju ...

[fakenickname]

me to chovani zase vyhovuje. sem spis designer nez programator takze vsechen muj kod je prehledne upraveny s komentaremi a vsechno je odsazene presne tak jak ma byt. nesnasim programatory, ktery pisou kod jak se jim to zrovna povede a cele to desektrat zprasi copy&paste. nejde to poradne cist

[happy barney]

dobrý design kódu je záležitosť človeka, nie syntaxe jazyka. Povedzte to inak, keby vás python nenútil pekne indentovať, všetko by sa vám zmestilo do jednoho riadku

[fakenickname]

nedelam v pythonu. programuju v jave, php, bashi a sem tam trochu v tom co je potreba..

[kyknos]

ale to je jedna z výhod pythonu, kvůli které ho mám rád

[Kyosuke]

A proto budeš mít rád i Haskell.

(Ranša Rosa? To je v Mexiku? )

[disorder]

nechcem sa zastavat pythonu, ale ty si hlavne zozen nejaky normalny editor a skus to znovu :)

[Lu-Tze]

Přesně tak. A ještě by se moh taky naučit programy testovat.

[Michal Kubeček]

riadenie toku kodu indentom ( co za blba toto vymyslelo! )

Za takové věci by měly být přísné tresty. To mi připomíná, že bych si měl konečně zjistit, kdo má na svědomí syntaxi makefilu… :-)

[Michal Vyskočil]

Stuart Feldman, více detailů, včetně vysvětlení, proč tam je ten tabulátor je v The Art of Unix Programming

[Kyosuke]

Dopisní bombu zašlete Stuartovi Feldmanovi do Googlu...

[thingie]

Vlezlá otázka, orientujete se v kódu podle závorek nebo podle odsazení? A proč by to měl překladač dělat jinak než vy?

[Ladicek]

Protože dělá něco jiného než vy?

[thingie]

Nedělá. Poznává podle toho bloky kódu. Stejně jako vy.

[Michal Kubeček]

Jak kdy. Vím, že puristé by mne vytahali za uši, ale věci jako

  if (R < 0) { perror("blabla"); exit(1); }

(to je jen příklad) mi připadá přehlednější napsat do jednoho řádku.

Jsem ochoten se skřípěním zubů akceptovat, když jazyk přikládá zvláštní význam značce konce řádku (Bourne shell, assemblery), ale jazyk, který nepřežije záměnu neprázdné posloupnosti mezer a tabulátorů jinou neprázdnou posloupností mezer a tabulátorů, považuji za zvrácený.

[Michal Vyskočil]

Jak kdy. Vím, že puristé by mne vytahali za uši, ale věci jako

  if (R < 0) { perror("blabla"); exit(1); }

(to je jen příklad) mi připadá přehlednější napsat do jednoho řádku.

To je argument proti Pythonu?

if True : print("koncim"); sys.exit()

V něm jde napsat taky.

ale jazyk, který nepřežije záměnu neprázdné posloupnosti mezer a tabulátorů jinou neprázdnou posloupností mezer a tabulátorů, považuji za zvrácený.

Popravdě, mě osobně se tato vlastnost Pythonu taky moc nelíbí (zlatý Haskell, tam si člověk aspoň vybere). Bílé znaky do syntaxe nepatří ... (ano, já mám :set list, ale co ostatní?)

[kyknos]

http://en.wikipedia.org/wiki/Whitespace_(programming_language) na tebe :D

[Rezza]

Tady RMS kaze sve evangelium teze

[andree]

a ty by si vyhodil 2k Kc do kosa kvoli presvedceniu?

[Lu-Tze]

Já bych jen odlepil tu nálepku

[Rezza]

Takze vyhodil dva tisice :) Jedna z vyhod open sourcu - nemusi clovek lepit nalepky!

[Rezza]

Jej, ja neresim tu nalepku, taky ji tam mam, ale ten svaty obrazek!

[Miloslav Ponkrác]

Sice jsem se už vyjadřoval ve zprávičce, ale budiž. C++0x je naprosto nepředložený počin, který C++ víc vezme, než dá.

V C++0x je pár hezkých věcí, které jsou vyváženy kupou naprostých zbytečností, které jen zesložití kompilátor na takovou míru, že se na to většina výrobců kompilátorů C++ vybodne. Sice nesouhlasím s tím, jak se v článku píše, že tu máme chybové kompilátory C++, naopak je na výběr z mnoha dobrých a kvalitních.

Jinak ani C++0x nepřidává do C++ takové naprosto základní věci, jak je třeba podpora finally, nebo přenositelných int typů, které jsou v C99. Ani C++0x nepřidává normální standardní základní objektovou knihovnu.

Problém je, že C++ už nemá tu neotřesitelnou pozici co míval. Dnes už nebudou chtít výrobci kompilátorů tolik investovat a velmi pochybuji, že implementují C++0x, které celý kompilátor několikanásobně zesložiťuje. Už předtím bylo napsání C++ kompilátorů složité, ale teď je to potuplováno. Vůbec strategie, necháme to skoro 20 let vyhnít a pak to pořádně zesložitíme se mi nelíbí - namísto toho měly postupně přicházet po malých částech inovace, které by se tím pádem rychle projevily v reálných kompilátorech.

[elviin]

Finally je syntakticky pohodlnejsi a hezci. Ale co se tyka funkce, tak to v C++ splnuje lokalni definice tridy: v konstruktoru resource inicializuju a v destruktoru opak. V pripade vyhozeni vyjimky mam jistotu, ze jsem spravne vycouval a nic mi nezustalo viset. C++ ma velky problem a to je to, ze spoleha na programatora, nabizi vicero moznosti reseni problemu. Ale to neni vlastnost jen jazyku. Ja bych zas tak nelamal hul na komisi. Musite uznat, ze prevazne videli pri C++97 do budoucna. Vyjadrovaci schopnost C++ je velika, viz boost. Ono to nejak dopadne.

[Miloslav Ponkrác]

No ano, finally se dá vždycky obejít tím, že všechny resource, pointery a další zabalím do třídy, třeba do ::std::auto_ptr. Pokud pracuji třeba s handly systému, už musím vytvářet deklaraci a definice nové třídy, která neslouží k ničemu jinému, než náhradě finally. Případně můžu vymýšlet zhůvěřilosti typu

catch (...) { finally_akce; throw; } finally_akce;

V mnoha případech by to finally bylo lepší. Koneckonců C++ je snad jediný jazyk s podporou výjimek, který nepodporuje finally.

[Sinuhet]

Ano ano, proc si na handle napsat nejakou tridu, ve ktere jednou pro vzdy naimplementuju zpusob uvolnovani a dal se o nic nestarat? Proc na zobecneni takove tridy pouzit sablony, pripadne makra?

Mnohem lepsi je se stale dokolecka kopirovat jeden a ten samy kus kodu s finally, znovu a znovu psat kontroly zdali uz byl handle v try {} inicializovan a muzu ho uvolnit, neustale premyslet nad tim, kde mi muze vybublat vyjimka a kde bude treba pridat finally s uvolnenim...

[Miloslav Ponkrác]

A proč namísto toho nemít finally?

Když budu mít v programu třeba 1000 druhů různých handlů, každý druh handle se bude zavírat naprosto jinou funkcí - ejhle máme tu tisíc tříd, které budou navíc v projektu jen proto, že není finally.

Nad tím, kde může vybublat výjimka se přeci nemusí přemýšlet - ta může vybublat naprosto všude v jakémkoli místě kódu.

[Deleted [8409]]

C++ neni Java. Pokud ocekavate vyjimku, tak neni problem se na ni pripravit a popripade uvolnit alokovane objekty nebo data. Pokud je vyjimka neocekavana, vede to stejne k padu aplikace, protoze se z ni aplikace neni shcopna sama zotavit.

Ja osobne si myslim, ze zrovna vyjimky a RTTI jsou nejmin uzitecna vec v C++.

[alblaho]

V plain C je polovina kódu kontroly návratových hodnot a zotavení z chyb. Výjimky tohle skóre dokáží podstatně vylepšit.

[Deleted [8409]]

Citelnost kodu dokazi zvysit, ale i presto se musi programator zaobirat tim, aby v pripade vyjimky (ktera by mela byt vyjimecna) po sobe vsechno uklidil. Toto musite resit i v plain C kdyz skonci funkce chybou, i v C++ kdyz vyhodi funkce / metoda vyjimku.

Mimochodem, citelnost kodu dokaze zvysit i dobre napsany kod a to mozna mnohokrat vic nez pri pouziti vyjimek

[Sinuhet]

Treba proto, ze to je kratsi, jednodussi a bezpecnejsi?

[Miloslav Ponkrác]

Opravdu je napsání deklarace třídy, definice třídy, napsání kódu konstruktoru a destruktoru kratší, než jednoduché použití finally?

Bezpečnější? Z hlediska vnitřního fungování je automatické volání destruktoru a volání bloku finally úplně to samé! Co myslíte, že je automatické volání destruktoru jiného, než zakleté finally? Dokonce strojový kód v případě finally je kratší a rychlejší, protože kompilátor si ušetří budování seznamu lokální objektů k destrukci! Ale ve strojovém kódu je automatické volání destruktorů a finally naprosto to samé! Je to totéž! Jak tedy jedno může být bezpečnější, než druhé?

Obojí je nenahraditelné. Jsem nadšen, že C++ bezpečně destruuje lokální objekty, aniž bych se o to musel starat. V jiných případech podle situace je buď lepší balit do objektů, a nebo rovnou napsat jeden finally řádek a bylo by to.

[Sinuhet]

Opravdu je napsání deklarace třídy, definice třídy, napsání kódu konstruktoru a destruktoru kratší, než jednoduché použití finally?

Jestli je pro vas neprekonatelny problem abstrahovat opakujici se kod a udelat to tak, abyste pro vygenerovani tridy zadaval jen typ handlu, funkci pro uvolneni a nazev, tak vam neni pomoci. Pokud handle pouzijete v celem programu pouze jednou, tak to vyjde (± pismeno) nastejno. Jakekoliv dalsi pouziti je cista ztrata pro finally.

Dokonce strojový kód v případě finally je kratší a rychlejší, protože kompilátor si ušetří budování seznamu lokální objektů k destrukci! Ale ve strojovém kódu je automatické volání destruktorů a finally naprosto to samé! Je to totéž! Jak tedy jedno může být bezpečnější, než druhé?

Jestli se vam program vlece kvuli "stack unwind" a hodlate to resit pomoci finally, tak vam neni pomoci. Rozdil je prave v tom, ze seznamy objektu k destrukci za vas vytvari kompilator, v pripade finally toto musite dalat sam. Ze se ma volat nejaka funkce na uklizeni je receno uz pri definici promenne, nemuze se vam stat, ze byste na uvolneni zapomnel, vubec to neresite - proto je to bezpecnejsi.

A az zas budete do c++ tlacit finally kvuli handlum, tak se hlavne v kontrastu k tomu nezapomente zminit, ze se vybor do standardu chysta prosadit spoustu naprosto zbytecnych veci...

[Miloslav Ponkrác]

Ne, není pro mě nepřekonatelný problém abstrahovat opakující se kód, ale pokud je kód jednorázový, je to poněkud byrokratické. Jinak viděl jste někdy použití finally?

handle_type some_handle = ::CreateHandleFromOsAPI(bla bla); try { ... } finally { if (some_handle != null_handle) ::CloseHandleOsApi(); }

Pokud je to jednorázové, rozhodně to není to samé co napsat definici třídy (pro jistotu připomínám, že handlů není jeden druh, aby to šlo odepsat jednou třídou).

Kde jsem napsal, že se mi program vleče kvůli "stack unwind"?

Poslední odstaven no comment. Zřejmě Vám Vaše žena nedala a Vy holt si nemáte kde vybít zlost.

[Deleted [8409]]

handle_type some_handle = ::CreateHandleFromOsAPI(bla bla); try { ... } finally { if (some_handle != null_handle) ::CloseHandleOsApi(); }

Moc nechapu, proc na takovy jednoduchy kod potrebujete nove klicove slovo v jazyce C++ ?

pro jistotu připomínám, že handlů není jeden druh, aby to šlo odepsat jednou třídou

Rika vam neco termin "template specialization" ?

[Kyosuke]

Sranda, co? Jiné jazyky to umějí desítky let. Ono se to hodí na všelijaké věci. S makrosystémem a bez výjimek třeba právě k té implementaci výjimek. Důležité je všimnout si toho "special operator" V Lispu není special operator nic, co jím být nemusí. Je jich tam jen pětadvacet, a nad nimi je vystavěno všechno. Jinými slovy, to, co Vy tady považujete za nové zbytečné klíčové slovo, je jinde považováno za užitečné primitivum pro flow of control.

[Sinuhet]

V LISPu je na tohle stavebnim kamenem unwind-protect, v C++ destruktory a RAII. Pridanim finally do C++ nic neziskate, nic dalsiho nad nim nepostavite. LISP a C++ jsou holt hodne rozdilne jazyky, ke kazdemu se hodi neco jineho.

[Kyosuke]

Ano, C++ podle Vašich představ je zřejmě vylepšený Turingův stroj...

[Bluebear]

Řekl bych, že to jsou všechny dosud známé programovací jazyky...

[Sinuhet]

Asi nechcete tvrdit, ze c++ neni ekvivaletni s Turingovym strojem, takze bohuzel nechapu pointu vasi poznamky...

[Kyosuke]

Ano, nechápete.

[Sinuhet]

A nechcete se rozepsat? Docela rad bych vedel o co prichazim.

[Sinuhet]

Ok, deme si je premerovat.

DEFINE_RRELEASE_CLASS(scoped_handle, handle_type, ::CloseHandleApi());
...
scoped_handle some_handle = ::CreateHandleFromOsAPI(bla bla);
...

Kde jsem napsal, že se mi program vleče kvůli "stack unwind"?

To jsem si dovolil vydedukovat z vasi odpovedi. Protoze jestli se vam program nevlece kvuli "stack unwind", tak naprosto nechapu proc resite na kolik instrukci vam vyjde finally a na kolik destruktory.

[podlesh]

Já vím že bych se do toho neměl motat, než také něco schytám, ale neodolám: To si opravdu nedokážete představit jiné možné využití finally než je destrukce objektu či uvolnění "handlu"?

[Sinuhet]

No tak s handlama si nabehl pan Ponkrac, ja si je nevymyslel.

Ano, dovedu si predstavit pripady, kdy vam to muze usetrit par radku kodu. Jenze finally neresi podstatu problemu, je to jen berlicka, ktera se neda k nicemu dalsimu pouzit. Doufejme, ze v novem stadardu bude vyresena ta postata (napr. pridanim lambda funkci) a pak uz bude podobna debata zbytecna.

[Sinuhet]

Prosim vas, pane Ponkraci, nesirte tady ty blbosti. Namatkove:

- novy kompilator
Nove vlastnosti prekvapive vyzaduji implementaci v prekladacich. Nastesti pripominky jejich vyvojaru jsou brany vazne, prave z toho duvodu, ze nikdo nechce, aby se opakovalo fiasko s exportovnanim sablon. Krom toho, pro gcc uz existuje iplementace napr. konceptu, "variadic templates", ...

- finally
V C++ se pouzivaji jine techniky, coz je ostatne duvod, proc se nikdo ani nepokusil to navrhnout a proc to nikomu neschazi.

- nebudou C99 int
Na to jste prisel jak?

[elviin]

Ja jsem si zase myslel, ze finally bude tutovka:)

[Miloslav Ponkrác]

A chcete snad říci, že běžné kompilátory bez úpravy zvládnou C++0x? Problém je jeden, že neexistuje jenom gcc. Já vím, že gcc implementuje leccos, na co se všichni ostatní vykašlou a tak to asi dopadne.

Co se týká fiaska ohledně exportování šablon, tak po celou dobu co sleduji vývoj C++0x, tak mohu zodpovědně říci, že C++0x _počítá_ s exportováním šablon a čas od času se v návrzích objevuje. Jestli bude v konečné verzi, to nikdo neví.

Ale ano, nepřítomnost finally se nakonec vždycky dá nějak obejít, ale dost často je to jen obcházení.

[Deleted [8409]]

Muzete uvest priklad, jak se obchazi podle vas finally?

[Deleted [8409]]

Pan Ponkrac vsechno vi na 100%, hlavne skinovani aplikaci ma v maliku

[Miloslav Ponkrác]

Á pan dark, tak to snad abych Vás ignoroval, když nepíšete k věci, ale snažíte se mě pouze shodit. Takže s prominutím na Vás nebudu v této diskusi reagovat.

[Deleted [8409]]

Ale pane Ponkrac, neberte vsechno tak osobne Vzdyt preci mam pravo se zasmat a jen jsem rad, ze nejsem sam, komu nektere vase prispevky pripadaji nepodlozene a chybne.

[Daniel Kvasnička ml.]

Ten Stallman je monstrozni!!

[pavlix]

Jj, ukazuje svoji pravou náturu.

[Kyosuke]

Ale kdepak...

[arthur dent]

co je na tom stitku????????

[cccc]

> Zkrátka vždycky když Bjarne hovořil o něčem, co úžasně zpřehlední kód, problesklo mi hlavou, jak elegantně je to vyřešeno v Pythonu/Ruby.

- Srovnavas nesrovnatelny. Je jasny ze v interpretovanym jazyku jdou delat veci o kterejch si v kompilovanym muzes nechat jenom zdat. Ale i naopak - C++ dosahuje rychlosti o ktery si v Pythonu/Ruby muzes nechat jen zdat...

Kazdej z tech jazyku je urcenej pro jinou oblast, kde jsou logicky jiny priority...

[Kyosuke]

Ale? Odkdy jsou jazyky interpretované a kompilované? Nejsou takhle náhodou interpretované a kompilované výhradně jejich implementace?

[Michal Kubeček]

Teoreticky ano. Ale vzhledem k tomu, že typické interpretované jazyky obvykle obsahují nějakou formu include, znamenalo by to, že každý zkompilovaný program, který by ho použil, by v sobě musel obsahovat interpreter jazyka, což IMHO praktickou použitelnost takového počinu značně sráží…

[Kyosuke]

Ne, musel by v sobě mít kompilátor. To IMHO není až takový problém, pokud to člověk potřebuje. A pokud to nepotřebuje, není problém to zkompilovat staticky. Koneckonců to trošku hapruje s testovatelností, takže se jistě najdou i tací, co to nebudou chtít umožnit, aby se nemohli uživatelé střílet do nohy.

[Filip Jirsák]

Ale vzhledem k tomu, že typické interpretované jazyky obvykle obsahují nějakou formu include,

To mě vždycky udivovalo, jak jsou v tomhle různé implementace JavaScriptu jednotné a o include jej nikdo nerozšíří a nerozšíří…

[deda.jabko]

proc taky? kdyz je tam "eval" ;-]

[Filip Jirsák]

No jo, jenže include umí vzít skript „zvenku“, eval umí pracovat jen s tím, co už má. Takže mu skript musíte dopravit jinou cestou, pokud něco takového umožňuje prostředí, ve kterém je interpret spuštěn. XMLHttpRequest ve webových prohlížečích je poměrně mladá záležitost, a chybějící include v JS pro Windows Scripting Host vypadá jako špatný vtip (přestavte si, jak by se asi pracovalo s unixovým shellem bez source).

[deda.jabko]

ale to uz zalezi na prostredi jake objekty/tridy poskytne...

pokud poskytne I/O operace, tak neni co resit... pokud se nekdo rozhodne, ze to neni dobry napad (treba jako v prohlizeci....) je to jeho problem....

sveho casu jsem si hral s knihovnou rhino... a to byste se divil co dokaze ecmascript, kdyz ma ty spravne bindingy....

s WSH jsem nemel dikybohu tu cest... ale pokud tam jdou instanciovat jakekoliv activex objekty (z cehoz mam docela strach) tak by nemel byt problem takvou funkcionalitu dopsat...

[Filip Jirsák]

sveho casu jsem si hral s knihovnou rhino... a to byste se divil co dokaze ecmascript, kdyz ma ty spravne bindingy....

Rhino už je součástí sunovské Javy 6, tam už je těch objektů pro binding docela dost

Což mi připomíná, že Java už vlastně tu možnost include má, protože načtení bajtkódu třídy z pole bajtů umí odpradávna, a v 6 už jsou i veřejné třídy pro volání kompilátoru (pokud je k dispozici, samozřejmě).

Takže to můžeme uzavřít, že interpretované jazyky zpravidla include mají, zatímco kompilované ne, přičemž pro jazyky s názvem vyhovujícím vzoru "Java*" platí výrok obráceně

s WSH jsem nemel dikybohu tu cest... ale pokud tam jdou instanciovat jakekoliv activex objekty (z cehoz mam docela strach) tak by nemel byt problem takvou funkcionalitu dopsat...

ActiveX tam fungují, takže by to šlo. Dokonce jsou pro WSH myslím nějaké objekty pro čtení souborů už přímo v systému. Ale pořád je jaksi nešikovné v prostředí, které má být určeno pro tvorbu systémových skriptů, programovat include na 5 řádek

[Michal Kubeček]

s WSH jsem nemel dikybohu tu cest...

Já bohužel ano. Konkrétně, když jsem ke své značné nelibosti zjistil, že Explorer (neplést s Internet Explorerem) ve Windows 98SE schovává některé přípony (např. shs) i v případě, že se mu v konfiguraci zaškrtne "zobrazovat přípony všech typů". Velmi praktické…

[thingie]

Co? Eval umí vyhodnotit řetězec, který se dá za běhu v tom skriptu napsat, dá se načíst z čehokoliv... (nebo se pletu? JS není můj obor)

[deda.jabko]

muj taky ne.... ale tvrdi to kolega google -> http://www.w3schools.com/jsref/jsref_eval.asp

[Deleted [8409]]

Eval proste spusti kod v retezci. Jedna moje mensi aplikace, ve ktere jsem s radosti vyuzil neceho takoveho je tady:

http://www.wdesktop.org/vypocty/vypocet.html

Byl to vypocet diferencnich rovnic, ktere po nas chteli pocitat rucne Urcite se problem da resit i jinak, ale ja to mel za 2 hodky hotove a hodne me to bavilo programovat a ulehcilo pocitani... no pocitani to ulehcilo asi vsem v rocniku

[deda.jabko]

teda kdybych si jeste vzpomel na to, co jsou to diferencni rovnice.... nejaky patek uz to je za mnou....

nicmene, ja bych na neco takoveho pouzil lisp/scheme.... kdyz to pouzijete jako funkci mate symbolicke reseni, kdyz jako makro muzete mit numericke reseni....

[Filip Jirsák]

Co? Eval umí vyhodnotit řetězec, který se dá za běhu v tom skriptu napsat, dá se načíst z čehokoliv...

Ano, přesně tak. Jenže problém je v tom „z čehokoliv“ – JS jako takový nemá žádnou možnost získat takový řetězec odněkud „zvenku“. K tomu musí poskytnout nějaké objekty běhové prostředí, ve kterém ten JavaScript běží (třeba webový browser). Před XMLHttpRequestem to znamenalo mít ve stránce skrytý iframe, do něj JavaScript asynchronně načíst (a to ještě tak, aby jej browser neinterpretoval, ale nechal na pokoji), zkontrolovat, že se načetl opravdu JS a ne chybová stránka a pak jej spustit. Ve WSH to znamená načíst textový soubor, v cyklu ho projít po řádcích a načíst do řetězce a pak opět předat do eval. Fakt jednoduchost sama Je to zhruba na stejné úrovni, jako z Cčkového programu zavolat kompilátor a výsledný program spustit – to pak C má taky include

[Kyosuke]

Takhle to řeší GCL - compile s následným loadem načtou lispový soubor, zkompilují do Cčka, zapíšou do souboru, zavolají GCC a nad výsledkem zavolají dlopen(). Což má samozřejmě omezení, ale funguje to. A jestli se nepletu, tak to takhle nějak funguje i v perlovském Inline::C a rubáckém RubyInline.