Program pro generování 3D lidských postav MakeHuman (Wikipedie, GitHub) byl vydán ve verzi 1.3.0. Hlavní novinkou je výběr tvaru těla (body shapes).
Intel vydal 41 upozornění na bezpečnostní chyby ve svých produktech. Současně vydal verzi 20240514 mikrokódů pro své procesory řešící INTEL-SA-01051, INTEL-SA-01052 a INTEL-SA-01036.
Společnost Raspberry Pi patřící nadaci Raspberry Pi chystá IPO a vstup na Londýnskou burzu.
Google na své vývojářské konferenci Google I/O 2024 představil řadu novinek. Keynote byl věnován umělé inteligenci (DeepMind, Gemini, Responsible AI).
V Gitu bylo nalezeno 5 zranitelností. Opraveny jsou ve verzích 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2 a 2.39.4. Útočník může připravit repozitář tak, že při jeho klonování (git clone) může dojít ke spuštění libovolného kódu.
Virtualizační softwary VMware Workstation Pro a VMware Fusion Pro jsou nově pro osobní použití zdarma. Softwary VMware Workstation Player a VMware Fusion Player končí.
Linuxová distribuce Endless OS (Wikipedie) byla vydána ve verzi 6.0.0. Přehled novinek i s náhledy v příspěvku na blogu, poznámkách k vydání a také na YouTube.
Byl vydán Mozilla Firefox 126.0. Přehled novinek v poznámkách k vydání, poznámkách k vydání pro firmy a na stránce věnované vývojářům. Vylepšena byla funkce "Zkopírovat odkaz bez sledovacích prvků". Přidána byla podpora zstd (Zstandard). Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 126 je již k dispozici také na Flathubu a Snapcraftu.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 11.0. Přehled novinek v aktualizované dokumentaci.
Byla vydána nová verze 24.0 linuxové distribuce Manjaro (Wikipedie). Její kódové jméno je Wynsdey. Ke stažení je v edicích GNOME, KDE PLASMA a XFCE.
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