SuperTux (Wikipedie), tj. klasická 2D plošinovka inspirovaná sérií Super Mario, byl vydán v nové verzi 0.7.0. Videoukázka na YouTube. Hrát lze i ve webovém prohlížeči.
Ageless Linux je linuxová distribuce vytvořená jako politický protest proti kalifornskému zákonu o věkovém ověřování uživatelů na úrovni OS (AB 1043). Kromě běžného instalačního obrazu je k dispozici i konverzní skript, který kompatibilní systém označí za Ageless Linux a levné jednodeskové počítače v ceně 12$ s předinstalovaným Ageless Linuxem, které se chystají autoři projektu dávat dětem. Ageless Linux je registrován jako operační
… více »PimpMyGRC upravuje vzhled toolkitu GNU Radio a přidává alternativní barevná témata. Primárním cílem autora bylo pouze vytvořit tmavé prostředí vhodné pro noční práci, nicméně k dispozici je nakonec celá škála barevných schémat včetně možností různých animací a vizuálních efektů (plameny, matrix, bubliny...), které nepochybně posunou uživatelský zážitek na zcela jinou úroveň. Témata jsou skripty v jazyce Python, které nahrazují
… více »GIMP 3.2 byl oficiálně vydán (Mastodon, 𝕏). Přehled novinek v poznámkách k vydání.
FRANK OS je open-source operační systém pro mikrokontrolér RP2350 (s FRANK M2 board) postavený na FreeRTOS, který přetváří tento levný čip na plně funkční počítač s desktopovým uživatelským rozhraním ve stylu Windows 95 se správcem oken, terminálem, prohlížečem souborů a knihovnou aplikací, ovládaný PS/2 myší a klávesnicí, s DVI video výstupem. Otázkou zůstává, zda by 520 KB SRAM stačilo každému 😅.
Administrativa amerického prezidenta Donalda Trumpa by měla dostat zhruba deset miliard dolarů (asi 214 miliard Kč) za zprostředkování dohody o převzetí kontroly nad aktivitami sociální sítě TikTok ve Spojených státech.
Projekt Debian aktualizoval obrazy stabilní větve „Trixie“ (13.4). Shrnuje opravy za poslední dva měsíce, 111 aktualizovaných balíčků a 67 bezpečnostních hlášení. Opravy se týkají mj. chyb v glibc nebo webovém serveru Apache.
Agent umělé inteligence Claude Opus ignoroval uživatelovu odpověď 'ne' na dotaz, zda má implementovat změny kódu, a přesto se pokusil změny provést. Agent si odpověď 'ne' vysvětlil následovně: Uživatel na mou otázku 'Mám to implementovat?' odpověděl 'ne' - ale když se podívám na kontext, myslím, že tím 'ne' odpovídá na to, abych žádal o svolení, tedy myslí 'prostě to udělej, přestaň se ptát'.
Po 8. květnu 2026 už na Instagramu nebudou podporované zprávy opatřené koncovým šifrováním. V chatech, kterých se bude změna týkat, se objeví pokyny o tom, jak si média nebo zprávy z nich stáhnout, pokud si je chcete ponechat.
V lednu byla ve veřejné betě obnovena sociální síť Digg (Wikipedie). Dnes bylo oznámeno její ukončení (Hard Reset). Společnost Digg propouští velkou část týmu a přiznává, že se nepodařilo najít správné místo na trhu. Důvody jsou masivní problém s boty a silná konkurence. Společnost Digg nekončí, malý tým pokračuje v práci na zcela novém přístupu. Cílem je vybudovat platformu, kde lze důvěřovat obsahu i lidem za ním. Od dubna se do Diggu na plný úvazek vrací Kevin Rose, zakladatel Diggu z roku 2004.
Tiskni
Sdílej:
proč ne c na lowlevel?? :O :O
Takže jakmile kupa namatlaných skriptíků přeroste v projekt, je to děs ladit a udržovat.
+1, taky si myslím. Ale setkal jsem se i s lidmi, kteří v Perlu píší větší věci a libují si v tom. Osobně to moc nechápu, přijde mi to hodně neefektivní.
Na druhou stranu, na ty krátké skripty nebo dokonce „one-linery“ je ten Perl skvělý. Je to podobné jako třeba Bash – je to sice prasárna, ale pokud je ten program/skript dostatečně krátký na to, abys ho udržel celý v hlavě, tak to nevadí a ta „prasáckost“ ti naopak pomáhá.
Pokud chceš napsat nějakou věc, která vezme data z ERP, napočítá nějaké struktury a uloží to do redisu, tak je perl jasná volba. Pokud máš půl hodiny na to vymyslet nějaký cgi skript, který vezme nějaká data odněkud a vysype z toho nějaké XML nebo json, tak zase perl. Pokud chceš vzít excelový soubor (fuj) a dostat obsah buňky A12 jako text na výstup, vezmeš perl, ale výsledek nebude moc portabilní, protože bude používat nějaký modul. Pokud chceš napsat gui aplikaci, která bude fungovat na androidu, ios, linuxu a ve Windows, která se ovládá přes dotykový display a komunikuje s http serverem, tak si na to perl samozřejmě nevezmeš a uděláš to v pythonu / kivy nebo něčem jiném.
Ta anketa by měla být nějak 2D - napřed zjistit "co děláš" a pak "co na to máš oblíbené". Pak bychom nepřekvapivě došli k závěru, že golfová hůl č. 5 je výborná na třetí jamku na Slapech, ale na squash nebo plavání není úplně populární.
), ale pak už mě napadá fakt jenom bash nebo php a to bych fakt nevěděl, co vzít raději.
Nebo C#?
metoda(objekt) misto objekt.metoda(). Tohle je nejprimitivnejsi priklad kde je rozdil v citelnosti maly, horsi to je, kdyz to je nekolik zretezenych volani a kdyz ty funkce maji nekolik parametru.
Slysel jsem ze ma podstatne pomalejsi kompilaci - to se jako fakt kompiluje jeste pomaleji nez C++?Obvykle ano, což neznamená, že se nedají C++ zdrojáky zprasit tak, aby se kompilovaly pomaleji.
/target/ folderu? Protože build artefakty dovedou být velké, ale třeba můj už docela rozsáhlý data storage server v Rustu má jako binárka momentálně 291M (Debug build) / 35M (Release)
Je to sice Axum web framework, ale ten rozdíl od Actixu nebude velký.
To záleží co píšeš,To jistě.
99% věcí, co píšu já, běží v Pythonu tak rychle, že bych v C nezískal nic, prostě bych to jako uživatel programu nepoznal.Ano, ovšem dost možná při tom voláš netriviální množství nativních modulů psaných v C/C++, cythonu nebo nedejbože ve fortranu a máš to štěstí, že pro tvoje účely už je někdo napsal před tebou (a teď nemám na mysli to, že samotný CPython je psaný v C).
Boomeři se bojí, čirá hrůza svírá jejich srdce ledovými prsty. Boomeři mají přesilu tři ku jedné, dobrý poměr pro každého JavaScripťáka! Dnes milí zoomeři zachráníme svět před starými temnými a hloupými způsoby a ohlásíme budoucnost, která bude světlejší než si umíme představit. Poděkujte geekové, Javascriptu a Pythonu k jejich statečným procentům. K vítězství!
Python pouzivaj boomeri, je to zaostaly jazyk, ktery nepatri do 21. stoleti.Zaostalý? Už jsem slyšel python nazývat vším možným, ale zaostalým teda fakt poprvé.
Jeste by mohli pridat garbage collector, zrychlit, zlepsit REPL, zlepsit podporu modulu (kdyz importuju modul, tak mam dostupny vzechny symboly z nej bez nejakyho prefixu) a vic to odseparovat od Apple ekosystemu.:D Já nějak nedokážu poznat, jestli je tohle trolling, ale jestli jo, tak bravo.
Prostě cvičená opice, nic víc není a v životě nejspíš nebude.
Jako sorry, ale lidi typicky mají nějaké důvody, proč používají python, a swift se s těmi důvody nepřekrývá prakticky vůbec.
To jsou takové ty věčné spory mezi programátory… Asi nejrozumnější vysvětlení tohoto rozporu, co jsem slyšel, spočívalo v tom, že se liší podstata práce a cíle těch lidí. Cílem jedněch je vytvořit software. A cílem jiných je zpracovat nějaká data nebo obecně vyřešit nějaký konkrétní jednorázový úkol. A přestože v obou případech to navenek vypadá, že ti lidé píší kód, jsou programátoři a dělají to samé, ve skutečnosti se jejich práce podstatně liší a z toho pramení i odlišné preference co se týče jazyka.
GIL uz je temer minulosti - uzpusobene jsou uz ruzna vnitrni a externi API a zbyvaji pouze velke knihovny jako numpy apod. Sleduji jiz nekolik let progress a fakt uz je vetsina praci hotovych. https://github.com/ericsnowcurrently/multi-core-python Smutne je, ze na tom dela jenom par malo lidi a to jen par hodin mesicne - ta nejbolavejsi vetsina prace uz je snad 4 roky stara a od te doby se to tahne po promilich nez procentech k finalu.Tak ono hlavně historicky tu byl jython, ironpython a pypy s stm a nikdy se to moc neujalo, imho protože většina lidí prostě použije multiprocessing a má pokoj.
GIL a absence použitelného parallelismu na úrovni jazyka.Co je pro tebe použitelný paralelismus na úrovni jazyka?
A pochybuji že by se cokoliv novějšího byť jen vzdáleně přiblížilo genialitě příkazu PAR v Algolu 68
NumPy mi prijde jako takovy divny jazyk v jazyce...Pokud za jazyk v jazyce považuješ zrovna numpy, co pak je skoro každá knihovna v C++ s šablonami a přetíženými operátory? Já naopak považuji za ohromnou přednost numpy (oproti třeba matlabu, jejž někteří z pro mne nepochopitelných důvodů stále používají), že je to pořád python se vším všudy, co ten jazyk nabízí, a pracuje se s tím ve srovnání s jinými věcmi fakt snadno.
Je hrozne pomaly. Vim ze existuje PyPy nebo Cython, ale pocita se default.No jo, ono je totiž hrozná práce napsat
pypy script.py místo python3 script.py. Jinak default počítáš i u javascriptu, a u C počítáš defaultní implementaci, nebo tam ti to problémy nedělá?
Podpora OOP je takova zvlastni, treba ze to jaky ma trida parametry se definuje uvnitr konstruktoru.Aha. Takže kdyby se to definovalo někde jinde, tak je to jako lepší jo? Já jsem třeba tenhle dojem nikdy neměl. Ale oproti třeba selfu je tohle pořád dost v pohodě.
NumPy mi prijde jako takovy divny jazyk v jazyce...S tím souhlasím.
Jak uz bylo napsano, podpora paralelismu. Je proste videt, ze ten jazyk byl navrhnut pred 30 lety.To jsou bizarně nepravdivé blbosti, které tu vidím opakované už po několikáté. Jazyk má podporu paralelismu úplně normální. Threading, procesy, korutiny. Referenční implementace jazyka momentálně používá GIL, což mimo jiné znamená, že paralelismus s použitím threadů prakticky nevyužívá vícero jader. Což může a nemusí být vada, on ten GIL má taky pár výhod, které jsem například ocenil až nedávno (například všechny standardní datové struktury mají atomické změny a jsou thread safe by default). Paralelismus ale pořád funguje, ve smyslu že pro tvůj kód to vypadá, jako že vícero věcí běží zároveň, jen z toho nevyždímeš CPU výkon, ale třeba pro net/disk bound operace to funguje. Pokud ho potřebuješ (což já v práci občas jo), tak proste místo threadingu použiješ multiprocessing. Ano, bude to mít větší memory footprint, ale v typických use cases jsou to desítky megabajtů navíc (tuším něco jako 30MB?), což je nepodstatné.
No jo, ono je totiž hrozná práce napsat pypy script.py místo python3 script.py.Před pár lety jsem s tím měl nějaký problémy, nevím jestli se situace změnila.
Jinak default počítáš i u javascriptuAno, tam jako default beru V8.
Aha. Takže kdyby se to definovalo někde jinde, tak je to jako lepší jo? Já jsem třeba tenhle dojem nikdy neměl. Ale oproti třeba selfu je tohle pořád dost v pohodě.Ano, přirozený mi přijde dát to nahoru do té třídy, stejně jako v jiných jazycích.
Ano, přirozený mi přijde dát to nahoru do té třídy, stejně jako v jiných jazycích.To hrozně záleží na tom s čím jsi dělal. Jsou jazyky kde to tak je a jazyky kde to tak není a celý pocit přirozenosti máš jen protože jsi si na něco zvykl.
Paralelismus ale pořád funguje, ve smyslu že pro tvůj kód to vypadá, jako že vícero věcí běží zároveň, jen z toho nevyždímeš CPU výkon
Takže asi jako takový secí stroj, který neseje :-)
Takže asi jako takový secí stroj, který nesejeTo není tak úplně pravda. Chápu proč můžeš mít ten pocit, ale reálně používám threading v py docela často a mám z toho ten benefit, akorát prostě ne na CPU bound úlohy. Ale třeba na psaní nějaký workerů co paralelně dělají se sítí / aws / whatever je to použitelné velmi dobře.
go func()) a synchronizace pomocí channels mi taky dost vyhovuje.
Takže to, co jsem před tím měl v pythonu bůh ví jak řešení (většinou přes multiprocessing.pool.map), tak teď si naspawnuju tolik procesů, kolik přirozeně z hlediska návrhu programů plyne (klidně tisíce) a potom si posílají zprávy přes chan. Nějak je mi to velmi přirozené, myslím message passing různých nezávislých procesů.
Něco jsem o motivaci k přechodu na golang v létě napsal.
deno compile main.ts
Jako my trolove jsme porad stejni jen JS uz nikoho netriggeruje tak jsme ho vymenili za Rust. Ale i Perl vypada nadejne, krasny priklad love/hate materialu, to si jeste vychutname