Frustrace ze stavu mainstreamových programovacích jazyků

O.

Re:Frustrace ze stavu mainstreamových programovacích jazyků
« Odpověď #15 kdy: 18. 08. 2017, 19:22:15 »
Buď rád, že nemusíš řešit error handling pomocí On Error GoTo ErrorHandler
Na chyby jsou monády  ;D

Lepsi je gonada


JSH

Re:Frustrace ze stavu mainstreamových programovacích jazyků
« Odpověď #16 kdy: 18. 08. 2017, 20:23:40 »
Čím dal víc mě vytáčí, že v jazycích jako Java, C# nebo C++ (nebo novějších jako Go) neexistuje analogie k typovým třídám, čímž je vývojář nucen k opakování (redundanci) kódu (což je velké fuj).
Tak zrovna koncepty z nového C++ se typovým třídám už vcelku blíží. Není to sice úplně ono, ale je to lepší, než by člověk čekal.

tisnik

Re:Frustrace ze stavu mainstreamových programovacích jazyků
« Odpověď #17 kdy: 18. 08. 2017, 21:11:01 »
Kdepak vyžužlal, koukej: http://www.antonis.de/qbebooks/gwbasman/onerror.html
Ale nebyl to zase úplně špatný soft, v NASA tím dokonce řídili robota na sváření raket!

Popravdě, zrovna toto je strukturovanější přístup, než například v céčku s návratovými kódy a jejich (ne)testováním :-) ERR+ERL jsou vlastně taková poor man alternativa k objektu Exception a vůbec, já na BASICu vyrost (Atari Basic + geniální Turbo Basic). Takže i ten robot jim asi chodil :-)

Aoidhghean

Re:Frustrace ze stavu mainstreamových programovacích jazyků
« Odpověď #18 kdy: 18. 08. 2017, 21:50:00 »
Čím dal víc mě vytáčí, že v jazycích jako Java, C# nebo C++ (nebo novějších jako Go) neexistuje analogie k typovým třídám, čímž je vývojář nucen k opakování (redundanci) kódu (což je velké fuj).
Tak zrovna koncepty z nového C++ se typovým třídám už vcelku blíží. Není to sice úplně ono, ale je to lepší, než by člověk čekal.
Akorát se nějak nedostaly do C++17.

Radovan.

Re:Frustrace ze stavu mainstreamových programovacích jazyků
« Odpověď #19 kdy: 18. 08. 2017, 23:21:41 »
Kdepak vyžužlal, koukej: http://www.antonis.de/qbebooks/gwbasman/onerror.html
Ale nebyl to zase úplně špatný soft, v NASA tím dokonce řídili robota na sváření raket!
Popravdě, zrovna toto je strukturovanější přístup, než například v céčku s návratovými kódy a jejich (ne)testováním :-) ERR+ERL jsou vlastně taková poor man alternativa k objektu Exception a vůbec, já na BASICu vyrost (Atari Basic + geniální Turbo Basic). Takže i ten robot jim asi chodil :-)
Návratové kódy: http://programujte.com/clanek/2006030305-rozhovor-s-bjarne-stroustrupem/ ;D

Copak přístup, s tím ON... se dalo dělat ledacos, ale z RESUME jsem tenkrát málem vypelichal. Zlatý ZX BASIC na Didaktiku. A je škoda že aspoň v QBasicu k tomu ON PEN nepřidali i ON MOUSE, světelné pero už tenkrát měl asi málokdo, zato když jsem si psal program pro myš, musel jsem do strojáku.


.

Re:Frustrace ze stavu mainstreamových programovacích jazyků
« Odpověď #20 kdy: 19. 08. 2017, 06:32:21 »
Kdepak vyžužlal, koukej: http://www.antonis.de/qbebooks/gwbasman/onerror.html
Ale nebyl to zase úplně špatný soft, v NASA tím dokonce řídili robota na sváření raket!
Je to vyžužlal!

RDa

  • *****
  • 2 465
    • Zobrazit profil
    • E-mail
Re:Frustrace ze stavu mainstreamových programovacích jazyků
« Odpověď #21 kdy: 19. 08. 2017, 13:18:01 »
Jsou dva typy programatoru. Jedni co programovat umi a druhy co se vymlouvaj na vse ostatni co s programovanim souvisi i nesouvisi.

Aoidhghean

Re:Frustrace ze stavu mainstreamových programovacích jazyků
« Odpověď #22 kdy: 19. 08. 2017, 14:05:55 »
Jsou dva typy programatoru. Jedni co programovat umi a druhy co se vymlouvaj na vse ostatni co s programovanim souvisi i nesouvisi.
Bohužel těch prvních je nás málo  ;D

kimec

Re:Frustrace ze stavu mainstreamových programovacích jazyků
« Odpověď #23 kdy: 19. 08. 2017, 18:00:00 »
Zdravím, mám konkrétní otázku, ale nejdřív motivace. Všichni mají plnou hubu keců o DRY, KISS, LSP apod., ale když přijde na rozumnou implementaci, jazyky jen hážou klacky od nohy. Čím dal víc mě vytáčí, že v jazycích jako Java, C# nebo C++ (nebo novějších jako Go) neexistuje analogie k typovým třídám, čímž je vývojář nucen k opakování (redundanci) kódu (což je velké fuj). Takže - jak řešíte generický ad hoc polymorfismus v OO jazyce bez typových tříd (beru OO obecně, předpokládají se rozhraní, dědičnost ne)? V Go to jde částečně přes typové aliasy, jen se pak vyžaduje explicitní přetypováváni, což zbytečně prodlužuje a znepřehledňuje kód. Swift by se mohl dostat blízko, až zavedou plánovaný operátor ~=, ale ten zas mimo macOS/iOS není moc schůdný (verze pro Linux zatím hapruje).

P.S. Dynamické jazyky tento problém nemají, proto jsou v kontextu této diskuze irelevantní.
Aplikacia KISS pravidla moze na konkretnej platforme a v konkretnom jazyku znamenat GOTO.
Myslim, ze miesate hrusky s jablkami.
Ak potrebujete typove triedy ku stastiu, pouzite jazyk, ktory ich podporuje prvotriedne. End of story.

Aoidhghean

Re:Frustrace ze stavu mainstreamových programovacích jazyků
« Odpověď #24 kdy: 19. 08. 2017, 18:24:28 »
Zdravím, mám konkrétní otázku, ale nejdřív motivace. Všichni mají plnou hubu keců o DRY, KISS, LSP apod., ale když přijde na rozumnou implementaci, jazyky jen hážou klacky od nohy. Čím dal víc mě vytáčí, že v jazycích jako Java, C# nebo C++ (nebo novějších jako Go) neexistuje analogie k typovým třídám, čímž je vývojář nucen k opakování (redundanci) kódu (což je velké fuj). Takže - jak řešíte generický ad hoc polymorfismus v OO jazyce bez typových tříd (beru OO obecně, předpokládají se rozhraní, dědičnost ne)? V Go to jde částečně přes typové aliasy, jen se pak vyžaduje explicitní přetypováváni, což zbytečně prodlužuje a znepřehledňuje kód. Swift by se mohl dostat blízko, až zavedou plánovaný operátor ~=, ale ten zas mimo macOS/iOS není moc schůdný (verze pro Linux zatím hapruje).

P.S. Dynamické jazyky tento problém nemají, proto jsou v kontextu této diskuze irelevantní.
Aplikacia KISS pravidla moze na konkretnej platforme a v konkretnom jazyku znamenat GOTO.
Myslim, ze miesate hrusky s jablkami.
Ak potrebujete typove triedy ku stastiu, pouzite jazyk, ktory ich podporuje prvotriedne. End of story.
Však na GOTO taky není nic špatného (dokud ho nedostane do ruky opice).

kimec

Re:Frustrace ze stavu mainstreamových programovacích jazyků
« Odpověď #25 kdy: 19. 08. 2017, 19:00:52 »
Aplikacia KISS pravidla moze na konkretnej platforme a v konkretnom jazyku znamenat GOTO.
Myslim, ze miesate hrusky s jablkami.
Ak potrebujete typove triedy ku stastiu, pouzite jazyk, ktory ich podporuje prvotriedne. End of story.
Však na GOTO taky není nic špatného (dokud ho nedostane do ruky opice).
Myslim, ze takych ludi nebudu trapit ani tie typove triedy.

Aoidhghean

Re:Frustrace ze stavu mainstreamových programovacích jazyků
« Odpověď #26 kdy: 19. 08. 2017, 20:44:08 »
Aplikacia KISS pravidla moze na konkretnej platforme a v konkretnom jazyku znamenat GOTO.
Myslim, ze miesate hrusky s jablkami.
Ak potrebujete typove triedy ku stastiu, pouzite jazyk, ktory ich podporuje prvotriedne. End of story.
Však na GOTO taky není nic špatného (dokud ho nedostane do ruky opice).
Myslim, ze takych ludi nebudu trapit ani tie typove triedy.
Problém je, že pokud je někdo nadprůměrně dobrý/vzdělaný a umí použít třeba ty typové třídy tak, aby mu tu usnadnilo práci a výsledkem byl lepší kód, tak to prostě v mnohých jazycích nejde - to jsou ty klacky pod nohy. Je jasné, že když někdo lepí kód ze stackoverflow nebo dělá podobné jirsákoviny, tak mu je nějaká typová třída k ničemu.

Kiwi

Re:Frustrace ze stavu mainstreamových programovacích jazyků
« Odpověď #27 kdy: 20. 08. 2017, 10:59:43 »
Kdepak vyžužlal, koukej: http://www.antonis.de/qbebooks/gwbasman/onerror.html
Ale nebyl to zase úplně špatný soft, v NASA tím dokonce řídili robota na sváření raket!

Popravdě, zrovna toto je strukturovanější přístup, než například v céčku s návratovými kódy a jejich (ne)testováním :-) ERR+ERL jsou vlastně taková poor man alternativa k objektu Exception a vůbec, já na BASICu vyrost (Atari Basic + geniální Turbo Basic). Takže i ten robot jim asi chodil :-)

Mně zas připadá, že tzv. strukturované výjimky a všechny možné variace na toto téma jsou spíš nabourání strukturovaného přístupu. Někomu se kdysi zdálo, že testování chybových stavů znepřehledňuje kód. Že chyby jsou cosi druhořadého, trpěného vedle "hlavního" algoritmu. Podle mě je však chybový stav zcela normální situace, je to prostě jeden z mnoha stavů ve stavovém diagramu a tak by se s ním mělo také zacházet, tj. úplně normálně, jako s každým jiným stavem.
Všelijaké ty trapy apod. akorát vytvářejí paralelní strukturu pro chyby, která pak v praxi ale nekopíruje strukturu "hlavního algoritmu". Způsobuje separaci místa vzniku chyby od místa jejího zpracování, a to i vertikálně, přes úrovně jednotlivých vrstev, což je IMO zlo. Korektní zpracování chyby tímto stylem totiž totálně znepřehlední program, daleko víc než prosté testování návratové hodnoty. A tak se na to kašle, nechá se to zpropagovat až kdo ví kam a tam se teprve chyba řeší. Jenže takové místo je z hlediska struktury, tj. viditelnosti a rozsahu platnosti jednotlivých entit, izolované od místa vzniku. Vlastně už se tam nedá dělat nic, než jen vzít na vědomí, že "někde dole" vznikla chyba, u pečlivějších se dokonce ví, kde, ale v místě toho "trapu" už se na ni stejně nedá účinně reagovat.

Radovan.

Re:Frustrace ze stavu mainstreamových programovacích jazyků
« Odpověď #28 kdy: 20. 08. 2017, 12:33:15 »
Ono je to v podstatě přerušení, a místo GOTO tam jde použít i GOSUB, navíc to proběhne několikanásobně rychleji než nějaké testování přímo v basicovém kódu, takže ve své době to byl určitě pokrok.

Přehlednosti to určitě nepřidá, ale když si promítneš jak vypadal běžný kód s číslovanými řádky v době kdy se to objevilo, tak to už fakt nic zhoršit nemohlo ;D

Re:Frustrace ze stavu mainstreamových programovacích jazyků
« Odpověď #29 kdy: 20. 08. 2017, 12:58:50 »
Způsobuje separaci místa vzniku chyby od místa jejího zpracování, a to i vertikálně, přes úrovně jednotlivých vrstev, což je IMO zlo. [...] A tak se na to kašle, nechá se to zpropagovat až kdo ví kam a tam se teprve chyba řeší. Jenže takové místo je z hlediska struktury, tj. viditelnosti a rozsahu platnosti jednotlivých entit, izolované od místa vzniku. Vlastně už se tam nedá dělat nic, než jen vzít na vědomí, že "někde dole" vznikla chyba
...což je přesně to, co u velkého množství programů chceš. Nějaký velký blok kódu řeší jednu věc, například načtení credentials, připojení na server, autentizace. Nechceš řešit všechny možné chybové stavy u všech jednotlivých kroků. Chceš na nejvyšší úrovni dostat informaci "nemohl jsem se připojit, protože ..." (nelze se připojit k DB, credentials jsou neplatné, server je nedostupný apod.)

Kdybys měl opravdu na každém místě řešit úplně všechny chybové stavy, ke kterým může dojít (včetně lowlevel věcí jako např. "out of memory" apod.), tak v té změti checkování bude ten samotný algoritmus jako jehla v kupce sena.