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

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