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é...

REDGUY: hele, je to už 10 let. Ale stejný web (dost primitivní,co si budeme povídat - měl vybrat v podstatě nejnovější položky z jediné tabulky) tehdy zvládal asi 3 requesty za sekundu, když byl napsaný v Djangu, zatímco po přepsání do nativního Pythonu jich zvládal asi 30 :-)

Připouštím, že tehdy možná někdo jen použil to Django špatně (moje práce to tehdy nebyla...). V Pythonu ale pořád občas programuju.. zrovna teď nějakou kombinatoristiku pro plánování naší bezdrátové sítě. V Pythonu se mi výborně pracuje s datovými strukurami - i když zrovna tenhle konkrétní algoritmus bych asi v C napsat dokázal, tak samozřejmě, když píšu něco jednorázově a jen pro sebe, tak dnes automaticky sáhnu po Pythonu.

XCHAOS: výkonnost Djanga mi, dejme tomu, neohromila (srovnáváno s nativní Python webovou aplikací) - Django neni "nativni Python webova aplikace"? A jakpak jsi to meril a srovnaval? Muzes to prosim nejak rozvest, jen tak, at se pobavime?

AXTHEB: takhle... přímo programovat jsem se v tom neučil, ale výkonnost Djanga mi, dejme tomu, neohromila (srovnáváno s nativní Python webovou aplikací)

nápad, že bych můj code generátor měl i ORM vlastnosti je popravdě jenom nápad. Ale bude staticky typovaný, tedy bude mít např. ekvivalent datové struktury struct, jako Céčko - v té na rozdíl od Python slovníku (dict) nebude moci být libovolný náhodný bordel...

jinak samozřejmě si cením konstruktivní kritiky, ale ta zdejší debata, kdy já víceméně nastíním, že si s něčím chci a dostanu tuny odpovědí "ne, s tímhle si opovoaž hrát".. no nevím.

AXTHEB: A samozřejmě, že to jde i obráceně, máš tabulku/pohled v databázi tu si necháš popsat Python kódem. Ale uděláš to jednou, a pokud ti někdo změní databázi tak na to přijdeš hned a tedy snadno zjistíš, komu máš jít naplivat do klávesnice.

XCHAOS: co takhle představa, že by mezikód pro jakýkoliv výsledek složitější SQL operace dokázal vybudovat lokální silně typovanou strukturu? - No a? V cem je vyhoda? Proc je kvuli tomu potreba psat vlastni jazyk? Co to vlastne znamena a jak by to vlastne fungovalo? Vi sam XChaos, o cem mluvi, nebo zase jen mota dohromady nejaky odporny termity a citi se pritom hrozne cool? Otazky, otazky, otazky 8)))

XCHAOS: jde zdůvodnit třeba i jen tím, že si prostě chci hrát (a opravdu by mi zajímalo, co najdeš špatném na tomhle nic, na tom pochopitelne nic spatneho neni. Akorat ze tvoje prefoukly ego ti nedovoli v ten moment prestat a skutecne si zacit hrat, ale musis pak mit plnou hubu kecu o tom, jak vyresis neexistujici nebo marginalni problemy, jak se lidi budou ucit programovat ctenim tveho generovaneho kodu, jak implementujes genialni "design patterny" tak skvele, ze se sebehnou lidi a zacnou na tebe pracovat a tak dale a tak dale. Jo, hraj si a pak predved vysledek. Temahle nafoukanejma recickama se ztrapnujes hned dvakrat: jednou ted, podruhy az je srovname s vysledkem 8))

XCHAOS: tímhle si zase dokazuješ co? - protoze ses ani po vsech tech letech nenaucil citovat to, na co reagujes, tak fakt netusim na co ptas.

REDGUY: ad browserový javascript: jediný jazyk, který je dnes reálně nativně instalovaný kdekoliv, je jazyk, ve kterém ani nejde ukládat do lokálního filesystému (a to je prostě fakt...). k zdůvodnění vývoje nové platformy to nestačí, to je fakt.

moje meta-platforma, co bude od začátku cílit na více cílových platforem, jde zdůvodnit třeba i jen tím, že si prostě chci hrát (a opravdu by mi zajímalo, co najdeš špatném na tomhle :-)

(jinak co takhle představa, že by mezikód pro jakýkoliv výsledek složitější SQL operace dokázal vybudovat lokální silně typovanou strukturu? připouštím, že nevím, jestli chci zacházet tak daleko... ale v zásadě, pokud bych opravdu chtěl programovat tak, že nebudu přemýšlet, ve které z 5 různých syntaxí se zrovna nacházím, tak bych se touhle cestou vydal...)

REDGUY: tímhle si zase dokazuješ co? (BTW, to už je intuitivnější generický mysql connect než tohle :-))

XCHAOS: když se z Pythonu připojuješ do databáze, jsi nucený importovat nějaký modul a přijmout design-pattern jakékoliv jiné databázové aplikace - proboha, a tohle ti prijde jako problem?

import psycopg2
db = psycopg2.connect("dbname=xchaos user=je password=idiot")

Tohle je pro tebe zasadni programatorskej problem, kterej vyzaduje reseni napsanim novyho jazyka? Podivej se, to ze to je problem pro _tebe_, neznamena, ze to nejak vadi lidem, co maj IQ vyssi nez prumerna denni teplota 8))

ještě intuitivnější by třeba bylo, kdyby se řádkem v databázi dalo pracovat úplně stejně, jako s nativní datovou strukturou (objektem, C strukturou). - ne, nebylo. Databaze je databaze, pole je pole. Kdyz se budu k databazi chovat uplne stejne jako k poli, tak to v lepsim pripade bude zoufale neefektivni, v horsim rozbity.

Pochopitelne, pokud jedina operace, kterou zvladas, je "sekvencne projizdim pres vsechny radky tabulky a vypisuju je" tak ti muze pripadat, ze neni rozdil mezi sql a nativnim polem. Akorat ze to je samozrejme velmi naivni predstava. Zacne se rozpadat uz v okamziku aktualizaci a je komplet mimo u slozitejsich operaci. Cela pointa sql databazi je, ze spoustu prace muze delat server za tebe a vyrazne efektivnejc. A v tu chvili se tvoje predstava "tabulka je pole" uplne katastrofalne mimo.

Jo, jasne, existujou nejaky ORM systemy, ale ani u nich se k databazi nechovas stejne, jako k nativnim objektum.

i když jsou prostředí, která je fakt složitá inicializovat A proc si myslis, ze to tak je? Protoze autori jsou hajzlove, kteri schvalne skodi uzivatelum? Samozrejme ze ne. Protoze ti to dava flexibilitu. Rekneme ze xJazyk se nejak automaticky pripojit k databazi, takze usetris ty straslivy dva radky kodu. A co kdyz potrebujes jinou databazi, nez tam xchaos naprogramoval? A co kdyz potrebujes dve databaze soucasne? Co kdyz se k databazi chces pripojit az nekdy uprostred behu programu? Co kdyz se k ni potrebujes pripojit s nejakejma nestandardnima parametrama? Bravo, usetril jsi dva radku... ale rozbil sis zbytek.

je tu pořád šance, že nějaký konkrétní design-pattern podchytím tak chytře - BUAHAHAHAHAHAHAHAHA. No tak jo. "Planuju neco udelat a doufam, ze neco, nevim co, udelam tak chytre, nevim jak, ze mi ostatni padnou k noham a zacnou resit veci za me." 8)))

Nne, fakt nepletu - no, mluvil jsi u ukladani do lokalniho systemu v kontextu browseroveho javascriptu. Coz je dost fail. Ale urcite se z toho vykecas, ja vim 8))


jakou máš vlastně ty message - ze jsi nafoukanej, neschopnej trouba, kterej placa nahodny nesmysly, mota buzzwordy kterejm nerozumi, casto odporuje sam sobe, neni schopnej drzet konzistentni argumenty a hrozne rad machruje o tom, jaky uzasny veci z nej vypadnou, akorat ze nakonec zustane jen u toho machrovani. Ja myslel, ze to uz jsi za ty roky pochopil, nebo ne?

Hele, existuje pro tebe privialni reseni: prestan mlzit a blabolit o tom, jak uzasna vec to bude a napis konkretni specifikaci, nebo jeste lepe, naprogramuj to. Uz ti to rikam ponekolikaty a porad nic. Skoro jako bych mel pravdu 8)

REDGUY: ano, Python je fajn. ale už když se z Pythonu připojuješ do databáze, jsi nucený importovat nějaký modul a přijmout design-pattern jakékoliv jiné databázové aplikace... není to složité odněkud opsat, ale je to určitý příklad. Python i PHP pracují s daty přinesenými s SQL jako s asociativními poli, to vypadá pěkně a intuitivně - proti všemu, co bylo k dispozici v minulosti - ale ještě intuitivnější by třeba bylo, kdyby se řádkem v databázi dalo pracovat úplně stejně, jako s nativní datovou strukturou (objektem, C strukturou).

Pak by si třeba SQL tabulku deklaroval stejně, jako deklaruješ datovou strukturu/objekt. A tabulka by byla jen požadavek na to, aby byla sestavená ze struktur tohoto typu - stejně, jako když chceš v programu udělat pole ze struktur daného typu.

Musíš uznat, že by minimálně z typického webového kódu zpracovávajícího výsledky SQL dotazu ubylo velké množství úvozovek :-) A jakmile jednou pracuju s codegeneratorem, může stejně tak přímo do definice jazyka zahrnout šablonovací systém pro serializace jakéhokoliv druhu (opět velké LOL nad vývojem PHP, které v podstatě bylo původně _jenom_ šablonovacím systémem, ale postupně začalo být využívané k tak komplexním věcem, že se začaly používat šablonovací systémy externí...)

Nejde tedy jen o inicializaci, i když jsou prostředí, která je fakt složitá inicializovat (nevím jestli si někdy psal třeba nějakou aplikaci s rozhraním Gtk). Jakmile se rozhodnu pro code generátor, můžu generovat i zdrojové kódy pro SQL tabulky (resp. ALTER TABLE kódy pro prostředí, kde už tabulky existují). Je to totiž přesně operace, kterou jako vývojář aplikace spolupracující s databází budeš dělat nejčastěji.

Samozřejmě existují, že frameworky, které tohle nabízí - ale nevím o tom, že by nějaký existoval pro C. Stejně tak ty frameworky přichází většinou z nějakou vlastní syntaxí, odlišnou od samotného jazyka, ve kterém píšeš zbytek kódu, i od SQL... viděl jsem to nedávno pro PHP, a prostě zápis tabulky tam není ani SQL, ani v PHP syntaxi deklarace objektu - ale je to vlastně nový další dialekt, který se chceš naučit (tedy: codeři stále rostoucím počtem dialektů sdělují, že neumí doopravdy programovat, neumí ani přijít s žádným inovativním algoritmem - ale pořád dělají něco, co min. trvá dlouho a jejich šéf to neumí nebo je líný dělat sám :-)

takže i když nepřibalím takovou sbírku samozřejmých knihovních funkcí, kterými se chlubí rozvinutější platformy a frameworky, tak je tu pořád šance, že nějaký konkrétní design-pattern podchytím tak chytře, že mi dobrovolníci pak ty "bells & whistles" přibastlí sami a rádi. (vezmi si jen, že code generator může třeba jako součást šablonovacího systému generovat třeba i browser-side javascript, který bude kontrolovat validitu vyplněného formuláře přesně v souladu s tím, jak máš na jednom jediném místě deklarovanou proměnnou... do toho jde zabudovat s výhodou enumerační typy, které jsou v SQL i v céčku, ale třeba i zapomenuté konstrukce z Pascalu - třeba proměnné nabývajících hodnot pouze z daného intervalu, apod...

komentáře typu jak si nodejs pletu s browserovým javascriptem bych nejradši dělal, že nevidím. Nne, fakt nepletu - ojednoduchén bastlení je možné mluvit jen u toho browserového). že je důvodem ta bezpečnost, to samozřejmě vím... ale současně je javascript asi jediná platforma, která je dnes díky implementaci v browserech všude k dispozici k okamžitému hraní si.

Otázkou je, jakou máš vlastně ty message, kromě snah o polemiku s každým ASCII nebo UTF-8 znakem, který postnu kamkoliv na nyx...

XCHAOS: každý, kdo demonstroval schopnost implementovat objektový polymorfismus v čistém C (například já :-), by za předpokladu, že by na to měl dost času, mohl implementovat compiler Pythonu do do C - no tak s chuti do toho! Tu tvoji "schoponost implementovat" jsem videl na vlastni oci, takze se nemuzu dockat 8))))

Moje ambice jsou daleko nižší. - aha. Takze ne. Hmmmm, proc asi 8)))

určitým specifikem "Basiců" bylo, že nabízely prostředí, ve kterém si mohl začít rovnou pracovat a nemusel si nic incializovat. - ale pitomost. V Pythonu to mas presne stejne, taky nemusis nic "inicializovat". A pripojeni do databaze jsi v Basicu nemusel inicializovat jen proto, ze tam zadny nebylo 8)))

v javascriptu v browseru je sice možné začít bastlit slušně from scratch, ale vyrostla díky tomu celá jedna generace progrmátorů, pro kterou je jednodušší uložit data někam na server, než do souborového systému svého vlastního PC - a co je tohle za blabol? Ze ty si tak trochu pletes node.js s browserovym javascriptem? A ze nemas moc predstavu o bezpecnosti js na browseru? Jen tak hadam 8)))

REDGUY: já jsem ti ale neříkal, že v dílčích bodech nemáš pravdu. já se bránil proti osobnostním útokům (což je taky to, za co máš ban v jiných mých klubech...)

Ono "mít pravdu" není zas takový kumšt, jako si myslíš.

Překladače z Pythonu do už C existují - většinou ale vyžadují rozšířit zdroják o statické typování. Některé se používají pro generování rychlejších implementací funkčnosti modulů, které pak můžeš importovat a používat v pythoních skriptech.

V podstatě každý, kdo demonstroval schopnost implementovat objektový polymorfismus v čistém C (například já :-), by za předpokladu, že by na to měl dost času, mohl implementovat compiler Pythonu do do C mezikódu (ale ovšem i do C++ mezikódu nebo každého dalšího jazyka, nabízejícího podobný framework.. objektově programovat lze nakonec i v ASM, že ano..) Já to dělat nehodlám, ale třeba se o to nějaká "komunita" časem pokusí... kdo ví.

Moje ambice jsou daleko nižší. Podoba s Pyhonem u mě bude vycházet spíš z toho, že zápis datových struktur v Pythonu je vlastně identický s formátem JSONu. Ale jinak daleko radši mluvím o podobnosti s Basicem :-) ostatně, z větvení pomocí "goto" akademikům vstávaly vlasy hrůzou na hlavě ze stejného důvodu, z podobného důvodu, z jakého je dodnes těžké používat thready - třeba přístup ke všem proměnným programu a možnost nečekaně pozměnit hodnoty, se kterými se pracuje na jiné místě (jen ta hrozba byla sekvenční a ne paralelizovaná :-)

zase mi špatně chápeš - určitým specifikem "Basiců" bylo, že nabízely prostředí, ve kterém si mohl začít rovnou pracovat a nemusel si nic incializovat. Dovedeno do důsledků, mohl si začít kreslit po obrovce a dokonce jí ani nemusel vymazat! Samozřejmě to byla znouzecnost - ale byl to pravý opak složitostí, kterým čelí uživatelé jakéhokoliv prostředí kdykoliv od té doby. (námatkou - v javascriptu v browseru je sice možné začít bastlit slušně from scratch, ale vyrostla díky tomu celá jedna generace progrmátorů, pro kterou je jednodušší uložit data někam na server, než do souborového systému svého vlastního PC :-)