Jaký programovací jazyk zvolit?

[Radovan.]

Blbost. Goto říká, kam se má skočit, ve strukturovaném programování ho nahrazuje else. Return obsahuje návratovou hodnotu, tedy data. Return neobsahuje žádnou adresu, s goto tedy nesouvisí.

Ved return ma adresu, aby vedel, kam skocit s vysledkom, resp pre navrat.

Instrukce pro return nemá adresu. Vezme si ji ze zásobníku.

To neznáš Fortran 77

[Reklama]

[Kit]

Instrukce pro return nemá adresu. Vezme si ji ze zásobníku.

To neznáš Fortran 77

Různé jazyky mohou mít rozdílné implementace. Instrukce pro return v assembleru (ke kterému jsme mezitím zavítali) žádnou návratovou adresu nemá, protože ji ani mít nemůže. Viz výše.

[BoneFlute]

Pochopil jsi to zcela chybně, protože to "else" není nutné ničím nahrazovat.

(1 + 2) is equals (2 + 1)

Tohle sice v Euklidovském prostoru platí, ale co to má společného s "else"?

To byla jen taková decentní narážka na to, že když poukážeš na blbost, kterou jsem neřekl, tak nezachráníš skutečnost, že si řekl blbost.

[BoneFlute]

return nebo throw. Je zbytečné dělat větve else pro nějaké chybové stavy, protože se tím zápis zbytečně komplikuje.

Tohle mi přijde jako příliš silné tvrzení. Pro "očekávané" chybové stavy (třeba výpadek spojení) mi házení vždycky tak zkomplikovalo kód, že jsem to nakonec přepsal přes návratové hodnoty.

Nevidím důvod, proč bych měl vyhozené výjimky konvertovat na nějaké návratové kódy z minulého století. Výjimka obsahuje úplnou informaci o chybovém stavu, mohu ji nechat propadnout až do takového levelu, ve kterém jsem ochoten ji ošetřit. Nemůže se mi stát, že bych na nějakou zapomněl, což se u návratových kódů stávalo běžně. Návratové kódy také nepříjemně ovlivňují typy návratových hodnot funkcí.

To hodně záleží na jazyku. Návratové kódy z minulého století často dokazují, že páni inženýři dříve to měli více vykoumané, než páni programátoři dneska.
Výjimky jsou nutnou cestou u jazyka, kde nelze zajistit odebrání si výsledku. V ostatních případech je to spíše komplikace.

A co se dodatečných returnů týká, po zkušenostech se snažím počet navratových bodů z funkcí omezovat. A všechny returny, co nejsou na konci funkcí se snažím výrazně značit. Else možná komplikuje zápis, ale na rozdíl od returnu je ta změna odsazení aspoň na první pohled vidět i při zběžném čtení.

To je dnes už zastaralá teorie jednoho návratového bodu.

Ale!? A to řekl kdo? A já měl naopak pocit, že tato zastaralá teorie zažívá comeback, páč jsme si ty slepé uličky prošli. To sou věci...

Naproti tomu více návratových bodů umožňuje zbavit se i "break" v cyklu a ve switchi. Navíc je to mnohem přehlednější.

Já si přeci kůli tomu, abych se zbavil nějakých konstrukcí které se nějakému Kitovi nelíbí nebudu zasí**t kontrakt.

na začátku metody pomocí podmínek ošetřím vstupy a pak teprve provedu požadovanou akci.

Nejvíce úsměvné je to, že já to takhle dělám taky. Ale z úplně jiných důvodů. Tvá argumentace, že nechceš používat else je prostě střelená. Hledáš magii, kde žádná není.

[aaa]

Nevidím důvod, proč bych měl vyhozené výjimky konvertovat na nějaké návratové kódy z minulého století. Výjimka obsahuje úplnou informaci o chybovém stavu, mohu ji nechat propadnout až do takového levelu, ve kterém jsem ochoten ji ošetřit. Nemůže se mi stát, že bych na nějakou zapomněl, což se u návratových kódů stávalo běžně. Návratové kódy také nepříjemně ovlivňují typy návratových hodnot funkcí.

Vynimky su "radost", teda aspon tie non-checked. Ked padaju cez viac levelov, tak funguju ako spolahliva obfuskacia, lebo nie su jasne vidiet urovne abstrakcie. Ide to uplne proti zvladnutelnemu programovaniu, kde zavolam funkciu a ta mi vrati hodnotu bez toho, aby som sa staral, ako k nej dosla. Naopak, treba poznat implementaciu do najmensieho detailu.

Ked neviem, co za nedokumentovanu vynimku vyleti, tak dokazem najviac nejaky univerzalny catch all, ktory aj tak nebude spravne* fungovat, lebo neviem, o aku chybu sa jedna. Z necheckovanych vynimiek spolahlivo a spravne funguje iba vynimka = koniec aplikacie, co je u kniznice neprijemne.

*spravnym fungovanim nemyslim hlasenie uzivatelovi ako od user-friendly vyrobcu: "Fatal error. Abort, Retry, Fail?".

[Reklama]

[Radovan.]

Instrukce pro return nemá adresu. Vezme si ji ze zásobníku.

To neznáš Fortran 77

Různé jazyky mohou mít rozdílné implementace. Instrukce pro return v assembleru (ke kterému jsme mezitím zavítali) žádnou návratovou adresu nemá, protože ji ani mít nemůže. Viz výše.

Přímo návratovou adresu ne, ale může si vybrat z několika předem připravených, i 8086 to umí. A podívej se na konci té stránky na "Alternate RETURN Statement", to se ti bude líbit: http://www.obliquity.com/computer/fortran/procedure.html

[Kit]

Nevidím důvod, proč bych měl vyhozené výjimky konvertovat na nějaké návratové kódy z minulého století. Výjimka obsahuje úplnou informaci o chybovém stavu, mohu ji nechat propadnout až do takového levelu, ve kterém jsem ochoten ji ošetřit. Nemůže se mi stát, že bych na nějakou zapomněl, což se u návratových kódů stávalo běžně. Návratové kódy také nepříjemně ovlivňují typy návratových hodnot funkcí.

Vynimky su "radost", teda aspon tie non-checked. Ked padaju cez viac levelov, tak funguju ako spolahliva obfuskacia, lebo nie su jasne vidiet urovne abstrakcie. Ide to uplne proti zvladnutelnemu programovaniu, kde zavolam funkciu a ta mi vrati hodnotu bez toho, aby som sa staral, ako k nej dosla. Naopak, treba poznat implementaciu do najmensieho detailu.

Ked neviem, co za nedokumentovanu vynimku vyleti, tak dokazem najviac nejaky univerzalny catch all, ktory aj tak nebude spravne* fungovat, lebo neviem, o aku chybu sa jedna. Z necheckovanych vynimiek spolahlivo a spravne funguje iba vynimka = koniec aplikacie, co je u kniznice neprijemne.

*spravnym fungovanim nemyslim hlasenie uzivatelovi ako od user-friendly vyrobcu: "Fatal error. Abort, Retry, Fail?".

Výjimky mi fungují zcela bez problémů, žádné obfuskace v nich nevidím. Při propadu přes více úrovní musí být samozřejmě součástí rozhraní a v případě potřeby je nutné je konvertovat.

Nevidím důvod, proč bych se měl starat o to, jakou hodnotu mi funkce vrací. Je to součástí její kompetence, která je řádně podchycena v testech. Při běhu ji tedy kontrolovat nemusím.

[aaa]

Výjimky mi fungují zcela bez problémů, žádné obfuskace v nich nevidím. Při propadu přes více úrovní musí být samozřejmě součástí rozhraní a v případě potřeby je nutné je konvertovat.

Ok, takze ked chytame vynimku na kazdej urovni abstrakcie, tak o co je to lepsie od vracania rovno chyby + navratovej hodnoty? Tym myslim pristup ako v Go, kde sa normalne vracia dvojica (hodnota, error).

Ked nechytame vynimky na kazdej urovni, tak nastava ten chaos, ze zavolam stiahnutie stranky a vyleti na mna UnknownCharacterException a musim ist az do najnizsej urovne, aby som zistil, ze niekto pridal overovanie platnosti Unicode znakov.

Nevidím důvod, proč bych se měl starat o to, jakou hodnotu mi funkce vrací. Je to součástí její kompetence, která je řádně podchycena v testech. Při běhu ji tedy kontrolovat nemusím.

Podchytenie v testoch funguje len bez cudzieho kodu a len bez chyb a zabudania. Urcite mate testy cudzej kniznice, ktore overuju aj vsetky vynimky, ktore vracia? Kde je istota, ze tam nikto neprida dalsiu "internu" vynimku, ktora vybuble von?

Ked sa bude funkcia bez exception pri nejakych vstupoch mylit, tak sa to da stale izolovat a dobre debugovat. Ked bude vyhadzovat exception a niekto tu exception raz nechyti, tak to bude bublat az niekam vysoko, tam to niekto nahodou chyti a z divnych dovodov sa nebude vykonavat cast kodu. A ten co to chytil nema sancu poznat, ze tu vynimku hodil niekto hlbsie v hierarchii ako sa cakalo a jeho reakcia bude v principe nezmyselna.

[JSH]

Nevidím důvod, proč bych měl vyhozené výjimky konvertovat na nějaké návratové kódy z minulého století.

Vždyť to info o chybě nemusím vůbec dostat formou výjimky. Rozumné api mě nechá vybrat. Někdy je daleko lepší neházet (klasika je NumberFormatException z Javy)

Výjimka obsahuje úplnou informaci o chybovém stavu, mohu ji nechat propadnout až do takového levelu, ve kterém jsem ochoten ji ošetřit.

To teda neobsahuje právě proto, že propadává nahoru. Neobsahuje nic, co do ní sám nenacpu.

Nemůže se mi stát, že bych na nějakou zapomněl, což se u návratových kódů stávalo běžně.

Já psal o "očekávaných" chybách. Ale zapomenutá výjimka je taky bug. Když zapomenu ošetřit nějakou výjimku, tak probublá ven, kde se už může leda tak hádat, co se vlastně stalo. Program může tak akorát padnout na hubu a případně poslat stacktrace mailem.

Návratové kódy také nepříjemně ovlivňují typy návratových hodnot funkcí.

Možná jsem zkažený Haskellem a C++, ale co je nepříjemného na součtovém typu? Nebo na přístupu z boost::asio, tzn další parametr, kterým buď předám proměnnou pro chybovou hodnotu, nebo jím zapnu házení.

To je dnes už zastaralá teorie jednoho návratového bodu. Naproti tomu více návratových bodů umožňuje zbavit se i "break" v cyklu a ve switchi. Navíc je to mnohem přehlednější.

He? Vždyť return dělá to co break. Jen pro jiné složené závorky.

[Ondra Satai Nekola]

Nevidím důvod, proč bych měl vyhozené výjimky konvertovat na nějaké návratové kódy z minulého století.

Vždyť to info o chybě nemusím vůbec dostat formou výjimky. Rozumné api mě nechá vybrat.

Proc by "rozumne API" melo umoznit u takove zakladni veci vyber? Tvurce toho API by mel zvolit jedu dobrou variantu (v pripade C??/Java/Python-like jazyku vyjimku) a te se drzet.

[Kit]

Nevidím důvod, proč bych měl vyhozené výjimky konvertovat na nějaké návratové kódy z minulého století.

Vždyť to info o chybě nemusím vůbec dostat formou výjimky. Rozumné api mě nechá vybrat. Někdy je daleko lepší neházet (klasika je NumberFormatException z Javy)

Výjimky mi vyhovují víc. Mám s nimi méně práce a dobře se testují.

Výjimka obsahuje úplnou informaci o chybovém stavu, mohu ji nechat propadnout až do takového levelu, ve kterém jsem ochoten ji ošetřit.

To teda neobsahuje právě proto, že propadává nahoru. Neobsahuje nic, co do ní sám nenacpu.

Zas tak moc ji propadávat nenechám. Pokud si nevytváříš vlastní třídy výjimek, tak zřejmě budou mít nízkou vypovídací schopnost.

Nemůže se mi stát, že bych na nějakou zapomněl, což se u návratových kódů stávalo běžně.

Já psal o "očekávaných" chybách. Ale zapomenutá výjimka je taky bug. Když zapomenu ošetřit nějakou výjimku, tak probublá ven, kde se už může leda tak hádat, co se vlastně stalo. Program může tak akorát padnout na hubu a případně poslat stacktrace mailem.

Co je to "zapomenutá výjimka"? To neznám.

Návratové kódy také nepříjemně ovlivňují typy návratových hodnot funkcí.

Možná jsem zkažený Haskellem a C++, ale co je nepříjemného na součtovém typu? Nebo na přístupu z boost::asio, tzn další parametr, kterým buď předám proměnnou pro chybovou hodnotu, nebo jím zapnu házení.

Haskel je zajímavý jazyk, který výjimky řeší zcela jinak než objektové jazyky. O výjimkách v C++ platí totéž - tam je to spíš parodie na výjimky. Nedivím se, že ti nevyhovují.

To je dnes už zastaralá teorie jednoho návratového bodu. Naproti tomu více návratových bodů umožňuje zbavit se i "break" v cyklu a ve switchi. Navíc je to mnohem přehlednější.

He? Vždyť return dělá to co break. Jen pro jiné složené závorky.

Return na rozdíl od break vrací nějakou hodnotu. V C++ se tak dají vracet jen hodnoty primitivních typů, takže to neoceníš. V objektových jazycích mi return ve switchi obvykle vrací hotové objekty - break by mi v takovém případě nebyl nic platný.

[gl]

Možná jsem zkažený Haskellem a C++, ale co je nepříjemného na součtovém typu? Nebo na přístupu z boost::asio, tzn další parametr, kterým buď předám proměnnou pro chybovou hodnotu, nebo jím zapnu házení.

Vyjímky se dají potlačit různými způsoby. V Pythonu by to šlo třeba wrapperem a vracet tuple:

Kód: [Vybrat]

import functools


def silenced(func, defaultval=None):
    @functools.wraps(func)
    def f(*args, **kwargs):
        try:
            return (func(*args, **kwargs), None)
        except Exception as e:
            return (defaultval, e)
    return f


def test1(err):
    """
    >>> silenced(test1)(False)
    ('OK', None)
    >>> silenced(test1, 1)(True)
    (1, Exception('Not OK',))
    >>> test1 = silenced(test1)
    >>> (res, _) = test1(False)
    >>> res
    'OK'
    """
    if err:
        raise Exception('Not OK')
    else:
        return 'OK'


@functools.partial(silenced, defaultval=False)
def test2():
    """
    >>> test2()
    (False, Exception('Not OK',))
    """
    return test1(True)

Je to jen takový nástřel. Neručím za to. Nevidím důvod proč to tak dělat. Namísto zachytávání výjimky je třeba testovat návratovou hodnotu.

[JSH]

Návratové kódy také nepříjemně ovlivňují typy návratových hodnot funkcí.

Možná jsem zkažený Haskellem a C++, ale co je nepříjemného na součtovém typu? Nebo na přístupu z boost::asio, tzn další parametr, kterým buď předám proměnnou pro chybovou hodnotu, nebo jím zapnu házení.

Haskel je zajímavý jazyk, který výjimky řeší zcela jinak než objektové jazyky. O výjimkách v C++ platí totéž - tam je to spíš parodie na výjimky. Nedivím se, že ti nevyhovují.

Přečti si pořádně, na co jsem reagoval. Já psal, že na přibalení chybového kódu k vracené hodnotě není nic složitého ani nepříjemného. O tom, že by mi výjimky nevyhovovaly, jsem nepsal. Naopak je používám, když se hodí víc než chybové kódy.

To je dnes už zastaralá teorie jednoho návratového bodu. Naproti tomu více návratových bodů umožňuje zbavit se i "break" v cyklu a ve switchi. Navíc je to mnohem přehlednější.

He? Vždyť return dělá to co break. Jen pro jiné složené závorky.

Return na rozdíl od break vrací nějakou hodnotu.

I return bez parametru? A return s parametrem si můžeš porovnat s přířazením+break. Furt je to tak rozdílné?

V C++ se tak dají vracet jen hodnoty primitivních typů, takže to neoceníš.

Blbost. Dá se vracet cokoliv kopírovatelného.

[JSH]

Proc by "rozumne API" melo umoznit u takove zakladni veci vyber? Tvurce toho API by mel zvolit jedu dobrou variantu (v pripade C??/Java/Python-like jazyku vyjimku) a te se drzet.

... Nevidím důvod proč to tak dělat. Namísto zachytávání výjimky je třeba testovat návratovou hodnotu.

Důvod je ten, že testování návratových hodnot občas vede k daleko přehlednějšímu kódu. Rozhodně netvrdím, že vždycky. Hodí se to, pokud ošetřuju chybu hodně blízko místa vzniku a vím že se to bude stávat celkem často. Jako dobrý příklad mi přijde třeba parsování vstupu od uživatele. V Javě třeba spoustě lidí chybí něco jako TryParseInt.

[Kit]

Return na rozdíl od break vrací nějakou hodnotu.

I return bez parametru? A return s parametrem si můžeš porovnat s přířazením+break. Furt je to tak rozdílné?
[/quote]

Return bez parametru jsem už hodně dlouho nepoužil. U funkcí mi return vrací výsledek, u procedur stavový kód provedené operace nebo počet provedených změn. Break mi prostě nevyhovuje.