Doporučte programovací jazyk pro Windows

[LarryLin]

Abychom si rozumněli:
boto3 je (dynamické) AWS SDK for Python.
botostubs je pro napovídání boto3 v IDE.

API služeb AWS SDK for Python (boto3) se mění velmi rychle https://github.com/boto/boto3/releases , tady je changelog https://github.com/boto/boto3/blob/6a6bf486d9dab16b0ac8d3accce07b5178ce8954/CHANGELOG.rst . Jak můžeš vidět releasse je každý den! Takže jak jsem už psal je pro mne pochopitelné proč se vývojáři AWS rozhodli to napsat dynamicky.

Do zdrojáku Pythonu přidáš botostubs a pak jen každý den jedním příkazem zaktualizuješ boto3 a botostub. Mě to nepřijde složité.

"V Jave zadne stubs nikdy importovat nemusis."

To znamená, že Java vůbec neumí takto dynamické API vytvořit? Představ si, že máš API, které nabízí různé funkce() třeba podle regionů, podle objednaných služeb, podle různých kombinací služeb atd. Takové API nelze vytvořit staticky, protože bude pro každého individuálního zákazníka jiné, tudíž ti nebude fungovat ani klasické našeptávání. Takže buď by se to muselo řešit nějakým pluginem do konkrétních IDE a ostatní IDE mají smůlu nebo bys i v Javě potřeboval něco jako botostubs. Pokud Java neumožňuje vytvořit dynamické API, tak to považuješ za výhodu?

[Reklama]

[Zabanovaný Anonymní Troll]

LarryLine,
1. Kdyz se ti meni API, tak zrefaktorujes model a vydas novou verzi - v Jave velice snadne.
2. To co udelali oni je obechcavka. V Jave, kdyz mas API definovane JSONem, a AWSje takova vesmes Javascript-orientovana sluzba, tak si na zaklade toho JSONu vygenerujes Model generatorem. Vsadim se, ze Python zadny takovy generator, pouzitelny, nema.

[Filip Jirsák]

To znamená, že Java vůbec neumí takto dynamické API vytvořit? Představ si, že máš API, které nabízí různé funkce() třeba podle regionů, podle objednaných služeb, podle různých kombinací služeb atd. Takové API nelze vytvořit staticky, protože bude pro každého individuálního zákazníka jiné, tudíž ti nebude fungovat ani klasické našeptávání. Takže buď by se to muselo řešit nějakým pluginem do konkrétních IDE a ostatní IDE mají smůlu nebo bys i v Javě potřeboval něco jako botostubs. Pokud Java neumožňuje vytvořit dynamické API, tak to považuješ za výhodu?

To, čemu říkáte „dynamické API“, se normálně nazývá „dynamické typování“. Java používá statické typování, tj. typy jsou zafixované a kontrolují se už v době překladu. Pokud se API takhle často mění, je nesmysl pokoušet se na to napasovat statické typy (protože kompilátor vám jeden den zkontroluje, že máte typy správně, ale druhý den už to stejně nebude fungovat, protože se API změnilo). Ve světě staticky typovaných jazyků se tedy na tu proměnlivou část API budete dívat jako na data. Ostatně vy sám jste to jako data popsal – regiony nebo objednané služby jsou data, ne výkonný kód.

A upřímně řečeno, nevidím žádný přínos dívat se na ta data jako na kód a chtít po IDE, aby mi našeptávalo – když stejně zítra takhle napsaný kód nemusí fungovat.

[Zabanovaný Anonymní Troll]

To znamená, že Java vůbec neumí takto dynamické API vytvořit? Představ si, že máš API, které nabízí různé funkce() třeba podle regionů, podle objednaných služeb, podle různých kombinací služeb atd. Takové API nelze vytvořit staticky, protože bude pro každého individuálního zákazníka jiné, tudíž ti nebude fungovat ani klasické našeptávání. Takže buď by se to muselo řešit nějakým pluginem do konkrétních IDE a ostatní IDE mají smůlu nebo bys i v Javě potřeboval něco jako botostubs. Pokud Java neumožňuje vytvořit dynamické API, tak to považuješ za výhodu?

To, čemu říkáte „dynamické API“, se normálně nazývá „dynamické typování“. Java používá statické typování, tj. typy jsou zafixované a kontrolují se už v době překladu. Pokud se API takhle často mění, je nesmysl pokoušet se na to napasovat statické typy (protože kompilátor vám jeden den zkontroluje, že máte typy správně, ale druhý den už to stejně nebude fungovat, protože se API změnilo). Ve světě staticky typovaných jazyků se tedy na tu proměnlivou část API budete dívat jako na data. Ostatně vy sám jste to jako data popsal – regiony nebo objednané služby jsou data, ne výkonný kód.

A upřímně řečeno, nevidím žádný přínos dívat se na ta data jako na kód a chtít po IDE, aby mi našeptávalo – když stejně zítra takhle napsaný kód nemusí fungovat.

Tak s tim co jste napsal uplne nesouhlasim, AWS ma api definovane JSONem podobne, jako jina API jsou definovana treba XSDeckem. V Jave je to tradicni uloha na vygenerovani modelovych trid v dobe kompilace, v samostatnem maven modulu. Kdyz jsou neco "data", tak vy na ta data chcete mit vyrobeny v Jave model. Jenze pochybuju, ze v Pythonu na tento ukon maji dostatecne robustni nastroj jako je Maven a generatory.

Javovska verze toho AWS API normalne naseptava.

[Zabanovaný Anonymní Troll]

Ano, takze je to presne jak jsem si myslel, v Jave je obdoba boto3 udelana spravne, dependency:

Kód: [Vybrat]

<parent>
    <groupId>com.amazonaws</groupId>
    <artifactId>aws-java-sdk-pom</artifactId>
    <version>1.11.690</version>
  </parent>
  <groupId>com.amazonaws</groupId>
  <artifactId>aws-java-sdk-sqs</artifactId>
  <name>AWS Java SDK for Amazon SQS</name>
  <description>The AWS Java SDK for Amazon SQS module holds the client classes that are used for communicating with Amazon Simple Queue Service</description>
  <url>https://aws.amazon.com/sdkforjava</url>

Maji tam vyrobeny model, ten model muze byt klidne napsany rucne, a nad tim vsim maji vyrobenou normalni poradnou OOP knihovnu, pouzivaji polymorfismus a dedicnost. Zbytecne toto diskutovat s Pythonistama, ti by to nepochopili. Kdyz se v AWS meni API, tak v tom API se nedelaji zpetne nekompatibilni zmeny rok co rok. To by prestal fungovat vsem jejich zakaznikum kod. Na to klidne muze byt model napsany rucne, kdyz zmeny jsou inkrementalni.

Uplne to same by slo udelat v Pythonu, ale proc by to delali, kdyz to muzou vobechcat a potom na to vyrobit stubs, ze...

[Reklama]

[Filip Jirsák]

Tak s tim co jste napsal uplne nesouhlasim, AWS ma api definovane JSONem podobne, jako jina API jsou definovana treba XSDeckem. V Jave je to tradicni uloha na vygenerovani modelovych trid v dobe kompilace, v samostatnem maven modulu.

Nezáleží na tom, jak je to API definované, jestli WSDL, OpenAPI nebo nějak jinak. Pokud je statické, můžete si ho namodelovat v jakémkoli staticky typovaném jazyce (v dynamicky typovaných jazycích samozřejmě také). Pokud je to API dynamické, není to podle mne API – protože implicitní vlastností rozhraní je to, že se nemění. proto proti němu můžu programovat a spolehnout se, že ten můj kód bude ještě zítra s tím API fungovat. Na druhou stranu, pokud je API dynamické jenom tím, že se tam přidávají nové služby,není problém mít ho namodelované ve staticky typovaném jazyce – a když budu chtít tu novou službu využít, vytvořím si příslušný model.

Jenze pochybuju, ze v Pythonu na tento ukon maji dostatecne robustni nastroj jako je Maven a generatory.

Když se tak bijete za to, jak je ekosystém Javy moderní, doporučuju něco tak zastaralého jako Maven přestat nazývat „robustním nástrojem“ a podívat se na nástroje, které patří do roku 2020 – třeba Gradle.

[LarryLin]

Javovska verze toho AWS API normalne naseptava.

OK, takže myslíš asi tohle - https://github.com/aws/aws-sdk-java/releases
Pokud i to funguje za pomosi JSONu, tak jaké úkony potřebuji udělat, aby to našeptávalo v Sublime text?
Potřebuji Maven nebo Gradle? Potřebuji nějaké další úkony?

není problém mít ho namodelované ve staticky typovaném jazyce – a když budu chtít tu novou službu využít, vytvořím si příslušný model.

A je to jednodušší a rychlejší než použít botostubs?

[Zabanovaný Anonymní Troll]

třeba Gradle.

Fuj, tak to radeji prejdu na Python, nez na Gradle.

Ok, uz jsem pochytil ten rozdil mezi boto3 a Javovskym SDK.

To api je napsane ve stylu RPC, tzn. pripomina to vzdalene volani metody.

1. V Jave k tomu pristoupili tradicne tak, ze to RPC predstavuje zasilani messages:

strangeApi.send(new PublishStrangeMessage("message"))

2. V Pythonu to RPC API vsak dynamicky ohli tak, ze se s tim pak pracuje takto:

strangeApi.publishStrangeMessage("message")

A potom v samostanych stubs si tu funkci i explicitne definovali.

---

Neco takoveho by slo udelat i v Jave:

Pythnovske stubs -> Javovsky Interface
Pythonovska dynamicka vyroba metod -> Javovska reflexe

---

[Ink]

Tak s tim co jste napsal uplne nesouhlasim, AWS ma api definovane JSONem podobne, jako jina API jsou definovana treba XSDeckem. V Jave je to tradicni uloha na vygenerovani modelovych trid v dobe kompilace, v samostatnem maven modulu.

Nezáleží na tom, jak je to API definované, jestli WSDL, OpenAPI nebo nějak jinak. Pokud je statické, můžete si ho namodelovat v jakémkoli staticky typovaném jazyce (v dynamicky typovaných jazycích samozřejmě také). Pokud je to API dynamické, není to podle mne API – protože implicitní vlastností rozhraní je to, že se nemění. proto proti němu můžu programovat a spolehnout se, že ten můj kód bude ještě zítra s tím API fungovat. Na druhou stranu, pokud je API dynamické jenom tím, že se tam přidávají nové služby,není problém mít ho namodelované ve staticky typovaném jazyce – a když budu chtít tu novou službu využít, vytvořím si příslušný model.

Jenze pochybuju, ze v Pythonu na tento ukon maji dostatecne robustni nastroj jako je Maven a generatory.

Když se tak bijete za to, jak je ekosystém Javy moderní, doporučuju něco tak zastaralého jako Maven přestat nazývat „robustním nástrojem“ a podívat se na nástroje, které patří do roku 2020 – třeba Gradle.

Konecne neco uzitecneho - kvuli Mavenu jsem nekolikrat Javu a jeji ekosystem proklel a zhnusen odesel. Pokud je Gradle vyrazne lepsi, bod k dobru.

[Zabanovaný Anonymní Troll]

Konecne neco uzitecneho - kvuli Mavenu jsem nekolikrat Javu a jeji ekosystem proklel a zhnusen odesel. Pokud je Gradle vyrazne lepsi, bod k dobru.

Vsak ho nepouzivej. Klidne si stahni jarko rucne a strc si ho do projektu, jak jsi zvykly z Pythonu A pak si to Jarko klidne rucne zase smaz a nahrad jarkem s novou verzi. A kdyz se ti rozsypou zavislosti kvuli nekompatibilnim verzim, tak si to klidne rucne zase oprav

Plus jeste v pripade Pythonu si pomoci pyenv si klidne udrzuje nekolik verzi Pythonu, aby sis mohl spoustet nekolik pythnovsky nekompatibilnich projektiku na svem pc

Vcelku mi ten Python pripomina takove ty vcs pro mentalne zaostale jako je Mercurial. Poradny VCS ktery obsahuje vsechno co je nutne, je GIT. Java je to same, ma tam vsechno co tam byt musi, aby se s tim daly delat stredne velke az ty uplne nejvetsi projekty. Pidi projekty si klidne pis Pythonu, ja umim Javu, tak se drzim ji...

[Zabanovaný Anonymní Troll]

Akorat musim rict, ze Jave docela dost hori koudel pokud jde o Cloud, microservices a serverless architketuru. Jestli to tahkle pujde dal, tak se obavam, ze Java na to chcipne. Jeji robustni tooly s cloudem a serverless nebudou potreba, protoze jejich roli prebere cloudova platforma, a bude se opakovat neco podobneho, jako kdyz pred lety Java premohla C++.

[Filip Jirsák]

A je to jednodušší a rychlejší než použít botostubs?

Záleží na tom, jak je to API definováno. Pokud můžu použít nějaký nástroj, který mi definici API překlopí do modelu v daném jazyce, je to záležitost jednoho příkazu.

Nicméně jednoduchost a rychlost nejsou jediná kritéria pro vývoj. Existují i projekty, které mají delší životnost než tři měsíce, tam pak získává na vrchu kritérium udržovatelnosti.

[Filip Jirsák]

Fuj, tak to radeji prejdu na Python, nez na Gradle.

Proč? Autoři Gradle pochopili, že každý trošku větší projekt si nevystačí s deklarativním popisem projektu. Maven sice neumožnil vyloženě imperativní programování v XML jako Ant, ale v Mavenu se to řeší miliony properties a profilů, takže výhoda deklarativního popisu je ta tam. A sice už se snad Maven zbavil Avalonu (alespoň pro pluginy), ale pořád je utrpení rozšířit build o nějaký kód.

Akorat musim rict, ze Jave docela dost hori koudel pokud jde o Cloud, microservices a serverless architketuru.

Co se vám nelíbí na Micronautu nebo Helidonu? Když to navíc spojíte s GraalVM… Můžete psát mikroservisy nebo lambda funkce, výkon bude už teď nejspíš lepší než u NodeJS a spol. a k dispozici máte celý ekosystém Javy. Javě v tom myslím trochu ujel vlak, ale už je zpět ve hře a má našlápnuto velice slušně.

[Zabanovaný Anonymní Troll]

Fuj, tak to radeji prejdu na Python, nez na Gradle.

Proč? Autoři Gradle pochopili, že každý trošku větší projekt si nevystačí s deklarativním popisem projektu. Maven sice neumožnil vyloženě imperativní programování v XML jako Ant, ale v Mavenu se to řeší miliony properties a profilů, takže výhoda deklarativního popisu je ta tam. A sice už se snad Maven zbavil Avalonu (alespoň pro pluginy), ale pořád je utrpení rozšířit build o nějaký kód.

Ja moc s Gradle neumi, delal jsem s nim jen z nouze, ale:
1. Pro zakladni rozvrzeni projektu vc submodulu je Gradle 1:1 to same co Maven
2. S tim rozdilem ze Gradle neumi definovat Parenta
3. S tim rozdilem ze Gradle je mene zaboilerplatovany, jenze jaksi za cenu toho, ze clovek nema naseptavani.
4. S tim rozdilem, ze v Gradlovi se da dobre programovat - to je snad ta nejhorsi vlastnost, protoze by to nekoho mohlo napadnout delat. Co potrebujete pri buildu programovat?

Akorat musim rict, ze Jave docela dost hori koudel pokud jde o Cloud, microservices a serverless architketuru.

Co se vám nelíbí na Micronautu nebo Helidonu? Když to navíc spojíte s GraalVM… Můžete psát mikroservisy nebo lambda funkce, výkon bude už teď nejspíš lepší než u NodeJS a spol. a k dispozici máte celý ekosystém Javy. Javě v tom myslím trochu ujel vlak, ale už je zpět ve hře a má našlápnuto velice slušně.

1. Zkousel jste si uz zbuildit ten Micronauti Lambda example na Githubu s GraalVM? Vzdyt to je hrozne, kompilace tim Graalem trva snad 3 minuty.
2. Kdyz jsem videl nejaky benchmark, tak to stejne melo pomalejsi cold start nez Node.js lambda.
3. Na takovou monolitickou lambdu rovnou muzete pouzit Spring Cloud Function - nevim jen jestli tu v budoucnu bude podporovat Graal. 
4. Ikdyz to vsechno udelate, tak budete tvorit relativne velke monoliticke lambdy a ja se ptam - proc to do haje radeji rovnou nerozjet jako service v docker kontejneru? Co tim ziskate ze to bude lambda funkce?

Jave tim ujel vlak a muj nazor po X hodinach googleni je, ze to jeste nedohnala. A pokud GraalVM nepohne pri rychlosti buildu zadeki, tak ani nedozene.

Nicmene reseni b mohlo byt jine, a sice jinaci JVM. V Lambde vam je burt nejaka performance vyjma cold startu. Pomale to muze byt klidne jako python. Hlavne at se ta mrcha lina rychle nastartuje.

[LarryLin]

V Javě nedělám, ale kdybych někdy potřeboval něco jednoduchého v Javě stvořit a hostovat na AWS, tak je tady někdo kdo mi vysvětlí jak bych měl postupovat aby fungovalo našeptávání? Předpokládám, že musím udělat toto:

1) Nainstaluji Eclipse (pokud by se Sublime byl problém)
2) Nainstaluji Java 8.0 or later
3) Nainstaluji http://maven.apache.org/install.html
4) Podle návodu z AWS - https://docs.aws.amazon.com/sdk-for-java/v2/developer-guide/setup-install.html#include-sdk stáhnu zdrojáky AWS SDK for Java z Githubu
5) Zkompiluji zdrojáky za pomoci Mavenu a vytvoří se mi .jar soubory

Po těchto krocích mně bude našeptávání fungovat?

Pokud https://github.com/aws/aws-sdk-java/releases má release každý den (tak jako boto3), tak budu muset denně kompilovat zdrojáky a vytvářet .jar soubory?

Nicméně jednoduchost a rychlost nejsou jediná kritéria pro vývoj.

Ptal jsem se proto, že PetroviK se botostubs zdál složitý.