REDGUY: tyhle nástroje byly napsané v C, a když jsme u toho, třeba POSIX regexpy jsou implenentované přímo v libc. Vývoj nebyl přímočarý, ale C skutečně ve své době nabízelo knihovnu pro práci se stringy jako součást standardní knihovny (byť se dnes chytáme za hlavu nad tím, jak je špatná). Zkus si zjistit, jak se v 70tých letech pracovalo se stringy např. ve Fortranu... nemluvě o jazycích, u kterých se předpokládalo, že je použije koncový uživatel, tzn. např. Basic.

Hmm, že C vzniklo jako jazyk pro implementaci operačního systému pro PDP11, to vím.. ale zadáním operačního systému Unix bylo pracovat s texty. Unix se tedy rozhodli implementovat v C, protože z dostupných jazyků nejlépe podporovalo práci se stringy... (a to zejména s přihlédnutím k tehdejším omezeném výkonu počítačů, nedostatku paměti, apod.)

Debata, jestli bylo dřív vejce nebo slepice je zajímavá, ale sám připouštíš, že C bylo vytvořené, aby mohl být implementovaný operační systém. Samozřejmě, že můžeš tvrdit, že dle kanonické mytologie byl operační systém potřeba, aby mohla být implementována hra Space Travel :-)) ale fakticky Bell Labs začal do Unixu lejt prostředky, když měl zadání na systém na zpracování textů.

(Otázka samozřejmě je, kdy začalo C vypadat tak, že bys ho možná poznal a že by překompilovalo nějaký tvůj zdroják... jestli už před Unixem, nebo až dlouho potom)

XCHAOS: nástroje pro tu práci s textem tehdy byly napsané v C - Aha. A procpak se asi nastroje pro praci s textem, jako sed nebo awk, vubec psali? Kdyz podle tebe bylo pro praci s textem urcene C? Podle tebe bylo C tak zamereny na praci s textem, ze si tenkrat radsi napsali sed, awk a dalsi veci protoze... proc? Protoze se nudili? 8))))

A kdyz jsme u toho "neco si precti", co kdyby sis prectel treba tvoji oblibeneou wikipedii?

The original PDP-11 version of Unix was developed in assembly language. The developers were considering rewriting the system using the B language, Thompson's simplified version of BCPL.[11] However B's inability to take advantage of some of the PDP-11's features, notably byte addressability, led to C. Doslova a do pismene, C vzniklo jako jazyk pro implementaci operacniho systemu. A to jsem si myslel, ze aspon o tom C neco vis. A pritom je to zase klasika: meles nesmysly o vecech, kterejm nerozumis a kdyz placnes pitomost, nejsi schopnej to priznat a jen se do toho zaplejtas dal a dal a dal...

A jako obvykle, velmi hlasite a usilove trapne mlceni o tech podstatnych otazkach. Hlavne to zamlzit a odskrolovat pitomostma o tom, jak C bylo na "praci s textem 8)))

REDGUY: ... dokonce i celého Unixu. nástroje pro tu práci s textem tehdy byly napsané v C, takže logicky, C mělo třeba silnější stringovou knihovnu, než co já vím - v té stejné éře Fortran. Něco si o tom přečti.

XCHAOS: v C je čárka , taky například operátor a ne nějaká základní konstrukce jazyka. - v C neni carka zakladni konstrukce jazyka? Operatory nejsou zakladni konstrukce C? Jo, od cloveka kterej si mysli, ze "práce s textem byla původní zaměření celého C" lze takovou pitomost ocekavat 8))

stejně jako ve funkcionálním jazyce všechno je funkce - ne, neni. Prosim, prestan placat o vecech, kterym nerozumis.

teď už zbývá jen začít - ver mi, nemuzu se dockat 8))) Nejakej casovej odhad? Ale kdybys predtim odpovedel na tech par otazek, co jsem tady napsal, bylo by to super. Rozumis, varianta "trapne mlceni" je nejnudnejsi mozna 8))

REDGUY: ty to hrozně hrotíš. instrukce je vlastně takový operátor bez návratového hodnoty ... šokující zjištění: v C je čárka , taky například operátor a ne nějaká základní konstrukce jazyka.

stejně jako ve funkcionálním jazyce všechno je funkce, tak je syntaxi jazyka možné poskládat čistě jen z operátorů :-) zápis by pak trochu připomínal regexpy (ne, že by pro mě byly srozumitelné, většina z nich... ale to mi nebrání snažit se vymyslet turing-complete regexpy :-))

ano, jistě metody zabudované, nativní třídy (jako string v Pythonu) jsou v jazyce jiná kategorie, než základní flow control struktury jazyka. na druhou stranu: a co jako? máš nějakou jinou motivaci sem psát, než snažit se dokazovat, že vše co napíšu je kravina?

ANT_39: já k tomu směřoval vždy.. vždy mi zajímalo, co je "uvnitř" programovacích jazyků... pochopit, co je uvnitř Basicu nebo C nebylo při znalosti základních instrukcí assembleru zas tak těžké, ale pochopit jak jsou implementované abstrakce vyšších jazyků je výzva (a hlavně soutěžení s nima, třeba co do výkonu).

stručně řečeno.. teď už zbývá jen začít

Hele, dalsi vec:

je to spíš zacílené na původní vývoj. třeba i jen hračkového kódu. nic velkého.
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

Co to znamena? Cim se lisi jazyk pro "hrackovy kod", "nic velkeho", "neco jen maleho" od jazyka pro "velke veci"? Protoze kdyz se podivam na ty skriptovaci jazyky, o kterych mluvis, tak ty moderni, rekneme Python, Ruby, Perl, Node.js nijak na "maly" veci omezeny nejsou. Muzu v nich stejne dobre psat oneliner, storadkovej one-off bastl i obrovskej web-scale projekt. S tim tedy, ze to "moderni" znamena vlastne "poslednich dvacet let". Takze, v cem bude omezenej tvuj jazyk? A hlavne... neni to tak trochu idiotske, uz od zacatku ho vedomne omezovat? Proc by do nej nekdo jakkoliv investovat cas a usili? Kdyz neco zacnu, ono se to ujme a budu to potrebovat vyrust z "neco maleho" na "neco velkeho", tak zjistim, ze jsem v hajzlu, protoze xChaos svuj jazyk navrhl jen na "male veci"? A neni tak trochu v rozporu tohle omezeni s tim, cos rikal o prinosu kompilovani do C? Ze ted si budu prekladat do PHP a pozdejc, az budu potrebovat vetsi vykon, tak do C? Neni nahodou dost pravdepodobny, ze okamzik "potrebuju kompilovat do C" prijde zhrube ve stejne dobe, jako okamzik "uz to neni hrackovy, maly projekt, ale neco vetsiho"? Povidej, vysvetluj 8))

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.