JANFROG: posílal jsem jen odkaz na to, že v GNU C jsou na to testovací funkce, které můžeš do kódu vložit... to je celé.

jinak celá úvaha o tom, jak to C vlastně vůbec nemá cenu používat, právě vázne na tom, že zdrojové kódy snad všech dnešně používaných runtime prostředí jsou v C. (což docela překvapí, když existují kompilovatelné dialekty Pythonu... proč teda není budoucí interpretr Pythonu vyvíjen v Pythonu? :-)

když jsem u toho, v čem budu co vyvíjet.. tedy, svatým grálem každého prostředí je, aby mohlo být vyvíjeno samo v sobě, když tomu zdejší troll říká "xjazyk", tak řekněme, představa je, že by nějaký primární "bootstrap" podmnožiny mého jazyka byl napsán buď v nějakém tom "C s makry", nebo v Pythonu, a potom by se už příští generace compileru (s větším množstvím features) psala přímo v něm samém :-) (s tím, že výhodou by bylo, že by sám ze sebe uměl přeložit příští binárku :-)

UETOYO: Experimentalni. Nevidim, jak by to tohle resilo, z pohledu Pythonu je to porad integer. Ten problem, ze cisla se proste chovaji jinak v PHP a Pythonu to neresi...


UETOYO: A coz o to, resitelny to je. Ale ne na urovni XChaosovejch predstav "jednoradkovy templaty". A specificky tenhle problem, kdyz se podivas co pisou o integerech, tak pisou, ze to neresi. Takze ta predstava "napisu jednou a pak mi to fiunguje vsude" neplati ani tam.

REDGUY: Nemá PHP stejně jako Pyhon *type hints*? to by nějak mohlo pomoci ne?

XCHAOS: Uhmmm... ty fakt nechapes, v cem je problem? Tak schvalne, rekneme, ze mas takovejhhle xjazykovej kod:

int a = 2**62;
int b = 2*a;

Jak ho prelozis do Pythonu? a jak do PHP?

REDGUY: čímž si dokázal... co? :-)

"v mém" jazyce si řekneš při deklaraci o int, long int/double nebo o var/auto, ke změně typu proměnné tam nedojde, stejně jako v C.

V C lze přetečení hlídat
c++ - How to detect integer overflow? - Stack Overflow
https://stackoverflow.com/questions/199333/how-to-detect-integer-overflow

to aby se taková detekce prováděla automaticky (což ale nevím, jestli je krok, kterým začnu) je další důvod pro generování mezikódu místo pro programování přímo v C.

nebo z jiného konce: sám si ukázal, že vyšší jazyky musí provádět spoustu podobných kontrol (a např. změnit typ objektu), zatímco když víš, že opravdu pracuješ jen s integery a provádíš operace, které až do tepelné smrti vesmíru nejspíš nepřetečou, tak může být kód rychlejší.

je možné ti prostě odpovědět i tak, i tak - a hlavně si vůbec nevyvrátil, že převod do vyšších jazyků by měl být těžší, než do C mezikódu (což bude ta zajímavá část projektu, kde se budou dělat podstatná vývojářská rozhodnutí...)

XCHAOS: Použijí se nativní datové struktury těch jazyků. - BUAHAHAHA. Tak jsem si rikal, jak nejsnaz ukazat, ze tohle je pitomost. PHP neznam skoro vubec, Python jen zlehka, ale uz druhej pokus vysel:

PHP:

$a = 2**62;
$b = 2*$a;

echo gettype($a), " ", $a, "\n";
echo gettype($b), " ", $b;

integer 4611686018427387904
double 9.2233720368548E+18

Python3

a = 2**62
b = 2*a
print (type(a), a)
print (type(b), b)

<class 'int'> 4611686018427387904
<class 'int'> 9223372036854775808

XCHAOS: u těhle tvých argumentů je nesmysl hned bode 1. samotný jazyk se nebude podobat C, ale spíš Pythonu. ja ne;pisu o tom, cemu je tvuj jazyk podobny. Pisu o tom, v cem _ted_ programuje jeho potencialni uzivatel. A doslova jsi psal, ze miris na lidi, co ted jedou v PHP.

bod 3 nevím jestli si rozumíme. paralelismu je myšlený i pro commandline only prostředí, - aha. Akorat ze do ted jsi mluvil o nahrade PHP na webu. Pokud mluvis i o lokalnim pouziti, tak zase nedava smysl ten argument "nema server pod kontrolou" a proste muze rovnou jet v C nebo necem vykonym.

bod 4 netvrdím. - jenomze to vypliva z tvechj "zduvodneni". Pokud pri genervani stranky vetsinu casu stravim cekanim na IO, tak je uplne jedno, jestli cekam v PHP nebo v C, prekladem nic neziskam. Aby tvoje argumenty o vyhode prekladu fungovaly, tak musi byt generovani stranky narocne na CPU, coz typicky proste neni, obzvlast na tehle urovni.

bod 5 jsem netvrdil. - totez jako 4. Netvrdil, ale aby tvoje povidani o tom, jak uzasna vlastnost je ta paralelizace, melo aspon trochu smysl, tak je to nutna podminka.

jen proto, že v tom půjde psát _i_ webové stránky - celou dobu mluvis o PHP, celou dobu rikas, jak je to urcene pro lidi, kteri nemuzou nasadit vlastni kod, ale jen na nejakej hosting uploadujou svoje skripty, celou dobu, dokonce i vtehle zprave, mluvis o "slozite administraci server". Takze jo, predstava, ze je to primarne pro www stranky je zcela na miste. Samozrejme, pokud ti doslo, ze to je pitomost, muzes se pokusit rychle pivotnout nekam jinam a nejak to zamluvit 8)))

bod 8: ne, nečekám že někdo bude něco přepisovat z PHP. - strawman. Osmej bod neni jen o prepisovani, ale hlavne o vedomostech, nastrojich a komunite. A doslova jsi psal, ze miris na PHP programatory.

třeba i jen hračkového kódu. nic velkého. - pak ale zase nedava moc smysl to o tom, jak dulezite je ta moznost prekladu do C 8)))

A porad cekam na ty priklady 8)))

REDGUY: u těhle tvých argumentů je nesmysl hned bode 1. samotný jazyk se nebude podobat C, ale spíš Pythonu. uživatel může nadále generovat cílový kód v PHP, jen dostane šanci napsat přehlednější zdrojový kód...

bod 2 nechám na každém, jak snadné je pro něj administrovat vlastní virtuální server (min. ne pro všechny webmastery to je jednoduché)

bod 3 nevím jestli si rozumíme. paralelismu je myšlený i pro commandline only prostředí, bez webového rozhraní. někdy nechceš, aby nějaká práce s daty na pozadí trvala třeba celou noc a dobíhala ráno...

bod 4 netvrdím. jenom si myslím, že I/O podceňuješ, navíc schopnost kódu paralelně čekat na vyřízení např. velkého množství http requestů nebo jiných requestů směrem ven není nutně o tom, že se využijí ta jádra, ale že se využije to, že čeká víc různých threadů současně. Ano, paralelní I/O programovat lze i bez multithreadingu, ale je to voser...

bod 5 jsem netvrdil. neustále za tím vidíš nějkaý zcela jednoúčelový nástroj jen proto, že v tom půjde psát _i_ webové stránky...

bod 6 jo a ne. někdo může mít pocit, že přeložený kód se statickým typováním je bezpečnějí (mezikód vygenerovaný do PHP překvapivě asi statické typování mít nebude i když je otázka, pro jakou verzi PHP se kód vlastně bude generovat...)

bod 7: obecně, lidi co mají zájem všechno od designu draze redesignovat jsou ti, co se programováním živí :-) tady jsou motivace různé a někdo třeba nemá čas nebo peníze všechno přepisovat

bod 8: ne, nečekám že někdo bude něco přepisovat z PHP. je to spíš zacílené na původní vývoj. třeba i jen hračkového kódu. nic velkého.

XCHAOS: překlad zejména do PHP a Pythonu bude 1:1 - jsou tam k dispozici naprosto ekvivalentní nativní konstrukce. - opravdu? Jako chapu, ze na urovni naprostyho zacatecnika, kdyz se bavime o vecech jsou prikazy for a if a takovyhe veci, tak to tak muze vypadat. Ale jakmile se dostanes krapet vejs, tak uz to tak samozrejme neni. Co treba objekty? Ty v PHP a Pythonu funguji stejne? Co system modulu a knihoven? Presne stejne funguje i aritmetika? A tak dale, a tak dale. Opravdu opravdu opravdu vsechno jsou "naprosto ekvivalentni nativni konstrukce", ze proste staci misto "python-xxx" napsat "php-xxx" a proste to funguje, search/replace? Nebo tohle vyresis tak, ze proste ty jazyky orezes a budes pouzivat jen to nejzakladnejsi, co maji spolecny?



Jo a btw, ocenuju, jak potvrzujes to co jsem rikal o trapnem mlceni co se tyce vsech ostatnich otazek, co jsem polozil. Zejmena to, ze nejsi schopnej ukazat konkretni priklady tech, kdo by to uzili, je velmi vymluvny 8)))

REDGUY: pokud by ten code generátor negeneroval slušný kód, nemá ho nejspíš vůbec cenu psát...

bavíme se tu o cca 4 procedurálních jazycích. překlad zejména do PHP a Pythonu bude 1:1 - jsou tam k dispozici naprosto ekvivalentní nativní konstrukce.

jediný, co má cenu diskutovat, je překlad do C, ten přímočarý nebude. Pokud vygenerovaný C mezikód bude pomalejší než PHP, bude to téměř určitě moje chyba a ne důkaz, že "C je špatné"

Pokud bude PHP či Python pomalejší, tak ale nevím, jak chceš argumentovat, že jsem "nenapsal" optimální kód. V podstatě, iterace se tam přeloží na iteraci, podmínka na podmínku. Použijí se nativní datové struktury těch jazyků. Pokud budou pomalejší, než jejich ekvivalent, který vygeneruju v C, tak mi popravdě fakt zajímá, jak chceš dokazovat, že "zkušený programátor v těch jazycích by to naprogramoval jinak"...

XCHAOS: třeba proto, že psát ty benchmarky ručně se mi nechce? zvlášť, pokud půjde o nějaký složitější algoritmus? - BUAHAHAHAHAHAHAHAHAHAHAHA. No jasne 8)))) To uz je tak sileny, ze ani nebudu komentovat 8))) Teda, jedina vec by me zajimala: fakt si myslis, ze tvuj "code generator" bude generovat optimalni kod (na urovni slusnyho programatora v danym jazyce) jak pro C, tak pro PHP, aby ten "benchmark" mel nejakou vypovidajici hodnotu? Kdyz to bude zalozeny na "jednoradkovejch templatach"? 8)))

REDGUY: geniální postřeh... a proč myslíš, že chci psát ten code generator? (třeba proto, že psát ty benchmarky ručně se mi nechce? zvlášť, pokud půjde o nějaký složitější algoritmus?)

Mimochodem, jak na tom ted vubec PHP s vykonosti? Skoro bych cekal, ze po ctvrtstoleti vyvoje to nebude zas tak spatny, ne? Neni nahodou ten zakladni xchaosovu predpoklad "Misto do PHP prelozim do C a tim ziskam spoustu vykonu navic" dost mimo i cpu-intenzivni loady?

Tak schvalne, zkusme si pro pobaveni sepsat podminky, ktere musi uzivatel splnovat, aby pro nej byl xJazyk prinosem:

(1) Programuje v PHP a nechce prechazet na vykonejsi jazyk jinej nez C (proc? Moznosti je spousta).
(2) Nema pod kontrolou server, na kterem to provozuje, muze jen uploadovat hromadku PHP skriptu (proc? V dobe, kdy cloudovy provideri nabizeji Linuxovy instance skoro zadarmo, ne-li uplne zadarmo).
(3) Na jeho server soucasne pristupuji maximalne nizke jednotky lidi, takze na efektivni vyuziti vsech jader serveru nestaci paralelismus na urovni HTTP requestu ale je potreba paralelizovat i zpracovani v ramci jednoho requestu.
(4) Generovani typicke stranky je narocne na CPU a ne na IO, takze ma smysl to prekladat do C.
(5) Algoritmus generovani stranky dava dostatek prilezitosti k "paralelnimu zpracovani prvku kontejneru", protoze to je v xJazyce jedinej doporucenej "pattern" paralelismu.
(6) Vyhledove pocita s tim, ze bude kvuli rostoucim pozadavkum na vykon prekladat do C, coz teda ale znamena, ze prestane platit (2)
(7) Az bude mit ty vyssi pozadavky na vykon tak neni ochotnej tu aplikaci redesignovat aby byla efektivnejsi a skalovatelnejsi, proste chce porad honit par skriptu v kontextu www serveru.
(8) Nevadi mu zahodit vsechny znalosti, komunitu, nastroje a knihovny v PHP a prepsat to do xJazyka (krapet rozpor s (1) a (7), ze ano )

Zapomel jsem na neco? Ja nevim, ale skoro bych rekl, ze jedinej clovek, kterej tohle vsechno splnoval, umrel na mor v roce 1349 8)))

A bonusova otazka: xchaosi, proc myslis, ze nikdo neprogramuje aplikaceni webovy servery v C? Proc vsichni pouzivaji vyssi jazyky, casto co se ciste CPU vykonu mnohonasobne pomalejsi nez C? Jo, aha, ja zapomel, ty uz jsi svuj pridel premejsleni vycerpal 8)))

XCHAOS: jako ale tvoje hlavní argumentace "není to vůbec potřeba" je fakt slepá ulička. na počítačích se vždycky dělalo, dodnes dělá a ještě bude dělat spousta věcí, které "nejsou potřeba" - A to je zase ta pokrivenost tvoji arugmentace. Ty sam tady stojis a vykrikujes, ze to _JE_ potreba. Ze existuje nejaka zahadna, velmi specificka skupina lidi, kterym by se to hodilo, kteri by to potrebovali. A ja ti ukazuju, ze to je pitomost. Ze i kdyby takovi lide existovali, tak benefit, kterej by tvuj xJazyk prinesl v takove podobe, kterou popisujes, by byl naprosto zanedbatelnej a zcela zjevne by se jim vubec nevyplatilo prechazet z pro ne osvedceneho PHP.

Moje argumentace proc to neni potreba je odpoved na tvoje povidani o tom, jak strasne potreba to je. Takze pokud ted najednou vykrikujes o tom, ze to je slepa ulicka a ze to potreba vlastne neni... no, to vypovida o tvych argumentech, ne o mych 8)))

vyjít s předpokladu, že všechny dosavadní nápady byly chytré, zatímco všechny budoucí nápady jsou předem podezřelé - ja jsem si rikal, ze uz dlouho jsi nepredvedl nejakyho svyho klasickyho strawmana. A hele, uz je tady 8)))

XCHAOS: tak určitě existuje i jiná odpověď, než mlčení nebo fantasmagorie - to urcite existuje. Ale musel bych se bavit s nekym, kdo vi, o cem mluvi. V tvem pripade jsou jen tyhle dve moznosti a ty sis zjevne vybral fantasmagorii. Tedy, pro tuhle otazku. Pro vsechny ostatni otazky a problemy, o kterych jsem psal, sis vybral trapne mlceni 8))

webové aplikace si spustí víc procesů tak jako tak, takže víc jader využijí. - pokud se bavime o nahrade PHP, tak mas nejakej Apache, kterej se stara o paralelismus na urovni jednotlivejch http requestu a pro kazdej request pak pousti, patrne pres mod_php, vlastni skript, kterej vygeneruje stranku. Cili paralelismus mezi jednotlivejma requestama mas vyresenej apachem a nemusis se o nej starat nejakym vlastnim jazykem. A k cemu je to tvoje "paralelni zpracovani kontejneru" pri zpracovani jedne stranky? K nicemu. Typickej webovej server je IO-bound, zejmena server, napsanej a provozovanej clovekem, kterej "pise v PHP a nema moznost nasadit si to na vlastni server". To je proste nejakej diskuzak, stranky nejakyho obchodu, tak neco. A ten server typicky proste vetsinu casu ceka na fileystem nebo databazi a tim, ze "spustim thready na kolekci" nic podstatnyho neziskam. Nastuduj si Amdahluv zakon 8)))

občas se zpracovávají skutečně velká data.. LOOOL. V PHP? No jasne. Akorat ze kdyz zpracovavas opravdu velky data, tak je fakt nezpracovavas v kontextu toho serveru, ale mas nekde nejakej worker proces, idealne na dedikovany masine a ten web server pak jenom sahne pro vysledek a posle ho klientovi. Takze zase, ten server je io-bound, ne cpu-bound. A jestli mi budes vysvetlovat, jak strasne se pletu, tak v kontextu toho, co me poslednich par let zivi to bude s prehledem nejsmesnejsi vec, cos v nasi debate kdy udelal 8))))

využít všechna jádra pak znamená, že to doběhne dřív - zase, idiot nechape, ze nema smysl optimalizovat veci, ktere se nevyplati. Podivej se na tuhle nyxovou stranku. Hadam, ze kdyz nejede z cache, tak minimalne 90% casu se pri jejim generovani stravi cekanim na IO, spis jeste vic. A z tech par zbejvajicich procent, na co by se tak dalo pouzit to tvoje "paralelni zpracovani kontejneru"? Mozna na formatovani jednotlivejch postu? Ale stejne to pak musis slozit dohromady, plus rezie distrubuce prace mezi thready... takze ve vysledku, i kdyby to nahodou fungovalo, usetris sotva par procent. A vlastne ani to ne, protoze na ten server ti pristupuje vic lidi a jader mas jen par, takze je vlastne uplne jedno, jestli je vytizis paralelnim zpracovanim postu pro jednoho cloveka, nebo paralalenim zpracovani requestu pro vic lidi. Ne, vlastne to neni jedno, tvuj pristup je pitomejsi, protoze paralelizace requestu uz je davno vyresena v apachi a nemusim se o ni starat, zatimco paralelizace zpracovani jednoho requestu je slozita, dost error-prone prace navic. Takze fail 8)))

Hele, tak mi nejaky konkretni priklady serveru, ktere by vyuzily to co hlasas. To znamena musi bejt napsanej v PHP, jeho provozovatel nema pod kontrolou server a deploynout muze ciste jen par skriptu, je to CPU-bound, takze preklad do C pomuze a navic je to takovej problem, kde se dobre uplatni "paralelni zpracovani prvku kontejneru" jako jedinej podporovanej druh paralelismu. Jo, a je to server, na kterej pristupuje jen par lidi a je tak zatizenej, ze casem budou chtit prekladat do C a zaroven nebou chtit prejit na pricetnou archikteturu s worker nodama... 8))) Prosim, napis par takovej prikladu. Psal jsi, ze takovejch lidi je "ne zrovna malo", tak prijit s konkretnima prikladama by nemel bejt problem, ne?

REDGUY: tak určitě existuje i jiná odpověď, než mlčení nebo fantasmagorie...

webové aplikace si spustí víc procesů tak jako tak, takže víc jader využijí. ale to, že aplikacím dnes dáváš webové rozhraní, to neznamená nutně, že pokaždé cílí na davy. občas se zpracovávají skutečně velká data... a využít všechna jádra pak znamená, že to doběhne dřív.

jako ale tvoje hlavní argumentace "není to vůbec potřeba" je fakt slepá ulička. na počítačích se vždycky dělalo, dodnes dělá a ještě bude dělat spousta věcí, které "nejsou potřeba". vyjít s předpokladu, že všechny dosavadní nápady byly chytré, zatímco všechny budoucí nápady jsou předem podezřelé a potenciálně blbé... no nevím, teda...

A samozrejme, extra vtipna otazka je, "proc by proboha paralelni zpracovani kontejneru" melo prinest nejak zasadni zrychleni pro typickou webovou aplikaci treba typu Nyx. To by me zajimalo, jestli odpovedi bude trapne mlceni, nebo nejaka fantasmagorie 8)))