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

JANFROG: Njn. Ja si zase myslim, ze kdyz vidim nekoho placat blbosti, tak bych mu to proste mel napsat, at uz dojel na kole do Ciny nebo ne. Kazdej mame neco.

A btw, jestli si o me delas zavery na zaklade toho, co o me doslova nevis, tak nevim nevim. Rozumej, jestli si o me myslis, ze jsem curak, protoze jsem osklivej na XChaose, oukej, takovej nazor aspon vychazi z faktu. Ale jinak... no, delej, jak myslis 8)

REDGUY:
No kazdopadne se tesim, az ten projekt v nejaky funkcni podobe predstavis. Kdy tak zhruba to bude? 8))

At uz si o nekterych XCHAOSovych myslenkach myslim cokoliv, jedna vec se mu neda uprit: predstavil minimalne dva ambiciozni a realizovane projekty (web browser a solarni kolo). To je vic, nez jsi - alespon co me je znamo - ukazal Ty. Mohu se plest, samozrejme

Ja osobne si respektuji vice lidi kteri neco delaji byt treba ne skvele nez lidi, co jen hospodsky kritizuji a navazeji se do jinych byt sami nic nepredvedli a sedi coma na prdeli.

KEJML: tak zas tak ambiciózní to není, dnes jsou jazyky dost složitý, takže pořád jsou lidi, kteří jen primitivně skriptujou v shellu, což je overkill směrem na druhou stranu.

spíš mám po letech chuť něco naprogramovat. podle kámoše co dělá v PHPse dnes všechno píše spíš v node.js... ale cílem je přesně to,co jsem popsal: lidi mají někde PHPhosting a potřebujou to, co usmolej, hned deploynout. nicméně, když se budou učit to moje prostředí, tak jim paralelně vyjede i zdroják v C pro FastCGI, nebo (snad) i ten node.js

nebude to nic extra složitýho, spíš prostě webová platforma.. bindingy na mysql a čtení formulářů, apod...

XCHAOS: jednak se vyhnu lock-inu na jedne platforme (coz je nakonec i gcc, jakkoliv svobodne) - poslechnete, Kefalin, co vy si predstavujete pod takym "Lock-in na jedne platforme"? Protoze GCC je schopny generovat kod pro procesory od AVR pres x86 az po treba IBM mainframy. Ja tam ten "lock-in" nejak nevidim, tak se tesim, az mi to vysvetlis 8)

No kazdopadne se tesim, az ten projekt v nejaky funkcni podobe predstavis. Kdy tak zhruba to bude? 8))

XCHAOS: Když máš v klubu právo mazat, vidíš všechny, včetně ignorovaných, jinak bys nemohl zodpovědně zastávat moderátorskou roli.

XCHAOS: Jazyk, co se bude prodávat do několika jiných jazyků - velice ambiciózní projekt. Jakou si představuješ aplikaci v praxi? Takhle z fleku mne nenapadá situace, kdy bych si řekl, že přesně tohle bych potřeboval.

REDGUY: chtel bych treba napsat i neco jinyho, nez generator iptables... ale pokud te to opravdu vzdava, tak snahu o nejake zjednoduseni C asi pomalu vzdam a uvazuju ted spis o generatoru kodu pro vice platform (tedy definovat si vlastni primitivni jazyk, napsat jeho parser, a generovat z nej kod pro C, PHP, Python, atakdal).

Tahle cesta je zajimava z vice duvodu: jednak se vyhnu lock-inu na jedne platforme (coz je nakonec i gcc, jakkoliv svobodne), jednak umozni srovnat vykon ruznych platforem provadejicich fakticky to same, jednak jsou mozne budouci optimalizace dilcich targetu bez nutnosti prepisovat hromady zdrojaku... no a v neposledni rade, je jasne, ze treba nejake binarni fastcgi bude vzdycky provozovat jen par geeku, zatimco siroke masy si nainstalujou jen to, co jim bude chodit na PHP hostingu.

Takovy code generator, i kdyz asi bude natruc napsany v C (rychlost se u compileru snad porad jeste ceni), ovsem asi v tomhle klubu kupodivu bude offtopic.

SplitStacks - GCC Wiki
http://gcc.gnu.org/wiki/SplitStacks

tak jsem dospěl někam sem:
c - Print out value of stack pointer - Stack Overflow
https://stackoverflow.com/questions/20059673/print-out-value-of-stack-pointer

napadlo mi, že kdyby alokátor seskupoval alokace podle hodnoty stack pointeru v momentě alokace, tak by při prvním volání po návratu z funkce mohl nějak vyhodnotit, které položky může už zahodit - bylo by to překvapivě bezpečné i pro nestandardní způsoby opuštění funkce (longjmp). takovýto "pseudo garbage collection" by šlo iniciovat i mimo volání alokátoru, kdyby bylo potřeba, ale alokátory by ho volaly minimálně pokaždé, když by jim došla pre-alokovaná paměť...

v podstatě by šlo o to vždy označit kus heapu jako asociovaný s aktuální hodotou stack pointeru. přičemž odmazávat by se měla vždy především "poslední předchozí", dle logiky věci.. akorát mi tam hapruje, jak jí odlišit např. od předposlední, která ještě může být platná, pokud se v té poslední nealokovalo nic.

alokátory paměti by pak v podstatě pro běžný život stačily dva, zhruba ekvivalentní prastarým Basicovským levelům "local" a "global" (což mimochodem velmi dobře odpovídá C světu do sebe nevnořovaných funkcí). lokální alokátor by pak podle nejlepších C zvyklostí pro označování privátních a lokálních hodnot mohl začínat podtržítkem...

REDGUY: jak to že tě tady vidím, když tě už mám v ignore? :-(

jinak ano, zamýšlím se nad tím, googlím... a alloca() asi fakt nebude řešením pro moje pokusy o nějakou sadu zásad pro bezstarostné programování v C... ale více nebudu psát v odpovědi pro tebe.

XCHAOS:

man bash

a hledej ulimit, switch -s. A zamysli se nad organizaci pameti a tim, jake dusledky ma pro moznou velikost stacku 8))

ANT_39: no ale jak je to vůbec s velikostí stacku např. v Linuxu? to je tam pořád omezení na fixní limit jako kdysi v DOSu?

XCHAOS: S alloca a VLA je problem, ze pro prilis velky alokace se muzes snadno dostat mimo stack. Tusim v glibc a elfutils jsem normalne videl kod ve stylu if (x > a lot) malloc(x) else alloca(x) (a odpovidajici tomu free nebo nic). V linuxovym kernelu se dela na nahrade vsech pripadu alloca a VLA za alkoace na halde, mimo jine protoze ten stack overrun je potencialni bezpecnostni riziko.