Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie).
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 12.0 (Mastodon). Forgejo je fork Gitei.
Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).
Hyprland, tj. kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, byl vydán ve verzi 0.50.0. Podrobný přehled novinek na GitHubu.
Patrick Volkerding oznámil před dvaatřiceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.
Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.
Vláda dne 16. července 2025 schválila návrh nového jednotného vizuálního stylu státní správy. Vytvořilo jej na základě veřejné soutěže studio Najbrt. Náklady na přípravu návrhu a metodiky činily tři miliony korun. Modernizovaný dvouocasý lev vychází z malého státního znaku. Vizuální styl doprovází originální písmo Czechia Sans.
Vyhledávač DuckDuckGo je podle webu DownDetector od 2:15 SELČ nedostupný. Opět fungovat začal na několik minut zhruba v 15:15. Další služby nesouvisející přímo s vyhledáváním, jako mapy a AI asistent jsou dostupné. Pro některé dotazy během výpadku stále funguje zobrazování například textu z Wikipedie.
Více než 600 aplikací postavených na PHP frameworku Laravel je zranitelných vůči vzdálenému spuštění libovolného kódu. Útočníci mohou zneužít veřejně uniklé konfigurační klíče APP_KEY (např. z GitHubu). Z více než 260 000 APP_KEY získaných z GitHubu bylo ověřeno, že přes 600 aplikací je zranitelných. Zhruba 63 % úniků pochází z .env souborů, které často obsahují i další citlivé údaje (např. přístupové údaje k databázím nebo cloudovým službám).
Open source modální textový editor Helix, inspirovaný editory Vim, Neovim či Kakoune, byl vydán ve verzi 25.07. Přehled novinek se záznamy terminálových sezení v asciinema v oznámení na webu. Detailně v CHANGELOGu na GitHubu.
podporovat i static typing (guards a trademarks)Koukal jsem na to a není mi jasné, jak budou fungovat parametrizované typy (například generika)?
Spise to vypada, ze oni ten jazyk opravi.Moc tomu nevěřím – nebude vůle udělat změny, které poruší zpětnou kompatibilitu. Spíš to dopadne tak, že k těm starým a špatným věcem přidají paralelně nové a lepší věci. V praxi se pak bude používat oboje a jazyk bude velice komplikovaný (na to, co umí, je komplikovaný už nyní). Například do ES 6 přidali generátory, což je IMO krok špatným směrem, uvažuje se o přidání async a await, což je IMO další krok špatným směrem. Pak třeba zjistí, že oboje vede na duplikaci kódu (viz příklad s
IEnumerable
z mého zápisku Algebraické efekty), a přidají vymezené kontinuace, které subsumují generátory i async a await.
Například do ES 6 přidali generátory, což je IMO krok špatným směrem, uvažuje se o přidání async a await, což je IMO další krok špatným směrem.Proč? Ten blog jsem více/méně četl, ale stejně mi to z toho není jasné.
Array.prototype.forEach
).
Druhý způsob generování prvků: Generátor – vrací objekt iterátor, jehož metodu next
můžeme volat, když chceme další prvek.
Výhodou prvního způsobu je, že takové funkci je snadné programovat. Jeho nevýhodou je, že cizí funcke řídí náš kód (inversion of control) – v některých případech může být těžké takovou funkci použít.
Naopak výhodou druhého způsobu je snadnost použití generátorů, jeho nevýhodou je, že se generátory těžko programují.
Aby ECMAScript odstranil nevýhodu druhého způsobu, přidal speciální podporu pro generátory. Tato podpora umožňuje psát generátory jako funkce z prvního způsobu – hlavní rozdíl je, že místo volání předané funkce voláme yield
a funkce je deklarována pomocí function*
.
Tato speciální podpora však neřeší nevýhodu prvního způsobu. Pokud máte například API, kde je pouze map
, tak vám podpora generátorů nepomůže – musíte počkat, až autor API přidá generátor.
Existuje však jiné řešení, které žádné generátory nepotřebuje a odstraní obě nevýhody. Tím řešením je převést první způsob na druhý. Je mj. snadné převést druhý způsob generování na první způsob. Převod naopak lze uskutečnit pomocí vymezených kontinuací nebo pomocí vlákna, mutexu a proměnné sdílené vlákny. Pokud ECMAScript bude podporovat green thready, nepotřebuje generátory.
To, co mi tedy vadí na generátorech je, že řeší problém jen napůl (neodstraňují nevýhodu prvního způsobu generování), komplikují jazyk a možná budou zbytečné, protože stejnou službu udělají green thready.
Kromě toho jsou tu otázky ohledně časové složitosti – jakou bude mít například ES analog následujích enumerátorů časovou složitost? Lineární nebo kvadratickou?
static IEnumerable<int> LeftAssocEnum(int i) { var acc = Enumerable.Empty<int>(); while (i > 0) { acc = Enumerable.Concat(acc, new int[] { i }); i--; } return acc; } static IEnumerable<int> RightAssocEnum(int i) { var acc = Enumerable.Empty<int>(); while (i > 0) { acc = Enumerable.Concat(new int[] { i }, acc); i--; } return acc; }Mj. v C# mají oba enumerátory kvadratickou složitost a oba z nich způsobí přetečení zásobníku pro dostatečně velké
i
. Nicméně v rozumné implementaci by RightAssocEnum
měl mít lineární časovou složitost a k žádnému přetečení zásobníku by u něj dojít nemělo.
function*
, navíc se takto označené funkce chovají jinak než klasické funkce označené function
. Green thready jsou tedy obecnější.
Když mám green thready, nemusím dopředu rozhodovat, zda nějaká funkce bude generátor – například map
mohu, jak jsem zmínil, použít jako generátor (bez toho abych něco přepisoval) – tj. vytvořím funkci, která vrací iterátor a tento iterátor uvnitř používá map
.
function*
.
Stejne tak preteceni zasobniku - implementace muze pouzivat segmented stack a tim se presune problem s alokaci do heapu.Oboje lze implementovat s konstantním zásobníkem a s lineární časovou složitostí. Je jen otázkou, jak chytrá je implementace. Příkladem takové implementace je knihovna scalaz-stream.
novy standard programovani vyrazne zjednodusujeMožná zjednodušuje programování, nicméně pochybuji, že zjednodušuje jazyk. Například verze 5 specifikuje jazyk na 100 stranách, verze 6 na 260 stranách.
Mozna koukate na jiny standard, ale verze 5.1 ma 258 stran, a verze 6.0 ma 566 stran.Bral jsem jazyk bez standardní knihovny – přijde mi to lepší pro odhad složitosti jazyka – a také jsem se spletl, v případě ES 6 to je více stran. Například oproti specifikaci Standard ML, která má pod 100 stran, je to celkem výrazný rozdíl.
v dalsich revizich muze byt vyjmuta.Jen dobře, pokud bude.
Například oproti specifikaci Standard ML, která má pod 100 stran, je to celkem výrazný rozdíl.To je nesmysl srovnavat podle stran, nebot se nejedna o dokumenty vytvorene pro jednu standardizacni instituci podle stejnych pozadavku. Lepsi priklad by byl treba Dart.
Koukal jsem na to a není mi jasné, jak budou fungovat parametrizované typy (například generika)?Pouzijete guards, ktere zajisti, ze v danem bloku kodu se pouziva pouze deklarovany trademark (typ). Kompilatoru pak zoptimalizuje genericky blok kodu pro dane typy. Stale je to otevrene, ale staticke typy v nejake forme budou.
a jazyk bude velice komplikovanýHorsi nez C++ ci rust to nebude.
Například do ES 6 přidali generátory, což je IMO krok špatným směrem, uvažuje se o přidání async a await, což je IMO další krok špatným směrem.Vsechno to ma byt postavene nad spawn, ktery ma bezet na green threads, takze blokovani neni az tak velky problem.
Pokud zarizeni nepodporuje WebAssembly - bude jich jeste dlouho plno, je Javascript fallback a nikdo to nebude psat dvakrat.Jako fallback muze byt interpretace WebAssembly pomoci JS. Nebo JIT preklad WebAssmebly do JS, ktery pak bude prolozeny JIT do nativniho kodu. ;-]
Spise to vypada, ze oni ten jazyk opravi.IMHO je JS FUBAR. Jak uz psal Radek Micek, ten jazyk obsahuje spoustu spatnych vlastnosti od zacatku a nikdo nebude mit odvahu rozbit zpetnou kompatibilitu... uz jenom kvuli tomu velkemu mnozstvi programatoru. Leda, ze by zavedli nejakou direktivitu (ala Perl), ktera by rikala, ze kod je napsany pro konkretni verzi JS.
"use more strict"
IMHO je JS FUBAR.To jsem si myslel take, a kdyby se mi zdalo o programovani v javascriptu, musel bych memit pyzamo, jak bych byl zpoceny hruzou. Rozdil oproti jinym jazykum je v tom, ze JavaScript se zatim pouziva v prostredi, kde zivotnost aplikaci beze zmen je v radu mesicu, zivotnost zarizeni v radu let, a prohlizec se updatuje kazdy mesic. To jim umoznuje delat i zpetne nekompatibilni zmeny, kde se kompatibilita docasne vyresi, jak bylo naznaceno vyse, pridanim dalsi direktivy.
Pokud zarizeni nepodporuje WebAssembly - bude jich jeste dlouho plno, je Javascript fallback a nikdo to nebude psat dvakrat.Dneska je v módě psát překladače do javascriptu.
Pokud používáte staticky typovaný jazyk, tak kód budete moci psát v něm, přeložit do WAsm a ono to poběží rychleji, než kdybyste to napsal přímo v ECMAScriptu. Kdo by pak používal ECMAScript?Určitě se počítá s tím, že JS se bude do WebAsm taky překládat. Jinak JS mi přijde jako celkem dobrý jazyk. Má svoje mouchy, ale určitě to není špatný jazyk ve smyslu skutečně špatných jazyků, jako třeba PHP...
V čom sú prototypy dobré? Neberte to ako hate príspevok, len ma to zaujíma. V js istý čas robím, čítal som mnoho blogov ako v tom napr. napísať dedičnosť a stále neviem ako na to.
Jinak doporučuji tento článek: Why Does JavaScript Suck?Mně právě tyhle quirks vůbec nepřijdou tak hrozné. Když píšu v JS, používám kontrolu typů, operátor
===
a podobně. Souhlasim s tim automatickým středníkem, to mě taky onehdá vytočilo. Ten scoping nevidim jako problém - stejně je to jazyk s GC. Ten odstavec o globálních proměnných mi přijde přehnaný, nevim o tom, že bych musel používat globální proměnný vyjma window
. Jako jo, v JS určitě jsou nepříjemnosti, ale ten jazyk alespoň celkově nějak dává smysl a má nějakou koncepci narozdíl od PHP.
Uz ted vznikaji ruzne prekladace pres LLVM do JSTo je hrozně pomalé a výsledná velikost je většinou taky dost špatná. O dost použitelnější jsou překladače přímo do JS, jako třeba brython.
Tiskni
Sdílej: