Fórum Root.cz

Práce => Studium a uplatnění => Téma založeno: mukel 07. 09. 2019, 23:24:25

Název: Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: mukel 07. 09. 2019, 23:24:25
Ahojte.

Hľadám, dosť neúspešne, knihy Myslime v C++ a Myslíme v Jave. (obidva diely) Na internete som narazil na obe knihy v angličtine, ale keďže moje znalosti angličtiny nie sú najlepšie, netrúfnem si, aby som ich čítal v originálnom znení. Neviete, kde by som obe našiel v češtine? Hľadal som na nete, ale žiaľ neúspešne.

Dik za rady.
Název: Re:Myslite v...
Přispěvatel: alex6bbc 08. 09. 2019, 07:40:07
nejsou tady na rootu v knihovnicce.
u programovani se anglictina fakt hodi, zacni se ji ucit.
Název: Re:Myslite v...
Přispěvatel: to_je_jedno 08. 09. 2019, 09:47:49
Jak chces myslet v (jakykoliv programovaci jazyk) kdyz nedokazes precist anglictinu?
Název: Re:Myslite v...
Přispěvatel: Kit 08. 09. 2019, 11:21:47
Jak chces myslet v (jakykoliv programovaci jazyk) kdyz nedokazes precist anglictinu?

Myslet se dá i česky. Dokonce se dnes dá česky i psát.
Název: Re:Myslite v...
Přispěvatel: Mlocik97 08. 09. 2019, 11:44:57
Súhlasím s Kitom, navyše existujú programovacie jazyky, ktorých "príkazy" nie sú v Angličtine. Ale samo o sobe aj človek čo vôbec nevie po Anglicky má možnosť programovať aj v C, Java, JS, Golang, Python, atd... Ako keby už teraz polovica "príkazov" neboli skratky ako napríklad fmt v Golangu. Neviem čo je celý tvar a čo to znamená v doslovnom preklade z Angličtiny a predsa viem čo to robí. Napríkald Int, to som vedel čo znamená ešte predtým než som vedel že je to skratka slova Integer a že to vlastne je latinské "Whole". Když som začal programovať, po Anglicky som nevedel povedať nič viac než "What is Your name?" a "How are You?" A odpovedať na tieto otázky. + Nejakých 10 slov. To je všetko čo som vedel. A predsa programovať viem (teda relatívne viem, tým myslím algoritmicky rozmýšlať, a zapisovať kód).
Název: Re:Myslite v...
Přispěvatel: to_je_jedno 08. 09. 2019, 11:51:51
Ale nejde preci jen o prikazy. Jak se chces vzdelavat v tom oboru? Jak chces hledat reseni problemu? Nemusis mluvit jako rodilej, ale umet precist a porozumet anglictine je nutna (avsak nikoliv postacujici) znalost programatora.
Název: Re:Myslite v...
Přispěvatel: Mlocik97 08. 09. 2019, 11:53:20
Ale nejde preci jen o prikazy. Jak se chces vzdelavat v tom oboru? Jak chces hledat reseni problemu? Nemusis mluvit jako rodilej, ale umet precist a porozumet anglictine je nutna (avsak nikoliv postacujici) znalost programatora.

Existuje tucet kníh aj v CZ/SK jazyku zaoberajúce sa programovaním. Od Napríklad Mistrovstvý Java až po Arduino od Matúša Seleckého. Áno není to všetko, a stackoverflow taky vie pomôcť. Ale dá sa i bez toho programovať. Možno ti vyriešiť problém bude trvať o niečo dlhšie.
Název: Re:Myslite v...
Přispěvatel: Mirek Prýmek 08. 09. 2019, 14:02:22
stackoverflow taky vie pomôcť. Ale dá sa i bez toho programovať.
Bez SO se programovat nedá. Když má SO výpadek, tak se celý IT průmysl zastaví :)
Název: Re:Myslite v...
Přispěvatel: Kit 08. 09. 2019, 14:03:47
Ale nejde preci jen o prikazy. Jak se chces vzdelavat v tom oboru? Jak chces hledat reseni problemu? Nemusis mluvit jako rodilej, ale umet precist a porozumet anglictine je nutna (avsak nikoliv postacujici) znalost programatora.

Začínal jsem programovat s tím, že jsem anglicky neuměl nic, neboť jsem angličtinu neměl ani na střední. Všechny potřebné materiály jsem měl v češtině a těch pár klíčových slov jsem se prostě naučil. Teprve až mnohem později jsem začal studovat materiály i v angličtině.

Základem programování není angličtina, ale analytické myšlení. Znám spoustu lidí, kteří perfektně umí anglicky, ale nezvládnou napsat ani jednoduchý vzoreček do Excelu.
Název: Re:Myslite v...
Přispěvatel: to_je_jedno 08. 09. 2019, 15:29:41
nezvládnou napsat ani jednoduchý vzoreček do Excelu.
a ty se divis? kdyz nejakej deb*l vymyslel, ze budou nazvy funkci cesky.
Název: Re:Myslite v...
Přispěvatel: mukel 08. 09. 2019, 16:03:15
nejsou tady na rootu v knihovnicce.
u programovani se anglictina fakt hodi, zacni se ji ucit.

Ano je, len je anglicky a ja som si anglicku verziu uz stiahol. Ked ma to nastve, tak sa do nej pustim so slovnikom v ruke.

Ak by ste vedeli, kde najdem ceske verzie, bol by som povdacny.
Název: Re:Myslite v...
Přispěvatel: ondrah 08. 09. 2019, 16:44:45
Základem programování není angličtina, ale analytické myšlení. Znám spoustu lidí, kteří perfektně umí anglicky, ale nezvládnou napsat ani jednoduchý vzoreček do Excelu.

Jasně že ne každý, kdo umí anglicky, je zároveň (schopný) programátor. Proč taky, když IT třeba vůbec není jeho obor?
Ale kolik znáš dobrých ajťáků, kteří nejsou schopni číst anglicky psanou dokumentaci, manuály, reference, fóra atd.? Já si teda po těch více než 20 letech v oboru žádného takového nevybavuji. Sebelepší analytické myšlení ti nepomůže, když nedokážeš tyhle schopnosti nějakým způsobem aplikovat v praxi. A k tomu potřebuješ ovládat nějaké nástroje, ke kterým seženeš nejvíce informačních zdrojů v angličtině, mnoho z nich dokonce pouze v angličtině.

Název: Re:Myslite v...
Přispěvatel: Jiří Havel 08. 09. 2019, 16:47:22
nezvládnou napsat ani jednoduchý vzoreček do Excelu.
a ty se divis? kdyz nejakej deb*l vymyslel, ze budou nazvy funkci cesky.
K tomu se dá dodat jenom jedno
(https://i.kym-cdn.com/entries/icons/mobile/000/005/378/worldburn-top.jpg)
Název: Re:Myslite v...
Přispěvatel: Kit 08. 09. 2019, 16:57:17
nejsou tady na rootu v knihovnicce.
u programovani se anglictina fakt hodi, zacni se ji ucit.

Taková teorie kategorií se z anglického originálu naučit nedá. Minimálně k tomu potřebuješ nějakou českou přednášku nebo vysvětlení. Když se v jedné větě sejdou tři neznámé pojmy, tak jsi ztracen, zejména když je to v cizím jazyce a ty pojmy nejsou ve slovníku.

Nepopírám, že se angličtina hodí, ale představa, že se někdo nejprve naučí anglicky a teprve pak se začne učit programovat, je lichá, prostě to tak nefunguje. Ideální je učit se obojí souběžně. Materiály v rodném jazyce mají přednost.
Název: Re:Myslite v...
Přispěvatel: Kit 08. 09. 2019, 17:05:50
Základem programování není angličtina, ale analytické myšlení. Znám spoustu lidí, kteří perfektně umí anglicky, ale nezvládnou napsat ani jednoduchý vzoreček do Excelu.

Jasně že ne každý, kdo umí anglicky, je zároveň (schopný) programátor. Proč taky, když IT třeba vůbec není jeho obor?
Ale kolik znáš dobrých ajťáků, kteří nejsou schopni číst anglicky psanou dokumentaci, manuály, reference, fóra atd.? Já si teda po těch více než 20 letech v oboru žádného takového nevybavuji. Sebelepší analytické myšlení ti nepomůže, když nedokážeš tyhle schopnosti nějakým způsobem aplikovat v praxi. A k tomu potřebuješ ovládat nějaké nástroje, ke kterým seženeš nejvíce informačních zdrojů v angličtině, mnoho z nich dokonce pouze v angličtině.

Stále to nechápeš. Nemám nic proti angličtině. Sám jsem se však nejprve učil z českých zdrojů, protože jsem anglicky neuměl. Postupem času jsem si rozšiřoval obzory z anglicky psaných zdrojů a dnes nejen čtu z SO, ale sám tam i přispívám.

Jako základ tedy nevidím angličtinu, ale právě to analytické myšlení. Anglicky se naučíš průběžně se studiem různé literatury.
Název: Re:Myslite v...
Přispěvatel: Mlocik97 08. 09. 2019, 17:08:58
Stále to nechápeš. Nemám nic proti angličtině. Sám jsem se však nejprve učil z českých zdrojů, protože jsem anglicky neuměl. Postupem času jsem si rozšiřoval obzory z anglicky psaných zdrojů a dnes nejen čtu z SO, ale sám tam i přispívám.

Jako základ tedy nevidím angličtinu, ale právě to analytické myšlení. Anglicky se naučíš průběžně se studiem různé literatury.

súhlasím... ano Angličtina pomôže, ale aj bez Angličtiny sa dá naučiť.
Název: Re:Myslite v...
Přispěvatel: Idris 08. 09. 2019, 17:33:34
stackoverflow taky vie pomôcť. Ale dá sa i bez toho programovať.
Bez SO se programovat nedá. Když má SO výpadek, tak se celý IT průmysl zastaví :)
;D
Název: Re:Myslite v...
Přispěvatel: Idris 08. 09. 2019, 17:35:49
nejsou tady na rootu v knihovnicce.
u programovani se anglictina fakt hodi, zacni se ji ucit.
Taková teorie kategorií se z anglického originálu naučit nedá.
Ale jasně že dá. Že to nedáš ty nevypovídá nic o jiných.
Název: Re:Myslite v...
Přispěvatel: Ondra Satai Nekola 08. 09. 2019, 17:44:19
nejsou tady na rootu v knihovnicce.
u programovani se anglictina fakt hodi, zacni se ji ucit.
Taková teorie kategorií se z anglického originálu naučit nedá.
Ale jasně že dá. Že to nedáš ty nevypovídá nic o jiných.

Zásah, potopena!
Název: Re:Myslite v...
Přispěvatel: gill 08. 09. 2019, 17:49:08
stackoverflow taky vie pomôcť. Ale dá sa i bez toho programovať.
Bez SO se programovat nedá. Když má SO výpadek, tak se celý IT průmysl zastaví :)

dokážu bez SO pracovat i několik dnů. Na internetu hledám, jen pokud nenajdu odpověď v offline dokumentaci nebo v některé z knih typu Cookbook (které už znám z větčí části nazpaměť).
Název: Re:Myslite v...
Přispěvatel: Ondra Satai Nekola 08. 09. 2019, 17:58:36
stackoverflow taky vie pomôcť. Ale dá sa i bez toho programovať.
Bez SO se programovat nedá. Když má SO výpadek, tak se celý IT průmysl zastaví :)

dokážu bez SO pracovat i několik dnů. Na internetu hledám, jen pokud nenajdu odpověď v offline dokumentaci nebo v některé z knih typu Cookbook (které už znám z větčí části nazpaměť).

To máš buď fenomenální paměť nebo se plácáš na hodně malém písečku.
Název: Re:Myslite v...
Přispěvatel: Kit 08. 09. 2019, 18:06:09
dokážu bez SO pracovat i několik dnů. Na internetu hledám, jen pokud nenajdu odpověď v offline dokumentaci nebo v některé z knih typu Cookbook (které už znám z větčí části nazpaměť).
To máš buď fenomenální paměť nebo se plácáš na hodně malém písečku.

Ve značné míře si vystačím s dokumentací, na SO hledám jen občas.
Název: Re:Myslite v...
Přispěvatel: Mirek Prýmek 08. 09. 2019, 18:40:55
jen pokud nenajdu odpověď v offline dokumentaci
Offline dokumentace? To existuje?
Název: Re:Myslite v...
Přispěvatel: SpaceExit 08. 09. 2019, 18:51:44
Nevím, proč by neznalost angličtiny, měla člověka odradit od programování. Tady není jediný příkaz anglicky.

https://github.com/tkohout/OSTRAJava

Kód: [Vybrat]
banik pyco

tryda Ostrava{
    rynek(){
        Konzola.pravit("Toz vitaj") pyco
    }
}

fajront pyco
Název: Re:Myslite v...
Přispěvatel: uetoyo 08. 09. 2019, 18:54:52
jen pokud nenajdu odpověď v offline dokumentaci
Offline dokumentace? To existuje?
Zeal https://zealdocs.org/
Dash https://kapeli.com/dash
atd., atp.
Zkus si příště zadat "Offline Documentation Browser" do "online" vyhledávače.
Název: Re:Myslite v...
Přispěvatel: gill 08. 09. 2019, 18:58:44
jen pokud nenajdu odpověď v offline dokumentaci
Offline dokumentace? To existuje?

na ustálené technologie stačí nainstalovat docset do Zeal. Výhoda Zeal je, že máte všechnu oficiální dokumentaci ihned po ruce, nemusíte dohledávat skrz google.

edit: uetoyo byl rychlejší
Název: Re:Myslite v...
Přispěvatel: Mirek Prýmek 08. 09. 2019, 19:32:50
Nežerete maso, nepoznáte vtip!
Název: Re:Myslite v...
Přispěvatel: Kit 08. 09. 2019, 19:33:13
jen pokud nenajdu odpověď v offline dokumentaci
Offline dokumentace? To existuje?
Zeal https://zealdocs.org/
Dash https://kapeli.com/dash
atd., atp.
Zkus si příště zadat "Offline Documentation Browser" do "online" vyhledávače.

Tak smůla, no...
Kód: [Vybrat]
$ zeal
QXcbConnection: Could not connect to display
Název: Re:Myslite v...
Přispěvatel: BoneFlute 08. 09. 2019, 21:10:36
nejsou tady na rootu v knihovnicce.
u programovani se anglictina fakt hodi, zacni se ji ucit.
Taková teorie kategorií se z anglického originálu naučit nedá.
Ale jasně že dá. Že to nedáš ty nevypovídá nic o jiných.

Zásah, potopena!
Ani když by sis to fakt hodně přál.

Pokud programovat mohou jen lidi znající angličtinu na takové úrovni, že pochopí z angličtiny teorii kategorií, tak pak nechápu koho, že to všichni ti klienti kolem mne platí. Programátoři to evidentně tedy nejsou.
Název: Re:Myslite v...
Přispěvatel: Ondra Satai Nekola 08. 09. 2019, 22:02:53
nejsou tady na rootu v knihovnicce.
u programovani se anglictina fakt hodi, zacni se ji ucit.
Taková teorie kategorií se z anglického originálu naučit nedá.
Ale jasně že dá. Že to nedáš ty nevypovídá nic o jiných.

Zásah, potopena!
Ani když by sis to fakt hodně přál.

Pokud programovat mohou jen lidi znající angličtinu na takové úrovni, že pochopí z angličtiny teorii kategorií, tak pak nechápu koho, že to všichni ti klienti kolem mne platí. Programátoři to evidentně tedy nejsou.

No pro začátek by stačilo, kdyby zvládali pochopení psaného textu...
Název: Re:Myslite v...
Přispěvatel: Idris 08. 09. 2019, 22:24:09
nejsou tady na rootu v knihovnicce.
u programovani se anglictina fakt hodi, zacni se ji ucit.
Taková teorie kategorií se z anglického originálu naučit nedá.
Ale jasně že dá. Že to nedáš ty nevypovídá nic o jiných.

Zásah, potopena!
Ani když by sis to fakt hodně přál.

Pokud programovat mohou jen lidi znající angličtinu na takové úrovni, že pochopí z angličtiny teorii kategorií, tak pak nechápu koho, že to všichni ti klienti kolem mne platí. Programátoři to evidentně tedy nejsou.
Většině je TK stejně k ničemu, takže otázka ani není, jestli ji jsou schopni pochopit (ať už z anglických textů nebo českých), ale spíše, zda se jim vyplatí na to vynaložit čas, ve kterém by mohli dělat něco smysluplnějšího.
Název: Re:Myslite v...
Přispěvatel: BoneFlute 08. 09. 2019, 22:42:15
Většině je TK stejně k ničemu, takže otázka ani není, jestli ji jsou schopni pochopit (ať už z anglických textů nebo českých), ale spíše, zda se jim vyplatí na to vynaložit čas, ve kterém by mohli dělat něco smysluplnějšího.

Znal jsem kolegu, který tlačil, že všechny komentáře musí být anglicky. Že ty komentáře byly ve výsledku nic neříkající bláboly mu vůbec nevadilo. (O TK neměl šajn. Plaval i v OOP.) Takže rozhodně souhlas.
Název: Re:Myslite v...
Přispěvatel: Idris 08. 09. 2019, 22:49:34
Většině je TK stejně k ničemu, takže otázka ani není, jestli ji jsou schopni pochopit (ať už z anglických textů nebo českých), ale spíše, zda se jim vyplatí na to vynaložit čas, ve kterém by mohli dělat něco smysluplnějšího.

Znal jsem kolegu, který tlačil, že všechny komentáře musí být anglicky. Že ty komentáře byly ve výsledku nic neříkající bláboly mu vůbec nevadilo. (O TK neměl šajn. Plaval i v OOP.) Takže rozhodně souhlas.
Úroveň angličtiny českých vývojářů by byla na dlouhé smutné povídání...
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: novotnyr 09. 09. 2019, 09:48:52
Eckelove knihy sú v českých prekladoch z roku 2000, resp. 2001.

Jeden z nápadov je pozrieť si katalóg slovenských knižníc (https://chamo.kis3g.sk/search/query?match_1=PHRASE&field_1=a&term_1=Eckel,+Bruce++&sort=dateBookAdded&facet_bl=m&theme=monografie), napr. prvý diel Javy je v Ružomberku a Humennom.

Ale úprimne, Eckelov český preklad Javy je naozaj zastaraný, pretože nereflektuje závažné zmeny Javy 5 (z roku 2005), o Jave 8 ani nehovoriac.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 09. 09. 2019, 12:09:03
Eckelove knihy sú v českých prekladoch z roku 2000, resp. 2001.

Jeden z nápadov je pozrieť si katalóg slovenských knižníc (https://chamo.kis3g.sk/search/query?match_1=PHRASE&field_1=a&term_1=Eckel,+Bruce++&sort=dateBookAdded&facet_bl=m&theme=monografie), napr. prvý diel Javy je v Ružomberku a Humennom.

Ale úprimne, Eckelov český preklad Javy je naozaj zastaraný, pretože nereflektuje závažné zmeny Javy 5 (z roku 2005), o Jave 8 ani nehovoriac.
To už je v IT pravěk.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: mukel 09. 09. 2019, 17:41:48
Eckelove knihy sú v českých prekladoch z roku 2000, resp. 2001.

Jeden z nápadov je pozrieť si katalóg slovenských knižníc (https://chamo.kis3g.sk/search/query?match_1=PHRASE&field_1=a&term_1=Eckel,+Bruce++&sort=dateBookAdded&facet_bl=m&theme=monografie), napr. prvý diel Javy je v Ružomberku a Humennom.

Ale úprimne, Eckelov český preklad Javy je naozaj zastaraný, pretože nereflektuje závažné zmeny Javy 5 (z roku 2005), o Jave 8 ani nehovoriac.

Tak neviem... neexistuje nejaká zrovnateľne kvalitná kniha na C++ a Javu? Chcem niečo čo by ma naozaj naučilo programovať a dozvedel som sa, ze eckel je v tomto bomba, preto som ich aj zháňal. Poraďte niečo v rovnakej, prípadne vyššej kvalite.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: novotnyr 10. 09. 2019, 10:15:48
Ak sa chcete samostatne naučiť dva odlišne náročné jazyky a ste obmedzení len na češtinu/slovenčinu, budete musieť robiť veľké kompromisy a vyvinúť nadľudské úsilie.

Porovnateľné knihy totiž existujú, ibaže len v angičtine. Napr. Head First Java. V češtine máte niekoľko kúskov (https://knihy.heureka.cz/f:q:java/).

Prakticky ide o dilemu Eckel (starý), Herout (majster C), Pecinovský (klasik), Roubalová, a Schildt (preklad z angličtiny).

Nerozmýšľali ste nad kurzom? Alebo univerzitným kurzom? Napr. UPJŠ (https://paz1a.ics.upjs.sk/2016/Prednasky/Prednasky) má úvod do objektového programovania v Jave so slajdami a videami.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: mukel 10. 09. 2019, 18:46:35
Ak sa chcete samostatne naučiť dva odlišne náročné jazyky a ste obmedzení len na češtinu/slovenčinu, budete musieť robiť veľké kompromisy a vyvinúť nadľudské úsilie.

Porovnateľné knihy totiž existujú, ibaže len v angičtine. Napr. Head First Java. V češtine máte niekoľko kúskov (https://knihy.heureka.cz/f:q:java/).

Prakticky ide o dilemu Eckel (starý), Herout (majster C), Pecinovský (klasik), Roubalová, a Schildt (preklad z angličtiny).


Nerozmýšľali ste nad kurzom? Alebo univerzitným kurzom? Napr. UPJŠ (https://paz1a.ics.upjs.sk/2016/Prednasky/Prednasky) má úvod do objektového programovania v Jave so slajdami a videami.

Nad kurzom neuvažujem. Nad univerzitou uvažujem, ale kým by som to už išiel študovať, tak by som chcel vedieť aspoň základ, čo sa naučím samoštúdiom.

Len si neviem vybrať knihu. Poradte najlepšiu. :D
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 10. 09. 2019, 18:49:33
Eckelove knihy sú v českých prekladoch z roku 2000, resp. 2001.

Jeden z nápadov je pozrieť si katalóg slovenských knižníc (https://chamo.kis3g.sk/search/query?match_1=PHRASE&field_1=a&term_1=Eckel,+Bruce++&sort=dateBookAdded&facet_bl=m&theme=monografie), napr. prvý diel Javy je v Ružomberku a Humennom.

Ale úprimne, Eckelov český preklad Javy je naozaj zastaraný, pretože nereflektuje závažné zmeny Javy 5 (z roku 2005), o Jave 8 ani nehovoriac.
To už je v IT pravěk.

Jenže Eckel to napsal nadčasově a nic lepšího není.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: gill 10. 09. 2019, 19:34:47
Len si neviem vybrať knihu. Poradte najlepšiu. :D

cokoliv novějšího.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: mukel 10. 09. 2019, 20:24:02
Eckelove knihy sú v českých prekladoch z roku 2000, resp. 2001.

Jeden z nápadov je pozrieť si katalóg slovenských knižníc (https://chamo.kis3g.sk/search/query?match_1=PHRASE&field_1=a&term_1=Eckel,+Bruce++&sort=dateBookAdded&facet_bl=m&theme=monografie), napr. prvý diel Javy je v Ružomberku a Humennom.

Ale úprimne, Eckelov český preklad Javy je naozaj zastaraný, pretože nereflektuje závažné zmeny Javy 5 (z roku 2005), o Jave 8 ani nehovoriac.
To už je v IT pravěk.

Jenže Eckel to napsal nadčasově a nic lepšího není.

Tak, jedine, citat to v eng. Ale to bude utrpenie. :)
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Makovec 10. 09. 2019, 21:25:02
Eckelove knihy sú v českých prekladoch z roku 2000, resp. 2001.

Jeden z nápadov je pozrieť si katalóg slovenských knižníc (https://chamo.kis3g.sk/search/query?match_1=PHRASE&field_1=a&term_1=Eckel,+Bruce++&sort=dateBookAdded&facet_bl=m&theme=monografie), napr. prvý diel Javy je v Ružomberku a Humennom.

Ale úprimne, Eckelov český preklad Javy je naozaj zastaraný, pretože nereflektuje závažné zmeny Javy 5 (z roku 2005), o Jave 8 ani nehovoriac.
To už je v IT pravěk.

Jenže Eckel to napsal nadčasově a nic lepšího není.

Tak, jedine, citat to v eng. Ale to bude utrpenie. :)

Jestli to chceš v tomhle (a skoro jakémkoli) oboru někam dotáhnout tak angličtina je ten nejdůležitější jazyk ve kterém bys měl umět myslet. To je dneska samozřejmý základ. Možná se spíš než na podrobná studia programovacích jazyků nejprve soustřeď na ni.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: mukel 10. 09. 2019, 21:57:45
Viem, ze anglictina je zaklad a teraz lutujem, ze viac casu pocas strednej som nestravil jej studiom, ale viac som sa zameral na prirodovedne predmety.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: mirekf80 11. 09. 2019, 09:05:33
2 mukel: poslal jsem ti PM
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: mukel 11. 09. 2019, 11:46:33
2 mukel: poslal jsem ti PM

v poho... Ja som zo Slovenska, z Cize neviem, ako by si mi to poslal, ale postovne by bolo asi extra drahe. :D
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: fortran1986 11. 09. 2019, 17:32:47
zohnaj si toto: https://ucebnice.heureka.sk/mistrovstvi-v-c-plus-plus-stephen-prata/ ale pozor treba kupit 4ku vydanie ( napr. na martinuse maju len 3ku).

Pri C++ nema zmysel kupovat stare knihy (ja mam doma tiez knihu o C++ z roku 92 zial ta je uz nepouzitelna, nakolko C++ vtedy neobsahovalo ani templaty a bol to vpodstate iny jazyk, ale ako muzealny exponat je to pekne). C++ sa od verzie 11 a potom aj 17 dost podstatne zmenilo pribudli lambdy smart pointery a dalsie vychytavky ktore tento jazyk posunuli na iny level.

Buduci rok ma vyjst verzia 20, ktora prinesie do dalsi rad revolucnych noviniek takze cim novsia kniha tym lepsie.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: hawran diskuse 11. 09. 2019, 17:50:24
https://herbsutter.com/

https://github.com/isocpp/CppCoreGuidelines

https://isocpp.org/
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: mukel 11. 09. 2019, 20:04:23
zohnaj si toto: https://ucebnice.heureka.sk/mistrovstvi-v-c-plus-plus-stephen-prata/ ale pozor treba kupit 4ku vydanie ( napr. na martinuse maju len 3ku).

Pri C++ nema zmysel kupovat stare knihy (ja mam doma tiez knihu o C++ z roku 92 zial ta je uz nepouzitelna, nakolko C++ vtedy neobsahovalo ani templaty a bol to vpodstate iny jazyk, ale ako muzealny exponat je to pekne). C++ sa od verzie 11 a potom aj 17 dost podstatne zmenilo pribudli lambdy smart pointery a dalsie vychytavky ktore tento jazyk posunuli na iny level.

Buduci rok ma vyjst verzia 20, ktora prinesie do dalsi rad revolucnych noviniek takze cim novsia kniha tym lepsie.

Nie je táto kniha pre začiatočníka veľmi komplikovaná?
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 12. 09. 2019, 04:06:40
Nie je táto kniha pre začiatočníka veľmi komplikovaná?

C++ patří mezi nejtěžší programovací jazyky, s komplikovaností knihy musíš počítat. Pokud jsi začátečníkem, začni raději s Javou - ta je jednodušší a získáš lepší návyky.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: mukel 12. 09. 2019, 04:33:49
Nie je táto kniha pre začiatočníka veľmi komplikovaná?

C++ patří mezi nejtěžší programovací jazyky, s komplikovaností knihy musíš počítat. Pokud jsi začátečníkem, začni raději s Javou - ta je jednodušší a získáš lepší návyky.

Tak OK, necham si poradit. Len mi porad nejaku knihu o jave... poohliadal som sa po Mistrovstvi v Java, myslis ze je dobra? Pripadne porad lepsiu.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: borekz 12. 09. 2019, 06:36:50
Na C++ nic komplikovaného nevidím. Problém bude spíše v těch knihách.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Jiří Havel 12. 09. 2019, 08:02:11
Nie je táto kniha pre začiatočníka veľmi komplikovaná?
Já se C++ učil právě z předchozí edice téhle knihy a šlo to dobře. Rozhodně je psaná pochopitelně a stravitelně. Jen nepočítej s tím, že z tebe ta kniha udělá mistra. Spíš tak pokročilého učedníka. :)
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 12. 09. 2019, 12:03:15
Nie je táto kniha pre začiatočníka veľmi komplikovaná?
C++ patří mezi nejtěžší programovací jazyky
Oproti Haskellu je triviální, nemluvě o vyšším levelu jako Agda.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Ondra Satai Nekola 12. 09. 2019, 12:51:23
Nie je táto kniha pre začiatočníka veľmi komplikovaná?
C++ patří mezi nejtěžší programovací jazyky
Oproti Haskellu je triviální, nemluvě o vyšším levelu jako Agda.

Jsou různé druhy obtížnosti.
C++ nemá moc abstraktních konceptů, ale je to dost rozsáhlý bordel s mnoha zbraněmi určenými ke střelbě do nohy...
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 12. 09. 2019, 13:05:16
Nie je táto kniha pre začiatočníka veľmi komplikovaná?
C++ patří mezi nejtěžší programovací jazyky
Oproti Haskellu je triviální, nemluvě o vyšším levelu jako Agda.
Jsou různé druhy obtížnosti.
C++ nemá moc abstraktních konceptů, ale je to dost rozsáhlý bordel s mnoha zbraněmi určenými ke střelbě do nohy...
Dobře, jestli pod “obtížný” rozumíme “neuvěřitelný bordel”, pak ano. Haskell je naopak velmi elegantní a uspořádaný, akorát ho běžný vývojář moc nepobírá. Možná je problémem právě absence bordelu a stupidit, jako v C++ a Javě?
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Ondra Satai Nekola 12. 09. 2019, 14:04:29
Nie je táto kniha pre začiatočníka veľmi komplikovaná?
C++ patří mezi nejtěžší programovací jazyky
Oproti Haskellu je triviální, nemluvě o vyšším levelu jako Agda.
Jsou různé druhy obtížnosti.
C++ nemá moc abstraktních konceptů, ale je to dost rozsáhlý bordel s mnoha zbraněmi určenými ke střelbě do nohy...
Dobře, jestli pod “obtížný” rozumíme “neuvěřitelný bordel”, pak ano. Haskell je naopak velmi elegantní a uspořádaný, akorát ho běžný vývojář moc nepobírá. Možná je problémem právě absence bordelu a stupidit, jako v C++ a Javě?

Pod pojmem "obtížný" se prostě může skrýt ledacos, protože "obtížnost" má různé příčiny.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Jakub55667788 12. 09. 2019, 14:15:42
Myslime v C++ prvni a druhý díl je v NTK na půjčení.
Jinak doporučuji Virius Programovací jazyk c++ 1., 2., 3. díl jsou z roku 2015,2016, 2017.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 12. 09. 2019, 15:04:21
Dobře, jestli pod “obtížný” rozumíme “neuvěřitelný bordel”, pak ano. Haskell je naopak velmi elegantní a uspořádaný, akorát ho běžný vývojář moc nepobírá. Možná je problémem právě absence bordelu a stupidit, jako v C++ a Javě?

Je to různé. PHP je poměrně snadný k naučení, ale obsahuje hodně bordelu a vývojář se snadno střelí do nohy. Haskell je elegantní, ale pro běžné vývojáře moc není. XSLT je na tom podobně, ale je ukecaný. Proto si moc příznivců nenašel. Jeho výhodou zase je, že se dá velmi snadno generovat a dá se přilepit k PHP, Javě, Pythonu a dalším jazykům.

Takže na jedné straně máme "dokonalé jazyky" se kterými většina vývojářů nechce nic mít, na druhé zase odpad, ve kterém se snadno programuje, ale je velké riziko vadné aplikace. Můžeme si vybrat nebo je zkombinovat.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 12. 09. 2019, 16:44:58
Haskell je naopak velmi elegantní a uspořádaný, akorát ho běžný vývojář moc nepobírá
Takže na jedné straně máme "dokonalé jazyky" se kterými většina vývojářů nechce nic mít
Ne že nechce, ale prostě nechápe. Nejde jen o Haskell, to je ve světě FP poměrně nenáročný entry level, ale nedávno tu byla debata o závislostních typech, které jsou ještě mnohem elegantnější a “dokonalejší”, tam už ale tápou i “senioři”.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: mukel 12. 09. 2019, 16:46:50
Tak sa pustím do Javy a C++, knihy ktore si zakupim su Mistrovstvi v C++ a Mistrovstvi v Jave. Alebo su este nejake lepsie, ako tieto dva spominane??
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: BoneFlute 12. 09. 2019, 17:36:57
Dobře, jestli pod “obtížný” rozumíme “neuvěřitelný bordel”, pak ano. Haskell je naopak velmi elegantní a uspořádaný, akorát ho běžný vývojář moc nepobírá. Možná je problémem právě absence bordelu a stupidit, jako v C++ a Javě?

IMHO zásadní problém je v tom, že C++ i Java jsou imperativní jazyky. Je možné pozorovat vývojáře, kteří prostě "vyřeší problém" místo toho, aby ho popsali. Udělají ciklus, nějaké ty podmínky, prostě dosáhnou výsledku. Jednou jsem viděl krásnou anketu, kde se dotyčný ptal, zda při návrhu nějaké systému používají papír nebo rovnou programují.

Haskell a spol jsou více na to dobře si promyslet co chceš. Protože zapsat to pak je na pár řádek. A možná požadavek na větší teoretický rozhled. V Javě ani v C++ nepotřebuješ prakticky nic znát.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 12. 09. 2019, 18:17:16
Haskell a spol jsou více na to dobře si promyslet co chceš. Protože zapsat to pak je na pár řádek. A možná požadavek na větší teoretický rozhled. V Javě ani v C++ nepotřebuješ prakticky nic znát.
Mně přijde, že mnoho algoritmů (jejich zápis) se v obou přístupech prolíná. Promyslet se člověk akorát musí, jak obejít to, že do proměnných nejde přiřazovat, ale to už je o neznalosti specifických řešení (nebo “vzorů”).
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 12. 09. 2019, 19:24:41
Haskell a spol jsou více na to dobře si promyslet co chceš. Protože zapsat to pak je na pár řádek. A možná požadavek na větší teoretický rozhled. V Javě ani v C++ nepotřebuješ prakticky nic znát.
Mně přijde, že mnoho algoritmů (jejich zápis) se v obou přístupech prolíná. Promyslet se člověk akorát musí, jak obejít to, že do proměnných nejde přiřazovat, ale to už je o neznalosti specifických řešení (nebo “vzorů”).

Fígl je v tom, že bys do proměnných ani neměl chtít zapisovat, podobně jako nepřepisuješ funkci. V XSLT to je také tak a docela mi trvalo, než mi docvaklo, že by byla blbost do nich zapisovat. Není tam ani "else" a časem jsem zjistil, že nepotřebuji ani "if" či "choose". Podobně dopadl i "for-each" - cykly už také nepotřebuji. Ta změna myšlení není jednoduchá, ale stojí za to.

Nakonec přijdeš na to, že ve funkcionálních jazycích žádné algoritmy nepotřebuješ, vystačíš si se vzorci.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: BoneFlute 12. 09. 2019, 19:41:53
Mně přijde, že mnoho algoritmů (jejich zápis) se v obou přístupech prolíná. Promyslet se člověk akorát musí, jak obejít to, že do proměnných nejde přiřazovat, ale to už je o neznalosti specifických řešení (nebo “vzorů”).

I v Javě jsou zkušenější programátoři.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 12. 09. 2019, 20:01:54
Mně přijde, že mnoho algoritmů (jejich zápis) se v obou přístupech prolíná. Promyslet se člověk akorát musí, jak obejít to, že do proměnných nejde přiřazovat, ale to už je o neznalosti specifických řešení (nebo “vzorů”).
I v Javě jsou zkušenější programátoři.
Nepochybně, ale tady jde o schopnost pochopit, ne zkušenosti.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 12. 09. 2019, 20:04:46
Haskell a spol jsou více na to dobře si promyslet co chceš. Protože zapsat to pak je na pár řádek. A možná požadavek na větší teoretický rozhled. V Javě ani v C++ nepotřebuješ prakticky nic znát.
Mně přijde, že mnoho algoritmů (jejich zápis) se v obou přístupech prolíná. Promyslet se člověk akorát musí, jak obejít to, že do proměnných nejde přiřazovat, ale to už je o neznalosti specifických řešení (nebo “vzorů”).

Fígl je v tom, že bys do proměnných ani neměl chtít zapisovat, podobně jako nepřepisuješ funkci. V XSLT to je také tak a docela mi trvalo, než mi docvaklo, že by byla blbost do nich zapisovat. Není tam ani "else" a časem jsem zjistil, že nepotřebuji ani "if" či "choose". Podobně dopadl i "for-each" - cykly už také nepotřebuji. Ta změna myšlení není jednoduchá, ale stojí za to.

Nakonec přijdeš na to, že ve funkcionálních jazycích žádné algoritmy nepotřebuješ, vystačíš si se vzorci.
Však taky nechci, ale většinu lidí to mate, protože to jinak neumí.

K poslední větě: 1) Najdi definici algoritmu. 2) Se vzorci si člověk vystačí, ale musí mít celou tu mašinerii za nimi, tj. typový systém, syntaktické cukrovinky apod.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 12. 09. 2019, 20:39:45
Se vzorci si člověk vystačí, ale musí mít celou tu mašinerii za nimi, tj. typový systém, syntaktické cukrovinky apod.

Není to tak zlé. V XSLT je jen 5 typů a syntaktického cukru tam moc není. Problém bude jinde.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 12. 09. 2019, 22:14:33
Se vzorci si člověk vystačí, ale musí mít celou tu mašinerii za nimi, tj. typový systém, syntaktické cukrovinky apod.
Není to tak zlé. V XSLT je jen 5 typů a syntaktického cukru tam moc není. Problém bude jinde.
To není zrovna plnohodnotný jazyk. V Haskellu už to vypadá jinak.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 13. 09. 2019, 00:11:16
Se vzorci si člověk vystačí, ale musí mít celou tu mašinerii za nimi, tj. typový systém, syntaktické cukrovinky apod.
Není to tak zlé. V XSLT je jen 5 typů a syntaktického cukru tam moc není. Problém bude jinde.
To není zrovna plnohodnotný jazyk. V Haskellu už to vypadá jinak.

XSLT je úplným programovacím jazykem, stejně jako Haskell.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 13. 09. 2019, 00:30:53
Se vzorci si člověk vystačí, ale musí mít celou tu mašinerii za nimi, tj. typový systém, syntaktické cukrovinky apod.
Není to tak zlé. V XSLT je jen 5 typů a syntaktického cukru tam moc není. Problém bude jinde.
To není zrovna plnohodnotný jazyk. V Haskellu už to vypadá jinak.
XSLT je úplným programovacím jazykem, stejně jako Haskell.
Nic moc pokus o provokaci, že je turingovsky úplný neznamená, že je srovnatelný s Haskellem.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 13. 09. 2019, 11:22:01
XSLT je úplným programovacím jazykem, stejně jako Haskell.
Nic moc pokus o provokaci, že je turingovsky úplný neznamená, že je srovnatelný s Haskellem.

Souhlas, XSLT má jiné paradigma.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: tomas88 13. 09. 2019, 17:49:11
Vždy radostu si tu počíst. Někdo slyšel haskellu a hnedka se už považuje za neobyčejného (nebo jaký je opak obyčejného?) vývojaře.  8)
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Cikáda 13. 09. 2019, 18:20:00
Nie je táto kniha pre začiatočníka veľmi komplikovaná?

C++ patří mezi nejtěžší programovací jazyky, s komplikovaností knihy musíš počítat. Pokud jsi začátečníkem, začni raději s Javou - ta je jednodušší a získáš lepší návyky.

Java je do začátků strašně ukecaná... a taky mám dojem, že z ní pak mají občas lidé pocit, že se všechno musí řešit přes výjimky, což mi jako lepší návyk nepřijde.

Nie je táto kniha pre začiatočníka veľmi komplikovaná?
C++ patří mezi nejtěžší programovací jazyky
Oproti Haskellu je triviální, nemluvě o vyšším levelu jako Agda.

"Problém" je, že Haskell je vcelku mladý a konzistentní. O C++ se to tvrdit nedá; ten jazyk je obří, se spoustou věcí se člověk snadno střelí do nohy a často doplácí na to, že "je v něm všechno". Zase nutno dodat, že pokrok je u C++ vidět dost.

Haskell a spol jsou více na to dobře si promyslet co chceš. Protože zapsat to pak je na pár řádek. A možná požadavek na větší teoretický rozhled. V Javě ani v C++ nepotřebuješ prakticky nic znát.

To bych si nebyl tak úplně jistý. Spíš bych řekl, že je to tím, že je normální začínat na imperativních jazycích. On programátor v Haskellu taky nemusí "prakticky nic znát", když bude vědět, jak co použít. Jen je k němu ta teorie prostě blíž než u C++.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 13. 09. 2019, 21:39:11
C++ patří mezi nejtěžší programovací jazyky, s komplikovaností knihy musíš počítat. Pokud jsi začátečníkem, začni raději s Javou - ta je jednodušší a získáš lepší návyky.
Java je do začátků strašně ukecaná... a taky mám dojem, že z ní pak mají občas lidé pocit, že se všechno musí řešit přes výjimky, což mi jako lepší návyk nepřijde.

Výjimky jsou výrazně lepší, než předávání chybových stavů. Bez mechaniky výjimek se objektově moc programovat nedá.

Java je ukecaná, jen když se píší anemické (v podstatě zbytečné) třídy. Neukecaného Pythonu se mnozí programátoři snad i bojí.

XSLT bylo pro mne také ukecané do doby, než jsem zjistil, že je to jen pověra a že ukecané není.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 13. 09. 2019, 21:43:41
Vždy radostu si tu počíst. Někdo slyšel haskellu a hnedka se už považuje za neobyčejného (nebo jaký je opak obyčejného?) vývojaře.  8)

Nechtěl bys to trochu rozvést? Ovládáš snad Haskell lépe než ti, kteří se tu o něm zmiňují? Pochlub se, rád se přiučím.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 13. 09. 2019, 21:53:55
C++ patří mezi nejtěžší programovací jazyky, s komplikovaností knihy musíš počítat. Pokud jsi začátečníkem, začni raději s Javou - ta je jednodušší a získáš lepší návyky.
Java je do začátků strašně ukecaná... a taky mám dojem, že z ní pak mají občas lidé pocit, že se všechno musí řešit přes výjimky, což mi jako lepší návyk nepřijde.
Výjimky jsou výrazně lepší, než předávání chybových stavů. Bez mechaniky výjimek se objektově moc programovat nedá.
OO nějak esenciálně závisí na výjimkách? Jak jejich absence omezuje posílání zpráv?
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 13. 09. 2019, 22:08:58
Vždy radostu si tu počíst. Někdo slyšel haskellu a hnedka se už považuje za neobyčejného (nebo jaký je opak obyčejného?) vývojaře.  8)
Nechtěl bys to trochu rozvést? Ovládáš snad Haskell lépe než ti, kteří se tu o něm zmiňují? Pochlub se, rád se přiučím.
Připojuji se, také bych se rád naučil něco nového o Haskellu nebo FP obecně.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 13. 09. 2019, 22:31:47
C++ patří mezi nejtěžší programovací jazyky, s komplikovaností knihy musíš počítat. Pokud jsi začátečníkem, začni raději s Javou - ta je jednodušší a získáš lepší návyky.
Java je do začátků strašně ukecaná... a taky mám dojem, že z ní pak mají občas lidé pocit, že se všechno musí řešit přes výjimky, což mi jako lepší návyk nepřijde.
Výjimky jsou výrazně lepší, než předávání chybových stavů. Bez mechaniky výjimek se objektově moc programovat nedá.
OO nějak esenciálně závisí na výjimkách? Jak jejich absence omezuje posílání zpráv?

Bez výjimek vlastně nemáš odezvu, co se s tou zprávou stalo - zda byla přijata či odmítnuta. Můžeš programovat i bez nich, ale praktické to není.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Cikáda 13. 09. 2019, 22:36:15
C++ patří mezi nejtěžší programovací jazyky, s komplikovaností knihy musíš počítat. Pokud jsi začátečníkem, začni raději s Javou - ta je jednodušší a získáš lepší návyky.
Java je do začátků strašně ukecaná... a taky mám dojem, že z ní pak mají občas lidé pocit, že se všechno musí řešit přes výjimky, což mi jako lepší návyk nepřijde.

Výjimky jsou výrazně lepší, než předávání chybových stavů. Bez mechaniky výjimek se objektově moc programovat nedá.

Výjimky jsou především výrazně dražší. Jinak moc nevidím důvod, proč by se bez nich nedalo objektově programovat...

Java je ukecaná, jen když se píší anemické (v podstatě zbytečné) třídy. Neukecaného Pythonu se mnozí programátoři snad i bojí.

Ne, Java je ukecaná sama o sobě. Už jen hloupé Hello World něco zabere.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: BoneFlute 13. 09. 2019, 22:36:41
Jen je k němu ta teorie prostě blíž než u C++.
Tak něco takového jsem víceméně chtěl říct. Plus to, že Haskel je víc deklarativní, což má IMHO velké důsledky. Jak na požadavky vývojáře, tak i na kvalitu výsledné práce.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: BoneFlute 13. 09. 2019, 22:39:05
Výjimky jsou především výrazně dražší.

Principielně?
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Cikáda 13. 09. 2019, 22:39:49
C++ patří mezi nejtěžší programovací jazyky, s komplikovaností knihy musíš počítat. Pokud jsi začátečníkem, začni raději s Javou - ta je jednodušší a získáš lepší návyky.
Java je do začátků strašně ukecaná... a taky mám dojem, že z ní pak mají občas lidé pocit, že se všechno musí řešit přes výjimky, což mi jako lepší návyk nepřijde.
Výjimky jsou výrazně lepší, než předávání chybových stavů. Bez mechaniky výjimek se objektově moc programovat nedá.
OO nějak esenciálně závisí na výjimkách? Jak jejich absence omezuje posílání zpráv?

Bez výjimek vlastně nemáš odezvu, co se s tou zprávou stalo - zda byla přijata či odmítnuta. Můžeš programovat i bez nich, ale praktické to není.

Nějak nevidím důvod, proč bych k tomu potřeboval výjimku...
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 13. 09. 2019, 22:52:38
C++ patří mezi nejtěžší programovací jazyky, s komplikovaností knihy musíš počítat. Pokud jsi začátečníkem, začni raději s Javou - ta je jednodušší a získáš lepší návyky.
Java je do začátků strašně ukecaná... a taky mám dojem, že z ní pak mají občas lidé pocit, že se všechno musí řešit přes výjimky, což mi jako lepší návyk nepřijde.
Výjimky jsou výrazně lepší, než předávání chybových stavů. Bez mechaniky výjimek se objektově moc programovat nedá.
OO nějak esenciálně závisí na výjimkách? Jak jejich absence omezuje posílání zpráv?

Bez výjimek vlastně nemáš odezvu, co se s tou zprávou stalo - zda byla přijata či odmítnuta. Můžeš programovat i bez nich, ale praktické to není.
Aha.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 13. 09. 2019, 22:54:29
Jen je k němu ta teorie prostě blíž než u C++.
Tak něco takového jsem víceméně chtěl říct. Plus to, že Haskel je víc deklarativní, což má IMHO velké důsledky. Jak na požadavky vývojáře, tak i na kvalitu výsledné práce.
Haskell je důsledně deklarativní, což je jenom dobře, ale jak to souvisí s C++ bordelem?
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Cikáda 13. 09. 2019, 22:55:33
Jen je k němu ta teorie prostě blíž než u C++.
Tak něco takového jsem víceméně chtěl říct. Plus to, že Haskel je víc deklarativní, což má IMHO velké důsledky. Jak na požadavky vývojáře, tak i na kvalitu výsledné práce.

Jak to myslíš? Především tu poslední větu, protože i v Haskellu jsem viděl dost nehezké věci...

Výjimky jsou především výrazně dražší.

Principielně?

Dobře, nejdřív by bylo asi vhodné si říct, co přesně pod výjimkami každý vidíme.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: BoneFlute 13. 09. 2019, 23:30:34
Jen je k němu ta teorie prostě blíž než u C++.
Tak něco takového jsem víceméně chtěl říct. Plus to, že Haskel je víc deklarativní, což má IMHO velké důsledky. Jak na požadavky vývojáře, tak i na kvalitu výsledné práce.

Jak to myslíš? Především tu poslední větu, protože i v Haskellu jsem viděl dost nehezké věci...
To se nevylučuje.

Mám před očima kolegy, kteří programovali stylem: funguje - funguje. Proč? Nevím, nezajímá. Co když... - nevím, nezajímá. Funguje, tak neřeš.

Domníváma se, že obecně jazyky C++, Java, Python k tomu svádí víc, než Haskell. Ale třeba je to jen můj dojem.

Výjimky jsou především výrazně dražší.

Principielně?

Dobře, nejdřív by bylo asi vhodné si říct, co přesně pod výjimkami každý vidíme.
Co třeba tento pěknej článek: http://www.abclinuxu.cz/blog/radekm/2015/6/algebraicke-efekty

Taky mne napadlo, že vhodně poskládaný funkce vracející Maybe/Either s nějakou omáčkou kolem by se mohli celkem podobat fungování výjimek. Compile-time.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Cikáda 13. 09. 2019, 23:48:40
Jen je k němu ta teorie prostě blíž než u C++.
Tak něco takového jsem víceméně chtěl říct. Plus to, že Haskel je víc deklarativní, což má IMHO velké důsledky. Jak na požadavky vývojáře, tak i na kvalitu výsledné práce.

Jak to myslíš? Především tu poslední větu, protože i v Haskellu jsem viděl dost nehezké věci...
To se nevylučuje.

Mám před očima kolegy, kteří programovali stylem: funguje - funguje. Proč? Nevím, nezajímá. Co když... - nevím, nezajímá. Funguje, tak neřeš.

Domníváma se, že obecně jazyky C++, Java, Python k tomu svádí víc, než Haskell. Ale třeba je to jen můj dojem.

Ne, tady se shodneme. On tomu ale imho dost pomáhá ten silný typový systém.

Výjimky jsou především výrazně dražší.

Principielně?

Dobře, nejdřív by bylo asi vhodné si říct, co přesně pod výjimkami každý vidíme.
Co třeba tento pěknej článek: http://www.abclinuxu.cz/blog/radekm/2015/6/algebraicke-efekty

Taky mne napadlo, že vhodně poskládaný funkce vracející Maybe/Either s nějakou omáčkou kolem by se mohli celkem podobat fungování výjimek. Compile-time.

Dík za článek, přečtu. :)

Osobně třeba Maybe/Either pořád beru jako "lepší návratové kódy". Výjimky, v tom kontextu, mám spojené se stack unwindingem a run-time.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 14. 09. 2019, 00:05:56
Taky mne napadlo, že vhodně poskládaný funkce vracející Maybe/Either s nějakou omáčkou kolem by se mohli celkem podobat fungování výjimek. Compile-time.
Ano, Maybe je isomorfní s výjimkami.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Cikáda 14. 09. 2019, 00:15:25
Taky mne napadlo, že vhodně poskládaný funkce vracející Maybe/Either s nějakou omáčkou kolem by se mohli celkem podobat fungování výjimek. Compile-time.
Ano, Maybe je isomorfní s výjimkami.

To je dost zajímavé tvrzení na to, jak je tu pojem "výjimky" dost abstraktní.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: BoneFlute 14. 09. 2019, 00:52:56
Taky mne napadlo, že vhodně poskládaný funkce vracející Maybe/Either s nějakou omáčkou kolem by se mohli celkem podobat fungování výjimek. Compile-time.
Ano, Maybe je isomorfní s výjimkami.

To je dost zajímavé tvrzení na to, jak je tu pojem "výjimky" dost abstraktní.

Idea výjimek je, že odchytáváš určitou skupinu konkrétních chybových stavů v konkrétním stromu výrazů. Víc toho není. IMHO zbytek je implementační detail.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 14. 09. 2019, 01:41:15
Taky mne napadlo, že vhodně poskládaný funkce vracející Maybe/Either s nějakou omáčkou kolem by se mohli celkem podobat fungování výjimek. Compile-time.
Ano, Maybe je isomorfní s výjimkami.
To je dost zajímavé tvrzení na to, jak je tu pojem "výjimky" dost abstraktní.
Idea výjimek je, že odchytáváš určitou skupinu konkrétních chybových stavů v konkrétním stromu výrazů. Víc toho není. IMHO zbytek je implementační detail.
Výjimky jsou hlavně konkrétní implementace, prostě takový elegantnější long jump z céčka. Maybe je instanciace určité abstraktní konstrukce (“návrhového vzoru”), kterou lze implementovat třeba právě výjimkami. Ve skutečnosti třeba řez v logickém programování je taky jen instance Maybe a vskutku se implementuje výjimkami (jen tedy poněkud složitějšími).

A abych se vrátil z odbočky, Haskellu chybí vzhledem k “výjimkám” transparentnost, v blbovzdorném funkcionálním jazyce by měl překladač podporovat automatický lifting na Kleisliho kompozici, když nějaká normální funkce dostane instanci Maybe. Možná právě tohle lidi mate, jakmile někde zavedu v Haskellu Maybe, kontaminuju tím celý kód s tímto místem propojený. Přitom je pro překladač triviální přidat před onu funkci η, aby do sebe vše typově zapadalo.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 14. 09. 2019, 02:13:17
C++ patří mezi nejtěžší programovací jazyky, s komplikovaností knihy musíš počítat. Pokud jsi začátečníkem, začni raději s Javou - ta je jednodušší a získáš lepší návyky.
Java je do začátků strašně ukecaná... a taky mám dojem, že z ní pak mají občas lidé pocit, že se všechno musí řešit přes výjimky, což mi jako lepší návyk nepřijde.
Výjimky jsou výrazně lepší, než předávání chybových stavů. Bez mechaniky výjimek se objektově moc programovat nedá.
OO nějak esenciálně závisí na výjimkách? Jak jejich absence omezuje posílání zpráv?

Bez výjimek vlastně nemáš odezvu, co se s tou zprávou stalo - zda byla přijata či odmítnuta. Můžeš programovat i bez nich, ale praktické to není.
Nějak nevidím důvod, proč bych k tomu potřeboval výjimku...

Jak to tedy uděláš, když ten chybový stav nesmíš předat returnem ani parametry nesmíš předávat odkazem?
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: BoneFlute 14. 09. 2019, 04:23:05
Jak to tedy uděláš, když ten chybový stav nesmíš předat returnem ani parametry nesmíš předávat odkazem?
To je ještě sranda. Ale jak to uděláš, když ten chybový stav nesmíš předat returnem ani parametry nesmíš předávat odkazem a nesmíš vyhazovat výjimky?
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 14. 09. 2019, 07:47:41
C++ patří mezi nejtěžší programovací jazyky, s komplikovaností knihy musíš počítat. Pokud jsi začátečníkem, začni raději s Javou - ta je jednodušší a získáš lepší návyky.
Java je do začátků strašně ukecaná... a taky mám dojem, že z ní pak mají občas lidé pocit, že se všechno musí řešit přes výjimky, což mi jako lepší návyk nepřijde.
Výjimky jsou výrazně lepší, než předávání chybových stavů. Bez mechaniky výjimek se objektově moc programovat nedá.
OO nějak esenciálně závisí na výjimkách? Jak jejich absence omezuje posílání zpráv?
Bez výjimek vlastně nemáš odezvu, co se s tou zprávou stalo - zda byla přijata či odmítnuta. Můžeš programovat i bez nich, ale praktické to není.
Nějak nevidím důvod, proč bych k tomu potřeboval výjimku...
Jak to tedy uděláš, když ten chybový stav nesmíš předat returnem ani parametry nesmíš předávat odkazem?
Jenže ty ho můžeš vrátit a parametry lze samozřejmě předávat odkazem.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 14. 09. 2019, 12:16:03
Jak to tedy uděláš, když ten chybový stav nesmíš předat returnem ani parametry nesmíš předávat odkazem?
Jenže ty ho můžeš vrátit a parametry lze samozřejmě předávat odkazem.

Už nejsme ve 20. století. Tyto archaismy do moderního programování nepatří.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 14. 09. 2019, 12:19:35
Jak to tedy uděláš, když ten chybový stav nesmíš předat returnem ani parametry nesmíš předávat odkazem?
Jenže ty ho můžeš vrátit a parametry lze samozřejmě předávat odkazem.
Už nejsme ve 20. století. Tyto archaismy do moderního programování nepatří.
Co sis šlehnul?
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 14. 09. 2019, 12:21:12
Jak to tedy uděláš, když ten chybový stav nesmíš předat returnem ani parametry nesmíš předávat odkazem?
To je ještě sranda. Ale jak to uděláš, když ten chybový stav nesmíš předat returnem ani parametry nesmíš předávat odkazem a nesmíš vyhazovat výjimky?

V parametrech předám vhodný objekt.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 14. 09. 2019, 12:22:53
Jak to tedy uděláš, když ten chybový stav nesmíš předat returnem ani parametry nesmíš předávat odkazem?
Jenže ty ho můžeš vrátit a parametry lze samozřejmě předávat odkazem.
Už nejsme ve 20. století. Tyto archaismy do moderního programování nepatří.
Co sis šlehnul?

Snad ti nedošly argumenty, žes vytáhl podpásovku?
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Jiří Havel 14. 09. 2019, 14:05:15
Jak to tedy uděláš, když ten chybový stav nesmíš předat returnem ani parametry nesmíš předávat odkazem?
Jenže ty ho můžeš vrátit a parametry lze samozřejmě předávat odkazem.
Už nejsme ve 20. století. Tyto archaismy do moderního programování nepatří.
Co sis šlehnul?

Snad ti nedošly argumenty, žes vytáhl podpásovku?
Nic proti, ale označit něco jako archaismus taky není argument.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 14. 09. 2019, 14:44:19
Jak to tedy uděláš, když ten chybový stav nesmíš předat returnem ani parametry nesmíš předávat odkazem?
Jenže ty ho můžeš vrátit a parametry lze samozřejmě předávat odkazem.
Už nejsme ve 20. století. Tyto archaismy do moderního programování nepatří.
Co sis šlehnul?
Snad ti nedošly argumenty, žes vytáhl podpásovku?
Nic proti, ale označit něco jako archaismus taky není argument.

Argument? Co třeba ten, že je to v rozporu s Clean Code?

V některých moderních jazycích to ani nejde. Někdo snad výjimky považuje za božstvo, kterého není radno se dotýkat, ale je to prostě sekundární informační kanál pro přenos chybových stavů, aby ten hlavní mohl být čistě na data.

A neplatí, že jsou výjimky drahé. Jsou levnější než ty okliky, které kvůli nim někteří vývojáři dělají.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: BoneFlute 14. 09. 2019, 14:51:14
Jak to tedy uděláš, když ten chybový stav nesmíš předat returnem ani parametry nesmíš předávat odkazem?
To je ještě sranda. Ale jak to uděláš, když ten chybový stav nesmíš předat returnem ani parametry nesmíš předávat odkazem a nesmíš vyhazovat výjimky?

V parametrech předám vhodný objekt.

Takže side-effect. To jsme si teda pomohli.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: BoneFlute 14. 09. 2019, 14:53:02
Argument? Co třeba ten, že je to v rozporu s Clean Code?
...
Někdo snad výjimky považuje za božstvo, ...
Zvýraznil jsem související.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 14. 09. 2019, 15:01:53
Jak to tedy uděláš, když ten chybový stav nesmíš předat returnem ani parametry nesmíš předávat odkazem?
To je ještě sranda. Ale jak to uděláš, když ten chybový stav nesmíš předat returnem ani parametry nesmíš předávat odkazem a nesmíš vyhazovat výjimky?
V parametrech předám vhodný objekt.
Takže side-effect. To jsme si teda pomohli.

O tom side-effectu vím a proto používám výjimky. Tak se předveď, jak bys to vyřešil.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 14. 09. 2019, 15:06:27
Argument? Co třeba ten, že je to v rozporu s Clean Code?
...
Někdo snad výjimky považuje za božstvo, ...
Zvýraznil jsem související.

Jak to spolu souvisí? Clean Code je návodem, jak psát kvalitní kód. Je v něm snad něco špatně?
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: BoneFlute 14. 09. 2019, 15:16:07
Jak to tedy uděláš, když ten chybový stav nesmíš předat returnem ani parametry nesmíš předávat odkazem?
To je ještě sranda. Ale jak to uděláš, když ten chybový stav nesmíš předat returnem ani parametry nesmíš předávat odkazem a nesmíš vyhazovat výjimky?
V parametrech předám vhodný objekt.
Takže side-effect. To jsme si teda pomohli.

O tom side-effectu vím a proto používám výjimky. Tak se předveď, jak bys to vyřešil.
Jednoduše. Já bych v prvé řadě nevytvářel umělá omezení.

Nemám v zásadě nic proti výjimkám, ale návratová hodnota je vždycky značka ideál. Zvláště v typovaných jazycích.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 14. 09. 2019, 15:48:22
Jak to tedy uděláš, když ten chybový stav nesmíš předat returnem ani parametry nesmíš předávat odkazem?
To je ještě sranda. Ale jak to uděláš, když ten chybový stav nesmíš předat returnem ani parametry nesmíš předávat odkazem a nesmíš vyhazovat výjimky?
V parametrech předám vhodný objekt.
Takže side-effect. To jsme si teda pomohli.

O tom side-effectu vím a proto používám výjimky. Tak se předveď, jak bys to vyřešil.
Jednoduše. Já bych v prvé řadě nevytvářel umělá omezení.

Nemám v zásadě nic proti výjimkám, ale návratová hodnota je vždycky značka ideál. Zvláště v typovaných jazycích.

Návratová hodnota je určena pro data. Pokud bych například místo stringu dostal int nebo boolean, tak by z toho navazující kód mohl být zmaten. Takovou funkci či metodu by nebylo možné použít ve výrazu. Analýza typu návratové hodnoty je zase code smell.

Výjimky to skutečně řeší mnohem lépe a popisněji. Dozvím se z nich nejen návratový kód, ale i co a kde se stalo a za jakých okolností. A když se mi nechce ji zachytávat, tak ji prostě nechám propadnout.

Když budeš ignorovat návratové kódy, tak se ti bude program chovat podivně. S výjimkami se ti to nemůže stát, tedy pokud je nebudeš polykat.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 14. 09. 2019, 15:53:02
Nemám v zásadě nic proti výjimkám, ale návratová hodnota je vždycky značka ideál. Zvláště v typovaných jazycích.

Jak bys tedy vyřešil návratovou hodnotu funkce, která má vracet třeba string, ale uvnitř selže? Prosím jinak než v Golang, jehož řešení znám.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 14. 09. 2019, 16:08:11
Nemám v zásadě nic proti výjimkám, ale návratová hodnota je vždycky značka ideál. Zvláště v typovaných jazycích.
Jak bys tedy vyřešil návratovou hodnotu funkce, která má vracet třeba string, ale uvnitř selže? Prosím jinak než v Golang, jehož řešení znám.
O monádách jsi už slyšel?  ::)
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Cikáda 14. 09. 2019, 16:09:50
Návratová hodnota je určena pro data. Pokud bych například místo stringu dostal int nebo boolean, tak by z toho navazující kód mohl být zmaten. Takovou funkci či metodu by nebylo možné použít ve výrazu. Analýza typu návratové hodnoty je zase code smell.

Pokud místo stringu dostanu int nebo boolean, tak je chyba trochu jinde než ve výjimkách / návratové hodnotě.

Výjimky to skutečně řeší mnohem lépe a popisněji. Dozvím se z nich nejen návratový kód, ale i co a kde se stalo a za jakých okolností. A když se mi nechce ji zachytávat, tak ji prostě nechám propadnout.

A z návratového kódu nelze určit, co a kde se stalo?

Když budeš ignorovat návratové kódy, tak se ti bude program chovat podivně. S výjimkami se ti to nemůže stát, tedy pokud je nebudeš polykat.

Jakože když budu ignorovat návratové kódy, tak se bude program chovat divně, ale když budu ignorovat výjimky, tak se divně chovat nebude?  :D

Nemám v zásadě nic proti výjimkám, ale návratová hodnota je vždycky značka ideál. Zvláště v typovaných jazycích.

Jak bys tedy vyřešil návratovou hodnotu funkce, která má vracet třeba string, ale uvnitř selže? Prosím jinak než v Golang, jehož řešení znám.

Například Either, Maybe/std::optional...
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 14. 09. 2019, 16:12:32
Nemám v zásadě nic proti výjimkám, ale návratová hodnota je vždycky značka ideál. Zvláště v typovaných jazycích.
Jak bys tedy vyřešil návratovou hodnotu funkce, která má vracet třeba string, ale uvnitř selže? Prosím jinak než v Golang, jehož řešení znám.
O monádách jsi už slyšel?  ::)

Ano, slyšel. A také jsem slyšel, že Maybe je izomorfní s výjimkami.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 14. 09. 2019, 16:20:50
Návratová hodnota je určena pro data. Pokud bych například místo stringu dostal int nebo boolean, tak by z toho navazující kód mohl být zmaten. Takovou funkci či metodu by nebylo možné použít ve výrazu. Analýza typu návratové hodnoty je zase code smell.
Pokud místo stringu dostanu int nebo boolean, tak je chyba trochu jinde než ve výjimkách / návratové hodnotě.

Tak tedy uveď návratovou hodnotu funkce, která má vrátit string, ale selže. Zároveň chci vědět, proč selhala a za jakých okolností.

Haskell prosím odlož stranou, bavíme se o objektových jazycích. Golang také můžeš vynechat, jelikož jeho řešení znám. Zajímá mě (a podle nadpisu nejen mne) řešení pro C++ a Javu.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 14. 09. 2019, 16:21:43
Nemám v zásadě nic proti výjimkám, ale návratová hodnota je vždycky značka ideál. Zvláště v typovaných jazycích.
Jak bys tedy vyřešil návratovou hodnotu funkce, která má vracet třeba string, ale uvnitř selže? Prosím jinak než v Golang, jehož řešení znám.
O monádách jsi už slyšel?  ::)
Ano, slyšel. A také jsem slyšel, že Maybe je izomorfní s výjimkami.
Tak proč se ptáš?
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 14. 09. 2019, 16:30:06
Když budeš ignorovat návratové kódy, tak se ti bude program chovat podivně. S výjimkami se ti to nemůže stát, tedy pokud je nebudeš polykat.
Jakože když budu ignorovat návratové kódy, tak se bude program chovat divně, ale když budu ignorovat výjimky, tak se divně chovat nebude?  :D

Přesně tak. Pokud neodchytíš výjimku, program zhavaruje a vypíše report, proč a kde zhavaroval. To není podivné, ale standardní chování.

Pokud budeš ignorovat návratový kód s chybou, tak s ní pojede dál a ani se nedozvíš, co se stalo, co bylo příčinou podivného chování.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 14. 09. 2019, 16:39:09
Nemám v zásadě nic proti výjimkám, ale návratová hodnota je vždycky značka ideál. Zvláště v typovaných jazycích.
Jak bys tedy vyřešil návratovou hodnotu funkce, která má vracet třeba string, ale uvnitř selže? Prosím jinak než v Golang, jehož řešení znám.
O monádách jsi už slyšel?  ::)
Ano, slyšel. A také jsem slyšel, že Maybe je izomorfní s výjimkami.
Tak proč se ptáš?

Přečti si diskuzi. Používám výjimky tam, kde mají být. Někteří diskutující píší, že by se neměly používat, protože jsou drahé, že by se měly používat návratové hodnoty. Z mého pohledu jen s výjimkami neumí pracovat.

Je snad logické, že se jich ptám, jak by to tedy řešili v C++ a Javě, kdyby nesměli výjimky používat. Nabízí se mi pouze kostrbatá řešení, které buď používají, anebo mají něco lepšího.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 14. 09. 2019, 16:51:40
Nemám v zásadě nic proti výjimkám, ale návratová hodnota je vždycky značka ideál. Zvláště v typovaných jazycích.
Jak bys tedy vyřešil návratovou hodnotu funkce, která má vracet třeba string, ale uvnitř selže? Prosím jinak než v Golang, jehož řešení znám.
O monádách jsi už slyšel?  ::)
Ano, slyšel. A také jsem slyšel, že Maybe je izomorfní s výjimkami.
Tak proč se ptáš?

Přečti si diskuzi. Používám výjimky tam, kde mají být. Někteří diskutující píší, že by se neměly používat, protože jsou drahé, že by se měly používat návratové hodnoty. Z mého pohledu jen s výjimkami neumí pracovat.

Je snad logické, že se jich ptám, jak by to tedy řešili v C++ a Javě, kdyby nesměli výjimky používat. Nabízí se mi pouze kostrbatá řešení, které buď používají, anebo mají něco lepšího.
Máš selektivní slepotu na Maybe? Vždyť ti to tu píšou furt dokola.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: BoneFlute 14. 09. 2019, 16:55:53
Nemám v zásadě nic proti výjimkám, ale návratová hodnota je vždycky značka ideál. Zvláště v typovaných jazycích.

Jak bys tedy vyřešil návratovou hodnotu funkce, která má vracet třeba string, ale uvnitř selže? Prosím jinak než v Golang, jehož řešení znám.

Asi se budu opakovat: Já bych v prvé řadě nevytvářel umělá omezení.

Zrovna případ Golang je super v tom, jak v jazyce kde "zapoměli" vynutit povinnost odebrat hodnotu, vyřešit návrat chyby.
V Javě jsou zvykem výjimky, dělal bych to tedy výjimkami. Ne proto, že by to byla nějaká zvláštní výhra, ale protože je to tam zvykem.
C++ nedělám, to je hnusnej jazyk.
Rust to řeší jako Golang, nebo případně monádama.
Lua to řeší jako Golang, ale výjimky to taky umí.
etc.

Je možno si všimnout, že mnoho, zvláště staticky typovaných jazyků, používají návratovou hodnotu. Mnoho dalších jazyků používá výjimky. Šermovat tu s CleanCode a brát výjimky jako písmo svaté je poněkud... nezkušené.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 14. 09. 2019, 16:57:32
Je snad logické, že se jich ptám, jak by to tedy řešili v C++ a Javě, kdyby nesměli výjimky používat. Nabízí se mi pouze kostrbatá řešení, které buď používají, anebo mají něco lepšího.
Máš selektivní slepotu na Maybe? Vždyť ti to tu píšou furt dokola.

Jak jsem měl poznat, že nemají na mysli Maybe z Haskellu, ale Maybe z C++ a Javy?
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 14. 09. 2019, 17:03:37
Nemám v zásadě nic proti výjimkám, ale návratová hodnota je vždycky značka ideál. Zvláště v typovaných jazycích.
Jak bys tedy vyřešil návratovou hodnotu funkce, která má vracet třeba string, ale uvnitř selže? Prosím jinak než v Golang, jehož řešení znám.
V Javě jsou zvykem výjimky, dělal bych to tedy výjimkami. Ne proto, že by to byla nějaká zvláštní výhra, ale protože je to tam zvykem.
C++ nedělám, to je hnusnej jazyk.

Je možno si všimnout, že mnoho, zvláště staticky typovaných jazyků, používají návratovou hodnotu. Mnoho dalších jazyků používá výjimky. Šermovat tu s CleanCode a brát výjimky jako písmo svaté je poněkud... nezkušené.

C++ a Java jsou staticky typované? Skaláry možná, ale objekty jsou typované dynamicky.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: BoneFlute 14. 09. 2019, 17:04:19
Z mého pohledu jen s výjimkami neumí pracovat.
Připomíná se mi tady takové otřepané úsloví o OOP: Jsou lidé, kteří nepoužívají objekty protože jim nerozumí. A pak jsou lidé, kteří nepoužívají objekty, protože jim rozumí velmi dobře.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 14. 09. 2019, 17:15:58
Nemám v zásadě nic proti výjimkám, ale návratová hodnota je vždycky značka ideál. Zvláště v typovaných jazycích.
Jak bys tedy vyřešil návratovou hodnotu funkce, která má vracet třeba string, ale uvnitř selže? Prosím jinak než v Golang, jehož řešení znám.
V Javě jsou zvykem výjimky, dělal bych to tedy výjimkami. Ne proto, že by to byla nějaká zvláštní výhra, ale protože je to tam zvykem.
C++ nedělám, to je hnusnej jazyk.

Je možno si všimnout, že mnoho, zvláště staticky typovaných jazyků, používají návratovou hodnotu. Mnoho dalších jazyků používá výjimky. Šermovat tu s CleanCode a brát výjimky jako písmo svaté je poněkud... nezkušené.
C++ a Java jsou staticky typované? Skaláry možná, ale objekty jsou typované dynamicky.
Ty v tom máš slušný guláš. Tak jo, C++ je dynamicky typované a Zeman není dementní alkoholik.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Cikáda 14. 09. 2019, 18:53:31
Někteří diskutující píší, že by se neměly používat, protože jsou drahé, že by se měly používat návratové hodnoty.

Ehm, to tu někdo napsal?

Je snad logické, že se jich ptám, jak by to tedy řešili v C++ a Javě, kdyby nesměli výjimky používat. Nabízí se mi pouze kostrbatá řešení, které buď používají, anebo mají něco lepšího.

Na to ses ale doposud neptal.

Tak tedy uveď návratovou hodnotu funkce, která má vrátit string, ale selže. Zároveň chci vědět, proč selhala a za jakých okolností.

To je dost abstraktní zadání. Nicméně lze to řešit např. dvojicí, referencovaným argumentem i výjimkou. Možností je dost a situací, kdy je to které řešení lepší, nespočet.

Haskell prosím odlož stranou, bavíme se o objektových jazycích.

Odkdy?
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 14. 09. 2019, 19:09:05
Tak tedy uveď návratovou hodnotu funkce, která má vrátit string, ale selže. Zároveň chci vědět, proč selhala a za jakých okolností.
To je dost abstraktní zadání. Nicméně lze to řešit např. dvojicí, referencovaným argumentem i výjimkou. Možností je dost a situací, kdy je to které řešení lepší, nespočet.

Dvojice se používají např. v Golang. V C++ a Javě vy to působilo poněkud nepatřičně.

Referencovaný argument byl zamítnut kvůli side-effectu a jsem téhož názoru.

Zbývají výjimky, které nejsou drahé, jsou praktické a vcelku efektivně brání logickým špagetám (není potřebné "else"). Jen se nesmí zneužívat k flow-controll.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Cikáda 14. 09. 2019, 19:18:49
Tak tedy uveď návratovou hodnotu funkce, která má vrátit string, ale selže. Zároveň chci vědět, proč selhala a za jakých okolností.
To je dost abstraktní zadání. Nicméně lze to řešit např. dvojicí, referencovaným argumentem i výjimkou. Možností je dost a situací, kdy je to které řešení lepší, nespočet.

Dvojice se používají např. v Golang. V C++ a Javě vy to působilo poněkud nepatřičně.

Nevím, co na auto [ ] = vypadá nepatřičně.

Referencovaný argument byl zamítnut kvůli side-effectu a jsem téhož názoru.

Takže teď je in nepoužívat cokoliv s vedlejšími efekty?

Zbývají výjimky, které nejsou drahé, jsou praktické a vcelku efektivně brání logickým špagetám (není potřebné "else"). Jen se nesmí zneužívat k flow-controll.

To je zase nepodložených tvrzení. 1) Nezbývají výjimky. 2) Pokud způsobí stack-unwinding, tak ano, jsou typicky významně dražší než návratová hodnota. 3) Nevím, proč by mělo být potřebné else.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 14. 09. 2019, 19:32:53
Tak tedy uveď návratovou hodnotu funkce, která má vrátit string, ale selže. Zároveň chci vědět, proč selhala a za jakých okolností.
To je dost abstraktní zadání. Nicméně lze to řešit např. dvojicí, referencovaným argumentem i výjimkou. Možností je dost a situací, kdy je to které řešení lepší, nespočet.
Dvojice se používají např. v Golang. V C++ a Javě vy to působilo poněkud nepatřičně.
Nevím, co na auto [ ] = vypadá nepatřičně.

Blbě se to používá ve výrazech.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 14. 09. 2019, 19:45:11
Zbývají výjimky, které nejsou drahé, jsou praktické a vcelku efektivně brání logickým špagetám (není potřebné "else"). Jen se nesmí zneužívat k flow-controll.

To je zase nepodložených tvrzení. 1) Nezbývají výjimky. 2) Pokud způsobí stack-unwinding, tak ano, jsou typicky významně dražší než návratová hodnota. 3) Nevím, proč by mělo být potřebné else.

Když místo výjimek použiješ návratovou hodnotu, tak musíš použít kolem ní dost bižuterie, aby se ti hodnoty nepomíchaly s chybovými stavy, takže se ceny vyrovnají. Výjimky jsou však výrazně přehlednější, protože jejich ošetření se nachází mimo výkonný kód.

A jako vždy: když neošetříš výjimku, tak se sama ozve. Neošetřený návratový kód bude zticha.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Cikáda 14. 09. 2019, 19:45:58
Tak tedy uveď návratovou hodnotu funkce, která má vrátit string, ale selže. Zároveň chci vědět, proč selhala a za jakých okolností.
To je dost abstraktní zadání. Nicméně lze to řešit např. dvojicí, referencovaným argumentem i výjimkou. Možností je dost a situací, kdy je to které řešení lepší, nespočet.
Dvojice se používají např. v Golang. V C++ a Javě vy to působilo poněkud nepatřičně.
Nevím, co na auto [ ] = vypadá nepatřičně.

Blbě se to používá ve výrazech.

Existuje first a second.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: tomas88 14. 09. 2019, 20:08:08
Vždy radostu si tu počíst. Někdo slyšel haskellu a hnedka se už považuje za neobyčejného (nebo jaký je opak obyčejného?) vývojaře.  8)

Nechtěl bys to trochu rozvést? Ovládáš snad Haskell lépe než ti, kteří se tu o něm zmiňují? Pochlub se, rád se přiučím.

Diky, ale opravdu se tu s váma (tím myslí, tu zdejší spam "elitu") nechci poměřovat / spamovat. Jen jsem chtěl vypíchnout tu absorditu, jak jinak obyčejní programátoři (všichni tu lepíte nějaký informační systémy a neříkejte, že ne), se dokážou navážet do obyčejných prográmátorů.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 14. 09. 2019, 20:30:36
Vždy radostu si tu počíst. Někdo slyšel haskellu a hnedka se už považuje za neobyčejného (nebo jaký je opak obyčejného?) vývojaře.  8)
Nechtěl bys to trochu rozvést? Ovládáš snad Haskell lépe než ti, kteří se tu o něm zmiňují? Pochlub se, rád se přiučím.
Diky, ale opravdu se tu s váma (tím myslí, tu zdejší spam "elitu") nechci poměřovat / spamovat. Jen jsem chtěl vypíchnout tu absorditu, jak jinak obyčejní programátoři (všichni tu lepíte nějaký informační systémy a neříkejte, že ne), se dokážou navážet do obyčejných prográmátorů.

Nebýt této komunity, asi bych se o Haskellu nedozvěděl. Snad není špatně, když se jich občas zeptám jak ho používají? Sám používám převážně PHP a XSLT, ale nebráním se rozšiřování obzorů.

V čem tedy programuješ?
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 14. 09. 2019, 20:55:09
Tak tedy uveď návratovou hodnotu funkce, která má vrátit string, ale selže. Zároveň chci vědět, proč selhala a za jakých okolností.
To je dost abstraktní zadání. Nicméně lze to řešit např. dvojicí, referencovaným argumentem i výjimkou. Možností je dost a situací, kdy je to které řešení lepší, nespočet.
Dvojice se používají např. v Golang. V C++ a Javě vy to působilo poněkud nepatřičně.
V Javě působí nepatřičně všechno. Ale C++ má n-tice přímo v syntaxi. I když lepší je použít optional nebo něco podobného, to je přímo v STL.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Jiří Havel 14. 09. 2019, 21:08:42
Když místo výjimek použiješ návratovou hodnotu, tak musíš použít kolem ní dost bižuterie, aby se ti hodnoty nepomíchaly s chybovými stavy, takže se ceny vyrovnají. Výjimky jsou však výrazně přehlednější, protože jejich ošetření se nachází mimo výkonný kód.

A jako vždy: když neošetříš výjimku, tak se sama ozve. Neošetřený návratový kód bude zticha.
Když neošetříš výjimku, tak se zas tak moc neozve. V lepším případě to v runtime komplet zdechne. V horším případě cestou nahoru rozbije nějaký ten invariant a chytně ji nějaký obecný catch blok.
V novém C++ máme třeba [[nodiscard]], takže neošetřený návratový kód se ozve už při kompilaci.

Zásadní problém výjimek je IMO právě to, že jsou oddělené od výkonného kódu a nejsou vidět.
Při pohledu na cizí kód nevím, co může a nemůže házet. Psát tak, že může házet opravdu cokoliv se moc nedá. Minimálně úklid a nějaký "commit" úspěšně vypočítaných hodnot (v c++ je to třeba oblíbený vzor výpočet a pak noexcept swap) musí jít bez házení. Jinak není moc šance udržet nějaké invarianty, leda tak při chybě všechno zahodit a doufat že to GC zvládne všechno pouklízet. O nějaké "strong exception safety" se v takovém případě moc uvažovat nedá.
Výkonný kód a chyby v něm jsou logicky dost úzce svázané a když je to na dvou místech tak se může snáze stát, že se upraví jen jedno. Ošetření výjimečných chyb je, díky tomu že to nastává jen zřídka, ten nejmíň otestovaný a nejvíc zabugovaný kód.

Z mých zkušeností byly výjimky výhodné, pokud jsem chyby nechtěl řešit. Tak trochu strčit hlavu do písku a nechat ať si to volající přebere. Ve chvíli kdy jsem začal přemýšlet nad možnými chybami a co by se v takovém případě mělo stát byly výjimky dost nešikovné. Právě díky tomu, že jsem ty možné stavy musel rozseknout a řešit na dvou místech.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 14. 09. 2019, 21:29:57
Když místo výjimek použiješ návratovou hodnotu, tak musíš použít kolem ní dost bižuterie, aby se ti hodnoty nepomíchaly s chybovými stavy, takže se ceny vyrovnají. Výjimky jsou však výrazně přehlednější, protože jejich ošetření se nachází mimo výkonný kód.

A jako vždy: když neošetříš výjimku, tak se sama ozve. Neošetřený návratový kód bude zticha.
Když neošetříš výjimku, tak se zas tak moc neozve. V lepším případě to v runtime komplet zdechne. V horším případě cestou nahoru rozbije nějaký ten invariant a chytně ji nějaký obecný catch blok.
V novém C++ máme třeba [[nodiscard]], takže neošetřený návratový kód se ozve už při kompilaci.

Zásadní problém výjimek je IMO právě to, že jsou oddělené od výkonného kódu a nejsou vidět.
Při pohledu na cizí kód nevím, co může a nemůže házet. Psát tak, že může házet opravdu cokoliv se moc nedá. Minimálně úklid a nějaký "commit" úspěšně vypočítaných hodnot (v c++ je to třeba oblíbený vzor výpočet a pak noexcept swap) musí jít bez házení. Jinak není moc šance udržet nějaké invarianty, leda tak při chybě všechno zahodit a doufat že to GC zvládne všechno pouklízet. O nějaké "strong exception safety" se v takovém případě moc uvažovat nedá.
Výkonný kód a chyby v něm jsou logicky dost úzce svázané a když je to na dvou místech tak se může snáze stát, že se upraví jen jedno. Ošetření výjimečných chyb je, díky tomu že to nastává jen zřídka, ten nejmíň otestovaný a nejvíc zabugovaný kód.

Z mých zkušeností byly výjimky výhodné, pokud jsem chyby nechtěl řešit. Tak trochu strčit hlavu do písku a nechat ať si to volající přebere. Ve chvíli kdy jsem začal přemýšlet nad možnými chybami a co by se v takovém případě mělo stát byly výjimky dost nešikovné. Právě díky tomu, že jsem ty možné stavy musel rozseknout a řešit na dvou místech.

Tak to máme s výjimkami opačné zkušenosti. Neošetřené výjimky se mi krásně ozývají už v testech a vzhledem k tomu, že mají společného rodiče, vím přesně co může házet. V C++ je to jinak - výjimky mohou být jakéhokoli typu a proto je v tom bordel, který popisuješ. O schopnostech GC nemám pochybnosti.

Výjimečné chyby ošetříš o pár pater výš a vhledem k jednotnému rozhraní v tom nevidím žádný problém. Granularitu lze kdykoli zjemnit odchycením výjimky a uložením do stacku nové výjimky na vyšším levelu. Tím si zdroj výjimky krásně vytrasuješ.

Když upravíš jen kód nebo ošetření výjimek, tak tě na to testy hned upozorní. Toho bych se nebál.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: BoneFlute 14. 09. 2019, 23:15:21
Zásadní problém výjimek je IMO právě to, že jsou oddělené od výkonného kódu a nejsou vidět.
Při pohledu na cizí kód nevím, co může a nemůže házet.

+1

Chtělo by to něco do syntaxe, kterou by se dalo jasně specifikovat jaké výjimky to může házet. Skutečnost v Javě, kdy musíš definovat co ti to vrátí za výsledek, ale nemusíš definovat co ti to háže za výjimky mi přijde takové nekonzistentní.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Jiří Havel 14. 09. 2019, 23:21:04
Tak to máme s výjimkami opačné zkušenosti. Neošetřené výjimky se mi krásně ozývají už v testech a vzhledem k tomu, že mají společného rodiče, vím přesně co může házet. V C++ je to jinak - výjimky mohou být jakéhokoli typu a proto je v tom bordel, který popisuješ. O schopnostech GC nemám pochybnosti.
Jak mi bázová třída pomůže v tom poznat, jestli nějaká funkce může házet nebo ne? A ta javovská Exception je tak generická, že vím přesně akorát to, že to zvládnu zalogovat. Do teď jsem měl pocit, že se bavíme o primárně produkci. Pokud mám nějakou situaci pokrytou testy, tak mi chytí i zapomenutý test na návratovou hodnotu. Ale ty zapomenuté situace už z principu těmi testy moc pokryté nebývají.

V C++ je to úplně na stejno, protože v praxi nikdo nehází nic, co by nebylo odvozené od std::exception. Inty a podobné věci se házejí akorát v (mizerných) ukázkových prográmcích.

Já o schopnostech GC pochybnosti mám. Protože to, co je opravdu třeba uklidit rychle je právě "nepaměťový" binec. Soubory, sockety a další takové věci. Když po chycení chyby zůstane (potenciálně dost dlouho) viset zamčený soubor nebo otevřený socket, tak to není úplně OK.
Citace
Výjimečné chyby ošetříš o pár pater výš a vhledem k jednotnému rozhraní v tom nevidím žádný problém. Granularitu lze kdykoli zjemnit odchycením výjimky a uložením do stacku nové výjimky na vyšším levelu. Tím si zdroj výjimky krásně vytrasuješ.
Jednotné rozhraní čeho? Neznámou Exception můžu akorát tak převést na neznámý řetězec, ten zalogovat a pak zdechnout. To už můžu zavolat při jakékoliv chybě rovnou abort. V tom crashdumpu ten callstack dostanu taky.

To "ošetříš" znamená kód, který se díky tomu "výjímečné" moc často nespouští. Je opravdu dobře otestovaný? Netestují se náhodou jen běžné chyby?
Citace

Když upravíš jen kód nebo ošetření výjimek, tak tě na to testy hned upozorní. Toho bych se nebál.
Teoreticky jo. Ale v praxi jsou ty testy kapku míň spolehlivé. Testuje se to, co někoho napadne, nebo co už se jednou vymamlasilo. Na nečekané chyby testy nejsou.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Jiří Havel 14. 09. 2019, 23:28:44
Chtělo by to něco do syntaxe, kterou by se dalo jasně specifikovat jaké výjimky to může házet. Skutečnost v Javě, kdy musíš definovat co ti to vrátí za výsledek, ale nemusíš definovat co ti to háže za výjimky mi přijde takové nekonzistentní.
Snaha byla. V c++ se může u funkce specifikovat throws(...), v Javě jsou checked exceptions. C# měl ty checked exceptions taky, ale vyhodil je. V javě se od nich pokud vím taky upouští. A v c++ to byl taky fail.

Nevím o jazyce, kde by se to fungovalo rozumně. Všude se pokud vím přešlo na jednodušší nehází/hází cokoliv.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 14. 09. 2019, 23:57:21
Zásadní problém výjimek je IMO právě to, že jsou oddělené od výkonného kódu a nejsou vidět.
Při pohledu na cizí kód nevím, co může a nemůže házet.

+1

Chtělo by to něco do syntaxe, kterou by se dalo jasně specifikovat jaké výjimky to může házet. Skutečnost v Javě, kdy musíš definovat co ti to vrátí za výsledek, ale nemusíš definovat co ti to háže za výjimky mi přijde takové nekonzistentní.
Ono také záleží na tom, jaké výjimky mohou nastat. Force majeure (například “file not found” nebo “out of memory”) se nedá předpokládat (=odchytit při typové kontrole), kdežto takové “index out of bounds” není force majeure, protože to umí eliminovat závislostní typy. Čím méně výjimek je přípustných, tím snazší je explicitně je specifikovat. Otázka pak jen je, jestli má smysl se s nimi otravovat, když kombinace silného (závislostního) systému a maybe pro nepředvídatelné výjimečné situace vede k přehlednějšímu kódu.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: BoneFlute 15. 09. 2019, 01:27:04
Otázka pak jen je, jestli má smysl se s nimi otravovat, když kombinace silného (závislostního) systému a maybe pro nepředvídatelné výjimečné situace vede k přehlednějšímu kódu.

Tak výjimky by měly být přehlednější. Měli by být schopny hezky vyjádřit triviální a chybovou/výjimečnou situaci. Zda je tomu tak, to je už jiná otázka.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 15. 09. 2019, 03:14:30
Já o schopnostech GC pochybnosti mám. Protože to, co je opravdu třeba uklidit rychle je právě "nepaměťový" binec. Soubory, sockety a další takové věci. Když po chycení chyby zůstane (potenciálně dost dlouho) viset zamčený soubor nebo otevřený socket, tak to není úplně OK.

Soubory, sockety a další alokované prostředky neřeší GC, ale destruktory, které se aktivují ihned po zrušení deskriptoru na objekt. GC se aktivuje až když dochází volná paměť. Takhle to funguje alespoň ve slušně napsaných jazycích.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 15. 09. 2019, 03:21:43
Výjimečné chyby ošetříš o pár pater výš a vhledem k jednotnému rozhraní v tom nevidím žádný problém. Granularitu lze kdykoli zjemnit odchycením výjimky a uložením do stacku nové výjimky na vyšším levelu. Tím si zdroj výjimky krásně vytrasuješ.
Jednotné rozhraní čeho? Neznámou Exception můžu akorát tak převést na neznámý řetězec, ten zalogovat a pak zdechnout. To už můžu zavolat při jakékoliv chybě rovnou abort. V tom crashdumpu ten callstack dostanu taky.

Výjimky nejsou final, klidně si je můžeš podědit a rozšířit o další atributy dle libosti. Při ošetřování jdeš od specializovaných k obecným. Je to velmi jednoduché.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 15. 09. 2019, 03:36:25
Výjimečné chyby ošetříš o pár pater výš a vhledem k jednotnému rozhraní v tom nevidím žádný problém. Granularitu lze kdykoli zjemnit odchycením výjimky a uložením do stacku nové výjimky na vyšším levelu. Tím si zdroj výjimky krásně vytrasuješ.
To "ošetříš" znamená kód, který se díky tomu "výjímečné" moc často nespouští. Je opravdu dobře otestovaný? Netestují se náhodou jen běžné chyby?
Citace

Když upravíš jen kód nebo ošetření výjimek, tak tě na to testy hned upozorní. Toho bych se nebál.
Teoreticky jo. Ale v praxi jsou ty testy kapku míň spolehlivé. Testuje se to, co někoho napadne, nebo co už se jednou vymamlasilo. Na nečekané chyby testy nejsou.

Ze zadání píši testy, podle testů pak produkční kód. Do testů mockuji i chyby filesystému nebo třeba ztrátu spojení s databází. Je snad v něčem problém?

Nesmí se také zapomínat na zotavení z výjimek. Když ho uděláš v main loopu aplikace, tak ti nespadne, ale přejde do nějakého výchozího stavu. Je to taková poslední záchrana. Samozřejmě musíš vše řádně zalogovat, což obvykle není problém.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: ondrama 15. 09. 2019, 09:45:26
Výjimečné chyby ošetříš o pár pater výš a vhledem k jednotnému rozhraní v tom nevidím žádný problém. Granularitu lze kdykoli zjemnit odchycením výjimky a uložením do stacku nové výjimky na vyšším levelu. Tím si zdroj výjimky krásně vytrasuješ.
To "ošetříš" znamená kód, který se díky tomu "výjímečné" moc často nespouští. Je opravdu dobře otestovaný? Netestují se náhodou jen běžné chyby?
Citace

Když upravíš jen kód nebo ošetření výjimek, tak tě na to testy hned upozorní. Toho bych se nebál.
Teoreticky jo. Ale v praxi jsou ty testy kapku míň spolehlivé. Testuje se to, co někoho napadne, nebo co už se jednou vymamlasilo. Na nečekané chyby testy nejsou.

Ze zadání píši testy, podle testů pak produkční kód. Do testů mockuji i chyby filesystému nebo třeba ztrátu spojení s databází. Je snad v něčem problém?

Nesmí se také zapomínat na zotavení z výjimek. Když ho uděláš v main loopu aplikace, tak ti nespadne, ale přejde do nějakého výchozího stavu. Je to taková poslední záchrana. Samozřejmě musíš vše řádně zalogovat, což obvykle není problém.

Produkcni kod je co?
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Jiří Havel 15. 09. 2019, 10:40:25
Já o schopnostech GC pochybnosti mám. Protože to, co je opravdu třeba uklidit rychle je právě "nepaměťový" binec. Soubory, sockety a další takové věci. Když po chycení chyby zůstane (potenciálně dost dlouho) viset zamčený soubor nebo otevřený socket, tak to není úplně OK.

Soubory, sockety a další alokované prostředky neřeší GC, ale destruktory, které se aktivují ihned po zrušení deskriptoru na objekt. GC se aktivuje až když dochází volná paměť. Takhle to funguje alespoň ve slušně napsaných jazycích.
O kterém jazyce je teď řeč? Třeba Java AFAIK destruktory nemá. A soubory se v ní musí uklízet ručně, aby nezůstávaly viset než se GC probere.

Citace
Nesmí se také zapomínat na zotavení z výjimek. Když ho uděláš v main loopu aplikace, tak ti nespadne, ale přejde do nějakého výchozího stavu. Je to taková poslední záchrana. Samozřejmě musíš vše řádně zalogovat, což obvykle není problém.
No tak nějaký všežravý catch blok v main loopu je zrovna dost pochybný obrat. Ok, chytnu v něm nějakou nečekanou výjimku. Je pravděpodobně nečekaná, protože očekávanou bych chytl nějakým cíleným catchem. Nevím o ní nic, takže ji můžu akorát tak zalogovat. Co vím o stavu programu? Akorát to, že se mi nečekaně přerušil nějaký kus kódu před dokončením. Co vím o invariantech? Ta výjimka byla nečekaná, takže klidně mohla vyletět v momentě, kdy byly invarianty rozbité.
Jediný způsob, jak se v takovém případě dostat do známého stavu, je zahodit úplně všechno a začít odznova. To už můžu místo toho použít nějaký výrazně jednodušší watchdog proces.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 15. 09. 2019, 11:25:04
Nesmí se také zapomínat na zotavení z výjimek. Když ho uděláš v main loopu aplikace, tak ti nespadne, ale přejde do nějakého výchozího stavu. Je to taková poslední záchrana. Samozřejmě musíš vše řádně zalogovat, což obvykle není problém.
No tak nějaký všežravý catch blok v main loopu je zrovna dost pochybný obrat. Ok, chytnu v něm nějakou nečekanou výjimku. Je pravděpodobně nečekaná, protože očekávanou bych chytl nějakým cíleným catchem. Nevím o ní nic, takže ji můžu akorát tak zalogovat. Co vím o stavu programu? Akorát to, že se mi nečekaně přerušil nějaký kus kódu před dokončením. Co vím o invariantech? Ta výjimka byla nečekaná, takže klidně mohla vyletět v momentě, kdy byly invarianty rozbité.
Jediný způsob, jak se v takovém případě dostat do známého stavu, je zahodit úplně všechno a začít odznova. To už můžu místo toho použít nějaký výrazně jednodušší watchdog proces.

Mně se ten všežravý catch blok osvědčil. Nejspíš proto, že se do něj skoro nic nedostane, neboť používám vhodnou granularitu výjimek v jednotlivých vrstvách, kde se s tím ještě dá něco rozumného dělat, i kdyby to mělo být jen kaskádování, které mi je hezky vytrasuje.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 15. 09. 2019, 11:25:35
Já o schopnostech GC pochybnosti mám. Protože to, co je opravdu třeba uklidit rychle je právě "nepaměťový" binec. Soubory, sockety a další takové věci. Když po chycení chyby zůstane (potenciálně dost dlouho) viset zamčený soubor nebo otevřený socket, tak to není úplně OK.

Soubory, sockety a další alokované prostředky neřeší GC, ale destruktory, které se aktivují ihned po zrušení deskriptoru na objekt. GC se aktivuje až když dochází volná paměť. Takhle to funguje alespoň ve slušně napsaných jazycích.
O kterém jazyce je teď řeč? Třeba Java AFAIK destruktory nemá. A soubory se v ní musí uklízet ručně, aby nezůstávaly viset než se GC probere.

Citace
Nesmí se také zapomínat na zotavení z výjimek. Když ho uděláš v main loopu aplikace, tak ti nespadne, ale přejde do nějakého výchozího stavu. Je to taková poslední záchrana. Samozřejmě musíš vše řádně zalogovat, což obvykle není problém.
No tak nějaký všežravý catch blok v main loopu je zrovna dost pochybný obrat. Ok, chytnu v něm nějakou nečekanou výjimku. Je pravděpodobně nečekaná, protože očekávanou bych chytl nějakým cíleným catchem. Nevím o ní nic, takže ji můžu akorát tak zalogovat. Co vím o stavu programu? Akorát to, že se mi nečekaně přerušil nějaký kus kódu před dokončením. Co vím o invariantech? Ta výjimka byla nečekaná, takže klidně mohla vyletět v momentě, kdy byly invarianty rozbité.
Jediný způsob, jak se v takovém případě dostat do známého stavu, je zahodit úplně všechno a začít odznova. To už můžu místo toho použít nějaký výrazně jednodušší watchdog proces.
Java má using jako C#, jen se jmenuje stupidně try, aby se hned nepoznalo, jak se opičí.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 15. 09. 2019, 11:28:04
Já o schopnostech GC pochybnosti mám. Protože to, co je opravdu třeba uklidit rychle je právě "nepaměťový" binec. Soubory, sockety a další takové věci. Když po chycení chyby zůstane (potenciálně dost dlouho) viset zamčený soubor nebo otevřený socket, tak to není úplně OK.

Soubory, sockety a další alokované prostředky neřeší GC, ale destruktory, které se aktivují ihned po zrušení deskriptoru na objekt. GC se aktivuje až když dochází volná paměť. Takhle to funguje alespoň ve slušně napsaných jazycích.
O kterém jazyce je teď řeč? Třeba Java AFAIK destruktory nemá. A soubory se v ní musí uklízet ručně, aby nezůstávaly viset než se GC probere.

Citace
Nesmí se také zapomínat na zotavení z výjimek. Když ho uděláš v main loopu aplikace, tak ti nespadne, ale přejde do nějakého výchozího stavu. Je to taková poslední záchrana. Samozřejmě musíš vše řádně zalogovat, což obvykle není problém.
No tak nějaký všežravý catch blok v main loopu je zrovna dost pochybný obrat. Ok, chytnu v něm nějakou nečekanou výjimku. Je pravděpodobně nečekaná, protože očekávanou bych chytl nějakým cíleným catchem. Nevím o ní nic, takže ji můžu akorát tak zalogovat. Co vím o stavu programu? Akorát to, že se mi nečekaně přerušil nějaký kus kódu před dokončením. Co vím o invariantech? Ta výjimka byla nečekaná, takže klidně mohla vyletět v momentě, kdy byly invarianty rozbité.
Jediný způsob, jak se v takovém případě dostat do známého stavu, je zahodit úplně všechno a začít odznova. To už můžu místo toho použít nějaký výrazně jednodušší watchdog proces.
Všežravý catch blok je code smell, ale aspoň může říct, že program nepadá.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Ondra Satai Nekola 15. 09. 2019, 11:41:20
Já o schopnostech GC pochybnosti mám. Protože to, co je opravdu třeba uklidit rychle je právě "nepaměťový" binec. Soubory, sockety a další takové věci. Když po chycení chyby zůstane (potenciálně dost dlouho) viset zamčený soubor nebo otevřený socket, tak to není úplně OK.

Soubory, sockety a další alokované prostředky neřeší GC, ale destruktory, které se aktivují ihned po zrušení deskriptoru na objekt. GC se aktivuje až když dochází volná paměť. Takhle to funguje alespoň ve slušně napsaných jazycích.
O kterém jazyce je teď řeč? Třeba Java AFAIK destruktory nemá. A soubory se v ní musí uklízet ručně, aby nezůstávaly viset než se GC probere.

Citace
Nesmí se také zapomínat na zotavení z výjimek. Když ho uděláš v main loopu aplikace, tak ti nespadne, ale přejde do nějakého výchozího stavu. Je to taková poslední záchrana. Samozřejmě musíš vše řádně zalogovat, což obvykle není problém.
No tak nějaký všežravý catch blok v main loopu je zrovna dost pochybný obrat. Ok, chytnu v něm nějakou nečekanou výjimku. Je pravděpodobně nečekaná, protože očekávanou bych chytl nějakým cíleným catchem. Nevím o ní nic, takže ji můžu akorát tak zalogovat. Co vím o stavu programu? Akorát to, že se mi nečekaně přerušil nějaký kus kódu před dokončením. Co vím o invariantech? Ta výjimka byla nečekaná, takže klidně mohla vyletět v momentě, kdy byly invarianty rozbité.
Jediný způsob, jak se v takovém případě dostat do známého stavu, je zahodit úplně všechno a začít odznova. To už můžu místo toho použít nějaký výrazně jednodušší watchdog proces.
Java má using jako C#, jen se jmenuje stupidně try, aby se hned nepoznalo, jak se opičí.

Ale, ale...
Hlavně nikdo nechce přidávat vyhrazená slova, když to nic nepřinese.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: BoneFlute 15. 09. 2019, 13:46:51
Mně se ten všežravý catch blok osvědčil. Nejspíš proto, že se do něj skoro nic nedostane,...
Ta věta nedává smysl. Tak osvědčil se ti ten všežravý catch, nebo ho nevyužíváš? Nemůžeš oboje najednou.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 15. 09. 2019, 14:07:51
Mně se ten všežravý catch blok osvědčil. Nejspíš proto, že se do něj skoro nic nedostane,...
Ta věta nedává smysl. Tak osvědčil se ti ten všežravý catch, nebo ho nevyužíváš? Nemůžeš oboje najednou.

Dělám vše pro to, aby se mi v něm nic neobjevilo, ale je tam. Mohu oboje najednou. Nemohu však za to, že ti to nedává smysl.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: BoneFlute 15. 09. 2019, 14:50:32
Mně se ten všežravý catch blok osvědčil. Nejspíš proto, že se do něj skoro nic nedostane,...
Ta věta nedává smysl. Tak osvědčil se ti ten všežravý catch, nebo ho nevyužíváš? Nemůžeš oboje najednou.

Dělám vše pro to, aby se mi v něm nic neobjevilo, ale je tam. Mohu oboje najednou. Nemohu však za to, že ti to nedává smysl.

Naopak. Teď to teprve dává všechno smysl. Pokud uvažuješ v duchu té věty, tak je to jasné. Pak je možné úplně cokoliv.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Jiří Havel 15. 09. 2019, 15:24:13
Mně se ten všežravý catch blok osvědčil. Nejspíš proto, že se do něj skoro nic nedostane,...
Ta věta nedává smysl. Tak osvědčil se ti ten všežravý catch, nebo ho nevyužíváš? Nemůžeš oboje najednou.

Dělám vše pro to, aby se mi v něm nic neobjevilo, ale je tam. Mohu oboje najednou. Nemohu však za to, že ti to nedává smysl.

Naopak. Teď to teprve dává všechno smysl. Pokud uvažuješ v duchu té věty, tak je to jasné. Pak je možné úplně cokoliv.
Taky mě to zarazilo. Nevím, jak se může osvědčit kód, co se skoro nedostane k lizu. Taky je možné, že zatím jenom nevybouchl. ;) Podle mých zkušeností je kód, do kterého se skoro nic nedostane, časovaná bomba plná bugů, které nikoho ani nenapadlo testovat.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 15. 09. 2019, 15:28:14
Taky mě to zarazilo. Nevím, jak se může osvědčit kód, co se skoro nedostane k lizu. Taky je možné, že zatím jenom nevybouchl. ;) Podle mých zkušeností je kód, do kterého se skoro nic nedostane, časovaná bomba plná bugů, které nikoho ani nenapadlo testovat.

Bez obav, testy se do něj v pohodě dostanou.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: mikrom 16. 09. 2019, 22:54:12
Vecko sa da otestovat.
Zriedkave chyby sa daju otestovat aspon v debuggeri, ze sa zmodifikuju premenne tak, aby dana situacia nastala.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Cikáda 16. 09. 2019, 23:27:40
Vecko sa da otestovat.
Zriedkave chyby sa daju otestovat aspon v debuggeri, ze sa zmodifikuju premenne tak, aby dana situacia nastala.

Problém je, že člověka tak nějak všechno nenapadne.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Jiří Havel 17. 09. 2019, 14:42:19
Vecko sa da otestovat.
Třeba souběh (race condition) se otestovat moc nedá.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Ondra Satai Nekola 17. 09. 2019, 14:55:26
Vecko sa da otestovat.
Třeba souběh (race condition) se otestovat moc nedá.

Nebo spousta situací v distribuovaných systémech
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 17. 09. 2019, 16:49:20
Vecko sa da otestovat.
“Vécko” určitě, Java a PHP k němu pasují nejlépe  :D
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 17. 09. 2019, 16:50:32
Vecko sa da otestovat.
Třeba souběh (race condition) se otestovat moc nedá.
Jednotkově ne, ale existují metody pro ověření při překladu i běhu, třeba Go je pro své gorutiny používá.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: BoneFlute 17. 09. 2019, 19:02:44
A proto jakékoliv ručně psané testy jsou z principu špatně. (Tím nechci říct, že by se neměli psát.) Bylo by mnohem lepší, když budou chyby hledat ti nejzkušenější vývojáři a zadrátuje se to do stroje.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: listoper 17. 09. 2019, 19:21:55
A proto jakékoliv ručně psané testy jsou z principu špatně. (Tím nechci říct, že by se neměli psát.) Bylo by mnohem lepší, když budou chyby hledat ti nejzkušenější vývojáři a zadrátuje se to do stroje.

Kdo bude ty chyby vyrabet, aby meli ti nejzkusenejsi co hledat?
Budou jenom hledat? Nebo budou mit cas i na neco jineho?
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Kit 17. 09. 2019, 19:22:10
A proto jakékoliv ručně psané testy jsou z principu špatně. (Tím nechci říct, že by se neměli psát.) Bylo by mnohem lepší, když budou chyby hledat ti nejzkušenější vývojáři a zadrátuje se to do stroje.

Jak bys ty testy chtěl psát jinak než ručně? Jistě, boilerplates na testy si necháš vygenerovat, ale asserty musíš dopsat ručně podle zadání úlohy. Nic jiného v tu chvíli nemáš.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: BoneFlute 17. 09. 2019, 20:52:20
A proto jakékoliv ručně psané testy jsou z principu špatně. (Tím nechci říct, že by se neměli psát.) Bylo by mnohem lepší, když budou chyby hledat ti nejzkušenější vývojáři a zadrátuje se to do stroje.

Kdo bude ty chyby vyrabet, aby meli ti nejzkusenejsi co hledat?
Budou jenom hledat? Nebo budou mit cas i na neco jineho?

Asi jsem se špatně vyjádřil.

Narážel jsem na poznámku, že go-lang dokáže detekovat race condition. A když to dokáže překladač, který napsal zkušený vývojář zaměřující se na problém, tak je to IMHO vždycky lepší, než když si ty chyby a testy na to bude hledat/psát každej koncák sám. Teoreticky by samozřejmě koncák měl mít větší předpoklady pro napsání lepšího testu. Ale v praxi to podle všeho nefunguje.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 17. 09. 2019, 20:55:51
A proto jakékoliv ručně psané testy jsou z principu špatně. (Tím nechci říct, že by se neměli psát.) Bylo by mnohem lepší, když budou chyby hledat ti nejzkušenější vývojáři a zadrátuje se to do stroje.
Také existuje formální verifikace (při překladu), kdy se ověřují různé invarianty pomocí symbolických dokazovačů (theorem provers), třeba jedno rozšíření Haskellu ověřuje platnost podmínek ohledně (endo)funktorů, které běžný překladač prostě ignoruje. Problém s takovouto verifikací je, že naučit se ji používat je samo o sobě náročné (nemluvě o pochopení implementace). V této inherentní složitosti je podobná závislostním typům, u kterých si také málokdo z fleku představí, proč jsou o řád lepší než běžná typová kontrola.
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: BoneFlute 17. 09. 2019, 23:17:08
A proto jakékoliv ručně psané testy jsou z principu špatně. (Tím nechci říct, že by se neměli psát.) Bylo by mnohem lepší, když budou chyby hledat ti nejzkušenější vývojáři a zadrátuje se to do stroje.
třeba jedno rozšíření Haskellu ověřuje platnost podmínek ohledně (endo)funktorů, které běžný překladač prostě ignoruje.

Měl by si hint?
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 17. 09. 2019, 23:33:55
A proto jakékoliv ručně psané testy jsou z principu špatně. (Tím nechci říct, že by se neměli psát.) Bylo by mnohem lepší, když budou chyby hledat ti nejzkušenější vývojáři a zadrátuje se to do stroje.
třeba jedno rozšíření Haskellu ověřuje platnost podmínek ohledně (endo)funktorů, které běžný překladač prostě ignoruje.
Měl by si hint?
http://www.cse.chalmers.se/~peterd/papers/TestingModelChecking.pdf
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: Idris 17. 09. 2019, 23:56:08
A proto jakékoliv ručně psané testy jsou z principu špatně. (Tím nechci říct, že by se neměli psát.) Bylo by mnohem lepší, když budou chyby hledat ti nejzkušenější vývojáři a zadrátuje se to do stroje.
třeba jedno rozšíření Haskellu ověřuje platnost podmínek ohledně (endo)funktorů, které běžný překladač prostě ignoruje.
Měl by si hint?
Tohle je stravitelnější: http://kindsoftware.com/documents/reports/Green10.pdf
Název: Re:Hledám knihy: Myslíme v C++ a v Javě
Přispěvatel: BoneFlute 18. 09. 2019, 15:18:54
Perfekt, dík.