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.
Microsoft představil open source textový editor Edit bežící v terminálu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
V Seattlu a také online probíhá konference Microsoft Build 2025. Microsoft představuje své novinky. Windows Subsystem for Linux je nově open source. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Z příspěvku Turris Sentinel – co přinesl rok 2024 na blogu CZ.NIC: "Za poslední rok (únor 2024 – únor 2025) jsme zachytili 8,3 miliardy incidentů a to z 232 zemí a z jejich závislých území. Tyto útoky přišly od 6,2 milionu útočníků (respektive unikátních adres). SMTP minipot je stále nejlákavější pastí, zhruba 79 % útoků bylo směřováno na tento minipot, 16 % útoků směřovalo na minipot Telnet, 3 % útoků směřovaly na minipot HTTP a 2 % na minipot FTP. Dále jsme zaznamenali 3,2 milionu unikátních hesel a 318 tisíc unikátních loginů, které útočníci zkoušeli."
Byla vydána (Mastodon, 𝕏) nová verze 3.0.4 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání a v souboru NEWS na GitLabu. Nový GIMP je již k dispozici také na Flathubu.
Psaní kompilátoru je to poslední, co by mělo trápit návrháře jazyka, ne? Primární je uživatelnost jazyka, ne složitost kompilátoru...Larry Wall označuje způsob návrhu Perlu 6 jako whirlpool model (model víru). Při psaní testů a implementaci zjistíte co je ve specifikaci špatně, takže upravíte specifikaci, upravíte testy, upravíte implementaci, vyhodnotíte co je špatně a zase znovu upravit specifikaci, uprati testy, ... pak začnete psát první aplikace a knihovny a zase znovu. Tím se dostanete právě k té uživatelnosti jazyka. Navrhnout jazyk bez psaní v jeho kódu nebo psaní kódu bez možnosti spustit jej je nesmysl. Specifikací/návrhů, které byly psány bez implementace existuje bezpočet. Dobře víme kolik chyb, rozporů a nejednoznačností v nich je. Myslím si, že napsat implementaci dynamického programovacího jazyka jen podle specifikace nejde. Perl 6 za správnou implementaci jazyka (určité verze) považuje tu, která splňuje existující testy Perlu 6 (pro tuto verzi). Testy jsou v podstatě součástí specifikace. Testových případů jsou tisíce a další tisíce se musí ještě dopsat. Programátor by neměl používat nespecifikovanou/netestovanou funkci jeho Perl 6 kompilátoru. Měl by test napsat a protlačit jej do jazyka. Když to neudělá, tak se může stát, že funkce nebude v příští verzi podporována (bez zmínky v changelogu). To je velký rozdíl oproti Perlu 5. V Perlu 6 jsou si všechny implementace rovny. Kvalita se dá měřit počtem splněných testů. Perl 5 ani specifikaci nemá. V případě, že je dokumentace v rozporu s kompilátorem perl, tak jde o chybu dokumentace. Svou roli zde hraje důraz na zpětnou kompatibilitu (jazyk má přes 20 let). Perl 5 je jeden a tak to asi i zůstane. Python, Ruby, PHP a další moc nesleduji. Existují zde "alternativní" kompilátory. Nevíte jak je to u nich? Je to jako u Perlu 6, že správnou implementací můžete napsat podle oficiální specifikace (oficiálních testů jazyka)? Nebo jako u Perlu 5, že specifikace je jen tak zhruba a při psaní kompilátoru musíte porovnávat s hlavní implementací, která určuje co je ten správný Python/Ruby?
Tiskni
Sdílej:
Whirlpool model je fajn. Je to podobné ako prototypovanie pri návrhu aplikácií. A obecnejšie je to veda: vytvoríš teoretický model a potom ho overuješ a upravuješ podľa experimentov
Na druhej strane, ak niekto plánuje písať stabilný program, ktorý musí vydržať niekoľko rokov, tak asi neni moc zábavné, keď sa mu každý týždeň mení špecifikácia jazyka pod rukami. Starý problém rolling updates Takže rozumnejšie asi je mať release cycles (napr. po 5 rokoch). Vždy vydať špecifikáciu jazyka, nechať ľudí ho pár rokov používať a tvoriť v ňom programy, a tie skúsenosti reflektovať do novej verzie (plus mínus ako to robí Scheme s RnRS).
Čo sa týka Pythonu, tak tam je štandardná implementácia v C, ale hlavná je špecifikácia a vďaka nej existuje aj kopa alternatívnych implementácií. Python napísaný v pythone, kompilátory do bytekódu rôznych virtuálnych mašín a pod. Zaujímavejšie je to napr. s Common Lispom alebo Scheme, kde žiadna štandardná implementácia neexistuje, máš len desiatky rôznych implementácií (viac či menej podporujúcich špecifikáciu).
Tak s týmto absolútne nesúhlasím. Návrhár jazyka musí byť zároveň schopný aj napísať jeho kompilátor, aby mal aspoň nejakú predstavu, či je niektorá vlastnosť vôbec realizovateľná v praxi. Nie všetky informatické problémy sú rozumne riešiteľné. A nie každá vlastnosť je vôbec rozumne programaticky podchytiteľná. Toho všetkého si musí byť návrhár vedomý, inak nikdy nevznikne nič viac než návrh.
O to väčší dôvod, aby bol ten kompilátor kvalitný
Ako som už napísal pod druhým blogom, vysokoúrovňovosť a prívetivosť jazyka nebráni peknému návrhu. Naopak
Psaní kompilátoru je to poslední, co by mělo trápit návrháře jazyka, ne? Primární je uživatelnost jazyka, ne složitost kompilátoru...Treba u C++ nemame poradne ani po 15ti letech kompilator ktery by jej bezezbytku implementoval. Zrovna nedavno jsem narazil ne nejakou nejednoznacnost vykladu specifikace mezi gcc a VC2008(i kdyz vic verim gcc). Co je tezke na implementaci pro kompilator musi by tezke na nauceni pro programatora. To mi nikdo nevymluvi.
Presne tak. C++ snáď nie je ani LALR, takže sa neni moc čo čudovať...
Aha, dík za upresnenie. Každopádne to musí byť humus
+1
Btw, keď už sa bavíme o tých jazykoch... netuší niekto či existuje prehľad, ktoré parsery (LL, LR, ...) sú najviac preferované pre kompilátory bežných jazykov? A súvisiaca otázka: ktoré sú najlepšie/najčastejšie používané generátory parserov (yacc, ANTLR, ...). Možno by o tom rovno Ladíček mohol napísať blog
Neviem, ale dúfam v najpozitívnejšiu možnosť: dosiahol nirvánu, odišiel z nášho sveta a stráži rovnováhu vesmíru, ktorá závisí na správnom spárovaní zátvoriek
kam vůbec zmizel Jakub Hegenbart (Kyosuke)?Nejaky Kyosuke (a mozna z Ceska, podle textu komentare) se vyskytl nedavno na Slashdotu: http://slashdot.org/comments.pl?sid=1669586&cid=32398916
Škoda, že Kyosuke (správne s dlhým ó) je úplne bežné japonské meno. Tiež si mohol vybrať lepší nick
Mne sa na disku povaľujú Red a Purple Dragon Book. Už je to dávno, čo som ich čítal (a aj to nie celé), ale mám pocit, že boli dosť dobré.
Treba u C++ nemame poradne ani po 15ti letech kompilator ktery by jej bezezbytku implementovalTo není tak úplně pravda; poslední verze standardu C++ je 7 let stará a kompilátor, který ji implementuje, pokud vím, existuje.
Zrovna nedavno jsem narazil ne nejakou nejednoznacnost vykladu specifikace mezi gcc a VC2008(i kdyz vic verim gcc)To je dost nesmyslné tvrzení: Buďto je ta specifikace nejednoznačná (klidně může být), a pak je každý konformní výklad stejně dobrý (můžeme se bavit o tom, jestli je vhodnější/použitelnější, ale těžko můžeme jednomu "víc věřit"). Nebo je některá z těch implementací v rozporu se standardem, a pak se dá těžko hovořit o nejednoznačnosti výkladu.
Co je tezke na implementaci pro kompilator musi by tezke na nauceni pro programatoraPokud by toto byla pravda, je pro programátora nejjednodušší (na naučení) stroják nebo assembler.
A ktorý to je?
Čo je na tom nezmyselné? Podstata je, že špecifikácia je nejednoznačná. To je celkom veľký problém. Lebo ak pripustíme nejednoznačnosť, tak už nám môže byť jedno, akého jazyka to vôbec špecifikácia je
Že sa 500 stránkový štandard bude učiť ťažšie než 50 stránkový Vám pripadá nezrejmé? Nič viac tá jeho veta nehovorila. A rozhodne nehovorila nič o assemblere (btw, ktorom konkrétne? A ste si istý, že každý assemble má triviálnu gramatiku?)
A ktorý to je?Dost kompletní jsou Comeau C++ a kompilátor v Sun Studiu. Mimochodem standard C++ ISO/IEC 14882:2003 má skoro 800 stran.