Vlákno názorů k článku Go: minimalistický a překvapivě výkonný programovací jazyk od fero - Moc se mi ten jazyk nelibi, je to...

ale tak jestli to umoznuje knihovna nebo samotný jazyk je podstatný rozdil. většinou i ve slozitosti zapisu.

Pythoní with y as x: i Javí try (x = y) {} jsou rozhodně součástí jazyka. Knihovny to jen dál vylepšují.

Navíc, standardní knihovna je podstatnou součástí jazyka.

Jestli chapu spravne vyuziti defer v Go, je to v podstate nahrada try-finally (coz ma treba Python snad odjakziva), protoze, ted pozor, Go vyjimky nema, protoze nejsou potreba. Ale jasne, zase soudruzi v Go vynalezli kolo. Context manager (with) je kvalitativne o uroven vys.

Defer není úplně to samé jako jednoduché finally, i když je mu hodně blízko.

Defer funkce se totiž dá zaregistrovat až ve chvíli, kdy je co uklízet. Čímž řeší problém alokace více zdrojů s kontrolou selhání a úklidem v každém kroku. Finally si naopak musí samo zjistit co uklidit a co se už nezvládlo vytvořit.

Myslím si, že právě proto jsou with a try-with-resources tomu defer sémanticky nejblíž. Všechno je to syntaktický cukr, který programátorovi umožňuje po sobě uklidit a přitom neřešit jak a kdy blok/funkce skončí.

Jasně, ale try-finally se dá přece vnořovat, ne? Není to kdovíjak krásné, ale funguje:

f1 = open()
try {
f2 = open()
try {
...
}
finally {
f2.close()
}
}
finally {
f1.close()
}

To si neumim moc predstavit. Funkce vrati chybu a hodnotu, Ty ji neresis a v pohode si pracujes s tou hodnotou? To se treba v Rustu da delat taky a lip - treba pomoci unwrap_or().

@unicode

Ode mne mínus nemáš, sorry. Nevím jak je to v Rustu, takže to nekomentuju. Ptám se proto, protože nedávno jsem řešil aplikaci bez vyjímek a není skutečně nic lepšího než vracet přes zanoření šesti funkcí nejaký objekt (či něco) s errory, předávat ho mezi všemi třídami či funkcemi a po každém každičkém volání funkce kontrolovat jestli neskončila errorem, případně jakým, to se ani nebavím o externích knihovnách a jejich takových objektech. Ostatně takto je napsaná půlka všemi milovaného Wordpresu. To je můj pohled. Pletu se? Tak se rád přiučím - proto se ptám.

Já dělám hlavně v C/C++, js (node), a trochu se zajímám o rust. Vyhýbám se PHP a Javě. Bez pohledu na konkrétní kód je podle mě těžké se bavit o tom, jaký přístup je lepší nebo co by se dalo zlepšit. Použití výjimek záleží i na tom, ve kterém jazyce člověk dělá. Např. v C++ hodně záleží na projektu i na tom, které knihovny ten projekt používá.

Osobně si myslím, že exceptions nejsou silver bullet a člověk, který je chce používat úplně na všechno je jak to dítě s tím kladivem co vidí všude jen hřebíky :)

Jenomže výjimkou jsou silver bullets. Je řada stavů, které bez výjimek prostě rozumně neošetříte. Proto výjimky existují už na úrovni procesoru a strojového kódu, kde se jim říká přerušení.

Jazyky na hraní, jako je Go, to nikdy nezjistí. Ale jazyky, které mají zajistit nějakou spolehlivost se bez výjimek neobejdou.

Zdrojem chyb může být miliarda věcí od hardware, operačního systému, momentálních potíží v alokaci zdrojů, různých existujících/ne­existujících práv kdekoli - a miliarda dalších věcí. I při otevírání souboru může docházet pamět, docházet místo na zásobníku, dojít k hardwarové chybě disku, mít problémy s právy, atd.

Za 30 let programátorské praxe jsem ještě nikdy neviděl dobře ošetřený kód bez výjimek ani při takové kravině, jako je otevírání souboru. Kód, který by skutečně kvalitně ošetřoval všechny možnosti. Nehledě k tomu, že různé chyby by se měly ošetřovat často na různých místech - ne vše může rozumně ošestřit ten, kdo volá fopen().

Většinou osoby zastávající nepoužívání výjimek končí tak, že většina lidí prostě chyby ignoruje. Počítá s tím, že nenastanou. Nebo je ošetřují jen někde. K nahlédnutí v tisících open source zdrojových kódech.

Vzpomínám si na to, jak programovací jazyk Ada urychleně přidával do nové normy výjimky. Zjistilo se, že ty sw prostě padají při řadě situací, a programátor bez výjimek s tím nic neudělá. Program při řadě chyb mohl jen udělat terminate(), a poslat do šrotu pár miliónů či miliard dolarů v družici kdesi mimo zemi. Najednou byly všechny námitky proti výjimkám bezpředmětné. A najednou šly ošetřit všechny stavy, a něco udělat.

"Za 30 let programátorské praxe jsem ještě nikdy neviděl dobře ošetřený kód bez výjimek"

V tom případě to musí být pravda!

Zase další, kdo neumí číst a chápat český psaný text! Ti analfabeti se tu snad rozmnožují!

@ Michal Mühlpachr

Asi protože neustále někdo tvrdí, že ti i takto ... a pak tím ještě dokládá že takového kódu je hodně, takže to asi nebude tak špatný přístup.

@unicode

Souhlasím že bez znalosti konkrétního kódu je těžko se o tom bavit. Dodám, že záleží i na koncepci jazyka. Ovšem já nejsem ten kdo tu začal tvrdit, že vyjímky jsou špatně by default. A taky si nevzpomínám že by někdo tvrdil že jsou vyjímky silver bullet. Proč to musí být v IT pořád odezdi ke zdi: Když vyjímky, tak všude jinak jsou na prd a když ne, tak nikdy nikde ... ?

Pokud bych měl ale opravdu vznést nějaký obecný soud, tak jakmile se začne řešit aplikace kde je struktura používání tříd a volání funkcí hodně složitá do hloubky co se týče volání (např. komponenta která používá komponentu která používá několik příd které obsluhují několik tříd - ideálně ještě různých vendorů), tak tam začínají být vyjímky velkou výhodou. Ono totiž to tzv. probublání ušetří tunu kódu a je naprosto hned jasné co se tam děje.
AFAIK u každého manuálu k vyjímkám a u každého slušnějšího tutoriálu je napsané, že vyjímky neslouží křízení toku programu a nejsou náhradou za větvění.
Pokud je problém v tom, že je špatně používá část programátorů, tak asi není správný postup řešit to odstraněním vyjímek by default, nota bene ne proto, že nejsou silver bullet. Ostatně co je ... Když se někdo snaží, zprznit jde všechno ....

Moc nechápu ty co to brali doslova a nedokázali interpretovat toho smajlíka. Za mě je to např. tak, že v aplikaci (doména C++) mi výjimky nějak extrémně nevadí, ale ve sdílených knihovnách už ano. Druhá věc je, že místo toho, aby tady lidi psali argumenty o které se můžou opřít, tak tady opakujou dávno vyvrácené mýty a zrůrazňujou jak dlouho už programujou :)

Abych to rekapituloval. Celé to bylo o tom, že bez výjimek to dnes rozhodně jde a nové programovací jazyky je výslovně nepotřebují (viz Rust, Go), pokud jsou schopné poskytnout jiné prostředky pro error handling. Druhá věc je ta, že současný stav výjimek v C++ rozhodně není ideální (tak jak tu někteří tvrdí) a je to "the least portable feature". Např. embedded, emscripten, C interfaces / language bindings - zapomeňte na exceptions.

Jak fungují exceptions

https://www.youtube.com/watch?v=XpRL7exdFL8

A např. jeden z nových návrhů, který chce řešit současnout nevyhovující situaci v C++ nazvaný "Zero-overhead deterministic exceptions: Throwing values".
- http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf

Nemám moc čas na žabomyší války, takže tímto bych to ukončil :)

@unicode

No proč ne, jenom generalizace není dobrá v přesných tématech ;-)

Znám hlavně C++, Javu a Python používám velmi málo. V C++ jsou výjimky podle mě opravdu na naprosto výjimečné stavy, protože na první pohled nevím, jestli funkce něco takového vrací a jestli je to relativně normální stav. Dělat něco takového jakože výjimku odchytnu přes šest zanořených funkcí je podle mě spíš prasárna, ulehčí to práci, ale někdo může použít funkci na třetí úrovni zanoření jinde a zapomenout na to.
V ideálním světě aspoň existuje dokumentace ohledně toho jaké výjimky funkce vrací, ale stejně ji málokdo čte.

@pp

No ony totiž ty vyjímku jsou opravdu na vyjímečné stavy - je to takový v podstatě chytatelný exit. Paradigma je takové, že je to jako nouzová brzda, kterou ovšem můžeš vědomě odchytit a odbrzdit v momentě, kdy jsi schopný situaci zase dostat do normálu, resp. standartního běhu. Toho docílíš tak že nevěštíš co úrovně pod nebo nad mají či nemají dělat, co možná kdyby někdo, ale buď tě stav vyjímka zajímá a zpracuješ ho nebo to necháš letět (probublat) dál a pak třeba někdo kdo používá tvou knihovnu která nechá tuto vyjímku z jiné knihovny letět se rozhodne jestli ho zajímá nebo ji nechá letět dál, resp. výše ....

Nevím jak v C++, ale například v tom zlém a nanicovatém světě PHP je už v podstatě standard do anotací uvádět všechno co ta funkce může hodit, minimálně deklarace jména. Taky existuje určitý standart jak vyjímku pojmenovávat - asi nebudeš muset moc hledat v dokumentaci když v anotaci je throws InvalidArgumen­tException nebo throws ConnectionFai­lureException - řekl bych že to není nic nepředvídalného ani hrozného .... Třeba ve Wordpresu se ti vrátí "něco" nebo objekt Error - tam je fak super chceckovat jesti tam není nějaký který tě zajímá :-O

Heh, to jsou kecy.

Na tom ze: "lidi začali používat výjimky pro ne úplně výjimečné stavy" je spatneho konktretne co?

Co je to "ne úplně výjimečné stavy"?

Normalni lidi kolem me pisou program zkratka tak, ze implementuji algoritmus korektniho prubehu. a vyjimkama resi vsechny deviace od tohoto prubehu. Vcetne nexistujiciho souboru, ci spatneho loginu do DB.
Korektni prubeh je v try, zpracovani chyb v catch blocich. Netusim, co na tom ma byt masochistickeho.

A co se tyce blaboleni o Resut<> ci Optional<>, v cem je presne lepsi kontrola existence hodnoty v Optional<> lepsi, nez prosta C like kontrola chyboveho stavu hned po volani funkce?

A "Pokud se bavíme o nějakém zjednodušení control-flow při výskytu chyby" - tak zde prosim doporucuju zkratka implementovat vyjimky.

Tvoji reakci bych popsal asi takto:

When you have a hammer, you want everything to look like a nail.

A co se tyce blaboleni o Resut<> ci Optional<>, v cem je presne lepsi kontrola existence hodnoty v Optional<> lepsi?

Vždyť to je jen syntax. C/C++ nemá elegantní návrat dvou hodnot, tak se to řeší takto. Jazyk který to má to může řešit klidně i jinak.

Výjimky jsou výjimky ze standardního průběhu programu - nikoli pro výjimečné situace. Tedy člověk implementuje průběh, který očekává jako ideální, a ostatní ošetří pomocí výjimek. A zbytek - včetně těch neotevřených souborů, či cokoli jiného. Neuvěřitelně to zpřehledňuje program, pokud se to dělá dobře, a činí ho tisíckrát srozumitelnějším a tedy udržovatelnějším.

Dobře implementované výjimky navíc zrychlují program. Když se nepoužívají výjimky: Ony ty miliardy ifů ve standardní cestě po volání každého podprogramu také nejsou rychlostně zadarmo. Kromě toho je rozdíl, když funkce musí vracet 2 hodnoty namísto jedné, protože do jedné si strčí chybu - už jsou to další strojové instrukce navíc = další zpomalení.

Programovací jazyk bez výjimek je něco jako špatný vtip.

Poprosil bych studii o tom jak výjimky zrychlují program. Tento mýtus jsem už slyšel, ale nikdy ho nikdo žádným materiálem nebyl schopný podpořit.

Jak výjimky urychlují program jsem napsal ve svém příspěvku. Pokud neumíš číst, přečti si jej znovu.

Tady je relevantní video o exception cost v C++:

https://www.youtube.com/watch?v=XVofgKH-uu4&feature=youtu.be&t=1h2m24s

Pokud má někdo něco co by ukazovalo opak, tak se rád podívám.

A nechceš mi dát jen jeden mínus místo těch 5? Né že by mi to nějak vadilo, ale je to celkem nefér, že privilegovaní jedinci tu mají 5 hlasů a všichni ostatní 1 :)

Zdá se, že si nepochopil o čem je ošetřování chybových stavů, a to včetně výjimek. Výjimky jsou o tom, že standardní cesta programu je rychlá, ošetřování výjimečného stavu je pomalé.

Dělat benchmarky rychlosti ošetřování chyb je skvělé, ale mám pro tebe jednu radu: Nejrychlejší ošetřování chyb je vůbec je neošetřovat - přesně tam míříš.

Lidi většinou zajímá, jak rychlý bude program, když nenastane chyba a problém. Když nastane chyba a problém (třeba výjimka), pak daleko zajímavější než rychlost je kvalita ošetření chyby - a tam výjimky excelují. Často se ta chyba dokonce někam loguje či otevírá dialogové okno se zprávou - a to už je rychlost úplně vepsí. Ale asi je to podle tebe chyba.

Vůbec neošetřovat chyby, tak tomu říkám 30 let praxe :)

Pro unicode: Jestli nechápete psaný text, tak to je váš problém a váš handicap - ne někoho jiného.

"Když nastane chyba a problém (třeba výjimka)"

A v tomhle je jádro sporu. Někteří diskutující hovoří o výjimce jako o chybě nebo problému. To bude váš případ a to bude i můj případ. Jenže pak jsou tu lidé, kteří výjimky považují za zcela běžný nástroj a používají ho i na věci, které nemají nic společného s chybou nebo problémem. Jejich programy jsou prolezlé výjimkami, protože oni nikdy netestují, zda soubor existuje, zda text je číslo apod. Oni to prostě ZKUSÍ a jedou dál. Jejich program neobsahuje kód "pokud existuje starší soubor, tak ho smaž". Jejich program obsahuje kód "smaž starší soubor a ignoruj výjimku FileNotFound".

Zde si vždy vzpomenu na jeden extrém, kde autor prostě procházel pole stylem "for(i = 0; true; i++)". Smyčku opouštěl tím, že to měl celé v TRY bloku a odchytával OutOfBounds exception. Je fakt, že pole má jen omezenou velikost, chyba nebo problém? Není to třebas samozřejmost? A co čtení souboru? Viděl jste, kolik lidí tam místo "while not eof" má prostě natvrdo čtení a chytá si výjimku "read beyond end of file"? Je snad skutečnost, že soubor má omezenou délku, chyba nebo problém? Nebo když testují, zda existuje záznam v tabulce, tak místo COUNT(*) tam dají prostě SELECT 1 INTO a odchytávají výjimku NO_DATA_FOUND. Některé zvrácenosti se už dostaly i do tutoriálů. Například že kontrola, zda řetězec obsahuje číslo, se provádí tak, že se v TRY prostě zkusí přetypovat.

PS: Pro chyby a problémy Go nástroj má. Viz Defer, Panic a Recover. Používá to právě na věci jako je čtení mimo rozsah pole. Můžete to použít také. Není to tak silné a pohodlné jako výjimky, ale možnost to je.

@Karel

No jistě. Není nic lepšího než prohlásit celý problém kdy a co je chyba a jak a čím na to má aplikace reagovat, na "Párkrát jsem viděl i ... ". #thumbup

V jazyce s levnými výjimkami ano. Python to tak má a vyskočit z několika úrovní zanoření výjimkou StopIteration je čisté a levné. Psát spoustu kódu na to samé s předáváním hodnoty by ten kód hodně znepřehlednilo.

Třeba v C++ už to zas tak levný a čistý přístup není.

Rozdíl je v tom, jestli o takové situaci přemýšlejí jako o něčem, co může nastat. Vyhodit výjimku je jedna věc. Druhá věc je napsat veškerý nadřazený kód až po místo chycení tak, že s ní počítá. Dosáhnout aspoň základní "exception safety" (jak se to překládá?) není až taková sranda.
A vůbec tomu nepomáhá, že v kódu obvykle není poznat odkud to může a nemůže lítat. Výjimky (alespoň v obvyklé podobě) jsou neviditelné při běžném čtení. Musím se podívat na jednotlivé funkce abych věděl, jestli náhodou nehází. Ify jsou sice opruz, ale aspoň je hned vidět, kde to může selhat. A jak o tom při psaní autor uvažoval.
O výjimkách se říká, že se nedají ignorovat. Není to pravda. Mezi místy odkud vyletí a kde ji někdo chytí je spousta příležitostí pro její ignorování. Nebo spíš pro ignorování možnosti, že výjimečně může něco stát.

V tomhle se mi moc líbí nový návrh výjimek v C++. Pokud je nechytám, tak každý házející výraz musím označit pomocí "try". I při zběžném čtení bude vidět, že to může vyletět a že se to bude propagovat výš. Už se dá trochu líp přemýšlet o tom, jestli mi náhodou nějaká data nemůžou zůstat v nekonzistentním stavu.

Alokace paměti tímhle způsobem takřka neselhává. Když dochází paměť, tak se dějou zajímavější věci. Na Windowsech se program obvykle uswapuje k smrti. Začne swapovat tak divoce, že vlastně prakticky zamrzne. Na Linuxu se to liší podle nastavení. Asi nejlepší je, když swapper náhodně vybere obětní proces a ten sejme. S overcommitem je taky sranda. Malloc alokuje virtuální adresový prostor bez fyzické paměti. Fyzické stránky se přidělují až při prvním přístupu. Takže to pak vypadá tak, že žádná výjimka nevyletí a program segfaultuje při přístupu do úspěšně alokované paměti. Řeknu na rovinu, že v posledních +-10 letech jsem bad_alloc nepotkal. Ale je možné, že některé jazyky tohle chování OS maskují a chovají se kultivovaněji.

> Závěr - předpokládej, že to může vylítnout kdekoli a podle toho piš kód.
Pokud to opravdu může vylítnout kdekoliv, tak se s tím nedá nic dělat. Leda tak doufat, že se to nestane a po chycení výjimky všechno zahodit a začít znova. Pro psaní exception-safe kódu je kritické mít místa, kde to vylítnout nemůže. Klasický obrat je vytvoření nových dat kde to může lítat + výměna původních dat kde to vylítnout nesmí. Pokud to může vyletět opravdu kdekoliv, pak se konzistence zaručit skoro nedá.

@JSH

Ale dá. Jenom nesmíš kód rozdělovat na místa kde vyjímka nemůže nastat a kde může nasat, je potřeba ošetřit celý kód. Po chycení vyjímky můžeš dělat spustu věcí, minimálně log, zpráva uživateli nebo "úklid" (např. otevřená spojení ...)

Ten úklid se musí dělat nejen po chycení výjimky. Ten úklid musí proběhnout po celé trase, kudy ta výjimka letí. Něco může uklidit garbage collector, ale třeba mutexy neodemkne. Nabízí se otázka, jestli i ten úklid může házet a co v takovém případě udělat. Tady se vedou vášnivé diskuze a shoda moc nepanuje.

A o co mi šlo je, že pokud může výjimka vyletět odkudkoliv, tak se to může stát zrovna ve chvíli, kdy nejsou splněné nějaké invarianty. Pokud se chci z chyby nějak zotavit, tak musím při chycení vědět, v jakém stavu se může objekt, odkud to vyletělo, nacházet. A pro to už je potřeba nějaký commit nebo rollback, který házet nemůže. Bez toho se nemůžu přesunout mezi validními stavy, ale můžu zůstat v nějakém polorozbořeném stavu, který ani nemusí jít korektně uklidit.

Minimálně nějaký swap/přiřazení a destrukce musí jít provést bez házení, jinak se nedá spolehnout ani na ten úklid.

@JSH

Chápu. Myslím že na to není přesná odpověď, protože to záleží na tom jaké jsou požadavky - minimálně na to jak se má SW, případně i HW, chovat navenek ... Jediné co se dá říct s jistotou je že musíš v kódu tak nebo onak ošetřit stavy všechny a s použitím vyjímek ošetřuješ jednak všechny normální průběhy - což ale po nefukčnosti jednoho celku může dále znamenat normální chod programu (třeba přechod na default config) - a druhak všechny errorové stavy.
Podle mě stavů a požadavků v projektu neubude ani nepřibude, jenom s použitím vyjímek je metodika trochu jiná. Např. když jsem nedávno dělal kus SW kde jsem chtěl aby celý běh proběhl tak nebo tak, případně skončil errorem a vypsal všechny vyjímky které posbíral po cestě, tak jsem Exceptions vůbec nepoužil. Až při volání tohoto kusu, protože pak už bylo potřeba vyexitovat s hláškou, kódem, a daty, zapsat všechny errory na výstup i do logu - tedy použiji vyjímku.

To je pak ale špatně vyhozená vyjímka. Ten catch, případně final, je tam proto aby se ošetřily ty stavy a vyjímka je takový lepší exit+notice, který se dá nějaké úrovni přerušit volajícím - tedy lepší variabilita. Že má jazyk vyjímky neznamená že musí letět vždy ...

Pokud neumí číst, proč by to měl číst znovu? Stejně zase dojde...ehm...k výjimce CannotRead :)

Nechci vam do toho moc mluvit, ale ona ta obsluha vyjimky taky neco stoji;

call    __cxa_begin_catch
movq    %rax, -32(%rbp)
// tady je kod z catch {} bloku
call    __cxa_end_catch
jmp     .L7

A o tom celou dobu píši. Plho!

Že standardní cesta programu je rychlá jako raketa, pokud nenstane chyba. A že ošetřování výjimky je pomalé, velice pomalé. Což je přesně to co chceme - rychlý program, pokud vše jede jak má, a kvalitní ošetření chyba pokud se něco zadrhne.

Tady se nějak množí lidi, kteří neumí číst či co!

Výborně, takže se možná shodneme na tom, že za ošetření chyby jsme ochotni platit nějakým časem navíc, tedy v systémech, kde to jde (tudíž ne mission critical věci). Proč ale pořád píšete o nějakém otevírání souborů? To se skutečně dnes považuje za tak výjimečný stav, že se kvůli tomu musí tvořit objekt s výjimkou, používat RTTI, cold tables a kdoví co všechno jsem už zapomněl? Dokonce se vsadím, že mnoho lidí bude mít právě tu práci se soubory naprogramovanou blbě s použitím výjimek, než ti, co si poctivě projdou všemi možnými stavy.

U mission critical věcí sakra záleží daleko více na kvalitním ošetření chyb než na čemkoli jiném:

1) Představte si, že mission critical řízení atomové hlavice bude ošetřovat chyby rychle, ale zato nekvalitně. Takový unicode si vezme benchmark chyb, shlédne dvouhodinové video o rychlosti ošetřování chyb. Dále vezme nejrychlejší způsob, a ušetří při ošetření chyby tři nanosekundy. Následně zlikviduje Paříž chybným zaměřením cíle.

2) Nebo atomová elektrárna bude neočekávané stavy ošetřovat rychle - jen přitom vybouchne jako vedlejší efekt a zamoří půl Evropy jaderným spadem. Ale ušetřili jsme při ošetřování chyb jednu pikosekundu a to se vyplatí!

Mýty o tom, že se "výjimky mají používat jen pro výjimečné situace" tu šíří jiní - já tento mýtus a tuto hloupost nikdy nešířil. Tudíž ta otázka, zda je "otevírání souboru výjimečná situace" je směrem ke mně naprosto irelelvatní. Směřujete tuto otázku na špatnou osobu.

Výjimkou jsou pro jednoduše způsob, jak ošetřovat chyby a problémy - výjimečné i očekávatelné. Tudíž si neničím den ani mozek zcela zbytečnými filozofickými úvahami na téma co je a co není "výjimečná situace", protože tuto starost nechávám koňovi, který má větší hlavu. Já tyto věci k životu nepotřebuji.

Na to že máte "30 let praxe" tu argumentujete jako malé dítě :)

> Na to že máte "30 let praxe" tu argumentujete jako malé dítě :)

"Promiňte, to je zajímavé, ale já když jdu s dětmi do lesa tak vždycky tleskám a dělám takové kšššc, abych případné zmije zaplašil."
"Tak to děláte zbytečně."
"Ale já to tak dělám už asi 20 let a věřte, že se mi to plně osvědčilo."
"Ano... to je úplně zbytečné."

U mission critical věcí se výjímky prakticky nepoužívají (viz třeba JSF C++).

Problém je v tom, že jak ta výjimka probublává nahoru, tak cestou toho může dost rozvrtat, nechat objekty v nekonzistentním stavu a podobně. A když není jasné, odkud všude může výjímka vyletět, tak se prakticky nedá napsat kód který nějaká výjímka z nižší úrovně nerozvrtá.

> Tudíž si neničím den ani mozek zcela zbytečnými filozofickými úvahami na téma co je a co není "výjimečná situace", protože tuto starost nechávám koňovi, který má větší hlavu. Já tyto věci k životu nepotřebuji.

A podle čeho se teda rozhodujete, zda danou věc obsloužíte mechanismem výjimek nebo "normálně"? Hodíte si kostkou?

Mimochodem, jako člověka, který se v průmyslové automatizaci pohybuje celý život, mě často baví laické představy o architektuře řídících systémů jaderných zařízení. Ale prozradím vám, že výjimky v tom smyslu, jaké je známe třeba v Javě, se tam rozhodně nepoužívají. Výjimky v hardwarovém smyslu ano, ale už jsme to tu spolu řešili - to není totéž. Rozlišování výjimka-přerušení zde má svůj smysl a to, co máte na mysli, je spíše hardwarové přerušení.

On celý ten embedded svět je trochu jiný a spousta těch vychytávek, jako objekty, výjimky apod. se tam ukazuje jako zbytečná a spíš nebezpečná, takže se volí raději podmnožiny možností nástrojů.

* A co se tyce blaboleni o Resut<> ci Optional<>, v cem je presne lepsi kontrola existence hodnoty v Optional<> lepsi, nez prosta C like kontrola chyboveho stavu hned po volani funkce?

Predpokladam, ze se specificky ptas na Result v Rustu (Option je v necem podobny pripad, ale vyuziti ma jinde). Vyhodou je, ze ta "uzitecna" navratova hodnota v pripade chyby neexistuje, neda se k ni nijak dostat a omylem ji nekde pouzivat. Pokud funkce vraci kod chyby a "uzitecnou" hodnotu, programator ma tu hodnotu k dispozici bez ohledu na to, jestli volana funkce indikuje chybu. Coz je spatne principialne a nebezpecne v praxi. Dava Ti to smysl?

Síla Optional není v tom, že obsahuje hodnotu i error. Ale v řetězení, které zlepšuje čitelnost kódu.


Optional.of(něco)
.map(f1)
.map(f2)
.map(f3)
.orElse(X);


Při vhodném použití to ušetří mnoho zbytečných podmínek s testem na chybu.

Přesně tak, typický příklad nalepováku je C++. Také leccos nalepovali dodatečně - a leccos drhne. Odnesla to hlavně zbytečná složitost C++ jazyka.

Myslíte, že když jsem si mimo jiné pročetl FAQ přímo od autorů Go, a na základě toho si udělal názor - že jsem čerpal z neseriózního zdroje? Zkuste mi prosím doporučit serióznější zdroj než jsou autoři Go, abych nepoužíval podle vás špatné zdroje!

Go jako nekonzistentní nalepovák skončí, protože přesně takto si autoři představují výrobu a vývoj programovacího jazyka. V tomto stavu a množině vlastností autoři Go nechat nemůžou, takže budou muset časem vlastnosti přidávat, pokud má ten jazyk rozumně přežít.

Takže na wikipedii ve sloupci "Language changes" u změn verzí Go lžou?

https://en.wikipedia.org/wiki/Go_(programming_language)

Je to hrozné, jak se na wikipedii lže a kecá! A to má anglická wikipedii tolik editorů! Že to neopraví, lháři jedni a šiřitelé fake news o Go jazyce!

A četl jste ty změny? Myslíte, že se dá na základě nich označit Go jako "nalepovák"? Která nová konstrukce byla nalepena?

Mně hlavně připadá absurdní, že autoři Go byli frustrováni složitostí jazyků jako je C++ či Java, a přitom se vydávají zcela stejnou cestou, aby došli časem k témuž výsledku.

Na počátku v prvních verzích byly C++ i Java pěkné, jednoduché a nijak těžké ani komplexní jazyky. Ty dnešní obludy se z nich staly až časem, když se postupně přidávalo to a ono. U C++ i Javy to jde chápat, protože v době jejich vzniku nemohli předvídat vývoj, který nastane v programovacích jazycích.

Jediná cesta, jak udělat moderní jazyk bez složitostí je navrhnout ho od začátku se všemi koncepty, které tam dříve či později hodláte mít. Jinak jdete neomylnou cestou k molochům ála C++, Java či PHP.

Já už se těším, jak bude Go nalepovat třeba ta generika. To se najednou zjistí, co všechno v současné verzi Go se nedomyslelo a příliš neladí s generiky!

Výjimky v Go možná budou, možná nebudou přidána - to se uvidí. A zase bude problém, protože se na to nemyslelo od začátku!

Ano, vratme sa k Paskalu, tiez nemal plno uzitocnych veci. Mna naozaj fascinuje ako ludia, co robia v Go doslova adoruju jeho nedostatky a nedorobky ako vyhodu, to nikedy nerobili v nicom pouzitelnom?

Turinguv stroj spocita vsechno.

> A: Já na to používám předpřipravené stavební bloky,

Může mi někdo vysvětlit význam slova "předpřipravený"? Podle mě je to nesmysl.

Chápu význam slova "připravený", nechápu význam slova "předpřipravený". Co to má být? Jaký význam v té zkomolenině má ta nadbytečná předpona "před-"? Podobně úchylný mi připadá "podtácek" (on je taky nějaký nadtácek?), "20tý" nebo dokonce "40cet".

"Připravit" znamená nachystat k něčemu - tedy před něčím. "Předpřipravit" už tedy nedává smysl. To slovo, které hledáte, je prostě "připravit". Připadá vám málo sexy? To je snad nějaká úchylka... "Hmotnost" ani "váha" se nepozdává, ale líbí se mi "gramáž" - někde jsem to zaslechl, sice nevím, co to znamená, tak mrsk s tím do nabídky. Hmm.. "ukrást".. to zní hospodsky, "odcizit" - to zní slušněji, ale "zcizit" - to se mi líbí úplně nejvíc, to jsem už někde zaslechl, to bude asi vono. Hoodinky nebo holínky, hlavně že se použije nějaký hezký termit.

"prepripraveny" je myslim docela jasne, wocogo.
kdyz je neco "pripravene", tak to proste vezmu jak je a vrazim, kam patri.
ale kdyz to je jeste treba mirne doladit, ne vsechno, jenom male detaily, aby to zapadlo, tak je to "prepripravene"
neco jako polotovar, ci sablona - taky polotovary nejime jenom tak, ale je jeste DOupravujeme, a sablony taky jeste DOvyplnujeme ...
podobne je to i s vyrazem "pos.rany" (vyznam asi neni treba vysvetlovat) a s vyrazem "predpos.rany" :)

Vy se na něco připravujete až po "tom"? Tomu se u nás říká s křížkem po funuse. Připravuje se vždy v očekávání něčeho budoucího, tedy časově před něčím. Proto je předpona "před-" naprosto zbytečná, protože sémantika něčeho předcházejícího je nedílnou součástí slova "připravit".

Na to jsem právě poukazoval. "Gramáž masa je před tepelnou úpravou." "Pachatel zcizil kolo." Proč ti lidi prostě nepoužili slova, která znají, a vymýšlejí si novotvary, jimiž se nevědomky trefují do již zavedených pojmů, které ale znamenají něco úplně jiného?
Další podobné patvary jako "předpřipravit" jsou "nejaktuálnější", "nejoptimálnější" apod. To je jak "lepšejší". Prosím, když takto žvatlají předškolní dítka, může to být i roztomilé.

> Mohl byste takto rozebrat i váš text a ptát se, proč píšete „nachystat“, když máme slovo „přichystat“, proč „nadbytečná“, když existuje slovo „zbytečná“.

Vidím, že vám naprosto chybí cit pro jazyk a jeho logiku a poukazujete na něco úplně jiného. "Chystat" je imperfektivní kořen a k němu se pojící předpony mají perfektivizující význam, jinak jsou synonymické. "Předpřichystat" už by byl opět nesmysl. U kořene "pravit" ale mají předpony navíc i sémantický význam: při-pravit, na-pravit, vy-pravit, po-pravit, o-pravit, s-pravit, z-pravit... Předřazování dalších předpon je v češtině možné, ale musí dále modifikovat smysl: roz-pro-střít, za-po-šít, při-po-strčit, ne-před-po-s.aný

@hawran, myslim, ze to je nejsamlepsejsi vyraz :)

Libi se mi primer a zaroven jsem fandago!
Ale jak se z cihel da postavit neklenuty strop? ;) V cinzacich jsou pouzity tramy..