V aktuálním příspěvku na blogu počítačové hry Factorio (Wikipedie) se vývojář s přezývkou raiguard rozepsal o podpoře Linuxu. Rozebírá problémy a výzvy jako přechod linuxových distribucí z X11 na Wayland, dekorace oken na straně klienta a GNOME, změna velikosti okna ve správci oken Sway, …
Rakudo (Wikipedie), tj. překladač programovacího jazyka Raku (Wikipedie), byl vydán ve verzi #171 (2024.04). Programovací jazyk Raku byl dříve znám pod názvem Perl 6.
Společnost Epic Games vydala verzi 5.4 svého proprietárního multiplatformního herního enginu Unreal Engine (Wikipedie). Podrobný přehled novinek v poznámkách k vydání.
Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
28.11.2008 11:02
xvasek | skóre: 21
| blog:
| Zlín
Funkcionální programování je nádherné, ale třída problémů, které se pomocí něj dají efektivně (efektivněji než imperativně) řešit, je bohužel žalostně malá. Trochu lépe je na tom logické programování - to je dobré pro problémy, které vypadají jako "sestav rozvh hodin" nebo "vyhledej v jízdním řádu", které už se v praxi vyskytují častěji, ale stejně, kdy jsem naposledy na něco takového narazil... ? Upřímě závidím lidem, kteří řeší problémy, které "pasují" na tyto jazyky - taky bych to chtěl někdy dělat. Bohužel na většinu mých pracovních problémů platí psaní programů v perlu, které si berou XML konfiguraci (aby to bylo obecné), ve které jsou nezřídka vstupy pro "eval" (aby to bylo ještě obecnější) - což je dost jednoduché na napsání a dost robustní na řešení náhodně přistávajících zadání od mého šéfa nebo zákazníků - prostě klasické "to have job done".
Nakonec nemusíme ty problémy řešit efektivněji, stačí, když to budeme umět alespoň stejně. Napsat některé věci v Haskellu s tou správnou složitostí je místy dřina, ale ještě jsem nenašla nic, co by nešlo... v nejhorším mírným podfukem...
Funkcionální programování je nádherné, ale třída problémů, které se pomocí něj dají efektivně (efektivněji než imperativně) řešit, je bohužel žalostně malá.A není lepší uvažovat spíš o "běžném použití" než o teorii? Osobně mi přijde zajímavější to, že v Haskellu jde napsat třeskutě rychlý značně paralelní webserver na pár obrazovek, než to, že holt člověk musí umět nějak obejít fakt, že nemá pole
Přesně tak, navíc právě o tohle se zmíněný zdroj (realworldhaskell.org) snaží.
O řešení běžných, "skutečných" problémů.
Tam neni pole ??? Ale fuj... (perl rulezzz)
Kdyby se nekdo pred chrlenim zarucenych faktu nejdriv podival aspon do tech standardnich knihoven, zjistil by, ze pole ma. Ma jich spoustu druhu, zajimavosti jsou treba paralelni pole (heslo pro google: nested data parallelism haskell).
A co takhle přístup -- z každého světa něco dobrého? Funkcionální uvožování do Perlu i Pythonu probublalo a určitá skupina lidí si ho velmi oblíbila.. Jiná ne ;) Ostatně lepší syntaktické konstrukce se postupně u jazyků vypůjčují z různých světů, některé se osvědčí, jiné ne.. A ta funkcionální nakonec vyhraje.. doufám ;)
Kdyz se podivame na nejake benchmarky, zjistime, ze se naopak vetsina imperativnich jazyku (az na C a C++, ktere jsou dost low-level) drzi az za haskellem, vcetne perlu. O jake efektivite nebo zalostne male tride je teda rec? Jsou to sice umele benchmarky, ale o necem urcite vypovidaji. Jinak jsem vybral zrovna benchmarky pro quad core, coz je dneska (maximalne zitra;) docela bezne pouzivany procesor. Jinak ATS, OCaml, Clean, Lisp jsou take jazyky, ktere by se daly zaradit do funkcionalnich (i kdyz nejsou ciste funkcionalni, takze by se dalo namitat, ze v tom pripade nejsou funkcionalni vubec), takze je videt, ze haskell neni nejaka vyjimka. Samotne paradigma zadne snizeni efektivity provadeni nijak nesnizuje.
jen bych upřesnil, že Clean je čistě funkcionální
No jedna věc je rychlost výdledného programu, druhá věc je úsilí potřebné pro jeho vytvoření.
Podle mě je to o zvyku. Můj mozek je zvyklý programovat imperativně. Možná bych si zvykl a pak bych říkal. Přiřazení? Fůj, takový borderl!
Kdyz se podivame na nejake benchmarky, zjistime, ze se naopak vetsina imperativnich jazyku (az na C a C++, ktere jsou dost low-level) drzi az za haskellem, vcetne perlu.
To je mi novinka, že kompilované jazyky jsou rychlejší, než interpretované Vůbec nezáleží na tom, jestli jsou low-level, nebo high-level, kompilované jazyky s kvalitním kompilátorem prostě budou běžet rychleji. Pokud to navíc má možnost běžných konstrukcí, pak to je dozajista rychlejší, než Haskell - Ada, Fortran, C, C++, to všechno poletí rychleji, než Haskell.
Ok, Ada možná - na rozdíl od Haskellu z ní lítají bezpečnější kódy, takže je plná runtimových kontrol. Ale C, C++, Fortran je určitě rychlejší.
Ok, Ada možná - na rozdíl od Haskellu z ní lítají bezpečnější kódy, takže je plná runtimových kontrol.
A proč si myslíte, že kód v jazyce Ada je nutně bezpečnější než kód v Haskellu? Uvažte třeba, že kód v čistě funkcionálních jazycích se lépe testuje a části kódu, které dělají nějaký IO jsou jasně odděleny od ostatního kódu.
Asi takto:
Vždy se dá napsat (pro jakýkoli algoritmus) v C/C++ rychlejší kód, než v Haskellu - protože tyto jazyky byly koncipovány na rychlost, a téměř vše je v nich maximální rychlosti podřízeno.
Vždy se dá napsat (pro jakýkoli algoritmus) v Adě bezpčenější kód, než v Haskellu - protože Ada byla na bezpečnost koncipována - a vše v Adě je bezpečnosti podřízeno.
Ada je bezpečnější také nejenom proto, že je na bezpečnost navržena, ale také proto, že každý kompilátor Ady musí projít velmi přísnými testy, aby vůbec mohl nosit jméno Ada - pokud to neudělá, má na krku soud z neoprávněného použití jména Ada.
Kompilátor Haskellu používá oproti C/C++/Adě naprosté minimum lidí (relativní porovnání množství) a naprosté minimum projektů. Zcela logicky bude v něm daleko víc chyb - nehledě vůbec na to, že neprošel stejně přísnými testy jako všechny kompilátory Ady.
Bezpečnost je jenom taková jako je bezpečnost nejslabšího článku celého řetězu. Velmi pochybuji, že by třeba NASA svěřila svoje drahá zařízení programům v Haskellu. Asi byste tu bezpečnost neobhájil.
Vždy se dá napsat (pro jakýkoli algoritmus) v Adě bezpčenější kód, než v Haskellu - protože Ada byla na bezpečnost koncipována - a vše v Adě je bezpečnosti podřízeno.
Pokud bych to bral, jak jste to napsal, tak je to nesmysl, neboť oba jazyky jsou výpočetně rovnocenné a v obou mohu napsat to samé.
Dále předpokládám, že se bavíme o běžně psaném kódu.
Ada je bezpečnější také nejenom proto, že je na bezpečnost navržena
To je zajímavý argument, Haskell nebyl navržen na bezpečnost, ale otázkou je, zda-li kód v něm napsaný je nutně méně bezpečný než v Adě.
Pokud se bavíme na úrovni jazyka (konkrétně mám na mysli Haskell 98):
Za prvé: Kód v Haskellu bývá typicky kratší a v kratším kódu je menší prostor na to udělat nějaké chyby a méně chyb v programu implikuje vyšší bezpečnost.
Za druhé: Jak jsem již psal, Haskell odděluje IO kód od ostatního kódu, což umožňuje neIO části programů (ty, co nemají přístup k okolnímu světu) snadno testovat a dokazovat jejich správnost, což pochopitelně vede k menšímu množství chyb.
Dále zmíněný neIO kód můžete bez obav znovu použít na jiném místě, třeba i v jiné aplikace, a 100% víte, že kód nedělá nic s okolním prostředím, což v Adě takovou záruku nemáte.
ale také proto, že každý kompilátor Ady musí projít velmi přísnými testy, aby vůbec mohl nosit jméno Ada - pokud to neudělá, má na krku soud z neoprávněného použití jména Ada.
Všimněte si, že jsem se bavil pouze o jazyku a nikdy jsem nezmínil kompilátor.
Ano, v tomto má Ada jasnou výhodu, neboť kompilátory Haskellu se velmi dynamicky rozvíjejí.
Kompilátor Haskellu používá oproti C/C++/Adě naprosté minimum lidí (relativní porovnání množství) a naprosté minimum projektů. Zcela logicky bude v něm daleko víc chyb - nehledě vůbec na to, že neprošel stejně přísnými testy jako všechny kompilátory Ady.
Když se na to podíváte z jiné strany, tak množství chyb kompilátoru závisí také na tom, v čem je kompilátor napsán, a jak je jeho kód dlouhý, a jak složitý jazyk kompiluje.
Velmi pochybuji, že by třeba NASA svěřila svoje drahá zařízení programům v Haskellu. Asi byste tu bezpečnost neobhájil.
To také pochybuji, Haskell není v žádném případě real-timový jazyk, tudíž by se jim na mnohá zařízení vůbec nehodil.
To je zajímavý argument, Haskell nebyl navržen na bezpečnost, ale otázkou je, zda-li kód v něm napsaný je nutně méně bezpečný než v Adě.
Nutně nikoli.
Za prvé: Kód v Haskellu bývá typicky kratší a v kratším kódu je menší prostor na to udělat nějaké chyby a méně chyb v programu implikuje vyšší bezpečnost.
Zase v kódu Haskellu je méně informací pro kompilátor, i pro runtime programu, kterým by mohl udělat chyby.
To je právě ta část:
C/C++ má syntaxi navrženou pro rychlost - a když se na to podíváte, tak většina konstrukcí v C/C++ má vlastně význam pouze pro zvýšení efektivnosti a rychlosti
Ada má syntaxi a další části navrženou pro bezpečnost - a řada věcí je tam jenom k tomu, aby kompilátor i runtime doslay "nezpečnostní informace", tedy aby v kódu byl obrovský přebytek informací využitelných ke kontrole správnosti.
To už také můžete tvrdit, že C je bezpečnější, než Pascal, protože v C napíšete blok jako {} a v Pascalu jako begin end, tedy Pascal má delší zápis, tudíž je nebzpečnější.
Ukecanost C/C++ je prostě z důvodu vsunutí řady dalších informací pro rychlost. Ukecanost Ady je z důvodu vsunutí dalších informací pro bezpečnost.
Sice rozumím jak jste to myslel, ale takhle automaticky to neplatí. Proč se tedy banky, velké podnikové systémy, jaderné hlavice, apod.. nepíší v Haskellu, který má kratší - tedy prý bezpečnější kód? Protože to za prvé tak jednoduše neplatí, a protože je v tom řada dalších, daleko důležitějších činitelů, co ovlivňují bezpečnost.
Za druhé: Jak jsem již psal, Haskell odděluje IO kód od ostatního kódu, což umožňuje neIO části programů (ty, co nemají přístup k okolnímu světu) snadno testovat a dokazovat jejich správnost, což pochopitelně vede k menšímu množství chyb.
A v jiných jazycích této oddělenosti pochopitelně velmi snadno dosáhnete rovněž. Jestli máte pocit, že v C, C++, Adě, Fortranu, Pascalu, assembleru a jiných jazycích se nedá psát tak, aby kód byl rozdělen na části, které nemají přístup k okolnímu světu, a na zbytek - abych použil terminologii Haskellu, tak se omlouvám, asi se nedomluvíme. Zkušeného programátora poznáte tak, že jeho kód je tak automaticky tvořen.
Všimněte si, že jsem se bavil pouze o jazyku a nikdy jsem nezmínil kompilátor.
Souhlasím, ale bez něj jaksi jazyk prakticky moc nemá smysl. Pokud budete mít špatný kompilátor, je řada výhod, ne-li všechny jazyka zadupána do země a pohřbena.
Když se na to podíváte z jiné strany, tak množství chyb kompilátoru závisí také na tom, v čem je kompilátor napsán, a jak je jeho kód dlouhý, a jak složitý jazyk kompiluje.
S tím bych souhlasil a nesouhlasil. Ta část kompilátoru, která je kritická na chyby - totiž optimalizační jednotka generující optimální kód - je především algoritmicky složitá. Pokud nepoužijete vysloveně low level jazyk, jako je stroják, tak pak už víceméně chyby kompilátoru = algoritmické chyby.
Ač vím, že Haskell se chlubí tím, jak je vynikající pro tvorbu kompilátorů - velmi pochybuji, že v něm někdo vůbec napíšete jakoukoli kvalitnější optimalizační jednotku. Podle mě se toto nikdy nestane.
Pokud berete kompilátor jako parser + vytvoření gramatiky a převod na nějaký graf, pak s Vámi musím souhlasit, chybovost bude značně záviset na použitém jazyce.
Je to třeba také vzít z druhé stránky, a teď jako smeč použiji přesně Váš vlastní argument. Sám jste psal, že kód v Haskellu nemusí být _:nutně_ méně bezpečný. Stejně tak kód kompilátoru v C nemusí být nutně méně bezpečný, než třeba kód kompilátoru v Haskellu. Záleží na kvalitě kódu, algoritmů, testování, atd.. Vzhledem k tomu, že není ekonomické věnovat spoustu času a finančních prostředků každému projektu, pak vítězí bezpečnější jazyk. Nicméně kompilátorům je věnována taková péče, že se chovají jako v bavlnce, testují, a také na nich pracují jedni z nejlepších programátorů. Kvalita kompilátoru třeba C/C++/Ady/Fortranu je totiž naprosto klíčová vůbec - a proto nesouhlasím s Vaším tvrzením, že až tak moc záleží na jazyce - prostě u vytváření kvalitního kompilátoru do strojového kódu jsou tak odlišné podmínky a tak násobná péče, že tam jsou úplně jiné výsledky. Já osobně považuji za největšího machra - programátora - na nejvyšším žebříčku toho, kdo udělá velmi kvalitní, vysoce optimalizovaný kompilátor do strojového kódu pro x86/64 platformu. Pokud je to vůbec práce, kterou může zvládnout jeden člověk. Podle mě nic složitějšího za úlohu v klasickém programování není.
Zase v kódu Haskellu je méně informací pro kompilátor, i pro runtime programu, kterým by mohl udělat chyby.
V kódu Haskellu je docela dost informací díky bohatému typovému systému.
Ada má syntaxi a další části navrženou pro bezpečnost - a řada věcí je tam jenom k tomu, aby kompilátor i runtime doslay "nezpečnostní informace", tedy aby v kódu byl obrovský přebytek informací využitelných ke kontrole správnosti.
To už také můžete tvrdit, že C je bezpečnější, než Pascal, protože v C napíšete blok jako {} a v Pascalu jako begin end, tedy Pascal má delší zápis, tudíž je nebzpečnější.
Měl jsem na mysli výraznější rozdíly než jen přejmenování tokenů.
Sice rozumím jak jste to myslel, ale takhle automaticky to neplatí. Proč se tedy banky, velké podnikové systémy, jaderné hlavice, apod.. nepíší v Haskellu, který má kratší - tedy prý bezpečnější kód? Protože to za prvé tak jednoduše neplatí, a protože je v tom řada dalších, daleko důležitějších činitelů, co ovlivňují bezpečnost.
IMO: Haskell je docela mladý jazyk, čistě funkcionální styl zatím není příliš rozšířený, a proto se Haskell zatím příliš mnoho nepoužívá. Navíc Haskell není vhodný pro real-timové systémy.
A v jiných jazycích této oddělenosti pochopitelně velmi snadno dosáhnete rovněž. Jestli máte pocit, že v C, C++, Adě, Fortranu, Pascalu, assembleru a jiných jazycích se nedá psát tak, aby kód byl rozdělen na části, které nemají přístup k okolnímu světu, a na zbytek - abych použil terminologii Haskellu, tak se omlouvám, asi se nedomluvíme. Zkušeného programátora poznáte tak, že jeho kód je tak automaticky tvořen.
Něco jiného je, když k dobrému stylu nutí programátora kompilátor. Další kapitolou může být čistě funkcionální GUI. Díky monádám se mohou některé části kódu výrazně zpřehlednit.
Ač vím, že Haskell se chlubí tím, jak je vynikající pro tvorbu kompilátorů - velmi pochybuji, že v něm někdo vůbec napíšete jakoukoli kvalitnější optimalizační jednotku. Podle mě se toto nikdy nestane.
A co třeba optimalizační jednotka GHC?
V kódu Haskellu je docela dost informací díky bohatému typovému systému.
Ada má daleko bohatší typový systém - řekl bych bohatejší, než jakýkoli jazyk, který jsem kdy viděl. Doporučuji se s tím seznámit. Tato Vaše odpověď mě přesvědčila s prominutím, že neznáte typový systém Ady.
Měl jsem na mysli výraznější rozdíly než jen přejmenování tokenů.
Rozumím a souhlasím. Souhlasím s tím, jak jste to myslel. Nicméně délka kódu je jen jedním z mnoha parametrů určující chybovost, a řekl bych tím méně podstatným.
IMO: Haskell je docela mladý jazyk, čistě funkcionální styl zatím není příliš rozšířený, a proto se Haskell zatím příliš mnoho nepoužívá. Navíc Haskell není vhodný pro real-timové systémy.
Žádný čistě funkcionální jazyk se nejspíše nikdy více nerozšíří. Funkcionální jazyky obecně spíše ustupují. Za mého mládí se používaly daleko intenzívněji. A druhá věc je, že pro řadu lidí je těžké je pochopit - nejsou intuitivní, a spíše se v nich trikuje, než aby se přímo zapsalo, co je třeba. Teď nemluvím konkrétně o Haskellu, ale faktem je, že některé věci se ve funcionálních jazycích dělají trochu přes ruku.
Něco jiného je, když k dobrému stylu nutí programátora kompilátor. Další kapitolou může být čistě funkcionální GUI. Díky monádám se mohou některé části kódu výrazně zpřehlednit.
Někdo potřebuje nad sebou bič, někdo raději svobodu. Nicméně zkušení programátoři, kteří dělají kompilátory se složitými optimalizátory ten bič nepotřebují. Spíše je omezuje.
A co třeba optimalizační jednotka GHC?
A snese srovnání s optimalizační jednotkou třeba Intel kompilátoru, nebo Microsoft kompilátoru? Podle mě ani dost vzdáleně.
No, co jsem tak koukal na průběh překladu programu v Haskellu, tak to skrz ten Intelí kompilátor jde (může jít) takyA snese srovnání s optimalizační jednotkou třeba Intel kompilátoru, nebo Microsoft kompilátoru? Podle mě ani dost vzdáleně.
Nicméně pak ale platí moje věta o tom, že pořádný optimalizátor nikdo v Haskellu nenapíše. A Intel kompilátor nemá žádnou část psanou v Haskellu. Což je to, o čem tato diskuse byla.
Ada má daleko bohatší typový systém - řekl bych bohatejší, než jakýkoli jazyk, který jsem kdy viděl. Doporučuji se s tím seznámit. Tato Vaše odpověď mě přesvědčila s prominutím, že neznáte typový systém Ady.
Zeptal bych se tedy, jaké vlastnosti má typový systém Ady, které typový systém Haskellu nemá?
Žádný čistě funkcionální jazyk se nejspíše nikdy více nerozšíří. Funkcionální jazyky obecně spíše ustupují. Za mého mládí se používaly daleko intenzívněji. A druhá věc je, že pro řadu lidí je těžké je pochopit - nejsou intuitivní, a spíše se v nich trikuje, než aby se přímo zapsalo, co je třeba. Teď nemluvím konkrétně o Haskellu, ale faktem je, že některé věci se ve funcionálních jazycích dělají trochu přes ruku.
Řekl bych, že běžné jazyky stále více a více přejímají vlastnosti z funkcionálních jazyků. A o čistě funkcionální jazyky je stále větší a větší zájem.
A snese srovnání s optimalizační jednotkou třeba Intel kompilátoru, nebo Microsoft kompilátoru? Podle mě ani dost vzdáleně.
Haskell je odlišný jazyk, proto nemá smysl srovnávat kompilátor Intelu/MS s kompilátorem GHC. Např. ani kompilátor MS ani Intelu nemá strictness analyzer, což je klíčová část při kompilování jazyků s líným vyhodnocováním.
Jak bylo zmíněno o příspěvek níže, umí GHC pro generování nativního kódu použít kompilátor jazyka C. Důležité je však podotknout, že napřed GHC provede některé vlastní optimalizace, a pak se teprve použije kompilátor jazyka C. Používá se to buď pro platformy, pro něž GHC neumí generovat nativní kód, nebo pokud program dělá mnoho výpočtů s čísly v plovoucí řádové čárce.
A snese srovnání s optimalizační jednotkou třeba Intel kompilátoru, nebo Microsoft kompilátoru?
pikantni na tomto tvrzeni je, ze na vyvoji GHC se z husta podileji borci z Microsoft Research a vysledky jejich vyzkumu se docela operativne presouvaji do C# a .NET ;-]
Kód v Haskellu bývá typicky kratší a v kratším kódu je menší prostor na to udělat nějaké chyby.
Zase v kódu Haskellu je méně informací pro kompilátor, ...
super! konecne, prekladac ktery pozna, ze jsem udelal chybu. zkuste mi treba v ade napsat program, u ktereho v tomto prekladac pozna vsechny chyby:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
28.11.2008 13:37
29.11.2008 16:07
int fact(int n) {
if (n == 2) return 2;
else return n * fact(n - 1);
}
C/C++ má syntaxi navrženou pro rychlost
a toto jste vycetl kde? syntaxe nema na rychlost vubec, ale opravdu vubec zadny vliv. doporucuji nastudovat nejakou knihu o programovacich jazycich a doplnit ke slovu syntaxe jeste terminy semantika (operacni a denotacni). jako cviceni si muzete zkusit prepsat syntaxi C/C++ do S-vyrazu bezezmeny semantiky daneho programu. pripadne zkuste si odpovedet jake zrychleni poskytuji treba makra v jazyce C.
Ada má syntaxi a další části navrženou pro bezpečnost
viz vyse, muzete uvest nejake syntakticke konstrukty zvysujici bezpecnost?
Ukecanost C/C++ je prostě z důvodu vsunutí řady dalších informací pro rychlost
v jine diskuzi pan MP:Stejně tak tyhle i dnešní nápovědy jsou v kvailtním kompilátoru kontraproduktivní, protože kvalitní analýzou to kompilátor udělá lépe, než člověk - zejména v kódu o miliónech řádků. (ponechavam bez komentare)
Proč se tedy banky, velké podnikové systémy, jaderné hlavice, apod.. nepíší v Haskellu, který má kratší - tedy prý bezpečnější kód?
tak treba ABN AMRO, Credit Suisse a Deutsche Bank opravdu vubec nepouzivaji haskell. ;-]
Ta část kompilátoru, která je kritická na chyby - totiž optimalizační jednotka generující optimální kód - je především algoritmicky složitá.
pominme skutecnost, ze tato uvaha je malinko spekulativni (viz doporucene cteni). pokracujme..
chyby kompilátoru = algoritmické chyby
a protoze haskell umoznuje delat algoritmicke chyby nehodi se na psani prekladacu... s tim se da naprosto souhlasit. ja osobne bych teda v jazyce, ktery umoznuje psat algoritmicke chyby nikdy nepsal! natoz, abych v nem psal prekladac!
dal uz opravdu nemam sily...
super! konecne, prekladac ktery pozna, ze jsem udelal chybu. zkuste mi treba v ade napsat program, u ktereho v tomto prekladac pozna vsechny chyby:
Chci se zeptat, viděl jste někdy Adu? Za prvné nikdo v Adě nepoužije typ int. Ale daleko omezenější typ - a tím dá kompilátoru tolik informací, že byste se divil. A pak už leccos dopadne úplně jinak.
syntaxe nema na rychlost vubec, ale opravdu vubec zadny vliv.
A ještě tu o červené karkulce. Jinak ono se v knihách napíše hovadin.
Ukecanost C/C++ je prostě z důvodu vsunutí řady dalších informací pro rychlost -v jine diskuzi pan MP:Stejně tak tyhle i dnešní nápovědy jsou v kvailtním kompilátoru kontraproduktivní, protože kvalitní analýzou to kompilátor udělá lépe, než člověk - zejména v kódu o miliónech řádků. (ponechavam bez komentare)
Á pan deda.jabko má koukám problémy s pochopením významu textu a kontextu. Chápete rozdíl mezi standardní syntaxí programovacího jazyka a rozšířením (tedy těmi nápovědami, o kterých jsem mluvil, že jsou zbytečné - což je v kontextu, ze kterého jste to vytrhnul jasně patrno? Doporučuji Vám intezívní kurs češtiny, protože opravdu není moje chyba, že nechápete význam psaného textu.
tak treba ABN AMRO, Credit Suisse a Deutsche Bank opravdu vubec nepouzivaji haskell. ;-]
Oni také třeba používají Excel a Windows třeba, ale na kritické části by si to nikdo neodvážil. A stejné je to s Haskellem, nikdo nebude riskovat jeho nasazení tam, kde jde o hodně. Ta stránka "Haskell in industry" sice velmi nadhodnocuje význam Haskellu v těchto institucích, ale v zásadě jejich hlavní a důležité systémy na Haskellu neběží.
Dál už nemám síly ani já. Pan deda.jablko mě vždy znovu a znovu dokáže překvapit, že nedokáže chápat ani význam textu. Někdy mám pocit, že když diskutuji s Vámi, že prostě vysvětluji tak ze značné části obvyklý význam českých slov. Nevím, jestli jste emigrant z jiného státu, a čeština Vám dělá problémy.
Za prvné nikdo v Adě nepoužije typ int. Ale daleko omezenější typ - a tím dá kompilátoru tolik informací, že byste se divil. A pak už leccos dopadne úplně jinak.
reci jsou levne, ukazte mi ten kod!
A ještě tu o červené karkulce. Jinak ono se v knihách napíše hovadin.
ono by to moc bolelo, kdybyste priznal, ze navrhu programovacich jazyku vubec nerozumite? pauselne odsuzovat, ze v knihach jsou hovadiny je nedustojne. ukazte mi teda kus syntaxe, ktery zrychluje kod. pro srozumitelnost to muzete napsat v BNF. a jako doplnek mi vysvetlete, proc specifikace kazdeho jazyka ma titernou cast venovou syntaxi a obri cast venovanou semantice.
Doporučuji Vám intezívní kurs češtiny, protože opravdu není moje chyba, že nechápete význam psaného textu.
muzete argumentovat aspon trochu na urovni?
Chápete rozdíl mezi standardní syntaxí programovacího jazyka a rozšířením (tedy těmi nápovědami, o kterých jsem mluvil, že jsou zbytečné - což je v kontextu, ze kterého jste to vytrhnul jasně patrno?
co mate porad s tou syntaxi? (muzete mi vysvetlit, co si pod syntaxi predstavujete?)
to, ze prekladac ma nejake informace (napovedu, ne prikaz!) navic prece nemuze byt na skodu? nebo snad ano? opet bych prosil dolozit vase tvrzeni.
ale v zásadě jejich hlavní a důležité systémy na Haskellu neběží
co povazujete za hlavni? takove ty systemy, kam se sype moc dat, aby se pak jednou za cas mohli nekam presypat? ano, oracle opravdu nikdo do haskellu prepisovat nebude. a nastroje na analyzu investic jsou v bankach stejne podruzne...
Pan deda.jablko mě vždy znovu a znovu dokáže překvapit, že nedokáže chápat ani význam textu.
prestante se do me navazet timto stylem, je to detinske! a misto toho se muzete radeji hloubeji rozepsat, proc haskell neni vhodny pro psani prekladacu. opet bych prosil demonstrovat na prikladech.
1.12.2008 11:31
xvasek | skóre: 21
| blog:
| Zlín
Ooops, napsal jsem to nešťastně - pod pojmem "efektivita" jsem myslel asi něco jako jak rychle je člověk schopen vyřešit daný problém - to znamená vymyslet řešení, sehnat si nástroje, naprogramovat, odladit a otestovat, nasadit. Že se to přelije do řešení složitosti a "rychlosti" daného algoritmu jsem nečekal. Někde mám ještě důkaz, že turingův stroj, imperativní programovací jazyky, logické programovací jazyky a funkcionální programovací jazyky umí řešit problémy jedné složitostní třídy "stejně rychle" (tzn. složitostní třídy jsou nezávislé na volbě programovacích paradigmata - tedy např. O(n^2) je stále O(n^2) bez ohledu na to, v čem to napíšu).
Díky za tip. Až budu mít někdy čas a chuť, tak na to mrknu. I když nemám nějakou velkou motivaci ten Haskell zkoumat dál. To se spíš vrtnu na Erlang, který začíná být velmi nahypovaný. Ruby nadcházejících dní
Dekuji za prijemny motivacni clanek.
Citim se osvicen, jen jsem to cetl.
Chvili jsem pouzival na spravu verzi DARCS, takze vim, ze Haskell umi u prakticke veci. (Bohuzel se DARCS obcas hryzal a nezvlada vetsi projekty, takze jsem dal prednost gitu.)
Smalltalk se píše s malým písmenem t.
fixnuto
zajimavy souhrn... nicmene, jenom tak na okraj... vetsinu techto bajecnych featur zvladaji bez problemu i LISP se Schemem (vcetne automaticke paralelizace a STM ;-])...
ale nesedi me jedna vec... pokud by byl paralelni haskell ciste funkcionalni, pak STM nema smysl... navic STM v haskellu je takova zvlastni a trochu nepohodlna. nicmene, musim uznat, ze lidi kolem SPJ diky haskellovske STM posunuli vyvoj docele dopredu.
Jasně, Haskell nemá na STM monopol... Čekal jsem, že se někdo od Scheme atd. ozve.
No Haskell čistě funkcionální není, protože obsahuje právě ty IO monády, které jsou potřeba pro hnusné IO sideefecty a taky pro explicitní vytvoření vlákna. Čistě funkcionální program by uměl leda tak vrátit návratový kód .
No Haskell čistě funkcionální není, protože obsahuje právě ty IO monády
IO monáda je pro programátora, který ji používá, čistě funkcionální věc.
Tiskni
Sdílej:
