Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - eMko

Stran: 1 ... 9 10 [11] 12 13 ... 31
151
Software / Re:Personalizace editoru VIM
« kdy: 12. 05. 2014, 22:07:24 »
Při studiu jsem si taky myslel, že nic horšího být nemůže. Pak jsem se začal zajímat m.j. i o jazyky Clojure a Common Lisp a začal jsem se učit Emacs. Od té doby mi vim připadá snadný... :-)

Kdysi jsem používal omnicompletion když jsem potřeboval psát skripty v Perlu, jinak si vždy vystačím s čistou instalací.

152
Vývoj / Re:Jsou Java generics opravdu špatné?
« kdy: 12. 05. 2014, 12:16:56 »
JIT virtuální metody taky AFAIK neoptimalizuje.

153
Vývoj / Re:Jsou Java generics opravdu špatné?
« kdy: 12. 05. 2014, 07:10:32 »
Ten ale nedokáže provést inline optimalizaci u virtuálních metod.

"Rozhodně to nedělat" bych rozhodně neříkal - spíš "dělat co nejméně, tam, kde to má smysl".

Stejně tak kód, který se dobře čte - to často znamená krátký kód.

154
Vývoj / Re:Rekurze v imperativních jazycích
« kdy: 08. 05. 2014, 07:11:29 »
Nic proti nikomu, ale programoval ten borec v C++?
Znam par lidi, co dle jejich slov programuji v C++, ale pritom je to C se special structama se jmenem "class", co obsahuje funkce a dokonce jista navesti public a private, ktera maji specialni vyznam. A abych nezapomel, misto malloc a free se pouzivaji new a delete.

Byl to přesně takový typ. C++ = C wrapped in classes.

155
Vývoj / Re:Rekurze v imperativních jazycích
« kdy: 07. 05. 2014, 17:47:13 »
Mě se jeden ostřílený borec zeptal co je "unique_ptr" v C++ - po odpovědi "náhrada za auto_ptr" se zeptal "co je to auto_ptr". Místo, aby si všiml, že před 14 lety přibyla šablona auto_ptr do standardní knihovny jazyka, raději řešil memory leaky a bordel na haldě. Podobný dotaz položil k výrazu "builder pattern".

Mám to snad po vzoru Karla také tak debilně generalizovat na větu:

Já zas vidím spoustu ostřílených zkušených borců, co díky všemožným asemblerům, Cčkům, Pascalům a Fortranům nezvládají základní objektové návrhové vzory, C# po nich vypadá jako brainfuck (teda sorry, COBOL) a díky ignoraci nových věcí v základní knihovně jejich hlavního jazyka nezvládají základní práci s pamětí?

156
Vývoj / Re:Eclipse a sdílení workspaces a projektů
« kdy: 06. 05. 2014, 06:52:58 »
.metadata prostě nesdílet - to je nejlepší řešení.

Prostě použij externí systém na správu projektů (maven, gradle, leiningen, sbt ... k výběru je jich hromada). Pokud to není možné, tak eclipse umí vygenerovat ant skript. Pak na jiném počítači stačí stáhnout projekt a naimportovat do eclipse či jiného vývojového prostředí.

Tímto se vyřeší i situace, kdy část týmu používá jiné vývojové prostředí.


157
Vývoj / Re:Rekurze v imperativních jazycích
« kdy: 05. 05. 2014, 18:36:39 »
Ona ta tail optimalizace není zadarmo, daná metoda musí splňovat určité požadavky [...]

Což vyplývá z definice "tail call optimization" - optimalizuje se pouze poslední výraz.

Rekurze s akumulátorem je možná o trochu méně elegantní, ale zrovna v tomto případě stále lépe čitelná než imperativní přístup se změnou hodnot proměnných v cyklu.

158
Desktop / Re:KDE
« kdy: 04. 05. 2014, 12:43:37 »
Lubuntu LTS má bohužel jen 3 roky, na rozdíl od Ubuntu. Každopádně i to je celkem dost na linuxové distro :) .

159
Desktop / Re:KDE
« kdy: 04. 05. 2014, 11:56:14 »
se [...] omlovám jestli se ptám na uplnou blbost.

Nejblbější otázky jsou takové, které nebyly vysloveny :-) .

Pro začátečníka nejjednodušší řešení si myslím bude stáhnout instalačku lubuntu (www.lubuntu.net - chceš-li klon Ubuntu, čehož bych se doporučil držet - přeci jen je to nejrozšířenější distribuce v současné době a nejsnáze se bude získávat podpora) a nainstalovat systém znovu.

Citace: http://lubuntu.net/
A Pentium II or Celeron system with 128 MB of RAM is probably a bottom-line configuration that may yield slow yet usable system with a standard lubuntu desktop.

z čehož vyplývá, že s 512 MB RAM bys měl být OK, pokud nebudeš mít spuštěný Firefox s 10 pluginama a otevřených 25 záložek s flashovýma stránkama. KDE je super prostředí, bohužel je dost paměťově nenažrané a Gnome mu šlape na paty.

Pokud budeš váhat jakou verzi stáhnout, tak silně doporučuji tu, která je založená na nějaké LTS verzi (např. "based on Ubutnu 14.04 LTS"). LTS znamená Long Term Support, tedy prodlouženou podporu (3 roky) a stabilnější software.

160
Vývoj / Re:Rekurze v imperativních jazycích
« kdy: 04. 05. 2014, 10:32:36 »
Clojure má konstrukci loop-recur (případně se používá trampoline) právě pro to, že JVM neumožňuje tail-call optimalizaci. Na druhou straunu překladač Scaly, která taky běží nad JVM, to "umí" - tím, že z toho udělá cyklus.

Jestli je to možné u C# 5, to se přiznám, že nevím - překladač verze 4 to neumí byť .Net to podporuje. C/C++ u novějších překladačů (jak Microsoft tak GCC) to umí a nedávno jsem to viděl i u free pascalu. Nicméně často se musí explicitně zapnout.

Každopádně i když rekurze je ve funkcionálních (a logických) jazycích celkem často k vidění, v imperativních jazycích není až tak potřeba - stejně je většinou pohodlnější tu danou věc zapsat cyklem než rekurzí.

161
Vývoj / Re:Konzolové C++ IDE
« kdy: 30. 04. 2014, 15:08:38 »
Nová věc nerovná se nová technologie. Před nedávnem pro mě byl emacs také nová věc, byť byl původně vytvořen v r. 1972, tedy je o trochu starší než já.

Nicméně plně souhlasím s tvrzením, že pokud se ajťák stále neučí pro něj nové věci, je to špatně.

162
Vývoj / Re:Hledání chyb v uzavřeném software
« kdy: 30. 04. 2014, 15:04:53 »
Přijít na mnoho chyb se dá i bez přístupu ke zdrojákům.

Kromě toho zdrojáky různých uzavřených programů jsou často dostupné, některé lépe, některé hůře. Vzpomínám si, že jsme s kolegou před pár lety prohlíželi zdroják .Net frameworku když se nám nezdálo chování jednoho objektu.

163
Problém je, že častých chyb začátečníků se občas doupouští i lidé s 10 a více letou praxí...

164
Dědičnost by se měla primárně používat k modelování vazby "něco je něco-obecnějšího".

Např. z třídy Animal může dědit třída Mammal a z ní třída Cat a Dog. Kočky i psi jsou savci a savci jsou zvířata.

Nicméně u adresy a regionu je použití dědičnosti nevhodné - tady spíš adresa patří do regionu, nikoliv adresa je region.

Vazbu "patří do" je lepší modelovat kompozicí:

Kód: [Vybrat]
class Region {
}

class Adress {
    private Region _region;

    function __construct(Region region) {
       _region = region;
    }

    function getRegion() {
        return _region;
    }
}

Udělat správně objektový návrh dat není úplně sranda. To, že je chyba v logice programu, nevadí zas až tolik - snadno se opraví (byť samozřejmě je tu riziko, že před zákazníkem bude člověk vypadat jako kkt). Ale pokud jsou špatně namodelovaná data, tak se to může později projevit tím, že celý softwarový produkt (a je jedno, jestli malý web nebo velký systém) bude ve stavu FUBAR* .

* http://en.wikipedia.org/wiki/Military_slang#FUBAR

165
Vývoj / Re:Perl v roce 2014 a v budoucnu...
« kdy: 28. 04. 2014, 06:36:59 »
Neznám jazyk kde abych byl něčeho minimálně schopen tak toho musím vědět tolik jako v Perlu. Nevím, nechápu to... je to psycho.

Nikdy jsem si nevšiml, že by člověk píšící v Perlu potřeboval více znalostí než v C, Pythonu apod. Myslím, že to je jenom Tvým odporem k Perlu ... čemuž se nedivím (a což máme společné ;-) ). V práci jsem viděl pár starších skriptů po ne-zrovna-moc-dobrých programátorech a nebyl jsem schopen poznat, jestli skript je napsaný v Perlu nebo Brainfucku.

Perl je pověstný tím, že velice snadno může být tzv. write-only jazykem - co napíšeš, to už nikdy nepřečteš. Na druhou stranu tím, že jej navrhoval lingvista, má celkem slušné množství zajímavých konstrukcí, díky nimž umožňuje napsat velmi dobře čitelný kód - ale chce to trochu zkušeností a hlavně sebedisciplínu - místo napsání kódu rychle je potřeba se kousnout a napsat ho pořádně.

Pokud Ti Perl nevyhovuje, zkus Python, máš-li možnost volby. Nevím o moc běžných věcech, které by v Pythonu byly výrazně horší než v Perlu. Naopak pokud potřebuješ pracovat s objekty a psát objektový kód, v Pythonu na to nepotřebuješ požehnání (viz funkce bless http://perldoc.perl.org/functions/bless.html nebo pole @ISA) :-) . Jediné, co Ti na Pythonu bude asi chybět, je CPAN a perlmonks.

Případně ještě Groovy je relativně jednoduchý a pohodlný jazyk, i když s trochu živelným návrhem. Jeho největší výhoda je, že běží nad JVM, takže o knihovny není nouze. Jeho největší nevýhoda je, že běží nad JVM, takže za jeho doporučování či protěžování by mě někteří členové komunity na Rootu asi začali kamenovat.

Stran: 1 ... 9 10 [11] 12 13 ... 31