Komentáře k článku

Remcání proti Javě

Po 3⁄4 roce práce v Golangu jsem se vrátil na chvíli k Javě. Doufám, že jen dočasně. Protože, když člověk na dostatečně dlouhý čas vypadne z prostředí, kde dlouhodobě pobýval, a vrátí se zpět, najednou mu dojde, jak jsou některé věci obskurní. A jak některé věci, které byly vymyšleny s nejlepšími úmysly pomáhat, ve skutečnosti práci zatemňují a ztěžují. Je to, jako když žijete v prasečáku a už si pak neuvědomujete, že prasata smrdí.

Zpět na článek

24 komentářů k článku Remcání proti Javě:

  1. Vít Heřman

    Tak jen tiše závidím možnost pracovat v Golang. Jako hračku jsem si ho již před časem také naučil a teď jsem přidal F#. A najednou člověk posuzuje všechny ty OOP patterny a frameworky úplně z jiné perspektivy. Jakoby jejich zásadním účelem bylo zamotat lidem hlavy a spoustu věcí zamlžit a zesložitit. Takže jsem rád, že neremcám sám :-)

  2. tmysik

    Škoda, že...
    …autor nepřidal aspoň minimální ochutnávku toho, jak je to v Go jinak/lepší. Jasně, můžu si to zkusit najít, ale tohle mi v článku tak nějak chybí (spolu s případným komentářem autora).

    1. Vít KotačkaAutor příspěvku

      Re: Škoda, že...
      Není to úplně ekvivalent toho, jak dělat věci v Golangu, ale v tom článku, který odkazuje @Martin jsem shrnul některé aspekty Java-Golang rozdílů.

  3. Tobiáš Potoček

    Lze psát stejný kód v Javě jako v Golang?
    Se zájmem jsem si přečetl tento článek, i související článek na autorově blogu. Přijde mi, že výtky se netýkají jazyka takového, ale spíše prostředí, nástrojů a návyků, které časem vznikly kolem. Tedy toho, jak tak nějak realisticky vypadá vývoj v Javě.

    Musí ale tak vypadat? Nikdo nás přeci nenutí nadužívat objektovost Javy a vytvářet spoustu vrstev, když to nemá praktický význam. Není možné v Javě psát prakticky ten samý kód jako v Golang? Chybějící funkcionalita se dá dodat malými knihovnami a co zbude je syntaktický cukřík. Je v tom ten rozdíl, které vede k dlouhodobě kvalitnějšímu kódu a souvisejícímu ekosystému?

    Mám např. dojem (nicméně přiznávám, že konkrétní zkušenosti s Golang nemám), že oba jazyky řeší error handling koncepčně velmi podobně. Golangovské panic odpovídá unchecked výjimkám, druhá vracená hodnota obsahující chybový status zase chedked výjimkám (jsou i součástí method signature). Rozdíl je skutečně pouze v syntaxi, jakou jazyk daný problém řeší. Dovedu si představit, že golangovský přístup je explicitnější (panika…) a tedy spíše povede programátory k dobrým návykům, na tu druhou stranu, javovský způsobem mi osobně přijde pohodlnější.

    1. Vít Heřman

      Re: Lze psát stejný kód v Javě jako v Golang?
      Autoři Golang by se asi bránili přirovnání výjimkám v Javě. Myslím, že hlavním jejich argumentem proti výjimkám je jejich podstata nestrukturovaného skoku (podobně jako goto). Error handling je proto realizován pomocí obyčejných návratových hodnot, což se liší od checked výjimek ve dvou věcech: a) nedochází ke skoku na stacku b) ošetření není vynucováno. S tím přirovnáním panic bych pak asi souhlasil.

      Jinak mám zkušenost, že podoba jazyka předurčuje, jak vypadají frameworky a ekosystém. Ale když píšete, že Vás nikdo nenutí, tak je to spíše o tom, kde pracujete a zda máte štěstí na projekty, kde Vás nikdo nenutí. Protože až příliš často nutí. Třeba přebíráte práci po někom jiném, firemní standardy, atd. Já mám pocit, že mne všude nutí přizpůsobovat se velkým frameworkům a patternům, přestože vím, že sám dokážu dosáhnout výsledku efektivnějším způsobem a dodat řešení lepší kvality

      1. balki

        Re: Lze psát stejný kód v Javě jako v Golang?
        jinak mám zkušenost, že podoba jazyka předurčuje, jak vypadají frameworky a ekosystém

        Nemal by mat scheme (lisp) potom najlepsi ekosystem na svete? Bude este programovanie v golang take sexi, ked sa nan nalepia 3 dekady balastu? C je tiez este stale tak sexi, ako bolo na zaciatku?

        To boli recnicke otazky, prosim nedpovedajte.

        1. Vít KotačkaAutor příspěvku

          Re: Lze psát stejný kód v Javě jako v Golang?
          Stejně na to odpovím. 😉

          Nevím, jak Lisp, nebo Scheme, ale Clojure je přesně ten případ, kdy ač JVM záležitost, tak ekosystém je podobný, jako u Golang a zároveň neztrácí pozitivní aspekty Javy.

        1. Vít Heřman

          Re: Lze psát stejný kód v Javě jako v Golang?
          Přečetl jsem pozorně, důvody vysvětluje skvěle. Teoretická námitka by mohla spočívat jen v tom, že při neošetření návratové hodnoty může program pokračovat dále, avšak s chybnými daty. Avšak ošetření chyb je tak geniálně jemným způsobem vynuceno tím, že kompilátor a) vynutí přiřadit si obě návratové hodnoty b) nenechat ani jednu z nich nevyužitou. Obojí založeno na principu, že deklarovaná a nepoužitá hodnota je chyba. Lze jemně potlačit pomocí _. Tomu říkám elegance.

          1. Tobiáš Potoček

            Re: Lze psát stejný kód v Javě jako v Golang?
            Hmmm články podobného typu nemám moc rád, protože už ten samotný název, Why Go gets exceptions right, se snaží tak trochu navodit dojem, že tady existuje jakýsi jednoznačně nadřazený způsob a že s ním přišlo Go. Že realita je trochu někde jinde dokazuje už ten samotný článek svým průřezem historií. Jazyk C (kterým článek začíná) a jazyk Go (kterým článek končí) řeší signalizování chyby velmi podobně, tedy skrz více návratových hodnot, jen jeden k tomu „zneužívá“ pointery a druhý má pro to nativní podporu. Jinými slovy, skončili jsme tam, kde jsme začali, jen s jemným iterativním zlepšením. Nedivil bych se, kdybychom za rok četli článek Why XYZ gets exceptions right, a základní premisou bude jemná iterace nad javovskými výjimkami :)

            Když už mluvíme o těch javovských výjimkách, tak článek zmiňuje dva základní problémy, které je nutno napravit:

            1. Výjimky už nejsou používány výjimečně
            2. Výjimky potenciálně vedou k zhůvěřilostem typu catch (e Exception) { // ignore }

            U toho prvního bodu mi není jasné, zda je to myšleno ryze akademicky / principiálně, či jsou tam nějaké skutečně praktické důsledky, např. ve výkonu či v dlouhodobé (ne)kvalitě produkovaného kódu. Signalizovat chybu nicméně není nijak výjimečná situace a výjimky jsou z mnoha pohledů elegantní způsob, tak proč bychom ho neměli používat? Obecně mám pocit (což se týká i toho druhého bodu), že ač dobrý návrh jazyka by samozřejmě měl sám o sobě vést ke kvalitnímu kódu a správným návykům, tak by to neměl dělat příliš na úkor pohodlí. Máme přeci k dispozici i jiné nástroje (best practices, conventions, code review…), jak se vyhnout zhůvěřilostem.

            V jednom komentáři výše je zmíněno, že ošetření výjimek není vynucováno. To u checked výjimek (které koncepčně odpovídají vraceným chybám v Go) není tak úplně pravda. Kompilátor vás donutí daný kód buď obalit try-catch blokem (pokud chybu můžete ošetřit na daném místě) či aspoň deklarovat výjimku pomocí throws v signatuře metody („probublání“ chyby). Ono „probublání“ ukazuje ten rozdíl mezi Go a Javou. Občas prostě „probublání“ je jediná věc, co se v daném místě kódu dá dělat, a Go vás v takovém případě donutí napsat 3 řádky boilerplate kódu. Java ne (to je to pohodlí). Neodvážím se tvrdit, který přístup je lepší, ale osobně preferuji Javu.

    2. Vít KotačkaAutor příspěvku

      Re: Lze psát stejný kód v Javě jako v Golang?
      Ano, ty výtky se netýkají jazyka jako takového, ale jeho ekosystému. Na druhou stranu, jazyk samotný neexistuje ve vacuu a nejde ho jednoduše oddělit od těch dalších vrstev, které ho obalují. Už dlouho dobu to vidím jako: language ➡️ frameworks ➡️ platform ➡️ landscape.

      Když někdo začne psát nový projekt/produkt/cokoli „v Javě„, tak nezačíná from-the-scratch, ale použije nějaké existující bloky, v Javě typicky frameworky. Plus se k tomu nabaluje, co je ve firmě k dispozici, co znají a mají tendenci používat lidi, co na tom budou pracovat, na co jsou zvyklí/mají k dispozici Ops/DevOps atd.

      1. Tobiáš Potoček

        Re: Lze psát stejný kód v Javě jako v Golang?
        Vyjdu-li z Vašeho language ➡️ frameworks ➡️ platform ➡️ landscape, tak Vy jste v podstatě celý řetězec vyresetoval a nahradil už jeho první článek, tj. jazyk. Nicméně Váš článek se vyhrazuje pouze vůči těm následujícím tří článkům. Takže svým způsobem je takový krok nesmyslný :) Nebylo by logičtější ponechat si to, co funguje a znám (jazyk), a nahradit ten pouze ten zbytek? Nebo to prakticky není možné, tj. všechny existující frameworks v Javě jsou poznamenané? A vyplývá tato poznamemanost z podstaty jazyka? Nebo by bylo možné si sednout a napsat nějakou Go-like knihovnu pro Javu?

        Omlouvám se, že Vás tlačím tímto směrem, ale tyto otázky mi přijdou skutečně zajímavé :)

        1. Vít KotačkaAutor příspěvku

          Re: Lze psát stejný kód v Javě jako v Golang?
          Ty otázky se mi líbí. 😀 A vlastně, podobné věci zazněly už u původního článku v diskuzi na Twitteru. Odpověď by byla filozoficky obšírná, nicméně v krátkosti:

          Ano, určitě by šlo vyjít jenom z jazyka a ty následující slupky (počínaje frameworky) nepoužívat. Kdybych to udělal u Javy, tak vlastně „klesnu“ na úroveň Golangu, kdy budu (re)implementovat poměrně nízkoúrovňové věci (a možná skončím u nějaké DIY sady knihoven, protože (Java) komunita tímhle způsobem nepracuje). Pak je otázka, proč bych takový jazyk volil – myslím, že jazyky v rámci obdobného paradigmatu jsou zaměnitelné – co mi daný jazyk nabídne, kromě sebe sama? 🤔

          Ta souslednost těch „slupek“ (language ➡️ landscape) je pro mne v realitě neoddělitelná. Ale možná je to daný jenom mým kontextem, řekněme technical leadera – kromě programování jsem, stavěl architekturu i najímal lidi do týmu a dělal business analýzu se zákazníkem. Možná, že někdo, kdo třeba celý život jen programoval, by to tak nedělitelně neviděl. (I když, moje zkušenost je, že programátoři žijí ve velmi silných bublinách. 😂)

          1. Tobiáš Potoček

            Re: Lze psát stejný kód v Javě jako v Golang?
            Tak i čistý jazyk má svá specifika, ať už jde o samotný syntax, související naming conventions, sada základních struktur a funkcí či signalizování chyb, viz diskuze výše o výjimkách :) Já osobně mám třeba Javu velmi rád (jednoduše mi sedne) a to i z důvodů, které jsou často předmětem kritiky (třeba ukecanost Javy je něco, co mi snadno umožňuje číst cizí kód). Takže v praxi budu mít vždy tendenci spíše napravovat chyby v těch nadstavbových slupkách, než vyresetovat celý stack :)

            Nicméně toto je možná dáno i tím, že v mém současném zaměstnání (korporát) se na serveru používá z velké částí custom Java stack (proto ty slupky vnímám jako oddělitelné), který v kombinaci s ustáleným (a rozsáhlým) seznamem konvencí a best practices prakticky eliminuje většinu zmiňovaných problémů. V jiném prostředí bych možná „trpěl“ podobně a radoval se z přechodu na Go, protože by to byla cesta nejmenšího odporu, jak z toho ven :)

    3. atamiri

      Re: Lze psát stejný kód v Javě jako v Golang?
      Stejný kód asi ne, v Go se píše jinak kvůli odlišnému runtimu, zejména gorutinám, například veškerá síťová komunikace je asynchronní (NIO), což se zrcadlí i ve standardní knihovně. Dalším problémem je pak nutnost mít JRE, kdežto Go produkuje vesměs statické binárky.

  4. Oldisy3

    To je tak když se jazyk používá k něčemu k čemu se nehodí. Stejný dojem sem získal když sem v c++, vlastně borland c++. taky sme v tom dělali něco na co se to absolutně nehodilo, ono to šlo ale to jen proto že to bylo dohnané 100MB knihoven částečně v delphi.

  5. Richard Šindler

    Problém javy je jak se se s ní pracuje. Zeptejte se javistu, jakou zvolí architekturu pro projekt Baf. Ještě dřív než se bude zajímat o to, co vlastně má Baf dělat, oznámí, že tam bude Spring a Hibernate. Možná, kdyby do javy přidali funkce dřív, než anotace, mohlo být všechno jinak.

    1. Balki

      Re:
      To skor nadriadeny javistu (obvykle zaprdeny fortranista, ktory si precital aka je java skvela) prijde ze ma skvely projekt Baf a bude to webservis, ktory bezi nad vsetkymi databazami, na vsetkych prostrediach, musi mat embednute jetty a uvari to kavu. Developer potom zisti, ze by im stacila command lineova appka, alebo nieco hotove a je z toho smutny.

  6. oldjay

    Tak opravdu jenom hádám
    ten první příklad – opravdu nevím co autora nutí dělat dvě prakticky identické třídy. hádám, že ty rozdílné anotace.
    To ale v normálních frameworks není potřeba. Klidně používám anotace pro eclipselink (ORM) a jersey (REST) společně v jedné třídě.

    1. Vít KotačkaAutor příspěvku

      Re: Tak opravdu jenom hádám
      Důvod, proč mít dvě identické třídy může být dvojí:

      1) Jedna třída (výjimečně i obě) můžou být generované. Typický use case: REST model generovaný ze Swaggeru a persistentní entity napsané ručně. Pokud si nechci psát vlastní post-processing (nebo mít jen jednorázové generování), tak se dvěma třídám nevyhnu.

      2) Pokud jsou instance jedné třídy (nebo opět i obou) managed, tj. mají nějaký container-based-lifecycle, typicky v ORM, ale třeba i v nějaké komplexnější business logice. Potom re-use fully managed, případně kombinovaný manual+managed, entit je osvědčeným receptem na memory leaky. Připočtěme k tomu ještě deployment v clusteru a můžeme se těšit na rollback na produkci 😈 (true story).

      A přidám k tomu ještě jeden důvod – Java frameworky/knihovny jsou povětšinou neschopny pracovat s immutable objekty a kolekcemi, takže šoupat data z modelu do modelu je relativně bezpečný způsob, jak se vyhnout budoucím, těžko detekovatelným, nebo dlouho neobjeveným problémům.

      Samozřejmě, bavíme se o real-world záležitostech – pokud si mastím nějaké PoC, nebo smažím jednu instanci Tomcatu/Jetty, tak to asi nebude takový problém.

  7. Mlocik97

    Díky za článek
    Skvelý článok, plne súhlasím… jedine co mi přijde na golangu horší než v jave je praca s enum.

    1. Vít KotačkaAutor příspěvku

      Re: Díky za článek
      To je pravda – Golang enumy (pomocí iota) vlastně nejsou enumy, jen taková náhražka.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=22708