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)))

XCHAOS: strašně napadáš můj pokus umožnit jako jednu ze základních feature (místo všeho shánění se po sofistikovaných knihovnách) multitheading. - ano. Protoze tvuj pristup "problem se slozitym multithreadingem vyresim tak, ze jedinej podporovanej pattern bude iterace pres kolekci" a i v tom je videt, ze _vubec_ nechapes, jak slozity multithreadingovy programovani je. Tvoje predstava "no proste nejak automaticky spustim hodne threadu" je neuveritelne naivni. Znovu: nastuduj si neco. Podivej se, jaky ruzny pristupy k paralelnimu programovani existujou: Promisy jako v JS? Superlehky thready komunikujici skrz kanaly jako v Go? Izolovany miniservery jako v Erlangu/Elixiru? Uz davno se ukazalo, ze "proste spustim thread" je model, kterej moc nefunguje, protoze je slozitej na pouziti, nachylnej k chybam a celkove krehkej. Takze to, jak si ten "multithreading" predstavujes, proste jen ukazuje, ze fakt nevis o cem mluvis.

cílové platformy, které jsem vyjmenoval (např. webové PHP, nodejs), tak jejichi interpretery skutečný multithreading nepodporují - HAHAHAHA. Me se fakt libi, jak skoro kazdou vetou dokazujes, ze o tom vubec, vubec nic nevis. Zrovna ten node.js je krasnej priklad: jedna z hlavnich motivaci byla prave vyzkouset uplne jinej pristup k paralelnimu zpracovani velkyho mnozstvi requestu. Jo, jasne, programator v nem ty thready primo nevidi. Ale to proto, ze jeho model je tak schvalne postavenej a ten runtime _samozrejme_ dalsi jadra CPU vyuzije, aniz by se o to programator musel nejak explicitne starat.

XCHAOS: pokud importuju externí knihovnu podporovanou jen v jedné z cílových platforem (typicky C), tak po připojení téhle knihovny můžou ostatní cílové platformy jen zařvat, že to nepodporují - HAHAHAHAHAHAHA. Jo, jasne. "Tady mam uzasnej skvelej xJazyk, kterej vam umozni napsat kod jednou a pak mym genialnim prekladacem prelozit na x ruznejch platforem. Teda, uhm, pokud nahodou nepouzijete knihovnu, kterou na ty platforme nepodporuju" 8)))))

napsat interfacy k existujícím populárním nástrojům by nemuselo být _tak_ složité - 8))) Jo, to je skvela argumentace. "Nemuselo by to byt _tak_ slozite". To je skoro datk dobry, jako tvoje legendarni "sazim na to, ze" nebo "tvrdim, ze".

btw, uz sis nastudoval, jak to je s tema garbage collectorama a proc je tvoje predstava "proste tam vrazim pocitani referenci" ponekud... naivni?

No a konecne: cela ta tvoje predstava "performance problem weboveho serveru vyresim tim, ze ho prelozim do C" jen krasne ukazuje, ze vubec netusis, kde jsou skutecne obtizny bottlenecky webovejch serveru. Coz asi nikoho neprekvapuje, ale je to peknej, dost vypovidajici detail...

XCHAOS: mi spíš vysvětli, proč něco takového neudělali všichni, kteří se v posledních letech pokusili o nějaký vlastní interpreter - protoze nikdo, kdo psal vlastni jazyk, nemel takhle idiotskou, zamotanou a nesmyslnou motivaci.

XCHAOS: lidí, kteří nejsou na web schopni deploynout binárku, nebo si jí tam přeložit, ale mohou někam hodit jen PHP kód, není zrovna málo. - "neni zrovna malo"? V dobe, kdy bud uplne zadarmo nebo za par drobnejch muzes nahodit instanci v AWS/Heroku/Google Cloud/ whatever a poustet si na ni co chces? No jasne 8))))

přesto bych tedy radši vyvíjel v něčem, z čeho mám C mezikód do budoucna - Takze ty rikas, ze exituje "ne zrovna malo" lidi, kteri:

- programujou v PHP
- nejsou schopnit si spustit vlastni server
- ale nekdy v budoucnu mozna z nejakyho duvodu budou potrebovat kompilovat do C (proc, proboha?)
- a aby tohle splnili, tak zapomenou to PHP, zahodi vsechny jeho knihovny, nastroje a kod, kterej uz v nem napsali a nauci se xJazyk, ke kterymu neexistujou knihovny, nastroje, je zabugovanej a navic neexistuje. Jen proto, aby mozna nekdy mohli "kompilovat do C".

Prosim, muzes nejak dolozit, ze takovych lidi existuje nejake nezanedbatelne mnozstvi? A ne "sazim na to, ze ano" nebo "ptal jsem se jednoho kamarada, a ten rekl, ze jo" 8)))

XCHAOS: dost tu argumentaci překrucuješ. Hele, top jsou skoro doslovny citace toho, cos ty sam psal. Chces, abych ti nasel presny zpravy a doslova to z nich opsal, nebo mi honem das banana, abych nemohl? 8))

REDGUY: ehm, dost tu argumentaci překrucuješ.

mám konkrétní příklad, proč někdo může být demotivován programovat čistě v C - lidí, kteří nejsou na web schopni deploynout binárku, nebo si jí tam přeložit, ale mohou někam hodit jen PHP kód, není zrovna málo. přesto bych tedy radši vyvíjel v něčem, z čeho mám C mezikód do budoucna

gerování C kódu je vzhledem k teoretické množství skutečně cílových platform neutrální, protože pro všechny další zamýšlené generované mezikódy pro další target platformy existují interpretery napsané v C, které se dají přeložit všude. motice pro paralelní generování do víc platforem je právě spíš možnost deploynout aplikaci někam, kde tě binárku buď pustit nenechají, nebo tě tam nenechají nakonfigurovat výkonostně efektivní uspořádání typu fastcgi.

(tady se BTW rovnou nabízí generování i pro více dílčích variant platformy - čisté C, s možnosti použití stdout jako CGI, fastcgi, nebo i verze s http serverem zabudovaným jako součást runtime, jak to evidentně umí udělat třeba node.js. a když se nad tím zamyslíš, tak slinkování aplikace přímo s miniwebserverem bude mít zřejmě ještě menší režii, než sebesofistikovaněší API na webserver... a nic z toho já jako vývojář překladače nemusím řešit hned, ale můžu tyhle dodatečné dílčí "variace cílových platforem" dodat až časem... klíč k tomu se mi otevře ve chvíli, kdy budu mít ten C mezikód, a s tím, kam přesně přesměruju jeho I/O si můžu hrát až dodatečně...)

místo teoretizování proč je to blbý nápad mi spíš vysvětli, proč něco takového neudělali všichni, kteří se v posledních letech pokusili o nějaký vlastní interpreter...

strašně napadáš můj pokus umožnit jako jednu ze základních feature (místo všeho shánění se po sofistikovaných knihovnách) multitheading. ale když si projdeš cílové platformy, které jsem vyjmenoval (např. webové PHP, nodejs), tak jejichi interpretery skutečný multithreading nepodporují. paralelní překlad do C zde tedy může přinést výrazný nárůst výkonu, protože i když syntaxe threadů v ostatních jazycích může C připomínat, a vytvořit pro programátora iluzi, že něco se děje paralelně, tak pouze thready v C jsou skutečné thready, které se skutečně pokusí využít další jádra CPU (kdyby to totiž bylo tak jednoduché, tak by se asi v Googlu nepouště do psaní Go, že ano)

zkráta, v hledání důvodů proč něco udělat jsi fakt dobrý - ale pokud je zadáním "umožním každému blbnout s programováním tak, aby mohl hned od začátku svoje výsledky deploynout do prostředí, na které je zvyklý, a přitom v budoucnu v případě potřeby navýšení výkonu nemusel nic přepisovat", tak prostě nemáš nic, co by se dalo nabídnout.

navíc spoustě tvých výhrad lze při troše snahy oponovat: tak např. pokud importuju externí knihovnu podporovanou jen v jedné z cílových platforem (typicky C), tak po připojení téhle knihovny můžou ostatní cílové platformy jen zařvat, že to nepodporují (ale tím se neomezí možnosti core jazyka). nebo binding ke knihovnám může být implementovaný pro všechny 4 cílové platformy, protože většinou stejně jde jen o wrappery kolem té jediné knihovny, implementované v C. Příklad: pokud jde o knihovny typu ImageMagick, bude API u všech cílových platforem podobné. napsat interfacy k existujícím populárním nástrojům by nemuselo být _tak_ složité - nejsložitější mezikód se nakonec vždy bude generovat jen pro to C, pro ostatní platformy bude překlad triviální.

ovšem proč se snažit argumentovat, když ty máš svojí zjevenou pravdu a předem víš, co všechno určitě nepotřebuješ a určitě to nepotřebuje ani nikdo jiný...

XCHAOS: Ty si napsal asi 10 příspěvků podrobně rozebírajících, jak je to celé nesmysl - nesmyslny jsou tvoje zduvodneni o tom, jak se lidi budou ucit programovat ctenim tveho generovaneho kodu, jak je potreba vyresit "problem" s konfiguraci tim, ze "platoforma" automaticky vsechno "zkonfiguruje" sama, jak programovat v C znamena "platoform lock-in" a tak dale a tak dale. Tohle jso konkretni nesmysly a pitomosti. "Chci si hrat" je jedinej rozumnej duvod a nikdy jsem ho nepopiral. Nelzi o tom.

XCHAOS: hele, je to už 10 let. No jasne. Takze to je fakt relevantni informace 8)))

když byl napsaný v Djangu, zatímco po přepsání do nativního Pythonu - aha, ty jen nevis, co znamena slovo "nativni". Ok 8)))

REDGUY: ehm, kdyby si napsal jen "hraj si a předveď výsledek", tak bych vůbec nic nerozporoval. Ty si napsal asi 10 příspěvků podrobně rozebírajících, jak je to celé nesmysl... a když ti došly argumenty, tak se zase zoufale snažíš dosáhnout zabanování.

což asi udělám.. je fakt nelogické mít lidi, které mám na ignorelistu, ve svých klubech nezabanové...