KEJML: v podstatě viz předchozí: ano, vždycky jsem měl chuť zkusit vyvinout něco jako vlastní platformu... a aby taková platforma byla "nezávislá na platformě" je vlastně jediný zbývající trik, který mi přijde zajímavý (a opět bych se odvolal na to, že takové rozhodnutí vlastně stálo u kořenů celého GNU hnutí, které původně mělo vlastní compiler a libc, ale žádný kernel... a právě nezávislost na platformě umožnila masovou adopci až do dnešních dnů...)

XCHAOS: Říkáš, že nechceš vyvíjet separátní platformu, ale nový jazyk je z pohledu programátora přesně takovou platformou je, i když se přeloží do existujícího jazyka. Když je někdo líný přejít že starýho PHP na nový, co ho donutí přejít na Xlang, tedy učit se nový jazyk?

KEJML:
REDGUY: já se to pokusím říct stručně: sere mi, že lidi kolem mě pořád bastlej kód v PHP, a to i když už jasně viděli, že staré verze PHP byly opuštěné a vše bylo nutné přesat. já se do toho zapojovat ani brodit se v tom nechci.

všechno ostatní je otevřený: vyvíjet vlastní marginální platformu se mi fakt nechce, takže jediná zbývající úvaha směřuje právě ke generování kódu pro víc platforem, a to včetně C zdrojáku. Tím pádem kdokoliv bych zjistil, že mu jeho bastl přeložený do PHP už výkonostně nestačí, by se prostě jen začal zajímat o to, jak zprovoznit C verzi, ale nemusel by ani hnout prstem

další věc je, že by vznikla platforma s jednotným způsobem konfigurace, takže věci typu parametry přístupu databáze nebo obecně, jakékoliv konfigurační soubory aplikace (.cfg/.ini), by se konfigurovaly stejně napříč všema cílovýma platformama i všema aplikacema vytvořenýma v tomhle prostředí, což by byla i výhoda pro administrátory (ti se dnes musí učit pro každou aplikaci co adminují novou syntaxi konfiguračních souborů, i když je to celé o tom samém). Nota bene by runtime mohl mít globální konfigurák (definující system-wide věci, v linuxu v /etc/) a lokální konfiguraci (v linuxu v /home nebo prostě v adresáři aplikace), v podstatě mechanismus velmi podobný práci s enviroment proměnnými - a to ne tak, že by programátor zavedl nějaký doporučený modul, ale prostě že by existoval jediný nativní způsob jak tohle řešit, o kterém by se dál nediskutovalo.

jde mi o to přesunout kreativitu programátorů trochu jiným směrem, tedy od nekonečného "zabydlování se" v systému a hledání, kdo všechno už něco naprogramoval za ně :-) směrem k algoritmům. paralelní překlad algoritmu pro víc platforem taky líp rozhodne, co má cenu optimalizovat a co ne.

je to pochopitelně poněkud rozmáchlá vize a na začátku asi budu mít stěží implementované víc než echo, for a if... stejně to ale nabízí zajímavé možnosti, třeba i jen jako toolkit na psaní benchmarků :-)

multiplatformní přenositelnost aplikací mi zajímala vždycky a koukat se na interpretované jazyky jako na platformu je prostě jedna z možností (námatkou: PHP i Python běhají i nativně na Windows, a spousta vývojářů je líná vyvíjet jinde, než na svém desktopu...)

Tak se přiznám, že o tom, jak fungují variable length arrays v C99 nemám ani tušení... natož o tom, že byly použitý v kernlu...
The Linux Kernel Is Now VLA-Free: A Win For Security, Less Overhead and Better For Clang - Slashdot
https://linux.slashdot.org/...-is-now-vla-free-a-win-for-security-less-overhead-and-better-for-clang

XCHAOS, XCHAOS: Upřímně jsem se nějak ztratil.

Pokud ti jde jen o vlastní hobby projekt, tak super, jdi do toho.

Ale ta praktičnost mi z celého tvého vyprávění uniká. V jakým případě napíšu program v Xlangu a využiju toho, že jednou ho přeložím do PHP a podruhé do C? Co mi to přinese?

Sorry, ale fakt nechapu, co chces rict. Nejdriv pises, ze chces delat jazy pro "geeky, co potrebujou binarni fastcgi". Pak ze jedndoduchej jazyk pro lidi, pro ktery je patrne i Python prilis slozitej. A ted zase nejaky buzzwordy o design patterns, kde se mi zda, ze nejlip to rekl Inigo Montoya.

Hele, muzes misto obecneho placani byt trochu konkretnejsi? Pro koho ma byt tvuj jazyk urceny? Jake specificke problemy ma resit? Jakym zpusobem je bude resit? V cem bude lepsi, nez alternativy? Jako samozrejme, kdyz to jednou sepises, tak to zkomplikuje nasledne klickovani a mlzeni, rozumim, ale jestli to myslis vazne a ne jen jako dalsi exhibici, tak by to znacne zjednodusilo komunikaci...

REDGUY: no podívej, pro začátek... já nehodlám nikoho přesvědčovat, aby programoval jinak, než mu vyhovuje...

všechny tyhle 90tkový "války o jazyky" vzešly z toho, že se předpokládalo, že v nějakém (jednom) jazyce je nutné programování učit na školách, že lidi budou placený za vývoj a udržování kódu v nějakém jazyce, který se naučí, apod.

přitom je ale jasný, že programátor je schopnější ne tím, kolik různých synonym pro print, write, echo, apod. (dosaď si libovolnou jinou direktivu) se naučí, ale kolik různých abstrakcí v kódu pochopí a dokáže smysluplně využít....

osobně... kdybych hledal, za co dostanu nejvíc zaplaceno, kdybych znovu začal programovat, tak to bude nějaký javascript, ve kterém dědičnost objektu vůbec není (aspoň nativně nebyla v tom původním - zato se v něm dnes prý už programuje bůhvíjak se statickým typováním nebo funkcionálně, apod. (přiznávám, že tohle dění nesleduju vůbec... je možné že i tu dědičnost si nějak ubastlili, kdo ví, ale používal se tam místo dědičnosti protyping)

zpět k tématu: že by for i "reverzní for" mělo umět pracovat s jakýkoliv objektem kontejnerového typu, to zpochybňovat nechci... já spíš mluvím o tom, že je spousta ustálených "design patterns", které by zasloužily

jako já fakticky už neprogramuju... ale koncepty řady dnešních jazyků se táhnou desítky let do minulost a design patterns které mezitím přišly do módy, v sobě prostě zabudovaný nemají. jako příklad bych použil to, jak se Pythonisti předhání v ujišťování, jak jednoduché je v Pythonu pracovat se singletony:
python - Is there a simple, elegant way to define singletons? - Stack Overflow
https://stackoverflow.com/questions/31875/is-there-a-simple-elegant-way-to-define-singletons

ano, samozřejmě že to je "jednoduchý" - možná jednoduší, než pokusy o "objektové ANSI C" - jenže už jen ta skutečnost, že Python nabízí od pohledu min 3 nebo 4 možnosti jak na to jít (BTW nejjednodušší je skutečně asi vyjít z toho, že v Pythonu se každý modul instancuje jen jednou, ale to zase AFAIK neumožňuje jednoduše nacpat celý kód do jediného fajlu...) vypovídá o tom, že stejně ve 3 různých projektech na to vývojáři půjdou 3 různými způsoby.

Takže pokud mám nějak shrnout můj záměr, tak je to právě to, abych se zabýval těmi "design patterns" a jednotmým způsobem, jak je vyjádřit. A do jakého více či méně nižšího jazyka ty design patterns budou přeložené, to je mi pak už v podstatě jedno, protože já třeba tu nižší abstrakci vůbec číst nechci (asi jako jsem nikdy nebyl zvyklý číst stroják vygenerovaný C compilerem...). (nicméně, existence mezikódu to pořád dělá debugovatelné, a dokonce to otevírá možnost k definici nějaký test suites, které budou otestovatelné na různých platformách, čímž se eliminuje možnost, že nějaký kód funguje "omylem" - trochu příliš naivní příkklad - např. v C člověk může někdy psát za hranice pole, aniž by to mělo okamžité důsledky, zatímco jiná platforma než C by hodila exception, ale myslím to obecně, byla by to i ochrana proti tomu, že něco omylem funguje díky příliš benevolentní implementaci nějakého API, apod.)

XCHAOS: a současně se třeba rozhodnu, že to nechci mít v paměti, ale v souboru ... a potom zase ne v souboru, ale v databázi... - eeehm. Btw, vis, ze tohle se typicky resi tema objektama a dedicnosti? Cili presne tim, co je pro tebe nezajimavy a udajne se od toho "hodne ustupuje"? 8)))

XCHAOS: Ach jo. No tak postupne.

mě se líbí, že v Pythonu můžu napsat prakticky všechno na jeden řádek... naučil jsem se to běhema cca 2 let praxe. Ale zjistil jsem, že pro nově příchozí je to podobně nesrozumitelné - dva roky na nauceni onelineru? Hmmm. Nemluve o tom, ze nadmerne pouzivani onelineru je zvrhlost, ktere je nesrozumitelna nejen pro "nove prichozi", ale pro vsechny.

podobně nesrozumitelné, jako pro mě třeba styl programování v Perlu, kdy většina kódu je jen pár obludných regexpů - pitomost, zase mluvis o necem, cemu fakt nerozumis. Vzhledem k tomu, ze Perl nemumis, tak neni divu, ze je pro tebe nesrozumitelnej a neni divu, ze meles nesmysly o tom, jak vypada Perlovej kod.

a v tom co jsem navrhoval, by programátoři museli používat v podstatě jen ty, které bych jim prefabrikoval. - a to je znovu to, na co jsem se ptal a co dusledne ignorujes: proc je podle tebe "zjednoduseni", kdyz v tvem jazyce necio nebude? V pythonu se ty custom iteratory ucit nemusim, muzu klidne pracovat bez nich a naucit se je, az kdyz je potrebuju. Proc by proboha melo bejt lepsi, kdyz tam vubec nebudou? Odpovis na tohle, nebo to budes zase ignorovat?

pro mě osobně vždycky daleko důležitější než dědění vlastností bylo procházení nějakých seznamů, jejichž velikost předem neznám - /facepalm. To neni ani srovnavani jablek s hruskama, to jsou jabka a ryby.

XCHAOS: námatkou plácnu, parametry připojování do databáze budou součást konfigurace celého prostředí a ne úkolem pro programátora (prostě jsou věci, které konfigurují admini a od těch bych programátory algoritmů asi úplně odfiltroval - stejně to, že to každá aplikace má jinak, jen přidělává práci..) - ach boze. Protoze konfigurace databaze je zasadni problem, kterej fakt neni uz davno vyresenej treba dvanacti faktorama a podobne. Jeste ze mame XChaose, kterej to vyresi! 8))

XCHAOS: Hele, takovyhle povidani je off-topic nebo on-topic? A pokud to prvni, tak porad jsou za off-topic bananmy? 8)))

JANFROG: díky že ses mi zastal... ale současně, nejde se celý život odvolávat na dva víceméně neúspěšné pokusy :-) na to, abych uvěřil, že si s tím vystačím, už příliš dlouho nepěstuju konopí :-)

solární kolo, podobně jako browser, jsem nevymyslel, a podobně jako browser bylo pouze bídnou napodobeninou (fail přiznávám, akorát si myslím, že si nezasloužím být kvůli tomu urážen, když jsem to aspoň zkusil)

fakt mě fascinuje, kde jsem mohl být, kdybych vyřešil fail, na který jsem s browserem dojel - tedy kdybych dokázal napsat interpreter javascriptu... to, jak masivně javascript ovládl za dalších cca 20 let pole, to jsme myslím v 90kách nečekali (když se poprvé objevil, tak ho všichni brali jako takové vteřinové lepidlo a nenáviděnou nouzovku.. jenže další generace programátorů z toho lepidla evidentně udělala laminát, ze kterého je dnes všechno....). a moje všechny pozdějí úvahy typu "jak to funguje vevnitř" byly motivované právě tím, že jsem tehdy zjistil, že na konstrukci interpreteru vyššího programovacího jazyka moje základní intuitivní programátorské dovednosti vůbec nestačily... (resp. myslím tím interpretr vyššího jazyka než je ten, ve kterém to programuju :-)

z mých "úspěchů" bys mohl uvést ještě založení internetového poskytovatele, kterému se (víceméně díky náhodné teriotirální shodě) podařilo vysokorychlostně připojit mj. několik milionářů až miliardářů a spoluzaložení politické strany, která právě ovládla post primátora v hlavním městě :-)) jenže všechno je to bohužel právě o tom, že svoje výtvory buď nedokážu sám dál rozvíjet, nebo nad nima okamžitě ztratím kontrolu (u Pirátů je to tím paradoxnější, než na začátku jsem byl snad jeden ze 4 zakládajících členů z Prahy a snad jediný na Praze 6 :-))

BTW, kdybys tušil, jak moc byly projekty jak browseru, kde to vzhledem k tomu jaké byl DOS bludiště nepřekvapí, tak i solárního kola závislé na dovednostech nějakých třetích stran, tak bys pochopil, proč se tak zoufale snažím ovládnout nějaké základy, na kterých všechno stojí... ať se pustím do čehokoliv, tak to dojede na podobných věcech. (což asi vysvětluje, proč se dnes snažím předpovídat, na čem se různé projekty asi zaseknou, ještě než je rozjedu...)

V tomhle směra obdivuju Elona Muska, který tak nějak "hacknul kapitalismus" a povedlo se mu něco, co se devadesátkovým lidem kolem unixového/linuxového ekosystému nikdy nepovedlo: dokázal svoje vize rozvíjet ekonomicky životaschopně.

(Počítám, že kdybych dneska rozjel třeba i úspěšný programátorský projekt, tak vzhledem k dnešním zvyklostem hodit všechno na github a tam to neomezeně forknout nad ním ztratím kontrolu rychleji, než nad čímkoliv, co jsem v životě zkusil předtím :-))

KEJML: když jsme u toho, tak jedna zbývající flow control struktura je konstrukce nějakého kontainer objektu, jehož velikost předem neznáš. a syntaxe, kterou na tohle nabízí Python, je sice elegantní, ale právě že jen v případě, pokud se vejdeš na jeden řádek (pokud mi teda něco neuniklo)

takže jedna konstrukce, která mi chybí i ve vyšších jazycích, je právě jakýsi "reverzní for" ... pro objekty umožňující serializaci (typicky soubor) je jednoduché použít nějakou obyčejnou smyčku... ale co když třeba chci, aby můj kód vypadal co nejvíc stejně pro konstrukci objektu v paměti (jehož velikost předem neznám, což třeba v C je složité), výstup do databázové tabulky i do souboru?

představ si jen, že výstup konstrukce typu [x for x in ....] chci zaprvé rozepsat na víc řádek - s tím x dělám něco složitého, ale současně jen jednou v celém kódu, takže definování funkce někde úplně jinde ve zdrojovém kódu mě může brzdit. a současně se třeba rozhodnu, že to nechci mít v paměti, ale v souboru ... a potom zase ne v souboru, ale v databázi...

vím, že PHP na tohle mělo nějaký "factory design pattern"... ale když si o tom něco začneš číst, tak je to skoro jako práce s Windows API v devadesátkách (a když se podíváš, o kolik více se od té doby zbastlilo webových aplikací, než aplikací využívajících nativní Windows API...)

takže ano... otázka, co má být překládano navíc oproti prostému if a for je dobrá otázka. určitě by byla blbost to vymýšlet tak, aby kód na 10 řádek v "metajazyce" vyšel na 10 řádek v C výstupu a 1 řádek v Pythonu ... spíš je potřeba uvažovat tak, aby 1 řádek v metajazyce zastoupl 3 řádky v pythonu, 10 řádek v PHP a 100 řádek v C :-)

REDGUY: aby bylo jasné, mě se líbí, že v Pythonu můžu napsat prakticky všechno na jeden řádek... naučil jsem se to během cca 2 let praxe před mnoha lety. Ale zjistil jsem, že pro nově příchozí je to podobně nesrozumitelné, jako pro mě třeba styl programování v Perlu, kdy většina kódu je jen pár obludných regexpů...

na druhou stranu, zatím jsem se v Pythonu nedostal k tomu, že bych vyvíjel třeba vlastní iterovatelné objekty (přitom, když se zamyslíš nad tím, že většina kódu si vystačí s if, for a rekurzí, tak právě snadná výroba nových iterovatelných objektů, které přitom nemusí být celé v paměti, je asi poslední směr v programování,který jsem nevyzkoušel.. a je fakt, že skoro v jakémkoliv "dialektu C" by výroba takových objektů byla těžká.. a v tom co jsem navrhoval, by programátoři museli používat v podstatě jen ty, které bych jim prefabrikoval.

moc nesleduju, kam se vyvíjí javascript, ale co jsem pochopil, tak se v tom dnes píše kdeco... a hodně se ustupuje od dědičnosti objektů (což je věc, která si mi nikdy nezískala). pro mě osobně vždycky daleko důležitější než dědění vlastností bylo procházení nějakých seznamů, jejichž velikost předem neznám (asi jsem poznamenaný tím, jak dlouho mi na různých školách šikanovali matematici s jejich operátory obrácené E "existuje alespoň jeden" a obrácené A "platí pro všechny", což se v programování tak trochu překládá jako if a for ... :-)

ještě k tomu mám jednu věc, kterou odpovím ale id KEJML

KEJML: ano, tak v podstatě... uvažuju o tom nějak takhle. pokud objekty, tak silně zjednodušené. ale spíš uvažuju o tom "jazyce" jako o runtime prostředí, kde třeba, námatkou plácnu, parametry připojování do databáze budou součást konfigurace celého prostředí a ne úkolem pro programátora (prostě jsou věci, které konfigurují admini a od těch bych programátory algoritmů asi úplně odfiltroval - stejně to, že to každá aplikace má jinak, jen přidělává práci..)

jinak v klubu o C je to trochu offtopic.. frajeřina by byla ale napsat "compiler" v takové podmnožině Pythonu, aby jí pak (po doplnění silného typování, které by mohlo být rozeznané např.při použití double-commentářů ##) překladač sám dokázal přeložit do C - to už ontopic bude :-)

jako je pravda, že některé dnešní tendence, typu že stejný fragment kódu na validaci nějakého vstupu může v javacriptu běžet na straně klienta i serveru tím asi nedoženu.. ale zajímá mi to teď už spíš jen jako čistě teoretický koncept... protože výkon při provozu řady vysloveně triviálních, učebnicových algoritmů, pracujících jen se stringy a paměťovými úložišťmi pak půjde srovnat v několika prostředích (a laděním "compileru" pak optimalizovat C verzi)

XCHAOS: Kdybych se ja vrhal do takovyhle veci asi bych vzal LLVM a psal backendy pro cilovy jazyky, pricemz treba Javascript uz je "hotovy". LLVM bitcode je imho srozumitelny narozdil od gcc gimple :)

JANFROG: Njn. Ja si zase myslim, ze kdyz vidim nekoho placat blbosti, tak bych mu to proste mel napsat, at uz dojel na kole do Ciny nebo ne. Kazdej mame neco.

A btw, jestli si o me delas zavery na zaklade toho, co o me doslova nevis, tak nevim nevim. Rozumej, jestli si o me myslis, ze jsem curak, protoze jsem osklivej na XChaose, oukej, takovej nazor aspon vychazi z faktu. Ale jinak... no, delej, jak myslis 8)

REDGUY:
No kazdopadne se tesim, az ten projekt v nejaky funkcni podobe predstavis. Kdy tak zhruba to bude? 8))

At uz si o nekterych XCHAOSovych myslenkach myslim cokoliv, jedna vec se mu neda uprit: predstavil minimalne dva ambiciozni a realizovane projekty (web browser a solarni kolo). To je vic, nez jsi - alespon co me je znamo - ukazal Ty. Mohu se plest, samozrejme

Ja osobne si respektuji vice lidi kteri neco delaji byt treba ne skvele nez lidi, co jen hospodsky kritizuji a navazeji se do jinych byt sami nic nepredvedli a sedi coma na prdeli.

KEJML: tak zas tak ambiciózní to není, dnes jsou jazyky dost složitý, takže pořád jsou lidi, kteří jen primitivně skriptujou v shellu, což je overkill směrem na druhou stranu.

spíš mám po letech chuť něco naprogramovat. podle kámoše co dělá v PHPse dnes všechno píše spíš v node.js... ale cílem je přesně to,co jsem popsal: lidi mají někde PHPhosting a potřebujou to, co usmolej, hned deploynout. nicméně, když se budou učit to moje prostředí, tak jim paralelně vyjede i zdroják v C pro FastCGI, nebo (snad) i ten node.js

nebude to nic extra složitýho, spíš prostě webová platforma.. bindingy na mysql a čtení formulářů, apod...