Doporučte programovací jazyk pro Windows

[qelurg]

Nemám. Imho to nejde staticky myslícímu člověku racionálně vysvětlit. Můžeš to zkoušet používat a buď přijde aha efekt a nebo nepřijde. Kdysi na to téma měl přednášku na techtalku Niclas Nilsson https://www.se-radio.net/2007/03/episode-49-dynamic-languages-for-static-minds/ ale imho ti to nepomůže, protože to není otázkou nedostatku informací, ale změny myšlení, a to může přijít jen s vlastní zkušeností. Můžeš si zkusít přečíst pár knih na téma javascript design patterns, kde jsou kodifikovány některé způsoby využití, které by tě asi jinak nenapadly, ale jsem pesimista. Tak jako polovina čechů nepochopí, že demokracie je dobrá, imho nepochopí ani polovina programátorů, že dynamické jazyky jsou dobré. Starý struktury musí vymřít a to špatný nerozujný mládí s tím už takové problém nemá.

1) Sorry, ale podle čeho soudíš že dynamické jazyky nepoužívám? Dělal jsem ve Smalltalku a teď nejvíc v Lue. Oba mi v porovnání se zmiňovaným Javascriptem přijdou výrazně konzistentnější.

2) BTW, ten podcast mluví o věcech z nichž spousta je na dynamičnosti jazyka úplně nezávislá. Bloky a uzávěry, funkce co vrací funkce, Currying, nebo continuations se vyskytují třeba v Haskellu. Což je pro mně jakýsi vzor toho jak má vypadat dobrý statický typový systém.

Statické typy nejsou jenom o jejich deklaraci, ale o tom, že ti determinují, co můžeš za běhu s programem ještě dělat a co už ne. Zjednodušeně řečeno, statické jazyky rozlišují kód a data, dynamické nikoliv (byť míra implementace je různá).  V dynamickém jazyku můžeš kód používat stejně jako data. Což by ti mělo úplně měnit pohled na program a programování, má to řadu důsledků a možností, třeba javascriptové aplikaci můžeš nový kód posílat jako data a za běhu měnit její funkčnost. A ne jako nějakou nouzovou záležitost, kdy servr opravuje za běhu lokální na js založenou aplikaci, ale jako běžné chování. Staticky myslícím programátorům se z toho zvedá kufr, pro ně je to prasárna, všechno chtějí mít pevné, neměnné, prostě statické předem zkontrolované, dynamicky 'mutujíci se' program je pro ně představa z pekla. Přitom přesně takto webové aplikace fungují, nalinkovaný js do stránky není nic jiného než program poslaný jako data, s každou stránkou se mohou načíst jiné, z pohledu uživatele se to mění za běhu aplikace, dělat změny i za běhu interpretu (zjednodušuji, vím) je už jen drobné rozšíření tohoto konceptu. Nebo třeba autonomně za běhu programu se vytvářející stovky nových tříd/datových typů na základě obsahu příchozích dat, která jsou hodně variabilní (na to aby je programátor předem otypoval všechny ručně), ale mají své časté opakující se vzory, aby stálo za to jim přiřadit vlastní datové typy.

3) Opravdu mi browser servíruje dynamicky generované kusy javascriptu? Není to spíš tak, že dostávám předpřipravené kousky, které někdo odladil, otestoval, možná prohnal nějakým transpilerem, linterem a obfuskátorem? S důrazem hlavně na to testování, protože můj dojem z dynamických jazyků je, že důkladné pokrytí testy je jediný způsob, jak se z toho nezbláznit. A taky jak si být aspoň trochu jistý, že jsem vychytal aspoň překlepy.

4) Stejně by mi webserver mohl servírovat kousky java/.net bytekódu, nebo dokonce x86 binárky. A nebo reálněji třeba webassembly. Mimochodem i ten javascript, co dostávám, mohl vzniknout transpilací z nějakého statického jazyka. Jako příjemce by to pro mně neznamenalo žádný rozdíl.

To jenom pro představu možností. To že ty osobně nenarážíš na možnosti statických typů je proto, že myslíš staticky a nechceš proto po nich víc, než ti umožňují. Zkus ale nahradit javascript v prohlížeči nějakým statickým jazykem. Ne že by to nešlo, ale narazíš na řadu omezení a problémů, která to přinese. Ne že by to lidé nezkoušeli, kdo si pamatuje java applety? Jestli tohle ti neumožní alespoň vidět nové možnosti, které přináší dynamické jazyky, tak ti asi nic nepomůže. A pokud ano, tak chápeš nesmyslnost tvrzení, že dynamické jazyky jsou stejné jako statické, ale horší.

5) Jinak zbytek keců o tom že to staticky myslícímu člověku nejde vysvětlit, nebo že to buď vidím nebo mi nic nepomůže si vážně můžeš nechat. Mohl bych to jednoduše otočit stylem že dynamicky myslící člověk není schopný pobrat výhody statických jazyků. Přínos nula.

1) Z nechápavosti, ale tak ti prostě nejsou souzeny. Souhlas, Javascript není dobře navržený jazyk, když vznikal, byla to spíš legrace, nikdo s ním tak velké ambice neměl. Holt stane se, smutné je, že nikdo nepřišel s lepší náhradou nebo alespoň javascriptem 2, který by se zbavil té nesmyslné zátěže. Přitom by v prohlížeči mohl běžet pár let paralelně s tím stávajícím a bezbolestně převzít štafetu.
2) To je pravda, ale už je to dost staré, tehdy to ještě nebylo všeobecně známé.
3) Původ není podstatný, podstatná je možnost modifikovat dynamicky a jednoduše běžící runtime. Testování je potřeba vždy, statické typy tě přece před překlepem nezachrání.
4) Jak bys v javě za běhu modifikoval třídu a všem stávajícím instancím změnil chování nějaké metody?
5) Otočit to samozřejmě můžeš, ale nemáš proti komu, protože nikdo tu význam statických jazyků nepopírá.

[Reklama]

[LarryLin]

Heh, v mym textu neni ani stopy despektu vuci mladym, tam je despekt vuci hloupym.
A vez, ze z mladyho blba bude stary blb a stary blb byl mladym blbem.
Kdyz mi nekdo realne zduvodni, proc je muj nazor mylny, nemam problem to uznat.

Uvažuješ úplně špatně, protože to, že do IT přicházejí lidé, kteří mají stále nižší IQ je důvodem rozmachu IT. Kdyby Bill Gates a Jobs nestrčili počítač do ruky každému blbcovi (když použiji tvůj arogantní slovník), tak by se IT nerozvíjelo tak dynamicky.
Nejsme schopni zajistit, aby se rodilo větší procento dětí s vysokým IQ, abychom těmito dětmi dokázali obsadit ty statisíce nových IT pracovních pozic, které vznikají. Tvoje arogance je stejná, jako kdybys viděl 5leté dítě jak si ťuká na tablet a začal mu nadávat, že dnes na počítači dělá kdejaký blb a kdeže jsou ty časy kdy na obsluhu počítače byly potřeba 2 vysoké školy.

Vy myslíte politicky, Halík!

Nee, myslím ekonomicky. Před 20 lety Standa Blábol a jeho 500 splupracovníků s IQ 200 pracovali na bankovních systémech v ČR což tenkrát bylo TOP zaměstnání. Dnes je potřeba na zajištění bankovních systémů 10000 pracovníků, ale v ČR je stále jen těch 500 lidí s IQ 200.

Správně by se měl Standa ze své pracovní pozice Vývojáře bankovních systémů přesunout na Vývojáře AI a těm 10000 zaměstnancům připravovat lepší automatizaci. Tak to má v ekonomice fungovat. Pokud se Standa nepřesunul na Vývojáře AI, tak zaspal dobu a teď nemůže pochopit, že Čo bolo, to bolo! 

[tomas88]

Tady se kazdy ohani IQ a pritom se resi takovy pakarny Staticky nebo dynamicky. Vzdyt je to stejna debata jako jestli mezery nebo tabulatory. Proste nema reseni. Nebo ma, ale protistrana ho stejne neprijme. Takze jako by nemel.

Pokud mam nest zodpovednost, volim staticky typovany jazyky. A kdyz po me zodpovednost nikdo nevyzaduje (to jest jsem na tom projektu jen jako pracovni jednotka), tak klidne experimenty vseho druhu a na vsech frontach. A az se to zacne srat, tak jdu dal.

[Jiří Havel]

To je oxymoron, kdyz chces mit vsechno zkontrolovane v dobe kompilace, nemuzes to pak vytvaret za chodu, a naopak. Pro statickou analyzu nepotrebujes staticke typy, na to ti staci typove anotace, ktere ma python nebo truescript.

Je nějaký principielní rozdíl mezi statickými typy a těmi typovými anotacemi? V obou případech jsou to překladačem vynucená omezení možných hodnot.

Vyhoda statickych typu je jina a imho jedina, umoznuje podstatne lepsi optimalizaci na urovni strojoveho kodu. Kdyz se ty kouzla ve statickych jazycich delaji, proc nemaji plnohodnotnou funkci eval (ci jeji ekvivalent, treba pythoni compile) nebo repl? Coz je dalsi z vyuziti schopnosti prace s dynamicky vytvarenym kodem.

Třeba takový Haskell (ghc) má plnotučný repl, eval a všechny tyhle radosti. Cerní C++ interpret ten repl zvládá taky bez problémů.

To, jestli má jazyk eval, repl a podobné věci není až tak závislé na statičnosti nebo dynamičnosti daného jazyka. Závisí to spíš na tom, jestli se programy v daném jazyce distribuují v podobě zdrojáků nebo jako nějaký bytecode či binárky. Jde jenom o tom, jestli se vyplatí k tomu programu přibalit řádově větší a složitější kompilátor/interpret. Nebo jestli tam ten kompilátor stejně přibalený být musí.

1) Z nechápavosti, ale tak ti prostě nejsou souzeny. Souhlas, Javascript není dobře navržený jazyk, když vznikal, byla to spíš legrace, nikdo s ním tak velké ambice neměl. Holt stane se, smutné je, že nikdo nepřišel s lepší náhradou nebo alespoň javascriptem 2, který by se zbavil té nesmyslné zátěže. Přitom by v prohlížeči mohl běžet pár let paralelně s tím stávajícím a bezbolestně převzít štafetu.

Omyl, JavaScript není vůbec navržený jazyk. Vznikl jako demíčko, které napsal jeden člověk za týden a shodou okolností se ujal jako standard. Proč nikdo nepřišel s lepší náhradou je IMO jasné. U webového jazyka je úplně jedno, jestli je statický, dynamický, takový nebo makový. Jediné relevantní kritérium je kompatibilita s tou hromadou existujícího JavaScriptu. Všechno ostatní jsou jen důsledky.

3) Původ není podstatný, podstatná je možnost modifikovat dynamicky a jednoduše běžící runtime. Testování je potřeba vždy, statické typy tě přece před překlepem nezachrání.

Možnost modifikovat runtime nevyplývá ze statičnosti/dynamičnosti ale z toho, jestli má ten jazyk vždycky přibalený kompilátor/interpret.
Testovat je třeba. Ale drtivá většina překlepů se ve statických jazycích chytne už při kompilaci, protože metody jako "SeParam" žádný interface nemá.

4) Jak bys v javě za běhu modifikoval třídu a všem stávajícím instancím změnil chování nějaké metody?

Javu moc dobře neznám. V C++ bych asi věděl. Přes věci jako dll injection se dají dělat zajímavé divočiny.
Daleko lepší nápad mi ale přijde, pokud má daný systém nějaké zotavení z pádu, kontrolovaně shodit celý proces a nahradit ho novou verzí.

[BoneFlute]

To je oxymoron, kdyz chces mit vsechno zkontrolovane v dobe kompilace, nemuzes to pak vytvaret za chodu, a naopak.

Právě že můžeš. V tom je ten spor.

Kdyz se ty kouzla ve statickych jazycich delaji, proc nemaji plnohodnotnou funkci eval (ci jeji ekvivalent, treba pythoni compile) nebo repl?

Protože mají.
Haskell, Elm mají repl co je znám.

[Reklama]

[BoneFlute]

4) Jak bys v javě za běhu modifikoval třídu a všem stávajícím instancím změnil chování nějaké metody?

Javu moc dobře neznám. V C++ bych asi věděl. Přes věci jako dll injection se dají dělat zajímavé divočiny.
Daleko lepší nápad mi ale přijde, pokud má daný systém nějaké zotavení z pádu, kontrolovaně shodit celý proces a nahradit ho novou verzí.

Jedna možnost - reflexí.
Druhá možnost - něco kolem vzoru interpreter.
Záleží, jak bych to chtěl pojmout. Zda jako hack, nebo jako systém.
(Určitě existují další způsoby.)

[BoneFlute]

Imho budoucnost je v jazycich, ktere tohle vsechno volitelne pojmou a nic si nebudou vynucovat. Zaklad takoveho jazyku bude nutne dynamicky s tim, ze si programator bude moci dobrovolne rict, tady chci statickou kontrolu, tohle chci mit dynamicky, tohle chci mit objektove, tady mi staci procedury a tyhle data zpracuju funkcionalne. Python se tomu blizi i kdy ma jeste co zlepsovat. Ale treba python 4 prinese dalsi pokrok.

To je všechno možný. Jen připomínám, že otázka nezněla jaká bude budoucnost. Ale otázka zněla, jak je to s tím dynamickým myšlením. To je to, co nás už tři zajímá.

[BoneFlute]

Hlavně existuje polymorfismus zajišťující dostatečnou míru dynamičnosti při zachování bezpečnosti. A víc dynamicky prasit se dá typovými asercemi (typicky třeba v Go, které nemá generika), dokonce i v C++, kde to vypadá obzvlášť hnusně, ale účel to plní.

Go a jeho generování kódu polymorfních funkcí je nejvíc.

[Standa Blábol]

4) Jak bys v javě za běhu modifikoval třídu a všem stávajícím instancím změnil chování nějaké metody?

Javu moc dobře neznám. V C++ bych asi věděl. Přes věci jako dll injection se dají dělat zajímavé divočiny.
Daleko lepší nápad mi ale přijde, pokud má daný systém nějaké zotavení z pádu, kontrolovaně shodit celý proces a nahradit ho novou verzí.

Jedna možnost - reflexí.
Druhá možnost - něco kolem vzoru interpreter.
Záleží, jak bych to chtěl pojmout. Zda jako hack, nebo jako systém.
(Určitě existují další způsoby.)

Kdyz uz takovou potrebu, ze menim classes za chodu, vybec mam, je neco hodne spatne v architektonickem navrhu.
V realu tohhle vede leda tak k nedefinovanemu bordelu, protoze nedokazu zajistit, aby se objekt nemodifikoval v nejakem prechodovem stavu.

V Jave proto Spring Boot sestavuje aplikaci pri startu, classes kompozice se sestavi jako IoC assembly podle konfigurace, musi vsak splnovat interface, pres ktere to spring via @autowired slepi dohromady. Jak uz aplikace nabehne, do kodu se uz nehrabe, to je hovadina.

Obdobnou funkcionalitu muze poskytnou Java OSGi container, tam se ale za chodu nemeni jednotlive classes, ale services. Tam je mozne uhlidat konzistenci, vymeni se zkratka servica, coz je uplne jina immutable class se stejnym interfacem, stavajici runy zkratka dobehnou, servica se otoci s novou class a hotovo. Je to vlastne obdoba microservices v ramci JVM.
Ma to definovany lifecycle, ostatni spolupracujici servicy zpusobne pockaji, nez se moje servica otoci.
Mutace class za chodu, i kdyz to pres reflection api asi pujde, je tak leda gigabordel.
Dalsi aspekt, jak se ma zachovat serializace? Kdyz ponecham puvidni id serializace, tak lzu, a zpusobim tak leda pad JVM pri deserializaci. Kdyz mam id jine, coz spravne byt musi, je to defacto jina class.

[BoneFlute]

4) Jak bys v javě za běhu modifikoval třídu a všem stávajícím instancím změnil chování nějaké metody?

Javu moc dobře neznám. V C++ bych asi věděl. Přes věci jako dll injection se dají dělat zajímavé divočiny.
Daleko lepší nápad mi ale přijde, pokud má daný systém nějaké zotavení z pádu, kontrolovaně shodit celý proces a nahradit ho novou verzí.

Jedna možnost - reflexí.
Druhá možnost - něco kolem vzoru interpreter.
Záleží, jak bych to chtěl pojmout. Zda jako hack, nebo jako systém.
(Určitě existují další způsoby.)

Kdyz uz takovou potrebu, ze menim classes za chodu, vybec mam, je neco hodne spatne v architektonickem navrhu.
V realu tohhle vede leda tak k nedefinovanemu bordelu, protoze nedokazu zajistit, aby se objekt nemodifikoval v nejakem prechodovem stavu.

V Jave proto Spring Boot sestavuje aplikaci pri startu, classes kompozice se sestavi jako IoC assembly podle konfigurace, musi vsak splnovat interface, pres ktere to spring via @autowired slepi dohromady. Jak uz aplikace nabehne, do kodu se uz nehrabe, to je hovadina.

Obdobnou funkcionalitu muze poskytnou Java OSGi container, tam se ale za chodu nemeni jednotlive classes, ale services. Tam je mozne uhlidat konzistenci, vymeni se zkratka servica, coz je uplne jina immutable class se stejnym interfacem, stavajici runy zkratka dobehnou, servica se otoci s novou class a hotovo. Je to vlastne obdoba microservices v ramci JVM.
Ma to definovany lifecycle, ostatni spolupracujici servicy zpusobne pockaji, nez se moje servica otoci.
Mutace class za chodu, i kdyz to pres reflection api asi pujde, je tak leda gigabordel.
Dalsi aspekt, jak se ma zachovat serializace? Kdyz ponecham puvidni id serializace, tak lzu, a zpusobim tak leda pad JVM pri deserializaci. Kdyz mam id jine, coz spravne byt musi, je to defacto jina class.

Mě to nevysvětluj.

Ale uvedu taky příklad z praxe: mám aktorovej model. Takže spustím aplikaci, ta si natáhne těch pár tasků, a běží. V databázi je definováno, kdy se má který task spustit. Mezi tím přijde požadavek na nový task. Takže si ho napíšu, odladím, přihodím k aplikaci a - upravím záznam db! Aplikace se podívá a uvidí, že tam má další task, tak si ho načte, inicializuje, vyřeší závislosti a spouští podle plánu.

Nevím, mě to přijde dynamický hezky.

[Ondrej Nemecek]

Nic proti, ale byl bych opatrný při hodnocení co vede nutně k bordelu a co ne. Když si vezmete Smalltalk, tak ten běží už spoustu let víceméně z jednoho a toho samého image a classy se tam také mění za běhu... Změny se projeví v nových instancích, možná lze v některých implementacích i modifikovat běžící instance, to přesně nevím.

V javě lze taky načítat různé verze téže knihovny (s různými problémy, které to nutně přináší) a můžete do určité míry i modifikovat instance. Svoje využití to má, i když určitě nepůjde o běžné využití v aplikační logice. Ale pro instrumentaci, monitoring, profiling a debugging se to používá běžně, sem tam i pro tvorbu tříd za běhu (dynamické proxy, AOP).

[Johnny]

Nic proti, ale byl bych opatrný při hodnocení co vede nutně k bordelu a co ne. Když si vezmete Smalltalk, tak ten běží už spoustu let víceméně z jednoho a toho samého image a classy se tam také mění za běhu... Změny se projeví v nových instancích, možná lze v některých implementacích i modifikovat běžící instance, to přesně nevím.

U toho Smalltalku se změny projeví dokonce i u stávajících instancí, pokud jde o předávané zprávy, v případě přidávaných instančních proměnných jsou u stávajích instancí pochopitelně nil, ale i tehdy je lze dodatečně inicializovat.