Jaký programovací jazyk zvolit?

[tuxik svk]

Poslední dobou si náhodně dávám do céčka komentáře typu "Céčko je nejlepší, javaman je debil".

Pitomej Flanders!
Já myslím, že každej máme svýho "Flanderse".
Docela by mě zajímalo, co jiného jinak dělaáte, když (zrovna) neprogramátorujete?

Pasiem ovce a učim sa programovať v ČOBOLE

[Reklama]

[Tuxik]

Docela by mě zajímalo, co jiného jinak dělaáte, když (zrovna) neprogramátorujete?

V práci jsem obyčejnej systémáček, kterej rád ví, s čím má tu čest a doma jsem obyčejnej táta. Jinak mě to vždycky táhlo trošku do hloubky problémů, jako malý javameně mě vždy po chvíli začalo víc zajímat, jak se taková hra dělá, než jak se hraje a z toho vznikla záliba v programování, nicméně jsem díky brzkým zkušenostem pochopil, že nechci být programátor na full time, protože jsem nezvládl tupě implementovat nesmysly, který si někdo vymyslí. Jinak jsem měl to veliké štěstí projít si několika málo firmami, ve kterých jsem (obzvlášť v jedné) zdědil i některá velmi kreativní díla svých předchůdců a ty bylo občas potřeba upravit/opravit. Někdy je až zábavné, jak může existovat složitý postup, který se celé roky používá, najednou se k tomu dostane někdo z IT, který musí něco udělat, napíše si na to vlastní program/skript, protože je prostě línej, někdo jej u toho nachytá, rozšíří to dál a za rok najednou nikdo neví, jak se to vlastně dělalo dřív a nikdo si to bez toho prográmku už nedokáže představit. Takto vzniká typický podnikový bastl nějakýho Franty, který tam před lety pracoval a zanechal tam touto formou svoji "stopu"

[JSH]

Významného zkrácení metod jsem docílil, když jsem přestal používat větve "else".

Neměl bys nějaký ukázkový příklad s else a bez něj? Takhle to zní dost podezřele.

[Tuxik]

Významného zkrácení metod jsem docílil, když jsem přestal používat větve "else".

Neměl bys nějaký ukázkový příklad s else a bez něj? Takhle to zní dost podezřele.

Taky by mě to celkem zajímalo. Dokážu si představit v IFu return a potom bez else, to co by bylo v else. Ale záleží na tom, jestli si ten return v tom IFu můžu na konkrétním místě dovolit a i když můžu, použitím else se mi ve zdrojáku dostanou krásně logicky dvě větve na stejnou úroveň ve struktuře a připadne mi to přehlednější. Na zkompilovaný výsledek by to podle mě nemělo mít žádný zásadní vliv, pokud kompilátor umí alespoň trochu optimalizovat. A nevím, jestli mi to stojí za těch pár řádků. Ale to je spíš o zvyku.

[Kit]

Významného zkrácení metod jsem docílil, když jsem přestal používat větve "else".

Neměl bys nějaký ukázkový příklad s else a bez něj? Takhle to zní dost podezřele.

Taky by mě to celkem zajímalo. Dokážu si představit v IFu return a potom bez else, to co by bylo v else. Ale záleží na tom, jestli si ten return v tom IFu můžu na konkrétním místě dovolit a i když můžu, použitím else se mi ve zdrojáku dostanou krásně logicky dvě větve na stejnou úroveň ve struktuře a připadne mi to přehlednější. Na zkompilovaný výsledek by to podle mě nemělo mít žádný zásadní vliv, pokud kompilátor umí alespoň trochu optimalizovat. A nevím, jestli mi to stojí za těch pár řádků. Ale to je spíš o zvyku.

V podstatě jsi to vystihl - v ifu return nebo throw. S tím rozdílem, že obvykle ty větve přehodím. Nejprve se zbavím chybových stavů a na konci je požadovaná akce. Je to vlastně explicitní líné vyhodnocování.

V některých případech tě to může donutit rozdělit metodu, takže se zároveň zbavíš dlouhých metod a docílíš toho, že metoda bude dělat jen jednu věc a pořádně.

Pokud tu větev else přece jen z nějakého důvodu potřebuji, tak tam zpravidla patří ternární operátor.

Na zkompilovaný výsledek by to nemělo mít zásadní vliv. Jde především o čitelnost zdrojáku.

[Reklama]

[Tuxik]

V podstatě jsi to vystihl - v ifu return nebo throw. S tím rozdílem, že obvykle ty větve přehodím. Nejprve se zbavím chybových stavů a na konci je požadovaná akce. Je to vlastně explicitní líné vyhodnocování.

V některých případech tě to může donutit rozdělit metodu, takže se zároveň zbavíš dlouhých metod a docílíš toho, že metoda bude dělat jen jednu věc a pořádně.

Pokud tu větev else přece jen z nějakého důvodu potřebuji, tak tam zpravidla patří ternární operátor.

Na zkompilovaný výsledek by to nemělo mít zásadní vliv. Jde především o čitelnost zdrojáku.

No zrovna ternární operátory podle mě moc čitelnosti kódu neprospívají, ale zkrátit kód se tím dá, to zase jo. Ale jak říkám pořád, programování je hodně o návycích, pokud člověka do něčeho netlačí místní konvence, dělá si to tak nějak jak se mu to líbí. Potom jsou z toho krásné hádky, kdo ho má většího, protože to každej dělá nejlíp

Mimochodem, sháním nějakou inspiraci, co si naprogramovat v Cčku, klidně nějakou konzolovou kravinku. Poslední dobou Cčko moc nepoužívám, takže občas vymyslím něco pro zábavu, naposledy to byl "řešič sudoku" Ideální je něco, co se dá snadno udělat a potom se dá pustit do různých optimalizací.

[Kit]

Pokud tu větev else přece jen z nějakého důvodu potřebuji, tak tam zpravidla patří ternární operátor.

No zrovna ternární operátory podle mě moc čitelnosti kódu neprospívají, ale zkrátit kód se tím dá, to zase jo. Ale jak říkám pořád, programování je hodně o návycích, pokud člověka do něčeho netlačí místní konvence, dělá si to tak nějak jak se mu to líbí. Potom jsou z toho krásné hádky, kdo ho má většího, protože to každej dělá nejlíp

V Cčku je ta situace trochu jiná, ale v OO jazycích moc jiných možností není, než právě ternární operátor. Musel bys deklaraci proměnné oddělit od definice její hodnoty. Tomu se cíleně vyhýbám.

[D3ad]

Povídej. Za mne je to omezení délky řádku na 120 znaků. Mně stačí 80 a ještě s rezervou. Možná to souvisí s délkou názvů identifikátorů, kde Bob doporučuje slepeninu z více slov. Je to dáno vlastnostmi germánských jazyků. Obvykle si však vystačím s jedním slovem. Samozřejmě bez zkratek.

Největší problém mám s 20ti řádky na metodu. Vim o tom, že občas i zbytečně něco rozepisuju na víc řádků, když se mi to zdá přehlednější a občas to prostě tak nějak vyplyne samo a nechce se mi dělit něco, co k sobě logicky patří a co považuji za jeden krok, na víc částí. I ty komentáře jsou občas sporný, osobně je používám tam, kde jsem musel něco moc vymýšlet a vím, že za chvíli nebudu vědět, proč jsem to tak udělal. Mám tím potom krásně označená místa, kde jsem to dělal moc složitě a je to dobrý začátek při případném refaktoringu Poslední dobou si náhodně dávám do céčka komentáře typu "Céčko je nejlepší, javaman je debil".

Tak s tímto pravidlem bych si hlavu nelámal, zejména pokud účelně výrazy rozděluješ na více řádek. Také to tak dělám. Když metoda vyjde na 30 řádek, tak je to stále OK, to číslo je prostě "měkké". Pokud se ti nějaká metoda jeví dlouhá, vyber si z ní nějaký scope, zamysli se nad významem, pojmenuj a udělej z toho privátní metodu. Typickými kandidáty jsou cykly a případně i switche. Ovšem i třířádková inicializace nějakého buttonu či panelu si koleduje o nějakou příhodnou tovární metodu, která se dá velmi dobře recyklovat. Významného zkrácení metod jsem docílil, když jsem přestal používat větve "else".

Dost věcí se dá vyhodit z konstruktoru a umístit do deklarace atributů. Typicky inicializace interních objektů a kolekcí. Vlastně cokoli, co není závislé na parametrech konstruktoru.

Ono taky zalezi co delas za projekt. Pokud vyvijis nejaky informacni system tak ano, je to dobra vec, kod je prehlednejsi, udrzovatelnejsi. Pokud ale delas embedded systemy nebo realtime systemy tak radeji hodim par radku navic do funkce/metody protoze usetrim celkem dost instrukci pri volani funkce/metody. Kazda kapka vykonu dobra. Pri delani unit testu v C++ na jeden realtimovy system jsem potreboval volat odmocninu klidne i 200x za sekundu. Tak jsem tam nacpal inline assembler a ejhle, hned to bylo nekolikrat rychlejsi. -O3 flag pro prekladac jsem si nemohl dovolit, protoze ten ma ve zvyku vyhazovat kontroly na NULL. Takto jsem usetril zbytek testu od nebezpecnych optimalizacnich tendenci prekladace a zaroven usetril bambilion instrukci na volani funkce a kontrol ohledne odmocniny. Samotny vypocet byl na 1 instrukci a 2 instrukce bylo nahrani hodnot z pameti do registru a pak naopak.

[Tuxik]

Ono taky zalezi co delas za projekt. Pokud vyvijis nejaky informacni system tak ano, je to dobra vec, kod je prehlednejsi, udrzovatelnejsi. Pokud ale delas embedded systemy nebo realtime systemy tak radeji hodim par radku navic do funkce/metody protoze usetrim celkem dost instrukci pri volani funkce/metody. Kazda kapka vykonu dobra. Pri delani unit testu v C++ na jeden realtimovy system jsem potreboval volat odmocninu klidne i 200x za sekundu. Tak jsem tam nacpal inline assembler a ejhle, hned to bylo nekolikrat rychlejsi. -O3 flag pro prekladac jsem si nemohl dovolit, protoze ten ma ve zvyku vyhazovat kontroly na NULL. Takto jsem usetril zbytek testu od nebezpecnych optimalizacnich tendenci prekladace a zaroven usetril bambilion instrukci na volani funkce a kontrol ohledne odmocniny. Samotny vypocet byl na 1 instrukci a 2 instrukce bylo nahrani hodnot z pameti do registru a pak naopak.

Můžu se jen zeptat, co to bylo za systém? Podle úrovně optimalizace bych očekával něco malýho, na druhou stranu, pokud je odmocnina jedna instrukce, tak to musí mít FPU, tak mě zajímá, jestli je něco bastlířského, co se dá použít i na rychlejší výpočty, nebo to byl nějakej relativně velkej CPU a šlo jen o rychlost toho realtimu?

[Kit]

Ono taky zalezi co delas za projekt. Pokud vyvijis nejaky informacni system tak ano, je to dobra vec, kod je prehlednejsi, udrzovatelnejsi. Pokud ale delas embedded systemy nebo realtime systemy tak radeji hodim par radku navic do funkce/metody protoze usetrim celkem dost instrukci pri volani funkce/metody. Kazda kapka vykonu dobra. Pri delani unit testu v C++ na jeden realtimovy system jsem potreboval volat odmocninu klidne i 200x za sekundu. Tak jsem tam nacpal inline assembler a ejhle, hned to bylo nekolikrat rychlejsi. -O3 flag pro prekladac jsem si nemohl dovolit, protoze ten ma ve zvyku vyhazovat kontroly na NULL. Takto jsem usetril zbytek testu od nebezpecnych optimalizacnich tendenci prekladace a zaroven usetril bambilion instrukci na volani funkce a kontrol ohledne odmocniny. Samotny vypocet byl na 1 instrukci a 2 instrukce bylo nahrani hodnot z pameti do registru a pak naopak.

Dělám hlavně v objektových jazycích, ve kterých jsou trochu jiné zvyklosti a mé postupy vedou sekundárně k jistému zefektivnění a zrychlení výpočtu v rámci OOP. Navíc objektové jazyky běžně optimalizují privátní metody tak, že je expandují jako makro - obejde se to bez zmíněného náročného volání. Je to hezky vidět u privátních getterů/setterů, které se v benchmarku chovají, jako kdybys pracoval přímo s daným atributem.

Ve tvém případě bych se asi snažil odmocňování nahradit násobením, které je podstatně rychlejší. Jistě, nejde to vždy, ale například pro hledání minimální či maximální vzdálenosti je to perfektní.

[gamer]

-O3 flag pro prekladac jsem si nemohl dovolit, protoze ten ma ve zvyku vyhazovat kontroly na NULL. Takto jsem usetril zbytek testu od nebezpecnych optimalizacnich tendenci prekladace

O3 nedělá nic nebezpečného ani nestandardního, kontroly na NULL vyhazuje až _PO_ dereferenci pointeru. Pokud program nefungoval s O3, tak byl vadný a že fungoval s jiným levelem optimalizací, byla jen náhoda. Takový program je potřeba opravit a ne vypínat O3.

[D3ad]

Ono taky zalezi co delas za projekt. Pokud vyvijis nejaky informacni system tak ano, je to dobra vec, kod je prehlednejsi, udrzovatelnejsi. Pokud ale delas embedded systemy nebo realtime systemy tak radeji hodim par radku navic do funkce/metody protoze usetrim celkem dost instrukci pri volani funkce/metody. Kazda kapka vykonu dobra. Pri delani unit testu v C++ na jeden realtimovy system jsem potreboval volat odmocninu klidne i 200x za sekundu. Tak jsem tam nacpal inline assembler a ejhle, hned to bylo nekolikrat rychlejsi. -O3 flag pro prekladac jsem si nemohl dovolit, protoze ten ma ve zvyku vyhazovat kontroly na NULL. Takto jsem usetril zbytek testu od nebezpecnych optimalizacnich tendenci prekladace a zaroven usetril bambilion instrukci na volani funkce a kontrol ohledne odmocniny. Samotny vypocet byl na 1 instrukci a 2 instrukce bylo nahrani hodnot z pameti do registru a pak naopak.

Můžu se jen zeptat, co to bylo za systém? Podle úrovně optimalizace bych očekával něco malýho, na druhou stranu, pokud je odmocnina jedna instrukce, tak to musí mít FPU, tak mě zajímá, jestli je něco bastlířského, co se dá použít i na rychlejší výpočty, nebo to byl nějakej relativně velkej CPU a šlo jen o rychlost toho realtimu?

Slo pouze o rychlost toho realtimu.

@Kit: Jednalo se o prepocet souradnic z WGS84 na polarni souradnice vuci bodu na mape.

@Gamer: To ze je neco standartni neznamena, ze to je bezpecne. Treba takovy Firefox po prelozeni s -O3 pada jako jablka na podzim. Tohleto se v realtimovem systemu nemuze stat. Preloz si Gentoo s -O3, bude to jeste mene stabilni nez emo patnactka na kokainu.

[gamer]

@Gamer: To ze je neco standartni neznamena, ze to je bezpecne. Treba takovy Firefox po prelozeni s -O3 pada jako jablka na podzim. Tohleto se v realtimovem systemu nemuze stat. Preloz si Gentoo s -O3, bude to jeste mene stabilni nez emo patnactka na kokainu.

Samozřejmě že to není bezpečné, když je ten program napsaný blbě. To je ale chyba programu, ne překladače. Je potřeba opravit program, protože funguje jen náhodou. S jiným překladačem nebo jeho jinou verzí to může klidně začít padat.

Jestli provozujete realtime systém, který s O3 padá (a není to chyba překladače, což se taky může stát, nicméně je to nepravděpodobné), tak to o nečem svědčí...

[Kit]

@Gamer: To ze je neco standartni neznamena, ze to je bezpecne. Treba takovy Firefox po prelozeni s -O3 pada jako jablka na podzim. Tohleto se v realtimovem systemu nemuze stat. Preloz si Gentoo s -O3, bude to jeste mene stabilni nez emo patnactka na kokainu.

Samozřejmě že to není bezpečné, když je ten program napsaný blbě. To je ale chyba programu, ne překladače. Je potřeba opravit program, protože funguje jen náhodou. S jiným překladačem nebo jeho jinou verzí to může klidně začít padat.

Jestli provozujete realtime systém, který s O3 padá (a není to chyba překladače, což se taky může stát, nicméně je to nepravděpodobné), tak to o nečem svědčí...

Na tohle se dobře hodí návrhový vzor NullObject. Kontroly se pak dají v klidu vyhodit.

[D3ad]

Samozřejmě že to není bezpečné, když je ten program napsaný blbě. To je ale chyba programu, ne překladače. Je potřeba opravit program, protože funguje jen náhodou. S jiným překladačem nebo jeho jinou verzí to může klidně začít padat.

Jestli provozujete realtime systém, který s O3 padá (a není to chyba překladače, což se taky může stát, nicméně je to nepravděpodobné), tak to o nečem svědčí...

Kde jsi prisel na to, ze to pri O3 pada? Cim vetsi level optimalizace, tim vetsi riziko bugu prekladace. Radeji pouziju O2 a nejake bottlenecky vyresim rucne, viz. odmocnina, nez riskovat, ze si prekladac zablbne a shodi to.
Cokoliv co ma mensi pravdepodobnost uspechu nez 100% je nepripustne.