Názory k článku Brython aneb použití jazyka Python ve skriptech přímo v prohlížeči

Pěkný článek, ale musím k němu mít terminologickou poznámku.

"Transpřekladač" jako termín je hrozný patvar. Původní termín "transpiler" vznikl spojením "translator" a "compiler". Ta první čast vychází z toho, že se překládá z jednoho jazyka do druhého (source-to-source), ta druhá označuje určitý typ nástroje. V češtině se ale pro "compiler" zažil termín "překladač", který už v sobě nese ten "překlad". Z čekož plyne, že zmíněný "transpřekladač" je fakticky pleonasmus typu lidová demokracie. A co hůř, kombinuje slova ze dvou odlišných jazyků, a navíc podle pravidel pro tvorbu anglických slov, takže to slovo v češtině vypadá naprosto nepatřičně.

Otázka je, zda má vůbec smysl rozlišovat mezi "compilery" a "transpilery", protože i u běžných překladačů velice často dochází k překladu do nějakého jiného (typicky nižšího jazyka), např. assembler, byte-kód, apod., a ničemu nevadí, když se to nerozlišuje od překledačů, které generují strojový kód přímo.

24. 10. 2019, 01:23 editováno autorem komentáře

To je velmi dobrá poznámka, dík. Kdybych nebyl "vycepovaný" z akademického prostředí to dost striktně rozlišovat, tak bych asi normálně psal překladač (druhá věc je, že terminologie není ustálená ani mezi jednotlivými VŠ, na což narážím například při čtení diplomek z jiných IT fakult).

Pokud mohu, přimlouval bych se do budoucnat za výraz "překladač".

Čistě z toho "akademického" hlediska lze chápat překladač jako funkci z jednoho jazyka do druhého (sjednoceno s množinou chybových stavů), přičemž tím druhým jazykem může být bez újmy na obecnosti jazyk stroje, jazyk virtuálního stroje nebo jiný (typicky nižší) jazyk (assembler, C). Z praktického hlediska není potřeba zavádět nový pojem. Ještě jsem se nesetkal se situací, kdy by bylo potřeba použít termín "transpiler". Pokud to není zjevné z kontextu (v drtivé většině případu to zjevne je), lze použít "překladač z něčeho do něčeho".

druhá věc je, že terminologie není ustálená ani mezi jednotlivými VŠ, na což narážím například při čtení diplomek z jiných IT fakult

Ono studenti (i pedagogové) umí (nebo spíš neumí) být kreativní a při přejímání a překládaní termínů jdou často cestou nejmenšího odporu. Slovo "transpřekladač" vypadá na první pohled relativně rozumně, protože předpona trans- se v českých slovech běžně vyskytuje, např. ve slově transatlantický. Je zde ale jiná etymologie. Tato předpona pochází z latiny a znamená "přes, za", což určitě nelze aplikavat na překladač (ve smyslu source-to-source), takže, jak jsem už psal výše takové slovo vypadá v češtině strašně nepřirozeně.

jj chápu, přístě si dám pozor. Díky!

porovnanie s nuitka by nebolo ? (https://nuitka.net/pages/overview.html)

A dá se to vůbec srovnávat, když Nuitka dělá, pokud mi něco neuniká, něco dost jiného?

Nuitka je taky transkompilátor, ale to je asi tak všechno co mají společné. Brython pracuje na hodně jiné úrovni převážně protože cílí na JavaScript, který má s Pythonem spoustu společné funkcionality. Pokud mi paměť slouží, tak se využívalo například resolvování atributů, volání funkcí a tak dál. Velká část vlastností tak může být emulována přímo vlastnostmi JavaScriptu, kdežto u Nuitky (a taky RPythonu) se kompiluje do C, kde z principu tohle použít nejde a je tak třeba z C vymodelovat chování interpretru a cílového programu na o dost nižší úrovni. Pokud by probíhal překlad Pythonu do JavaScriptu na stejné úrovni jako u Nuitky, bylo by to celé brutálně pomalé (ostatně takových pokusů bylo několik).

Proč by nešel použít React? Máte přístup k js objektům přes browser.window. Můžete použít libovolnou knihovnu. Můžete vytvářet callbacky. Nic víc nepotřebujete. Nechce se mi to zkoušet, ale podle mě nepotřebujete knihovny speciálně pro brython.

Pravda je, že jsem to taky nezkoušel (spíš se snažím front endu vyhýbat :-), ale dám tomu šanci, protože by to mohla být dobrá kombinace.

asi nebude problém, React jde dobře používat i bez JSX, tohle https://github.com/ustun/react-without-jsx půjde přepsat do pythonu 1:1

Osobně jsem na raných verzí Brythonu postavil dvě aplikace, jednu menší a druhou větší a dalo se to už tenkrát.

• Argparse builder
• WA-KAT

Tenkrát v tom ještě dost věcí nefungovalo a pro některé konstrukce bylo třeba hledat workaround. I tak se v tom ale dalo vyvíjet dost svižně, přestože jsem byl nucený postupně vytvářet cosi jako vlastní grafické rozhraní. Jak je poznamenáno v článku, ta rychlost za jak dlouho se načte interpreter je znát i dneska, pro spoustu aplikací to ale nemusí vadit.

v článku byly zmíněné různé překladače jazyka Lua do javascriptu. Myslím, že v tomhle ohledu stojí za to zmínit ještě jeden projekt a to Fengari - https://fengari.io/.

Na rozdíl od Brythonu se (v tomto případě Lua) nepřekládá do javascriptu, ale rovnou interpretuje virtuálním stojem. Ten byl v tomto případě ručně přepsán do javascriptu.

Jak, „rovnou interpretuje virtuálním strojem“. To není rovnou, to je další mezikrok, který akorát zpomaluje.

Místo aby se lua překládala na javascript, a ten se interpretoval a JIToval a překládal na machine code, tak se lua interpretuje v interpretru, který se interpretuje v javascriptu, který je JITovaný a jehož machine code jde nakonec do procesoru. To je cca 10-100x pomalejší než přístup brythonu.

Testoval jsem a pěkné. V praxi ne moc použitelné mimo intranetu. Chovám stále bláhovou naději, že jednou bude Python v browseru nativní, jako alternativa k JavaScriptu. Občas se někde nějaká zmíňka objeví, mohlo by to jednou vyjít.

Brython a další jsou zajímavé projekty. Je s podivem, kolik práce a energie do nich bylo vynaloženo.

Přitom by vlastně stačilo naprogramovat python engine do majoritních prohlížečů a žádný z těchto projektů by nebyl potřeba.

A to sa bude pre kazdy trochu viac pouzivany programovaci jazyk programovat do browserov engine pre dany jazyk? Fakt nestaci ten Javascript?

No asi nestačí, když vznikají projekty o kterých je článek.

Byli bychom zpět v devadesátých letech, kdy prohlížeče nepodporovaly jednotný jazyk.

24. 10. 2019, 11:42 editováno autorem komentáře

Naštěstí tu máme WASM, který má šanci tu homogenitu zvrátit z jiné strany.

Možná na některé specifické use-case.

Python jako clientside jazyk v prohlížeči tady byl ještě před tím, než vznikl JavaScript.
https://en.wikipedia.org/wiki/Grail_(web_browser)
Bohužel v některých ohledech předběhl dobu a neměl podporu velké firmy.

Ono by ale asi dlouho trvalo, než by se ten nový prohlížeč pořádně rozšířil i do různých obskurnějších zařízení. V tomto má JavaScript výhodu - prostě tam je a pokud je to starší verze, můžeme to obejít Babelem atd.

To ale není jenom. To je ohromný kus práce s mnoha temnými zákoutími. Třeba řešením bezpečnosti nebo mobilní platformy, kdy stejně nedokážete zaručit 99% dostupnost, jakou má js.

Po Brythonu pokukuji mnoho let, ale zatím jsem stále zdrženlivý.
Jeden z důvodů je, že v mém hlavním prohlížeči se stránka brython.info, kromě zeleného pozadí a baneru, vůbec nezobrazí.

Aktuálně:
Ubuntu 18.04.3 LTS
FF 70.0 (64 bitů)
AdBlock 0
NoScript 0 blokovaných ze 2
JS Enabled - ve stavu JS povolen
HTML 5 Autoplay - deaktivován
V jiném prohlížeči mi funguje.

== Máte zkušenosti s ostrým nasazením? ==

Dá se k Brythonu naimportovat např. knihovna PyMongo
a rovnou z browseru přistupovat ke vzdálené Mongo databázi?

== Jak je to se zpožděním při reloadu stránky? ==

brython.js se stáhne 1x při prvním spuštění aplikace a pak už jen kontroluje zda se na serveru nezměnil?

brython.js coby JavaScript se celý interpretuje po každém reloadu stránky?

> Dá se k Brythonu naimportovat např. knihovna PyMongo

Ne. Browser není počítač, nemá to třeba TCP/IP spojení a když už můžeš používat třeba websocket, tak to má vlastní limitace, z principu stejné jako v JavaScriptu (same origin policy a tak dál). Můžeš si napsat nějaký transport nad třeba REST API.

> brython.js se stáhne 1x při prvním spuštění aplikace a pak už jen kontroluje zda se na serveru nezměnil?

To záleží jen na tom jak máš nastavené hlavičky na serveru. Pokud si nastavíš správě cacheování, tak se to bude cacheovat.

> brython.js coby JavaScript se celý interpretuje po každém reloadu stránky?

To bohužel jo. Má to tendenci na vteřinu / dvě zasknout celý prohlížeč.

Jen poznámka k tomu dotažení brython.js - jak píše Bystroushaak, pokud je správně nastavený HTTP server, tak bude posílat korektní informace o tom, jestli se resource změnil nebo ne (pro hlavičku dotazu If-Modified-Since). Takže se brython.js dotáhne jedenkrát a potom zůstane v cachi prohlížeče. Až se vydá nová verze Brythonu a vy ji použijete, natáhne se do prohlížeče znovu.

Jde to vyzkoušet i přímo na stránce www.brython.info. Poprvé ji normálně načtěte, potom si zobrazte tab Network (Ctrl+Shift+E) a můžete sledovat, co se bude dít po reloadu (F5):

200 GET www.brython.info      /                     document      html  4.66 KB 12.92 KB     53 ms
200 GET fonts.googleapis.com  css?family=Montserrat stylesheet    css   996 B   1.80 KB      71 ms
304 GET www.brython.info      brython.js            script        js    cached  684.83 KB    85 ms
304 GET www.brython.info      doc_brython.css       stylesheet    css   cached  3.77 KB     227 ms
304 GET www.brython.info      brython_tp.png        img           png   cached  1.57 KB     135 ms
200 GET www.brython.info      favicon.png           img           png   cached  299 B ...

Ten skript je největší resource, ovšem je cachovaný a dotáhne se tedy z lokální cache ihned poté, co server odpověděl kódem 304.

Ale stejně - pokud máte OPA, je (IMHO) Brython fajn řešení, pokud však aplikaci typu Root, kde se jednotlivé stránky pořád dotahují celé, tak se ztratí moc času inicializací celého překladače.

Děkuji vám oběma za upřesnění.

Bylo by na zajímavé zamyšlení obejití opakované interpretace brython.js
Je to obecný problém opětovného interpretování velkého bloku JS.
Určitě to někdo někdo řešil a snad i vyřešil.

Od boku mě napadají směry:
- obalení stránky "blokem/rámem/fra­mem", který se nebude znovu načítat a obsah se bude načítat a vykonávat uvnitř.
- převod brython.js do nějakého JS ASM nebo ještě hlouběji
- schopnost prohlížeče, zachovat již jednou zpracovaný .js např. v rámci domény (samozřejmě promyšlený s ohledem na bezpečnost)

píše to něco do konzole?

Ahoj

Díky, že jsi mě nasměroval (resolved nefunkční obsah na brython.info).

První 4 řádky výpisu:

uncaught exception: Object

[Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMWindowUtils.addSheet]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: resource://gre/modules/ExtensionCommon.jsm :: runSafeSyncWithoutClone :: line 75"  data: no] ExtensionCommon.jsm:75:12
    runSafeSyncWithoutClone resource://gre/modules/ExtensionCommon.jsm:75
    cssPromise resource://gre/modules/ExtensionContent.jsm:520
    InterpretGeneratorResume self-hosted:1300
    AsyncFunctionNext self-hosted:839

[Exception... "Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIDOMWindowUtils.addSheet]"  nsresult: "0x80070057 (NS_ERROR_ILLEGAL_VALUE)"  location: "JS frame :: resource://gre/modules/ExtensionCommon.jsm :: runSafeSyncWithoutClone :: line 75"  data: no] ExtensionCommon.jsm:75:12
    runSafeSyncWithoutClone resource://gre/modules/ExtensionCommon.jsm:75
    cssPromise resource://gre/modules/ExtensionContent.jsm:520
    InterpretGeneratorResume self-hosted:1300
    AsyncFunctionNext self-hosted:839
    $download_module https://brython.info/src/brython.js:8840
    find_spec https://brython.info/src/brython.js:9061
    method https://brython.info/src/brython.js:5321
    find_spec https://brython.info/src/brython.js:9048
    f https://brython.info/src/brython.js:6372
    method https://brython.info/src/brython.js:6376
    import_hooks https://brython.info/src/brython.js:13370
    $__import__ https://brython.info/src/brython.js:9104
    $import https://brython.info/src/brython.js:9137
    anonymous https://brython.info/src/brython.js line 5202 > Function:21
    loop https://brython.info/src/brython.js:5202
    _run_scripts https://brython.info/src/brython.js:5088
    brython https://brython.info/src/brython.js:5010
    onload https://brython.info/:1

Chyba zabezpečení: Dokument na https://brython.info/ nemůže načítat nebo odkazovat na moz-extension://e2984dc2-4e2a-438a-b061-d48f48154fe4/js/Lib/site-packages/header.py?v=1572002494195.

Chyba zabezpečení: Dokument na https://brython.info/ nemůže načítat nebo odkazovat na moz-extension://e2984dc2-4e2a-438a-b061-d48f48154fe4/js/Lib/site-packages/header/__init__.py?v=1572002494321.

Z toho jsem zjistil, že něco z brythonu teče přes

extension://e2984dc2-4e2a-438a-b061-d48f48154fe4/

což je u mě Disable HTML5 Autoplay (i když by nemělo).

Při zastavení Disable HTML5 Autoplay brython.info funguje.

Zkoušel jsem tedy hledat náhradu za toto, již neudržované rozšíření a je to celkem zamotané:

https://github.com/Eloston/disable-html5-autoplay/issues/175

Ve FF to budu řešit nastavením v about:config

media.autopla­y.default na 1

dle

https://www.ghacks.net/2018/09/21/firefox-improved-autoplay-blocking/

Podobné nastavení se dá najít v

about:preferen­ces#privacy

Oprávnění -> Automatické přehrávání -> Nastavení -> blokovat přehrávání videí a medií se zvukem

Mintaka

BTW: Nefungovaly mi některé captchy. Vůbec se na stránce nezobrazily, jen mi to vynadalo, že jsem je nevyřešil a nepustilo mě to dál, což třeba při vyplnění komplikovaného formuláře naštve. Možná se tím vyřeší i tento problém.

25. 10. 2019, 14:14 editováno autorem komentáře

Je dobrej nápad přímo z browseru, kde je uživateli k dispozici zdrojový kód, přistupovat k db, ke který potřebujete přihlašovací údaje?

Zrovna bezpečnost je jedna z věcí, kterou jsem tím kódem na straně uživatele chtěl posunout zase o kousek dál.

Databáze by mohla být i na localhostu, ale v principu kdekoliv, dostupná po TCP.
Volitelně zde může být dvoufaktorová autentizace přes SMS nebo email a několik dalších opatření.

V této aplikaci má každý uživatel svou vlastní databázi. Uživatelé jsou v bezpečnosti svých zařízení "pokročilí", jejich stroje mají nadstandardní zabezpečení, bohužel přístup nelze omezit na konkrétní IP/MAC., někteří však přistupují přes VPN do bezpečnější sítě a pak teprve ven.
Heslo do DB by bylo složením saltu, který přišel po https ze serveru + toho co by zadal uživatel přímo v aplikaci a měl uložené jen u sebe.

Aktuálně to funguje tak, že k databázím uživatelů se připojuje server s aplikačním kódem se svým saltem+hashem hesla uživatele. (Změna hesla uživatele je pak bohužel netriviální operace.) Databáze jsou mimo server s aplikační logikou.

Ovšem heslo byť ve formě hashe odchází od klienta na server.
Navíc, data v databázi jsou šifrována na úrovni jednotlivých záznamů/dokumentů jde o MongoDB ale principiálně by šlo použít téměř libovolné SŘBD.

Data z databáze jsou nahrána na server, kde jsou rozšifrována a po dobu přihlášení uživatele jsou kompletně v RAM serveru. Odtud jsou používána pro vytváření stránek dle požadavků uživatele.
Čtení je ze záznamů v RAM serveru, zápisy do DB se v samostatných vláknech šifrují a ukládají do zdrojové databáze, takže se tím nezdržuje samotný běh aplikace a uživatel na to nečeká.

Od možnosti přihlášení k DB přímo z browseru od uživatele bych si sliboval:
- zmenšení nároků na RAM serveru (od 15 do 200MB na uživatele, medián ~70MB)
- snížení zátěže serveru
- zrychlení odezvy (teď je dobrá, ale mohla by být ještě lepší)
- zvýšení zabezpečení (rozšifrovaná data by byla jen v prohlížeči nikoliv v prohlížeči a ještě i na serveru)
- lepší možnosti offline funkčnosti

Pokud v tom vidíte problém, který možná nevidím, budu rád za připomínky.

PS:
Tady to vypadá, že by přímé připojení do MongoDB z JS mělo být možné:
https://dzone.com/articles/crud-operations-on-mongodb-thru-nodejs
https://www.tutorialsteacher.com/nodejs/access-mongodb-in-nodejs

Kdyby to přes REST API nešlo, i tak by šlo využít server k předání šifrovaných dat k uživateli a rozšifrování a uložení pracovní kopie dat by se řešilo až v browseru a v RAM uživatele.

Trošku mě překvapila zmínka o CoffeeScriptu. Skutečně je už mrtvý nebo v tom ještě vznikají NOVÉ projekty? Sám vím, že je v něm psaný Atom a i GitHub announcoval, že ho používá/používal. Má prosím někdo zkušenosti s tímto jazykem v reálném provozu? (asi ho stejně nepoužiju, ale jsou tam pěkné myšlenky, takový JS+Python mix style :-)

V reálném provozu je bez problémů, výsledný javascript dobře čitelný (oproti třeba Brythonu, kde to bez source map asi nepůjde). Většina featur z původního coffeescriptu byla přidána do javascriptu. Dobrovolně bych to dnes určitě nepoužíval, ale setkávám se s tím. Dávám přednost čistému javascriptu.

24. 10. 2019, 20:29 editováno autorem komentáře

Bylo by dobré, kdyby tento mechanismus podporovaly prohlížeče. Pak by odpadlo ono náročné stahování knihoven.

Python používám fakt dlouho, ale ten předpoklad, že je to lepší jazyk než moderní JS, je podle mne špatně. Python používáme na backendu (protože JS sme předtím moc neuměli). Používáme ho pro zpracování dat a numeriku/simulace jako lepidlo pro knihovny napsané v C/C++/Fortranu a ML. Ekosystém docela fajn, ale jako jazyk -- nic moc a design knihoven jako Numpy, Scipy, Pandas, Matplotlib :/. Ten jazyk je prostě rozbředlej a nemá jasný paradigma. Lidi se v něm naučí skriptovat, ale psát v tom robustní kód nebo aplikaci je už těžký a chce to netriviální zkušenosti s OOP. Třeba F# nebo OCaml/Reason jsou nejen lépe navržený jazyky ale navíc mají transpilaci do JS a spolupráci s JS knihovnama defakto vyřešenou. Python má svoji niku, ale webový frontend to asi nikdy (doufám) nebude. Už tak je zázrak, že se JS ekosystém nějak ustálil.

Souhlasím, že JS není horší než Python. O Reasonu tu vycházel seriál, pokud si vzpomínám, má také své mouchy, třeba defaultní řetězce nepodporují unicode. Podpora asynchronního programování oproti modernímu JS dost ubohá.

JS jako jazyk je zcela objektivně podstatně horší než python, z mnoha různých důvodů. Ostatně to si uvědomují i tvůrci různých nadstaveb (teď je co? ECMAScript 2019? kolik lidí to fakt používá?). Za všechny nevýhody například různé datové typy, kde javascript působí v porovnání s pythonem i díky weakly typed proměnným, nebo jednomu numerickému typu, jak bahno, kde se ti věci přetypovávají z jednoho typu na druhý místy úplně náhodně. Na zbytek viz https://whydoesitsuck.com/why-does-javascript-suck/

Samozřejmě pak další věc je standardní knihovna, kde javascript nemá žádnou, kdežto python má slavné "batteries included" a s čistou instalací je možné dělat všechno možné. Nutno poznamenat, že oba jazyky to pak hodně dotahují přes package managery.

Rád bych taky rozporoval to co tu naznačovali někteří diskutující, tedy že v pythonu se nedají psát velké aplikace, nebo že je to nějak extra náročné. Není. Sám momentálně mám v IDE otevřen projekt, čítající dle `cloc` utility počítající jen samotné řádky kódu bez komentářů, 123178 řádků kódu. A to je jedna monolitická aplikace. Další backendové věci pak mají své stovky tisíc řádků kódu.

Na pythonu běží například celý backend uložto, většina služeb seznamu, nebo google. Všechno firmy, které musí obsloužit stovky desítky tisíc až miliony zákazníků najednou. V pythonu jsem pracoval například na projektech rozpoznávání obrazu, trackování lidí na kamerách a tak podobně, tedy i věcech, kam se zdánlivě nehodil, protože by člověk očekával potřebu nějakého většího výkonu. Opět věci, které měly stovky tisíc řádků kódu, typicky stačilo přepsat pár procent do C/C++/Rustu a celé to fungovalo krásně.

Co uznávám, tak je pravda, že nejde prostě jen tak přijít a aplikovat svoje pochopení jak psát tenhle druh aplikací třeba z C, nebo (typicky) z Javy. Pokud se o to člověk bude snažit, tak narazí. Ale to by narazil i kdyby přišel z toho C do Javy. Prostě má vlastní filosofii.

Stěžovat si, že nemá jasně dané paradigma, když je to z definice už od úplného začátku multiparadigmatický jazyk je tak nějak nepochopení jedné z hlavních výhod a vydávání jí za nevýhodu.

Samozřejmě, python má taky spoustu svých nevýhod, ale typicky se nachází někde úplně jinde, než kde se do něj opírá spousta kritiků. Například balíčkování přes setuptools je příšerné a vrství se tam spousta bahna a historické špíny. Logovací framework je javovina. Optional typing přes mypy je nedotažený a pořád si myslím že se na to mělo jít přes docstringy ala "napoleon / google style". Asyncio je místy nedotažené a jeho debugování je peklo. Podpora unicode už sice byla dotažena, ale pořád to umí člověka hodně nepotěšit, speciálně když teď některé metody chtějí bytes místo stringu a naopak, takže člověka nutí neustále zbytečně přetypovávat. CPython je místy brutálně pomalý a v podstatě nechápu, proč se místo něj masivně nepoužívá pypy, které umí být na některé věci cca 1000x rychlejší.

Nechtěl jsem krmit "troly", kteří nepřišli s něčím konkrétním, ale když jsi se toho ujal, tvá slova podpořím.

Ano Python není nejlepší jazyk na všechno, ale ve spustě případů je dost dobrý.

JavaScript v browserech těží z monopolu, který tam má a jak moc je "dobrý" je vidět na neutuchajících snahách se mu nějakým způsobem "vyhnout".

Osobně jsem to s ním zkoušel, několikrát poprvé už v roce 1997.

Na vtipné rozpohybování stránek a kontrolu formulářů to ještě šlo, později na Ajax věci to bylo téměř nutností, ale vždy jsem se dostal do situace kdy jsem vychytával problémy JS způsobené nekoncepčností a "podivným" chováním, na které jsem za ta léta nezvykl.

Jasně JS je dnes někde jinde než byl před 25 let. Ale...
Posledních pár let mě třeba významně iritují vznikající a upadající nástavby nad JS, které s velkým hypem přichází, aby za pár let upadly v zapomnění.
Peklo při debugování zkrz nepřehledné knihovny.
Hromada balastu v Node.js.
A také nenažranost na prostředky.
Proč mi jediná stránka Gmailu sežere 500MB RAM!?!
Zrovna u tak klíčové aplikace, neřku-li vlajkové lodi JS, bych očekával výstavní chování a ono to na jedné stránce sežere víc paměti než celý OS s grafickým prostředím, s drivery a několika aplikacemi, funkčně významně bohatšími než nějaký webový emailový klient.

Rád bych věřil, že prohlížeče postaví, dobře navrženou nižší vrstvu do které bude možné překládat zdrojáky z různých jazyků. ASM.JS může být dobrý směr i když samotné stránky http://asmjs.org/ vypadají žalostně.

Tak ať nám ty "trans"-překladače fungují a je méně bolehlavu a více dobře fungujících aplikací.

> Posledních pár let mě třeba významně iritují vznikající a upadající nástavby nad JS, které s velkým hypem přichází, aby za pár let upadly v zapomnění.

To bylo o dost víc než "před pár lety". V posledních letech naopak skoro všechy ty CoffeScripty pomřely a prakticky jediná používaná nástavba je Typescript. Přidává do Javscriptu silnější typování, což je jediná zásadní věc, která v moderních verzích chybí. A její duck typing je naopak velmi silný nástroj. Když si vzpomenu, kolik zbytečných řádků jsem musel napsat třeba v Javě...

> Peklo při debugování zkrz nepřehledné knihovny.

No tak používej přehledné knihovny.

> Hromada balastu v Node.js.

Ugh?

> Proč mi jediná stránka Gmailu sežere 500MB RAM!?!

To fakt netuším. Mě žere 150MB.

Re. To bylo o dost víc než "před pár lety".
To jsem rád, že se to snad stabilizuje, byť ještě před necelým rokem jsem byl na přednášce, kde to JS odnožemi jen sršelo.

Re. No tak používej přehledné knihovny.:
To se snadno řekne, pokud si ten projekt řídíte od začátku, což se nepoštěstí pokaždé.

Re. Node.js.:
Možná chyba na mé straně, když jsem se pokoušel prozkoumat co je uvnitř.

Re. Gmail a 500MB RAM:
Mám 100 mailů na stránku, černé pozadí a zapnutých několik rozšíření.
Jsem ze staré školy. I 150MB na jednu stránku mi přijde obludně hodně. "Nedávno" jsme jeli na počítačích s 64MB RAM a stačilo ke svižnému běhu OS, webovému prohlížeči a dalším několika najednou spuštěným aplikacím.
Co tam žere těch 150MB? Jako že to načítá do RAM přílohy těch mailů pro případ, že by si to chtěl uživatel prohlédnout? Kde to vypnu?

Tim trolenim si myslel co? Jiny nazor nez mas ty?

Možná jsem se ve tvém případě unáhlil, ale názor:

<i>Ekosystém docela fajn, ale jako jazyk -- nic moc a design knihoven jako Numpy, Scipy, Pandas, Matplotlib :/. Ten jazyk je prostě rozbředlej a nemá jasný paradigma. Lidi se v něm naučí skriptovat, ale psát v tom robustní kód nebo aplikaci je už těžký a chce to netriviální zkušenosti s OOP.</i>

mi přijde tak daleko od reality, že jsem to bral jako trolení.

Jednotlivě:

<i>Ekosystém docela fajn, ale jako jazyk -- nic moc </i>: Nechápu, jak by si Python vybudoval skvělý ekosystém, bez peněz velké firmy, aniž by jako jazyk byl "nic moc".

<i>design knihoven jako Numpy, Scipy, Pandas, Matplotlib</i>: Že by na designu těch knihoven nebylo co vylepšit si nemyslím

<i>Ten jazyk je prostě rozbředlej a nemá jasný paradigma.</i>: Má jasné multiparadigmatické paradigma.

<i>Lidi se v něm naučí skriptovat, ale psát v tom robustní kód nebo aplikaci je už těžký</i>: Jako by to bylo v některém jazyce jednoduché. Stovky aplikací napsaných v Pythonu tedy ukazují, jak je život programátorů "těžký".

<i>chce to netriviální zkušenosti s OOP.</i> Chce to především netriviální znalosti dekompozice, izolace, dodržovat DRY, KISS a další osvědčené postupy softwarového inženýrství. Jestli tam někdo použije OOP může být užitečné ale rozhodně ne nezbytné.

Ano, můj názor je odlišný a v tom příspěvku mi přišlo být tolik nesmyslů, až mi to přišlo jako trolení.

26. 10. 2019, 16:45 editováno autorem komentáře

Za příspěvek dávám plus, je vidět, že jsi člověk z praxe. Mám také zkušenosti s velkými projekty v Pythonu, v zásadě jako největší problém vnímám GIL. Přechod na PyPy u některých produktů asi zvážíme, myslím, že už by to mohlo být na pořadu dne.

Jako zcela zásadní mi přijde ovšem znovu zdůraznit užitečnost multiparadigma­tického programování. Procedurální, funkcionální a do jisté míry i objektově orientované se výhodně doplňují a ten trend je vidět ve většině moderních jazyků. Čisté OOP je z nouze ctnost, klasické procedurální programování je otročina a čisté FP musí různě bojovat s reálným světem, kde důležitou roli hrají čas a změna.

S čím konkrétně musí bojovat FP? Prosím zohlednit vývoj překladačů (například Haskellu) v posledních letech, abychom neopakovali již neplatné, desetiletí staré argumenty.

Aha a když si chci jen tak náhodně něco zalogovat, už nemusím používat Unsafe IO?

Ano, JS je objektivně horší, v nepodstatných detailech. V praxi malé nekonsistence moc nevadí, většinou na to upozorní IDE. Na interaktivní aplikace, kde se často používají callbacky, je JS podle mě lepší díky plnohodnotným anonymním funkcím.

> Optional typing přes mypy je nedotažený a pořád si myslím že se na to mělo jít přes docstringy ala "napoleon / google style".

docstringy neumožňují introspekci. Současné anotace lze kontrolovat i za běhu, využívá to třeba knihovna pydantic, docela užitečná věc, můžete stejné anotace použít pro statickou analýzu i validaci vstupů.

naopak v JS jsou podle mě lepší typové anotace v docstringu než anotace odstraňované při transpilaci.

> docstringy neumožňují introspekci.

oprava. Umožňují. Není problém je rozparsovat za běhu, ale v praxi se to asi moc nepoužívá.

26. 10. 2019, 12:47 editováno autorem komentáře

Python nemusí být všude lepší, než JS, proto jsem schválně psal, že pro _některé týmy_ je lepší. Když mám například tým, který pracuje především v Pythonu a webovka je jen by product pro interní použití, tak se to dá jednoduše celé udělat v Pythonu (včetně back endu) s tím, že do toho front endu může případně zasáhnout každý, každý bude znát celý tooling, IDEčka atd. Ale někdo to má přesně naopak - celý stack v JS, tam je to něco jiného.

Minimálně jeden velký webový framework má koukám i brython binding projekt :) Asi to vyzkouším.

https://stefanhoelzl.github.io/vue.py