Programování, aneb co se na škole neučí

31.8.2009 18:50 | Přečteno: 17972× | poslední úprava: 31.8.2009 19:15

Pár obecných rad jak se naučit programovat.

• Naučte se psát rychle a bez překlepů. 200 úhozů za minutu je nejlepší způsob komunikace s počítačem. Pokud je třeba přihlaste se do kurzu, trénujte několik stovek hodin.
• Nebojte se psát dlouze. Pište komentáře, assertions, unit testy a všechny ty "zbytečné" věci. Hromada věcí je odfláknutých, jen protože autor píše pomalu.
• Perfektně se naučte zkratky svého editoru/IDE. Vytiskněte si je a nalepte vedle monitoru, na záchodové dveře apod. Nikdy nesundávejte ruce z klávesnice, 90% věcí by mělo jít přes klávesnici.
• Navigace v kódu je základ. Používejte outline, hierarchy view, reference search, bookmarky, jump to declaration apod. Musíte se naučit skákat po kódu jako opice po stromech. Tohle se nedá naučit na pidi projektu, je třeba mít aspoň 1 MB kódu
• Myslete v kódu. Žádné patterny či algoritmy, vše musí být přeloženo už ve vaší hlavě. Stejně tak dekompozice, názvy promněných.. se musí vybavovat sami a bez velkého přemýšlení. Nejlepší přirovnání je k matematickým vzorečkům: popsat integrál slovy zabere půlku stránky (a hodně přemýšlení), vzorec je menší (a rychlejší na pochopení).
• Nemyslete v kódu. Některé věci je třeba předžvýkat, než je možné je převést do strojové podoby. Není možné dělat zároveň rozbor problému a převod do kódu. To způsobí ztrátu efektivity (swapování) a horší výsledek (nejde se tak koncentrovat). Pokud se problém "nevejde do hlavy" (nerozloží se na kód vcetne všech ifu, cyklu apod) je třeba odložit klávesnici a vzít papír. Cvičením se dá "zvětšit objem hlavy".
• Občas budete muset pracovat v neuvěřitelných podmínkách. Snažte se zjistit, jak na to budete reagovat, jak moc vás to zpomalí a ovlivní kvalitu výsledku. Například kódování v různých stupních opilosti/kocoviny, spánková deprivace, zavirované Win95 (u zákazníka).

Řešení problému

• 80% práce je údržba stávajícího kódu, 20% práce je psaní nového.
• Je třeba zkazit aspon dva projekty, než se clovek naučí 'zdravému rozumu' a začne efektivně programovat. Nikdy neveřte zelenáčům co píšou první kód (prověřujte jejich kód).
• Naučte se debugovat cizí kód. Perfektní znalost IDE, dobrou znalost profileru a naučit se spoustu triku. Na zvládnutí toho jsou třeba stovky hodin trénování.
• Naučte se debugovat bez možnosti reprodukovat problém a s minimem informací. Například screenshoty, stack trace... Typický příklad je naštvaný uživatel na telefonu. Je třeba vypracovat hypotézy, co problém způsobuje a ty vyvracet.
• Problém muže mít více rešení (workaround, hotfix, hack, clean fix, complete rewrite). Stejne tak je hodne kritérií (rizikovost, čas, čitelnost). Je treba umět dělat a odhadovat všechny.
• Naučte se risk management pro bugfixy. Které části muže bugfix rozbýt? Jak se to dá otestovat? Jiné riziko je ve formátování výstupu, jiné v metode která je volaná z tisíce míst.
• Spolkněte svou pýchu. Naprosto prasácké rešení proti čistému a kratšímu, může být lepší, pokud jste pod tlakem a znamená menší riziko. (samozřejmě TODO/FIXME v komentáři)
• Hromadu nápověd lze najít v subversion. Občas byl bug způsoben opravením jiného bugu. Takové veci je treba najít (hint: binary search). Naučte se perfektně zvládat SVN, pokud přes terminal nejste efektivní spolkněte pýchu a používejte gui (TortoiseSVN, IDE)
• Je třeba mít dobrou znalost bugzilly / JIRA a souvisejících procesů. Jak se bug vyvíjí, jaké jsou statusy, kdo má jaká práva (vytvořit bug, resolve bug, close bug)?

Open-source jako laboratoř

• Open-source je dobrá laboratoř. Hromady zdrojových kódu na trénování. Velké projekty do kterých lze přispívat bez velké byrokracie...
• Nejcennější jsou kometáre od ostatních a srovnání svého kódu s cizím.
• Pro začátek je třeba vybrat projekt, který ma jasně definovaného vudce a několik kontributorů. "Vůdce" by mel mít dobrou pověst a být ochotný odpovídat na otázky (projdete si mail-list). Zdrojáky by měli být psané stejným stylem. Archiv se zdrojáky by mel mít do 1 MB. Program by mel řešit jasný, přesně vymezený problém. Program by měl být tak 5 let starý, 2 roky je málo, 10 let moc.
• Ujasněte si motivaci a postavení. Přispíváte jen pro učení se? Chcete commity použít jako referenci pro budoucí zaměstnání? Máte dostatek času a zápalu?
• Přihlašte se do mail-listu a měsíc ho sledujte, projděte si archiv. Projděte si dokumentaci a příklady použití.
• Pak je treba dostat nadhled. Co který soubor / třída dělá, jak jsou oddělené části, jak to zkompilovat, zakladní debug apod.
• Zkuste rozumnět jednotlivým commitům v SVN. Je důležité vědět, jak se kód vyvíjí, proč jednotlivé řádky byli přidány.
• Dál zkuste kontrolovat bugfixy. Najděte opravený bug, vytáhnete z SVN související commity a čtete. Zeptejte se autora pokud něčemu nerozumíte.
• Zkuste opravit již opravený bug. Zkontrolujte vaše řešení s autorovým. Je důležité oddělit neznalost konkrétního projektu od obecné neznalosti programování a poučit se z nich.
• Předstírejte že bug je kritický problém a opravte ho na čas. Napřed work-around/hotfix, pak čisté rešení.
• Trénujte, opět se bavíme o stovkách hodin a desítkách bugů.
• Dobré cvičení ja také přepsat projekt z jednoho jazyka do druhého. (jen přepis, žádná nová funkcionalita, nebo nový návrh)
• Portace na exotickou platformu také pomůže. Například Linux aplikace na Cygwin nebo UClibc.

Hledání práce

• V práci strávíte většinu života, výběru firmy věnujte víc péče než výběru vysoké.
• Vysokoškolákama se dneska dláždí ulice. Nečekejte ovace jen za papíry na hlavu.
• Reference, praxe, reference. Důležité jsou roky odpracované na komerčních projektech. Školní projekty se nepočítají, open-source projekty jen některé
• Do CV dávejte jen technologie se kterými jste denně pracovali aspoň 3 měsíce. Také to napište do poznámky. Většina napíše všechny věci o kterých jen četla, z CV pak není možné zjistit co člověk umí.
• V CV nelžete, pokud lžete tak musíte mít ‘kule to ukecat. Například pokud napíšete že znáte „RHEL“ a umíte jen Debian, je vhodné nad RHEL strávit pár hodin a naučit se rozdíly.
• Na rozhovor se důkladně připravte. Věci o firmě, zaměstnancích a jejích produktech. Proklepněte si lidi kteří dělají interview. Stáhněte si program na kterém budete pravděpodobně dělat a dekompilujte ho. Projděte si bugzillu nebo jiné místo, kde si stěžují uživatelé. Tím získáte reálnou představu o stavu firmy a podmínky pro jednáni o nástupním platu.
• Ignorujte agentury, většinou nic neumí a jen vás připraví o plat (bez agentury lze dosáhnout vyššího nástupáku).
• Většina firem vystavuje pozice na svých vlastních stránkách. Vytáhnout z rejstříku zajímavé firmy v ČR (pár stovek) a ručně je všechny projít, je práce na dva dny. Na základě toho lze pak lépe vybírat.
• Hromada firem používá openspace a podobné ohavnosti. Je dobré si toho všimnout ještě před nástupem. Openspace v klasickém americkém stylu ještě ujde, ale České/Německé firmy tento systém dotáhly ad absurdum. Openspace může být dobrý ale:
  • Stropy musí být vysoké pro dostatek vzduchu a tlumení zvuků
  • Stěny by měli být polstrované, či něčím potažené aby neodráželi zvuk
  • Musí poskytovat dostatek soukromí, v sedě nesmíte nikomu koukat na záda nebo do ksichtu.
  • Bacha na průduchy klimatizace, měl by být od vás daleko. Pozor na strop.
  • Zrovna tak osvětlení, pískající zářivky, prudké světlo z boku apod.
  • Není dobré sedět poblíž místa kde se vyskytuje moc lidí: kuchyňka, hlavní uličky mezi kukaněmi apod.

Na co se ptát u pohovoru

• Účelem těchto otázek je vyšší nástupák, případně se vyvarovat naprosto prasácké firmy. Nesmíte ale jít příliš do hloubky.
• Můžu vidět ukázku kódu na kterém budu dělat?
• Používáte SVN nebo něco podobného? Pokud ne, tak proč? (dosaďte si jinou naprosto základní technologii)
• Kolik je ročně releasů?
• Platíte přesčasy? (nikdy, ale proč nepopíchnout)
• Zeptejte se svého budoucího manažera kolik přesčasů jeho podřízení obvykle odpracují.
• Práce z domova? Jak je řešena VPN a kolik lidí ji používá? (práce z domova ano, ale pouze po večerech )
• Kde bude moje židle? Můžu ji vidět?

Výpověď z práce

• Nedělejte si velkou hlavu s výpovědí během zkušební doby. Zkušební je od slova zkusit. Pokud se firma chová k zaměstnancům jako k dobytku, šetří kde může a natahuje zkušební dobu, vůbec bych neváhal. Manažer se může ohánět etikou pokud vás potřebuje, ale bez uzardění vyhodí člověka co nestíhá.
• Dát výpověď před deadline, nebo v podobné situaci je velké nee (v UK je výpovědní doba 1 týden). Ale neplatí pokud deadline je už 10x tento rok.
• Je dobré mít dobré vztahy se zaměstnavatelem i po výpovědi. Nabídněte bezplatné konzultace nebo zaučení náhrady po výpovědi. Šéf se musí spolehnout jen na čestné slovo, takže vám neudělá za zbývajících týdnů peklo. Na druhé straně to vyřeší palčivý problém s náhradou.

       

Komentáře

[Jan Grmela]

Moc pěkné shrnutí, díky.

[rastos]

Celkom slušná zbierka rád.

Pridal by som ešte:
- keď už sa niekde zamestnáte, nebojte sa pýtať kolegov. Ak sa zaseknete na nejakom probléme a nepohnete s ním za pol dňa, nenaťahujte to a nesnažte sa to zatušovať.
- ak urobíte rozsiahlejšiu zmenu do cudzieho kódu, pred commitom ju prejdite s "vlastníkom" projektu

Mňa osobne deprimujú uchádzači, ktorí nemajú potuchu
- čo je systém na správu verzií
- že sa z jedného stroja na druhý dá dostať cez ssh (plus čo sú privátny a verejný kľúč)
- ako funguje overovanie hesiel vo Windows sieti
- ako (aspon zhruba) funguje resolvovanie a routovanie

[AHAHA]

- ako funguje overovanie hesiel vo Windows sieti
- ako (aspon zhruba) funguje resolvovanie a routovanie

Muzu se zeptat na co bych tyto dve veci potreboval?

[Josef Kufner]

Tak zrovna základy fungování sítě je při jakékoliv hlubší práci s počítači (tj. více než psaní ve wordu) velmi důležité. Většinou stačí opravdu jen základní, ale je to potřeba.

S ověřováním hesel ve Win síti to ale je ptákovina. Tam hodně záleží na používaných technologiích a navíc je to záležitost adminů.

[rastos]

Muzu se zeptat na co bych tyto dve veci potreboval?

Ak nerobíš vo veľkej firme, kde je vyhradený človek, ktorý kompletne nachystá každý jeden systém, ale robíš v menšej firme, kde si občas musíš urobiť vlastný testovací systém (aj keď napr. len virtualizovaný), alebo riešiť prečo sa u zákazníka tvoja aplikácia nevie spojiť s DB/web serverom ... tak je dobré vedieť, ako zistiť IP adresu seba/IP DNS servera/gateway/SQL servera/proxy/...

[ARny]

dobre toto vsetko robim, ale nechapem ten bod s overovanim hesiel na windowse. Ako funguje overovanie hesiel na windowse?

[happy barney]

Ako funguje overovanie hesiel na windowse?

niekedy case-sensitive, niekedy nie
niekedy clear-text, niekedy nie
niekedy funguje, niekedy áno, niekedy ánoEx

[rastos]

nechapem ten bod s overovanim hesiel na windowse. Ako funguje overovanie hesiel na windowse?

To je moja osobná trauma z jedného projektu, na ktorom robím. Jeho súčasťou je pri nainštalovaní vytvorenie užívateľa a skupiny vo Windowsoch, ktorý sa používa napr. pri supporte a pri overovaní či užívateľ niečo má/nemá vidieť. Komplikované to opäť začína byť vtedy, keď sa človek vyskytne v novom prostredí (inštalovaný vlastý testovací systém, demo/support u zákazníka, ...). Ak je počítač v doméne, tak sa heslo overuje voči Primary Domain Controlleru - PDC. Pužitie toho správneho PDC (resp. NT domény, ktorú ten PDC spravuje) možno dosiahnuť napísaním "domena\uzivatel" na mieste kde sa očakáva užívateľské meno - to platí pri prístupe na vzdialený stroj cez explorer, akýkoľvek fileopen/filesave dialog, pri špecifikovaní konta pod ktorým beží service, pri používaní prikaz "net" s parametrom "view" alebo "use", ... Pri overovaní členstva v grupe pomocou príkazu "net user" treba rozlišovať či sa konto overuje na lokálnom stroji, alebo na PDC (prepínač /domain). Podobne pri zmene, alebo overovaní prístupových práv (či už cez cacls alebo v GUI) treba dávať pozor či konto, ktoré človek vidí je lokálne alebo doménové. A k tomu celému ešte môžeme prihodiť lokálne a globálne grupy ... (prečo vlastne ľudia hovoria, že Windows je jednoduchý ?? )

[uf]

To jsou detaily, které ti někdo ukáže jednou nebo dvakrát a pak už jedeš sám.

[alblaho]

Zkuste opravit již opravený bug.

Nedovedu si představit, že bych dobrovolně dělal něco tak nudného. Programování mě vždycky bavilo a je to pro mě zábava i když se tím živím. Takovýhle tuhý tréning snad musí provozovat někdo, koho programování v podstatě hrozně štve, jenom to vyhodnotil jako dobrý způsob vydělávání peněz.

Jinak mi většina bodů přijde rozumných. I když ten důraz na IDE nesdílím, pro Javu jasně, ale na Python stačí GEdit s pár pluginama.

[Marek Bernát]

+1

[Trained.Monkey]

To neni tuhy trening, ale zakladni cviceni. A clovek si tim proste musi projit, jestli se chce dostat dal nez "linux rulez".

[alblaho]

Uh. Ty znáš ještě někoho, kdo takové "základní cvičení" takhle svědomitě provozuje? Myslíš, že makáči jako Torvadls nebo Gosling něčím takovým prošli?

Lepší je navrhnout si jazyk a napsat k němu interpreter. Nebo vlastní operační systém. Když už to není užitečné, ať je to aspoň zábava.

[Trained.Monkey]

>> Ty znáš ještě někoho, kdo takové "základní cvičení" takhle svědomitě provozuje?

Jo, prakticky vsechny programatory se kterymi jsem se setkal. Problem je ze tohle zakladni cviceni provozuji na zivem projektu. Vysledek pak podle toho vypada.

>> Lepší je navrhnout si jazyk a napsat k němu interpreter.

Jenze psanim se nenaucis rozumnet kodu. Budes jako pologramotny co se naucil psat, ale neumi cist. A to je po nekolika letech na vysoke dost smutny.

[alblaho]

Počkej. Bavíme se o opravování už opravených chyb a porovnávání s původní opravou z důvodu tréninku? Protože pak tu narážku na živý projekt nějak nechápu.

Ale uznávám, že čtení cizího kódu jsem se naučil až s komerční praxí. Ale skoro si myslím, že to jinak ani nejde. Na VŠ se IMHO mají určit hlavně principy.

[Trained.Monkey]

Uznavam, prvni cast je trochu mimo. Znam asi 3 lidi kteri se takhle ucili (vcetne me)

[Ladicek]

Souhlasím s tebou. Tenhle článek mi místy nebezpečně připomíná, jak se tu kdysi vychvaloval nějaký absolvent VŠE Samozřejmě obsahuje i řadu užitečných věcí, ale pokud jde o to, co programátory ve škole neuči, doporučil bych spíš knížku pana Palety. To, co je popsáno tady, se člověk, kterého programování baví, na škole a postupně v praxi naučí samospádem, drilovat to musí opravdu jen ti, kteří se programováním chtějí jenom živit. Těm to ale stejně moc nepomůže.

[melkors]

Copak o to, ta knizka neni spatna. Ovsem dost veci mi na ni vadilo:

- zbytecne vypady proti OSS

- nektere, rekneme ne zcela rozumne priklady (napr. me zarazilo, ze by vystudovany programator neznal rozdil mezi bubble sortem a quick sortem a nevedel, kdy je ktery vhodne pouzit)

- orientace takrka vyhradne na MS

+ rada dalsich veci

Bohuzel je to jiz nekolik lete, co jsem to cetl, takze uz stacila skleroza zapracovat

[podlesh]

Tenhle článek mi místy nebezpečně připomíná, jak se tu kdysi vychvaloval nějaký absolvent VŠE

Já myslím že je to tentýž autor

[Ladicek]

To by ledacos vysvětlovalo

[uf]

Ještě bych doporučil knížku Programátor pragmatik, je i česky a jsou tam obecné zásady.

A hlavně programovat a programovat a programovat a prohlížet cizí kód,

[Ladicek]

Jo, Pragmatic Programmer je legenda. Český překlad není špatný, ale za dobrý bych ho taky neoznačil

[microcz]

+1 ...mluvis mi z duse

[David Ježek]

Jsem rád, žes opět začal blogovat.

[freshmouse]

Lidi, vy ještě programujete? Kupte si na to opice.

I já si tak někdy připadám. Před týdnem jsem si přinesl do práce banány, dal jsem si je na stůl a pracuju si... Pak jsem se tak nad něčím zamyslel, zakoukal jsem se na ty banány a připadal jsem si dost divně.

[freshmouse]

Ale jinak mi ten článek přijde jako takové "prostě se všechno naučte". Jako říkat kuchaři, že nemá přesolovat a nalévat polévku nožem...

[Jirka]

A co čekáš v blogu, jehož autor má přezdívku "trénovaná opice".

[trekker.dk]

Oook?

[Fluttershy, yay!]

Eeek. (Hint: opice.)

[e.lisak]

No, styl reakce Knihovníka na oslovení "opice" nebo "opička" býval poměrně známý.

Mělo to myslím souvislost s vývojem...

[Fluttershy, yay!]

Poslední bod první části do kamene tesat. Nejsem schopen (bez sluchátek a metalu) vůbec fungovat ve školních učebnách s hučícími projektory a bzučícími zářivkami. Jakpak bude vypadat maturita?

[David Ježek]

já ji dělal pod vlivem fernetu a zářivky mě netrápily.

[Jan Grmela]

+1, správný přístup

bez piva či vína dlouhodobě na počítači žádnou duševní činnost vyvíjet nemůžu. Mimo celodenního popíjení jsou vhodné ještě několikahodinova noční sezení známá jako "chlapi, dem se vožrat", po kterých má člověk ráno krásně čistou hlavu

[Stevko]

Dúfam, že nikdy nebudem musieť nič väčšie programovať (nerád programujem a vyhýbam sa tomu). Prečo som ja len liezol na tú informatiku (MFF)?

[Bluebear]

Omlouvám se předem, ale nemůžu si pomoct, budu rýt. Prosím promiň.

• Naučte se psát rychle a bez překlepů. 200 úhozů za minutu je nejlepší způsob komunikace s počítačem. Pokud je třeba přihlaste se do kurzu, trénujte několik stovek hodin.
• Perfektně se naučte zkratky svého editoru/IDE
• Navigace v kódu je základ. Používejte outline, hierarchy view, reference search, bookmarky, jump to declaration apod.

Nezlob se, ale IMHO tohle všechno je blbost. Člověk stejně vždycky myslí rychleji a hlavně v mnohem větší šíři, než píše. Programátor dvě hodiny dumá, čmárá na papír, nechápavě hledí na obrazovku, ohryzává tužky a podobně, a pak napíše tři řádky. Jestli ty tři řádky píše vteřinu nebo deset vteřin, je fakt úplně jedno. Totéž u zkratek - pokud je člověk používá, přejdou mu do krve samy, ale rozhodně to není to podstatné.

To samé platí o navigaci v kódu - ta je samozřejmě důležitá, ale programátor má mít mapu projektu v hlavě, kód má být rozumně rozdělen do bloků a vizuálně formátován tak, aby byl přehledný.

• Nebojte se psát dlouze. Pište komentáře, assertions, unit testy a všechny ty "zbytečné" věci.

A zapalte svíčku za tu nešťastnou duši, která po vás bude muset tu hrůzu číst.

Příručka How to write unmaintainable code uvádí, že jsou dva způsoby, jak vyrobit z programu naprostý bordel: jeden je nepsat žádné komentáře, druhý je komentovat úplně všechno. Do toho ještě unit testy, záplavu assertů, všechno pečlivě zdokumentované, a z dvacetiřádkového kódu je padesát obrazovek.

Kód sám by měl být stručný a srozumitelný. Komentáře by měly obsahovat informaci, která se z kódu vyčíst nedá (tedy jaký byl záměr autora), nebo pomoci čtenáři v nepřehledných místech. Čím je kód kratší, tím lépe se v něm orientuje a chyba se v něm hůře ukrývá.

• Tohle se nedá naučit na pidi projektu, je třeba mít aspoň 1 MB kódu

Tohle když zkusí začátečník, tak skončí v péči MUDr. Chocholouška. Pokud je projekt tak veliký, tak jsou jen dvě možnosti: buď je extrémně komplexní a psal ho tým lidí, a pak to není vhodný projekt pro učení, anebo je to projekt jednoduchý, který psalo prase - rovněž nevhodný pro učení.

• Myslete v kódu. Žádné patterny či algoritmy, vše musí být přeloženo už ve vaší hlavě.

IMO volovina. Důležitá by měla být logika, datové struktury a tok informací - tedy všechno věci, u kterých je úplně jedno, v jaké reprezentaci s nimi programátor pracuje.

• Naučte se debugovat cizí kód. Perfektní znalost IDE, dobrou znalost profileru a naučit se spoustu triku.

Žel, perfektní znalost IDE a padesáti ladících nástrojů je člověku na velké hnědé smradlavé, pokud nedokáže v hlavě analyzovat ten kód. To je třeba se učit - znalost nástrojů přijde sama, stačí je chvíli používat.

• Dobré cvičení ja také přepsat projekt z jednoho jazyka do druhého. (jen přepis, žádná nová funkcionalita, nebo nový návrh)
• Portace na exotickou platformu také pomůže. Například Linux aplikace na Cygwin nebo UClibc.

Jo, cvičení ve frustraci. Takhle se učí matematika na základní škole - proto máme tolik lidí, kteří matematiku nenávidí k smrti, a tak málo lidí, kteří jí rozumějí.

Pokud se chci něco naučit, musí mě to bavit. Pokud mě to má bavit, musí být to, co dělám, zajímavé, musí v tom být objevování něčeho nového, musí to být tvořivá činnost. Opakovat opravy cizích bugů a přepisovat stávající kód, to je úkol pro otroka, ne pro duševně aktivního jedince.

Kromě toho, přepisování kódu do jiného jazyka nebo na exotickou platformu je často věc kur*vsky složitá, na které si vyláme zuby i zkušený praktik. Často vyplave na povrch spousta subtilních problémů závislých na architektuře, na chování nedokumentovaných funkcí systému či procesoru, atd. Tohle bys chtěl hodit na začátečníka? Vždyť bys ho zahubil.

[Grunt]

Přesně, i když jako neprogramátor, tak mám takový pocit jako by nějaký Manažer/Team Leader/Něco podobného psal Pilně se učte a cvičte včeličky a pak se u mě hlaste.. Těch 200 úhozů mi naprosto uniká. Kde se takový Superman jenom skrývá?

[Jirka]

Jistý člověk, jehož jméno se nevyslovuje, dokáže za den napsat 2 MiB bezchybného kódu. Ovšem už se nezmiňuje, že ten kód ukradl a ty 2 MiB kódu nasbíral na ASCII artu a copyrightových sračkách v komentářích.

Význam 200 úhozů za minutu u programátora má asi tak stejnou váhu jako ty sračky v těch komentářích.

[stativ]

Jistý člověk, jehož jméno se nevyslovuje, dokáže za den napsat 2 MiB bezchybného kódu. Ovšem už se nezmiňuje, že ten kód ukradl a ty 2 MiB kódu nasbíral na ASCII artu a copyrightových sračkách v komentářích.

Já myslel, že toho je schopné jen prase (hint: Preston Pigglesworth III).

[alblaho]

Já si ale myslím, že dobře a rychle psát je pro programátora přece jenom velké plus. Pak třeba napíše komentář, na který by se před tím vyflákl. A hodí se to, když člověk programuje v Adě

Add_Item_To_List(The_Item => Selected_Item, The_List => All_Selected_Items);

[melkors]

Mys ma tri tlacitka.

[starouš]

Tak dlouho mě lezlo na nervy, že si neustále musím koukat na prsty, až jsem se jednoho dne naštval a naučil se psát všema deseti. Nekoukat si na prsty je super a to nejen při programování. Asi je fakt, že nebudu rychleji programovat než ten, kdo psát všema deseti neumí, ale určitě se mi pracuje s počítačem rychleji. Dneska to třeba dost oceňuju u sql dotazů, které jsou dost často hodně primitovní a pokud tam chci mít sloupce vypsaný bez hvězdičky, tak to opravdu ušetří spoustu času.

Jo, naučit se psát všema deseti byla otázka asi 3 měsíců, kdy jsem tomu večer věnoval asi 2 hodiny denně. Sehnal jsem si na to prográmek, který hlídal chyby a i sledoval mojí rychlost.

[Trained.Monkey]

Ad 200 uhozu:

Nejedna se jen o rychlost psani ale o i jistotu. Proste aby clovek busil bez divani se na klavesnici. A obcas se clovek na tuhle rychlost psani kodu dostane (napriklad pri psani dlouheho komentare, nebo testu apod)

Ad navigace: Na jednoduchy kod mozna neni potreba. Realita je takova ze uz po dvou letech se i vlastni kod stava nesrozumitelny a pak se hodi.

Ad dlouhy kod: Takze komentare, assertions a unit testy zpusuboji neudrzovatelny kod? Hadat se nebudu.

Ad pidi projekt:

Je treba zacit na rozumne velkem projektu. Jinak se clovek nauci spatne cist kod a u vetsich projektu bude mit velke problemy. Rozepisu se o tom vice v dalsim blog postu.

Ad myslete v kodu:

Je to vec efektivity, prectete si ten post poradne + dalsi bod.

Ad Perfektní znalost IDE:

Hromada veci se da opravit bez velkych analyz. Proste replikuju, izoluju, opravim, otestuju. Typicke je nahrazeni ArrayListu LinkedHashSet. Ucit se za pochodu muze byt fajn, ale pak clovek napriklad nezjisti co dela 'drop stack frame' apod.

Ad cviceni:

Jo, je to stejne jako matika. Proto je taky tak malo lidi co umi cist kod. Opravovat jiz opravene bugy je treba pro porovnani svych vysledku s profiky. Nejde jen o to bug opravit, ale opravit ho dobre. Opravovani bugu neni ukol pro otroka, je to kreativni cinnost. A je to stejne potreba jako navrh, psani noveho kodu apod.

Ad prepisovani:

Je to posledni krok v tech cviceni. Tedy po tom co clovek uz par problemu opravil a rozumi kodu. Cil neni projekt dokoncit, ale vylamat si co nejvice zubu a poucit se. Po druhe nebo potreti uz to pujde daleko vic. Rozhodne mi to prijde jako lepsi cviceni nez psat po 1500 operacni system.

Ad problemy:

vite jak se delal prvni port Postgresql na Win? Cygwin neumel poradne thready, takze z toho thready vyhazeli, udelali ho single threaded a ono to fungovalo.

[Bluebear]

Hromada veci se da opravit bez velkych analyz. Proste replikuju, izoluju, opravim, otestuju.

Doplním z vlastní zkušenosti: Rozjedu se, nevšimnu si drobné nuance, změním to někde, kde to mělo zůstat, celé se to podělá, budu nad tím zoufat měsíc a nakonec mě z toho bude muset vytáhnout zkušenější programátor.

Cil neni projekt dokoncit, ale vylamat si co nejvice zubu a poucit se.

Ideální způsob, jak člověku zničit sebevědomí a navždy mu zhnusit programování. Začátečníkovi musíš přece, ku*va (dámy prominou) pomoci, a ne ho deptat. Deptání zvládne život sám a dobře; lidi by si měli pomáhat.

Rozhodne mi to prijde jako lepsi cviceni nez psat po 1500 operacni system.

Považuji za mnohem lepší psát potisící něco, co člověka baví, než psát potisící něco, co se člověku protiví. Naučí se toho přibližně stejně a užitečnost je také stejná (nulová), ale je to mnohem hezčí zážitek - a hezké zážitky formují přístup k problému.

vite jak se delal prvni port Postgresql na Win? Cygwin neumel poradne thready, takze z toho thready vyhazeli, udelali ho single threaded a ono to fungovalo.

(Probůh, nevykej mi, já jsem medvěd, šelma pozemní...)

Víš, jak se dělal port Virtual Reality Toolboxu pro Matlab na první preview OS X Jaguar? Tam nebyla proměnná errno vázaná na thread, takže chybové hlášky prosakovaly z jednoho javového threadu do druhého. Ztratili jsme díky tomu týden života, hrozně jsme se nas*ali a jediné poučení, které jsme si odnesli, bylo, že když ti systém hází klacky pod nohy, tak jsi v pr...

[uf]

200 uhozu za minutu budu mit, kdyz mezitim budu premyslet a cekat na hinty editoru.Vsema deseti umim dost dlouho a je to prijemnejsi, ackoli syn pise stejne rychle i ctyrma prstama a palcem. Spis bylo blby, kdyz jsem si jeden cas zvykl divat se na prsty.

[uf]

Ale je pravda, ze nektere veci je rychlejsi napsat nez je hledat a kopirovat.

[ARny]

hej a potom sa k nim par krat vratit aby si opravil tie chyby co si si tam narobil.

[Leoš Literák]

Unit testy se pisou do samostatnych souboru, casto v odlisnem adresari (src vs. test), tudiz kod na citelnosti neztraci. Za to se zlepsuje udrzovatelnost (jsi upozornen na chybu; pak fixujes tak dlouho, dokud testy nezacnou zase chodit).

[Ladicek]

Pokud se chci něco naučit, musí mě to bavit. Pokud mě to má bavit, musí být to, co dělám, zajímavé, musí v tom být objevování něčeho nového, musí to být tvořivá činnost.

Tady je zakopaný pes. Totiž jehla Pokud je programování umění, pak ho mohou provozovat pouze ti, kteří mají talent. Rady v článku jsou pokusem předat nadání těm, které programování nebaví a chtějí se jím jen živit, což je předem odsouzeno k neúspěchu.

Bohudíky, programování už zdaleka není jen umění, ale (bohužel?) pořád ještě to není jen inženýrská disciplína. Takže určité množství nadšení je u programátorů pořád potřeba. Dril samotný nefunguje.

[podlesh]

Jako mnoho oblastí lidské činnosti, programování má několik úrovní:

- umění / umělec

- řemeslo / řemeslník

- průmysl / dělník

To poslední ale (zatím?) moc nefunguje, přes usilovnou snahu z "manažerské" strany.

[uf]

Dneska se citi jako programator kazdy, kdo opise kus HTML kodu, jako fotograf a umelec kazdy, kdo ma digitalni fotak lepsi nez v mobilu.

Trochu predpokladu to chce.

[ARny]

ano podla mna je to o talente uz koli tomu, ze nie kazdy je schopny abstraktne mysliet. Takze programovanie je umenie a samotne ucenie nemusi stacit.

[Marek Bernát]

To je pravda, ale na rozdiel od bežného umenia to platí aj naopak. Programátor bez znalosti matematiky a teoretickej informatiky je na nič, bez ohľadu na to, aký má talent.

[ARny]

To suhlasim a ked si to vezmem tak aj Leonardo da Vinci ci Michelangeo by neboli taky slavny keby ich tiez niekto neucil aj keby mali talent. Neviem ale podla mna je programovanie ciste umenie. Prejavuje sa individualita pri vyhotoveni. Tak ako by ten isty obraz namalovali iny umelci trochu inak tak aj kazdy program je od inych luci trochu iny aj ked robi to iste.

[Marek Bernát]

No, neviem. Určite je znalosť teórie dôležitá aj pri umení, ale podľa mňa to nikde nie je zďaleka tak výrazné ako v informatike. Podľa mňa v umení má človek celkom dobrú šancu sa uplatniť aj bez učenia sa teórie, ak má talent. Dôkazom je napríklad to, že všetci veľkí umelci začínali vo veľmi nízkom veku (cca 5 rokov) a okamžite boli schopní maľovať/koncertovať. V informatike to tak bohužiaľ nefunguje Niektoré veci z matematiky a informatiky sa dajú vymyslieť, ale tie stovky rokov zložitých vecí si človek z prsta proste nevycucá.

[ARny]

Vsetci ty velky umelci co zacinali v malom veku boli k tomu vedeni. Ano talent sa vie prejavit ale jeho maximum sa da ziskat vedomostami.

[Marek Bernát]

Takže myslíš, že aj programovať sa dá od 5 rokov, keby k tomu človeka viedli? Ja osobne som začal v 10 a až tak do 15 to boli samé sprostosti Keď to porovnám s Mozartom, ktorý začal v 4 rokoch a v 6 už koncertoval... Njn, ale ja nie som žiadny génius. Takže možno máš pravdu

[ARny]

A preco nie?

http://www.youtube.com/watch?v=O0Gk2Mu9H6g

Poznam ludi co v 7mich rokoch urobili svoj prvy program vo visual basicu. Verim zeby sa to dalo aj skor ale ktory rodic bude svoje dieta nutit programovat tak skoro len aby sa dostal do vecernych sprav alebo sa stal znamy. Taketo experimenty (ci skor tyranie) na detoch si mohli dovolit v 16-17. storoci

[Marek Bernát]

Hej, hej, asi sa to v princípe dá. Ale s tými experimentami sa mýliš. Virtuózi dnešnej doby málokedy začínali neskôr ako v 5 rokoch. S tou hudbou to funguje stále. Myslím, že je hlúposť to nazývať týraním. Ak má dieťa talent, tak bude nadšené z toho, jak sa môže s nástrojom vyblázniť Btw, ja osobne som sa k hudobnému nástroju dostal až oveľa neskôr z vlastnej vôle a to už bolo neskoro, aby som sa niečo rozumné naučil. Čo by som dal za to, aby ma rodičia "týrali" od 6 rokov a dnes by som dokonale nejaký nástroj ovládal...

[ARny]

Nemyslim, ze je to hlupost. Ved aj my sme raz boli deti a kazdu chvilu sme chceli robit nieco ine. Priznavam, ze niektore deti to moze chytit ale verim aj v to, ze existuju rodicia ktory nutia svoje deti robit to co v podstate robit nechcu. Keby si sa naucil hrat v 6tich rokoch tak by si teraz stal v rade ako kazdy dobry hudobnik a cakal kym si ta niekto vsimne a zasponzoruje ta. Ty bud len rad, ze si programator (ak teda si programator ;)). Mozno mas viac talent na abstraktne myslenie nez na myslenie v hudbe tak to vyuzi.

[Marek Bernát]

Všetci rodičia nútia deti robiť to, čo nechcú. Volá sa to výchova

Som napol programátor a napol fyzik. Ale inak si myslím, že sa to s hudbou nijako nevylučuje. Poznám kopu ľudí, ktorí hudbu študujú od malička, ale pritom sa venujú niečomu úplne inému. Fakt by som bol oveľa radšej, keby som vedel tiež poriadne hrať na nejaký nástroj a z času na čas si mohol zahrať hocijakú hudbu, čo ma zrova napadne.

[Jirka]

Neviem ale podla mna je programovanie ciste umenie.

To se už ve školách neučí o Softwarové krizi (programátor umělec) a na ni navazujícímu vzniku nové disciplíny nazvané: softwarové inženýrství (dad)?

[JS]

Diky, +1

blogpost -1

Byt zacatecnik, radeji dam na Bluebeara nez na TrainedMonkey.

[rastos]

• Naučte se psát rychle a bez překlepů. 200 úhozů za minutu je nejlepší způsob komunikace s počítačem. Pokud je třeba přihlaste se do kurzu, trénujte několik stovek hodin.
• Perfektně se naučte zkratky svého editoru/IDE
• Navigace v kódu je základ. Používejte outline, hierarchy view, reference search, bookmarky, jump to declaration apod.

Nezlob se, ale IMHO tohle všechno je blbost. Člověk stejně vždycky myslí rychleji a hlavně v mnohem větší šíři, než píše.

Nevieš si predstaviť tú frustráciu, keď prídeš za kolegom, že máš kus dát na ktorých jeho knižnica zlyhá a chceš, aby zistil čo sa deje (napísal malý test-case, vysledoval čo sa deje s nejakým konkrétnym údajom,...) a ten človek začne klepať do klávesnice štýlom "peck-hunting". Už sa mi stalo, že som musel človeku, čo je odo mňa starší o 10-15 rokov, povedať "Uhni!" a na jeho stroji, v programovacom jazyku - ktorý nepoužívam, v projekte - ktorý nepoznám, v IDE - ktoré nepoužívam, som problém našiel skôr ako on. Dobrý hudobník tiež musí vedieť, kde má akú klapku/dierku na svojom stroji aj o pol noci.

Programátor dvě hodiny dumá, čmárá na papír, nechápavě hledí na obrazovku, ohryzává tužky a podobně, a pak napíše tři řádky.

Neviem teda či ty si programátor, ale z mojej skúsenosti platí, že v 95% prípadov netreba vymýšľať prefíkané algoritmy a sedieť nad papierom. 95% programátorov sú skutočne cvičené opice - akurát, že poznajú syntax, nástroje a vedia, čo daný jazyk umožňuje. Samozrejme poznať tieto veci nie je málo a preto nie každý je programátor.

[Bluebear]

Nevieš si predstaviť tú frustráciu, keď prídeš za kolegom, že máš kus dát na ktorých jeho knižnica zlyhá a chceš, aby zistil čo sa deje (napísal malý test-case, vysledoval čo sa deje s nejakým konkrétnym údajom,...) a ten človek začne klepať do klávesnice štýlom "peck-hunting".

Propána, když tě frustruje, jak někdo ťuká do klávesnice, tak se na něj nedívej. Ono je docela možné, že zatímco ťuká, v hlavě se mu otáčejí kolečka setsakramentsky rychle a až to doťuká, tak to bude mít rovnou správně.

(Pozn.: Já píšu třikrát pomaleji, když mi někdo čumí na prsty, protože mě to znervózňuje.)

Už sa mi stalo, že som musel človeku, čo je odo mňa starší o 10-15 rokov, povedať "Uhni!"

K tomu se hodí citát z jakési restaurace: Nepomlouvejte naši kávu - i vy budete jednou slabí a studení...

[Grunt]

Já to nechápu. Když chci napsat nějaký jaderný ovladač, tak většinou musím vzít do ruk Jelínka, datasheet k čipu, pár terminálů(find,man,…) a pomalu, pomalounku než se vůbec odhodlám udeřit do klávesnice první kód. A i pak je potřeba obhospodařovat všechno smetí kolem a čekat, než se to všechno převede do binární podoby, nainstaluje, spustí, atd. A pak následuje testování různých pozic a vyčkávání na první Oops. A to v případě, že mám k dispozici datasheet. Když ne, tak následuje psaní trasovacích programů, jejich distribuce, získávání údajů, půldenní hledění do monitoru na nějaký polo-binární bastl a hledání souvislostí v něm, čtení spousty materiálu jak vůbec obvykle daný kus HW funguje, přemýšlení co by tak asi mohlo být co, atd. A nebo mi chce někdo tvrdit, že jaderné struktury drží v hlavě, pro psaní jaderných modulů už předpřipravené šablony, POSIX nadiktuje pozpátku i když ho o půlnoci vodou obleju a datasheet mu bleskne v hlavě jen pouhým pohledem na čip? Stejně tak třeba nucení Pythonu ke cross-kompilaci. To bylo celkově pár řádků v Pythonu(,které jsem díky neznalosti tohoto jazyka radši po pár neúspěšných pokusech stáhl z internetu), ale kupa rozčilování se nad buildrootem a autotools a přemýšlení nad tím, co bych asi tak udělal s autory těchto výmyslů, kdyby se mi dostali do rukou. No a hlavně pár dnů, během kterých by se dali napsané řádky kódu spočítat na prstech jedné ruky. A nebo si mám opravdu v této společnosti připadat jako naprostá lama když mi takováto coderate nejde do hlavy?

[podlesh]

Ne každý patří do kategorie "cvičená opice".

Nebo, pokud to vezmeme bez urážlivých pojmů: již jsem zde zmínil, že na tvorbu software lze považovat za umění, řemeslo či průmysl. V tom posledním případě potřebujeme "dělníky" - kodéry kteří prostě píšou a píšou a nijak zvlášť nad tím nemusí dumat. Ani nemají, od toho mají "mistra" (senior developer, architect, team leader).

Psaní jaderného ovladače, nucení Pythoniu ke cross-kompilaci - to je naprosto jasně řemeslo.

Umění je pak například psaní interpreteru na 200 řádek a méně

PS: Pojem "řemeslo" používám bez pejorativního nádechu který tento pojem někdy má. Spíše tak v pojetí sto, dvěstě let starém.

[Grunt]

kodéry kteří prostě píšou a píšou a nijak zvlášť nad tím nemusí dumat. Ani nemají, od toho mají "mistra" (senior developer, architect, team leader).

No dobře, ale i tak je pořád potřeba zpětná vazba a interakce, ne? A nebo to se prostě někdo(Senior Developer) narodí s tím, že teď když napíše make, tak ví, že celý překlad proběhne bez problému? Hele, to chci umět. Kde se to můžu naučit?

[podlesh]

?? Samozřejmě, vždyť píšu že od toho jsou tam jiní lidé. Jasnovidnost je samozřejmě výhodou, ale obvykle se dá obejít i bez ní.

[rastos]

Když chci napsat nějaký jaderný ovladač ...

Ono to silne závisí od toho, v akej oblasti sa pohybuješ. Jadrový ovládač asi spadá do tých zvyšných 5%.

Ak máš povedané, urob komunikáciu cez sockety v multithreadovej aplikácii, tak je jasné, že odniekiaľ musíš dostať meno servera (prípadne port) a musíš vyresolvovať adresu, vyrobiť socket, nastaviť mu nejaké option-y, zavolať connect() a celé to strážiť nejakým mutexom. V C to vyjde spolu s ošetrovaním chýb tak na 20-30 riadkov. A nemusíš nad tým rozmýšľať ani ň.

Nedávno som potreboval vyrobiť .zip v C. Nájdeš si popis štruktúry .zip. Pol dňa stratíš s tým, že zisťuješ čo je v tom dokuemnte len balast a zistíš, že tam treba dať 4 bajty také, 2 bajty onaké, potom timestamp súboru, jeho meno, atď atď ... žiadne rozmýšľanie. Len píšeš.

Iný príklad - bug: javovské combo plnené z databázy má niektoré položky farebne zvýrazniť podľa ďalšej hodnoty v DB. Nájdeš, kde sa to combo plní, do select-u pridáš ten stĺpec čo hovorí o farbe, napíšeš vlastný renderer podhodíš ho tomu combu a je (ak vieš ako sa to robí). Nikde žiadne algoritmy.

[Grunt]

Nájdeš si popis štruktúry .zip. Pol dňa stratíš s tým, že zisťuješ čo je v tom dokuemnte len balast a zistíš, že tam treba dať 4 bajty také, 2 bajty onaké, potom timestamp súboru, jeho meno, atď atď ... žiadne rozmýšľanie. Len píšeš.

Tak na to bych se z vysoka vy…kašlal. Buď bych k tomu přilinkoval nějaký libzip(či jinou knihovnu tvořící zipy) nebo bych ten make_zip.c odněkud zkopíroval. Snad nejsem blázen abych psal něco co už předemnou někdo napsal(a ve většině případů i lépe a ještě to ke všemu asi i zoptimalizoval).

napíšeš vlastný renderer

Úplně ten samý případ jako o odstave výše.

[Grunt]

Snad nejsem blázen abych psal něco co už předemnou někdo napsal

A nebo to jsou opravdu lidé, které jen samotné bušení do klávesnice baví/vzrušuje?

[xvasek]

Openspace je IMHO asi ideální řešení, pokud je dobře udělaná (jakože šéf nesedí všem za zády nebo kolega vedle nemá slabý mikrofon u telefonu, tak do toho musí hulákat). Teď mám samostatnou kancelář - nevím žádné drby, s lidma se bavím jenom telefon nebo cestou na oběd a je mi smutno...

Taky jsem zjistil, že není k zahození Java. Pošlu šéfovi screenshot nějaké náhodné chybové hlášky a nemusím vysvětlovat, co jsem dělal celé odpoledne.

[Grunt]

• Hromada firem používá openspace a podobné ohavnosti. Je dobré si toho všimnout ještě před nástupem. Openspace v klasickém americkém stylu ještě ujde, ale České/Německé firmy tento systém dotáhly ad absurdum. Openspace může být dobrý ale:
• …

A co teprve sedět v prosklené baňi u okna na úrovni velmi frekventovaného hlavního chodníku, který se táhne hned vedle skla, tak že si kolemjdoucí mohou bez problémů číst Vaši konverzaci v okně ICQ?

[Petr Bravenec]

Hehe, to by mě taky potěšilo. Já jsem jednu dobu seděl naproti skladu, oddělený pouze překližkou. Párkrát za den se mi o stůl opřel vysokozdvižný vozík a se skladníkova rádia se na mě neustále sypal proud jakýchsi komerčních sraček. Hlasitost byla samozřejmě nastavená tak, aby to rušilo, ale bylo rozumět pouze reklamám: "...chrochrochro pouze DEVADESÁTDEVĚTDEVADESÁÁÁT!!!! .... chrochrocho DEVADESÁT!!!! ... chrochro ... DEVADESÁT!!!!"

[xsubway]

Chybami se opice učí.

[tmr]

Zkoušel sis někdy udělat statistiku kolik průměrně napíšeš řádků za pracovní den? Kolik procent (odhadem), je opravdový kód, ne testy, komentáře atd.  Docela by mě tohle zajímalo...

[Marek Bernát]

A čo je to "opravdový" kód? V jave nie je problém popísať niekoľko stránok kódom, ktorý v lepších jazykoch zaberie pár riadkov Ak má niekto záujem, tak dám odkaz na kompilátor Lispu v Haskelli pod _200_ riadkov (a je to nádherný elegantný kód -- proste Haskell). Chcel by som vidieť ten kompilátor napísaný v Jave.

[kralyk z abclinuxu]

Jó, tak to sem hoď... voni lidi ten Haskell obvykle chválej, tak bych se mrknul jak to vypadá. (Budu z toho něco mít, i přesto že Haskellu konkrétně nerozumím?)

[Marek Bernát]

Yup, Haskell uznávajú dokonca aj Lisperi. A o tých je známe, že čo nie je Lisp, tým pohŕdajú

Budeš, lebo je to aj s návodom

P.S.: zabudol som, že to bol interpreter a nie kompilátor. Sorry. Ale aj tak to stojí za to.

[xsubway]

ale IMHO trochu nespravedlivé. StringBuffer se v javě takto nevytváří:

StringBuffer output("(");

a místo

for (; it.hasNext(); )

bude zřejmě vhodnější (i když se stejným výsledkem)

while (it.hasNext())

nehledě na to, že v příkladu je v haskel kódu vše pojmenováno krátce: x, f, ... a javě dlouze: _value, output, ...

ps: ale jinak stejně díky za ten odkaz

[podlesh]

Klasická ukázka jednoho zajímavého efektu: když někdo píše opravdu nadšený článek a chce tam něco jiného hodně strhat, ve většině případů zvolí nevhodné příklady. Prostě se trefí úplně mimo a pak ze sebe dělá blbce když se do nich pokouší nacpat svoje nadšení a zhnusení.

Typicky se to stává v ódách na operační systémy. Pominu teď klasické Linux vs. Windows, ale zábavné bývají články o BSD (považte: kompilace jádra v BSD se dělá jednoduše v konfiguračním souboru, nemusíte odpovídat stovky otázek nebo startovat X jako v linuxu; navíc ksh je mnohem lepší než trapný bash, příklady následují; etc).

Napsat dobrý vysvětlující a vyzdvihující článek je těžké; napsat dobrý kritizující článek je mnohem těžší.

[Marek Bernát]

Nerobí zo seba blbca. Väčšina toho, na čo poukazuje, je skutočne pravda. Ak nie, prosím dodaj funkčný interpreter v Jave do 200 riadkov kódu, alebo si nechaj tie žvásty pre seba

Myslím, že si to nepochopil (čítal si to vôbec?). Ten článok nie kritikou Javy, ale hlavne ilustruje, ako pohodlne sa programuje v Haskelle kompilátor, čo je relatívne netriviálna činnosť a v bežných jazykoch dosť problematická. Napríklad v C si môžeš napísať pomerne ťažkopádny lexer + parser (s tým, že nebude extra rozšíriteľný, ak na to nemyslíš od začiatku), prípadne siahnuť po lex/flex/bisone, s ktorými sa aj tak moc dobre neintegruje, atď. V Jave je to podobné.

[Filip Jirsák]

Ten článok nie kritikou Javy, ale hlavne ilustruje, ako pohodlne sa programuje v Haskelle kompilátor, čo je relatívne netriviálna činnosť a v bežných jazykoch dosť problematická.

V tom případě jsou v tom článku ale zbytečné příklady toho, jak by se to samé dalo špatně napsat v Javě. Pak ten článek spíš vzbuzuje pocit, že nemá vychválit Haskell, ale autor si potřeboval kopnout do nějakého jiného jazyka, kterému nerozumí. Což poněkud zpochybňuje věrohodnost celého článku.

[Marek Bernát]

To ma mrzí, že ste to zobrali takto. Môžete teda dať príklady niektorých vecí v Jave, ktoré by sa dali napísať lepšie?

[Filip Jirsák]

První příklad (AST) je poněkud umělý, ve skutečnosti by asi od těch tříd asi chtělo víc, než pamatovat si jednu hodnotu – podle toho by pak záleželo na implementaci. Pokud jde opravdu jen o uchování seznamu hodnot, stačí obyčejný List<Object>.

Druhý příklad (tisk) je zřejmě pokus o optimalizaci, jinak by se použilo klasické sčítání řetězců (které nahradí kompilátor StringBufferem, i když v tomto případě by asi neodhadl, že má pro všechno použít jeden StringBuffer). V Javě 1.5 by se ale místo StringBufferu použil StringBuilder, pro iterátor by se použily generiky (takže by odpadlo přetypování, které je mimochodem zbytečné i ve starších verzích, protože toString() je metoda předka Object). No a udělat z toho knihovní funkci a použít ji v one-lineru by taky nebyl problém.

Ve vykonávání kódu je if přes typy pěkná prasárna, pro vyjádření omezené množiny možností má Java typ Enum, navíc v tomto případě je každý typ reprezentován jinou třídou, takže výkonný kód má být součástí oné třídy (to je ale základ OOP).

Celé to srovnání je postavené na hlavu, pokud bych chtěl napsat rychle interpret na 200 řádků, nebudu ho psát v Javě; pokud by autor naopak chtěl použít Javu, třeba pro množství knihoven a pro to, že by interpret byl součástí nějakého většího projektu, pravděpodobně by si zase nastudoval alespoň základy OOP postaveného na třídách.

[podlesh]

Vesměs detaily. Mně osobně docela stačí, že používá copy-paste (kód uvnitř cyklu a jeho speciální případ mimo cyklus), to je docela těžký hřích.

[Marek Bernát]

Prečo od nich potrebujete niečo viac? Pre interpreter je to dostačujúce. Keď máte v texte po zlexovaní token <int, 5>, tak Vás nič iné nezaujíma. List <Object> nie je ale vôbec analóg [Expr] v Haskelle a prišli by ste o kontrolu typu. Do List<Object> môžem narvať všetko, do [Expr] len skutočné výrazy. Proste na toto je Java nevhodná -- núti Vás písať veľa tried, ktoré nič nerobia. Pravda, tu zlyháva OOP obecne. Na manipuláciu symbolov je holt ďaleko vhodnejší funkcionálny prístup.

Ten príklad s výstupom sa mi tiež nepozdáva. Ale článok je z roku 2006, možno vtedy bola situácia iná (?).

Ten if je síce prasárna, ničmenej, má ilustrovať to, že Java nemá pattern matching (čo je ďaleko obecnejší polymorfizmus, než ten OOP). Ale súhlasím, že by sa to dalo spraviť ako Expr.doSomething(world) metódou, ktorú by implementovali všetci potomkovia, takže to tiež nie je extra dobrý príklad.

Uvedomte si, že Haskell nie je žiadny skriptovací shellový jazyk, ale je to silný statický jazyk rovnako ako Java a je vhodný prakticky na ľúbovoľnú úlohu. Prečo teda v tej Jave nebudete písať ten interpreter na 200 riadkov a rýchlo? Odpoveď je jednoduchá: _nedá sa to_. Proste v tejto oblasti je Java ako jazyk horšia než Haskell. Nič viac a nič menej a očividne sa zhodneme.

[podlesh]

Ano, shodneme - ale jen dokud z toho nebudete zase dělat flamewar.

[Marek Bernát]

Prečo by som z toho mal robiť flamewar? Ja som postoval link na článok, o ktorom si myslím, že je dosť dobrý. Vám sa nepáči, ok -> ale v tom prípade chcem počuť konkrétne argumenty a môžeme ich rozobrať ako civilizovaní ľudia. Od Vás som zatiaľ nepočul ani jeden argument, ale za to kopu kecov, ktoré s článkom v podstate nesúvisia. Takže sa mi s Vami baví skutočne ťažko

[Filip Jirsák]

Prečo od nich potrebujete niečo viac? Pre interpreter je to dostačujúce. Keď máte v texte po zlexovaní token <int, 5>, tak Vás nič iné nezaujíma. List<Object> nie je ale vôbec analóg [Expr] v Haskelle a prišli by ste o kontrolu typu. Do List<Object> môžem narvať všetko, do [Expr] len skutočné výrazy. Proste na toto je Java nevhodná -- núti Vás písať veľa tried, ktoré nič nerobia. Pravda, tu zlyháva OOP obecne. Na manipuláciu symbolov je holt ďaleko vhodnejší funkcionálny prístup.

Buď tam může být opravdu cokoli, pak je Object vhodná reprezentace. Nebo tam mohou být pouze určité typy, a to nejspíš z toho důvodu, že je nutná nějaká další manipulace s nimi – pak bude ale ona manipulace zapouzdřena v kódu toho typu. Ostatně dál v kódu s podmínkou podle typu by přesně tohle autor měl využít. A kdyby to autor celé napsal javovsky správně jako enum, odpadla by mu asi polovina problémů, které v článku s Javou má.

Ale článok je z roku 2006, možno vtedy bola situácia iná (?).

Java 5 byla vydána v roce 2004.

Ten if je síce prasárna, ničmenej, má ilustrovať to, že Java nemá pattern matching

Kdyby se autor raději soustředil na to, co má Haskell, než aby řešil, co nemá Java, kterou neumí… Ve většině případů se pattern matching používá pro výběr z omezené množiny případů, a k tomu má Java typ Enum. Ostatní případy jsou pro Javu nezajímavé a je případně nutné je opsat extra kódem bez podpory kompilátoru.

Odpoveď je jednoduchá: _nedá sa to_. Proste v tejto oblasti je Java ako jazyk horšia než Haskell. Nič viac a nič menej a očividne sa zhodneme.

Na tom se asi shodneme, problém je v tom, že článek vyvolává dojem právě opačný. Člověk, který zná Javu, si může snadno myslet, že je to přesně opačně – jinak by přece autor článku nemusel kód v Javě tolik zprasit.

[podlesh]

V tomto případě nebude Object správná reprezentace, správně to bude Expr - což bude nějaký interface (či abstraktní třída). Enum by byl vhodný jen pro základní LISP, pro nějaké rozšířené možnosti jako má třeba CL by se muselo počítat s rozšiřováním.

Zrovna v tomto případě je myslím možné dobře použít jak objektový přístup se single-dispatch, tak funkcionální přístup s pattern-matching. Když pak dáme stranou ukecanost konkrétních jazyků (určitě existuje OOP jazyk ve kterém se to celé dá napsat na 200 řádek), tak jako výhodu funkcionálního bych viděl především to, že je celá funkčnost interpreteru uvedena na jednom místě a tedy mnohem přehlednější, než když je "rozstrkána" po různých metodách různých objektů.

[Marek Bernát]

Nemôže tam byť "cokoli". Je to interpreter. Môžu tam byť len tie výrazy, ktoré interpreter skutočne podporuje. Ale s tým prístupom funkcionalita do objektov súhlasím, to je v tých jeho príkladoch riešené škaredo.

 

V tom prípade tomu fakt nerozumiem a tiež mi z toho vyplýva, že tú Javu buď neovláda, alebo ju chcel úmyselne zhodiť. Problém je, že ten človek je fakt skvelý programátor a slušný človek a ani jedno z toho sa mi k nemu nehodí. Takže nadšenecký zápal vyzerá najpravdepodobnejšie.

 

To sa ale mýlite. Pattern matching sa využíva na oveľa širšiu množinu prípadov. V Haskelle sa dá matchovať voči ľubovoľným konštruktorom daného typu.

Napríklad pre čísla:

f n = ..

f 5 = ..

A ak je argument komplexnejším typom, napríklad zoznamom, ktorý má konštruktory [] a x:xs, tak môžete spraviť

f [] =

f (x:xs) =

Atď, ak máte zoznam zoznamov a chcete akceptovať ľubovoľný výraz tvaru [[x, 5, y, z ..], ..], s tým že automaticky pomenujete jeho podvýrazy, tak môžete spraviť

f (x:(5:ys)):ys

Je to skutočne sila, zvlášť pri zložitejších typoch a prirovnávať to k Enum je zúfalé. Takže je dobre, že tam ten príklad dal, aspoň ste dostali nepriamo možnosť sa naučiť niečo nové

 

Súhlas, je škoda, že tú Javu tak (úmyselne alebo neúmyselne) zhadzuje.

[podlesh]

A jak asi jinak? Nejenom že tam dal zcela zbytečné příklady, dal tam minimálně jeden za který by se měl hanbou propadnout. Kdyby si to celé odpustil, bylo by to mnohem lepší.

Ale samozřejmě to nepochopí flamer od přírody, který ostatní jenom považuje za blbce.

[Marek Bernát]

Súhlasím, že si tie príklady s Javou mohol odpustiť, ale nesúhlasím s tým, že na nich nie je žiadna pravda, viď môj komentár vyššie.

Nepovažujem nikoho za blbca, ak mi k tomu nedá dostatočný dôvod. V tejto diskusii napríklad zatiaľ nikoho. Takže si tie urážky ráč odpustiť

[podlesh]

Súhlasím, že si tie príklady s Javou mohol odpustiť, ale nesúhlasím s tým, že na nich nie je žiadna pravda, viď môj komentár vyššie.

No, žádná pravda... Některé ty příklady jsou v pořádku (třeba ten s těmi datovými typy), ale konkrétně ten s tím toString() je úplně mimo (tj. nejenom že neilustruje to co by měl, ale ještě je dost hnusný, a je otázka zda to není záměrně).

Nepovažujem nikoho za blbca, ak mi k tomu nedá dostatočný dôvod. V tejto diskusii napríklad zatiaľ nikoho. Takže si tie urážky ráč odpustiť

No, jak jsem si již ráčil všimnout, tak ten práh důvodů je poměrně nízký. V mém případě je zase docela nízký práh vztahovačnosti

[Marek Bernát]

Ok, to sa zhodneme. Ad zámerne -- to tu nevyriešime, ale môžete mu keď tak napísať mail. Komentáre k článkom AFAIK uvíta

Hm, ja sa síce občas nevyjadrujem nijak pekne, ale skutočne to neznamená, že by som niekoho považoval za blbca Ten práh náhodou nie je úplne nízky, ale keď sa chce niekto baviť o programovaní obecne a povie, že 2 roky robí v Jave a iný jazyk nevidel (nie je prípad tejto diskusie, ale už sa mi to stalo), a napriek tomu chce viesť siahodlhé debaty o teoretickej informatike a jazykoch vôbec, tak to už mi dôvody vcelku dáva

[podlesh]

No, tak se omlouvám, nechal jsem se trochu unést.

[JS]

Samozrejme, ze to srovnavaji s Javou. Java je nejpouzivanejsi jazyk. Kdyby bylo nejpouzivanejsi C, C++ nebo C#, srovnavali by se s nim.

[podlesh]

Myslím že jsi nepochopil můj příspěvek (četl jsi ho vůbec?), takže si svoje žvásty nech pro sebe.

[Marek Bernát]

Čítal: píšeš o nadšeneckých člankoch a strhávaní druhého a nemáš v texte ani jeden konštruktívny komentár, len samé obecné žvásty. Vysvetlíš mi, ako to súvisí s článkom, na ktorý som odkazoval? Alebo to nemalo súvisieť nijak a bol to úplne OT komentár?

[podlesh]

Ano, byla to obecná poznámka, která ovšem 100% platí v tomto případě. Co není jasné?

Takže pro ty natvrdlejší: celé ty "příklady" s Javou by v článku vůbec být neměly, výrazně by to zvýšilo jeho úroveň.

[Marek Bernát]

Nie, bola to demagógia, ktorá pomocou ilustrácie obecného a iného príkladu, chce aplikovať tú obecnosť na tento prípad a vôbec to nefunguje. Takže asi tak

Nemuseli by tam byť, to sa zhodneme. Ale niečo na nich je. Už len preto, aby si sa zamyslel, ako ich urobiť lepšie (stále máš k tomu možnosť a stále si to neurobil -- kecáš, kecáš, ale skutek utek ), ak sú teda tak hrozné. Pokojne ich tu môžeme rozobrať. Ty namiesto toho používaš len ad hominem voči autorovi článku a voči mne, z mne neznámeho dôvodu.

[podlesh]

Demagogie by to byla, pokud bych chtěl na těchto základech popírat samotný základní význam toho článku. Ale to tak není. Se samotným základním obsahem článku zde v podstatě nikdo nepolemizuje, takže se zcela zbytečně rozčiluješ a požaduješ dvěstěřádkový interepreter v Javě.

Taktéž ad hominem je něco jiného.

Nad příklady se zamyslet můžu.

[Marek Bernát]

Ok. Ok. Ok

[Filip Jirsák]

Ale to je přece základní princip článků porovnávajících dva různé programovací jazyky. V jednom jazyce se napíše program špatně a v druhém špatně, případně – pokud se má porovnávat rychlost výsledného kódu – se napíše druhý program, který dělá něco úplně jiného (a kupodivu vždy pomalejšího). A pak se to vydává za to, že první programovací jazyk je perfektní a druhý je fuj. že z toho mají programátoři, který opravdu znají druhý jazyk, legraci, to nevadí, protože oni přece programují v tom fuj programovacím jazyce a není potřeba je brát vážně.

[Marek Bernát]

Príliš generalizujete. Mám pocit, že ste ten článok nečítali.

Ja Vás beriem úplne vážne, vyzeráte ako vzdelaný človek (), ničmenej, je fakt, že niektoré jazyky sú lepšie ako iné (minimálne na niektoré typy úloh), takže obecne nevidím nič zlé na tom niečo porovnávať. V následnej diskusii sa môžu miesta, kde došlo k nedorozumeniu vysveliť. Ttakže ešte raz poprosím o konštruktívne argumenty a nie o generalizujúce žvásty .

[Filip Jirsák]

Sice generalizuju, ale na zmíněný článek to sedí. Pokud jsou některé jazyky obecně lepší, než kterékoli jiné, nechápu, proč se nepoužívají pouze ty (nebo pouze ten jeden nejlepší jazyk). Já bych spíš řekl, že některé jazyky jsou pro některé úlohy lepší, než jiné jazyky. Ale ukazovat to na tom, že napíšu trochu podobný kód v jiném jazyce, u kterého neznám ani základy, není šťastný postup.

[Marek Bernát]

Dobré jazyky sa nepoužívajú z rôznych dôvodov. Napríklad, z toho že ten dobrý jazyk obvykle dovoľuje robiť viac abstrakcií. Lenže z toho automaticky plynie, že človek musí disponovať dostatočnou inteligenciou, inak sú mu tie abstrakcie na nič a dokonca môžu mu ešte uškodiť, ak nevie, čo robí. Takže áno, "moje" lepšie jazyky, sú lepšie len pre inteligentných ľudí. Pre priemerných (ktorých je proste väčšina už zo štatistiky, nemyslím to pejoratívne) asi nie. Možno by som na to mal explicitne upozorňovať

Jasné, že ide aj o konkrétnu úlohu. Ale v tom zasa silné (v zmysle abstrakcie, nie typovosti) jazyky pomáhajú tým, že sa dajú pohodlne vytvoriť DSL pre danú úlohu. Hoci popravde, ešte som nevidel žiadnu aplikáciu Javy, kde by nebol vhodnejší Lisp/Haskell (ak nie ste vyložene nútený) :-/ Problém je, že na tomto fóre sa nenájde nikto s dostatočnou skúsenosťou vo všetkých zmienených jazykoch, aby nás rozsúdil.

S tým kódom celkom súhlasím, nebolo to šťastné.

[Miloslav Ponkrác]

Ono nejde jen o kvalitu jazyka. Ani o inteligenci.

Ono jde normálně stupidně jednak o určité záruky. Prorazíte v bance spíše s Javou, nebo s Haskellem? Prorazíte v raketoplánech spíše s Adou, nebo s Haskellem? Jaké můžete dát záruky za kvalitu programu v Haskellu a jeho kompilátoru/interpreteru?

Pak jde stupidně o knihovny toho jazyka. Řada skvělých jazyků mají knihovnu na úrovni, která to všechno sráží dolů.

Pak jde o udržovatelnost toho kódu. Pokud samotné programování chce nadměrně inteligentního jedince, pak to s udržovatelností na 99% bude velmi na štíru.

Aby nedošlo k omylu, já s Vámi v principu souhlasím.

Já sám osobně často programuji v nezvyklých jazycích, pokud si mohu vybrat. Ale vím, že dobrý jazyk neznamená dotáhnutý jazyk. Řada jazyků se diskvalifikuje také tím že nemá žádný závazný standard, což pro praxi (zejména pokud očekáváme dlouhodobou údržbu projektu) je nesmiřitelné mínus. Navíc je v poslední době moderní tvrdit, že zpětná kompatibilita je přežitek (Python, Ruby), což žádný soudný člověk do praxe nenasadí tak, kde o něco jde.

Pak také očekáváme dotaženost jazyka (kvalita kompilátoru/intepreteru, dotažené, dobře navržené a bohaté knihovny). Opět obrovský problém mnoha dobrých jazyků. A je nutné je pak odpískat, nebo dodělat.

[Marek Bernát]

Súhlasím s Vami na 100%. To, o čom hovorím ja, sú teoretické výhody. V praxi je to tak, ako hovoríte Vy. Ničmenej, možno by ste sa čudovali, ako často sa v kritických aplikáciách používajú práve jazyky ako Lisp, ML a pod. Dobrým príkladom je určite aj Erlang, ktorý patrí medzi tie pokročilejšie jazyky a myslím, že čo sa robustnosti a stabilnosti týka, tak sa mu nič iné nevyrovná (pravda Adu moc nepoznám a zrejme sa v NASA nepoužíva len tak zo srandy).

[Miloslav Ponkrác]

Ono se v kritických aplikacích dá použít leccos. Otázka je, kdo za to dal záruky, a kdo ponese odpovědnost, když se něco stane.

LISP se dřívě používal skoro všude. Býval dřív hodně rozšířeným jazykem a řada aplikací ze starší doby ho má jako připomínku ducha té doby jako skriptovací jazyk (AutoCAD, emacs, …).

Ada je robustní a stabilní až moc. Je velmi resitriktivní a kompilátor dostává o několik řádů více informací o Vašem kódu a záměrech, než v jiných jazycích. Navíc se dá přeložit jak na jednočip s několika KB RAM, tak na enterprise aplikaci. Její možnosti portability jsou neuvěřitelné a těžko se s tím měřit. Ada vznikla přímo na zakázku NASA.

On v zásadě není problém použít jakýkoli dobrý jazyk, jehož autor není vůl. To jest napíše závaznou normu jazyku, ctí maximálně zpětnou kompatiblitu v dalších verzích, navrhne jazyk solidně a solidní knihovny. Jenže to je bohužel minimum jazyků.

Takový LISP je perfektně přenositelný a svojí normu má. Není problém ho použít, byť se to dnes děje zřídka. Ale co s Pythonem? Co s Ruby? Vždyť oba to přeorávají natolik, že s tím nic dlouhodobého neuděláte. Co s Eiffelem, který je roztříštěný?

[Marek Bernát]

Myslíte to ako riešenia na zakázku aj so zmluvou? Jasné, že v open source Vám nikto záruky nedá. Pre Lisp máme napríklad LispWork a Franz. Jak je to inde netuším, ale zrejme sa pár odborných firiem živiacimi sa profesionálnymi kompilátormi + knižnicami živí.

Lisp sa stále používa na veľa miestach, nie je to len pripomienka doby. Nedávno som čítal o softvére na dizajn a testovanie lietadiel. Ale máte pravdu, že nijak extra sa nerozšíril. Nie že by nebol vhodný na komerčné uplatnenie, ale jednak o ňom nikto nevie a jednak tí, čo o ňom vedia, sú obvykle buď ľudia z univerzít, alebo ľudia z AI (a to je možno jedna a tá istá množina )

O niekoľko rádov viac? Čo som zbežne pozeral zdrojáky, tak to vyzeralo ako trochu ukecanejší Pascal. Tá prenositeľnosť sa ale netýka jazyka, ale kvality kompilátorov. Pravda, jazyk je len tak dobrý, jak dobrý je kompilátor

Súhlas

Presne tak, Lisp je v tomto ok. Na druhej strane, už by potreboval po tých 20+ rokov vydať nový štandard, ktorým by sa odstránil bordel -- toho je tam tak 50% -- a veci by sa mohli trochu učesať. GLS ešte žije, tak snáď to nie je úplne nereálne.

K tomu Pythonu a Ruby sa moc nevyjadrujem, nie sú to zlé jazyky, ale človek musí vedieť, čo od nich chce. Sú vhodné na mnohé nasadenia, sú živelné, vyvíjajú sa a to je určite dobre. Komerčnú aplikáciu s 10 rokmi podpory by v nich asi písal len blázon, ale to snáď nie je jediný sektor, kde sa jazyky využívajú. Eiffel nepoznám vôbec.

[Miloslav Ponkrác]

Ada je ukecanější Pascal, ale s mnohem geniálnějšími vlastnostmi. Je to téměř jediný jazyk, který vyřešil třeba přenositelnost na 100%.

Navíc Ada nemůže mít a nemůže existovat nekvalitní kompilátor, nebo nevyhovující normě. Pokud takový kompilátor napíšete a nazvete ho Adou, pak máte velmi rychle na krku soud. Každý kompilátor Ady musí projít sadou tvrdých testů. Ba dokonce kompilátor nesmí mít nestandardní extenze!

Jakou větší záruku kromě striktnosti jazyka chcete? Na Adě je každý kompilátor důkladně prověřený, všechny kompilátory se chovají naprosto stejně a 100%ně vyhovují normě. Kromě toho Ada je velmi bezpečný a nesmlouvavý jazyk se 100%ní přenositelností. Ani Java třeba není 100%ně přenositelná.

Tím nehájím Adu, moc jsem v ní taky nenapsal, ale ty záruky od jazyka i kompilátoru jsou úžasné.

Ohledně LISPu si myslím, že mu hodně uškodila snaha rozvíjet Scheme.

Osobně si myslím, že starší jazyky, které do 10 let nevydají novou normu (vyšší verzi jazyka) už nemají moc šanci jazyk dále měnit. C++ vydává novou normu, nicméně její význam bude podle mě spíše teoretický. Nová verze LISPu by uspěla jen, pokud by jí zaštítilo dost významných jmen. Ostatně samotné Céčko C99 se podle mě také generálně nerozšíří mimo gcc. Většinu programů po všechny věky bude nutné psát v C89.

Ideální by bylo, kdyby LISP našel pár killer aplikací, které by ho povznesly. Kdysi jsem se ochomýtal kolem paralelních programů v LISPu. Ta jednoduchost nad LISPem byla úžasná. Nejsem si jist, jestli nějaký jazyk dosáhl té elegance paralelního programování tak snadno.

Python a Ruby jsem uvedl jako příklad jazyků, které jsou pro větší nasazení v praxi nepoužitelné právě díky živelným zásahům a nestabilitě syntaxe jazyka i dalších věcí kolem.

[Marek Bernát]

Aha, tak ak je to takto striktné, to potom áno, to je jazyk, v ktorom sa oplatí už robiť aj tie vesmírne lode

100% vyhovujú norme? To asi nie. Dokázať, že nejaký väčší kus kódu robí presne to, čo má, a nerobí nič iné, je zhola nemožné. Netvrdím, že nemôžu byť tie kompilátory brutálne preskúmané a otestované, ale tých 100% znie fakt naivne.

Čo je 100% prenositeľnosť? Funguje na všetkých architektúrach, ktoré boli kedy navrhnuté? Alebo v čom má lepšiu prenositeľnosť ako napríklad C?

To je zaujímavý názor s tými štandardami. IMHO Lisp ešte nepovedal posledné slovo, tým jak sa moderné jazyky k nemu stále viac a viac približujú, tak možno bude dostupnejší širšiemu spektru ľudí a znova ožije. Maybe... Čo sa C týka, tak to je určite mŕtve z tohoto hľadiska. C je totiž malý a relatívne čistý jazyk, odrážajúci jeden typ hardvéru, a nejak nevidím dôvod na ňom niečo meniť.

To by pravda bolo ideálne, ale nejak si neviem predstaviť, ako by taká killer aplikácia mala vyzerať a ako by ste donútili ju používať bežného človeka. Napríklad ja za killer aplikáciu považujem Emacs. Je síce napísaný v ELispe a na niektorých miestach v kóde zamrzí, že to nie je CL, ale inak je to skvelý nástroj na všetko možné. Ale trpí rovnakým neduhom ako Lisp samotný, totiž že je "made by aliens, for aliens"

Paralelné programovanie akého druhu máte na mysli? Dnes fičí Erlang, kde každé vlákno má vlastný stav, nemôže meniť stav cudzieho vlákna a celá synchronizácia sa deje pomocou posielania správ. A knižnice pre takéto erlang-like vlákna sú už v každom lepšom programovacom jazyku (napríklad do Lispu nie je problém takúto abstrakciu dorobiť). Alebo myslíte automatickú paralizáciu čisto funkcionálnych programov, ako má Haskell? Alebo myslíte bežnú mutex/semaphor paralizáciu (IMHO prežitok)?.

[Miloslav Ponkrác]

Dokázať, že nejaký väčší kus kódu robí presne to, čo má, a nerobí nič iné, je zhola nemožné. Netvrdím, že nemôžu byť tie kompilátory brutálne preskúmané a otestované, ale tých 100% znie fakt naivne.

Ale u Ady nic takového se nedokazuje. Tvrdými testy se jen dokazuje, že kompilátor přeloží, co přeložit má. Můžeme říci, že ke 100% se můžeme jen přiblížit, tak řekněme, že na 99,999999%. Mimochodem, v žádném schváleném kompilátoru Ady se nikdy neobjevila žádná chyba, která by způsobila chybná překlad.

Čo je 100% prenositeľnosť? Funguje na všetkých architektúrach, ktoré boli kedy navrhnuté? Alebo v čom má lepšiu prenositeľnosť ako napríklad C?

100% přenositelnost je naprosto shodná funkce, když stejný zdroják přeložíte na levný jednočip s pár KB paměti, nebo na PC, nebo na superpočítač, a to beze změny jediného písmenka ve zdrojáku a bez jakéhokoli podmíněného ifu závislého na platformě ve zdrojáku Ady. Samozřejmě s ohledem na omezení platformy. V zásadě napsat nepřenositelný program v Adě chce moc a moc úsilí. Ada Vám nedává fakticky téměř šanci.

IMHO Lisp ešte nepovedal posledné slovo,

Jako princip asi ne, ale jako jazyk nevím.

Čo sa C týka, tak to je určite mŕtve z tohoto hľadiska. C je totiž malý a relatívne čistý jazyk, odrážajúci jeden typ hardvéru, a nejak nevidím dôvod na ňom niečo meniť.

C je hlavně přenositelný assembler, nic víc, a nic míň. A ve stejném duchu se používá. C odstranilo nutnost použít asm tak, kde by ho bez C bylo nutné použít.

Killer aplikace je aplikace, kterou by nebylo možné snadno zvládnout standardními procedurálními/objektovými jazyky. Funkcionální jazyky mají některé vlastnosti, které v určitých situacích jsou výhodnější, ale zatím nebyly až tak moc prakticky uplatněny.

Erlang bohužel neovládám. Právě, že v době cca před 20 lety mnoho jazyků mělo nativní podporu paralelismu. Bylo to nesmírně výhodné, komfortní a efektivní. Programátor ani moc nevěděl, co kompilátor přeloží, jen kompilátoru řekl něco o stavech, kde to chce mít atomické, případně co a jak chce vykonat paralelně a zbytek byla práce kompilátoru. Pak přišly jazyky typu C, Java, C#, které zavedly ideu co nejblbnějšího a co nejneschopnějšího jazyka, který v zásadě umí kulové a zvládne ho i baba, co dělal celý život ve vrátnici. Jenže tím se paralelní programování řešilo hrozně low level a bylo to neefektivní, značně chybové a řada lidí to dodnes nezvládá. To jsou ty různé mutexy/semafory a další.

 

 

 

 

[Marek Bernát]

> Ale u Ady nic takového se nedokazuje. Tvrdými testy se jen dokazuje, že kompilátor přeloží, co přeložit má. Můžeme říci, že ke 100% se můžeme jen přiblížit, tak řekněme, že na 99,999999%. Mimochodem, v žádném schváleném kompilátoru Ady se nikdy neobjevila žádná chyba, která by způsobila chybná překlad.

Ok

> 100% přenositelnost je naprosto shodná funkce, když stejný zdroják přeložíte na levný jednočip s pár KB paměti, nebo na PC, nebo na superpočítač, a to beze změny jediného písmenka ve zdrojáku a bez jakéhokoli podmíněného ifu závislého na platformě ve zdrojáku Ady. Samozřejmě s ohledem na omezení platformy. V zásadě napsat nepřenositelný program v Adě chce moc a moc úsilí. Ada Vám nedává fakticky téměř šanci.

Aha, takže takto ste to mysleli. Ono, prenositeľnosť dosť súvisí aj s tým, aká množina architektúr je podporovaná. Ak len jednoprvková, tak nie je problém zaistiť 100% prenositeľnosť

> Jako princip asi ne, ale jako jazyk nevím.

Ako princíp určite nie, ako jazyk sa necháme prekvapiť. Ničmenej, komunita stále žije a prekvapujúco dnes nemá priemerne 70 rokov, ale stále je najviac ľudí s vekom 20--30

> C je hlavně přenositelný assembler, nic víc, a nic míň. A ve stejném duchu se používá. C odstranilo nutnost použít asm tak, kde by ho bez C bylo nutné použít.

Presne tak. Len ľudia si to občas neuvedomujú; len pred pár dňami som musel jednému človeku vysvetľovať, že C je skutočne extrémne primitívny jazyk a aj tak mi asi neuveril -- veď je v tom predsa napísaný linuxový kernel, ako by to mohlo byť primitívne...

> Killer aplikace je aplikace, kterou by nebylo možné snadno zvládnout standardními procedurálními/objektovými jazyky. Funkcionální jazyky mají některé vlastnosti, které v určitých situacích jsou výhodnější, ale zatím nebyly až tak moc prakticky uplatněny.

Aha takto. No, tak pomerne veľká množina umelointeligentných aplikácií je v Lispe (z reálnych príkladov ma teraz napadá Festival tts, ten by mal byť v Scheme, ak sa nepletiem -- btw, neviem, či sa bavíme o Lispe ako takom, alebo len CL) a tiež komerčné datábazy znalostí sú v Lispe, ale s AI to vyzerá bledo a dnes už asi nikto neverí, že sa podarí inak ako zázrakom napodobniť ľudskú inteligenciu. Inak štandardnými postupmi dosiahnete všetko aj v tom C, len sa holt viac upíšete, ale ak to ľuďom nevadí (a to nevadí, stále sa C veselo používa) a máte takých programátorov kopu (to máte), tak nie je problém všetko vyrobiť aj v C.

> Erlang bohužel neovládám.

Tiež Erlang moc neovládam, len som čítal nejaké články, plus viem, že je nasadený už roky v kritických telekomunikačných aplikáciách, kde si nejaké výpadky nemôžu dovoliť a svete div sa, ono im to funguje Takže sa časom chcem Erlangu chcem pozrieť na zúbok, zatiaľ len šírim osvetu

> Právě, že v době cca před 20 lety mnoho jazyků mělo nativní podporu paralelismu. Bylo to nesmírně výhodné, komfortní a efektivní. Programátor ani moc nevěděl, co kompilátor přeloží, jen kompilátoru řekl něco o stavech, kde to chce mít atomické, případně co a jak chce vykonat paralelně a zbytek byla práce kompilátoru. Pak přišly jazyky typu C, Java, C#, které zavedly ideu co nejblbnějšího a co nejneschopnějšího jazyka, který v zásadě umí kulové a zvládne ho i baba, co dělal celý život ve vrátnici. Jenže tím se paralelní programování řešilo hrozně low level a bylo to neefektivní, značně chybové a řada lidí to dodnes nezvládá. To jsou ty různé mutexy/semafory a další.

To som nevedel, že v minulosti bola podpora paralelizácie v jazykoch lepšia -- mal som za to, že low-level to bolo odjakživa, resp. aspoň od dôb čo Dijkstra vymyslel semafór O ktoré jazyky konkrétne sa jednalo?

[Miloslav Ponkrác]

To som nevedel, že v minulosti bola podpora paralelizácie v jazykoch lepšia -- mal som za to, že low-level to bolo odjakživa, resp. aspoň od dôb čo Dijkstra vymyslel semafór  O ktoré jazyky konkrétne sa jednalo?

Když jsem před cca 20 lety začínal vážněji s programováním, tak programovací jazyky veskrze byly složitější, než dnes, ale zato programátorovi vydatně pomáhaly.

Pak přišlo C a Java a nastolilo se paradigma, že čím blbější jazyk tím lépe (neboť stačí IQ želvy na iluzi, že jste jazyk zvládli) a jazyk pak neuměl skoro nic. Pak přišel trochu kočkopes C++, který právě použil Stroustrup, protože blbost současných jazyků jako C, nebo Java, nebo většina dnešních mu moc nepomáhla, a tak chtěl pořádný jazyk jako za starého času. Který se déle učíte, ale když ho zvládnete, jazyk je vám výrazně nápomocen. Trošku C++ zkazilo to, že musel být extrémně rychlý v produkovaném kódu.

Klidně se můžete podívat do Ady, jakou má podporu paralelního programování. Jen varuji, na dnešní poměry je pojata velmi nezvykle.

Právě že low level to nebylo odjakživa. Právě, že současné jazyky jsou asi jedny z nejblbějších, a v minulosti byly podstatně schopnější (mluvím zhruba o 80tých letech).

Ostatně i jazyk C byl navržen primitivně proto, že jeho autor byl frustrován z pro něj složitého jazyka PL/I, a proto udělal jazyk co nejblbější a nejjednodušší. Mimochodem, PL/I nebyl zase tak špatný jazyk, což dokazuje i to, že řada lidí dnes se ho nehodlá vzdát, přestože je to počin 60tých let.

No a s dnešními mainstreamovými jazyky, které jsou jenom „asm-like“ obálkou, někdy s podporou OOP obálky a tím jsme skončili, se paralelní programování opravdu dělá hodně špatně. Ale věřte, že tomu tak nebylo vždycky. Dnes už spousta lidí věří, že takový jazyk je nejlepší, ale že se u nich programátoři strašně nadřou, to už nevidí, protože nic jiného neznají. Řada lidí pak je překvapena, jak dobře se jim dělá v jazycích, které měly tu odvahu a třeba mírně překročily paradigma, že jazyk má být kretén a vše jsou knihovny. Proto řada lidí nedá dopustit na LISP, nebo třeba se pachtí v Pythonu, či Ruby. A nechce se jim vracet do C, nebo do Javy, nebo do C#. Ani já se nechci do těchto jazyků vracet. Proto je pro mě C++ lowest jazyk, ve kterém chci dělat (protože rychlost výsledného kódu) a řada jiných high level jazyků, které mi budou pomáhat.

 

[xkucf03]

jazyk má být kretén a vše jsou knihovny.

A co je tak špatného na tom, že se hodně věcí řeší pomocí knihoven a ne na úrovni samotného jazyka? Já v tomhle přístupu naopak vidím dvě výhody:

 

• znovupoužitelnost knihoven: když budeme v těch „lepších“ jazycích chtít mít kód znovupoužitelný ve víc projektech, skončíme tak jako tak u knihoven.
• větší pružnost: když zapomeneme dát něco do jazyka, je změna specifikace docela složitý a zdlouhavý proces – ale když to zapomeneme dát do knihovny, stačí jednoduše napsat knihovnu novou.

[happy barney]

"najlepší je jazyk, ktorý nevie skoro nič, iba načítať svoje chovanie z knižníc" ...

[Miloslav Ponkrác]

To je heslo sado-maso salónů?

[happy barney]

pôvodne to bolo myslené ako vtip, ale čím ďalej, tým viac mi to dáva zmysel ... viď váš príklad zoznamov kúsok nižšie

[Miloslav Ponkrác]

A co je tak špatného na tom, že se hodně věcí řeší pomocí knihoven a ne na úrovni samotného jazyka?

Třeba v tom, že hodně věcí se z knihoven načíst nedá. Například porovnejte zadávání seznamů, hašovacích polí apod. se zadáváním téhož v C, nebo jiných jazycích.

znovupoužitelnost knihoven: když budeme v těch „lepších“ jazycích chtít mít kód znovupoužitelný ve víc projektech, skončíme tak jako tak u knihoven.

Takže to co je v jazyce, není použitelné?

větší pružnost: když zapomeneme dát něco do jazyka, je změna specifikace docela složitý a zdlouhavý proces – ale když to zapomeneme dát do knihovny, stačí jednoduše napsat knihovnu novou.

Chcete snad říct, že když se to zapomene dát do jazyka, že nelze napsat knihovnu? Nezlobte se, ale Vaše argumenty jsou poněkud, poněkud …

Zkuste si někdy delší dobu programovat v jazyce, který je něčím jiným, než lehoučkou skořápkou (jako je C, Java, C#, atd.), a už nikdy se nebudete chtít vrátit, věřte mi. Ovšem je třeba překonat pár měsíců, někdy i rok. Ale pak už nikdy neřeknete, že chcete lehkotonážní jazyk. Vaše efektivita bude někde jinde, asi tak ve sféře, které jsou s mainstreamovými jazyky považovány za sci-fi. Nemohu někoho přesvědčit, to chce osobní zkušenost.

[Miloslav Ponkrác]

Vypadlo mi tam slovo: Třeba v tom, že hodně věcí se z knihoven načíst nedá. Například porovnejte zadávání seznamů, hašovacích polí v Pythonu apod. se zadáváním téhož v C, nebo jiných jazycích.

[Marek Bernát]

Osobne si nemyslím, že pre každú blbú dátovú štruktúru by priamo v jazyku mala byť podpora. Je 10 ďalších dosť často používaných štruktúr a pre tie už tú syntax nemáte a do Pythonu sa Vám budú zadávať rovnako ako do C. Jasné, Python dovoľuje overloadovať operátory prístupu k poliam, ale aj tak to nie je žiadna výhra. Mne oveľa viac vyhovuje konzistentnejší lispoidný prístup. A zrovna mapy sa zadávajú v Lispe rovnako dobre ako v Pythone vďaka keyword argumentom. Zoznamy ani nemá zmysel spomínať. Ale ak máte exotickejšiu štruktúru, tak už si môžete povedať sám, akú má mať v Lispe syntax jej zadávanie. Podobne v Haskelle nie sú tieto typy ničím špeciálnym a keby v jazyku neboli, tak si ich všetky nadefinujete. Aby som to zhrnul, Python je pre mňa len trochu uhľadenejšia Java. Je to v mnohom ďaleko lepší, ale objektívne trpí úplne rovnakými fundamentalnými nedostatkami (PEP/JSR) a spoliehanie sa na osvieteného diktátora (Guido/Sun) a nedovolenie programátorovi, aby myslel sám a vymýšľal si vlastné abstrakcie.

[xkucf03]

Kéž by měl Python statické typování.

[Marek Bernát]

Nerozumiem, prečo s kolegom nesúhlasíte. Podľa mňa je správne mať toho čo najviac v knižniciach. Napríklad celý Lisp je takto postavený a nie je problém si pridať vlastné knižnice implementujúce ľubovoľnú vec, ktorá je v iných jazykoch trvalou súčasťou core jazyka. IMHO práve táto sloboda nechať programátora upraviť si jazyk k svojmu obrazu je to, čo robí z Lispu najlepší jazyk pod slnkom Ale nie je to len o syntaxi, ale o abstrakciách všeobecne. Čím silnejšie abstrakcie jazyk ponúka, tým menej toho potrebujete v jazyku a stačia knižnice. Naopak, jazyky ako Java majú toho v jazyku zbytočne moc a moc. A áno, je problém pridať knižnicu, keď to nemáte v jazyku. Ako do Javy pridáte knižnicu, ktorá podporuje lambda funkcie? Asi jedine tak, že JSR a 5 rokov si počkáte

[xkucf03]

Například porovnejte zadávání seznamů, hašovacích polí apod. se zadáváním téhož v C, nebo jiných jazycích.

A je to až takový problém? Zadávat prvky pole nebo seznamu pomocí jedné metody? Chápu, že pokud je tato operace řešena zvláštní syntaxí, stačí na ekvivalentní zápis méně písmenek. Ale vždyť já tohle vkládání mám v daném kusu kódu jen jednou, proč by mi mělo vadit, že musím volat metodu? Nejsem příznivcem míchání kódu a dat – takže data (obsah) seznamu budu odněkud načítat (DB, soubor atd.) a v kódu budu mít cyklus, který obsahuje ono přidávání – a jestli je to metoda nebo nějaké pole[] = hodnota jako v PHP je mi úplně jedno.

Šlo mi trochu i o to, že když si člověk zvykne, že je prakticky všechno v knihovnách, nedělá mu to velký problém – pokud je něco v jazyce a něco v knihovnách, je to méně přehledné. (ale nechme to stranou).

O zbytku se hádat nechci – asi bych fakt měl vyzkoušet jiné jazyky než javu, C++, C# a pár dalších podobných. Jen si na to najít čas…

[Josef Kufner]

Možnost zapsat 1D a 2D data elegantně v kódu umožní zkrátit mnohé algoritmy i o více než 3/4. Taková malá tabulka, která obsahuje přehledně zapsané koeficienty pro algoritmus hned pod ní, je mnohdy velmi šikovná věc, hlavně při vícesměrovém procházení něčeho. A zrovna v Javě je tohle obrovský nedostatek.

[Marek Bernát]

3/4!? Mohol by si dať nejaký príklad? Ja viem o prípadoch, kedy sa dĺžka algoritmu dá skrátiť podstatne, ale rozhodne nesúvisí s nejakou ad-hoc syntaxou, súvisí s tým, že daný jazyk je proste ďaleko expresívnejší. Viď 2-riadkový quick-sort v Haskelle, oproti typickým 10 až 20 riadkom v C...

[Josef Kufner]

Kdysi dávno (více než 5 let nazpět) jsem psal piškvorky a potřeboval jsem si zkontrolovat, zda vznikla přidáním křížku či kolečka pětice, pak také nějak hodnotit možné tahy. V takových případech je potřeba projít kousek 2D pole v několika směrech a počítat. Buď můžeš pro každý směr napsat vlastní cyklus nebo napsat jeden, který použije tabulku s několika +1, 0 a -1. Tehdy jsem napsal varianty obě (v tomto pořadí) a ten rozdíl jak v přehlednosti tak v stručnosti a chybovosti byl celkem drastický.

Další a častější případ jsou různé mapovací tabulky, které dokážou v určitých případech nahradit ošklivé a rozvleklé switche a ify. A právě v těhle případech je potřeba mít možnost nějak efektivně zapsat ten kousek dat (a externí soubor nepřichází v úvahu), protože když to nejde, tak se skončí u toho rozvleklého switche.

[Marek Bernát]

Nehnevaj sa, ale toto je blbý príklad Ten kód sa ti skrátil proste preto, že si odstránil kopu duplicít. Vôbec nejde o to, že tá tabuľka sa ľahko zadáva. Aj keby sa zadávala ťažko, tak by to bol stále správny prístup, ten kód by sa ti skrátil a už vôbec nemá cenu hovoriť o tom, o čo je menej náchylný na chyby a ľahšie sa udržiava (hoci takýto triviálne write-only algoritmus to nepotrebuje...).

Toto zasa nie je o algoritmoch. Rozvleklý switch budeš mať tak možno niekde v main loop na spracovanie príkazov a pod. To už je otázka konkrétneho designu, či je lepšie to mať všetko konfigurovateľné cez nejakú jednoduchú tabuľku, atď. V C to ale môže byť trochu nepraktické, lebo zložitejší kód v switchi musíš nahradiť funkciou a pointer na ňu vložiť do tej tabuľky. V lepšom jazyku budeš do tej tabuľky môcť dať priamo kód, alebo ho aspoň zabaliť do lambdy.

[Josef Kufner]

Toto zasa nie je o algoritmoch. Rozvleklý switch budeš mať tak možno niekde v main loop na spracovanie príkazov a pod.

Ale i to je algoritmus a mnohdy naprosto klíčový. Zejména v případě jednodušších nástrojů používajících nějakou knihovnu nebo démona poskytujícího data ostatním částem systému.

V C to ale môže byť trochu nepraktické, lebo zložitejší kód v switchi musíš nahradiť funkciou a pointer na ňu vložiť do tej tabuľky. V lepšom jazyku budeš do tej tabuľky môcť dať priamo kód, alebo ho aspoň zabaliť do lambdy.

Právě že tam žádné pointery nestrašily Byly tam opravdu jen koeficienty k tomu cyklu, který to procházel.

Ale i ty pointery v takové tabulce jsou dobrá věc. Zrovna ten main-loop na zpracování příkazů toho může perfektně využít – uděláš tabulku s příkazy, názvy funkcí a dalšími údaji a místo rozvleklého switche máš cyklus na pár řádek a tabulku. Navíc do té tabulky můžeš přidat i nápovědu (popis příkazů) a budeš mít na jednom místě data pro interpret i generátor nápovědy. Vlastní funkce pak můžeš uklidit někam stranou, aby každá měla dostatek prostoru a navzájem si nepřekážely. Asi nemusím říkat, jak to věci zpřehlední.

[Marek Bernát]

Absolútny súhlas, čo najviac jazyka by malo byť v knižniciach. Rýp: ale zrovna Java je v tomto absolútne nahovno, lebo do tých knižníc nedáš nič iné ako funkcie. Keď už tento prístup, tak by to chcelo nejaké možnosti abstrakcie. Napríklad Haskell má implementované výnimky ako knižnicu. V Lispe je obyčajnou knižnicou každá druhá vec, na ktorú sa v Jave čaká 5 rokov. V Jave holt človek má jediný správny model výnimiek a môže sa ísť pásť, ak mu to tak nevyhovuje. Detto všetky ostatné veci v jazyku. Ale tam určite povieš, že je správne, že sa to nedá v tej Jave meniť, lebo všetko je jednotné a designéri Javy sú neomylní bohovia. Ja viem, ja viem, už sme tieto diskusie viedli veľakrát

[xkucf03]

Ad výjimky: jak bys chtěl řešit různorodé výjimky (několik různých implementací) v programu, který je poskládaný z několika knihoven (a každá má jinou implementaci výjimek)?

Jak fungují kontrolované vs. nekontrolované výjimky, pokud nejsou součástí jazyka, ale jsou nezávislými knihovnami?

To mi připomnělo logování: v Javě můžeš použít buď standardní logger, který je součástí Javy, nebo Log4J (samostatná knihovna) nebo ještě několik dalších implementací (taky knihovny třetích stran). A z toho guláše pak moc nadšený nejsem – stačí použít několik knihoven a/nebo spojit několik projektů a rázem máš v programu několik implementací logování – nejen že pak potřebuješ udržovat několik konfiguráků pro různé implementace logovače, ale taky se ti těžko podaří složit nějakou jednu časovou osu v rámci jednoho .log souboru – protože logy z každé implementace logovače nasměruješ do jiného souboru, aby se nepřetahovaly o jeden .log soubor.

Neříkám, že ten standardní logovač je nějaký úžasný, ale stav, kdy v jednom programu mám několik různých implementací logovače taky není zrovna super.

[Marek Bernát]

Njn, to je furt ten večný problém: kompatibilita vs. sloboda. Človek nemôže mať obidvoje Výnimky sú pravda tak fundamentálne, že je ideálne mať ich štandardizované. Ale aj tak je výhoda mať ich v knižnici, lebo si ich môžeš vždy priohnúť, ak to náhodou potrebuješ. Aspoň pre interné projekty, ktoré nie sú knižnicami, by to nemalo vadiť.

Bah, som zistil, že to nebola úplne pravda. Funkcia throwTo je implementovaná ako primitívna priamo v kompilátore. Ale zvyšok výnimiek je fakt knižnica a môžeš si ich predefinovať (tj. catch/finally, atď. nad tým máš plnú kontrolu). Ale ten kompilátor sa dá obísť throwIO funciou, ktorá bude hádzať výnimky do IO monádu (dá sa zobecniť na iné monády). Ale to zasa obmedzuje vyhadzovania výnimiek len v kóde, ktorý pracuje s IO, nehovoriac už o tých špecializovaných monádoch a o tom, že to bude totálne nekompatibilné s ľubovoľným iným typom výnimiek. Takže to nie nič dokonalé, ale aspoň sa s tým dá trochu pohrať Na záver ešte dodám, že v hackage (haskellovská databáza projektov) je niekoľko rôznych implementácii výnimiek, takže je predsalen možné, že sa dajú tie štandardné nahradiť kompletne, ale neskúmal som, jak to riešia. Budem musieť neskôr zistiť

To je ale problém toho logovacieho softvéru (všetkého koľko ho je). Keby namiesto zapisovania do súboru radšej poskytovali API na príchod logov (proste zaregistruješ listenera, ktorého logovacie API zavolá vždy keď príde log), tak môžeš všetky logy od jednotlivých podprojektov pekne zozbierať a zalogovať si ich sám. A teda ideálne by si mal tiež poskytnúť logovacie listener API, keby niekto chcel použiť tvoj projekt ako súčasť ešte niečoho väčšieho. Tak či tak, tu už ide skôr o dobrý návrh softvéru všeobecne, než o nejaké špeciality jazyka.

[xkucf03]

Keby namiesto zapisovania do súboru radšej poskytovali API na príchod logov (proste zaregistruješ listenera, ktorého logovacie API zavolá vždy keď príde log)

Vždyť takhle to je – můžeš logovat třeba do databáze nebo do syslogu, nebo na TCP soket… můžeš si napsat i vlastní třídu pro logování. Ale někomu se to standardní API prostě nelíbilo, tak používá nějaké vlastní API.

[Marek Bernát]

Ale písal si niečo o tom, že každý podprojekt zapisuje do vlastného súboru. Tak buď neposkytujú API a sú zle navrhnuté, alebo ho poskytujú a potom nechápem, kde je problém

[Ladicek]

Ono to bylo spíš tak, že vzniklo log4j, autoři ho nabídli Sunu k začlenění do Javy, ti odmítli a vyrobili java.util.logging, a už se vezeme. Každopádně když vezmete slf4j, tak můžete všechny běžně používané logovací knihovny dostat pod jednu střechu a zprávy z nich hrnout kam si usmyslíte.

[default]

Doufám, že to SLF4J neni tak tragický, jako Apachí Commons-Logging…

[Ladicek]

SLF4J a Logback jsou AFAIK to nejlepší, co dneska pro Javu je

[Filip Jirsák]

Není, je to už docela slušná logovací fasáda. Akorát mají autoři poněkud macešský vztah k Javě 5 a metodám s proměnným počtem parametrů. Ale to se dá vyřešit jednou obalující třídou.

[:::]

pouziva se ada dneska jeste nekde?

Ja pracuju na level A aplikacich (podle DO-178B) a pouzivame C++...

[Miloslav Ponkrác]

Pokud budete dělat zakázku pro NASA, Adě se nevyhnete.

Všechno, co je v raketách, či jiných strategických věcech, je jedině Ada.

[marbu]

Tuhle jsem našel pěkný přehled současného nasazení Ady.

[alblaho]

Tak za prvé, Ada nevznikla na objednávku NASA, ale amerického ministerstva obrany (DoD).

Přenositelnost Ady je slušná, protože programy mají možnost abstrahovat od fyzických datových typů, což ale neznamená, že tam takové nejsou.

Nevím, jak je to s certifikací překladačů, kdo ty testy garantuje. Nicméně nestandardní překladače existují, různá akademická uděláka pro .Net, Java bytecode překládají jenom podmnožinu. Zkrátka je to asi jako u Javy.

A jestli překladač Ady nemůže mít extenžny, o tom taky nic nevím. Dokonce si myslím, že ten nejpoužívanější (GNAT) nějaké to #pragma, co není ve standardu má.

Jestli se všechny překladače chovají 100% stejně, to nevím, protože pro běžného smrtelníka je dostupný jenom ten GNAT. Adu 95 umí, umí už i 2005?-).

[Miloslav Ponkrác]

Tak za prvé, Ada nevznikla na objednávku NASA, ale amerického ministerstva obrany (DoD).

Ok, drobná chyba, děkuji za opravu.

Přenositelnost Ady je slušná, protože programy mají možnost abstrahovat od fyzických datových typů, což ale neznamená, že tam takové nejsou.

Přenositelnost Ady je taková, jakou si programátor v Javě, Pythonu, či jinde nedokáže ani představit. Je to výrazně výše.

Násilím zavedete nepřenositelnost kam chcete, ale je zde rozdíl. V Javě napíšete nepřenositelný program snadno, a musíte na to myslet, pokud chcete přenositelnost. Je tam řada skutečností platformově závislých, byť malých. V Adě se musíte silně záměrně snažit o nepřenositelný program.

Nicméně nestandardní překladače existují

Ale nejmenují se Ada.

ten nejpoužívanější (GNAT)

Nejmenuje se Ada.

 

 

[Ladicek]

GNAT je free verze překladače Ady od AdaCore, který je samozřejmě certifikovaný. Jinak s vámi ve všem souhlasím – Ada je profesionálně navržený jazyk určený hlavně pro embedded zařízení (proto to DOD a ta NASA), který má spoustu pokročilých vlastností, které jí můžou dnešní jazyky leda závidět (přímo se nabízí třeba rozdíl mezi odvozenými typy a podtypy), akorát ty řetězce a objekty za moc nestojí Určitě je dobré se o ní něco málo dozvědět, i kdyby v ní člověk nikdy nenapsal ani řádku.

[alblaho]

Ale Ada není ničím magická. Jistě, typový systém systém je tak mazaný, že si to většina uživatelů jiných jazyků neumí představit (ale na Haskell to v žádném případě nemá).

Ta přenositelnost zas tak zázračná není, v momentě kdy se použije nativní datový typ, tak je na tom člověk stejně jako v céčku. Myslím si, že když člověk programuje v Javě (bez Swingu), tak přenositelnost mezi různými mašinami splňujícími testy od Sunu je bezproblémová.

Kdysi jsem zkoušel přenést takový jeden program (pár tisíc řádků, ale Ada je ukecaná) který dobře fungoval na Windows do Linuxu. Obojí jsem kompiloval GNATem, ale v Linuxu to mělo nějaké problémy. Samozřejmě je možné, že chyba byla někde jinde.

A to, že každý překladač se chová naprosto stejně jsou nepodložené pohádky, protože de facto standard je GNAT, zbytek jsou akademické hračky, nebo uzavřené věci, ke kterým se člověk nedostane. I ESA/NASA používá GNAT, i když asi high integrity edici, což je GNAT ořezaný na kost.

Aby nedošlo k mejlce, vašnosto. Ada je skvělý jazyk, svého času jsem ji používal a Programming in Ada 95 od Johna Barnese je knížka, která programátora posune. Ale není to žádná magie. Objekty ale nic moc a řetězce fakt peklo, jak už psal Láďa.

[Miloslav Ponkrác]

v momentě kdy se použije nativní datový typ

A pročpak byste to dělal? Co by Vás k tomu vedlo? Tedy kromě snahy rozbít co se dá?

Myslím si, že když člověk programuje v Javě (bez Swingu), tak přenositelnost mezi různými mašinami splňujícími testy od Sunu je bezproblémová.

Ha ha ha.

de facto standard je GNAT

O kvalitě rozšířených open source věcí si nedělám nejmenší iluze. Ada je de jure stadard, ne jenom de facto. Už jenom to, že GNAT nemá název Ada svědčí, že neprošel jako kompilátor Ady.

I ESA/NASA používá GNAT, i když asi high integrity edici, což je GNAT ořezaný na kost.

Na testy a hraní lze použít leccos.

Ada je skvělý jazyk, svého času jsem ji používal a Programming in Ada 95 od Johna Barnese je knížka, která programátora posune. Ale není to žádná magie. Objekty ale nic moc a řetězce fakt peklo, jak už psal Láďa.

Aby bylo jasno vašnosto, já jsem tu netvrdil nic o tom, že je to magie. To jste vydedukoval z nějaké křišťálové koule, ale asi byste jí měl reklamovat. Kromě toho na každém jazyce najdete šrám.

Já mám tu nevýhody, že knihy od programátorů většinou nečtu. Většinou mě to posune daleko více, zvláště pokud se takto stavím k dnešním knihám. Čtu pouze teorii a referenční příručky.

Něco řeknu. Zatímco dodnes se používají a přežily jazyky staré desítky let. S dnešními jazyky se to nestane, ty se daleko dříve odklidí do zapomnění a nikdo je ani nebude chtít používat. Takový Python, nebo Ruby to relativně brzy čeká (mluvím o horizontu řádově deset, v krajním případě hodně nepravděpodobně max. dvacet let). Zatímco starší jazyky se stále budou používat dále, i když třeba nebudou mainstream. Dnešní cesta light jazyků se záporným IQ (pokud nejsou určeny jako systémové, near asm, nebo syperrychlostní) se ukáže jako špatná a bude to slepá větev. Stejně tak jako jazyků, které nemají svojí normu a nedrží zpětnou kompatibilitu, to bude další slepá větev.

[Marek Bernát]

Nikto ti nebráni napísať ten interpreter lepšie. Ten človek tiež nie je superman a neovláda všetky jazyky dokonale (hneď v úvode píše, že v Haskelle je začiatočník a zrejme by sa to dalo napísať podstatne lepšie/kratšie).

Čo sa týka tej Javy, tak v Jave je bežné písať myMethodThatDoesThis(ToThisClass, andThisObject). Kdežto Haskell je funkcionálny jazyk (= matematický), takže sa oveľa viac narába s bežnou matematickou notáciou x, y, z, f, g, h (už si videl niekedy v matematike niečo podobné ako tie Java metódy? najdlhšie, čo tam nájdeš bude zrejme arccos, argcotg a pod.).

[Radek Miček]

Zápisek z blogu Dona Stewarta, kde autor ukazuje, jak napsat RLE v Haskellu.

[Marek Bernát]

O Donovi Stewartovi som už veľa počul, v komunite býva považovaný za poloboha, ale ešte som od neho moc kódu nevidel. Dík za link

[JS]

Uznavam, ze to ukazuje silu Haskellu (i kdyz Haskell znam jenom velmi velmi malo), ale stejne, v Common Lispu by to vyslo take pekne. (a nemyslim proto, ze CL uz Lisp je)

Me napriklad Haskell nesedi filozoficky, i kdyz jeho matematickou eleganci jsem ochoten uznat. Ale proste mi ten jeho staticky zpusob typovani a funkcionalni programovani bez vedlejsich efektu nevyhovuje. Pro prakticke veci je to pres ruku, a proto mam radeji multiparadigmaticke jazyky jako Python nebo CL.

[Marek Bernát]

Jasné, že by to bolo pekné (práve včera som čítal Grahamovu reprodukciu McCarthyho článku. Definoval tam plnohodnotný eval asi na 50 riadkoch -- ono, nie že by na tom bolo niečo ťažké, teda aspoň v tom pôvodnom Lispe bez lexikálneho scopingu. S LS sa ten eval trochu zozložití). Ale je to tak trochu o ničom úloha, lebo ten eval už v jazyku je, takže človek sa musí umelo obmedzovať v tom, čo z jazyka použiť, aby to nebol podvod

Hm, ja neviem. Videl som veci, ktoré s tým páni programátori sú schopní robiť a zostal som len nemo čumieť už párkrát Jasné, že funkcionálne programovanie je nezvyk, ale IMHO, keď si človek zvykne, tak v ňom dosiahne všetko vcelku pohodlne (občas oveľa pohodlnejšie ako imperatívne) a s kopou výhod k tomu ako bonus. Ale je jasné, že človek sa do toho nebude nútiť, keď nemusí a siahne to prítulnom imperatívnom štýle

[podlesh]

A čo je to "opravdový" kód? V jave nie je problém popísať niekoľko stránok kódom, ktorý v lepších jazykoch zaberie pár riadkov

To je znamená, že poměr komentáře:kód bude ještě větší. Nebo alespoň měl by.

Komentáře tam musí být a vysvětlit, co ten kód má dělat a proč. Tady žádný jazyk nepomůže, protože mi nezarují bug-free kód.

[default]

Opravdový kód je takový kód, který:

1. funguje,
2. je zdokumentovaný (insource dokumentace, manuály atd.) a jednoduše pochopitelný,
3. je otestovaný (pokrytý automatizovanými testy),
4. je vzhledem k možnostem rozšiřitelný
5. a je podporovatelný (supportable, maintainable).

Na jazyku a platformě vůbec nezáleží.

[Marek Bernát]

To sú celkom pekné body, s ktorými sa dá súhlasiť, ale dal si dokopy dva body, ktoré spolu byť nemajú:

2a) dokumentácia

2b) pochopiteľnosť

2a) je na jazyku nezávislé (aj keď len v miere, do akej je pochopiteľný -- čo nie je pochopiteľné, to sa musí dokumentovať), ale 2b) už na jazyku silne závisí. Skús si napísať ľubovoľný kód v brainfucku

Takže 2b) je práve to, o čo v programovaní skutočne ide a čím sa jazyky najviac od seba líšia: abstrakcie a expresívnosť. V menej expresívnych jazykoch musíš písať dlhší kód a tým pádom ťažšie pochopiteľný -- pretože človeku sa lepšie sústredí na pár riadkov nabitých informáciami (pozor, tu sa predpokladá inteligencia!), ako na celú stránku kódu, kde je väčšina z toho len balast.

[default]

Na první část: jsem rád, že aspoň v něčem se shodneme.

Na druhou část: vzhledem k tomu, že jsi známý svou neomalenou nenávistí k Javě, SQL a PL/SQL, dovolím si dále nereagovat a diskuzi ukončit.

[Marek Bernát]

To nie je nenávisť k Jave, to je obyčajné objektívne zhodnotenie schopností jazyka pri porovnaní s jazykmi lepšími. Napríklad PHP je tiež zlý jazyk, ale nechovám k nemu nenávisť. Len je skrátka dobré vedieť, že vznikol najprv ako Perlový skript bez nejakej výraznej koncepcie a stále sa doňho dolepujú nové a nové veci. S Javou to nie je tak zlé samozrejme, tá má aspoň nejaký koncept a každým releasom sa skutočne zlepšuje.

K tomu SQL si neviem ako prišiel. Relačné databázy tvoria veľkú časť teoretickej informatiky a ich základom sú matematické operácie. Prečo by som mal mať niečo proti tomu? Bežne ho používam v práci

[default]

To nie je nenávisť k Jave, to je obyčajné objektívne zhodnotenie schopností jazyka pri porovnaní s jazykmi lepšími.

Já osobně Javu taky moc nemusím. Je plná omezení a dalších šíleností. Ale nic lepšího bohužel není. Navíc jsem postupem času zjistil, že ta omezení jsou vlastně výhodou. Každá chybějící vychytávka má svůj work-around a tyto workaroundy jsou vpodstatě přímočaré. Takže se sice každý upíše, ale z kódu pochopíš, co tím chtěl básník říci. Prostě se naučíš kód nečíst po znacích, ale po odstavcích. Zrovna teď jsem úspěšně odhalil skryté chování jedné nejmenované aplikace z výstupu JADu.

Napríklad PHP je tiež zlý jazyk, ale nechovám k nemu nenávisť. Len je skrátka dobré vedieť, že vznikol najprv ako Perlový skript bez nejakej výraznej koncepcie a stále sa doňho dolepujú nové a nové veci.

Tady se raději zdržím komentáře.

K tomu SQL si neviem ako prišiel. Relačné databázy tvoria veľkú časť teoretickej informatiky a ich základom sú matematické operácie. Prečo by som mal mať niečo proti tomu? Bežne ho používam v práci

To bylo jen rýpnutí na tvou reakci na mou implementaci faktoriálu v SQL:

SELECT ROUND(EXP(SUM(LN(LEVEL)))) FROM dual CONNECT BY LEVEL <= :1

Osobně mě vlastní implementace RDBMS nikterak nezajímá. Zajímá mě to SQL nad tím. Nejsem moc příznivcem PL/SQL (nebo obecně libovolného procedurálního jazyka v databázi), protože SQL je určeno pro manipulaci s daty a to by mělo stačit. Specielně u Oracle můžu objektivně prohlásit, že kdo použije PL/SQL, neumí SQL. A z vlastní zkušenosti musím říci, že pro zvládnutí jazyka SQL stačí první třída základní školy — tedy množiny. Ano — na ten faktorial musí člověk znát logaritmy, aby věděl jak převést součin na součet, ale to je v praxi na pytel.

Takže tak.

Co jsem tím chtěl vlastně říct? Již několikrát tady padlo, proč že se jiné jazyky — a lepší jazyky — neujaly. Nevím.

Třeba Python. Všichni o tom básní. Já říkám: NE! Podle mě má zůstat význam bílých znaků na autorovi kódu. Sám této svobody v ostatních jazycích využívám a díky tomu i vyhrávám.

Někdo tu psal něco o počtu úhozů. Spousta lidí byla proti. Já jsem pro. Umět psát je základ. Já třeba vyhrávám (nejen kvůli odsazování, ale) i kvůli rychlému psaní. Kolega psát neumí a jeho coding-style podle toho vypadá. Když mám na něj navázat, vždy ztratím hodinu jen posraným formátováním. Že mají být klíčová slova velkými písmeny? Že se názvy tabulek a sloupců píší malými? Kdo to má kurva číst!?! A hlavně — supportovat?!? Zaplaťbůh, že je to jen podělaný SQL a né Java (nebo jiný jazyk)!

Další téma je tabulátory versus mezery.

A tak dále a tak dále.

Podle mě je zdrojový kód umělecké dílo. Né nadarmo spadá pod klasický autorský zákon (nepočítám výjimky). A né nadarmo také říkám — a to manažeři velmi neradi slyší —, že posledních 10 % sežere stejné množství času jako těch prvních 90.

A teď se s dovolením vrátím ke svému Ableton Live!.

[Filip Jirsák]

Další téma je tabulátory versus mezery.

Snad všichni programátoři se shodují na tom, že otázka mezery vs. tabulátory má jedno jednoznačné řešení. Bohužel polovina za to řešení považuje mezery a polovina tabulátory

[Marek Bernát]

Tak je to predsa v otázkach viery vždy

[Marek Bernát]

Prečo hovoríš, že nič lepšieho ako Java nie je? Skúsil si Lisp/Haskell/ML/Scheme/Smalltalk? Nie? Tak ich choď skúsiť a potom mi povedz, že nič lepšie nie je

Ten faktoriál je zaokrúhlený a nesplňuje zadanie úlohy, ktoré bolo ... spočítať faktoriál

Jj, SQL samotné je skvelé, stačia množiny a je to čistá matematika, tiež to mám tak rád Ale netuším, prečo sa bavíme o SQL. To je predsa domain-specific jazyk na manipuláciu dát. Nie je to zďaleka tak pekná forma výpočtov ako lambda kalkulus, čo je IMHO jediná správna forma a všetky horeuvedené jazyky -- napriek tomu, že sa veľmi rôznia -- nie sú vo svojej podstatne nič iné ako jeho realizáciou a všetky ostatné jazyky ako C#/Java a celý mainstream sa tam snažia pomaly ale isto dostať

Python je jazyk podobný Jave. Tiež trpí kopou nedostatkou a štandardizáciou polofunkčných riešení. Ale nie je to zlý jazyk. Ničmenej riešiť tabulátory je demencia Proste keď robíš v jazyku A, tak používaš syntax jazyka A. V Lispe píšem všade zátvorky, v SQL mám select/from/where/join, no a v tom Pythone mám (okrem iného) tabulátory. Get used to it, or don't use it

Počet úderov a ovládanie prostredia je síce užitočné, ale nie je pre programovanie ako také dôležité. Jasné, ak chceš s niekým súťažiť, tak to dôležité je

Podľa mňa by tiež kód mal byť umením. Dobrý kód sa pozná po kráse

All in all, som prekvapený, v čom všetkom sa s tebou zhodnem. Ničmenej, píšeš zvláštne: v tomto komentári si načal asi 5 nových OT tém. Máš zaujímavý spôsob uvažovania (nič proti), očividne myslíš na 10 vecí naraz

[default]

Zkusím odpovědět. Nepředpokládám, že se mi to povede tak, jak bych si předstaoval.

Prečo hovoríš, že nič lepšieho ako Java nie je? Skúsil si Lisp/Haskell/ML/Scheme/Smalltalk? Nie? Tak ich choď skúsiť a potom mi povedz, že nič lepšie nie je

Lisp, Haskell, ML (nevím o co jde), Scheme ani Smalltalk jsem vživotě nepoužil (krom maker v AutoCADu). Po pravdě: neviděl jsem k tomu důvod. Ano, vím, jedná se o funkcionální programování. Ale: ke své profesi nic takového nepotřebuji. Naopak. Ke své práci mi velmi pomůže znalost API procedurálních jazyků. Takže večery radši věnuji JMS, WSIT a tak podobně. Uznávám, že funkcionální jazyky by mi hóóódně pomohly, ale: stačily by mi pak ty procedurální? A když ne: co bych pak dělal?

Ten faktoriál je zaokrúhlený a nesplňuje zadanie úlohy, ktoré bolo ... spočítať faktoriál

Ano. Uznávám. Ale na lepší řešení jsem nepřišel. Přecinejen — mám jen střední školu.

Jj, SQL samotné je skvelé, stačia množiny a je to čistá matematika, tiež to mám tak rád Ale netuším, prečo sa bavíme o SQL. To je predsa domain-specific jazyk na manipuláciu dát. Nie je to zďaleka tak pekná forma výpočtov ako lambda kalkulus, čo je IMHO jediná správna forma a všetky horeuvedené jazyky -- napriek tomu, že sa veľmi rôznia -- nie sú vo svojej podstatne nič iné ako jeho realizáciou a všetky ostatné jazyky ako C#/Java a celý mainstream sa tam snažia pomaly ale isto dostať

Bavíme se o něm, protože několik let jsem v tomto jazyce dělal a naučil mě, jak správně definovat datové struktury. Aneb, jak řekl Donald E. Knuth: "Váš algoritmus bude tak efektivní, jak dobře jste navrhnuli datové struktury." Má pravdu?

Python je jazyk podobný Jave. Tiež trpí kopou nedostatkou a štandardizáciou polofunkčných riešení. Ale nie je to zlý jazyk. Ničmenej riešiť tabulátory je demencia Proste keď robíš v jazyku A, tak používaš syntax jazyka A. V Lispe píšem všade zátvorky, v SQL mám select/from/where/join, no a v tom Pythone mám (okrem iného) tabulátory. Get used to it, or don't use it

Ty tabulátory — přiznám se — byl jen placeholder pro mou antipatii. Největší zděšení jsem prožil, když jsem tu v blozích četl komentář na způsob:

"…a proměnná x není definována…"

a odpovědí bylo:

"No proměnná x se sama vytvoří, když neexistuje."

Promiň, ale přesně tohle mi vadilo na PHP a dalších dynamických jazycích. Překlepy dělá každý. Zvlášť, když používáš delší identifikátory. Prostě mozek čte první tři a poslední tři písmena slova a zbytek si domyslí. Tento způsob tedy nemůže by design odhalit chybu. Jakmile proměnná (či cokoli) neexistuje, pak to musí zfalírovat. Je mi vzásadě jedno zda při kompilaci či při běhu (automatizovaných testů). Prostě musí! A tečka!

Možná tato vychytávka jde vypnout nějakým parametrem. Ale! Co když použiji nějakou cizí knihovnu, která bude závislá na tomto chování a celý můj program bude falírovat jen pro to, že někdo se snaží založit proměnnou, která neexistuje?

Takovému jazyku já nemůžu věřit. Promiň. Dělám chyby a vím to. Čím víc kontrol, tím lépe.

Počet úderov a ovládanie prostredia je síce užitočné, ale nie je pre programovanie ako také dôležité. Jasné, ak chceš s niekým súťažiť, tak to dôležité je

Tady nejde o soutěž. Tady jde o ryzí produktivitu. Zatímco někdo, kdo hledá každý znak na klávesnici (a zároveň s tím zjištuje, jaký layout má aktuálně zapnutý), nemá nejmenší šanci se zabývat nejen dokumentací relevantních částí kódu, natož něčím hlubším. Promiň, toliko zkušenost. Já tady třeba udělal mnoho integrací do cizích systémů. Každá "integračka" je jen hloupý SELECT. Ale v JOIN podmínkách a WHERE podmínkách mám v komentářích odkazy na business požadavky. Pro mě rutina. Myslíš, že pro někoho, kdo není schopen napsat slovo SELECT velkými písmeny, se bude obtěžovat s lomeno, hvězdička, mezera, odkaz do dokumentace, mezera, hvězdička, lomeno??? Dám ruku do ohně, že ne!

Podľa mňa by tiež kód mal byť umením. Dobrý kód sa pozná po kráse

A je. Na tom nic nezměníš. Já se programováním živím, protože mě to baví a devadesát procent mám vydřených. Nepatřím mezi ty, kteří přijdou k něčemu novému a řeknou: "Takhle!" A když je poslechenš, funguje to. Já prostě mám své zvyky, o kterých vím, že zákazníci mají rádi. Koneckonců; mám školu Microsoftu:

• vím, jak se nedělá software a
• není důležité, co prodáváš, ale jak to prodáváš.

Možná to zní vtipně, ale funguje to. Tím druhým bodem ani nemám na mysli grafickou úpravu materiálů (ano, je důležitá), jako spíš úroveň (nejsem si jist, zda volím správný termín…) kódu, jak moc je připraven pro produkční nasazení. Příklad: teď třeba dělám na jednom reportu. Protože klient neví, co vlastně chce, mám vlastní repliku dat, Den po dni. Ano, je to ohromné množství dat. Tak ta data postupně podle stáří přesouvám do partitions. Jednoduše: poslední dva měsíce jsou po dnech. Zbytek do půl roku je po měsících. Poslední zbytek je po rocích. Můj kód se spoští každý den (ani to není prioritní). Když můj kód selže, support týmu řekne: "Není místo pro dokončení v tom a v tom tablespacu." Prostě kód, který když spustíš znovu, orpaví co sám poškodil. Kód, který nepotřebuje údržbu.

Zkrátka: snažím se dělat software tak, aby lidem pomáhal. Nepřidělával jim práci. To je můj cíl. Ano! Nejsem na to talentovaný. Ale! Jak jinak můžu lidem pomoci? Začít se učit něco nového? Asi né, že? Radši se budu zdokonalovávat v tom, včem jsem se něco naučil a jsem užitečný druhým. Není lepší pocit, než ten, že cítíš, že jsi udělal něco dobrého a druhým to pomůže. Ať ti to řeknou nebo ne.

All in all, som prekvapený, v čom všetkom sa s tebou zhodnem. Ničmenej, píšeš zvláštne: v tomto komentári si načal asi 5 nových OT tém. Máš zaujímavý spôsob uvažovania (nič proti), očividne myslíš na 10 vecí naraz

Děkuji! Jsem poctěn! Tohle mi neřekli ani mí nejbližší. Děkuji moc!

[Ladicek]

WSIT

Nenávidím WSIT (a JAX-WS)! Teda, miluju že stačí nadeployit pět JARů a jede to, ale ta onanie s konfigurací! Než jsem třeba zjistil, že wsit-client.xml patří na CLASSPATH, uff, to trvalo! A ne že by stačilo říct "při volání téhle WS autentizuj vzájemnou výměnou certifikátů, truststore je tady, keystore je tady, použij certifikát ten a ten, heslo je to a to", já mu musím narvat celé WSDL a do něj to dobaslit, keystore a truststore definovat v systémových proměnných a heslo pro keystore i certifikát musí být stejné. Fuj. Asi se začnu zajímat o Spring WS.

[default]

Nenávidím WSIT (a JAX-WS)!

Já taky ne. Celou Javu EE jsem zahodil do koše. Zbytečně složitý a beztak to z principu (HTTP, web…) nemůže fungovat. Na světě jsou mnohem zajímavější hračky, který nejsou broken by design.

[Ladicek]

Přesně! Na otázku o čem je JEE? bych již nějakou dobu odpověděl v první řadě o bolesti.

[podlesh]

A to jsi to ještě nezkoušel pod IBM WebSphere!

[Ladicek]

Zaslechl jsem nějaké zkazky o WebSphere Portálu od kluků z CIVu a to mi úplně stačilo

[Marek Bernát]

Lisp, Haskell, ML (nevím o co jde), Scheme ani Smalltalk jsem vživotě nepoužil (krom maker v AutoCADu).

Lisp/Scheme sú jazyky, kde dáta sú kód a priamo v jazyku môžeš manipulovať kód (lebo sú to aj dáta) a hneď ho zasa spustiť. ML/Haskell sú staticky typované funkcionálne jazyky (vďaka typom sú vzdialene podobné Jave), no a Smalltalk je OOP jazyk. Ale všetky jazyky využívajú viac či menej myšlienky lambda kalkulu, vďaka čomu sú extrémne silné.

Uznávám, že funkcionální jazyky by mi hóóódně pomohly, ale: stačily by mi pak ty procedurální? A když ne: co bych pak dělal?

No, tak funkcionálne programovanie jednak nemusí byť úplne čisté (to je len v Haskelle, v ostatných jazykoch môžeš používať čiastočne, alebo aj výlučne procedurálne) a jednak sa začína dostávať aj do bežných jazykov (napríklad Java by konečne mala dostať lambda funkcie). To je otázka, či by ti potom stačili procedurálne jazyky. Ale ak by si sa naučil dosť dobre programovať funkcionálne, tak nejakú robotu by si si snáď našiel. Budeš sa čudovať, ale sú firmy, ktoré berú len ľudí, ktorí ovládajú jazyky ako Haskell a Lisp a v iných (určite Google) je to obrovský bonus.

Bavíme se o něm, protože několik let jsem v tomto jazyce dělal a naučil mě, jak správně definovat datové struktury. Aneb, jak řekl Donald E. Knuth: "Váš algoritmus bude tak efektivní, jak dobře jste navrhnuli datové struktury." Má pravdu?

Má (aspoň z istého pohľadu). A v tom prípade ti 100% odporúčam Haskell, ktorý je nad dátami založený úplne maximálne. Vždy sa najprv definuje riešenie problému pomocou návrhu štruktúr a funkcionalita sa implementuje až nad tými štruktúrami (a ide to pekne, pretože Haskell má pattern matching a dovolí ti implementovať funkcionalitu na základe tých dát skoro automaticky).

Ty tabulátory — přiznám se — byl jen placeholder pro mou antipatii. Největší zděšení jsem prožil, když jsem tu v blozích četl komentář na způsob:

"…a proměnná x není definována…"

a odpovědí bylo:

"No proměnná x se sama vytvoří, když neexistuje."

Promiň, ale přesně tohle mi vadilo na PHP a dalších dynamických jazycích. Překlepy dělá každý. Zvlášť, když používáš delší identifikátory. Prostě mozek čte první tři a poslední tři písmena slova a zbytek si domyslí. Tento způsob tedy nemůže by design odhalit chybu. Jakmile proměnná (či cokoli) neexistuje, pak to musí zfalírovat. Je mi vzásadě jedno zda při kompilaci či při běhu (automatizovaných testů). Prostě musí! A tečka!

Možná tato vychytávka jde vypnout nějakým parametrem. Ale! Co když použiji nějakou cizí knihovnu, která bude závislá na tomto chování a celý můj program bude falírovat jen pro to, že někdo se snaží založit proměnnou, která neexistuje?

Takovému jazyku já nemůžu věřit. Promiň. Dělám chyby a vím to. Čím víc kontrol, tím lépe.

V podstate súhlasím. Lenže toto sa ti stane len v PHP, nie v Pythone. Python nedeklarované premenné automaticky nevytvára, ani ti nedovolí sčítať Int a String. To robí len PHP. Tá vlastnosť (kontrola typov, nevytváranie premenných) sa volá silné typovanie a ľudia si často myslia, že dynamické jazyky musia byť hneď slabé (PHP je slabé). Nemusia a obvykle (aspoň tie dobré) nie sú. Ale ak chceš úplnú kontrolu, tak samozrejme potrebuješ statický jazyk a v tom prípade ti znova odporúčam Haskell.

Tady nejde o soutěž. Tady jde o ryzí produktivitu. Zatímco někdo, kdo hledá každý znak na klávesnici (a zároveň s tím zjištuje, jaký layout má aktuálně zapnutý), nemá nejmenší šanci se zabývat nejen dokumentací relevantních částí kódu, natož něčím hlubším. Promiň, toliko zkušenost. Já tady třeba udělal mnoho integrací do cizích systémů. Každá "integračka" je jen hloupý SELECT. Ale v JOIN podmínkách a WHERE podmínkách mám v komentářích odkazy na business požadavky. Pro mě rutina. Myslíš, že pro někoho, kdo není schopen napsat slovo SELECT velkými písmeny, se bude obtěžovat s lomeno, hvězdička, mezera, odkaz do dokumentace, mezera, hvězdička, lomeno??? Dám ruku do ohně, že ne!

Hm, sorry, ale ja píšem tieto veci malým Zvýrazňovanie za mňa rieši editor, stačí mi, že kľúčové slová majú inú farbu. Ale tiež máš pravdu, že ja ku svojím selectom nepíšem dokumentáciu. Ale obvykle to nie je ani potrebné. A v poslednej dobe som už prešiel na automatickú generáciu SQL z objektov, takže ma to už netrápi vôbec

A je. Na tom nic nezměníš. Já se programováním živím, protože mě to baví a devadesát procent mám vydřených. Nepatřím mezi ty, kteří přijdou k něčemu novému a řeknou: "Takhle!" A když je poslechenš, funguje to. Já prostě mám své zvyky, o kterých vím, že zákazníci mají rádi. Koneckonců; mám školu Microsoftu:

• vím, jak se nedělá software a
• není důležité, co prodáváš, ale jak to prodáváš.

Možná to zní vtipně, ale funguje to. Tím druhým bodem ani nemám na mysli grafickou úpravu materiálů (ano, je důležitá), jako spíš úroveň (nejsem si jist, zda volím správný termín…) kódu, jak moc je připraven pro produkční nasazení. Příklad: teď třeba dělám na jednom reportu. Protože klient neví, co vlastně chce, mám vlastní repliku dat, Den po dni. Ano, je to ohromné množství dat. Tak ta data postupně podle stáří přesouvám do partitions. Jednoduše: poslední dva měsíce jsou po dnech. Zbytek do půl roku je po měsících. Poslední zbytek je po rocích. Můj kód se spoští každý den (ani to není prioritní). Když můj kód selže, support týmu řekne: "Není místo pro dokončení v tom a v tom tablespacu." Prostě kód, který když spustíš znovu, orpaví co sám poškodil. Kód, který nepotřebuje údržbu.

Zkrátka: snažím se dělat software tak, aby lidem pomáhal. Nepřidělával jim práci. To je můj cíl. Ano! Nejsem na to talentovaný. Ale! Jak jinak můžu lidem pomoci? Začít se učit něco nového? Asi né, že? Radši se budu zdokonalovávat v tom, včem jsem se něco naučil a jsem užitečný druhým. Není lepší pocit, než ten, že cítíš, že jsi udělal něco dobrého a druhým to pomůže. Ať ti to řeknou nebo ne.

No, tak ak ti vyhovuje ako to robíš a vyhovuje to ostatným, tak netuším, prečo by si na tom niečo menil. Podľa mňa základ úplne všetkého je, aby ťa to v nejakom zmysle bavilo. Preto sa ja hrám s jazykmi, ktoré mi na 99% budú v živote úplne na nič

Děkuji! Jsem poctěn! Tohle mi neřekli ani mí nejbližší. Děkuji moc!

Aj nabudúce

[Filip Jirsák]

A v poslednej dobe som už prešiel na automatickú generáciu SQL z objektov, takže ma to už netrápi vôbec

To je tedy dost kontrast. Na jedné straně řešíte interpret Lispu na 200 řádků, a pak si necháte generovat SQL kód, ze kterého se zvedá žaludek i databázovým analfabetům.

[Marek Bernát]

Nerozumiem. Vy ste asi ešte nepočuli pojem ORM, že?

[Marek Bernát]

Pre upresnenie: keď mám v aplikácií 100+ objektov, tak je vyslovená demencia písať SQL pre tvorbu a management tabuliek, select/insert/update ručne, keď je to pokaždé o tom istom. Jednak sa tým porušuje DRY princíp, jednak je to nudááá. Prečo by som robil niečo, čo môže robiť počítač? Ja pracujem len s objektami a databáza ma nezaujíma. Je to len jedno z možných úložísk. Ak budem chcieť vymeniť engine, napríklad použiť nerelačnú databázu (hint: prevalence), tak mám otvorené dvere. Napokon, tento systém používajú všetky kvalitné webové frameworky (RoR, Django, TurboGears, Seaside, UCW, Weblocks, PLT, ale aj kopa Javovských a .NETovských). Vôbec nerozumiem Vašej výhrade. Ak Vám ide o optimalizáciu, tak tá sa dá vždycky do medzivrstvy implementovať (napríklad vložiť join medzi previazané objekty, atď).

[Filip Jirsák]

Samozřejmě, že jsem o ORM slyšel. A dokonce jsem viděl i vygenerované SQL dotazy, proto ten můj komentář…

[Marek Bernát]

A zakladá sa Vaše tvrdenie na poriadnom testovaní všetkých frameworkov na trhu? V princípe totiž tej optimalizácii nebráni nič. V praxi samozrejme áno a je otázka, či ste zrovna nenarazili na nejaký, kde to bolo riešené extrémne primitívne. Pravda, ja som tiež tú generáciu SQL v nich nijak podrobne neskúmal, takže ruku do ohňa by som za to nedal

[happy barney]

nie je ORM ako ORM. Veľa záleží aj na schopnostiach cieľového jazyka ako i použitej db. ORM nezakryje (skôr len zvýrazní) chyby, či už návrhu databáz alebo v myslení používateľov.

[podlesh]

Já bych podle komentáže řekl že nejenom slyšel, ale i viděl

ORM je skvělá věc na CRUD operace a hlavně pokud se jedná o jednotlivé tabulky. Jakmile ale tabulky tvoří složitější strukturu, tak začnou problémy.

Osobně jsem většinou narazil na klasický problém s načítáním: co se má načítat hned, co ne a co donatahovat "lazy"?

No a potom samozřejmě problém s dotazy, kdy se složitější SQL dotazy musí stejně napsat ručně. Nestačí jen join, je potřeba i přidat nějaké redundantní informace a případně přidat hinty pro případ, že selžou statistiky a databáze použije špatný index (v DB2 běžné, v mysql se neřeší, s ostatními databázemi nemám tak velké zkušenosti).

[Marek Bernát]

Hm, to je možné. Naša aplikácia je, čo do veľkosti, stredná; s veľkými a komplikovanými DB skúsenosti nemám. V každom prípade pán Jirsák hovoril o použití v _mojom_ prípade a tam je to maximálne oprávnené. Toho ušetreného a neduplikovaného kódu oproti trochu pomalším dotazom. Menil by som hocikedy

Všetko lazy samozrejme. Aký má význam vykonávať dotazy skôr, než sú potrebné? V priebehu ďalších výpočtov sa môže ukázať, že daný objekt sa vôbec nepoužije a tak ani nebude treba volať dotaz. Nevidím žiadny význam eager dotazovania.

Tomu zlyhaniu nerozumiem. Index mi fungoval vždy. Ale btw, v prípade, že to skutočne vyžadujete, tak aj s ORM máte možnosť napísať si dotaz na mieru a nasypať si dáta do objektu ručne. Ale toto už patrí do kategórie optimalizácii, takže nie je dôvod sa s tým srať od začiatku. A zvlášť, ak v priebehu vývoja zistíte, že potrebuje zmeniť náväznosť tabuliek, tak môžete všetky skvelé optimalizované dotazy hodiť do koša. S ORM proste prepíšem na pár miestach objekty a som hotový. Ale znova opakujem, že je to vhodné pre mňa konkrétne. Pre obrovské databázy, ktoré potrebujú 100% optimalizáciu, je to zrejme inak.

[podlesh]

Ano, pro velkou množinu aplikací je ORM velmi vhodné, proto se také tak ujaly Pokusil jsem se je zhruba charakterizovat, ale víc to nechci rozebírat. Tohle nechám na lidech, co mají na ORM velmi vyhraněný názor. Spousta databázistů vyznává názor že aplikační programy (a programátoři) by neměli do databáze vůbec takto přímo sahat, mají používat stored procedures.

Všetko lazy samozrejme. Aký má význam vykonávať dotazy skôr, než sú potrebné? V priebehu ďalších výpočtov sa môže ukázať, že daný objekt sa vôbec nepoužije a tak ani nebude treba volať dotaz. Nevidím žiadny význam eager dotazovania.

Význám to má naprosto zásadní. Nemluvím samozřejmě o jednom záznamu z tabulky; mluvím o vazbách 1:N a M:N. Je rozdíl provést jeden SQL dotaz a je rozdíl provést jich stovku.

Tomu zlyhaniu nerozumiem. Index mi fungoval vždy.

To by bylo na delší vysvětlování (napsal jsem dvě verze, ale dospěl k závěru že z toho asi nikdo moc nepochopí). Takže jen ve zkratce: Pokud mám mnoho podmínek (typické pokud filtruji nad několika tabulkami s daty v normální formě), často nejsou pokryty jediným indexem. Optimalizátor tedy musí zvolit na každé tabulce nejlepší index (tj. takový který vybere nejméně řádek) a nejlepší algoritmus pro join (nested-loop join, hash join, merge join - to jsou ty hlavní). Cílem je aby se nakonec musel iterovat a filtrovat podle zbylých podmínek (ty které nejsou pokryty indexy) co nejmenší počet řádek.

Pokud zvolí špatně, může se stát že nakonec proiteruje tisíce či miliony řádek, ačkoliv nakonec výsledkem jsou řádově jednotky.

[default]

Spousta databázistů vyznává názor že aplikační programy (a programátoři) by neměli do databáze vůbec takto přímo sahat, mají používat stored procedures.

Kolikrát bych to i uvítal, když vidím, co jsou někteří schopni vyprodukovat. Ale osobně jsem proti, protože to znamená mít business logiku kompletně v databázi, což není vždy možné a pak to končí tak, že půlka je tam a druhá půlka zas jinde. A udržuj to, že?

To by bylo na delší vysvětlování (napsal jsem dvě verze, ale dospěl k závěru že z toho asi nikdo moc nepochopí). Takže jen ve zkratce: Pokud mám mnoho podmínek (typické pokud filtruji nad několika tabulkami s daty v normální formě), často nejsou pokryty jediným indexem. Optimalizátor tedy musí zvolit na každé tabulce nejlepší index (tj. takový který vybere nejméně řádek) a nejlepší algoritmus pro join (nested-loop join, hash join, merge join - to jsou ty hlavní). Cílem je aby se nakonec musel iterovat a filtrovat podle zbylých podmínek (ty které nejsou pokryty indexy) co nejmenší počet řádek.

Pokud zvolí špatně, může se stát že nakonec proiteruje tisíce či miliony řádek, ačkoliv nakonec výsledkem jsou řádově jednotky.

A když se zvětší objem dat, tak se kolikrát musí ty dotazy celý udělat jinak. A přesně tyhle šukačky se s ORM nedělají tak jednoduše.

[podlesh]

Naprosto souhlasím.

BTW To s tím zvětšením objemu dat je docela zákeřné...

[happy barney]

ad "lazy vždy": jedine s možnosťou vynútiť si opak

ad "zlyhanie indexov": môžu byť za tým bugy, jeden konkrétny príklad (postgresql, staršie verzie): stĺpec typu int8 a hodnota, ktorá sa zmestí do int4 ... vtedy sa index nepoužil (bolo treba explicitne pretypovať na int8).

[podlesh]

Nemusí se jednat o bug. Stačí když několik sloupců obsahuje závislá data, s tím většinou statistiky nepočítají. DB2 ano, ale až od 8.1 nebo 8.2 a jen v rámci jediného UNIQUE indexu.

Pojmem "závislá data" nemyslím špatný návrh a porušení normální formy - naopak. Někdy jsou ale prostě různé údaje teoreticky nezávislé, ale prakticky je mezi nimi korelace.

[default]

S tím jsem se setkal. Měl jsem tu jednu komponentu, která "převáděla" jednu strukturu dat do druhé. Jednoduše řečeno — něco jako pivoting. Převést určité řádky z tabulky A pro konkrétní entitu z tabulky A do sloupců tabulky B. Oracle vysledoval business povahu dat a celý dotaz přeskládal na podmínky IS NULL. Ano. Ten jeho dotaz byl mnohem jednodušší a z business pohledu i správnější. O tom žádná. Ale ty IS NULLy prostě vedly na několik FULL SCANů tabulky A, což byl problém. Tak jsem ten jeden MERGE zrušil a nahradil sadou INSERT/UPDATE a najednou se vejdeme do dvou minut. Tyto dotazy dokonce přežily i migraci, po které se množství dat zvedlo zhruba desetinásobně.

Tolik z praxe. Teď zpět k ORM.

[Marek Bernát]

Lazy príkaz sa vykoná práve vtedy, keď ho potrebuješ. Ak si povieš, že potrebuješ všetko hneď, tak sa to vykoná hneď. No problemo.

Na produkčnom servere má človek obvykle dosť dobrý a poriadne otestovaný db engine. Čím nechcem povedať, že sa to nemôže stať, ale je to extrémne okrajový prípad

[default]

Hola!

Co se toho Pythonu týče — uznávám — přestřelil jsem. Vycházel jsem z tohoto přízpěvku. Opět uznávám — o Pythonu vím kulový a jazyk jako takový mě moc nezajímá, tak jsem nepátral, co je na tom pravdy. Ale tys to pochopil vpodstatě správně; co jsem chtěl říci.

O Haskellu jsem slyšel, dokonce jsem se o něj kdysi dávno začal malinko zajímat, ale pak jsem se musel věnovat jiným věcem (jak typická výmluva ), takže jsem na něj úplně zapomněl. Určitě jej zařadím zpět na seznam.

Ale teď stahuju Oracle 11gR2. Jen zběžně jsem prolétnul seznam změn a — prostě mám novou hračku. Jen namátkou:

• Nové analytické funkce.
• Funkce LEAD a LAG mají novou klauzuli IGNORE NULLS.
• Factoring klauzule umí rekurzi.
• Nové vychytávky v partitioningu.
• DBMS_PARALLEL_EXECUTE pro paralelní vykonávání uživatelských statementů.
• Nové zacházení s MATERIALIZED VIEW LOGem — FAST REFRECH ON COMMIT má být rychlejší. Aneb — Query Rewrite valí.

Chci to vyzkoušet a když budu mít čas a chuť, tak bych o tom mohl něco sepsat. Je tam dost novinek, který mě zajímají. Aspoň mám program na víkend.

Snad to stihnu do víkendu nainstalovat. Ve virtuálu mám tak trošku bordel, tak musím napřed uklidit. Ale to vím už dva roky.

[Marek Bernát]

O python sa nijak zvlášť zaujímať nemusíš. Nie je to zlý jazyk, ale nič moc nové neprináša, len kopírujé vychytávky z ostatných jazykov. Ak už sa chceš venovať niečomu novému, tak určite bude lepší ten Haskell.

Ty si ale Oracle freak Kľudne o tom napíš. Ja sa síce o databázy nijak extra nezaujímam, vystačím si s obyčajným SQL, ale možno by tiež nebolo od veci priučiť sa nové veci. Btw, nesmej sa a ber to ako otázku od úplného laika: v čom podstatnom sa oracle líši od klasických databáz ako postgre a mysql?

[default]

O python sa nijak zvlášť zaujímať nemusíš. Nie je to zlý jazyk, ale nič moc nové neprináša, len kopírujé vychytávky z ostatných jazykov. Ak už sa chceš venovať niečomu novému, tak určite bude lepší ten Haskell.

Jo, zařadil jsem na task list.

Ty si ale Oracle freak Kľudne o tom napíš. Ja sa síce o databázy nijak extra nezaujímam, vystačím si s obyčajným SQL, ale možno by tiež nebolo od veci priučiť sa nové veci. Btw, nesmej sa a ber to ako otázku od úplného laika: v čom podstatnom sa oracle líši od klasických databáz ako postgre a mysql?

Já jsem začínal na jednoduchých prográmcích pro kamarády. Databázím jsem se vždycky vyhejbal, jak to jen šlo. Parsery a generátory souborů pro mě byly vždycky jednodušší. Ale pak jsem přičuchnul k SyBase ASE 12. Docela to bylo fajn. Pak jsem podstoupil školení SyBase ASE performance tuning a tím to celé začalo. Najednou jsem pochopil, o čem ty databáze jsou. Začal jsem hledat způsoby, jak věci zjednodušit.

Pak jsem přešel na Oracle. Oracle Database má jednu výhodu: pořád se učíš nové věci. Stále objevuješ něco nového.

Někdo někdy prohlásil, že pro každý požadavek businessu má Oracle Database hotovou funkci. A zatím to vypadá, že je to pravda.

Čím se Oracle liší od PostgreSQL či MySQL? Na to nemůžu odpovědět. Obecně lze říci, že pro webové aplikace je MySQL nejlepší, protože je nejrychlejší na typy dotazů, které se v těchto aplikacích používají. Ale Data Ware House a Advanced Reporting z toho nevymáčkneš. PostgreSQL je dost inspirovaný Oraclem, a protože o Oracle něco málo vím, nemůžu hodnotit. Viz třeba má implementace podpory locale. Psal jsem tady o tom v poradně.

Teď třeba rozšiřuji systémy pro vymáhání dluhů, které používají Oracle. Krom výkonu třeba implementuji reporty. Pro příklad: kolik klientů, kteří byli kontaktováni vymahačem, zaplatili a kolik? A tak dále. Reporty o vývoji dluhových epizod a tak podobně. Díky analytickým funkcím a DWH vychytávkám je to vždy jen jeden SELECT statement, který doběhne do třiceti vteřin. Vpodstatě ty reporty můžeš pouštět on-demand. Původní implementace používala kartézské součiny v PL/SQL smyčkách a pokud někde běží, tak nedoběhnou. Máme tady v podniku nový termín. Když chceš někomu říct, že to prostě nikdy dělat nebudeš, prostě řekneš: "When the reports will finish." Mé krédo je: "From centuries to seconds."

V současné době si hraji právě s těmi rozšiřujícími možnostmi. Snažím se zjistit, kdy kterou funkci, chování či vychytávku použít.

Například: Oracle nemá LIMIT m OFFSET n jako ostatní. Má jen ROWNUM. Takže když chceš omezit na prvních deset řádek, musíš napsat něco jako:

SELECT
    col1
FROM
    (SELECT
        col1
    FROM
        src_table
    ORDER BY
        col1)
WHERE
    ROWNUM <= 10

Někdy je však výhodnější použít analytickou funkci:

SELECT
    col1
FROM
    (SELECT
        col1,
        ROW_NUMBER() OVER (ORDER BY col1) AS rn
    FROM
        src_table)
WHERE
    rn <= 10

Specielně ve vnořených poddotazech, protože ten STOP-KEY přes ROWNUM je prostě pomalý. Nebo třeba PARTITION BY klauzule v JOIN klauzuli. Proč používat analytické funkce, když to může dopočítat samotné spojení.

A to je jen malá ukázka SQL. Nepočítám tuny hotových řešení v PL/SQL (DBMS_ a UTL_ balíky) či autonomní transakce. Podpora XML, indexy pro XPath… Nebo přesuny velkého množství dat pomocí ALTER TABLE hist_table EXCHANGE PARTITION p10 WITH TABLE src_table. To by mohli podporovat i ostatní. Partitioning má dnes kde kdo. Nebo tady třeba používáme logování ve stylu Log4J (celá aplikace je napsaná v Javě a já jsem Javou sám dost ovlivněn) pomocí Oraclích typů a autonomních transakcí:

DECLARE
    v_logger UTL_LOGGER := UTL_LOG.logger('context_name');
BEGIN
    v_logger.log_info('Hola!');
    
    -- do something here
    
    v_logger.log_info('Finished!');
EXCEPTION
    WHEN OTHERS THEN
        v_logger.log_error(q'[Something's odd here (as expected).]', SQLCODE, SQLERRM);
        RAISE;
END;
/

Samo to generuje stack-tracy, takže pohodička. Navíc to slouží jako komentáře, takže se s nimi nemusíš obtěžovat.

Je to prostě skvělá hračka. To se musí zažít.

[default]

Jo! A málem bych zapomněl!

Proč píšu klíčová slova v SQL velkými písmeny?

Jednoduše. Protože ty skripty musím kolikrát prohlížet a editovat na serverech bez barviček. Prostě jen v plain-textu. Tohle mi třeba na SQL a PL/SQL vyhovuje. Oči prostě vnímají ta vykřičená klíčová slova jako celek a soustředí se jen podstatné věci — tabulky, sloupce, podmínky… A vadí mi to na Javě, protože všechno je malými a já musím vše louskat jak debil. Zase na druhý straně — zpět k SQL a PL/SQL — nesnáším, když nějaký magor používá pro názvy sloupců klíčová slova jako ID, MAX a tak podobně. To mě zase ruší v těch color-full editorech. Já třeba neuznávám ani podmínky spojení ve WHERE klauzuli, nejde-li to jinak (existenční joiny a tak dále). Jsem prostě extrémista.

[Miloslav Ponkrác]

Aneb, jak řekl Donald E. Knuth: "Váš algoritmus bude tak efektivní, jak dobře jste navrhnuli datové struktury." Má pravdu?

Má pravdu v kontextu, ve kterém to psal a ze kterého to nejspíše bylo vytrhnuto. Obecně lidi se nevyjadřují právnicky tak, aby každá věta dala přesný smysl bez kontextu a situace.

Obecně je to jen polopravda. Navíc dříve, kdy lidé dobře znali algoritmizaci, a kdy Knuth více působil, nebyl většinou problém na straně algoritmu, protože teorii a možná řešení znali všichni nazpaměť i o půlnoci. Takže nikoho ani moc nenapadlo, že by se podceňovala otázka vhodného algorimu z páru (datové struktury, algorimus) a proto se zdůrazňovaly datové struktury, kde byl obvykle spíš problém. To, že ve 21. století budou programátoři obvykle bez znalostí teorie algoritmizace, a často neznající ani základní algoritmické metody, to nenapadlo podle mě ani Knutha.

[Ladicek]

Metacirkulární interpret Lispu v Lispu jsem taky napsal do stovky řádek. A interpret Lispu v Object Pascalu jsem měl asi na tisíc. Když si uvědomím, že jsem tam musel implementovat věci, které jsem od "podkladového" Lispu dostal zadarmo, není to tak děsný rozdíl. Odhaduju, že kdybych to chtěl psát v čisté Javě a snažil se o maximální úspornost, dokážu se dostat tak na pět set, určitě bez těch prapodivných konstrukcí předvedených v tom článku.

Ale skutečnost je mnohem prozaičtější – pořádné implementace programovacích jazyků jsou výrazně komplikovanější a porovnávat je co do počtu řádků prostě nedává smysl.

[Marek Bernát]

No, on Lisp je dosť špecifický jazyk, jednak tým, že nemá syntax, jednak tým, že je homoikonický, takže implementovať ho nie je až taký problém v žiadnom jazyku a v Lispe samotnom je to záležitosť na chvíľu

To nie tak úplne pravda. Ak ti intepret obyčajného Lispu vyjde v Jave na 500 riadkov a v Haskelli pod 200, tak jaké to bude s kompilátorom normálneho jazyka? V tom sa ti dobrý jazyk IMHO prejaví ešte oveľa viac. Na kompiláciu (a metaprogramovanie obecne) sú holt najvhodnejšie jazyky, ktoré vedia manipulovať symboly.

[Ladicek]

S kompilátorem normálního jazyka to bude mnohem víc srovnatelné. Dej mi čistě funkcionální implementaci optimalizačních algoritmů! Nedáš, neexistuje, jsou to všechno grafy Schopnost práce se symboly je jistě užitečná, ale s trochou práce je to knihovna, která bude tomu Lispu hodně podobná. A když na to přijde a je opravdu potřeba – není problém si velmi rychle podmnožinu Lispu naprogramovat sám, to je jedna z jeho zásadních výhod.

[Marek Bernát]

Priznávam, že o optimalizácii viem hovno, takže si ma dostal -- čítal som len prvú polovicu Dragon Book, lebo optimalizácie ma až tak nezaujímali; možno sa k tomu časom vrátim. Ak sú to fakt grafy a robí sa len mágia na nich, tak pravda, Haskell tam bude na nič (aspoň pokiaľ viem o jeho podpore grafov)

[Ladicek]

Mne optimalizace dlouho taky nezajímaly (a doteď o nich vím jen velmi málo), ale u "opravdových" jazyků tvoří optimalizátor zdaleka největší a nejsložitější část překladače. Všechno to stojí a padá s analýzou control flow grafu kódu, resp. v dnešních překladačích SSA podoby toho kódu. A už třeba algoritmus pro převod na SSA nebo algoritmy pro alokaci registrů jsou těžce imperativní.

Jinak Dragon Book jsem nečetl, prostě rok vydání ve mně nevzbuzoval důvěru. Na Modern Compiler Implementation in Java (existuje i in ML ) sice někteří nadávají, ale mně se to hodně líbilo a je tam právě i dost prostoru věnováno optimalizacím.

Jo a mimochodem, zajímavý bonus, aneb jak se kompiluje Haskell (z mailing listu JVM languages):

Writing an interpreter for Haskell would be no big deal, but it has the performance you'd expect. Writing an efficient compiler, either to bytecode or native machine code is an entirely different matter. If you take a look at how Glasgow Haskell Compiler implements all of this, you'll see that it emits C code that does *not* actually work as expected with regard to strict lazy evaluation, runs it through a C compiler, then after the C compilation step it will transform the compiled object code, mostly putting jump sites in places of function returns and finally link the doctored object code into an executable.

Ať žijou vedlejší efekty!

[Marek Bernát]

Ja viem, že optimalizácia tvorí najväčšiu časť, ale je to nepotrebný detail, ktorý len čiastočne zlepší výkon. Proste prax. A ja som teoretik. Takže asi nič pre mňa Na druhej strane, asi sú tam pekné algoritmy a teória, takže to úplne nezavrhujem

Ktorú Dragon Book máš na mysli? Sú dve, prvé vydanie je extrémne staré a kód myslím ilustrovaný v C (túto som ale v ruke nemal), druhé je pomerne nové, s príkladmi v Jave, s kapitolami napríklad o GC a ďalších "moderných" veciach a tiež niekoľkými novými kapitolami o optimalizáciách. Tú tvoju knihu nepoznám vôbec. Btw, Dragon Book možno je zastaralá, ale na kompilátoroch sa nič moc za 50 rokov nezmenilo Stále musíš lexovať, parsovať, robiť sémantickú analýzu, vyrábať výstup. Takže na pochopenie kompilátorov to určite stačí. Druhá vec je, ak sa tým chceš živiť, tam sa bez tých optimalizácii nepohneš.

Haha, pekný prístup Možno sa ti bude páčiť komiks o vedľajších efektoch

[Ladicek]

No, za optimalizacemi stojí ohromná spousta teoretické práce. Ale sémantika mi taky přijde zajímavější

Koukám na Wikipedii a poslední vydání je z roku 2006, to jsem fakt nevěděl. Ale je mi to teď celkem jedno, spíš mne teď zajímají Design Concepts in Programming Languages a Concepts, Techniques, and Models of Computer Programming. Doufám, že se k nim někdy v dohledné době dostanu, mám tu ještě Introduction to Information Retrieval a pár dalších zajímavých věcí

Jo jo, ten znám, konec je moc pěkný

[Radek Miček]

Jo a mimochodem, zajímavý bonus, aneb jak se kompiluje Haskell (z mailing listu JVM languages)...

Jen tak mimochodem, GHC umí generovat nativní kód bez kompilátoru C, a když náhodou kompilujete přes kompilátor C, tak se do něj posílá už (částečně) optimalizovaný kód.

[alblaho]

Určitě to bylo způsobené mou nezkušeností, ale u Haskellu mě vždycky drtilo, že jsem nebyl schopen odhadnout, jaký vlastně bude ten výsledný kód. Člověk zamění foldr za foldl a dějou se věci. To céčku nebo Javě "assembler kouká z vočí"

[alblaho]

Jinak mě taky na Haskellu překvapilo, že to funkcionální líné programování má svoje jedinečné limity. Třeba hashtabulky jsou typicky neefektivní (když ji nemůžete modifikovat, pořád se, sviňa, celá kopíruje) a používají se místo ní stromy.

[Marek Bernát]

To je ale IMHO veľmi naivná predstava. Kompilátor predsa nemôže mať problém pozrieť sa, čo sa s tou tabuľkou deje a keď ju len posielate jednej funkcii, ktorá ju celú prejde a zmení jednu hodnotu, tak kompilátor to zistí a vygeneruje rovnaký kód, aký by ste napísali v imperatívnom jazyku (= jedno priradenie do pamäte). Netuším, či to robí aj GHC, ale v princípe sa to určite dá. A tiež, GHC by asi nebol v testoch na úrovni GCC, keby nemysleli aspoň na takéto veci

[alblaho]

Vycházím z toho, co jsem četl v Real World Haskell. Prostě velké bloky dat, kde by člověk měl chuť někde uprostřed udělat imperativní modifikaci, je pro GHC problém. To že na funkcionální programování se hodí seznamy je padesát let staré poznání.

A neříkám, že na hash tabulce, která je ve skutečnosti strom, je něco špatného. Ale myslím si, že momentálně čistě funkcionální jazyky nejsou úplně univerzálně použitelné. Čímž ale zase neříkám, že na některé věci je ten Haskell prostě skvělý.

[Marek Bernát]

No, asi som moc veľký idealista, ale aj tak si myslím, že kompilátor by teoreticky mal byť schopný zoptimalizovať tie funkcionálne prechádzania zoznamov na niečo jednoduchšie. Na druhej strane, ako som píšal vyššie, o optimalizáciach toho moc neviem, takže sa už k tomu nebudem vyjadrovať

Ja si myslím úplne to isté. Na druhej strane, vieš aspoň niečo o Monádoch? Pomocou nich sa aj v Haskelle dá písať de facto imperatívne, takže o nič neprichádzaš (práca s poľami, tabuľkami, grafmi, etc., to všetko funguje s klasickou dobrou imperatívnou zložitosťou). Na druhej strane, ani tým nič nové nezískaš, takže ak tvoria tieto veci 90% tvojho programu, tak je použitie Haskellu blbosť. To mám overené na vlastnej koži

[Radek Miček]

Vycházím z toho, co jsem četl v Real World Haskell. Prostě velké bloky dat, kde by člověk měl chuť někde uprostřed udělat imperativní modifikaci, je pro GHC problém.

V IO monádě a ST monádě je možné mít modifikovatelné pole (viz třeba kapitola 26 v RWH). Docela dobré řešení pro modifikovatelné struktury a IO je uniqueness typing.

[Marek Bernát]

Ešte detail: nie sú náhodou hash tabuľky v STL implementované tiež cez red-blacky? Už je to 5 rokov, čo som tieto veci študoval, ale niečo takéto sa mi marí Alebo je tam špeciálna štruktúra hashset?

[mektige]

Asociativní pole (std::map apod.) jsou v implementovány RB stromy, proto se tomu neříká hash tabulka, ta je něco jiného. Hash tabulka ve standardních knihovnách není, ale je v Boostu.

[Marek Bernát]

Kto tomu tak nehovorí? Tie názvy (asociatívne pole, map, hash-table, dictionary) sú synonymá a je fuk, ako sú implementované. Je fakt, že hash tabuľka je aj zvlášť koncept, ale ten sa obvykle nemyslí, lebo používateľa dátových štruktúr nezaujíma, ako fungujú vnútri.

[Ladicek]

Třeba já Mapa, slovník, asociativní pole, to jsou různé názvy pro jeden abstraktní datový typ. Hashovací tabulka, to je název jedné z možných implementací (resp. jednoho možného druhu implementací).

[Marek Bernát]

Lidi jsou různí... hovada

[Ladicek]

S tím nepolemizuju. Ach, být tak znovu jen hovado.

[Radek Miček]

Člověk zamění foldr za foldl a dějou se věci.

Tohle bude zřejmě jen o praxi. Nicméně, pokud byste chtěl vidět výstup kompilátoru GHC (v jazyce GHC Core), je možné si ho nechat vydumpovat, nebo ještě lépe je možné použít program ghc-core, který vám to i pěkně zobrazí.

[alblaho]

Bude to o praxi. Ale takový styl programování hodně spoléhá na optimalizace (protože naivní vyhodnocení může být dost drahé), na které ale v principu není spoleh, přijde mi to takové křehké. Zkoumat výstup z GHC už ale není moc abstraktní přístup, pro který lidi ten Haskell mají rádi.

[Radek Miček]

Dej mi čistě funkcionální implementaci optimalizačních algoritmů! Nedáš, neexistuje, jsou to všechno grafy

Nevidím důvod, proč bych to nedal. Podívej se třeba na www.cs.tufts.edu/~nr/pubs/zipcfg-abstract.html.

[Ladicek]

To vypadá zajímavě, to si večer projdu. Díky za link. Ale je to v OCamlu, takže bych se nedivil, kdyby tam na pár dobře utajených místech bylo pár malinkatých přiřazení

[Martin Lebeda]

Podle některých statistik to je (načetl jsem to tuším v "Code complete") je průměr cca čistých 5 řádek na den. Zbytek strávíte komentáři, laděním a režií.

[Kvakor]

Ano, škoda, že se nevykreslují grafi v menších jednotkách - tam by bylo vidět ostré vrcholy vysoké aktivity (psaní nového kódu) mezi úseky s nízkou (ladění, komentáře) až nulovou aktivitou (přemýšlení, přestávky a ostatní režije).

[Kvakor]

Grrrr, s/grafi/grafy

[freshmouse]

Ta část o open space je dost legrační.

"Open space je dobrý, pokud nemá žádné vlastnosti open spaců."

"Open space je dobrý, pokud v něm sedí jen dva lidé."

Atd.

Do open space bych šel fakt jen za extrémních podmínek (kdybych nemohl sehnat práci, kdyby můj plat měl mít zajímavý počet cifer atp.).

[kralyk z abclinuxu]

Jeden takový drobný dotaz - co je to openspace? Taková ta velká místnost rozdělená takovejma těma přepážkama?
Něco jako v Dead Like Me?

[freshmouse]

Nevím, co je Dead Like Me.

Velká místnost to je, ale obvykle (?) bez přepážek. Proto je to "open".

[mkoubik]

Nevím, co je přepážka.

Dead Like Me je vynikající seriál, který se mimojiné proslavil otřesným českým dabingem.

[JS]

Mistnost je open space, pokud ke kazdemu bodu mistnosti existuje okoli takove, ze hluk z tohoto okoli je obsazen v te mistnosti.

 

[mkoubik]

Tak to snad splňuje libovonlý neprázdný prostor, ne?

[JS]

Mate samozrejme pravdu. Libovolny neprazdny prostor je otevreny, jak plyne z topologickych axiomu.

Abychom to mohli uvazovat, museli bychom si ho vzit jako nejaky podprostor vetsiho prostoru.

[Marek Bernát]

IMO to, o čom sa snažíš hovoriť, je súvislosť priestoru. Otvorenosť/uzavretosť nemá v reálnom svete miesto, lebo otvorená množina sa od uzavretej líši len hranicou, ktorá je vždy o dimenziu menšia a teda nepozorovateľná už z princípu

[microcz]

Přečetl jsem si to až do konce, trošku mě tvůj zápisek popudil, možná proto že sám hodně z uvedených bodů nesplňuji. Jsou to ale z 98% pravdivé postřehy, nelze je zpochybnit, je vidět že z tebe mluví leta zkušeností.

Dovolil bych si ale poznamenat jednu drobnost, pryč jsou doby, kdy byl programátor expert, jehož znalosti zasahovali do všech oborů výpočetní techniky, dnes je již potřeba rozlišovat. Dejme stranou všechny systémové analytiky a obchodníky, kteří se většinou přímo na kódu programu nepodílejí, potom je podle mě potřeba rozlišovat mezi kodéry (cvičenými opičkami, u kterých je potřeba aby příslušnou část nejčastěji webové aplikace nabušili co nejrychleji) a odborníky (člověk který rozumí detailům, je schopen zaměřit se na problém, který vyžaduje hlubší pochopení problematiky, jíž se aplikace týká). V tom druhém případu mám na mysli tvorbu sofistikovaných aplikací pro lékařství, fyzikální ústavy, výzkumná zařízení. K tomuto já chci směřovat i za cenu menšího finančního ohodnocení, a zde na volbě školy záleží a to silně.

Nevím proč, možná je to nějaké moje fóbie, ale jak se v nějakém povolání začíná řešit více jak pracovat efektivně, jak vymáčknout ze zaměstannce maximum, jak tlačit na pilu u zaměstnavatele a být úspěšný, než jak řešit konkrétní problémy, začíná mě znechucovat, tím ovšem netvrdím, že by neměl každý hledat způsoby jak zrychlit a zefektivnit svoji práci, jen mě dopalují takové ty univerzální pravdy.

[TanisCZ]

Myslete v kódu. Žádné patterny či algoritmy, vše musí být přeloženo už ve vaší hlavě

Tak po tomhle se mi udělalo špatně od žaludku. Proboha takhle ne. Každej větší projekt předpokládá pečlivou analýzu-řešení. Programátor, který nepoužívá návrhové vzory při programování nejen že ztíží přehlednost/rozšiřitelnost kodu, ale téměř jistě do programu zanese další chyby.

[Martin Lebeda]

+1

- Nikdy nemyslete v kódu, ale "programujte do jazyka, nikoliv v jazyku". 

[podlesh]

Pozor na slovní spojení "používat návrhové vzory"! Často se tím míní "psát kód podle nějaké chytré knihy, protože je tak psáno" a to už se dostáváme do oblasti cargo-cult.

Ono je dobré se pořádně zamyslet nad tím, co to vlastně "návrhový vzor" je a k čemu má sloužit.

[Trained.Monkey]

Precti si to poradne, hned v dalsim bode je to vysvetlene. Jde o to aby se clovek nezastavoval nad kazdym listenerem.

[Martin Lebeda]

 - obklopte se lidmi kolegy, kteří toho umí víc než vy a jsou ochotní odpovídat. Jen tak se budete posunovat dopředu

[Dalibor Smolík]

Například kódování v různých stupních opilosti/kocoviny

Já jsem jednou sice nic nekódoval, ale dával dohromady rozsypaný počítač kamarádce. Při tom jsme vypili demižon vína, asi 3 litry. Práce dopadla kupodivu dobře.

[dad]

vy taky vlezete do kazdy diskuze. Copak to pane kolego necitite, ze zde diskutuje budouci programatorska elita o vecech, o kterych nemuzete mit sebemensi paru. Nebo snad vite co jsou, o co jde:

• outline, hierarchy view, reference search, bookmarky, jump to declaration
• risk management pro bugfixy
• commity použít jako referenci
• bez velkych analyz. Proste replikuju, izoluju, opravim, otestuju. Typicke je nahrazeni ArrayListu LinkedHashSet.
• se dělal port Virtual Reality Toolboxu pro Matlab na první preview OS X Jaguar
• Unit testy se pisou do samostatnych souboru
• Tady je zakopaný pes
• Diky, +1
• Haskell uznávajú dokonca aj Lisperi.
• dodaj funkčný interpreter v Jave do 200 riadkov kódu, alebo si nechaj tie žvásty pre seba
• Java 5 byla vydána v roce 2004.
• f (x:(5:ys)):ys
• Tak po tomhle se mi udělalo špatně od žaludku

Jak vidite, zde nemaji stare struktury co delat. Zde vyrusta nova nadeje, nove zitrky,zde se to hemzi mladymi Vaclavy, co budou ohybat koleje ....(jen tak mezi nami, jak se jmenovala ta skupina? )

 

[JS]

Diky, +1

[dad]

pane kolego, Vas prispevek jsem tam dal, protoze se graficky hodil do toho vyctu. Jinak vim,  ze patrite mezi ty  'nad veci' , i kdyz v jedne z minulych diskuzich jste rajtoval na nejakych  malickostech ohledne tech funkcionalnich jazyku. To me trochu zmatlo, ale verim, ze to byla vyjimka.

[Ladicek]

Tady je zakopaný pes. Totiž háček Vy, staré strojařské struktury, byste měly konečně vysvětlit ekonomickým školám, že opravdu neprodukují inženýry. Možná by pak ubylo profesorů, kteří rozumějí všemu od klimatologie po těžký průmysl, a přibylo lepších vzorů pro budoucí elitu národa.

Nebo ne?

[dad]

my stare struktury se snazime to doklepat do penze. Mate pravdu, ekonomove jsou mor dnesni doby, i kdyz pan Smolik mini, ze nekdo prodavat musi. Uprimne nevim, jak to zmenit. Moje svagrova mini, ze rodice, kteri nerozmluvili diteti technickou skolu by meli jit k psychiatrovi. Takze ono to bude zakoreneno asi i v beznem obyvatelstvu.

Jinde pisete, ze spichnete interpreter za par dni. Je to skutecne tak?

[Ladicek]

No, tam šlo o interpret Lispu, ten se skutečně za pár dní spíchnout dá (ve funkcionálních jazycích možná i v řádu hodin, když to má člověk v krvi, ale to jen odhaduju). Ale co do výkonu nebude stát za zlámanou grešli. U složitějších jazyků to bude pochopitelně trvat dýl.

[Dalibor Smolík]

V jednom s vámi určitě souhlasím: dnes je málo kvalitních technických inženýrů. Bohužel. Tahle doba produkuje jiný typ lidí, ale je otázkou, jestli na to v Evropě nedojedeme. Zatím však platí, kdo umí prodat, ten přežije. Mohou s tím nesouhlasit, ale to je tak to jediné, co s tím mohu udělat (Který klasik tohle prohlásil? )

 

[Miloslav Ponkrác]

Nemyslím si, že je kvalitních technických inženýrů málo.

Problém je, že dnes se od kvalitních inženýrů čeká, aby měli manažerské, obchodní a public relation schopnosti, jinak neprojdou sítem personalistů a řady dalších překážek. Bohužel dovednosti dobře se prosazovat, či prezentovat jsou skoro antagonistické k dovednostem technickým.

Že na to Evropa dojede, to všichni uvidíte na vlastní oči.

Mě se vždycky líbí, jak se tvrdí věci, které by se ale objektivně nedaly prokázat. Není to tak dávno, co se všude mnoho měsíců mlátilo v tv, novinách, prostě všude, jak je u nás levno, a jak musíme zdražit na úroveň EU. To ale přestávalo být udržitelné s tím, jak čím dál více lidí nakupovalo kvalitnější a zároveň levnější zboží v zahraničí, často si tam fyzicky zajeli a stále se jim to víc, než bohatě vyplatilo.

Pořád se tvrdí, že je nedostatek programátorů, kvalitních techniků, atd. Já říkám, že to není pravda. Pravda je, že ty překážky jsou značné pro tyto lidi a tak často raději dělají něco jiného.

Tyhle mýty často roznáší Praha a Pražáci. Normální rozumný člověk přijde na to, že když je v Praze omezený počet lidí, a neustále se tam stěhují a koncentrují další a další firmy potřebující další a další lidi, pak tam -  kdo by to byl řekl, že? - logicky vznikne nedostatek potřebných programátorů a techniků.

Řešením je samozřejmě, aby se lidi stěhovali, či dojížděli za prací do Prahy, nicméně životní náklady v Praze jsou jedny z nejvyšších v Evropě (viz statistiky), až na malé výjimky ovšem platy tam zdaleka nejsou nejvyšší v Evropě. Na rozdíl od jiných zemí pražské firmy důsledně odmítají práci z domova, požadují fyzickou přítomnost ve firmě jen z podstaty. Podporu pro bydlení v Praze, apod. většinou firmy nedávají.

Někteří se proto dočasně, či trvale přestěhují do Prahy, jiní to nechtějí, či nemohou udělat. Tím ovšem díky další zvyšující se koncentraci firem v Praze vzniká nedostatek kvalifikovaných lidí, protože jejich počet je plus mínus omezen a tak prostě vzniká, matematicky řečeno, lokální extrém. Částečně to zachraňuje krize, ovšem nikoli trvale, a je to pouze odklad, aby se mohlo předstírat, že je tu nedostatek kvalifikovaných lidí.

Já jsem to řešil a dnes už jen minimálně něco dělám pro Česko. Řada lidí z mého okolí prostě pracuje na dálku pro jiné státy, protože nemají jinou možnost. Kvalifikovaných lidí je dostatek, ale musí si najít jinou práci, nebo lokalitu. Samozřejmě netvrdím, že řadě lidí se práce, či přestěhování do velkoměsta nevyplatí, nicméně pokud bude koncentrace firem na jednom místě pokračovat, bude to uměle vyvolávat dojem, že nejsou kvalifikovaní lidé.

 

 

 

[Dalibor Smolík]

Díky za dobrý a vyvážený příspěvek. Já se pohybuji mj. v oblasti kovárenství a těžkého průmyslu a vidím, jak rychle ubývá zkušených lidí, kteří jsou schopni vytvořit případné zakázky. Souvisí to se zavíráním firem, na jejichž místě rostou sportovní haly nebo solárka.  Například na Kladně je velký problém sehnat kvalitní kováře. A to je průmyslová oblast! V ooru IT na tom stále nejsme špatně. Ale na tom špatně není třeba ani indické Bangalore ..Dané je to také tím, že jsou lidé schopni pracovat "na dálku", což zvyšuje mobilitu pracovní síly.

Proč píšu, že na to Evropa dojede? Evropa je rozsáhlá oblast, ve které končí ve velkém průmyslová výroba. Vše se přesouvá na východ, do Asie. Nejdřív je to textil, teď již jsou to třeba kotevní řetězy ..Vše se bude dovážet. V případě nějaké větší krize (přírodní katastrofy, změny klimatu nebo vojenské akce) může být Evropa odříznutá od prostředků. Než by znovu obnovila svůj provoz, mohlo by dojít k obrovským škodám.

[Miloslav Ponkrác]

Ano, přesně tak to je.

A stejné je to se zastánci zrušení našeho zemědělství, protože všechno levněji dovezeme. Samozřejmě až do okamžiku, kdy nebude potravinová krize, nebo kdy budeme mít co nabídnout.

Sám vidím, jak více a více oborů je přesouváno do Asie. Ona Asie vlastně nedělá špatný kšeft. Za určitou, řekněme max. pár desetiletí trvající, zlevnění své práce a výrobků dostane k dispozici veškeré vědění, znalosti a technologický i jiný potenciál k sobě. V dlouhodobém měřítku se jí to velmi vyplatí.

Mezitím západní svět jde jenom po penězích a měří HDP. Ovšem nikdy neodpověděl na otázku, co bude dělat, až nebude nic vyrábět, nebude nikdo, kdo to bude umět. A také mě napadá otázka, co pak budeme Asii za to nabízet, abychom to od nich koupili. Poradenství jak získat dotace EU? Právníka znající české právo? Českého hygienika? Nebo služby českého úředníka? Nebo dealera české pojišťovny? Jednou bude Evropě hodně ouvej.

A nebo může přijít katastrofa a urychlí se to.

Je to krátkozraká politika, s tím naprosto souhlasím. Nicméně je to společenská vize většiny lidí, a těžko ho zastavit.

Evropa zkrátka prodává a obchoduje, ale v zásadě už nemá s čím, pokud by neměla Asii. A navíc vzniká velká iluze, protože Asie stále používá evropskou a americkou měnu. Do značné míry je dolar a euro kryté asijskou prací. Jenže je nemožné, aby Asie, která přebírá technologické vedení i know how se čaem nevyšvihla jako leader a pak třeba bude chtít mít vlastní měnu a ne neustále krýt a dotovat západní měny. Už teď se dolaru stává, že řada asijských států za něj víc a víc odmítá prodávat, a dolaru to moc nesvědčí.

Tady se pořád jenom vyrábějí peníze z peněz, ale hodnotu za ně západ dává čím dál méně. A jednou se to provalí a spousta lidí se bude divit.

[Fluttershy, yay!]

Ano, správně! Každá vesnice musí být zcela samostatná!

Ehm, máme tu globální trh. Nejen trh. Proč dělit Západ a Východ? Je snad studená válka?

[Ladicek]

Programátoři vědí (abychom nebyli tak off-topic ), že těsná vazba je špatná. Pokud to nevědí ekonomové, pak jsou na tom ještě hůř než jsem čekal (což mi nevadí), a s nimi i my (což mi vadí).

[Marek Bernát]

Coupling je zlý, cohesion je dobrý. Ak sa stane celý svet jedným organismom, tak pôjde o cohesion

[Fluttershy, yay!]

Gaia.

[Marek Bernát]

To sme sa už zas dostali k detskému pornu?

[Dalibor Smolík]

Nejde o to, aby byla každá vesnice samostatná, ale regiony by měly být aspoň částečně soběstačné. Souhlasím, že je trh globální - dnes jsem koupil Seagate USB disk,  díly byly vyrobené v Thajsku a montované v Ćíně. Koupené ve  Stodůlkách. Nic proti tomu. Ale problematika Evropy je úplně jiná než problematika Číny a Jihovýchodní Asie. Proto to členění Západ a Východ. Řekněme, že podobnou problematiku mají USA+Kanada a k tomu  západní a střední Evropa.  Rusko je trochu jiné, ale ne příliš. Samostatný region je Střední Východ a arabské země a pak Dálný Východ. Nemluvě o Latinské Americe. Nejde o to, že by byla studená válka, ale ty země na východě mají úplně jiné podmínky, nesrovnatelné s našimi. Jinak by se taková kvanta zboží nevalila na Západ.

 

[kralyk z abclinuxu]

Nejde o to, aby byla každá vesnice samostatná, ale regiony by měly být aspoň částečně soběstačné.

+1 Mnohem lépe by pak odolávaly různým ekonomickým krizím apod.

[alblaho]

V KLDR tomu říkají čučche.

[Ladicek]

Něco jako chucpe?

[Dalibor Smolík]

Moje svagrova mini, ze rodice, kteri nerozmluvili diteti technickou skolu by meli jit k psychiatrovi.

Technická škola byla často zárukou dobrého zaměstnání (pokud byl člověk šikovný). Například moje matka měla střední ekonomickou školu, ale ještě před tím se vyučila nástrojařkou. A to je věc, která jí pomáhala celý život. Strojař, který se ještě orientuje v ekonomice to vždycky jistil.

Jen mám dnes obavy, že tu brzy nebude proč studovat  technické obory ...

[mkoubik]

dodaj funkčný interpreter v Jave do 200 riadkov kódu, alebo si nechaj tie žvásty pre seba

Tak tohle je, vytržené z kontextu, naprosto ultimátní. To budu používat v diskusi, když mi dojdou argumenty (taky se stane).

[podlesh]

-1

Saze!!

[dad]

Saze jsou spravne ..i kdyz Vas nemam rad, protoze Vy me nemate rad davam +1

[Dalibor Smolík]

No, samozřejmě příspěvek byla nadsázka v  souvislosti s "různými podmínkami" při kódování. Jinak já jsem si pro vlastní firmu udělal ekonomický systém v MySQL+PHP,  který používáme od roku 2002, prokousal jsem se tím od samého začátku, takže tak úplně "mimo " nejsem. Vím, o čem je řeč, i když třeba ne ve všech detailech. 

Rozhodně tím nesnižuji význam zápisků a postřehů při řešení problémů, naopak jsem si blog se zájmem přečetl.  A staré struktury? Neházel bych je do jednoho pytle a už vůbec ne do starého železa. Právě mladí (tzv. Kindermanagement) ve vedení bank způsobili problémy , které v důsledcích vedly k dnešní krizi a proč? Neměli zpětnou vazbu na zkušenosti, které starší generace měla.  Takže nelze všechny odsuzovat šmahem.

[Theodor]

Sice píšu všemi deseti bez celkem problémů, ale učil jsem se to normálně "za běhu" a netrávil jsem kvůli tomu čas žádnými stupidními prográmky. A chlastat jen kvůli tomu, abych věděl, jaké to je, programovat opilý, taky nezačnu.

Možná jsou tam i nějaké chytré rady, ale když člověk zahlédne pár nesmyslů, tak to celkový dojem zkazí.

[Miloslav Ponkrác]

Většina rad je typu: Nemůžete programovat, dokud se nenaučíte hrát na banjo. Nemůžete programovat, pokud nezvládnete sanskrt.

Upřímně lituji všechny, kteří ten text vezmou vážně.

[Miloslav Ponkrác]

Přiznávám, že kdybych se držel výše zmíněných rad, dodnes programovat neumím. Jsem rád, že jsem používal hlavu.

[antaran]

RE: Naučte se psát rychle a bez překlepů. 200 úhozů za minutu je nejlepší způsob komunikace s počítačem. Pokud je třeba přihlaste se do kurzu, trénujte několik stovek hodin.

 

Ja som sa vzdy chcel naucit pisat 10-timi prstami, ale moje IDE mi to nikdy nedovolilo. :)

Ked som si pozrel statistiky pouzivania, tak tam boli statisice stlaceni CTRL-SPACE a CTRL-SHIFT-SPACE a inych klavesovych skratiek...

Navyse ked som uz viac nez rok s tym IDE-ckom robil na jednom pocitaci, mal som pocit ako by mi citalo myslienky, nikdy som nemusel pisat meno triedy alebo premennej a podobne...

Keby som pisal mojim stylom 200 uderov za minutu, tak by mi nestihali oci citat to co pisem. :)

 

To iterate is human to recurse is divine.

[Ondrej 'SanTiago' Zajicek]

> Ked som si pozrel statistiky pouzivania, tak tam boli statisice stlaceni CTRL-SPACE a CTRL-SHIFT-SPACE a inych klavesovych skratiek...

A to je takovy problem si namapovat CTRL na Caps Lock?

[antaran]

>A to je takovy problem si namapovat CTRL na Caps Lock?

Nerozumiem otazke...? Preco by som to robil?

Ja som s tymi skratkami spokojny tak ako su...

Mozno som sa zle vyjadril, myslel som MOJE statistiky pouzivania, tj. co si IDE zapametalo, ze som pisal ked som programoval.

[Ondrej 'SanTiago' Zajicek]

Predpokladal jsem, ze problem je v tom, ze mackani CTRL nezapada do standardniho 'prstokladu' pri psani vsema deseti, a proto na nej upozornujes jako na neco, v cem ti UI brani psat vsema deseti.

[Miloslav Ponkrác]

Já jsem se nikdy psát 10ti prsty neučil, a přesto píšu rychleji, než potřebuji.

Navíc si myslím, že způsob psaní deseti prsty tak, jak se učí je vymyšlen pro psací stroj, ne pro počítač. A na psacím stroji je jistě nejefektivnější.

Píšu na klávesnici tak, jak hraju na kytaře, případně na klavíru. Je to velmi rychlé a nic jsem se učit nemusel.

Nejrychlejší psaní je ve vimu, a to právě proto, že tam nezdržují různé Shifty, Ctrly, Alty a pod.

Nicméně myslím si, že právě programátor potřebuje rychlé psaní ze všech lidí pracující na počítači nejméně. Pokud tedy jde o programátora, kde více času jde o přemýšlení, ne o rychlé psaní. A přemýšlení u programování se setsakra vyplatí, protože po rozmyslu se snadno dostanete na desetinu (nebo třeba ne desetinu, ale určitě významně méně) kódu, který bude výrazně čitelnější a udržovanější. I u programování (alias rychlé psaní) platí Práce kvapná málo platná. Možná to nikde neplatí více, než u programování.

[default]

Jistě. Ale lovit každé písmenko? Když tento způsob vidím, usínám.

[Jirka]

IMHO málokterý ajťák loví písmenka očima a málokterý využívá techniku všemi deseti při běžné práci. To možná sekretářky, které píšou souvislý dlouhý text, ale to se zase moc nevidí v programařině.

[Miloslav Ponkrác]

Přesně tak. Píše klidně poslepu, a nikdy jsem neslyšel ani o základech psaní všema deseti. A ke 200 úhozům na minutu v českém textu se též dostanu. Jen svým specifickým originálním stylem ála hra na hudební nástroj.

Navíc jsem si pro své účely mírně předefinoval klávesnici, abych nemusel přepínat mezi českou a anglickou, protože pro těch pár znaků, které na jedné jsou a na druhé hůře je to zbytečné.

Jak se skutečně stát dobrým programátorem

On totiž dnes každý propaguje učit se oficiální věci, ale zapomínají se řídit selským rozumem. Takže všichni se budou drtit psaní všema deseti, pak objektové vzory v OOP (ne že by nebyly užitečné pro někoho, kdo nezdědil v genech programátorský talent, ale člověk se selským rozumem je vymyslí taky – já je používal daleko dříve, než vznikly). Pak se budou učit nazpamět ovládání IDE – a stejně budou umět programat jako koza řídit autobus.

Nejvíce získáte, když budete přemýšlet, proč se co dělá. Vymýšlet své. Potřebuje xkrát narazit do zdi a vědět proč. Potřebujete udělat malý projekt, stejně tak jako velký, každý vás zocelí v něčem jiném. Potřebujete projekt, který budete dlouho udržovat. Doporučuji vytvořit užitečný free program pro druhé a udržovat ho několik let (doporučuji ho ovšem jako closed source, protože nesoudné poznámky dnešních lidí, kteří kromě linux kernel code style nic jiného nepřečetli vás daleko neposunou, a profesionálové pravděpodobně nebudou mít čas se vaším kódem zabývat).

Upřímně učit se z dnešních zdrojových textů. kdy kvalitních programátorů je naprosté minimum bych doporučoval jen s určitou dávkou podezřívavosti. Obrovská část zdrojový kódů je shit, a to i od lidí zvučných jmen. Uvědomte si, že prosadit se a získat zvučné jméno chce jiné osobní schopnosti, než jsou potřeba k programování.

A až budete něco umět studujte teorii. Základy matematiky, algoritmizace. To vás raketově posune o několik levelů výše. Bez dobré znalosti teorie se dostanete na určitou laťku, kterou nikdy nepřekročíte, protože to nejde. Nedoženete to ani intenzívní praxí, a nebo ano – za deseti, nebo padesatinásobek doby, kterou byste to zvládli se studiem teorie. Ale teorii budete potřebovat až zvládnete základy jazyky a napsat jednouchoučký program. Neberte si toho moc najednou.

[xkucf03]

 

Navíc jsem si pro své účely mírně předefinoval klávesnici, abych nemusel přepínat mezi českou a anglickou, protože pro těch pár znaků, které na jedné jsou a na druhé hůře je to zbytečné.

+1, tohle bych doporučoval každému.

 

 

[Fluttershy, yay!]

Doporučuji vytvořit užitečný free program pro druhé a udržovat ho několik let (doporučuji ho ovšem jako closed source...

Zabít je málo.

[Josef Kufner]

Protože sekretářky se učí psaní všema deseti ve škole, programátoři a podobná havěť ne.

[Jirka]

Já jsem se na škole učil všemi 10 (SPŠ, obor informační technologie, skupina programátorů) a dokonce jsem na školní soutěži obsadil druhé místo a postoupil do okresního kola, kde nás všechny rozdrtily písařky z podnikatelky.

Ale při programování jsem tuto dovednost nepoužil a tak zakrněla. Taky mi moc nechybí.

[Josef Kufner]

Je potřeba umět psát tak rychle, aby to nezdržovalo. To jest o něco rychleji nežje většinou potřeba.

Psaní u programování ale je dosti specifické a jsou tam dost často se opakující vzory (klíčová slova, závorky, různé specialní znaky a podobné). To vyžaduje maličko jiný prstoklad, než je u "všema deseti" a jinou klávesnici (US místo české), aby ty všelijaké symboly byly poruce.

Rozhodně ale doporučuju projít si alespoň nějaké ty základy psaní všema deseti. Kdysi jsem to udělal a je to narychlosti psaní znát. Hlavně to umožní psát naslepo s rozumnou spolehlivostí. Třeba hmatové značky jsou velice užitečné a když člověk ví, které prsty na ně patří, hned se orientuje lépe a není třeba koukat kde je klávesnice.

[kralyk z abclinuxu]

Česká klávesnice není na programování o nic horší. Jde spíš o to, jak kdo je zvyklý.

[Josef Kufner]

Je horší protože se na ní těžko mačkají všelijaké ty užitečné symboly, např. &, |, \, *, {, } a spousta dalších. Většina jich tam ani vůbec není. A pokud to tam je dobastlené pomocí AltGr, tak je nevýhodou, že AltGr je na klávesnici jen jeden, ale shiftů je více.

Btw, ještě jsem neviděl člověka, který by uměl programovat a používal k tomu českou klávesnici.

[kralyk z abclinuxu]

No programovat asi Neumím™, ale snažím se. Takové ty symboly se na české klávesnici nepíšou o nic hůř třeba & stačí zmáčknout AltGr+C, kdežto na US klávesnici musíš šahat až někam nahoru na ý/7, kde je to od obou shiftů dost daleko. To samé platí o hvězdičce, plusu a dolaru. Aj ty závorky jsou na české blíž, snad krom hranatých.

[Theodor]

Hm, a viděl jsi člověka, který uměl programovat?

[default]

Navíc každá platforma mapuje ty speciální znaky jinam, což je asi ten největší problém.

[kralyk z abclinuxu]

Neřekl bych. Jedinej rozdíl mezi např. linuxem a windows je ve znaku '~', který je na v linuxu na A a ve windows na 1, takže o dvě klávesy

Ono nejde o to, že by US klávesnice byla pro programování nějak lépe uzpůsobena. Jde o to, že lidi jsou líní si na české klávesnici ty znaky najít. Zkušenější programátoři jím navíc poradili, že US klávesnice je "ta programátorská" a že ji tedy mají používat. A tak si na US zvyknou a česká jim pak připadá nemožná. A když se stanou zkušenější oni, zase mladším doporučí jen US nebo to i napíšou do knih.

Ve skutečnosti není ani jedno z těchto dvou rozložení pro programování uzpůsobené a obě jsou použitelné přibližně stejně (já si dokonce myslím, že ta česká i trochu líp).
Já to řeším tak, že v ČR používám českou, abych nemusel přepínat a při práci v západním zahraničí ze stejného důvodu tamější.
Takže jsem používal při programování obě a to dostatečně dlouho na to, abych mohl říct, že to prakticky není rozdíl.

[default]

Neřekl bych. Jedinej rozdíl mezi např. linuxem a windows je ve znaku '~', který je na v linuxu na A a ve windows na 1, takže o dvě klávesy

Mluvil jsem o platformě. Né o zavaděči na hry. A teď vážně: co třeba Solaris? Mac?

Ono nejde o to, že by US klávesnice byla pro programování nějak lépe uzpůsobena. Jde o to, že lidi jsou líní si na české klávesnici ty znaky najít. Zkušenější programátoři jím navíc poradili, že US klávesnice je "ta programátorská" a že ji tedy mají používat. A tak si na US zvyknou a česká jim pak připadá nemožná. A když se stanou zkušenější oni, zase mladším doporučí jen US nebo to i napíšou do knih.

Možná. Já ale souhlasím s tím, že AltGr je jen jeden a některý kombinace jsou fakt o vykloubení zápěstí.

Ve skutečnosti není ani jedno z těchto dvou rozložení pro programování uzpůsobené a obě jsou použitelné přibližně stejně (já si dokonce myslím, že ta česká i trochu líp).
Já to řeším tak, že v ČR používám českou, abych nemusel přepínat a při práci v západním zahraničí ze stejného důvodu tamější.
Takže jsem používal při programování obě a to dostatečně dlouho na to, abych mohl říct, že to prakticky není rozdíl.

Tak si vyzkoušej šanělské rozložení.

[Marek Bernát]

To o tom AltGr počujem prvý raz. Píšem ním diakritiku a tej je celkom dosť po celej klávesnici. Žiadne problémy so zápästím som si nevšimol.

[default]

Ne, ne. AltGr je potřeba pro české rozvržení. Na každé platformě ty specielní symboly leží jinde. A někdy je třeba použít AltGr+Shift a tak podbně. A vzhledem k tomu, že AltGr je jen jeden, místy potřebuješ dvě ruce.

Jinak ano — diakritika lze psát i na US rezvržení. Třeba v OS X Leopard je akcentová čárka pod Alt+E jako mrtvá klávesa. Ale už chybí háček a kroužek. Zajímavé je, že španělská tilda (Alt+N) nechybí.

[Marek Bernát]

Naopak, je potrebný pre anglické rozvrhutie, lebo inak diakritiku nenapíšem (prepínanie klávesnice je pre amatérov). A používam to stále, ako vidíš, mám v texte diakritiky kopu. A ÓBČÁŠ TŔÉBÁ ŠÍFŤ, no a čo?

Nie, že de psát, ale netuším ako inak sa dá rozumne písať. Na slovenskej/českej sa nedala. Tam je namapovaných tak 10 znakov nad shift + číslo a ostatné treba písať nepohodlne cez mŕtve znaky (nehovoriac o tom, že stláčať čísla nie je ideálne, lebo sú ďaleko od homerow). Je oveľa pohodlnejšie písať diakritiku úplne rovnako ako píšeš bežné písmená, len keď chceš pridať diakritiku, stlačíš AltGr (bije sa to len pri óô áä ĺľ (a české ŕř úů, to používam raz za rok), ale na to sa dá zvyknúť). Maximálna pohodlnosť.

[Marek Bernát]

Inak uznávam, že na programovanie by AltGr tiež nemuselo byť od veci, ale mal by som oveľa väčší problém si zvyknúť na rozloženie -- de facto by som sa musel naučiť kompletne nový layout. Pri písaní diakritiky som sa nič učiť nemusel, okamžite som začal písať rovnako rýchlo ako text bez diakritiky.

[Josef Kufner]

Já používám primárně anglickou klávesnici a na Shift-Shift (toggle) a AltGr (jen na stisk) mám přepnutí na českou klávesnici, takže ať mačkám co mačkám, všecko mám namalované na čudlících... shift znamená nahoru, altgr doprava

[default]

Má situace je taková, že změnit si mapování klávesnice nepřipadá v úvahu, vzhedem k tomu, že musím pracovat u klientů na dodaném hardware. Tak jsem se naučil českou QWERTY a US a jsem spokojenej. Teď jsem si dokonce zvyknul na španělskou klávesnici, která je podle mě vůbec nejlepší — akcenty se píší přes mrtvou klávesu a "emerické" znaky jsou standarizovány přes AltGr. Všichni (Windoze a Apple) to respektují.

[Marek Bernát]

Hm, ale českú diakritiku máš stále namapovanú na číslach, nie? To je pre mňa veľmi nepohodlné. Zvlášť ak by som musel stláčať AltGr + číslo. Oveľa lepšia je diakritka rovno na písmenách (stláčanie AltGr už ani nevnímam). Tak či tak, určite je to z 99% o zvyku

[mirec]

Tak mne teda IDE dokumentáciu nepíše. Vlastne ani nepoužívam IDE. Sakra ľudia, to nepíšete k funkciám ani len dokumentáciu?

[xkucf03]

Naučte se psát rychle a bez překlepů. 200 úhozů za minutu … Nikdy nesundávejte ruce z klávesnice

O tom dobré programování není – je o tom, jak ti to myslí, ne o tom, jak rychle dokážeš ty myšlenky nabouchat do počítače. Rychlost psaní by měla význam, pokud by vývojář trávil psáním kódu třeba takových 80% pracovní doby – ovšem praxe je diametrálně odlišná

Nebojte se psát dlouze. Pište komentáře, assertions, unit testy a všechny ty "zbytečné" věci.

Souhlasím, hlavně komentáře a nesnažit se o minimalizaci počtu řádků, to je druhořadé, jednoduchost spočívá v něčem jiném.

Akorát k těm unit testům – idální je, když ti ty testy napíše někdo jiný (ten, kdo ti práci zadal), výhodu mají junioři, protože těm testy může napsat zkušenější kolega. Pokud to jsi ty, máš smůlu a tuhle otravnou činnost budeš muset pravděpodobně dělat sám (zadavatel z byznysu nebo analytik tyhle testy psát neumí, tester pravděpodobně taky ne). Test Driven Developement. IMHO by se měly testovat jen důležité a tímto způsobem testovatelné věci (algoritmy, funkce), než psát jednotkové testy na všechno, jen abychom mohli říct, že máme pokrytý kód z X% (přitom ty testy budou jenom jako).

 

Používejte outline, hierarchy view, reference search, bookmarky, jump to declaration apod.

jj, tyhle funkce jsou dost šikovné, pomáhají hlavně pro pochopení struktury kódu – prostě co se člověku nevejde do RAMky v mozku, to mu poskytne přehledně IDE.

 

 

Myslete v kódu. Žádné patterny či algoritmy, vše musí být přeloženo už ve vaší hlavě. Stejně tak dekompozice, názvy promněných..

S tím dost nesouhlasím – člověk by měl myslet na vyšší úrovni abstrakce a až následně tyto myšlenky přepsat do konkrétního jazyka – nenechat se jím omezovat – je to jako při návrhu datového modelu, taky bys měl dělat nejdřív konceptuální (zcela obecný) → logický (relační, objektový, hierarchický…) → fyzický (PostgreSQL, MySQL, Oracle…). „Programujte do jazyka, nikoli v něm“ radí Steve Mcconnell v knize Dokonalý kód.

 

 

Nemyslete v kódu.

OK

 

 

kódování v různých stupních opilosti

To se mi jednou stalo – nelezl z toho sice vyloženě špatný kód, ale když jsem se na něj druhý den díval, bylo to, jako kdybych ho vidět poprvé v životě. Programovat v opilosti nebo při velké únavě nedoporučuji (sklenka vína, nebo jedno pivo nevadí, dokud to člověk nijak nepociťuje).

 

 

80% práce je údržba stávajícího kódu, 20% práce je psaní nového.

A co všechen ten čas, kdy se člověk jen houpe na židli a přemýšlí, nebo si něco čmárá na papír. Hledání různých informací na webu a studium tvoří taky nezanedbatelnou část práce – člověk se prostě pořád učí. Kdo se učit přestal, může to s programováním klidně zabalit.

 

Ad úrdžba vs. psaní nového – po tom, co člověk napíše první řádek kódu, už ten kód vlastně jen udržuje, přidává ke starému nový, čte, přepisuje ho…

 

Naučte se debugovat cizí kód. Perfektní znalost IDE, dobrou znalost profileru

Dobrý programátor by měl chyby odhlalit pouhým čtením kódu bez debuggeru – ale občas se hodí.

 

 

stack trace... Typický příklad je naštvaný uživatel na telefonu. Je třeba vypracovat hypotézy, co problém způsobuje a ty vyvracet.

Jaké si to člověk udělá, takové to má – platí platí pro logy a vyhazované chyby, chybové hlášky – když si někdo vypisuje do logu nesmyslná kvanta zvratků a opomíjí důležité informace, je to jeho problém.

 

 

používejte gui (TortoiseSVN, IDE)

Pěkný program je SmartSVN – sice uzavřený, ale multiplatformní. Netbeans mají také dobrou podporu pro verzování (svn, hg).

 

 

kontributorů

fuj, snad přispěvatelů nebo spoluautorů, ne?

 

 

Většina firem vystavuje pozice na svých vlastních stránkách.

Souhlas, je lepší si vytipovat pár firem, ve kterých by člověk rád dělal, a kouknout přímo na jejich nabídku – něž chodit přes agenturu.

 

 

Používáte SVN nebo něco podobného?

Vývojářská firma, která nepoužívá verzovací systém (a systém na správu chyb a požadavků) je naprosto tragická. Buď se jí člověk může obloukem vyhnout, nebo se postavit do role metodika a tyhle vymoženosti jim tam zavést – sice si moc nezaprogramuje, ale bude uživačný a můžou ho za to patřičně ohodnotit.

 

 

Zeptejte se svého budoucího manažera kolik přesčasů jeho podřízení obvykle odpracují.

To je jako ptát se veksláka, jestli ty rolexky, co ti nabízí, jsou pravé. Člověk by se měl soustředit na plat a další věci, které jsou výslovně uvedené v pracovní smlouvě – nespoléhat se na přátelské řeči o tom, jak je to u nás fajn, že chodíme v pátek brzo domů atd. – protože tyhle ústní dohody jsou leda prostorem pro budoucí vydírání – zvykneš si na tyhle výhody, budeš je brát jako samozřejmost (třeba se díky nim spokojíš i s nižším platem) a až se to zaměstnavateli bude hodit, prostě ti je sebere (nebo jejich sebráním pohrozí).

 

 

Práce z domova? Jak je řešena VPN a kolik lidí ji používá?

Práce z domova je fajn, třeba když je člověk nemocný, ale potřebuje dotáhnout projekt – nemusí chodit do práce a infikovat kolegy. Nebo když potřebuješ absolutní klid na práci, přemýšlení – zavřeš se doma a vyhneš se hluku společné kanceláře. Ale může se z toho stát i pěkná otročina. Pro workoholiky je to pohroma.

 

 

Kde bude moje židle? Můžu ji vidět?

Sice to zní legračně, ale kvalita židle je strašně důležitá, člověk na ní prosedí většinu pracovní doby (ještě že se může projít aspoň na záchod nebo do kuchyňky a trochu si tam odpočinout)

 

[ARny]

Nebojte se psát dlouze. Pište komentáře, assertions, unit testy a všechny ty "zbytečné" věci.

Souhlasím, hlavně komentáře a nesnažit se o minimalizaci počtu řádků, to je druhořadé, jednoduchost spočívá v něčem jiném.

Akorát k těm unit testům – idální je, když ti ty testy napíše někdo jiný (ten, kdo ti práci zadal), výhodu mají junioři, protože těm testy může napsat zkušenější kolega. Pokud to jsi ty, máš smůlu a tuhle otravnou činnost budeš muset pravděpodobně dělat sám (zadavatel z byznysu nebo analytik tyhle testy psát neumí, tester pravděpodobně taky ne). Test Driven Developement. IMHO by se měly testovat jen důležité a tímto způsobem testovatelné věci (algoritmy, funkce), než psát jednotkové testy na všechno, jen abychom mohli říct, že máme pokrytý kód z X% (přitom ty testy budou jenom jako).

Pani casto zabudate na jednu vec. Vytvaranie unit testov, assertions ci prilisneho poznamkovania kodu vytvara neprehladost v kode je nutne testy ci assertions neustale aktualizovat resp. pri kazdej zmene a co je hlavne sice su tieto veci fajn ale dost predrazuju pracu na projektoch. Preto pri malych projektoch (hlavne ked su na objednavku) nemaju az taky vyznam a z vlastnej skusenosti viem, ze su neni potrebne. Dalsia vec je, ze prakticky nikdy sa nepodari otestovat vsetko potrebne a tak projekt moze padnut na hubu aj tak. Pri velkych projektoch, ktore maju velku zivotnost a su v nich investovane velke financne prostriedky by som to uz asi odporucal.

[xkucf03]

 

je nutne testy ci assertions neustale aktualizovat resp.

Test je vhodným doplňkem zmenového požadavku nebo analýzy – programátor dostane test, kterému má vyhovět, napsat kód, který testem projde. Je to svým způsobem sdělovací prostředek – jasnější a srozumitelnější než slovně psané požadavky (i když bez nich to taky nejde).

 

 

ale dost predrazuju pracu na projektoch

Za kvalitu se prostě platí. Chce to ale psát testy tam, kde je to potřeba (kritické části kódu) a ne jakoby všude, aby si pak člověk (firma) mohl honit triko, že má 100% pokrytí kódy testy (code coverage).

 

Navíc nesouhlasím s tím, že testy jen prodražují vývoj – můžou ho i zlevňovat – automatizovaný test napíšeš jen jednou (což stojí nějaký čas) a v dalších verzích ho jen spouštíš (což je zadarmo). Kdybys ty testy neměl, stejně potřebuješ nějak zkontrolovat, že program dělá to, co má – a když to budeš dělat bez testů ručně, stojí tě to ten čas při každé iteraci.

 

Dalsia vec je, ze prakticky nikdy sa nepodari otestovat vsetko potrebne a tak projekt moze padnut na hubu aj tak.

Testování a psaní kvalitního kódu není o tom, že napíšu dokonalý program – ale že napíšu, co nejlepší program, jaký je v daném čase a za daných nákladů možné napsat. Je to o minimalizaci chyb, nikoli jejich úplné eliminaci (té se nepodaří dosáhnout téměř nikdy – v každém SW je nějaký chyba, i lkdyž třeba jen drobnost).

 

P.S. no sakra, teď vypadám jako nějaký testovací fanatik, přitom je to spíš naopak

[ARny]

nuz ono je to vsetko pekna teoria ale naozaj iba velky zakaznici si mozu dovolit investovat do testovania a ani to im nezaruci kvalitu kedze nieje mozne (v ludskych silach) otestovat vsetko.

Takze ako teoria je to pekna vec bohuzial v praxi je to inak. Aspon co sa tyka mensich projektov. Bohuzial. Nieje cas ani peniaze. Kazdy to chcel mat uz vcera a zadarmo ;).

[uf]

Jeste chybi jedna rada: 

Pokud budes v budoucim zamestnani neco psat, nauc se cesky nebo sezen korektora. Uz jsem se za leta naucil ignorovat gramatiku, kdyz me autor zaujme, ale zensky rod a mekke i nebo bili je opravdu sila. Promin.

[:::]

spys bych to zmenil na: when you write anything related to sw, use english...

[Trained.Monkey]

A proc kdyz vsechno pisu anglicky? Jsem na zapadnim pobrezi Irska, do Cech me uz nikdo nedotahne ani buldozerem

[uf]

I tak bys nemel psat anglicky jako ja

[default]

Fuj! Tam musí bejt kosa!

[kralyk z abclinuxu]

A kde? Westport? Galway? Limerick? Tralee? Enis? Killarney? Znám to tam všude (kromě Connemara, tam jsem bohužel nebyl)

[Zerog]

Me by zajimalo jak je to s tim psanim na klavesnici (200 uderu za sekundu).

Jsem se jednou ucil psat rychle a pak jsem si 3 mesice lecil zapesti :( 

[Fluttershy, yay!]

...200 uderu za sekundu...

To vůbec jde? Za minutu bych to chápal, to je normálka, to dávám i já, ale za sekundu asi fakt ne-e.

Jsem se jednou ucil psat rychle a pak jsem si 3 mesice lecil zapesti :(

Záleží na stylu, klávesnici, posezu, nábytku,... Třeba já mám nepříliš podepřenou nízkozdvihovou klávesnici, ruce mi na ní i na stole leží a jsem v pohodě. Zápěstí AFAIK bolí hlavně ze "zalomení" vůči zbytku ruky.

[Josef Kufner]

Jsem se jednou ucil psat rychle a pak jsem si 3 mesice lecil zapesti :( 

V první řadě musíš začít tím, že si ruce dobře a pohodlně položíš

[uf]

Vim, kdo to umi jeste rychleji. Superman !

[uf]

Je zvláštní, jak ze sebe vyrábíš klasika. Pár článků vycucaných z prstu a literatury a bude z tebe klasik.