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

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