DAVIDOWITCH: tohle ale není soukromá pošta, to je diskuzní klub. tak nějak se očekává, že to je skupinová debata, a ne sada "veřejných dvoustranných konverzací"...

REDGUY: zrovna věc, běžící v podstatě jako skript na pozadí, bych dnes asi přeci jen psal v Pythonu. ale zrovna třeba webové rozhraní se víc a víc víc blíží k tomu stát se real-time GUI (což tak rozhodně původně nebylo zamýšleno) a tedy na webové serverové aplikace jsou dnes kladeny naprosto jiné nároky, než v počátcích webu (jak co se týče množství requestů, tak i požadavků na rychlost jejich vyřízení)

XCHAOS: Mne je celkem burta co dela REDGUY, s tim dialog nevedu.

REDGUY: co je to zase zase strawman fallacy, tohle? proč myslíš, že nechápu rozdíl mezi (dynamicky typovanými!) referencemi na objekty v Pythonu a primitivními datovými typy v C? já jsem si dokonce prošel zdrojáky Python interpreteru (ten je samozřejmě implementovaný v C), protože mě zajímalo, jak jsou implementovaný Python pole :-)

PIGSTER: no, v podstatě ano. v podstatě ale i ty struktury v C jsou jen syntaktickej cukr na pointerovou aritmetikou :-) každá členská proměnná struktury je vlastně jen offset přičítaný k pointeru na strukturu.

(A přesně kvůli takovýmhle věcem C představuje past na programátory postižený analytickým myšlením :-) protože je to prostě strašně návykové, začít uvažovat takhle redukcionisticky :-)

XCHAOS: Komplikuje, nekomplikuje... problem je, ze nechapes rozdil mezi pythonem a ceckem. Cecko je jednoduchej, low level nastroj, glorifikovanej assembler urcenej na low level praci, kdy potrebujes mit velmi presnou kontrolu nad tim co se deje. Podivovat se nad tim, ze neposkytuje podporu pro nejake high level konstrukce je proste pitomost a nepochopeni toho k cemu je urcene. Pro kazdou praci pouzivej takovy nastroj, ktery se pro ni hodi. Pises device driver? Napis ho v C. Pises generator konfiguracnich souboru pro iptables? Napis ho v pythonu/perlu/ruby/jinem high-level jazyce. Jestli to delas obracene, delas to blbe.

A ano, vim ze se C siroce pouziva i pro jine veci nez lowlevel praci. Coz na veci nic nemeni, viz http://www.jwz.org/doc/worse-is-better.html .

DAVIDOWITCH: ...a on se tu např. REDGUY někdy snažil sdělit něco jiného, než "i přesto mám pravdu"? :-)

TENCOKACISTROMY: bavíš se o C? tak to chci fakt vidět, ten typedef na pole známé délky :-)

(jasně.. jestli myslíš, že budu pracovat s něčím jako pole->val[n] a pole->len ... ale to je pak právě tak "nativní" jako ty polymorfní objekty... a navíc je to ještě ošklivé)

REDGUY: tak to musíš uznat i ty, že třeba proti Pythonu apod. se tím situace dost komplikuje. A v podstatě to lze chápat tak, že "C nemá nativní podporu pro pole předem známé délky" (když budu fakt přísný :-)

a mj. většina prog. jazyků, které se snaží dál rozvíjet C (C++, D, apod.) se snaží k tomutu problému nějak postavit....

ISTEVE: Nejez to...

TENCOKACISTROMY: A tuhle myslenku bych mozna rozvedl dal... co kdyz podobnej problem ma vic lidi? nebylo by uzasny, kdyz by treba existovala standardni technologie kterej tenhle problem resi pro vic nez jen pro jeden projekt?

...ale to asi jen snim...

REDGUY: Jak by byl problem na to pouzit/si vytvorit patricny typ.

ANT_39: XChaos ma zasadni problem s tim, ze u Cckoveho pole neni dostupna jeho delka, takze (napr.) kdyz si ho poruznu predavas po programu, musis ji predat jako extra parametr. A tim se vsechno strasne komplikuje, nebo tak neco.

XCHAOS: Co je to za druh pole, ze na nej for nestaci? Predstavuju si, ze nacpat do toho treba pruchod stromem by byla vyzva, ale pro pole a seznamy by to nemel byt problem, ne?

XCHAOS: Ja sem naprosto nepochopil co se pokousis rict, krom obligatniho "i presto mam pravdu".

REDGUY: Uz je to davno. V DOSu. On v nicem jinym neprogramoval. Az pak se naucil cecko.

ADAMJ: Jako mentalni cviceni nebo z nutnosti? Na jaky platforme?

TENCOKACISTROMY: GUI realizovany dle paradigmatu OOP, ale implementovany v assembleru.