Erin Catto, autor open source 2D fyzikálního enginu Box2D (Wikipedie), představil nový 3D fyzikální engine Box3D. Engine je již používán ve hře The Legend of California.
Byla vydána nová verze 4.0.0 multiplatformního svobodného frameworku pro zpracování obrazu G'MIC (GREYC's Magic for Image Computing, Wikipedie). Přehled novinek i s náhledy nových filtrů na PIXLS.US.
Český statistický úřad (ČSÚ): Průměrná hrubá měsíční mzda ICT specialistů v roce 2025 meziročně vzrostla o 6 % na téměř 100 tisíc korun. Nejlépe placeni byli vývojáři softwaru. Dlouhodobým trendem zůstává nízké zastoupení žen, a to jak mezi specialisty, tak studenty těchto oborů.
Ochranný svaz autorský (OSA) připravuje žalobu na společnost Suno, která umožňuje generování hudby pomocí umělé inteligence (AI). ČTK to sdělil předseda představenstva OSA Roman Strejček. Suno podle něj bez souhlasu využívá k trénování svých modelů hudbu autorů, které svaz zastupuje. Nedávný investigativní materiál magazínu The Atlantic ukázal, že firmy jako Suno nebo Udio k trénování modelů používají rozsáhlé databáze obsahující miliony skladeb. V databázích, které časopis zveřejnil, lze dohledat i písně řady českých a slovenských umělců.
Byl publikován přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Vyřešen byl problém s macOS 27 Golden Gate. Vývoj lze podpořit na Open Collective a GitHub Sponsors.
EU dnešním dnem zavedla clo ve výši 3 eur na balíky nízké hodnoty dovážené ze zemí mimo EU. To zahrnuje širokou škálu výrobků běžně nakupovaných on-line, jako jsou oděvy, hračky, elektronika a další spotřební zboží v hodnotě až 150 EUR.
Vyšel Redmine 7.0, jeden z nejlepších open source ticketovacích systémů. Došlo k migraci na Rails 8, vylepšení UI/UX, Workflow, byla přidána podpora náhledu pro Microsoft Office a LibreOffice dokumenty, došlo k výkonnostním optimalizacím a přibylo spoustu dalších oprav a novinek. Více informací v oficiálním oznámení.
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 166 (pdf).
Blíží se prázdniny a než se rozutečete k moři, je na čase se opět sejít na Virtuální Bastlírně - pravidelném setkání elektroniků, ajťáků, bastlířů a obecně nadšenců do techniky. Co si pro vás strahovští bastlíři připravili tentokrát? Určitě proberou blížící se Linux Days i další události. U softwaru se chvíli zdrží a poví si kupříkladu o tom, jak se zbavit Bambu Cloudu, ale nepřijít o možnost ovládat tiskárnu na dálku. Řeč dojde i na AI,
… více »Vývojáři postmarketOS vydali verzi 26.06 tohoto operačního systému pro chytré telefony vycházejícího z optimalizovaného a nakonfigurovaného Alpine Linuxu s vlastními balíčky. Přehled novinek v příspěvku na blogu. Na výběr jsou 4 uživatelská rozhraní: GNOME, KDE Plasma Mobile, Phosh a Sxmo.
Zdravím.
Zajímalo by mě, zda je funkcionální programování pouze akademická záležitost, nebo zda se v praxi v nějakém velkém projektu používá...
Ne, není to pouze akademická záležitost. Například společnosti Galois, Credit Suisse používají Haskell, společnost Jane Street Capital používá OCaml, Twitter používá Scalu, IntelliFactory používá F#, FaceBook používá Erlang, NASA používala Common Lisp (nevím, jak je to v dnešní době). Pro další použití se můžete podívat na program jednotlivých ročníků konference CUFP.
Který funkcionální jazyk bych se měl naučit? Je nějaký funkcionální jazyk, jehož znalostí bych se například mohl živit, tedy který bych využil například v práci?
Osobně Vám doporučuji Haskell. Není tam možné tak snadno psát imperativní kód jako v jazycích, které nejsou čistě funkcionální, což Vám na jednu stranu bude činit problémy, protože budete nucen změnit způsob uvažovaní, ale na druhou stranu se rychleji naučíte funkcionálně myslet (protože Vám nic jiného nezbyde).
Jelikož říkáte, že jste Javista, můžete také zkusit jazyk Scala. Má docela blízko k Javě, ale můžete v něm používat i funkcionální techniky. A když nebudete chtít nebo se to nebude hodit, můžete psát podobný kód jako v Javě s tím, že u některých věcí se Vám zápis podstatně zkrátí. Domnívám se, že tento jazyk má potenciál postupně nahradit Javu.
Co jsem tak koukla, tak bych se asi začal učit Erlang...
Oproti Haskellu a Scale je Erlang dynamicky typovaný jazyk, což pro Vás znamená, že nebude tak rychlý a některé chyby, které by v Haskellu/Scale odhalil už kompilátor, se Vám v Erlangu projeví až za běhu.
Nevíte o nějaké vhodné literatuře k funkcionálnímu programování? Mám na mysli nějaké obecné algoritmy, přeci jenom pro mě jakožto začínajícího javistu je ztráta možnosti měnit hodnotu proměnné celkem frustrující...
Doporučuji Vám začít knížkou o základech funkcionálního programování a naučit se používat funkce vyšších řádů a currying. Zkuste se podívat třeba na Naučte se Haskell.
Na škole jsem měly předmět základy algoritmizace, ale to mi je ve funkcionálním programování jaksi k ničemu...
Máte pravdu, že se často dává přednost perzistentním datovým strukturám, ale snad ve všech známějších funkcionálních jazycích můžete použít i klasické datové struktury a i klasické algoritmy.
Můžete se podívat na What’s a good Functional language to learn first případně zkusit hledat podobné dotazy na Stack Overflow.
Oproti Haskellu a Scale je Erlang dynamicky typovaný jazyk, což pro Vás znamená, že nebude tak rychlý a některé chyby, které by v Haskellu/Scale odhalil už kompilátor, se Vám v Erlangu projeví až za běhu.
Source or it didn't happen. Tenhle obecně oblíbený omyl, podpořený nezvratitelným tvrzením "JÁ nechápu, jak by to mohlo být jinak", mě rozesmívá už řadu let. Zhruba stejnou řadu let, co v dynamických jazycích píšu (Smalltalk, Erlang, Python). Moje zkušenost je taková, že 99% chyb je v sémantice a ne v tom, že se někde objeví jiný typ než by jeden čekal. Argument rychlosti je mimo už z principu. Běžná představa je předpokládám taková, že před každým voláním funkce se testuje typ. Směšné.
Jinak tazateli bych z vlastní zkušenosti (navíc komerční zkušenosti) doporučil Erlang. Nejvíc impresivní jsou na něm schopnosti paralelizace a distribuce. A ta jednoduchost paralelních výpočtů, to se s thready nedá srovnávat. Je na něm vidět, že je to "programátoři programátorům", i když nemám nic proti principům "hej, na přednášce z matiky jsem slyšel...".
Moje zkušenost je taková, že 99% chyb je v sémantice a ne v tom, že se někde objeví jiný typ než by jeden čekal.
U jazyků se silným typovým systémem (Agda, Gallina) zakóduji prakticky každou vlastnost do typů. Tudíž projde-li program typovou kontrolou, je korektní (vzhledem k vlastnostem v typech). Já programuji převážně v Haskellu a z vlastní zkušenosti vím, že dobře navržené typy umožní odhalit řadu chyb už při kompilaci. V některých případech lze například už v době kompilace zkontrolovat, že index pole bude směřovat dovnitř a ne mimo.
Argument rychlosti je mimo už z principu.
Zkušenost tento argument potvrzuje. Spoustu vlastností pak můžete testovat v době kompilace a ne až za běhu (třeba zmíněné meze polí nebo typy), což šetří čas.
Nejvíc impresivní jsou na něm schopnosti paralelizace a distribuce.
Snadnou paralelizaci dnes už podporuje kdeco například C#, F#, Scala, Clojure, Haskell. Navíc v Haskellu, Clojure i .NET Frameworku máte STM. Haskell dále podporuje Nested Data Parallelism.
U jazyků se silným typovým systémem (Agda, Gallina) zakóduji prakticky každou vlastnost do typů. Tudíž projde-li program typovou kontrolou, je korektní (vzhledem k vlastnostem v typech). Já programuji převážně v Haskellu a z vlastní zkušenosti vím, že dobře navržené typy umožní odhalit řadu chyb už při kompilaci. V některých případech lze například už v době kompilace zkontrolovat, že index pole bude směřovat dovnitř a ne mimo.
To nepopírám a doporučuji pozornosti číslo 99. Toto číslo reprezentuje chybu programátora, tedy např. sčítá místo odečítá, načte čtyři byte místo dvou apod. Je to chyba algoritmu, typově je v pořádku a přesto nelze říci, že program je korektní, tj. dělá přesně to, co má a nikdy nespadne. Po uvedené filipice je překvapivé, že pro staticky typované jazyky vůbec existují testovací frameworky.
Argument rychlosti je mimo už z principu.Zkušenost tento argument potvrzuje. Spoustu vlastností pak můžete testovat v době kompilace a ne až za běhu (třeba zmíněné meze polí nebo typy), což šetří čas.
Tak tahle zkušenost by mě zajímala. Je ovlivněna velkým množstvím faktorů, ať už na straně prostředí nebo návrhu jazyka nebo kdekoliv jinde. Jak je možné, že tentýž program v C přeložený GCC a ICC je různě rychlý? Je tedy různě rychlý jazyk C? Prostým srovnáním téhož programu napsaného v různých jazycích také nelze nalézt srovnání (viz The Computer Language Benchmarks Game ), tam např. Erlang propadá, protože není stavěný na indexaci polí, přestože v rekuzivním výpočtu si tak špatně nestojí. Za pozornost rovněž stojí např. optimalizace ve Smalltalku (zejména VisualWorks a Smalltalk/X), notoricky považovaném za nejpomalejší prostředí na světě. Jsou situace, kdy neudrží dech ani C++ se svými VMT.
Snadnou paralelizaci dnes už podporuje kdeco například C#, F#, Scala, Clojure, Haskell. Navíc v Haskellu, Clojure i .NET Frameworku máte STM. Haskell dále podporuje Nested Data Parallelism.
Nerozporuji, že ve spoustě prostředí bude nějaká knihovna, která dokáže zařídit jak paralelizaci na jednom stroji, tak distribuci např. v clusteru. Na Erlangu je zajímavé to, že zkušenosti z prvního "Hello World" člověk použije beze změny při psaní toho clusteru, resp. mohu vzít jakýkoliv program a beze změny ho spustit na libovolně velkém clusteru. A protože je to základním prvkem prostředí, vůbec, ale vůbec to nebolí.
Další flame na toto téma není myslím třeba. Na světě budou vždycky lidé, kteří píší ve staticky typovaných jazycích a haní dynamické a ti, kteří to dělají naopak. Většina webů se pak namastí v PHP a stejně to funguje. Někdo vdolky, jiný holky.
To nepopírám a doporučuji pozornosti číslo 99. Toto číslo reprezentuje chybu programátora, tedy např. sčítá místo odečítá, načte čtyři byte místo dvou apod. Je to chyba algoritmu, typově je v pořádku a přesto nelze říci, že program je korektní, tj. dělá přesně to, co má a nikdy nespadne.
Já se snažím říct, že do těch typů mohu zakódovat specifikaci. Tudíž ten program bude korektní vzhledem k té specifikaci. A samozřejmě, pokud napíši špatně specifikaci, tak ten program bude také špatný, protože dělá přesně to, co je v té specifikaci.
Dám příklad. Napíšu funkci sort, kde typ vstupu bude seznam celých čísel a typ výstupu bude vzestupně utříděná permutace vstupního seznamu. U takové funkce mi pak kompilátor garantuje, že ta funkce třídí.
Po uvedené filipice je překvapivé, že pro staticky typované jazyky vůbec existují testovací frameworky.
Napsat pár testů je jednodušší (a hlavně levnější), než popsat danou vlastnost a udělat k ní důkaz. Navíc ne všechny staticky typované jazyky mají dostatečně silný typový systém.
Je tedy různě rychlý jazyk C?
To už mě chytáte za slovo.
tam např. Erlang propadá, protože není stavěný na indexaci polí, přestože v rekuzivním výpočtu si tak špatně nestojí
Erlang nebyl hlavně stavěn na žádné náročné výpočty.
Je tedy různě rychlý jazyk C?To už mě chytáte za slovo.
Zkušenost byl jediný předložený důkaz. Snažím se jen přijít na zdroj té zkušenosti. Zatím jsme tedy zřejmě dospěli k tomu, že rychlost provádění přeloženého kódu s rychlostí jazyka nesouvisí. Pokud ano, jaký závěr o rychlosti jazyka lze vyvodit, pokud (hypoteticky) t(C/ICC) < t(Erlang) < t(C/GCC)?
Erlang nebyl hlavně stavěn na žádné náročné výpočty.
Chytání za slovo? Zaprvé, opravdu si ve výpočtech proti některým tak špatně nestojí, i když výpočetní výkon nebyl nikdy prioritou. Zadruhé, úlohy, zejména distribouvané, ve kterých Erlang vyniká, by sesadily třeba i C (pamatuji si knihovnu MPI) nebo Javovské RMI. Každý "univerzální" jazyk byl stvořen k nějakým úlohám a zbytek univerza prostě tak dobrý není.
Snažím se jen přijít na zdroj té zkušenosti.
Jeden takový zdroj jste si sem sám nalinkoval.
Zkušenost byl jediný předložený důkaz.
Podstata mého tvrzení o pomalosti dynamicky typovaných jazyků je v tom, že když nějakou informaci mám, tak určitě nebudu pomalejší, než když ji nemám. A nejen moje zkušenost s různými implementacemi dynamicky typovaných a staticky typovaných jazyků ukazuje, že staticky typované jazyky jsou rychlejší (jejich implementace, chcete-li).
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz