Portál AbcLinuxu, 20. května 2025 23:43
Tiskni
Sdílej:
Tak ono se to celkově blbě popisuje, zvlášť když lidi čtou třeba jen každou třetí větu, přeskakují úvod, dívají se čistě jen na screenshoty a nic jiného, když čtou že to je bez JS tak to okamžitě odepíšou na základě vlastní negativní zkušenosti a přitom hned za tím je napsáno jak se právě tenhle problém řeší těma opravnýma skriptama. Aspoň tyhle různé věci jsem vydedukoval z různých komentářů co lidi psali.To chapu ze je na hovno, ale myslim si, ze nejaky screenshoty by prave pomohly tomu aby si kazdej udelal prvotni obrazek a pripadne "neztracel cas s necim co nefunguje". Proste screenshot "web xy ve firefoxu" vs. "web xy ve firefoxu pres FixProxy", pripadne pridat cas nacteni nebo tak neco, aby clovek videl "ok, to je zajimava myslenka".
Nepomáhá že jsou to vlastně dvě aplikace, jedna je browser (kterej zatím není praktickej na používání) a druhá proxy (kterej naopak je v pohodě na používání).Jo, to muze byt trochu matouci. Neni mi uplne jasny proc se snazit delat browser v takovym pripade, kdyz lightweight je relativne dost, a prave pridanim FixProxy bys z nich mohl udelat neco pouzitelnyho.
Teď naposled si někdo myslel že screenshot ukazující něco v tý proxině je ten browser a zmínil to jen protože si všiml že tam je ikonka doplňku uBlock Origin a divil se že to v tom prohlížeči může fungovat když je to alfa verze. A přitom je to screenshot Firefoxu kde se používá právě ta proxy.Imho jednoduchej popisek pod screenshotem by pomohl, pokud byl a nepomohl, tak se s tim netrap, v takovym pripade je komentujici spis mimo.
už zkompilovaný to hele mužeš stahnout u nich na webu :O ;D
nóó menuje se to fixbrowser tak si ňák hele todlecto fixni :D ;D
function main() { var arr = [10, 20, 30]; // append to end: arr[] = 40; arr[] = 50; for (var i=0; i < length(arr); i++) { log(arr[i]); } }
arr[] = 40;
. Celkově mi přijde, že ta syntaxe je hrozně nedodělaná. U embedovatelného skriptovacího jazyka očekávám minimalistický, ale kompletní seznam featur. Nepřijde mi úplně užitečné mít možnost syntaxi rozšiřovat (zvlášť, když se to píše v C).
Nemáš nějaké benchmarky? Mě ty tvoje argumenty nepřesvědčili, např. LuaJIT je sice separátní projekt, ale zato pro víc platforem atd. Většina těch věcí je spíš věc názoru a vzhledem k lepšímu toolinga a více knihovnám pro Luu to moc přesvědčivě nevypadá.
.length
nebyl čistě z důvodu toho že sem byl navyklej na length()
, od té doby je to již implementované, protože je to lepší.
Neměli bychom zapomínat na to, že samotný vyšší programovací jazyk (např. Java nebo PHP) spolu se svojí standardní knihovnou jsou samy o sobě frameworkem, stejně jako je frameworkem UNIX (resp. dnes převážně GNU/Linux) a že poskytují víc než dostatečnou úroveň abstrakce pro vývoj mnoha aplikací. Přidání jakékoli vrstvy nad ně bychom neměli vnímat jako samozřejmost a měli bychom toto rozhodnutí mít vždy dobře zdůvodněné a podložené.Je to o hledání nějaké rovnováhy – na jednu stranu chceš znovupoužitelnost a nevynalézat pořád kolo nebo kopírovat kód a na druhou stranu se nechceš utopit v hromadách (přímých a tranzitivních) závislostí. Proslulý je tím zejména webový frontend a JavaSript, kde se v rámci buildu stáhne a přibalí půlka internetu. Bohužel se tenhle trend dostal i do Javy, kde aplikace postavené nad Springem psané „moderně“ dělají totéž. Když se pak autorů zeptáš, proč je tam přibalená ta či ona knihovna a k čemu ji používají, tak většinou neví. Ve světě Javy EE / Jakarty je od toho člověk odstíněn a píše proti standardu. A o tu implementaci (nalezení fungující kombinace různých knihoven) se starají autoři aplikačního serveru. Ve světě OSGi taky aspoň nebalíš ty knihovny ke své aplikaci a jen deklaruješ závislosti tzn. nedodáváš stovky megabajtů velká JARka jako u Springu, ale jen třeba desítky nebo stovky kilobajtů svého modulu. Někdy závidím kolegům, kteří píší primárně PL/SQL nad Oraclem. Jazyk je to sice dost zastaralý a nepohodlný (myslím PL/SQL, ne SQL), ale skvělé na tom je, že se tam běžně nepoužívají žádné dodatečné knihovny – máš prostě jen standardní knihovnu / běhové prostředí, a to ti stačí k tomu, abys napsal aplikaci, vytvořil systém, který něco netriviálního a užitečného dělá.
A čo ty si spravil pre slovenský hip-hop?
Kolik peněz si zaplatil, nebo kolik času věnoval na odstranění těch warningů?!
Tak lidí, co píšou co by se mělo dělat, těch má samozřejmě většina opensource projektů dost (až přebytek, řekl bych), problém jenom je, že žádný takový článek ještě sám o sobě neopravil jeden jediný řádek v žádném projektu...
| grep warirnigs | wc -l
. A obecně ke všem jazykům, někdy hlavně nechápu počet externích knihoven.
Hele, já bych taky pověsil každého, kdo do projektu zatáhne Google protocol buffers (to by se mělo na školách ukazovat jako exemplární příklad jak se nemá dělat SW) za koule do průvanu, ale nechápu, co je na té explozi externích knihoven k nepochopení. Důvod je zcela triviální - běžný programátor je prostě jenom líný/neschopný si danou funkcionalitu napsat sám, tak prosté to je. Když k tomu přidáš existenci balíčkových manažerů, kde získat danou funkcionalitu je otázkou doslova jednoho jediného řádku nebo v horším případě Dockeru (to pro ty nešťastné jazyky/platformy, kde to o jednom řádku není), do kterého se celý ten build bordel zabalí, tak proč by si někdo měl komplikovat život nějakým přemýšlením a prací?!
nechápu, co je na té explozi externích knihoven k nepochopení. Důvod je zcela triviální - běžný programátor je prostě jenom líný/neschopný si danou funkcionalitu napsat sám, tak prosté to jeNemyslím si, že by za tím byla až tak neschopnost to napsat (to může být spíš druhotné – když to lidi nedělají, ztrácejí v tom praxi a následně i tu schopnost). Spíš si myslím, že je to důsledek toho, jak se tu šířily názory, že kopírovat kód je špatné (to jakž takž pravda je) a dělají to jen lemplové a znovuvynalézat kolo bude jen blbec, zatímco profesionál použije hotové řešení napsané někým jiným (lépe). Tohle jsem slýchal na SŠ i VŠ a vycházely o tom hromady článků… Tyhle názory mají nějaký reálný základ. Ale když se to v praxi dovede do extrému a překroutí, tak to dopadá, jak to dopadá. Pak se lidi kolikrát bojí napsat i triviální vlastní kód a radši přidají několik knihoven a přidělají si tím víc problémů než jich ušetří. Taky to stojí na předpokladu, že tam venku je nějaký bájný super-programátor, který nám napíše všechny potřebné knihovny (a my je jen poslepujeme dohromady). Jasně, jsou třeba vysoce optimalizované kodeky, šifrovací knihovny, části operačních systémů atd. které píší nadstandardně schopní programátoři. Ale většinu knihoven píší běžní lidé, průměrní programátoři (byť mohou pracovat v nějaké velké a známé firmě). A běžně se ti může stát i to, že najednou zjistíš, že „opisuješ písemku od hloupějšího spolužáka“ a že bys udělal lépe, kdyby ses spoléhal sám na sebe.
Když k tomu přidáš existenci balíčkových manažerů, kde získat danou funkcionalitu je otázkou doslova jednoho jediného řádku nebo v horším případě Dockeru (to pro ty nešťastné jazyky/platformy, kde to o jednom řádku není), do kterého se celý ten build bordel zabalí, tak proč by si někdo měl komplikovat život nějakým přemýšlením a prací?!S tímhle souhlasím. Dřív bylo přidávání dalších knihoven pracné, což je na jednu stranu nevýhoda, ale na druhou stranu to fungovalo jako přirozená brzda – autor si lépe rozmyslel, jestli danou knihovnu potřebuje a jestli mu to stojí za tu námahu.
Ale většinu knihoven píší běžní lidé, průměrní programátoři (byť mohou pracovat v nějaké velké a známé firmě). A běžně se ti může stát i to, že najednou zjistíš, že „opisuješ písemku od hloupějšího spolužáka“ a že bys udělal lépe, kdyby ses spoléhal sám na sebe.Problém není v tom kód napsat, to je ta nejlehčí část. Problém je v tom kód otestovat a opravit bugy. Široce používaná knihovna je testována v praxi a chyby se opravují. Samozřejmě musí tomu tak skutečně být, a proto je nutné knihovny dobře vybírat.
tak proč by si někdo měl komplikovat život nějakým přemýšlením a prací?!S tímhle přístupem si člověk nevybere a do průseru spadne tak jako tak.
Široce používaná knihovna je testována v praxi a chyby se opravují. Samozřejmě musí tomu tak skutečně být, a proto je nutné knihovny dobře vybírat.
Bohužel opravdu ne vždy platí, že "široce používaná knihovna" = "chyby se opravují". A je to ten zásadní kámen úrazu toho přístupu: "nic vlastního, všechno z cizích knihoven". Jako příklad třeba (lib)VLC, který jsme v práci použili pro jednoduchý přehrávač videí z našeho HW, protože vlastní video framework si na tohle fakt psát nechceš. Jenomže se brzo ukáže, že tam nefunguje výběr video formátu a co hůř, YUV 4:2:2, který náš HW kromě RGB32 používá, má výrazně degradovaný výstup. I když si to sám opravím, tak to půl roku čeká než se to možná dostane k uživateům, to druhé ani neopravím, protože to je jednak mimo mé schopnosti a beztak by do legacy kódu takovou velkou změnu nikdo nepřijal. Jasně jsou to Francouzi a to, že už 4 roky jedou vývoj verze, kterou ale nikdo venku nemá je dost "Francouzskej přístup", ale podobný WTF momenty můžou přijít s jakýmkoliv jiným 3rd party kódem. A neuděláš nic.
Na druhou stranu, těžko můžeš někomu říct, že vývoj jednoduchého prohlížeče, který má být za měsíc hotový začneš tím, že si rok budeš psát vlastní video framework... A to jsem ještě nezmínil, že libVLC už vyhrálo "výběrové řízení", protože alternativy (Gstreamer, Qt Multimedia), které by přicházely v úvahu - Linux/Windows, nahrávání do H264, screenshoty - dopadly ještě hůř...
C/C++ se také hodí jen na malé projekty.
V jaké realitě žiješ? Když pominu fakt, že C/C++ je jenom "undefined behavior" tak v C nebo C++ je napsaná drtivá většina největších SW projektů ve známém vesmíru, namátkou:
a to se ještě radši nepouštim do oblasti AAA her, protože tam netušim, kolik % jsou tam enginy a kolik procent nascriptované herní děje... Mám to chápat tak, že všichni to desetiletí dělají blbě, jenom Heron ví, co je pro jejich obří projekty dobré?!
Jako že lidem řekneš: "Chtěli jsme vám dát skvělý operační systém, ale protože už jenom v kernelu je pár warningů, tak my řekli ne!"?!
Uživatele fakt nezajímá, nějaká "technická čistota", jeho zajímá, jestli ten SW řeší jeho problém. Což je mimochodem ten zásadní problém i toho projektu pod kterým tady "diskutujeme", protože jeho potenciální uživatele taky opravdu nezajímá, že je to napsané v nějakém cool samodomo interpretru (který se "skládá" z jediného 25k řádkového C souboru...), ale že to není schopné korektně vyrenderovat ani to, co dokázal links už v roce 1999....
-Wall
z compile.sh
nebo tam dát ten parametr co to vypisuje, ten to myslím specificky vypíná tuhle kontrolu.
Zkusil jsem srovnat s Links_2. Links_2 zatím lepší.
Haiku - Hmm, pokračování 90. let BeOS. Na svou dobu násobně lepší jak produkty Microsoft. Já užíval výborný OS2/Warp, předražený OS od IBM, který nakonec zachraňovali i darováním instalaček pro domácí užití (36 disket s CZ?).
Velmistr o tom neřekl ani ň, tak drž pec a nelži.
A do prdele zmiz laskavě sám.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.