Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »
Tiskni
Sdílej:
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
- ako funguje overovanie hesiel vo Windows sieti
- ako (aspon zhruba) funguje resolvovanie a routovanie
Muzu se zeptat na co bych tyto dve veci potreboval?
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/...
Ako funguje overovanie hesiel na windowse?niekedy case-sensitive, niekedy nie
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ý ??
To jsou detaily, které ti někdo ukáže jednou nebo dvakrát a pak už jedeš sám.
Zkuste opravit již opravený bug.Nedovedu si představit, že bych dobrovolně dělal něco tak nudného
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
Tenhle článek mi místy nebezpečně připomíná, jak se tu kdysi vychvaloval nějaký absolvent VŠEJá myslím že je to tentýž autor
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,
+1 ...mluvis mi z duse
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ě.
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...
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á?
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).
Add_Item_To_List(The_Item => Selected_Item, The_List => All_Selected_Items);
Mys ma tri tlacitka.
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.
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.
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).
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
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.
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.
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)?
Diky, +1
blogpost -1
Byt zacatecnik, radeji dam na Bluebeara nez na TrainedMonkey.
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.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.
- 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.
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.
kóduspočí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?
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?
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.
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.
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.
A co teprve sedět v prosklené
- 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:
- …
baňiu 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?
Chybami se opice učí.
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...
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.
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.
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
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é.
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.
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?
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.
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.
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
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 matchingKdyby 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.
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ů.
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.
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ť
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
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
Samozrejme, ze to srovnavaji s Javou. Java je nejpouzivanejsi jazyk. Kdyby bylo nejpouzivanejsi C, C++ nebo C#, srovnavali by se s nim.
Čí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?
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.
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
.
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é.
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.
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).
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ý?
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.
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.
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)?.
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ší.
> 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?
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.
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:
To je heslo sado-maso salónů?
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.
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.
Kéž by měl Python statické typování.
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…
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.
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
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.
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.
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.
Doufám, že to SLF4J neni tak tragický, jako Apachí Commons-Logging…
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.
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.
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.
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.).
Zápisek z blogu Dona Stewarta, kde autor ukazuje, jak napsat RLE v Haskellu.
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
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.
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
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 riadkovTo 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.
Opravdový kód je takový kód, který:
Na jazyku a platformě vůbec nezáleží.
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.
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.
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
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!.
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
Tak je to predsa v otázkach viery vždy
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
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ádAle 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 demenciaProste 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:
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!
WSITNená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.
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.
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 vJOIN
podmínkách aWHERE
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 slovoSELECT
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
A v poslednej dobe som už prešiel na automatickú generáciu SQL z objektov, takže ma to už netrápi vôbecTo 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.
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.
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.
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.
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 NULL
y 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.
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
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:
LEAD
a LAG
mají novou klauzuli IGNORE NULLS
.DBMS_PARALLEL_EXECUTE
pro paralelní vykonávání uživatelských statementů.MATERIALIZED VIEW LOG
em — 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.
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?
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 freakKľ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.
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.
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.
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.
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!
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
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.
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
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.
Č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í.
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.
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í.
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.).
Nevím, co je Dead Like Me.
Velká místnost to je, ale obvykle (?) bez přepážek. Proto je to "open".
Mistnost je open space, pokud ke kazdemu bodu mistnosti existuje okoli takove, ze hluk z tohoto okoli je obsazen v te mistnosti.
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.
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.
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.
+1
- Nikdy nemyslete v kódu, ale "programujte do jazyka, nikoliv v jazyku".
- obklopte se lidmi kolegy, kteří toho umí víc než vy a jsou ochotní odpovídat. Jen tak se budete posunovat dopředu
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.
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:
f (x:(5:ys)):ys
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? )
Diky, +1
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.
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?
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? )
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é.
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.
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.
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.
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.
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 ...
dodaj funkčný interpreter v Jave do 200 riadkov kódu, alebo si nechaj tie žvásty pre sebaTak tohle je, vytržené z kontextu, naprosto ultimátní. To budu používat v diskusi, když mi dojdou argumenty (taky se stane).
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.
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í.
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ě.
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.
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.
> 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?
>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.
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.
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í.
Jistě. Ale lovit každé písmenko? Když tento způsob vidím, usínám.
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.
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.
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.
Navíc každá platforma mapuje ty speciální znaky jinam, což je asi ten největší problém.
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í.
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í.
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ť.
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í.
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)
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
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.
I tak bys nemel psat anglicky jako ja
Fuj! Tam musí bejt kosa!
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 :(
...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.
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žíš
Vim, kdo to umi jeste rychleji. Superman !
Je zvláštní, jak ze sebe vyrábíš klasika. Pár článků vycucaných z prstu a literatury a bude z tebe klasik.