Byla vydána nová major verze 28.0 programovacího jazyka Erlang (Wikipedie) a související platformy OTP (Open Telecom Platform, Wikipedie). Přehled novinek v příspěvku na blogu.
Český telekomunikační úřad zveřejnil Výroční zprávu za rok 2024 (pdf), kde shrnuje své aktivity v loňském roce a přináší i základní popis situace na trhu. Celkový objem přenesených mobilních dat za rok 2024 dosáhl dle odhadu hodnoty přibližně 1,73 tis. PB a jeho meziroční nárůst činí zhruba 30 %. Průměrná měsíční spotřeba dat na datovou SIM kartu odhadem dosáhla 12,5 GB – v předchozím roce šlo o 9,8 GB.
Z novinek představených na Google I/O 2025: Přehledy od AI (AI Overviews) se rozšiřují do dalších zemí. Užitečné, syntetizované přehledy od generativní AI jsou nově k dispozici i českým uživatelům Vyhledávače.
Šestice firem označovaných jako „MAMAAN“ – tedy Meta (Facebook, Instagram), Alphabet (Google), Microsoft, Apple, Amazon a Netflix – je zodpovědná za více než padesát procent světového internetového provozu. Dalšími velkými hráči jsou TikTok a Disney+. Společně tak zásadně určují podobu digitálního prostředí, spotřebitelského chování i budoucích trendů v oblasti technologií. I přesto, že se podíl těchto gigantů od roku 2023 o něco snížil, jejich dominantní postavení zvyšuje volání po regulaci.
Evropská komise (EK) navrhuje zavést plošný poplatek ve výši dvou eur (zhruba 50 Kč) za každý malý balík vstupující do Evropské unie. Poplatek se má týkat balíků v hodnotě do 150 eur (zhruba 3700 Kč), které v EU nepodléhají clu. V loňském roce bylo do EU doručeno kolem 4,6 miliardy takovýchto balíků. Poplatek má krýt náklady na kontroly rostoucího počtu zásilek levného zboží, které pochází především z Číny.
Dnes a zítra probíhá vývojářská konference Google I/O 2025. Sledovat lze na YouTube a na síti 𝕏 (#GoogleIO).
V Bostonu probíhá konference Red Hat Summit 2025. Vybrané přednášky lze sledovat na YouTube. Dění lze sledovat na síti 𝕏 (#RHSummit).
Společnost Red Hat oficiálně oznámila vydání Red Hat Enterprise Linuxu 10. Vedle nových vlastností přináší také aktualizaci ovladačů a předběžné ukázky budoucích technologií. Podrobnosti v poznámkách k vydání.
Tuto sobotu 24. května se koná historicky první komunitní den projektu Home Assistant. Zváni jsou všichni příznivci, nadšenci a uživatelé tohoto projektu. Pro účast je potřebná registrace. Odkazy na akce v Praze a v Bratislavě.
Troy Hunt představil Have I Been Pwned 2.0, tj. nový vylepšený web služby, kde si uživatelé mohou zkontrolovat, zda se jejich hesla a osobní údaje neobjevily v únicích dat a případně se nechat na další úniky upozorňovat.
Brendan Eich, mj. autor JavaScriptu, spoluzakladatel Mozilly a její několikadenní CEO (zprávička), představuje v článku From asm.js to WebAssembly na svém blogu společný projekt Googlu, Microsoftu, Mozilly a dalších s názvem WebAssembly (GitHub, FAQ), jehož cílem je zvýšit výkon webových aplikací použitím univerzálního webového bajtkódu.
Tiskni
Sdílej:
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.