Fórum Root.cz
Práce => Studium a uplatnění => Téma založeno: 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.
-
nejsou tady na rootu v knihovnicce.
u programovani se anglictina fakt hodi, zacni se ji ucit.
-
Jak chces myslet v (jakykoliv programovaci jazyk) kdyz nedokazes precist anglictinu?
-
Jak chces myslet v (jakykoliv programovaci jazyk) kdyz nedokazes precist anglictinu?
Myslet se dá i česky. Dokonce se dnes dá česky i psát.
-
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).
-
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.
-
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.
-
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í :)
-
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.
-
nezvládnou napsat ani jednoduchý vzoreček do Excelu.
a ty se divis? kdyz nejakej deb*l vymyslel, ze budou nazvy funkci cesky.
-
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.
-
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ě.
-
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)
-
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.
-
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.
-
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ť.
-
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
-
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.
-
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!
-
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ěť).
-
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.
-
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.
-
jen pokud nenajdu odpověď v offline dokumentaci
Offline dokumentace? To existuje?
-
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
banik pyco
tryda Ostrava{
rynek(){
Konzola.pravit("Toz vitaj") pyco
}
}
fajront pyco
-
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.
-
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ší
-
Nežerete maso, nepoznáte vtip!
-
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...
$ zeal
QXcbConnection: Could not connect to display
-
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.
-
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...
-
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.
-
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.
-
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í...
-
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.
-
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.
-
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.
-
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.
-
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
-
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í.
-
Len si neviem vybrať knihu. Poradte najlepšiu. :D
cokoliv novějšího.
-
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. :)
-
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.
-
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.
-
2 mukel: poslal jsem ti PM
-
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
-
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.
-
https://herbsutter.com/
https://github.com/isocpp/CppCoreGuidelines
https://isocpp.org/
-
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á?
-
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.
-
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.
-
Na C++ nic komplikovaného nevidím. Problém bude spíše v těch knihách.
-
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. :)
-
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.
-
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...
-
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ě?
-
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.
-
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.
-
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.
-
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”.
-
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??
-
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.
-
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ů”).
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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)
-
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++.
-
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í.
-
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.
-
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?
-
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ě.
-
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í.
-
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.
-
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.
-
Výjimky jsou především výrazně dražší.
Principielně?
-
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...
-
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.
-
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?
-
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.
-
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.
-
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.
-
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.
-
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í.
-
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.
-
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.
-
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?
-
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?
-
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.
-
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ří.
-
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?
-
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.
-
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?
-
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.
-
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í.
-
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.
-
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 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.
-
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ě?
-
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.
-
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.
-
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.
-
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á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...
-
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á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.
-
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áš?
-
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í.
-
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.
-
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.
-
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é.
-
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?
-
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.
-
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.
-
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ě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?
-
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.
-
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.
-
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.
-
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.
-
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.
-
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ů.
-
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š?
-
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.
-
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.
-
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.
-
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í.
-
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.
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?
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.
-
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.
-
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.
-
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.
-
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.
-
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é.
-
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?
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.
-
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?
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?
-
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.
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.
-
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.
-
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.
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čí.
-
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.
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á.
-
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.
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
Vecko sa da otestovat.
Zriedkave chyby sa daju otestovat aspon v debuggeri, ze sa zmodifikuju premenne tak, aby dana situacia nastala.
-
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.
-
Vecko sa da otestovat.
Třeba souběh (race condition) se otestovat moc nedá.
-
Vecko sa da otestovat.
Třeba souběh (race condition) se otestovat moc nedá.
Nebo spousta situací v distribuovaných systémech
-
Vecko sa da otestovat.
“Vécko” určitě, Java a PHP k němu pasují nejlépe :D
-
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á.
-
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.
-
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?
-
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áš.
-
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.
-
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.
-
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?
-
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
-
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
-
Perfekt, dík.