Proč ten hype okolo Go?

[kiki]

když se tě někdo zeptá jakou máš kvalifikaci

Zatím se nikdo neptal. A už přestaň otravovat, takoví kriplové jsou fakt nejlepší, bezdůvodně se do někoho navážet. Najdi si radší babu (nebo chlapa) a dělej něco užitečného.

Díky za radu, jako kripl si to přeberu. Co tedy děláš?

[Reklama]

[Miloslav Ponkrác]

Podmínka mi kontext nenaruší - chybu zachytím a vypořádám tam, kde k ní došlo. Try-catch vyjde buď nastejno jakožto ukecanější varianta ifu, nebo mě hodí někam na jiné místo, mimo původní lexikální kontext, a to i v rámci jedné funkce! O šíření nezachycené výjimky vertikálně už nemluvím vůbec. Kontext, v němž chybový stav nastal, je pro jeho efektivní řešení dost důležitý.

Vy se tváříte, jako kdybyste ten kontext urgentně potřeboval. Vy ho nepotřebujete skoro nikdy, taková je pravda.

Programování není nic jiného, než neustálé mohutné zahazování kontextu. To platí jak v běžném toku programu, tak při ošetřování chyb. Zahazujete lokální kontext při opuštění každého bloku programu. Zahazujete kontext při každém vynoření se z podprogramu. Zahazujete kontext na mnoha jiných místech.

Vy jste si vymyslel teorii padlou na hlavu, že výjimka je chybový stav, a že je něco ultra jiného, než co tu bylo už dávno.

Pro efektivní řešení chyby nepotřebujete celý kontext prakticky nikdy. A těch několik málo proměnných, co byste mohl zužitkovat si dáte jako součást výjimky. Howgh.

Znovu: Je to programátor, který píše zdrojový kód. Výjimka a ošetření výjimky je něco, co také řídí programátor. Pokud není programátor idiot, tak výjimka má potřebné informace, tedy plný kontext už nikoho nezajímá.

Výjimky slouží k vypořádávání chybových stavů.

A už jste zase u té demagogie. Výjimky slouží k vypořádání jakýchkoli stavů, které vyžadují ošetření mimo hlavní proud programu. Ten stav nemusí být nutně chybovým.

Tedy ze stavu, který se před nimi řešil jako kterýkoli jiný, udělaly jakýsi privilegovaný stav, chybový, který se ošetřuje odlišně, dokonce nezávisle na kontextu. Zavádějí úplně novou, nezávislou mašinérii ve struktuře programu. Neříkám, že je to celé špatně. Ale říkám, že v té adoraci výjimek bych hodně brzdil.

Výjimky nezávádějí žádný privilegovaný stav. Jsou prostě jednou z cest, kudy může běžet program. Nic více a nic méně. Vaše tendence z výjimek dělat něco, co stojí úplně stranou ostatních konstrukcí programovacího jazyka je až fanatická. Výjimky jsou jednou z normálních konstrukcí jazyka.

Kromě toho dobře zvládnuté výjimky mohou být i levnější a efektivnější než testování návratových hodnot z podprogramů. Jestli si myslíte, že ty bazilióny podmínek k testování návratových hodnot po každém volání podprogramu jsou zadarmo a nezpomalují program, tak se strašně mýlíte. Výjimky umožňují tyto podmínky odstranit a tím program zrychlit, pokud budete dobře programovat.

Není náhodou, že ošetřování chyb výjimkami čím dál častěji používají i kernely operačních systémů. Je to totiž nejefektivnější možné řešení pro rozsáhlé možnosti chyb. Výjimky nemusí vůbec být objekty - viz třeba SEH (Structured Exception Handling) ve Windows (máte tam výjimky i v programovacím jazyce C), nebo třeba výjimky v programovacím jazyce Ada.

[Kit]

Podmínka mi kontext nenaruší - chybu zachytím a vypořádám tam, kde k ní došlo. Try-catch vyjde buď nastejno jakožto ukecanější varianta ifu, nebo mě hodí někam na jiné místo, mimo původní lexikální kontext, a to i v rámci jedné funkce! O šíření nezachycené výjimky vertikálně už nemluvím vůbec. Kontext, v němž chybový stav nastal, je pro jeho efektivní řešení dost důležitý. Naopak - funkce a bloky programu představují faktorizační celky, jejichž kontexty úmyslně oddělujeme. Ale předpokládám, že tady svou omezenost jen předstíráte.

Try-catch nevyjde nastejno. Je v pořádku, že mě výjimka hodí za příslušný catch, kde ji mohu ošetřit. Vše, co z původního kontextu potřebuji, je obsaženo v té výjimce.

Pokud výjimku nezachytím v rámci jedné metody, tak mají ještě jednu podstatnou výhodu: Nenaruší typ návratové hodnoty. Pokud nepoužiji výjimky, je tato situace prakticky neřešitelná a obchází se to ve stylu jazyka C - returnem se vrací pouze stav a návratová hodnota jde přes parametr předávaný odkazem. Když zapomenu zkontrolovat stav, program pokračuje dál s chybnými daty. Prostě hrůza.

Výjimky slouží k vypořádávání chybových stavů. Jistě by šly použít i jinak, asi bych mohl přes ně předávat návratové hodnoty, iterovat seznamy (někteří matláci to tak skutečně dělají! Nepatříte náhodou mezi ně?) a kdo ví, co ještě. Ale k tomu určeny nejsou. Tedy ze stavu, který se před nimi řešil jako kterýkoli jiný, udělaly jakýsi privilegovaný stav, chybový, který se ošetřuje odlišně, dokonce nezávisle na kontextu. Zavádějí úplně novou, nezávislou mašinérii ve struktuře programu. Neříkám, že je to celé špatně. Ale říkám, že v té adoraci výjimek bych hodně brzdil.

Pokud potřebuji vrátit hodnotu z iterovaného seznamu, používám standardně return. Pokud projdu celý seznam bez úspěchu a vyskočím tak z cyklu, vyhodím výjimku.

V těch článcích byly konkrétní příklady, podle Kita špatné. Tak postněte konkrétní dobrý příklad, jak se to má používat.

Správné použití výjimek při práci se zdroji bylo vysvětleno o kousek níže: try-with-resources a using/IDisposable.

[Miloslav Ponkrác]

Kdyby byl program bezchybný, tak by k nim vůbec nedošlo. Je to řešení ultima ratio, záchranná plachta, do níž se skočí, když už žádné schodiště nejde použít. Implementací do programovacích jazyků se z těchto "výjimek" udělalo pravidlo - zábradlí je přežitek, když někdo uklouzne na schodech, je dole plachta. Protože zábradlí přece narušuje elegantní estetiku schodiště, není kvůli němu ani pořádně vidět a přitom slouží "jenom" jako ochrana před nehodou.

Ale houby s octem. Vy žijete v utopickém světě. V reálném světě nastává mnoho chyb a zvláštních situací. Nemůže za ně pouze program, ale také chyby pocházejí z hardware, nebo ze vzdálené sítě, nebo do uživatele nebo z tisíci různých zdrojů.

Je chybou programu, že došla paměť k alokaci? Je chybou programu, že se odpálil tranzistor na základní desce a tudíž přestala fungovat nějaká funkce v hardware PC? Je chybou programu, že kopáč v Arménii překopl páteřní optický kabel a najednou se nespojíte s počítačem, který ještě před sekundou komunikoval? Je chybou programu, že uživatel natvrdo vyndal flešku z USB, ze které program čte data? Je chybou programu, že uživatel zmáčkl na klávesnici "P", ačkoli se čeká zadání čísla? Je chybou programu, že má číst data z databáze, která tam prostě nejsou?

***

Kromě toho ty obsese, že programátor nemá v programovacím jazyce dostávat do rukou něco, co může být při špatném použití nebezpečné - už jsou nudné. Od toho je to programátor, aby věděl co dělá. Aby se naučil každou konstrukci v jazyce používat správně.

Ze stejného důvodu už jsou trapní i javisté (o pár stránek nazpět), kteří si představují, že každý programovací jazyk má být kopie javy. A že přístup javy je jediný správný.

[Kit]

Ze stejného důvodu už jsou trapní i javisté (o pár stránek nazpět), kteří si představují, že každý programovací jazyk má být kopie javy. A že přístup javy je jediný správný.

To je zajímavé, protože třeba v XSLT jsem zatím na potřebu výjimek nenarazil, podobně jako v něm ani nepotřebuji else.

[Reklama]

[Miloslav Ponkrác]

To je zajímavé, protože třeba v XSLT jsem zatím na potřebu výjimek nenarazil, podobně jako v něm ani nepotřebuji else.

Já také ne, dokud jsem v XSLT nezačal psát video kodek, mp3 přehrávač, nebo komunikaci s STM32.  Pak už ta potřeba nastala

[Krysa11]

ja si myslim, ze jediny duvod proc je okolo GO vetsi povyk nez okolo brainfuck je ten, ze je mozne, ze do toho google nalije 100 miliard dolaru, protoze na to ma a to neco bude znamenat a nikdo nevi co.

 Za soucasnych okolnosti je to k nicemu. Na frontend a jednoduche projekty je tu JS, ktery je rychlejsi nez go spusti se i v interpretu webbrowseru, na slozite promyslene backendy je tu java (nebo C# pro MS golden kissass), ktera ma mnohem vyspelejsi a mocnejsi nastroje a je rychlejsi kvuli JIT a vubec experience, na specializovane nizkourovnove veci, kde je potrena pracovat primo s pameti a vyuziji se pointery je tu C/CPP a pro blbinky s gui python, ktery bude postupne vytlacovan JS.

[Krysa11]

a samozrejme se muze stat, ze nekdo napise nejakou solidni aplikaciv GO, protoze proste proto. Napriklad DoubleCommander je v pascalu a je to solidni aplikace, na kterou nedam dopustit. Ale taky je treba smeknout klobouk pred autorem, ze to tech vic nez 10 let vydrzel a udrzel.

Uvidime.

[Kiwi]

Buďme konkrétní - třeba program, co se uživatele postupně zeptá na název souboru, číslo řádku (n) a číslo slova (m) a z daného souboru zobrazí m-té slovo n-tého řádku. Je-li to možné, umožní uživateli opravu zadané hodnoty. Definované relevantní funkce: path = input_path() -> not_valid_path/init_error, i = input_num() -> not_a_number/init_error, file = open(path) -> cannot_open/init_error, line = read_line(file, i) -> error_reading_file/no_such_line/init_error, word = get_word(line, i) -> no_such_word/init_error.

Nebo jiný vhodný příklad. Znovu opakuji, že nejsem a priori proti výjimkám. Zabalení informace o chybovém stavu do objektu je perfektní, jednotné chybové rozhraní taky, ale ta separace místa vzniku od místa řešení mi prostě nevoní. A v praxi co vídám se mi nelíbí už vůbec - v jednom programu se něco řeší přes návratové hodnoty, něco zase přes výjimky, ošetření chyb končívá o několik pater výš zachycením výjimky "něco se stalo"... Opakuji asi potřetí, že v kritizovaných článcích byly konkrétní příklady kódu, jež označujete za chybné/nevhodné použití výjimek. Tak mi ukažte konkrétní, modelový kus kódu, který má řádně ošetřeny běžné chybové stavy (ne parity-error kvůli poškozené RAMce) pomocí výjimek. Jeden příklad je lepší než dlouhé teoretizování.

[Krysa11]

kiwi->

muzes ten kod vlozit nejak srozumitelneji?

[Miloslav Ponkrác]

ja si myslim, ze jediny duvod proc je okolo GO vetsi povyk nez okolo brainfuck je ten, ze je mozne, ze do toho google nalije 100 miliard dolaru, protoze na to ma a to neco bude znamenat a nikdo nevi co.

Bohužel souhlasím. Kolem Go je hype, protože Google. Právě Google je největší plus i mínus jazyka Go.

Mám vůbec dojem, že prezentované hlavní výhody Go jsou:

1) Je to od Google.

2) Je to open source.

A pak už je to jen krčení rameny. Není vůbec jasné, proč Go byl vydán. Kde by měla být jeho síla. Jaký je jeho předpokládaný scénář použití.

Za soucasnych okolnosti je to k nicemu. Na frontend a jednoduche projekty je tu JS, ktery je rychlejsi nez go spusti se i v interpretu webbrowseru, na slozite promyslene backendy je tu java (nebo C# pro MS golden kissass), ktera ma mnohem vyspelejsi a mocnejsi nastroje a je rychlejsi kvuli JIT a vubec experience, na specializovane nizkourovnove veci, kde je potrena pracovat primo s pameti a vyuziji se pointery je tu C/CPP a pro blbinky s gui python, ktery bude postupne vytlacovan JS.

Ne tak zhurta. Scénářů použití programů je mnohem více.

To, co se dnes řeší, a kde je díra na trhu, je programovací jazyk, který by levou zadní zvládal multithreading, paralelní programování, a masivní komunikaci mezi thready, procesy, sítí. Z vámi vyjmenovaných jazyků toto neumí rozumně ani jeden z nich. (Jak moc dobře to umí Go nevím, přiznám to bez mučení.)

Představte si, že dnes už na PC procesoru máte mnoho jader a threadů. S tendencí tento počet zvyšovat. Procesory mají obrovský potenciál výkonu, který dnešní programovací jazyky typu C, C++, JavaScript, Java, C#, Python (abych vyjmenovat vaše jazyky) nedokáží využít. Pokud o skutečné paralelní aplikace vedou k neskutečně neefektivnímu vývoji, který je asronomicky drahý, a přitom velice náchylný na chyby. Jakmile se objeví kvalitní paralelní jazyk - a to je jen otázkou času - tak to převálcuje všechno jako buldozer.

Paralelitu přitom nejde, má-li to být efektivní a nenáchylné k chybám, našít do jazyka jako knihovnu. Musí to být přímo součástí jazyka. Dosud byl trend blbných programovacích jazyků umějících co nejméně, a vše ostatní se našije knihovnami. Extrémem v retardovanosti a slunci tohoto trendu bylo C a Java. To je ale teď úzkým hrdlem.

Jinak řečeno, hardware, procesory, elektornika je tak o 20-30 let napřed před vývojem programovacích jazyků. Je tu velice mnoho prostoru pro nový jazyk.

[Miloslav Ponkrác]

Znovu opakuji, že nejsem a priori proti výjimkám. Zabalení informace o chybovém stavu do objektu je perfektní, jednotné chybové rozhraní taky, ale ta separace místa vzniku od místa řešení mi prostě nevoní. A v praxi co vídám se mi nelíbí už vůbec - v jednom programu se něco řeší přes návratové hodnoty, něco zase přes výjimky, ošetření chyb končívá o několik pater výš zachycením výjimky "něco se stalo"... Opakuji asi potřetí, že v kritizovaných článcích byly konkrétní příklady kódu, jež označujete za chybné/nevhodné použití výjimek. Tak mi ukažte konkrétní, modelový kus kódu, který má řádně ošetřeny běžné chybové stavy (ne parity-error kvůli poškozené RAMce) pomocí výjimek. Jeden příklad je lepší než dlouhé teoretizování.

Výjimky nejsou nutně objektové. V řadě jazyků jsou výjimku neobjektové.

Separace místa řešení od vzniku existovalo dříve, než byl stvořen první programovací jazyk. Jakmile bylo poprvé vynalezeno přerušení programu, měl jste přesně tuto věc na stole.

Přehlednost programu, tedy i ošetřování chyb pomocí libovolné metody, nemá smysl ukazovat na pár řádcích. Úhelným kamenem, kde se oddělují zrna od plev, jsou středně velké a velké programy. Řekněme od 30 000 řádků kódu výše, a ideální ve více vývojářích, plus nutnost kód udržovat po řadu let a implementovat nové vlastnosti podle přání zákazníků.

Mám teorii, že programátor je hochštaplerem přesně do doby, než mu spadne na hlavu projekt s alespoň 100 000 řádky, kterému se pak musí 2 roky věnovat, a všechny problémy padají na jeho hlavu. Do té doby jednoduše nikoho nepřesvědčíte, že programování není o tom napsat hello world nebo něco kapánek složitějšího. Celé softwarové inženýrství je o udržitelnosti, testovatelnosti, spolehlivosti a rozumně nízkých nákladech vývoje u praktických projektů, nikoli modelových příkladů. Kdo psal jen kraťoučké programy, které nebyly prověřeny drsnou praxí - ten si může dovolit i "levičácké názory", tedy různá dogmata a pózy, které nejsou prověřeny pořádným hurikánem.

[Krysa11]

Ne tak zhurta. Scénářů použití programů je mnohem více.

To, co se dnes řeší, a kde je díra na trhu, je programovací jazyk, který by levou zadní zvládal multithreading, paralelní programování, a masivní komunikaci mezi thready, procesy, sítí.

prej ne tak zhurta a hned na to takova bomba

 je docela mozne, ze levou zadni zvladat "multithreading, paralelní programování, a masivní komunikaci mezi thready" tak moc nejde, neodpustim si, ze presne na tohle se pouziva Java. Ono je to tak nejak by default slozite. Neco jako "chtel bych system rizeni spolecnosti, kde muze kazdy blb ridit oddeleni o 50-ti lidech levou zadni". Ja bych to chtel taky, ne, ze ne. Zastavam nazor, ze vytvorenim noveho jazyka se tato vize neuskutecni. Mozna se mylim.

[Miloslav Ponkrác]

je docela mozne, ze levou zadni zvladat "multithreading, paralelní programování, a masivní komunikaci mezi thready" tak moc nejde, neodpustim si, ze presne na tohle se pouziva Java. Ono je to tak nejak by default slozite. Neco jako "chtel bych system rizeni spolecnosti, kde muze kazdy blb ridit oddeleni o 50-ti lidech levou zadni". Ja bych to chtel taky, ne, ze ne. Zastavam nazor, ze vytvorenim noveho jazyka se tato vize neuskutecni. Mozna se mylim.

Paralelní programování je by default složité. A proto se nedá efektivně (všimněte si slova efektivně) dělat na jazycích, které mají koncept jako java nebo c nebo ...

Paralelní jazyky existují už dlouhou řadu let a pár jsem jich viděl.

Můžete napsat paralelní program tak, že vezmete běžný prací prášek programovací jazyk. A pak si poctivě používáte z nějaké knihovny atomické proměnné, mutexy, sdílené proměnné, semafory, události, atd. atd. atd. Celé to děláte v podstatě ručně - a kompilátor to ani nezkontroluje. To je případ Javy/C/C++/Pythonu/JavaScriptu, atd. atd. atd.

Paralelní programovací jazyky mají především programové konstrukce podporující paralelismus. Kompilátor tak dostává informaci přímo ze zdrojového kódu, co vlastně paralelně kutíte. Můžete to zkontrolovat, optimalizovat, oprostit vás od práce pro vraha zvané "synchronizujeme pomocí low level objektů z knihovny". Analýzou zjistí, kde lze synchronizaci vypustit, protože ke konfliktu nedojde, nebo to zkompiluje tak, aby se konfliktu vyhl - a tak drasticky zvýší výkon.

Paralelní programovací jazyk sám hledá místa, kde lze paralelizovat. Je jich plno. Například ve složitějších cyklech lze v řadě případů provést iterace paralelně. Několik volání podprogramů lze také paralelizovat, pokud na sobě nezávisejí. Atd. atd. atd.

Paralelní programování je by default složité. A pokud programovací jazyk je by default single thread a pak na to více méně dlabe, je to práce pro vraha. Řadu věcí lze přenést na kompilátor.

[Krysa11]

prave jste velice hezky popsal JIT optimalizaci JVM u dlouhodobe beziciho procesu.