Doporučte programovací jazyk pro Windows

[qelurg]

Zdá se, že reimplementace těchto pár řádků Python kódu v Javě je nad síly kritika Pythonu. Můžeme jen hádat na čem všem se zasekal :-). Budiž to ponaučením pro budoucí posměváčky.

Ne panove, to je zkratka moje prohlednuti, ze vy tu vubec nemate tuseni o cem to melete.
Pisu tady, ze signatura java metody je vcetne parametru metody a vrati se mi dotaz, jak bych asi tu python zpatlaninu udelal v Jave.

Neblábol Stando, už i ty jsi pochopil v čem a proč je Java špatná. Nenašel jsi odvahu sem dát implementaci něčeho, co je Javě vlastní (přetěžování) a pro Python je to škrábání se na krku přes hlavu. I tak to má Python stručnější a přehlednější. Pokud nesouhlasíš, hoď sem ukázku.

Budiz, mejme dva typy: A a inherited B

...

Toto jsou naproste zaklady javy, uplne mi nebere hlava, proc maj potrebu se hadat o kvalite jazyka lidi, co o nem vi kulantne receno mene nez optimum.

Dobry Stando, něco jsi se možná naučil. Teď dodej v Jave implementaci toho Python programu, co jsi ho sem pastnul jako důkaz  nepřehlednosti. Neboj, smát se budem jenom trochu.

[Reklama]

[Standa Blábol]

Na Javě je zajímavé jen to JVM. Proto pro JVM vzniká tolik jazyků, je tu ohromující snaha se jazyku Java vyhnout. https://en.m.wikipedia.org/wiki/List_of_JVM_languages

Alternativní jvm jazyky hlavně svědčí o kvalitách celého ekosystému a flexibilitě javové platformy. Dále o kvalitách samotné vm. Komu přestane vyhovovat java, ten přesedlá na příbuzný ale progresivnější jazyk a může pokračovat ve stejném projektu prakticky bez překážek. Tím pádem i to haterství tím anebo druhým směrem přestává celkově dávat smysl, protože vzniká synergie.

Osobne se mi libil Ceylon. https://ceylon-lang.org/
Takove zmeny si Java z duvodu kompatibility dovolit nemuze.
Ale zdechlo to, Redat se na to vykvak v roce 2017 a od te doby nic.

[Standa Blábol]

Zdá se, že reimplementace těchto pár řádků Python kódu v Javě je nad síly kritika Pythonu. Můžeme jen hádat na čem všem se zasekal :-). Budiž to ponaučením pro budoucí posměváčky.

Ne panove, to je zkratka moje prohlednuti, ze vy tu vubec nemate tuseni o cem to melete.
Pisu tady, ze signatura java metody je vcetne parametru metody a vrati se mi dotaz, jak bych asi tu python zpatlaninu udelal v Jave.

Neblábol Stando, už i ty jsi pochopil v čem a proč je Java špatná. Nenašel jsi odvahu sem dát implementaci něčeho, co je Javě vlastní (přetěžování) a pro Python je to škrábání se na krku přes hlavu. I tak to má Python stručnější a přehlednější. Pokud nesouhlasíš, hoď sem ukázku.

Budiz, mejme dva typy: A a inherited B

...

Toto jsou naproste zaklady javy, uplne mi nebere hlava, proc maj potrebu se hadat o kvalite jazyka lidi, co o nem vi kulantne receno mene nez optimum.

Dobry Stando, něco jsi se možná naučil. Teď dodej v Jave implementaci toho Python programu, co jsi ho sem pastnul jako důkaz  nepřehlednosti. Neboj, smát se budem jenom trochu.

Mno, co se tyce method overloadu, priklad jsem tak trochu poslal, pokud te zmatlo, ze jsem jinak pojmenoval typy, zkus to zvladnout.
Pak uz je tam jenom foreach cyklus nad polem netypovanych objektu, tak tady mam 2 varianty:

- bud jak tatar to udelam stejne prasecky jako pole Objectu a ve vlastni metode budu pomoci instanceof a getClass() jak u blbejch zjistovat o jaky typ se realne jedna a podle toho budu renderovat. A az budu chtit pridat podporu dalsiho typu objektu k renderovani, pridam do dipatch metody dalsi if - prevelika krasa.

- nebo, jak bych to udelal ja, definuju si Interface, ktere pro vsechny objekty vynutim metodu getRenderData(), ktera mi pripravi data pro jednu obecnou metodu render(). Mimochodem koncept GDI z windows 3.1, mozna este driv.
- pak do foreach cyklu naleju objekty handlovane pres interface. Kdyz budu chtit pridat dalsi typ objektu k renderovani, proste ho necham implementovat interface a voila! - Umime renderovat dalsi objekt. A nikdo nemusi sahat do myho kodu, berou to jako knihovnu a ani k tomu zdrojaky nemaji. A nikdo mi tam nepodrstrci neco, co skonci zpravou "Unknown render type"

Psat ti to tady jako exampl s dummy daty fakt nebudu, pokud tomu nerozumis, zeptej se nekoho chytrejsiho.

[qelurg]

Zdá se, že reimplementace těchto pár řádků Python kódu v Javě je nad síly kritika Pythonu. Můžeme jen hádat na čem všem se zasekal :-). Budiž to ponaučením pro budoucí posměváčky.

Ne panove, to je zkratka moje prohlednuti, ze vy tu vubec nemate tuseni o cem to melete.
Pisu tady, ze signatura java metody je vcetne parametru metody a vrati se mi dotaz, jak bych asi tu python zpatlaninu udelal v Jave.

Neblábol Stando, už i ty jsi pochopil v čem a proč je Java špatná. Nenašel jsi odvahu sem dát implementaci něčeho, co je Javě vlastní (přetěžování) a pro Python je to škrábání se na krku přes hlavu. I tak to má Python stručnější a přehlednější. Pokud nesouhlasíš, hoď sem ukázku.

Budiz, mejme dva typy: A a inherited B

...

Toto jsou naproste zaklady javy, uplne mi nebere hlava, proc maj potrebu se hadat o kvalite jazyka lidi, co o nem vi kulantne receno mene nez optimum.

Dobry Stando, něco jsi se možná naučil. Teď dodej v Jave implementaci toho Python programu, co jsi ho sem pastnul jako důkaz  nepřehlednosti. Neboj, smát se budem jenom trochu.

Mno, co se tyce method overloadu, priklad jsem tak trochu poslal, pokud te zmatlo, ze jsem jinak pojmenoval typy, zkus to zvladnout.

Podívej Stando, to jsou bláboly. Smál jsi se pěknému přehlednému a srozumitelnému  Python programu ve věci, která ani není nativní vlastností toho jazyka. Můžeš předvést jak si s tím poradí Java, u které to je nativní vlastnost, tudíž by to měla zvládnout lépe nebo aspoň stejně. Ano, Java je hnusný těžkopádný jazyk, takže to nezvládne, to víme oba, teď jde jenom o to, jestli to přiznáš nebo ne. Čím víc to budeš rozpatlávat abys to zakamufloval, tím víc to bude smrdět. Takže hoď sem Java implementaci kraťoučkého Python programu, co jsi sem sám napastoval a nebo jsi porazil sám sebe svými vlastními hloupými ukázkami. :-)

[Ondrej Nemecek]

No a co? Způsob jak se technologicky řeší to a ono v daném jazyce je podružné. Z toho, že Java nepotřebuje dekorátory či knihovny (protože si to tahá přímo "v základu" = v přibalené knihovně) na určité věci, narozdíl od Pythonu je jen ukázka dvou různých řešení téhož a nevypovídá to nic o tom, že automaticky řešení v Javě je lepší, jak to tady nastavujete v téhle diskuzi manipulativně vy.

No ona si to java netahá v přibalené knihovně, je to vlastnost jazyka jako takového.

Samozřejmě o charakteru jazyka hodně vypovídá, co je zahrnuto do jazyka, co do standardní knihovny a co je ponecháno na externích nástrojích. Nutně to ale neznamená, že je něco lepší než druhé.

Ano, plny souhlas.
Ze je neco zadratovane v jazyce nebo stdlib este neznamena, ze je to dobre.
Treba legacy Java logging, nebo stary zadratovany JAX-WS ve spoupraci s pribalenym wsimport, co podporuje nahodne vybrane featury WS-SOAP standardu - je na streleni se do hlavy. A tak kazdy mavenem bunluje SJLF a Apache CXF.

Kdzy se vratime k puvodnimu examplu, tady je vide rozdil filosofie Python vs. Java asi nejlip.

Kód: [Vybrat]

@singledispatch
def render(s, **kwargs):
  print('Rendering an unknown type')

@render.register(S_Block)
def _(s, **kwargs):
  print('Rendering an S_Block')

@render.register(S_Empty)
def _(s, **kwargs):
  print('Rendering an S_Empty')

Potom indicky spoluprqcovnik vezme nas kod jako knihovnu, prida si novy typ S_Vindaloo, a tak nejak zapomene maimplementovat vsechny potrebne metody ktere ja v ramci ducktypingu ocekavam, proste uplne chybi a tento se zavola vzdy v utery a dubnu

Holy python bez typehintingu: program rok bezi a pak cely zbuchne v utery v dubnu

Python s @singledispatch" program rok bezi a pak v utery v dubnu vypise hlasku 'Rendering an unknown type' pricemz neprovede ocekavane. Indicky kolega musi hrabat do meho kodu, aby zacal podporovat S_Vindaloo.

Java (C#, C++): vubec to nejde zkompilovat, coz indickeho kolegu donuti, aby S_Vindaloo splnovalo potrebne interface, pak vsecko funguje.

Slozitejsi program, kde kooperuje vic lidi + dynamicke typovani => pain.

Proto má třeba Smalltalk dynamic dispatch a současně protokoly. Což řeší oba požadavky.

[Reklama]

[Ondrej Nemecek]

Podívej Stando, to jsou bláboly. Smál jsi se pěknému přehlednému a srozumitelnému  Python programu ve věci, která ani není nativní vlastností toho jazyka. Můžeš předvést jak si s tím poradí Java, u které to je nativní vlastnost, tudíž by to měla zvládnout lépe nebo aspoň stejně. Ano, Java je hnusný těžkopádný jazyk, takže to nezvládne, to víme oba, teď jde jenom o to, jestli to přiznáš nebo ne. Čím víc to budeš rozpatlávat abys to zakamufloval, tím víc to bude smrdět. Takže hoď sem Java implementaci kraťoučkého Python programu, co jsi sem sám napastoval a nebo jsi porazil sám sebe svými vlastními hloupými ukázkami. :-)

Jak to?? Podle mě ten java kód už poslal. Ale férovější by bylo popsat, co ten Python kód přesně dělá a pak řešit, zda a jak se to dá realizovat v jiném jazyku.

[registrovany_ava]

Proto má třeba Smalltalk dynamic dispatch a současně protokoly. Což řeší oba požadavky.

Protokoly ve Smalltalku neřeší vcelku nic, je to jen kategorizace selektorů (metod), nic nevynucují (což je trošku škoda).

Dynamic dispatch má i Java, Python, prakticky každý OOP jazyk, to není žádná specialita Smalltalku.

[Google CTCCTCGGCGGGCACGTAG]

Proto má třeba Smalltalk dynamic dispatch a současně protokoly. Což řeší oba požadavky.

protokoly resi jiny problem nez pretezovani funkci.

Python ma mnohem mocnejsi nastroje pro staticky typovane signatury nez java. Namatkou treba Literal types. Muzete napsat funkci, kde navratovy typ zavisi na hodnote vstupnich parametru. https://mypy.readthedocs.io/en/stable/literal_types.html

Protokoly python take ma, jak staticky tak dynamicky vynucovane, https://mypy.readthedocs.io/en/stable/protocols.html

Ja chapu, ze prilezitostni uzivatele Pythonu jako Standa Blabol novinky moc nesleduji. Uvadim jen pro informaci, nechci zacinat dalsi spor.

[redustin]

Java (C#, C++): vubec to nejde zkompilovat, coz indickeho kolegu donuti, aby S_Vindaloo splnovalo potrebne interface, pak vsecko funguje.

Indický kolega samozřejmě nepíše javu ve vimu, takže na dvě kliknutí řekne IDE, aby mu vygenerovalo předpisy metod, které má z generického řešení implementovat, již s jejich konkrétními datovými typy. Pak jen dopíše těch pár řádků, kterými se jeho konkrétní implementace odlišuje v rámci generického designu. A je úplně jedno, že se mu při tom na úvod automaticky přidalo deset importů a že výsledná třída má 50 řádek, když on napsal řádky čtyři. Není blázen, aby scrolloval zdrojákem, když od toho má navigaci mezi voláními, skoky na definice/deklarace. Je celkem jedno, jak dlouhé jsou typy parametrů metod či proměnných, když nic z toho nikdy nenapíše, protože to IDE vytvoří rovnou za něj a vždy správně , má to jen jednu variantu (příp. si zvolí, kterého vhodného předka/úroveň zobecnění chce použít).  Kolega jen píše příkaz a pak zadá název proměnné, pokud se mu žádný z nabízených názvů nelíbí (obvykle hned ten první je logický a správný).

Inkrementálně označí funkční blok klávesovou zkratkou a na jednu kombinaci nechá IDE vygenerovat metodu se všemi parametry - má garantované, že taková operace bude vždy fungovat správně. Jen si třeba triviálně změní pořadí parametrů, aby to sedělo zavedené štábní kultuře projektu. Nemusí se obávat, že by se změna neprovedla v jakékoliv volání metody, i kdyby to bylo ve sto různých třídách, je to úplně jedno. A bude se pokud možno vyhýbat více parametrům stejného typu vedle sebe, právě aby se vyhnul chybě přehození parametrů stejného typu, až tu metodu bude volat na jiném místě ručně. Až bude java umět hodnotové typy (projekt valhalla), bude šance podstatně menší, protože i základní typy bude mít označený jejich významem a nebude je možné míchat.

A nebo bude používat args a kwargs a šedivět, co se zase kde rozsypalo. Ba ne, nebude, to to raději nechá načuněné ve špagetě (protože první verze kódu není nikdy optimální) nebo s nesmyslným názvem (protože se během psaní metody význam té proměnné trochu změnil, opět zcela normální). A kdo  říká, že takové změny ve svém kódu (obzvláště prvních verzích) provádět nepotřebuje, buď nic většího neprogramuje, nebo produkuje čuňárny. To mi nikdo nevymluví, viděl jsem to mnohokrát.

Můj názor na python ve velkých firmách je takový, že začali ve startupu v malém, logicky v pythonu a pak už neměli prostor to přepsat do něčeho, co jim v projektu dokáže udržet pořádek. Proto třeba mypy pochází z dropboxu https://blogs.dropbox.com/tech/tag/mypy/

===
At our scale—millions of lines of Python—the dynamic typing in Python made code needlessly hard to understand and started to seriously impact productivity. To mitigate this, we have been gradually migrating our code to static type checking using mypy,
===

[Google CTCCTCGGCGGGCACGTAG]

Java (C#, C++): vubec to nejde zkompilovat, coz indickeho kolegu donuti, aby S_Vindaloo splnovalo potrebne interface, pak vsecko funguje.

to muze velice snadno vynucovat CI.

[redustin]

Java (C#, C++): vubec to nejde zkompilovat, coz indickeho kolegu donuti, aby S_Vindaloo splnovalo potrebne interface, pak vsecko funguje.

to muze velice snadno vynucovat CI.

Proč by měl čekat až na CI, když v IDE zmáčkne jednu klávesovou zkratku (v Idee Ctrl+I - Implement methods), ze seznamu nabídnutých metod si vybere ty, které bude konkrétní level dědičnosti implementovat, a do vygenerovaným předpisů dopíše těla. Pokud jde o koncovou (již neabstraktní) třídu, dá implementovat všechny. A z hlediska datových typů má 100% jistotu, že je vše v pořádku.

Když bude chtít přetížit již implementovanou metodu, dá Ctrl+O (Override) a opět dostane kompletní předpis se správnými konkrétními parametry pro daná generika, se správnou anotací a ještě mu to předvyplní volání předka, které se v přetížených metodách obvykle vyskytuje. Nikoho nepálí, že jsou v parametrech dlouhé typy nebo že je to ukecané, když on z těch "nevýkonných" textů takřka nic nepíše. Ale bez nich by kompilátor a hlavně IDE nemělo možnost držet projekt pod kontrolou. Jako je tomu v pycharmu, když dám přejmenovat metodu a ono mi to přejmenuje i volání metod u jiných tříd, které jsem vůbec neměnil, protože nemá víc než tupý fulltext (+ zde zatracované typehinty, které samozřejmě v pythonu používám, aby mi z toho úplně nehráblo).

[Google CTCCTCGGCGGGCACGTAG]

Java (C#, C++): vubec to nejde zkompilovat, coz indickeho kolegu donuti, aby S_Vindaloo splnovalo potrebne interface, pak vsecko funguje.

to muze velice snadno vynucovat CI.

Proč by měl čekat až na CI, když v IDE zmáčkne jednu klávesovou zkratku (v Idee Ctrl+I - Implement methods), ze seznamu nabídnutých metod si vybere ty, které bude konkrétní level dědičnosti implementovat, a do vygenerovaným předpisů dopíše těla. Pokud jde o koncovou (již neabstraktní) třídu, dá implementovat všechny. A z hlediska datových typů má 100% jistotu, že je vše v pořádku.

ten checker samozrejme bezi i v IDE, ale CI je zaruka, ze ten jeho kolega commituje validni kod.

[Google CTCCTCGGCGGGCACGTAG]

A nebo bude používat args a kwargs a šedivět, co se zase kde rozsypalo.

tak ukaz, jak bys tu zanorenou strukturu z te tve funkce append definoval v Jave. Ja jen nastinil, jak by to slo idiomaticky. Sebeodkazujici typova definice narozdil od Javy v pythonu je mozna.

nebo s nesmyslným názvem

kwargs a args je standardni nazev, jiny by byl proti konvencim.

[Ondrej Nemecek]

Proto má třeba Smalltalk dynamic dispatch a současně protokoly. Což řeší oba požadavky.

Protokoly ve Smalltalku neřeší vcelku nic, je to jen kategorizace selektorů (metod), nic nevynucují (což je trošku škoda).

Dynamic dispatch má i Java, Python, prakticky každý OOP jazyk, to není žádná specialita Smalltalku.

Žil jsem v přesvědčení že protokoly můžou ve Smalltalku implementaci vyžadovat. Protože by mi přišlo ideální mít možnost volné vazby a volitelně vynucené implementace.

[redustin]

tak ukaz, jak bys tu zanorenou strukturu z te tve funkce append definoval v Jave. Ja jen nastinil, jak by to slo idiomaticky. Sebeodkazujici typova definice narozdil od Javy v pythonu je mozna.

Už to tu zaznělo, samostatnými generifikovanými metodami nějakého generického předka komponenty pro kolekci komponent, mapu <klíč, komponenta> a jiné komponenty. Ty složené metody by normálně kolekci i mapu proiterovaly a zavolaly tu jednoduchou append. Iterování je v defaultní idee o napsání iter + tabulátor, rovnou se vygeneruje celá smyčka se správnými typy a ručně se napíše jen její tělo. Idea si bude stěžovat, že jsem nepoužil foreach (pokud není ten hint vypnutý), ale to vypnu jednoduchou anotací (šipka vpravo a šipka nahoru), protože pouhý foreach přes streamy (tedy funkcionálně) má špatný výkon oproti normálnímu for component in components.

Ano, kód bude delší, ale na první pohled je úplně jasný, co dělá. Nevidím důvod, proč by měl do jednoho parametru rvát kolekci, mapu nebo komponentu, když parametr každé z metod má mít jiný název (components, componentsByKey, component).

kwargs a args je standardni nazev, jiny by byl proti konvencim.

Jasně, myslel jsem nesprávný název proměnné/metody/parametru, ne tohle. Jasně že musíš použít tyhle dva názvy, aby bylo všem jasné, že metoda umí spoustu věcí a mají si dát sakra bacha, jestli podporuje zrovna ten datový typ, který by oni rádi předali.