Vlákno názorů k článku Brython aneb použití jazyka Python ve skriptech přímo v prohlížeči od Wavelet - Python používám fakt dlouho, ale ten předpoklad, že...
-
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.
-
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í.
-
L.Stříbrný podporovatel
> 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? -
L.Stříbrný podporovatel
> "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.
To museli psát hrozný matláci. když to bylo takhle náročný. Já dělal na počítači, kde na podobné věci stačil 1MB RAM, 2 MB pokud jste se praštil přes kapsu (Amiga).
> Co tam žere těch 150MB?
To nevím, já to nepsal :-D Můžete si přes DevTools udělat memory dump toho JS enginu a koumat ;-) Tipuju ale, že to bude nějaký základ JS mašiny, virtuální DOM aplikace a pak další data (?). Plus to využití se mění s časem - když stránku otevřu, bere mi nějakých 67 MB, s časem to narůstá, asi jak si nějaké věci cachuje.
Každopádně i těch 150MB je 1% paměti mého počítače, tedy nic, co by mi nedovolovalo usnout. Jak říká staré programátorské přísloví: "Předčasná optimalizace je horší, než předčasná ejakulace." A nejhorší je, když člověk trpí obojím najednou :-D
-
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
-
"Nechápu, jak by si Python vybudoval skvělý ekosystém, bez peněz velké firmy, aniž by jako jazyk byl nic moc"
Úplně stejně jako JS -- pokud jde o knihovny. Že by Python byl (i v minulosti) bez podpory není tak úplně pravda https://www.python.org/psf/sponsorship/sponsors/Python má spoustu knihoven, ale množství nikdy neznamená výhodu. V době vzniku, nebo lépe řečeno od verze 2.X měl Python oproti jiným jazykům výhodu. Nebyl tolik ukecaný, byl objektový, ale člověk nemusí vše balit do třídy a je přehlednější než např. Perl. Nicméně dnes je jeho model dost zastaralý, proto se přidává typování, dataclasses apod.
"Má jasné multiparadigmatické paradigma." To už ukázalo C++ že žádná výhoda není.
"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é."
Samozřejmě, ale je lepší se to naučit na ne tak benevolentním jazyku. Realita je taková, že spousta lidí s Pythonem začne a také u něj skončí.
Mě Python jakž takž živí a je to první jazyk po kterém sáhnu, protože v něm dělám rychle, ale nějak mám pocit že trpíte Stockholmským syndromem.
Celý to povídání je o tom, že oproti JS nemá Python na frontendu žádnou výhodu. To je můj názor a tím to můžem uzavřít.
-
> Nicméně dnes je jeho model dost zastaralý, proto se přidává typování, dataclasses apod.
To mi přijde jako fakt hodně odvážné tvrzení. Python se kontinuálně vyvíjí od svého vzniku a něco se do něj přidává neustále. Například dávno před dataclasses tam byly přidány namedtuples, nebo context manager, či list comprehensions / generator expressions. Pochybuji, že by to někdo vnímal jako že "model je dost zastaralý", tak přidáme dataclass. To ostatně ani nedává žádný smysl, tím by se model nijak neomladil.
> "Má jasné multiparadigmatické paradigma." To už ukázalo C++ že žádná výhoda není.
Podle mě není validní takhle použít diskuzní argument. C++ nedokazuje naprosto nic o pythonu. Problémy C++ nejsou problémy pythonu. To že tam něco nefungovalo (a fakt to nefungovalo? kde jsou čísla a studie?) těžko něco dokazuje o funkčnosti či nefunkčnosti někde jinde. I kdyby to náhodou bylo validní, tak C++ má spoustu problémů, které s pythonem nijak nesouvisejí a ovlivňují a zkreslují validitu tohohle porovnávání.
-
To je zvláštní, že chcete čísla a studie, když sám píšete subjektivní názory a vydáváte je za objektivní.
"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í."Dropbox: "Although Python is really good at early and middle stages of a project, at a certain point successful projects and companies that use Python may face a critical decision: “should we rewrite everything in a statically typed language?”
A tak samozřejmě že se v tom dá napsat velká aplikace, co se týká řádků kódu, ale jestli je to nejlepší nápad, to bych netvrdil.
Seriózní porovnání přepisu Python->OCaml http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-retrospective/#background
Já si ponechám Python na malé a střední projektíky a prototypování.
28. 10. 2019, 12:31 editováno autorem komentáře
-
Re. Celý to povídání je o tom, že oproti JS nemá Python na frontendu žádnou výhodu. To je můj názor a tím to můžem uzavřít.:
Celé je to o tom, že Python jsem si vybral, z těch mnoha jazyků se kterými jsem se setkal, za nejvhodnější jazyk, jehož filozofie, návrh, syntaxe, chování, schopnosti, knihovny, vývojové nástroje, komunita, ..., mi vyhovují víc v případě jiných jazyků.
A jiní lidé si z podobných důvodů vybrali zase jiné jazyky.Nemyslím si, že je dobré a vhodné, aby byl svět webového frontendu, který je dnes de-facto novým OS prostředím, vyhraněn pouze jedinému jazyku.
Že JS, není "ten jediný správný jazyk", který by dostatečně vyhovoval všem, jde vytušit z té obrovské snahy a energie věnované různým překladačům
https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-jsOsobně se domnívám, že závislost na JavaScriptu bude jen porodní a batolecí epizoda prvních desítek let existence webového frontendu.
"Brzy" snad nebude nutné psát komplikované překladače do JS a bude stačit psát překladače do dobře navrženého, bezpečného, optimalizovaného a standardizovaného "strojáku" pro prohlížeče.PS: Ono by neškodilo se na celý ten komplex TCP/DNS/webserver/cache/webbrowser/DOM/HTTP(S)/HTML/CSS/JS/... podívat pěkně od základů a navrhnout efektivní řešení.
-
> "Brzy" snad nebude nutné psát komplikované překladače do JS a bude stačit psát překladače do dobře navrženého, bezpečného, optimalizovaného a standardizovaného "strojáku" pro prohlížeče.
To je možné už dnes, ale kvůli výkonu to má to smysl jen u aplikací nepracujících s DOMem. Javascript jako jazyk na webové aplikace to nahradit nemá. I na JVM stále dominuje Java, přitom rozdíl v produktivitě mezi Javou a třeba Kotlinem je ohromný. Javascript se na rozdíl od Javy průběžně zlepšuje, přebral většinu lákadel alternativních jazyků. V posledních letech nepozoruji poptávku po něčem novém. Ekosystém se stabilizoval, vývojáři jsou spokojeni. Kdo nadává na Javascript, většinou nadává i na webové technologie obecně, není webový vývojář. Nelze brát jeho kritiku vážně.
-
Java se taky zlepšuje, třeba konečně do ní přidali víceřádkové řetězcové literály. Kvalitu jazyka, jak dokládají problémy třeba s C++, ale neurčuje jenom to, co do něj kdo přidá, ale taky co v něm není.
DOM bude: https://github.com/WebAssembly/proposals/issues/16
-
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 multiparadigmatické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.
-
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.
-
Pavel TišnovskýZlatý podporovatelPython 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.
