Názory k článku
Algoritmus Fractal Flame prakticky

je tu este nekto kto povazuje ten C++ zapis za ohyzdny?

Jde o princip. Si to muzes predelat.

preto je to off topic, nemyslel som tym nic zle.

V pohode, ja jsem to tak pochopil. Je pravda, ze i do ceckovych zdrojaku se mi posledni dobou zacinaji plest idiomy z jinych programovacich jazyku a treba zpusob psani identifikatoru (velka pismena na zacatcich slov vs. podtrzitka) opravdu moc ceckova nejsou.

Ono je to ciste Cecko, nelibi se Vam indentace nebo zdrojak jako takovy? Rad se necham poucit, uznavam, ze uz jsem lehce "riznuty" jinymi programovacimi jazyky a v Cecku toho napisu uz malo (ale v minulosti to byly tisice radku).

nie, indentacia je OK (aj v C by sa nasli divne sposoby) priklad:

//-----------------------------------------------------------------------------
// Přírůstek barvy pixelu na zadaných souřadnicích ve floatové monochromatické
// pixmapě
//-----------------------------------------------------------------------------
void addfloat(const unsigned int x, const unsigned int y)
{
    // kontrola, zda není překročena velikost pixmapy
    // (záporné hodnoty není díky převodu na unsigned int zapotřebí
    //  brát v potaz)
    if (x>=PIXMAP_WIDTH || y>=PIXMAP_HEIGHT) return;
    // zvýšit hodnotu čítače
    floatMap[y][x]++;
}

a

/*
 * Přírůstek barvy pixelu na zadaných souřadnicích ve floatové monochromatické
 * pixmapě
 */ 
void add_float(const unsigned int x, const unsigned int y)
{
    /* kontrola, zda není překročena velikost pixmapy
       (záporné hodnoty není díky převodu na unsigned int zapotřebí
       brát v potaz)
     */
    if ( x >= PIXMAP_WIDTH || y >= PIXMAP_HEIGHT )
        return;

    /* zvýšit hodnotu čítače */
    ++float_map[y][x];
}

su to detaily ako styl poznamok, styl vytvarania nazvov a pod. mne sa zda ten druhy sposob citatelnejsi...

Pokusim se osvetlit, proc pouzivam ty "C++" poznamky (ve skutecnosti jsou vsak i v novejsich normach Cecka, tj. jejich pouziti je dnes na 100% validni). Je to z toho duvodu, ze poznamky // maji pri zpracovani preprocesorem "nizsi prioritu", nez poznamky /* a */. Proto komentare ke kodu pisu s // a pokud si nejakou vetsi cast potrebuji rychle zakomentovat, pouziju /* a */, misto toho abych musel psat #if 0 a #endif (coz je v podstate to same, oboje zpracuje preprocesor).

Opet je to dusledek toho, ze musim pracovat v dalsich nejmenovanych jazycich, ktere preprocesor nemaji a tvurci techto jazyku tvrdi, ze je zbytecny (takze pekne kecaji a nevi o cem mluvi, nebo -a to je mnohem horsi- nam lzou).

Jinak vcelku souhlas, ty mezery pred a za operatorem jsou na delsi debatu a zalezi na zvolene stabni kulture (ktera vam po delsi dobe zaleze pod kuzi), stejne tak jako pouziti prefixoveho ci postfixoveho ++.

Jeste me napadlo, ze pridani jednoradkovych poznamek uvozenych // prineslo do jazyka nekompatibilitu se starsimi zdrojaky (ty nepujdou na novejsich prekladacich prelozit), ale to je opravdu veci tvurbu normy; ta sance, ze se na takovy zdrojak narazi, je miziva.

viem ze su v novsich normach, ale v podstate sa nepouzivaju :)

rozumiem tomu dovodu, ja tiez pouzijem niekedy, ale iba v docasnom kode. a ten prefixovy ++ som dal z dovodu citatelnosti, zdalo sa mi, ze sa to za tymi zatvorkami trochu straca :) vlastne vsetky upravy co som spravil su (zda sa) len z dovodu lepsej citatelnosti.

Priznam se, ze mam stesti, ze me nikdo nenuti psat ++ prefixove, protoze se mi to nejak nelibi :-) a tam, kde nemusim (tj. v tech nekolika pripadech, kde se prefixova a postfixova forma funkcne odlisuje), to pisu radeji postfixove. Ostatne i ve Vasi ukazce jsou vetsinou pouzity postfixove formy, ale tady se (v mem pripade) opravdu jedna o dlouholety navyk, ktery se obtizne meni :-)

Hlavicky funkci jsou OK? Nekteri lide maji nazor, ze je vyhodnejsi psat hlavicky v GNU stylu, ale me to tedy moc prehledne nepripada, radeji vsechno nechavam na jednom radku, popr. rozepisu parametry na vic radku.

hlavicky v GNU style su malickost. zda sa mi, ze je to lepsie, vedel by som si na to zvyknut, ale nejak mi to nestoji za to :)

No, me by to vadilo, protoze pouzivam folding ve Vimu a tam by mi ty navratove hodnoty na samostatnem radku zbytecne visely.

Jeste k tem poznamkam: muj zitrejsi clanek uz bude obsahovat poznamky v old-c-style, tj. /* a */ misto //. Jeste, ze na prevod je mozne napsat jednoduche makro (nepouzil jsem tu jednu vyjimku, kdy novy styl poznamek starsi kod poskodi).

Ktery nejmenovany jazyk - python? ja myslim, ze ho opravdu nepotrebuje.

Python ho opravdu nepotrebuje, myslel jsem ten vytvor od Sunu :-) btw, ve ktere firme se ve vetsim pouziva Python? U nas se preferuje Java protoze ... no, ma dobre jmeno i pro manazery :-)

aha, Self ;-)

Nazdar Pavle!

uz ses blizko - ze Selfu byl odvozen (resp. hodne se jim inspiroval) jeden znamy a pouzivany skriptovaci dynamicky typovany jazyk, ktery byl pozdeji prejmenovan. A prvni ctyri pismena tohoto prejmenovaneho jazyka jsou tim hledanym nazvem (ovsem jazyka kompilovaneho a staticky typovaneho, takze nic pro Tebe :-)))

Já myslel že ten jazyk se původně jmenoval LiveWire a až časem evolučně doputoval k voňavému nápoji... ;-)

Ahoj, je to ještě horší. Já už jsem bytostně srostl s image konceptem. Takže třeba u výše nejmenovaného dynamického scriptovacího jazyka mě děsně deptá, že pro něj není k dispozici inkrementální exploratorní prostředí pokud možno i s nějakým hezkým outlinerem :-) Pokud se pletu, tak mě, prosím, někdo opravte, budu vám neskonale vděčen ;-) Totéž Lisp, Python, Ruby, CLOS...

Teda ja o nicem podobnem nevim, budes asi muset zustat u Squeaku :-( Teda mam dojem, ze pro Lisp neco spachala IBM, ale tato firma je expert na pohrbivani svych nejlepsich produktu, takze nic blizsiho nevim.

Ale je to Tvoje chyba, kazdy kdo chvili pouziva Smalltalk potom pri praci s jinymi jazyky trpi :-)))

Naštěstí mě Squeak/VisualWorks/Seaside uživí, ale když jsem nucen šáhnout příležitostně jinam, tak teče krev :-)

Paradoxně se v poslední době ve vývoji Squeaku zaměřuju na jeho modularizaci a separování jádra. Víceméně něco jako jeho částečnou (cizinec promine) degradaci na úroveň jazyků jako Ruby nebo Python. Brouzdat v image a hledat a likvidovat zapomenuté objekty jenom s textovou konzolí, to je zážitek :-)

Ale cekem se daří, už se mi podařilo vyčlenit nezbytné jádro a celkem ho pročistit, dokážu do něj nahrát funkční Seaside a dokonce se mi podařilo o víkendu vytvořit balíček, který do jaderné image nahraje celý zbytek Squeaku a rozjede funkční Morphic (na což nadšeně reagoval i samotný Alan ;-).

Takže brzo jedna z hlavních výtek Squeaku snad padne...

Cau Pavle,

to me tesi, ze se praci ve Smalltalku uzivis. Ja ted musim pouzivat ten nejmenovany mainstreamovy jazyk a zrovna pro nase ulohy (intranetove aplikace) se staticky typovany jazyk vubec nehodi - uz jenom z toho duvodu, ze mnoho metod aplikacniho serveru pracuje s typem Object, takze nejaka staticka typovost jde vis kam :-)))

Na Squeak lidi dost nadavali kvuli tomu, ze je to moloch a nejenom kvuli nedelitelnosti jadra, ale take napr. ze GUI je uplne nezavisle na hostujicim OS apod. To je na jednu stranu vyhoda, ale BFUcka to IMHO nepotesi.