Evropská komise schválila český plán na poskytnutí státní pomoci v objemu 450 milionů eur (téměř 11 miliard Kč) na rozšíření výroby amerického producenta polovodičů onsemi v Rožnově pod Radhoštěm. Komise o tom informovala v dnešní tiskové zprávě. Společnost onsemi by podle ní do nového závodu v Rožnově pod Radhoštěm měla investovat 1,64 miliardy eur (téměř 40 miliard Kč).
Microsoft v příspěvku na svém blogu věnovaném open source oznámil, že textové adventury Zork I, Zork II a Zork III (Wikipedie) jsou oficiálně open source pod licencí MIT.
První prosincový týden proběhne SUSE Hack Week 25. Zaměstnanci SUSE mohou věnovat svůj pracovní čas libovolným open source projektům, například přidání AI agenta do Bugzilly, implementaci SSH v programovacím jazyce Zig nebo portaci klasických her na Linux. Připojit se může kdokoli.
Google oznámil, že Quick Share na Androidu funguje s AirDropem na iOS. Zatím na telefonech Pixel 10. Uživatelé tak mohou snadno přenášet soubory z telefonů s Androidem na iPhony a obráceně.
Byla vydána nová verze 8.5 (8.5.0) skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Přináší řadu novinek a vylepšení (URI Extension, Pipe Operator, Clone With, …). Vydána byla také příručka pro přechod z předchozích verzí.
Evropská komise zahájila tři vyšetřování týkající se cloudových platforem Amazon Web Services (AWS) a Microsoft Azure. Evropská exekutiva, která plní také funkci unijního antimonopolního orgánu, chce mimo jiné určit, zda jsou americké společnosti Microsoft a Amazon v cloudových službách takzvanými gatekeepery, tedy hráči, kteří významně ovlivňují provoz internetu a musí dle nařízení o digitálních trzích (DMA) na společném trhu
… více »Společnost Meta Platforms vyhrála ostře sledovaný spor o akvizici sítě pro sdílení fotografií Instagram a komunikační aplikace WhatsApp. Podle amerického soudu firma jejich převzetím neporušila antimonopolní zákon, protože si tak nemonopolizovala trh sociálních sítí. Žalobu na Metu podala před pěti lety americká Federální obchodní komise (FTC). FTC argumentovala, že Meta, tehdy známá jako Facebook, koupila tyto dvě společnosti v letech 2012 a 2014 proto, aby s nimi nemusela soutěžit.
Home Assistant včera představil svůj nejnovější oficiální hardware: Home Assistant Connect ZBT-2 pro připojení zařízení na sítích Zigbee nebo Thread.
Byla vydána verze 9.1 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a informačním videu.
Byl aktualizován seznam 500 nejvýkonnějších superpočítačů na světě TOP500. Nejvýkonnějším superpočítačem zůstává El Capitan od HPE (Cray) s výkonem 1,809 exaFLOPS. Druhý Frontier má výkon 1,353 exaFLOPS. Třetí Aurora má výkon 1,012 exaFLOPS. Nejvýkonnější superpočítač v Evropě JUPITER Booster s výkonem 1,000 exaFLOPS je na čtvrtém místě. Nejvýkonnější český superpočítač C24 klesl na 192. místo. Karolina, GPU partition klesla na 224. místo a Karolina, CPU partition na 450. místo. Další přehledy a statistiky na stránkách projektu.
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