Doporučte programovací jazyk pro Windows

[Zabanovaný Anonymní Troll]

Chtel jsem napsat, ze je to prispevek klasickeho prislusnika Java sekty, ale jelikoz uznal Pythonu aspon ty baterky, neni zrejme jeste ztracen. Takze snad pochopi i navrhove nedostatky Javy a uzna, ze nektere principy pouzite v Pythonu fakt maji smysl. A nemyslim tim ducktyping, ten je skutecne IMO sporny.

 

Jak muzes rikat ze Ductyping je sporny, kdyz to je pointa toho, proc se v Pythonu dobre pisou skripty, a ty jsou zase pointa toho, proc to ma ty baterky. Udelej si poradek v hlave synku, jinak z tebe nikdy poradny Javista nebude a navzdy budes jen smutne koukat

[Reklama]

[Ink]

Chtel jsem napsat, ze je to prispevek klasickeho prislusnika Java sekty, ale jelikoz uznal Pythonu aspon ty baterky, neni zrejme jeste ztracen. Takze snad pochopi i navrhove nedostatky Javy a uzna, ze nektere principy pouzite v Pythonu fakt maji smysl. A nemyslim tim ducktyping, ten je skutecne IMO sporny.

 

Jak muzes rikat ze Ductyping je sporny, kdyz to je pointa toho, proc se v Pythonu dobre pisou skripty, a ty jsou zase pointa toho, proc to ma ty baterky. Udelej si poradek v hlave synku, jinak z tebe nikdy poradny Javista nebude a navzdy budes jen smutne koukat

Než programovat v současné Javě, to už snad raději fakt Python 2. Naštěstí se Python vyvíjí, i Java se vyvíjí a jazyků, kterými se dá uživit, od doby vzniku a rozšíření Pythonu i Javy výrazně přibylo. Navíc už programuju málo, klidně to nechám Tobě a jiným kolegům.

[Standa Blábol]

Chtel jsem napsat, ze je to prispevek klasickeho prislusnika Java sekty, ale jelikoz uznal Pythonu aspon ty baterky, neni zrejme jeste ztracen. Takze snad pochopi i navrhove nedostatky Javy a uzna, ze nektere principy pouzite v Pythonu fakt maji smysl. A nemyslim tim ducktyping, ten je skutecne IMO sporny.

 

Jak muzes rikat ze Ductyping je sporny, kdyz to je pointa toho, proc se v Pythonu dobre pisou skripty, a ty jsou zase pointa toho, proc to ma ty baterky. Udelej si poradek v hlave synku, jinak z tebe nikdy poradny Javista nebude a navzdy budes jen smutne koukat

Než programovat v současné Javě, to už snad raději fakt Python 2. Naštěstí se Python vyvíjí, i Java se vyvíjí a jazyků, kterými se dá uživit, od doby vzniku a rozšíření Pythonu i Javy výrazně přibylo. Navíc už programuju málo, klidně to nechám Tobě a jiným kolegům.

Nejak jsem nepobral, proc by melo byr problem programovat v soucasne jave.
Dneska muzes delat v Jave na urovni 1.5 a nove veci zkratka nepouzivat, s tim nikdo nebude mit potiz.
Akorat musis ve frameworkach brat anotace jako cernou magii a pouzivat to tak, kdyz uz je nekdo linej se naucit nove veci.

Python2 se s tim merit neda ani hodne vzdalenym omylem.
Slusne pouzitelny je az Python3 a to prave proto, ze prebira koncepty z javy.

Python neumi nic, co by neumela java(akorat vylozene nebezpecne veci se tam delaji ukecane, typicky reflection api, to je zalesitost pro tvurce frameworku, bezny jouda do toho nema co hrabat), naopak to zdaleka neplati. Ostatne jython je imementace pythonu v jave, javu v pythonu nikdo nenapsal

[Zabanovaný Anonymní Troll]

Naucit se Spring framework v Jave a neco v nem byt schopen sam delat, to neni zadna legrace, je to nastroj pro poradny chlapy, je to poradna zemedelska technika pro poradny softwarovy engineery Ja hosi dycky kdyz k tomu sednu, tak to je jak kdybych ridil 300 konovy kombajn, to nikdy nejaky cmrndala Pyjthonista nepozna tuhletu silu  A kdyz ta Spring aplikace startuje, tak to je tvl jak kdyz startuje tryskac, az se mi vsechny vetracky roztoci na tom mojem notebuku  Kdepak Pyjthon...

[Google CTCCTCGGCGGGCACGTAG]

Delas veci zbytecne slozite a jeste s tim machrujes na foru.

[Reklama]

[Ink]

Python neumi nic, co by neumela java(akorat vylozene nebezpecne veci se tam delaji ukecane, typicky reflection api, to je zalesitost pro tvurce frameworku, bezny jouda do toho nema co hrabat), naopak to zdaleka neplati. Ostatne jython je imementace pythonu v jave, javu v pythonu nikdo nenapsal

Python umí porovnávat číslo s číslem pomocí operátorů, objekt s objektem pomocí ==, jak se sluší a patří a nepotřebuje na blbý hello world žádný public static void main(). A to už od začátku. A od začátku měl normální kolekce, do kterých vlezl objekt, který věděl, co je zač a ne pole Objectů s křišťálovou koulí a pitomým přetypováním, když mu koule řekla, co je to skutečně zač. Nikdy a nikde jsem netvrdil, že Python je všespásný, to akorát vaše sekta v Javě chtěla psát všechno od jádra OS po widgety na webu. Zrovna tak jsem netvrdil, že v Javě principiálně nejde napsat cokoli, co jde v Pythonu, to nebude tvrdit nikdo, kdo slyšel o turingovsky úplných jazycích.

Jo a proč nechci programovat v dnešní Javě není dáno tím, co je v ní nového, ale co v ní naopak ještě chybí a co je v ní od počátku blbého. Jinak bych asi nepsal, že se Java vyvíjí a nepsal, že to je dobře.

[Zabanovaný Anonymní Troll]

Delas veci zbytecne slozite a jeste s tim machrujes na foru.

TIpnu si, ze ty delas webdevelopment a nebo jsi student a jeste ti tece mliko po brade. Tohle uz jsem slysel od kdejakeho webovkarskeho patlaly rozumbrady, nez si cvrknul do kalhot z toho, jake veci se resi v enterprise

[Zabanovaný Anonymní Troll]

Python neumi nic, co by neumela java(akorat vylozene nebezpecne veci se tam delaji ukecane, typicky reflection api, to je zalesitost pro tvurce frameworku, bezny jouda do toho nema co hrabat), naopak to zdaleka neplati. Ostatne jython je imementace pythonu v jave, javu v pythonu nikdo nenapsal

A od začátku měl normální kolekce, do kterých vlezl objekt, který věděl, co je zač a ne pole Objectů s křišťálovou koulí a pitomým přetypováním, když mu koule řekla, co je to skutečně zač.

Tak to je trochu blbost, nemyslis? Objektu je prd po tom, co je zac, ta informace je dulezita predevsim pro programatora. To programator nevedel, co v tom Listu je, videl jen ze je to list Objektu, nez se do Javy daly genericke typy Pri spusteni aplikace a debugovani samozrejme slo videt co presne v Listu je za Tridu. A protoze Pythonu pouziva ducktyping, tak ty uz vubec nevis, co v te kolekci je, dokud si to nespustis.

[Ink]

Python neumi nic, co by neumela java(akorat vylozene nebezpecne veci se tam delaji ukecane, typicky reflection api, to je zalesitost pro tvurce frameworku, bezny jouda do toho nema co hrabat), naopak to zdaleka neplati. Ostatne jython je imementace pythonu v jave, javu v pythonu nikdo nenapsal

A od začátku měl normální kolekce, do kterých vlezl objekt, který věděl, co je zač a ne pole Objectů s křišťálovou koulí a pitomým přetypováním, když mu koule řekla, co je to skutečně zač.

Tak to je trochu blbost, nemyslis? Objektu je prd po tom, co je zac, ta informace je dulezita predevsim pro programatora. To programator nevedel, co v tom Listu je, videl jen ze je to list Objektu, nez se do Javy daly genericke typy Pri spusteni aplikace a debugovani samozrejme slo videt co presne v Listu je za Tridu. A protoze Pythonu pouziva ducktyping, tak ty uz vubec nevis, co v te kolekci je, dokud si to nespustis.

Objektu se muzes zeptat a podle toho s nim pracovat - za behu. Timto s Tebou koncim, pokud si myslis, ze v Pythonu neni mozne statickou analyzou zjistit, co je v kolekci, je tato debata nadale zbytecna.

[redustin]

Jistěže lze kdykoliv zjistit typ objektu. Bohužel to pak dopadá třeba takhle https://github.com/dddomodossola/remi/blob/master/remi/gui.py#L1914 . V javě (a spoustě jiných jazyků) by se v této situaci (pokud bych to nechtěl celé postavit jinak, víc objektově) udělalo více metod append s různými vstupními parametry (Map, Collection, Widget) a každá by se chovala jinak. Jak to udělat v pythonu? Udělat metody appendDict, appendCollection, appendWidget? Nebo jednu metodu, která ale ve skutečnosti dělá pomocí if elseif... tři různé věci, jak je to v ukázce.

Nicméně samozřejmě nesouhlasím, že by se java neměla od pythonu co učit. Chybějící mixiny jsou zásadní nedostatek, o který zakopávám v jednom kuse. A defaultní metody interfaců to zdaleka neřeší, protože jsou public a interfacy nemají vnitřní proměnné. Tuples by se sakra hodily. Rovněž nemožnost volat kód s checkovanými výjimkami ve streamu je zásadní omezení modernizace legacy kódu. Končí to obalováním bloků runtime výjimkami, což je zbytečný balast. Python to v generátorech neřeší, příjemně se používají.

Na druhou stranu chápu, že java musí držet nějakou kompatibilitu a přidávání nových vlastností není úplně jednoduché. Přechod python2 -> python3 byl úplně špatně, to mi nikdo nevymluví. Ale i java má své problémy, technické změny v javě 9 zasekly spoustu projektů na osmičce (nepočítám-li změnu licence).

O kvalitě vývoje v enterprise si nedělám iluze :-)

[Ink]

Jistěže lze kdykoliv zjistit typ objektu. Bohužel to pak dopadá třeba takhle https://github.com/dddomodossola/remi/blob/master/remi/gui.py#L1914 . V javě (a spoustě jiných jazyků) by se v této situaci (pokud bych to nechtěl celé postavit jinak, víc objektově) udělalo více metod append s různými vstupními parametry (Map, Collection, Widget) a každá by se chovala jinak. Jak to udělat v pythonu? Udělat metody appendDict, appendCollection, appendWidget? Nebo jednu metodu, která ale ve skutečnosti dělá pomocí if elseif... tři různé věci, jak je to v ukázce.

Ten kod je jednoznacne napraseny - pokud uz chci povolit takovyto rozptyl vstupu, je to jednoznacne na vice metod - pro list a dict ta metoda stejne jenom rekurzivne vola samu sebe. Navic ma volitelny parametr key, ktery ale v pripade listu a dictu ignoruje, coz je na prvni pohled sporne. A vyhodu v tom mit vsechny tri metody pojmenovane stejne, osobne nevidim - semantika je jina, tak at se to i jinak jmenuje. Podle me nejaky mechanismus a la multimethods zde postrada smysl a implementace z prikladu je dost tragikomicka. Podobne nejsem priznivcem pouzivani **kwargs coby soucasti API, podle me je to dost zoufale a kontraproduktivni rozhodnuti, kdyz k tomu nekdo svevolne sahne.

[redustin]

Bohužel s podobným přístupem k netypovanému parametru metod se setkávám v pythoních projektech docela často. Půlka metod API začíná runtime kontrolou správných typů parametrů.

[Standa Blábol]

Jistěže lze kdykoliv zjistit typ objektu. Bohužel to pak dopadá třeba takhle https://github.com/dddomodossola/remi/blob/master/remi/gui.py#L1914 . V javě (a spoustě jiných jazyků) by se v této situaci (pokud bych to nechtěl celé postavit jinak, víc objektově) udělalo více metod append s různými vstupními parametry (Map, Collection, Widget) a každá by se chovala jinak. Jak to udělat v pythonu? Udělat metody appendDict, appendCollection, appendWidget? Nebo jednu metodu, která ale ve skutečnosti dělá pomocí if elseif... tři různé věci, jak je to v ukázce.

Nicméně samozřejmě nesouhlasím, že by se java neměla od pythonu co učit. Chybějící mixiny jsou zásadní nedostatek, o který zakopávám v jednom kuse. A defaultní metody interfaců to zdaleka neřeší, protože jsou public a interfacy nemají vnitřní proměnné. Tuples by se sakra hodily. Rovněž nemožnost volat kód s checkovanými výjimkami ve streamu je zásadní omezení modernizace legacy kódu. Končí to obalováním bloků runtime výjimkami, což je zbytečný balast. Python to v generátorech neřeší, příjemně se používají.

Na druhou stranu chápu, že java musí držet nějakou kompatibilitu a přidávání nových vlastností není úplně jednoduché. Přechod python2 -> python3 byl úplně špatně, to mi nikdo nevymluví. Ale i java má své problémy, technické změny v javě 9 zasekly spoustu projektů na osmičce (nepočítám-li změnu licence).

O kvalitě vývoje v enterprise si nedělám iluze :-)

Souhlas, osobne pouzivm Javu na tezsi veci a Python3 na skriptovani.
A zrozvna mixin mi vubec nechybi, to povazuju za pomerne nebezpecnou zalezitost co vede k pekne zamotanemu kodu.
Osobne se vubec snazim vyhnou dedeni a preferuju kompozici ve stylu Spring bean injection. Tim ddosahnes stejny vysledek a bezpecne, pripadne problemy bouchnou hned pri startu programu programu kde te Spring posle do zadele s cyklickymi referencemi apod.
Co se tyce tuples, ty mi taky nechybi. Vyrobit staticky bean v Ecplise je par kliku na generator, staci definovat atributy, zbytek dogeneruje IDE. A mam moznosti si treba interceptovat pro potreby debug pristup k jednotlivym atributum beanu pres injektovany logger, to s holym python tuplem neudelas.
dalsi aletrnativa je Lombok, tam vypada definice beanu takto:

Kód: [Vybrat]

@RequiredArgsConstructor
@Accessors(fluent = true) @Getter
public class LoginResult {
 
    private final @NonNull Instant loginTs;
 
    private final @NonNull String authToken;
    private final @NonNull Duration tokenValidity;
     
    private final @NonNull URL tokenRefreshUrl;
 
}

Krasne citelne, kazdy z fleku vidi co to dela, par radku kodu.


Streamy se snazim osobne nepouzivat, pouze pro jednoduche transformace collections apod. Stejne je z toho ve vysledku bytecode s foreach cyklem, to radsi napisu ten foreach rovnou a obetuju par radku kodu navic vymenou za lepsi citelnost.

[Standa Blábol]

Python neumi nic, co by neumela java(akorat vylozene nebezpecne veci se tam delaji ukecane, typicky reflection api, to je zalesitost pro tvurce frameworku, bezny jouda do toho nema co hrabat), naopak to zdaleka neplati. Ostatne jython je imementace pythonu v jave, javu v pythonu nikdo nenapsal

A od začátku měl normální kolekce, do kterých vlezl objekt, který věděl, co je zač a ne pole Objectů s křišťálovou koulí a pitomým přetypováním, když mu koule řekla, co je to skutečně zač.

Tak to je trochu blbost, nemyslis? Objektu je prd po tom, co je zac, ta informace je dulezita predevsim pro programatora. To programator nevedel, co v tom Listu je, videl jen ze je to list Objektu, nez se do Javy daly genericke typy Pri spusteni aplikace a debugovani samozrejme slo videt co presne v Listu je za Tridu. A protoze Pythonu pouziva ducktyping, tak ty uz vubec nevis, co v te kolekci je, dokud si to nespustis.

Objektu se muzes zeptat a podle toho s nim pracovat - za behu. Timto s Tebou koncim, pokud si myslis, ze v Pythonu neni mozne statickou analyzou zjistit, co je v kolekci, je tato debata nadale zbytecna.

Mno, v Jave se operatorem instanceof taky dozvis, co je to za objekt. V Jave <1.4 se to tak taky po pythonovsku delalo. Proto jsem nahore vyslovne psal, ze staci psat na urovni java 1.5, ktera uvedla generika, to mluvime o roku 2004, mimochodem.

[Google CTCCTCGGCGGGCACGTAG]

Jistěže lze kdykoliv zjistit typ objektu. Bohužel to pak dopadá třeba takhle https://github.com/dddomodossola/remi/blob/master/remi/gui.py#L1914 . V javě (a spoustě jiných jazyků) by se v této situaci (pokud bych to nechtěl celé postavit jinak, víc objektově) udělalo více metod append s různými vstupními parametry (Map, Collection, Widget) a každá by se chovala jinak. Jak to udělat v pythonu? Udělat metody appendDict, appendCollection, appendWidget? Nebo jednu metodu, která ale ve skutečnosti dělá pomocí if elseif... tři různé věci, jak je to v ukázce.

Nicméně samozřejmě nesouhlasím, že by se java neměla od pythonu co učit. Chybějící mixiny jsou zásadní nedostatek, o který zakopávám v jednom kuse. A defaultní metody interfaců to zdaleka neřeší, protože jsou public a interfacy nemají vnitřní proměnné. Tuples by se sakra hodily. Rovněž nemožnost volat kód s checkovanými výjimkami ve streamu je zásadní omezení modernizace legacy kódu. Končí to obalováním bloků runtime výjimkami, což je zbytečný balast. Python to v generátorech neřeší, příjemně se používají.

Na druhou stranu chápu, že java musí držet nějakou kompatibilitu a přidávání nových vlastností není úplně jednoduché. Přechod python2 -> python3 byl úplně špatně, to mi nikdo nevymluví. Ale i java má své problémy, technické změny v javě 9 zasekly spoustu projektů na osmičce (nepočítám-li změnu licence).

O kvalitě vývoje v enterprise si nedělám iluze :-)

tady by mozna stalo za to pouzit keyword argumenty? Rozhodovaci logika by se dost zjednodusila. Asi bych jeste oddelil ty dve cinnosti. Na splosteni te zanorene vstupni struktury bych pouzil nejakou generickou funkci. Na zpracovani jednotlivich key value paru bych pouzil oddelenou funkci. Na testovani vice pribuznch typu se da pouzit neco jako isinstance Iterable nebo isinstance Sequence a pod.