XCHAOS: jinak důkaz, že se to dnes běžně dělá, námatkou - nikdo nerika, ze se to nedela. Ale podivej se treba na ten CoffeeScript: mas nejakou velmi rozsirenou platformu (webovej browser), na ktery existuje pouze jeden programovaci jazyk, kterej navic v dobe vzniku CoffeeScriptu byl dost hloupej a mel/ma par dost blbech featur. Takze vznikl CoffeeScript kterej v podstate opravuje a doplnuje JavaScript. Coz je kompletne jina motivace, nez mas ty. Na tvych cilovych platoformach existuje spousta kvalitnich jazyku a tvuj vlastni jazyk nic noveho, lepsiho neprinese, naopak, podle toho co pises o "jednoradkovych templatach" to bude dost mrzak, obsahujici jen ty nejzakladnejsi vlastnosti spolecni vsem cilovejm jazykum.

Cili zase klasicky, tvuj "dukaz" je jednak o necem, co nikdo nerozporuje, jednak se tyka uplne jine situace.

Mě jako jeden poměrně vážný argument napadá, - "pomerne vazny argument" proc napsani uplne vlastni jazyk je, ze nevis, jak pomoci maker v C udelat paralelni zpracovani seznamu? LOL 8))))

jen programátor zná záměr, kdy se musí procházet položky seznamu sekvenčně a kdy mohou být paralelizované - nepravda. V C to tak mozna je, ale obecne to neplati.

celá struktura přitom bude fungovat i když se pro ""hloupé" vyšší jazyky preloží identicky s normální for. - anebo proste muzes programovat v Pythonu, kterej ma modul multiprocessing . Nebo v Clojure, kde proste udelam pmap. Nebo Perl6, kterej ma podporu pro multithreading velmi hluboko v sobe. Nebo, pokud jsem IO-bound, tak v Node.js. A necpohybuju ze nejaka knihovna existuje i pro C. Anebo proste pokud jsem trouba a o nicem z toho nevim, tak si budu predstavovat, ze jsem prisel na neco genialniho a zacu vymejslet vlastni jazyk. Co z toho je lepsi reseni 8)))

ještě poslední slovo dneska - proč se mi s tím asi chce přeci jen hrát. přečetl jsem si historii tohoto přístupu - používal se hlavně na začátku éry mikropočítačů, co jsem tak pochopil....
Source-to-source compiler - Wikipedia
https://en.wikipedia.org/wiki/Source-to-source_compiler

(ale nezmiňuje to příklady zavedených code generátorů)
Eiffel (programming language) - Wikipedia
https://en.wikipedia.org/wiki/Eiffel_(programming_language)
Although there is no direct connection between Eiffel and C, many Eiffel compilers (Visual Eiffel is one exception) output C source code as an intermediate language, to submit to a C compiler, for optimizing and portability.

jinak důkaz, že se to dnes běžně dělá, námatkou
CoffeeScript - Wikipedia
https://en.wikipedia.org/wiki/CoffeeScript

Mě jako jeden poměrně vážný argument napadá, že pokud chci paralelně k vždy-sekvenčmu for_each (nebo prostě for ve stylu pytnonu) udělat nějakou modifikaci (typu for_any, nebo napsat jen "any"), které bude automaticky spouštět iteraci ve více vláknech (jen programátor zná záměr, kdy se musí procházet položky seznamu sekvenčně a kdy mohou být paralelizované!), tak si prostě v C s makry nevystačím ani při nejlepší vůli.

celá struktura přitom bude fungovat i když se pro ""hloupé" vyšší jazyky preloží identicky s normální for. Pro C pak můžou existovat dva sub-targety, jeden s použitím multithreadingu a druhý bez něj. přitom ale zdroják zůstane snadno čitelný a přenositelný na systémy bez multithreadingu.

(podotýkám, že dnes se fakt pořád spousta věcí programuje tak, jako by CPU pořád měla jen jedno jádro.... zrovna na serverech, kde se prostě jen pustí víc procesů, to asi nevadí... pokud budu mít datovou strukturu, která přibližně bude vědět "kolik toho je", tak jen třeba automatická paralelizace kódu, o kterém programátor ví, že paralelizovatelný je, za nějaké to úsilí stojí...)

XCHAOS: tím pádem zase mezikód bude poměrně debugovatelný i mimo rámec IDE, které je specializované na konkrétní jazyk. - HAHAHAHAHAHAHAHAHA. Takze ty rikas, ze se bude debuggovat ten generovanej mezikod? HAHAHAHAHAHAHA. Cili kdyz budu chtit ladit svuj program, budu muset soucasne premejslet ve svym jazyce a v cilovym jazyce? HAHAHAHAHAHAHA. Tak touhle zoufaly usili vydavat kazdou nesmysl a pitomost vlastne za vyhodu, to je proste super 8))

že v jistý moment je užitečnost algoritmu tím větší, čím větší množství lidí je schopno porozumět zdrojovému kódu a SOUČASNĚ čím větší množství lidí je schopné kód jakkoliv spustit. - akorat ze tenhle "argument" ma ten problem, ze kdyz pises v Pythonu nebo C, tak jsi schopnej to pustit v podstate vsude a rozumi tomu taky spousta lidi. PHP jsi pak schopnej pustit vsude, kde potrebujes (realnej webovej server, neschopnej pustit PHP snad ani neexistuje, ). Takze znovu: tvoje predstava, ze fungl novej jazyk, kterej nikdo neumi a kterej se bude prekladat do C/PHP/Pythonu/whatever nejak uzitecne rozsiri mnozstvi platforem, na ktery jsem schopnej programovat, je _nesmyslna_.

očekávám jednořádkové templaty - LOL. Jinymy slovy, ten "prekladac" bude extremne naivni a jazyk sam extremne omezenej, protoze to bude proste nejakej malinkej prunik vlastnosti jednotlivejch cilovejch jazyku. Abys mohl mit "jednoradkove templaty", tak proste nebudes moc pouzit veci, ktery jsou v Pythonu a ne v C a tak dale. Cili to bude hloupy, omezeny a pomaly. Oooukej 8)))

Is there a program which converts code written in one programming language to code in another programming language? - Quora
https://www.quora.com/...written-in-one-programming-language-to-code-in-another-programming-language

KEJML: tak minimálně to, že z kódu obsahujícího unicode identifikátory vygeneruju mezikód pro C, které je nemá, ale zato tam můžu do mezikódových pracovních názvů proměnných zabudovat masivní debug info (typu local_integer_xn--luouk k-z2a6lsyxjlexh, global_string_xn--rrvn28h :-). tím pádem zase mezikód bude poměrně debugovatelný i mimo rámec IDE, které je specializované na konkrétní jazyk...

podívej se na to z toho úhlu pohledu, že v jistý moment je užitečnost algoritmu tím větší, čím větší množství lidí je schopno porozumět zdrojovému kódu a SOUČASNĚ čím větší množství lidí je schopné kód jakkoliv spustit.

samozřejmě taky nejtěžší bude generování C mezikódu a pokud zvládnu tohle, tak paralelní překlady do vyšších jazyků jsou v proti tomu podstatě formalita (očekávám jednořádkové templaty...)

taky mi asi inspirovalo, že se dnes používá se střídavými výsledky strojový překlad mezi vecelku-nedeterministickými lidskými jazyky - přičemž na překlad mezi téměř-deterministrickými počítačovými jazyky jsem nenarazil (ale právě to zkusím pogooglit...)

KEJML: Souhlas. Je to cute, ale fakt to neni featura, kvuli ktery by nekdo zahodil celej ekosystem normalniho rozsirenyho jazyka a presel na xJazyk.

Jako na unicofe identifikátorech bych se fakt netočil. To funguje v Jave, Perlu, Pythonu 3, Javacriptu, Ruby a jistě v mnohých dalších. Na druhou stranu v komerční praxi jsem to použitý neviděl.

XCHAOS: ale kdo ovládá všechny ty knihovny? - aha. Takze tvoje reseni je "budu si psat vsechno sam, tak to budu mit pod kontrolou a budu vedet, kdo to dela a jestli je to bezpecny". No, je videt, ze o programovani cehokoliv vetsiho fakt vubec nic nevis.

Nemluve o tom, ze se ted krasne strilis do vlastni nohy: pokud ty neveris knihovnam, proc by nekdo mel verit tvemu prekladaci?

slabiny se ti hledají blbě. - LOOOOOOL. No jasne, zadny "slabiny" tady vubec najevo nevysly, nenene, v zadnym pripade. Idiotsky debugovani, zadny knihovny, nebo uz samo to, ze vlastne nejsi poradne schopnej rict, jaky realny vyhody to bude mit, ne, to vubec nejsou slabiny 8)))))


že nějaký jazyk přináší spoustu okrajových a málo používaných features, to jako velkou výhodu nevidím. - rika clovek, kterej se chvastal tim, ze jeho jazyk bude umoznovat unicode ve jmenech promenych 8))))

REDGUY: ano, ale kdo ovládá všechny ty knihovny? do jisté míry je tím dané, že i když kód, který si stáhneš, je opensource, tak znalost jazyka, bez znalosti všech použitých knihoven, je ti téměř nanic, pokud jde o vyhodnocení toho, co kód vlastně dělá a jestli je bezpečný...

REDGUY: a debugger... přiznávám, že jsem o tom nepřemýšlel, je fakt, že už léta vyvíjím bez debuggeru a když něco nedělá to co má, tak používám konzervativní nástroje jako logování nebo debugovací výstup. je ale pravdě, že je to dnes silně menšinový styl (přitom v 90kách jsem normálně používal Borland IDE.. jen jsem si to odvykl při ladění aplikace, co se nevešla do paměti, nebo ne současně s aktivním ovladčem síťové karty, byly v ní problémy s přepínánám grafického módu, apod.... a pak dtto, v Linuxu na přelomu tisíciletí žádné pořádné IDE nebylo, i když jsem kdysi používal první IDE, která byla)

v nějakej moment si prostě krokovat kód odvykneš a přidáš do něj debug hlášky... vím že to zní jako návrat do historie, ale prostě IDE, která jsem viděl v poslední době, jsou natolik monstrózní, že mi přijde lepší prostě psát kód, u kterého je jasné co dělá :-)

(použít commandline debugger je pak naprosté zoufalství, před tím jsem prchnul hned jak to šlo :-)

zmínka o debugování je samozřejmě namístě.. já chci cílit na lidi, co potřebují co nejrychleji napsat kód, který dělá to, co chtějí, aby dělali... myslím fakt nemám větší ambice než svého času Perl, který v podstatě začínal jako nástroj na efektování parsování logů a generování různých statistik.

pokud by se to fakt náhodou rozšířilo, tak navázat debugování na debug informace v mezikódu by bylo pro vývojáře ide asi to nejmenší, navíc právě překlad do více jazyků může v budoucnu umožnit třeba použít pro debugování jazyk, ve kterém se lépe debuguje, protože má nějaký runtime (javascript?), zatímco deploynout bys mohl binárku vyrobenou z C mezikódu.

prostě jako obvykle útočíš na hypotetický koncept jen tak z principu (protože tě to prostě baví), ale slabiny se ti hledají blbě.

to, že nějaký jazyk přináší spoustu okrajových a málo používaných features, to jako velkou výhodu nevidím. jak jsem psal dříve - snižuje se tím počet osob, které jsou schopné kódu porozumět, čímž se v podstatě znehodnocuje celý koncept opensource (porozumět zdrojovému kódu spravovaného jiným vývojovým týmem je často docela komplikované)

uznávám, že Esperanto, coby vzdáleně podobný pokus v "lidské lingvistice" zůstalo okrajovou kuriozitou...
Esperantští rodilí mluvčí – Wikipedie
https://cs.wikipedia.org/wiki/Esperant%C5%A1t%C3%AD_rodil%C3%AD_mluv%C4%8D%C3%AD
wow.. Soros je rodilý mluvčí Esperanta? tak to vysvětluje mnohé :-))

XCHAOS: představ si třeba názvy proměnných v plném utf-8. - Ach boze. Myslis treba tak, jako v Perlu 6? Sokujici 8)))

v generovaném mezikódu můžu řádky původního zdrojáku vždycky vkládat jako komentář - a to bude k cemu? Ty jako cekas, ze nekdo bude pracovat s tim mezikodem? Nebo proste bude muset, protoze mu nic jinyho nezbude treba pri lateni programu, protoze xJazyk samozrejme zadny poradny debuggery mit nebude? To zni fakt pohodlne 8)))

Akorat ze teda porad nic konkretniho a zasadniho. UTF-8 jmena promenych? Cute, ale zily to nikomu fakt nerve. Puvodni zdrojak jako komentar? Wow, sokujici. Znovu: proc by nekdo mel zahodit vsechno, co mu prinasi Pyhon/Perl/Erlang/Node.js a pouzivat xJazyk?

XCHAOS: ano, PHP i node.js mají dnes vlastní balíčkovací systémy - co to zase mlzis? Proc do toho tahas balickovaci system? Nejde o balickovaci system, jde o to, ze pro PHP, Perl, Python a dalsi rozsireny jazyky existuje spousta knihoven (bez ohledu na to, jak jsou distribuovany), ktery muzes pouzivat. Komprese, kryptografie, statistika, http, whatever, proste kdyz to potrebuju, tak najdu prislusnou knihovnu a jedu. Zatimco u xJazyka? Nic.

několikrát jsem tě prosil, abys solární letadla a kola netahal do diskuzí, kde jsou offtopic. me prijde fakt zabavny, jak je tvuj pristup naprosto stejnej, at uz jde o letadla, programovani nebo kola. Spousta velkejch reci a pak... no, vime 8)


doufám aspoň snad uznáš, že je to daleko rozumnější ze je_co_ daleko rozumnejsi? Zatim jen placas paty pres devaty a nejsi schopnej poradne popsat, co vlastne udelas, co presne to bude delat a v cem to bude lepsi.

REDGUY: ehm, "ekosystém knihoven".... ano, PHP i node.js mají dnes vlastní balíčkovací systémy, ale je to fakt dobře? fakt by se měly aplikace lepit takhle? (ostatně i Perl je má)

Jako mícháš pátý přes devátý a několikrát jsem tě prosil, abys solární letadla a kola netahal do diskuzí, kde jsou offtopic.

S tímhle nic vyhrát nechci, prostě jde jen o to, že jsem už někdy v éře 8bitových počítačů plánoval "vlastní dialekt Basicu", protože některé tehdejší dialekty Basicu se mi od pohledu líbily o dost víc, než tehdy oficiálně doporučovaný Turbo Pascal. (Hodně lidí se naštve, když Python označím za "dialekt Basicu"... ale... :-)) Prostě vždycky jsem přemýšlel nad omezeníma jazyka, kterým se bavím s počítačem...

celá věc s paralelním cílením na víc platforem se mi může vymstít, až narazím na konstrukci, kterou třeba některý z těch jazyků nemá vůbec, nebo jí má řešenou zcela odlišeně od ostatních (ehm, to popravdě nastane asi hodně brzo - viz jen různé systémy odchytávání vyjímek, apod. :-)

celkově je to prostě nová věc, o které jsem začal přemýšlet. dnes máš toolkity, které ti umožní úplně předefinovat nějaký jazyk a psát v něm úplně jiným stylem, než v původním jazyce: tohle je vlastně přesný opak, je za tím snaha o srozumitelnost, o psaní jednotným stylem bez ohledu na cílovou platformu.

(doufám aspoň snad uznáš, že je to daleko rozumnější, než releasnout nějakou aplikaci pro více platforem a pak čekat, že případná zlepšení nebo bugfixy někdo backportne pro všechny podporované platformy...)

XCHAOS: proměnné v mezikódu se mohou jmenovat komplexně a obsahovat v sobě např. informace o typu

to už existuje :)
Name mangling - Wikipedia
https://en.wikipedia.org/wiki/Name_mangling

REDGUY: bude high-level, ale staticky typovaný. vlastně v nějakých prvních alfaverzích bude určitě daleko víc low-level, než cílové platformy typu PHP, Python nebo Javascript :-)

je to poměrně jednoduchý nápad, který je navíc příjemně mimoběžný k mým dalším snahám v C - pokud někdy v budoucnu vymyslím nějaký vlastnílepší memory management, můžu ho právě zabudovat do tohohle překladače :-)

jak jsem tu před lety předváděl, v čistém C není problém zkonstruovat většinu vyšších abstrakcí, typu polymorfní objekty, apod. Jediný problém je, že tyhle konstrukce pak nejsou úplně human-readable, což právě precompiler řeší (mj. ručení editace těch složitějších konstrukcí budou zdlouhavé a náchylné k chybování programátora, a makra mají taky svoje mouchy...).

Mj. v generovaném mezikódu můžu řádky původního zdrojáku vždycky vkládat jako komentář (nebo min.to může být on-demand feature, přepínaná commandline parametrem).

Další věc, která mi napadá je, že proměnné v mezikódu se mohou jmenovat komplexně a obsahovat v sobě např. informace o typu, což mezikód učiní čitelnějším a umožní to vkládat do názvů proměnných znaky, které cílové platformy nepovolují (zase, tahle feature může být volitelná...)

(Příklad: představ si třeba názvy proměnných v plném utf-8. generování mezikódu tenhle problém plně řeší. možná ti to nepřijde podstatné, ale já si dovedu představit, že to zpřístupní programování třeba národům, které nepoužívají latinku... a i v češtině bude frajeřina mít proměnné s diakritkou :-))

(Jako částečně je to samozřejmě samoúčelné, ale taky to neprezentuju jako jako nějaké všespásné řešení - s rostoucím věkem a vývojem okolo je pro mě všchno programování víc a víc jenom hraní... ale pořád mám potřebu udělat něco,s čím by si chtěli pak hrát i jiní...)

A btw, chapu spravne, ze si predstavujes, ze tvuj xJazyk bude obdobne high-level jako rekneme python nebo php, nebo mozna jeste vic... a soucasne si myslis, ze zvladnes napsat jeko prekladac do C, takze to bude schopny bezet i na hardwarove extermne omezenejch embedded platformach? No, LOL. Uz se nemuzu dockat 8)))

XCHAOS: nemůžeš mi současně vyčítat, že to platforma je i že to platforma není : - lzes, nerikam, ze to "neni platoforma". Rikam, ze to je spatna, mala a omezena platforma a pokud by ji nekdo zacal pouzivat, byl by na tom mnohem hur, nez kdyz pouziva treba to PHP, protoze locknutej by byl uplne stejne, ale navic by nemel ten obrovskej ekosystem knihoven, nastroju a vedomosti, co existuje kolem PHP.

vzhledem k tomu, že už jsem se učil v X programovacích jazycích, tak mi zajímá spíš "komparativní počítačová lingvistika", - hmmm. A ja do ted mel pocit, ze tech jazyku zas tak moc neumis. A ted najednou ses jich ucil "X" a chces bejt "komparativni lingvista"? S ohledem na blaboly, co rikas treba o perlu si o tom dovolim dost pochybovat 8)))

parser + generátor kódu (v podstatě "praser", generátor zpraseného kódu :-) je věc, kterou jsem zatím ještě nikdy neprogramoval - coz o to, klidne si to naprogramuj. Ale prestan blabolit nesmysly o tom, jak timn vyresis "problemy" kolem PHP, C a jinejch veci. Coz je ostatne stejnej problem jako se vsim co delas: nejsi schopnej proste jen rict "budu si hrat s psanim prekladacu/solarnima letadlama/solarni kolo", ale proste musis machrovat o tom jak "napisu vlastni platformu ktera vyresi problemy C a PHP/postavim revolcuni solarni letadlo/vyhraju suntrip" - a vsichni vime, jak to pak dopadne 8))) Trochu soudnosti, prosim.

Stejně tak se do C prekompiluje kde co, např. různé parsery (GNU nástroje bison/flex) - ale prdlajs. Bison neni prekompilator, bison je generator parseru.

a tedy i platformy, na které nebylo zatím přeneseno, co já vím PHP, nebo Python, - a nedostupnost PHP na Atmel AVR je problem proc? Zase, tohle je odpoved na neexistujici otazku. Nikdo na svete si nerika "Jezis, me chybi moznost provozovat PHP na tyhle bizarni architekture, kez by nekdo napsal nejakej uplne novej programovaci jazyk, kterej by sel pres C zkompilovat jak na x86_64, tak na AVR".

Python, nebo zejména, embeded platfory, pro které mají tahle prostředí moc velký overhead - LOL. A ted zase vidime, jak vubec netusis o cem mluvis, protoze shodou okolnosti zrovna minulej tejden jsem si nainstalovat python na ESP8266 jednocipak, cili desticku 4x2cm s dvema integracema a dvaceti nozickama. Hele fakt, prestan placat o vecech, o kterejch prd vis.

někdo s odvahou označovat sysadminy za trouby - znovu, lzes. Neoznacuju globalne sysadminy za trouby, za trouby oznacuju jen ty, co maj problem naucit se par syntaxi konfiguraku.

Ad "co má cenu optimalizovat a co ne" - no prostě máš nějaký kód, který napíšeš intuitivně, a zjistíš, že ti překlad do vyšších jazyků běží třeba 10 sekund, což by třeba v daném prostředí ("všechno je runtime", jak si všimli už v 60tých letech - skript pro výpočet měsíčních mezd nesmí běžet dýl, než 1 měsíc, apod. :-) už byl problém, ale C verze poběží sekundu, tak se na nějaký optimalizování toho kódu vykašleš... když i C verze poběží 10 sekund, tak víš, že nad tím musíš dál přemýšlet. - sorry, vubec nechapu, co timhle chces rict.

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

REDGUY: já se popravdě ani nehádám, ve většině podstatných bodech (i když to nic nemění na tom, že moje politka je lidi, které mám na ingorelistu, ve svých klubech preventivně zabanovat, a tady jsem na to prostě jen zapomněl :-)

Kromě míst, kde si protiřečíš - nemůžeš mi současně vyčítat, že to platforma je i že to platforma není :-) Je to "mikroplatforma". Pokud si jako první cíl vytyčím, že jí použiju jen ke generování benchmarků, tak se tím vyjasní spousta věcí - např. od příznivců jednotlivých dílčích sub-platforem očekávám, že budou auditovat vygenerovaný mezikód a bedlivě hlídat, jestli se používají opravdu postupy, které by sami použili při psaní nativního kódu, apod.

jak daleko je node.js mi popravdě celkem zajímá - dnes jsem si ho poprvé nainstaloval.

podívej se na to z jiné stránky: pokud si chci hrát s novými platformami, tak mě prostě v mém věku nebaví jen tak si vymyslet něco, co bych naprogramoval v node.js jen tak. vzhledem k tomu, že už jsem se učil v X programovacích jazycích, tak mi zajímá spíš "komparativní počítačová lingvistika", tedy okamžitě jakýkoliv nový jazyk srovnávám s tím, co už znám z minulosti (u příkladu na node.js mi pobavilo, že javascript už nemá jen "var", ale i "const" :-) možná to měl vždycky, ale já nikdy v javascriptu neprogramoval nějak vážně, vždycky jsem jen bastlil)

parser + generátor kódu (v podstatě "praser", generátor zpraseného kódu :-) je věc, kterou jsem zatím ještě nikdy neprogramoval, a už jen rozmyslet si, jak se to celé bude konfigurovat (pravděpodobně k tomu obrovská knihovna nějakých template-fragmentů pro všechny ty různé jazyky - s tím, že si budu muset vymyslet vlastní syntaxi pro ty templaty....)

myslím, že naučit se přemýšlet tímhle směrem by mi pomohlo i líp vytrénovat mozek pro učení se běžných lidských jazyků (pociťuju potřebu naučit se francouzsky a čínsky - protože to jsou dva národy, který na angličtinu prostě serou). kromě toho už mi po letech nebaví nechat se omezovat přemýšlením jak rozšířit C o nějká chytrá makra :-) protože takové přemýšlení má jasně dané limity, které už mi štvou.

prostě komparativní kompilace (zpočátku aspoň jednoduchých) struktur do více jazyků je zajímavá hra, která mi zajímá čistě jen proto, že jsem na nic podobného ještě nenarazil (možná to už někdo udělal, a já o tom jen nevím - proto o tom píšu sem)

Pre-kompilaci do C (pokud si to s něčím nepletu) používalo např. prostředí Eiffel, ale to mi ve srovnání s tím, jak se programuje dnes, připadalo takové hrozně zastaralé, hmm... (ale zase, šel jsem hodně po povrchu). Stejně tak se do C prekompiluje kde co, např. různé parsery (GNU nástroje bison/flex), ale fakt jsem zatím neslyšel o precompileru který by kompiloval do více cílových platforem (jedinou inspirací může být samotné GNU C, generující strojový kód pro více různých platforem - a tady současně vidíš, jeden z možných argumentů: pokud budu generovat ze "svého jazyka" C mezikód, okamžitě tím dosáhnu na všechny platformy, pro které umí gnu C vygenerovat binárku - a tedy i platformy, na které nebylo zatím přeneseno, co já vím PHP, nebo Python, nebo zejména, embeded platfory, pro které mají tahle prostředí moc velký overhead...)

(Tím současně asi definuju první užitečnou aplikaci: hypoteticky by target platforma "C mezikód" měla mít menší memory footprint a menší system requirements, než ostatní target platformy, a tím by automaticky bylo všechno, co se na "mé platformě vyvine", možné provozovat i na skromnějších platformách...)

O tom, kdo všechno je u tebe trouba, asi nemá cenu tu vést další diskuzi :-)) Jsem rád, že konečně je tu někdo s odvahou označovat sysadminy za trouby - většinou se totiž hádám s lidma, který jsou primárně sysadmini :-)

Ad "co má cenu optimalizovat a co ne" - no prostě máš nějaký kód, který napíšeš intuitivně, a zjistíš, že ti překlad do vyšších jazyků běží třeba 10 sekund, což by třeba v daném prostředí ("všechno je runtime", jak si všimli už v 60tých letech - skript pro výpočet měsíčních mezd nesmí běžet dýl, než 1 měsíc, apod. :-) už byl problém, ale C verze poběží sekundu, tak se na nějaký optimalizování toho kódu vykašleš... když i C verze poběží 10 sekund, tak víš, že nad tím musíš dál přemýšlet.

XCHAOS: 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 - za prve, mozna se rozhlidnout dal, nez jen "kolem sebe". Moznosti v cem psat je mnohem vic, nez jen PHP. Za druhe: "vse je nutne prepsat" - LOOOOOOOL. To je zase videt, jak strane jsi mimo. Pokud mas nejakou opravdu velkou codebasi, tak "proste to prepsat" fakt neni tak jednoduchy, jak si predstavujes. Mozna ti "lidi kolem tebe" nejsou konzervativni troubove, co se PHP drzej jen kvuli svoji omezenosti, ale proste jim nic jinyho nezbejva. Precti si treba https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ .

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. - a tohle uz je naprosta pitomost. Vis, co znamena slovo "platoforma"? Nebo je to zase jen dalsi pripad, kdy kolem sebe hazis buzzwordama a fakt netusis, co vlastne znamenaji? Je uplne jedno, jestli tvuj jazyk preklada do C, PHP nebo je samostatnej runtime (nebo vsechno najednou). Proste uz ciste tim, ze to je samostatnej jazyk to je vlastni "platforma". Uvozovky proto, ze samozrejme neobsahuje vsechno ty uzitecny knihovny a nastroje, ktery jsou k dispozici ve skutecnejch platformach jako PHP nebo treba Node.js.

jeho bastl přeložený do PHP už výkonostně nestačí - a to je zase ta naivni predstava "vykon se zvysi prelozenim do C". PHP (a Node.js a Python a Erlang a Java a Clojure a Scala a...) jsou v soucasny dobe tak daleko, ze pro rozumne napsany aplikace, zejmena webovy, by zvyseni vykonu "prepsanim do C" bylo zcela marginalni, ne-li negativni. To jsou extremne chytry interpretry (nebo dokonce JIT prekladace), cely leta optimalizovany spoustou fakt chytrejch lidi. Takze webova aplikace, ktera typicky limitovana spis IO nez CPU, z nejakyho "prekladu do C" fakt moc neziska. Tim spis, kdyby ten "prekladac do C" psal nekdo jako ty 8))) Ostatne, viz ta trapna scenka par let dozadu, co jsi sem linkoval nejakej bizarni microbenchmark, u kteryho se pak ukazalo, ze daval naprosto nesmyslny vysledky, protoze jeho autor by proste trouba a kdyz se to napsalo spravne, najednou to vyslo uplne obracene 8)))

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 - blabol. Za prve, zpusoby konfigurace aplikaci jsou uz dostatecne sjednocene, za druhe, jestli je pro sysadmina problem naucit se treba syntaxi jsonu, tak je to dost trouba.

paralelní překlad algoritmu pro víc platforem taky líp rozhodne, co má cenu optimalizovat a co ne. - a co je tohle za pitomost? Co tim chces rict?

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