XCHAOS: tím vznikne knihovna rutin, ze kterých zájemci budou moc libovolně opisovat (a to tak, že se právě podívají na C mezikód, kterým ji to vygeneruje) Hele, tohle me fakt fascinuje. Prisim, vysvetli mi, jak si to predstavujes? Nejakej konkretni, specifickej use-case, zadny obecny kecy (pokud toho jsi schopnej 8)) ). Kdo konkretne by byl takovej zajemce? Nejakej zacatecnik v C? Zkusenej programator v Pythonu? Bezdomovec z Hlavaku? A na jakou konkretni rutinu by se koukal? Neco zakladniho, jako quicksort? Nebo neco ezoterickyho? Prosim, zkus popsat konkretni priklad. A kdyz k tomu zvladnes napsat i jak ta knihovna rutin "vznikne", bude to super 8))

XCHAOS: jinak pokud by můj "bizarní jazyk" splnil kritérium [...] tak je to podle mě určitý achievement - no urcite. A kdyby byly v kapse ryby, nemuseli by bejt rybniky. A kdybys mel technolohickej naskok, tak bys vyhral SunTrip 8)) Hele, s timhle radsi pockej, az to budes mit. Protoze jinak jsou to zase jen plany kecy.

XCHAOS: Pythonu jsou stringy natolik nativní součástí jazyka (neimportuješ na ně žádný modul) - meh. To nic nemeni na tom, ze jadro jazyka a knihovna jsou uplne jine veci. Ty jsi v situaci, kdy vlastne jeste ani poradne nevis, jak ten jazyk bude vypadat, ale uz resis, ze v knihovne bude mit "split". No, ok, no. Mas ty priority krapet pomotany 8))

REDGUY: no jen tak letmo, nemám čas odpovídat na všechno

- že je jazyk dynamicky typovaný, mi může být jedno, pokud během vygenerování kódu v tomto jazyce více či méně pohlídám, jaký typ proměnný přidávám čemu (méně pohlídám = compile time kontroly, jako v C, více pohlídám = např. v případě proměnných předávaných funkci provedu jejích přetypování

- u Pythonu jsou stringy natolik nativní součástí jazyka (neimportuješ na ně žádný modul), že nemůžeš rozhodně mluvit o knihovně funkcí (to, že v C jsou stringy jen knihovna neznamenám, že to tak je v jakémkoliv jiném jazyce, kde jsou většinou ten nejvestavěnější základ všeho - dělá to z C nikoliv "kapotovaný assembler", ale naopak naprosto nekapotovaný podvozek, ke kterému si musíš externě připojit volant i sedačky)

- jinak pokud by můj "bizarní jazyk" splnil kritérium, že bude schopen přeložit sám sebe a mít v sobě napsaný svůj vlastní compiler, tak je to podle mě určitý achievement programátorského vývoje, přechod na další level... jako když máš počítačovou hru a dohraješ jí na další level.

XCHAOS: Hele, polozil jsem ti jednoduchou otazku. A samozrejme, misto toho, abys jednoduse odpovedel, taks to proste jako obvykle zacal okecavat. Klasicky xmlzeni 8)))

ne další ochranu uvnitř kódu - coz je u jazyku, jako PHP, ktery obcas zmeni typ promenny, krapet problem 8)))

aby si třeba funkci, která má jako parametr int, nemohl předat string - ne, opravdu, nemusis nam vysvetlovat, co jsou to typovy kontroly. Teda, pokud neni tvym cilem jen odvest rec od problemu 8))

. metoda .join() co má jako parametr seznam :-)), i když obdivuju jak dlouhé onelinery tam s tím často jde poslepovat... naopak "split()" tam v nějaké fomě určitě chci mít. - jeeeezis. Ty asi moc nechapes rozdil mezi knihovnou funkci a jazykem, vid? 8))

Obecně práce s textem (což bylo původní zaměření celého C) - Eeeeeeh? Muzes prosim tenhle blabol nejak dolozit? Ja si vzdycky myslel, ze C vzniklo jako systemovej jazyk pro implementaci Unixu. Ale zjevne mas jine informace, takze prosim, povidej 8)))

ak už třeba jen iterovatelnost stringů po jednotlivých utf-8 znacích je věc, na kterou asi bude v Pythonu potřeba napsat nějaký ten iterátor - A co je tohle za pitomost?

Minimálně tím vznikne knihovna rutin, ze kterých zájemci budou moc libovolně opisovat (a to tak, že se právě podívají na C mezikód, kterým ji to vygeneruje) - a proc by to proboha nekdo delal? Proc by se nekdo ucil nejakej bizarni jazyk, kterej dokonce podle tvyho vlastniho vyjadreni nebude pouzitelnej na vetsi projekty, jen proto, aby se koukal, jakej C mezikod z nej vypadne? Teda, krome me, abych se pobavil 8)))

Tohle je zase klasika: ty proste nejsi schopnej priznat, ze jedinej smysl, kterej to muze realne mit, je, ze se zabavis a neco se naucis. Ty proste musis mit svalnaty recicky o tom, jakej uzasnej prinos to bude mit pro lidstvo. No... nebude 8))

XCHAOS: já ale v životě udělal už řadu hloupostí a popravdě - láká mi to asi právě proto. - to ale nic nemeni na tom, ze tvuj argument je nesmyslnej. A pokud te nesmyslny argumenty lakaji proto, ze jsou nesmyslne... no, mel by sis najit nejakej min exaktni obor, jako programovani 8)))

REDGUY: já ale v životě udělal už řadu hloupostí a popravdě - láká mi to asi právě proto.

Doufám, že konečně teda ukončíš svůj boj s větrnými mlýny (protože pro mě jakožto pro větrný mlýn je to strašně únavné).

REDGUY: popravdě, předpokládám hlavně kontrolu silného typování během překladu, ne další ochranu uvnitř kódu (typu proti tvým přetečením, apod.). Extrémní use casy se asi na každé cílové platformě budou chovat trochu jinak (ostatně, asi ne nepodobě jako při překladu C kódu pro různé platformy)

Speciálně mi půjde o to, aby si třeba funkci, která má jako parametr int, nemohl předat string - díky dynamickému typování tahle věc v řadě případů projde, a např. i díky použití + jako operátoru pro řetězení stringů se můžeš dostat docela daleko.

Ta ochrana bude tedy o tom, že můj překladač odmítne kód vůbec vygenerovat, pokud nebudou typy kompatibilní (s tím, že k přetypování či předávání void pointerů nebude ani žádný důvod, protože jazyk bude mít pokročilou nástroji se sbírkami/kontejnery po vzoru vyšších jazyků - kdo takovou potřebu bude cítit, ať zůstane přímo v C...). Pokud bude kód "vygenerovatelný", tak ale pak dál v tom PHP či Pythonu už nebudou žádné speciální ochrany - bude to prostě ochrana na té úrovni, kterou by měl dělat programátor, kdyby myslel na všechno (s tím, že samozřejmě v řadě případů nemyslí).

Jinak pro řetězení stringů (což bude akce vždu alokující paměť) chci použít operátor (resp.asi se to ani nebude zapisovat jako operátor) zcela nový (a tím i vytvořit nekompatibilitu právě s Pythonem, u kterého se mi tahle jedna jediná konkrétní věc prostě moc nelíbí). Je pár dalších věcí kolem stringů v Pythonu, které mě nepřijdou úplně intuitivní na čtení (např. metoda .join() co má jako parametr seznam :-)), i když obdivuju jak dlouhé onelinery tam s tím často jde poslepovat... naopak "split()" tam v nějaké fomě určitě chci mít.

Obecně práce s textem (což bylo původní zaměření celého C) je věc, kterou se zabývám odjakživa a kterou chci nějak provádět bez ohledu na platformu. Tak už třeba jen iterovatelnost stringů po jednotlivých utf-8 znacích je věc, na kterou asi bude v Pythonu potřeba napsat nějaký ten iterátor .... už jen to, že udělám nástroj nativně pracující s utf-8 na všech platformách stejně pro mě bude mít význam (tím současně prozrazuju, že jako na možnou cílovou platformu asi zatím cílím na Python 2.X, spíš než na Python 3...)

Jako je mi úplně jedno, že si myslíš, že je to hloupost. Minimálně tím vznikne knihovna rutin, ze kterých zájemci budou moc libovolně opisovat (a to tak, že se právě podívají na C mezikód, kterým ji to vygeneruje). A wannabe guruové jako ty to budou moc neomezeně dle libosti kritizovat a vysmívat se tomu, proč ne..

UETOYO: člověče, díky za tip :-) minimálně je tedy vidět, že nejsem jediný na světě, kdo uvažuje tímhle směrem.
Haxe - Wikipedia
https://en.wikipedia.org/wiki/Haxe
Home - Haxe - The Cross-platform Toolkit
https://haxe.org/
Overview - Haxe - The Cross-platform Toolkit
https://haxe.org/use-cases/

Pro mě to úplně není, protože "Haxe had its origins in ActionScript 3" ... hmm. Já uvažoval o něčem jednodušším, bližším skriptovacím jazykům, po kterých dnes sáhne většina vývojářů, když se rozhodnout napsat jen něco malého...

Zjevný rozdíl je ale v tom, že cílit překlad i do C je větší výzva, než cílit ho do objektového C++

XCHAOS: celá úvaha o tom, jak to C vlastně vůbec nemá cenu používat, právě vázne na tom, že zdrojové kódy snad všech dnešně používaných runtime prostředí jsou v C - to je samozrejme blabol. [ JANFROG @ ANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API ] rika, ze pouzivat C jako generovany mezikod je hloupost. Coz vubec nesouvisi s tim, ze interpretr Pythonu nebo PHP je rucne napsany v C.

JANFROG: posílal jsem jen odkaz na to, že v GNU C jsou na to testovací funkce, které můžeš do kódu vložit... to je celé.

jinak celá úvaha o tom, jak to C vlastně vůbec nemá cenu používat, právě vázne na tom, že zdrojové kódy snad všech dnešně používaných runtime prostředí jsou v C. (což docela překvapí, když existují kompilovatelné dialekty Pythonu... proč teda není budoucí interpretr Pythonu vyvíjen v Pythonu? :-)

když jsem u toho, v čem budu co vyvíjet.. tedy, svatým grálem každého prostředí je, aby mohlo být vyvíjeno samo v sobě, když tomu zdejší troll říká "xjazyk", tak řekněme, představa je, že by nějaký primární "bootstrap" podmnožiny mého jazyka byl napsán buď v nějakém tom "C s makry", nebo v Pythonu, a potom by se už příští generace compileru (s větším množstvím features) psala přímo v něm samém :-) (s tím, že výhodou by bylo, že by sám ze sebe uměl přeložit příští binárku :-)

UETOYO: Experimentalni. Nevidim, jak by to tohle resilo, z pohledu Pythonu je to porad integer. Ten problem, ze cisla se proste chovaji jinak v PHP a Pythonu to neresi...


UETOYO: A coz o to, resitelny to je. Ale ne na urovni XChaosovejch predstav "jednoradkovy templaty". A specificky tenhle problem, kdyz se podivas co pisou o integerech, tak pisou, ze to neresi. Takze ta predstava "napisu jednou a pak mi to fiunguje vsude" neplati ani tam.

REDGUY: Nemá PHP stejně jako Pyhon *type hints*? to by nějak mohlo pomoci ne?

XCHAOS: Uhmmm... ty fakt nechapes, v cem je problem? Tak schvalne, rekneme, ze mas takovejhhle xjazykovej kod:

int a = 2**62;
int b = 2*a;

Jak ho prelozis do Pythonu? a jak do PHP?

REDGUY: čímž si dokázal... co? :-)

"v mém" jazyce si řekneš při deklaraci o int, long int/double nebo o var/auto, ke změně typu proměnné tam nedojde, stejně jako v C.

V C lze přetečení hlídat
c++ - How to detect integer overflow? - Stack Overflow
https://stackoverflow.com/questions/199333/how-to-detect-integer-overflow

to aby se taková detekce prováděla automaticky (což ale nevím, jestli je krok, kterým začnu) je další důvod pro generování mezikódu místo pro programování přímo v C.

nebo z jiného konce: sám si ukázal, že vyšší jazyky musí provádět spoustu podobných kontrol (a např. změnit typ objektu), zatímco když víš, že opravdu pracuješ jen s integery a provádíš operace, které až do tepelné smrti vesmíru nejspíš nepřetečou, tak může být kód rychlejší.

je možné ti prostě odpovědět i tak, i tak - a hlavně si vůbec nevyvrátil, že převod do vyšších jazyků by měl být těžší, než do C mezikódu (což bude ta zajímavá část projektu, kde se budou dělat podstatná vývojářská rozhodnutí...)

XCHAOS: Použijí se nativní datové struktury těch jazyků. - BUAHAHAHA. Tak jsem si rikal, jak nejsnaz ukazat, ze tohle je pitomost. PHP neznam skoro vubec, Python jen zlehka, ale uz druhej pokus vysel:

PHP:

$a = 2**62;
$b = 2*$a;

echo gettype($a), " ", $a, "\n";
echo gettype($b), " ", $b;

integer 4611686018427387904
double 9.2233720368548E+18

Python3

a = 2**62
b = 2*a
print (type(a), a)
print (type(b), b)

<class 'int'> 4611686018427387904
<class 'int'> 9223372036854775808

XCHAOS: u těhle tvých argumentů je nesmysl hned bode 1. samotný jazyk se nebude podobat C, ale spíš Pythonu. ja ne;pisu o tom, cemu je tvuj jazyk podobny. Pisu o tom, v cem _ted_ programuje jeho potencialni uzivatel. A doslova jsi psal, ze miris na lidi, co ted jedou v PHP.

bod 3 nevím jestli si rozumíme. paralelismu je myšlený i pro commandline only prostředí, - aha. Akorat ze do ted jsi mluvil o nahrade PHP na webu. Pokud mluvis i o lokalnim pouziti, tak zase nedava smysl ten argument "nema server pod kontrolou" a proste muze rovnou jet v C nebo necem vykonym.

bod 4 netvrdím. - jenomze to vypliva z tvechj "zduvodneni". Pokud pri genervani stranky vetsinu casu stravim cekanim na IO, tak je uplne jedno, jestli cekam v PHP nebo v C, prekladem nic neziskam. Aby tvoje argumenty o vyhode prekladu fungovaly, tak musi byt generovani stranky narocne na CPU, coz typicky proste neni, obzvlast na tehle urovni.

bod 5 jsem netvrdil. - totez jako 4. Netvrdil, ale aby tvoje povidani o tom, jak uzasna vlastnost je ta paralelizace, melo aspon trochu smysl, tak je to nutna podminka.

jen proto, že v tom půjde psát _i_ webové stránky - celou dobu mluvis o PHP, celou dobu rikas, jak je to urcene pro lidi, kteri nemuzou nasadit vlastni kod, ale jen na nejakej hosting uploadujou svoje skripty, celou dobu, dokonce i vtehle zprave, mluvis o "slozite administraci server". Takze jo, predstava, ze je to primarne pro www stranky je zcela na miste. Samozrejme, pokud ti doslo, ze to je pitomost, muzes se pokusit rychle pivotnout nekam jinam a nejak to zamluvit 8)))

bod 8: ne, nečekám že někdo bude něco přepisovat z PHP. - strawman. Osmej bod neni jen o prepisovani, ale hlavne o vedomostech, nastrojich a komunite. A doslova jsi psal, ze miris na PHP programatory.

třeba i jen hračkového kódu. nic velkého. - pak ale zase nedava moc smysl to o tom, jak dulezite je ta moznost prekladu do C 8)))

A porad cekam na ty priklady 8)))

REDGUY: u těhle tvých argumentů je nesmysl hned bode 1. samotný jazyk se nebude podobat C, ale spíš Pythonu. uživatel může nadále generovat cílový kód v PHP, jen dostane šanci napsat přehlednější zdrojový kód...

bod 2 nechám na každém, jak snadné je pro něj administrovat vlastní virtuální server (min. ne pro všechny webmastery to je jednoduché)

bod 3 nevím jestli si rozumíme. paralelismu je myšlený i pro commandline only prostředí, bez webového rozhraní. někdy nechceš, aby nějaká práce s daty na pozadí trvala třeba celou noc a dobíhala ráno...

bod 4 netvrdím. jenom si myslím, že I/O podceňuješ, navíc schopnost kódu paralelně čekat na vyřízení např. velkého množství http requestů nebo jiných requestů směrem ven není nutně o tom, že se využijí ta jádra, ale že se využije to, že čeká víc různých threadů současně. Ano, paralelní I/O programovat lze i bez multithreadingu, ale je to voser...

bod 5 jsem netvrdil. neustále za tím vidíš nějkaý zcela jednoúčelový nástroj jen proto, že v tom půjde psát _i_ webové stránky...

bod 6 jo a ne. někdo může mít pocit, že přeložený kód se statickým typováním je bezpečnějí (mezikód vygenerovaný do PHP překvapivě asi statické typování mít nebude i když je otázka, pro jakou verzi PHP se kód vlastně bude generovat...)

bod 7: obecně, lidi co mají zájem všechno od designu draze redesignovat jsou ti, co se programováním živí :-) tady jsou motivace různé a někdo třeba nemá čas nebo peníze všechno přepisovat

bod 8: ne, nečekám že někdo bude něco přepisovat z PHP. je to spíš zacílené na původní vývoj. třeba i jen hračkového kódu. nic velkého.

XCHAOS: překlad zejména do PHP a Pythonu bude 1:1 - jsou tam k dispozici naprosto ekvivalentní nativní konstrukce. - opravdu? Jako chapu, ze na urovni naprostyho zacatecnika, kdyz se bavime o vecech jsou prikazy for a if a takovyhe veci, tak to tak muze vypadat. Ale jakmile se dostanes krapet vejs, tak uz to tak samozrejme neni. Co treba objekty? Ty v PHP a Pythonu funguji stejne? Co system modulu a knihoven? Presne stejne funguje i aritmetika? A tak dale, a tak dale. Opravdu opravdu opravdu vsechno jsou "naprosto ekvivalentni nativni konstrukce", ze proste staci misto "python-xxx" napsat "php-xxx" a proste to funguje, search/replace? Nebo tohle vyresis tak, ze proste ty jazyky orezes a budes pouzivat jen to nejzakladnejsi, co maji spolecny?



Jo a btw, ocenuju, jak potvrzujes to co jsem rikal o trapnem mlceni co se tyce vsech ostatnich otazek, co jsem polozil. Zejmena to, ze nejsi schopnej ukazat konkretni priklady tech, kdo by to uzili, je velmi vymluvny 8)))