Co si myslíte o OOP?

[listoper]

...
Podobne v clojure, coz je lisp family ale mota tam infix notaci kvuli citelnosti. Clojure vypada vic jako cisty lisp. U elixiru musi clovek vic zamhourit oci aby to videl.
....

Muzes ukazat priklad infix notace v clojure?

 (hash-map :key1 1, :key1 2)
Ta carka je infix syntakticky cukr.

{:key1 1, :key1 2}
Dalsi syntakticky cukr je pouziti jinych zavorek.

https://clojuredocs.org/clojure.core/hash-map

a jo tohle. To sem nikdy nepouzil, protoze to podle me citelnost zhorsuje. Myslel sem, ze mas na mysli neco kde by mel infix operator nejaky vyznam...

[Reklama]

[operator]

Uniklo Ti to, co jsem psal. Když napíšu málo parametrů pro formát v Pythonu, v runtime mi to hodí výjimku. Překladač Rustu odmítne chybné parametry makra při překladu.

Však to v Pythonu odchytí testy, ne?

Ano, na každém jednotlivém místě, kde potenciálně zavoláš danou funkci, to musíš pokrýt testem. Při použití makra ne. A je to horší, v Pythonu můžeš do formátu poslat tuple nebo dict a ten si pošleš do funkce kdoví odkud. A ten test prostě budeš muset dělat pro všechna možná volání té vnitřní funkce, kde se daný formát řetězce provádí a doufat, že jsi na nic nezapomněl. A kvůli hloupému formátování řetězce, který se třeba zapisuje někam do logu, kam prakticky nikdy nikdo nekouká, spadne celá aplikace nebo neošetříš jeden request a je průšvih. S makrem nic takového nehrozí, tam víš, na čem jsi.

Nerozumím. Proč by ta aplikace měla spadnout, když zavolám nějakou funkci či metodu s chybným prametrem?

Asi nerozumíš více věcem, ale to je normální.

Typický inkvizitorský bullshit. V pythonu bys dnes měl v první řadě používat fstringy a v tu ránu ti zmíněný problém nehrozí. Mimo to, že ti nesedí počet argumentů, ti ošetří lint realtime už při psaní, viz obrázek. Když od někud taháš data, musíš si je validovat v každém jazyce. Statické C ti bez toho s makry i bez nich padá jako zralá hruška. Výjimky jsou tu od toho, abys je ošetřoval a ne proto, abys je ignoroval a nechal na nich spadnout program. A když jsi takový neumětel, že si neošetřuješ IO operace, nic jiného si ani nezasloužíš a to v libovolnám jazyce.

[petersonoop]

Clovek zalozi temu a ty par kokotov sa nachyta a honia si tu ego. Mali ste ist radsej kopat jamy curaci, lebo vy nemozte robit programatorov za tych XYtisic kc.

[Kit]

Uniklo Ti to, co jsem psal. Když napíšu málo parametrů pro formát v Pythonu, v runtime mi to hodí výjimku. Překladač Rustu odmítne chybné parametry makra při překladu.

Však to v Pythonu odchytí testy, ne?

Ano, na každém jednotlivém místě, kde potenciálně zavoláš danou funkci, to musíš pokrýt testem. Při použití makra ne. A je to horší, v Pythonu můžeš do formátu poslat tuple nebo dict a ten si pošleš do funkce kdoví odkud. A ten test prostě budeš muset dělat pro všechna možná volání té vnitřní funkce, kde se daný formát řetězce provádí a doufat, že jsi na nic nezapomněl. A kvůli hloupému formátování řetězce, který se třeba zapisuje někam do logu, kam prakticky nikdy nikdo nekouká, spadne celá aplikace nebo neošetříš jeden request a je průšvih. S makrem nic takového nehrozí, tam víš, na čem jsi.

Nerozumím. Proč by ta aplikace měla spadnout, když zavolám nějakou funkci či metodu s chybným prametrem?

Asi nerozumíš více věcem, ale to je normální.

Mohl bys mi prosím odpovědět na položenou otázku?

Proč by ta aplikace měla spadnout, když zavolám nějakou funkci či metodu s chybným prametrem?

Pokud neznáš odpověď, tak samozřejmě nemusíš a ani se nemusíš zbytečně vykrucovat.

[BoneFlute]

Uniklo Ti to, co jsem psal. Když napíšu málo parametrů pro formát v Pythonu, v runtime mi to hodí výjimku. Překladač Rustu odmítne chybné parametry makra při překladu.

Však to v Pythonu odchytí testy, ne?

Ano, na každém jednotlivém místě, kde potenciálně zavoláš danou funkci, to musíš pokrýt testem. Při použití makra ne. A je to horší, v Pythonu můžeš do formátu poslat tuple nebo dict a ten si pošleš do funkce kdoví odkud. A ten test prostě budeš muset dělat pro všechna možná volání té vnitřní funkce, kde se daný formát řetězce provádí a doufat, že jsi na nic nezapomněl. A kvůli hloupému formátování řetězce, který se třeba zapisuje někam do logu, kam prakticky nikdy nikdo nekouká, spadne celá aplikace nebo neošetříš jeden request a je průšvih. S makrem nic takového nehrozí, tam víš, na čem jsi.

Nerozumím. Proč by ta aplikace měla spadnout, když zavolám nějakou funkci či metodu s chybným prametrem?

Asi nerozumíš více věcem, ale to je normální.

Mohl bys mi prosím odpovědět na položenou otázku?

Proč by ta aplikace měla spadnout, když zavolám nějakou funkci či metodu s chybným prametrem?

Pokud neznáš odpověď, tak samozřejmě nemusíš a ani se nemusíš zbytečně vykrucovat.

Ano. Taky se hlásím. Taky nerozumím, proč by zavolání nějaké funkce či metody s chybným prametrem nemělo spadnout.

[Reklama]

[Honza]

Proč by aplikace musela rovnou celá spadnout? Proč by se nemohlo provádění dané operace zastavit, odeslat programátorovi (třeba e-mailem) serializovaný stack, který si programátor otevře, zobrazí mu to debugger v daném místě, s příslušnými parametry dané metody, zjistí, kde se stala chyba, kterou opraví, aplikaci aktualizuje, a ta může dál v běhu pokračovat tam, kde se zastavila?!

[Inkvizitor]

Proč by aplikace musela rovnou celá spadnout? Proč by se nemohlo provádění dané operace zastavit, odeslat programátorovi (třeba e-mailem) serializovaný stack, který si programátor otevře, zobrazí mu to debugger v daném místě, s příslušnými parametry dané metody, zjistí, kde se stala chyba, kterou opraví, aplikaci aktualizuje, a ta může dál v běhu pokračovat tam, kde se zastavila?!

Třeba proto, že než programátor dostane mail, aktualizuje aplikaci apod., request už dávno vyexpiroval a provozovatel přišel o kšeft. Ale asi žijeme každý v jiném světě a Ty s Kitem si pozastavíte realitu, opravíte aplikaci a ona pojede dál, kde skončila a to zcela bez následku.

[Kit]

Proč by aplikace musela rovnou celá spadnout? Proč by se nemohlo provádění dané operace zastavit, odeslat programátorovi (třeba e-mailem) serializovaný stack, který si programátor otevře, zobrazí mu to debugger v daném místě, s příslušnými parametry dané metody, zjistí, kde se stala chyba, kterou opraví, aplikaci aktualizuje, a ta může dál v běhu pokračovat tam, kde se zastavila?!

Třeba proto, že než programátor dostane mail, aktualizuje aplikaci apod., request už dávno vyexpiroval a provozovatel přišel o kšeft. Ale asi žijeme každý v jiném světě a Ty s Kitem si pozastavíte realitu, opravíte aplikaci a ona pojede dál, kde skončila a to zcela bez následku.

Program kvůli takové prkotině nezastavuji. Zaloguje chybu, zotaví se a jede dál. Standardní postup.

[BoneFlute]

Proč by aplikace musela rovnou celá spadnout? Proč by se nemohlo provádění dané operace zastavit, odeslat programátorovi (třeba e-mailem) serializovaný stack, který si programátor otevře, zobrazí mu to debugger v daném místě, s příslušnými parametry dané metody, zjistí, kde se stala chyba, kterou opraví, aplikaci aktualizuje, a ta může dál v běhu pokračovat tam, kde se zastavila?!

Protože pád aplikace je furt ještě lepší výsledek než poškození dat. Chyba programátora může být prkotina (argument navíc), ale také může být zásadní. A to nejde rozhodnout.

Proto je obecně lepší všechny tyhle scénáře nechat vychytat už dlouho před tím, než se kód vůbec dostane na produkci (dost na tom, že i tak nejdou udělat všechny).

[Kit]

Proč by aplikace musela rovnou celá spadnout? Proč by se nemohlo provádění dané operace zastavit, odeslat programátorovi (třeba e-mailem) serializovaný stack, který si programátor otevře, zobrazí mu to debugger v daném místě, s příslušnými parametry dané metody, zjistí, kde se stala chyba, kterou opraví, aplikaci aktualizuje, a ta může dál v běhu pokračovat tam, kde se zastavila?!

Protože pád aplikace je furt ještě lepší výsledek než poškození dat. Chyba programátora může být prkotina (argument navíc), ale také může být zásadní. A to nejde rozhodnout.

Proto je obecně lepší všechny tyhle scénáře nechat vychytat už dlouho před tím, než se kód vůbec dostane na produkci (dost na tom, že i tak nejdou udělat všechny).

Aha, takže když uživatel místo int vloží text, tak necháš aplikaci slítnout? Hmm, to asi bude hodně stabilní.

[operator]

Proč by aplikace musela rovnou celá spadnout? Proč by se nemohlo provádění dané operace zastavit, odeslat programátorovi (třeba e-mailem) serializovaný stack, který si programátor otevře, zobrazí mu to debugger v daném místě, s příslušnými parametry dané metody, zjistí, kde se stala chyba, kterou opraví, aplikaci aktualizuje, a ta může dál v běhu pokračovat tam, kde se zastavila?!

Protože pád aplikace je furt ještě lepší výsledek než poškození dat. Chyba programátora může být prkotina (argument navíc), ale také může být zásadní. A to nejde rozhodnout.

Proto je obecně lepší všechny tyhle scénáře nechat vychytat už dlouho před tím, než se kód vůbec dostane na produkci (dost na tom, že i tak nejdou udělat všechny).

Jde to rozhodnout. Už v zadání bylo řečeno, že jde o nedůležitou funkci. Takže příslušnou operace můžeš nechat v klidu selhat, selhání zaznamenat a program může pokračovat dál.

[v]

Proč by aplikace musela rovnou celá spadnout? Proč by se nemohlo provádění dané operace zastavit, odeslat programátorovi (třeba e-mailem) serializovaný stack, který si programátor otevře, zobrazí mu to debugger v daném místě, s příslušnými parametry dané metody, zjistí, kde se stala chyba, kterou opraví, aplikaci aktualizuje, a ta může dál v běhu pokračovat tam, kde se zastavila?!

Protože pád aplikace je furt ještě lepší výsledek než poškození dat. Chyba programátora může být prkotina (argument navíc), ale také může být zásadní. A to nejde rozhodnout.

Proto je obecně lepší všechny tyhle scénáře nechat vychytat už dlouho před tím, než se kód vůbec dostane na produkci (dost na tom, že i tak nejdou udělat všechny).

Jde to rozhodnout. Už v zadání bylo řečeno, že jde o nedůležitou funkci. Takže příslušnou operace můžeš nechat v klidu selhat, selhání zaznamenat a program může pokračovat dál.

selhání nedůležié funkce je pro mě třeba selhání zobrazení notifikace na desktopu (tj. IO operace mimo kontrolu programátora), volání funkce s nesprávným počtem argumentů je docela hrozivá logická chyba

[Inkvizitor]

Aha, takže když uživatel místo int vloží text, tak necháš aplikaci slítnout? Hmm, to asi bude hodně stabilní.

Kite, Kite. Bavime se o chybach, ktere zpusobil programator, v tomto pripade dokonce o chybe, ktera by se dala odchytit pri prekladu, kdyby dany jazyk rozumne podporoval makra. Pokud nekdo nema validaci vstupu a necha probublat z formulare nenumericky vstup tam, kde je pozadovano cislo, ma mnohem vetsi problem, nez ze mu to shodilo aplikaci.

A ano, mas pravdu, ze v dnesnich interaktivnich systemech fakt runtime chyba obycejne nevede k ukonceni cele aplikace. Jenze problem, o kterem jsem puvodne psal, je v tom, ze (zase se opakuju) dnesni jazyky uz umeji nektere tridy chyb proste eliminovat. Ty ostatni se budto prizpusobi nebo budou v nekterych oblastech po pravu vytlaceny.

[gll]

Linter může kotrolovat jenom to, čemu rozumí. Makro si můžu napsat vlastní a mám to i s tou kontrolou, nejde jenom o standardní knihovnu.  Mimochodem právě na Pylintu je vidět, jak se vyplatí psát všechno "hloupě" jako ve statických jazycích, jinak přestane chápat, co se kam může posílat a kde se bere jaká hodnota a už nám s kontrolou nepomůže.

kolik jsi takových maker validujících mikrojazyk napsal? Podle mě to není častý problém a lépe ho vyřeší plugin do linteru.

[Inkvizitor]

Linter může kotrolovat jenom to, čemu rozumí. Makro si můžu napsat vlastní a mám to i s tou kontrolou, nejde jenom o standardní knihovnu.  Mimochodem právě na Pylintu je vidět, jak se vyplatí psát všechno "hloupě" jako ve statických jazycích, jinak přestane chápat, co se kam může posílat a kde se bere jaká hodnota a už nám s kontrolou nepomůže.

kolik jsi takových maker validujících mikrojazyk napsal? Podle mě to není častý problém a lépe ho vyřeší plugin do linteru.

No promin, ale jak mam na tohle reagovat? Plugin do linteru ten problem samozrejme nevyresi lepe, je to reseni ad hoc a je to reseni z principu mene spolehlive, nez first-class podpora ve standardnich nastrojich jazyka. Kolik jsem dosud napsal podobnych maker ja (0, kdyz to chces slyset), je z tohoto pohledu vedlejsi.