Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »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.