Portál AbcLinuxu, 1. listopadu 2024 00:06
Skus F# tu je par video-tutorialov od Tomasa Petricka:
http://channel9.msdn.com/Blogs/JanSteberl/Uvod-do-jazyka-F-IAggregateNumbers treba misto for cyklu pouziva rekurzi - tedy pro milion hodnot bude milionkrat volat sebe sama, jen aby se vyhnula prirazeni do promenne - i pokud to nespadne na nedostatek pameti, tak silne pochybuju o tom, ze by to dopocitalo v nejakem rozumnem case.seda je teorie, ... inteligentni prekladac to prevede na cyklus, gcc bezne tail cally prevadi na cyklus uz s -O1 a slozitejsi rekurzi s -O2
Presne ako pise deda.jabko, rekurzivne volania sa prevadzaju na cykly (ak je rekurzivna funkcia spravne napisana).
http://thevalerios.net/matt/2009/01/recursion-in-f-and-the-tail-recursion-police/ F# neni ziadny akademicky experiment, je to realne pouzivany jazyk bezne sa pouziva u trading apps. Vykon je +- rovnaky ako u C#.a ty hledas nejakou pro praci.a proto by si mel vybrat jazyk podle prace Vyber si firmu kde chces delat a podle toho se nauc jazyk/jazyky, ktere tam budes potrebovat
Co je na Javě jednoduchého?Oproti C++ všechno :) Syntaxe mi nepřijde složitější než ta co má Python nebo Ruby.
V tom GC se nikdo nevyzná (aspoň nikoho neznám)Co to znamená vyznat se v GC? Jako vyznat se v tom, jak to je implementovaný?
každá třída má tunu metod a předchůdcůHm, je pravda, že ze standardní knihovny mám (někdy) podobný dojem...
a je tam kopa zásadních návrhových chyb, které se pak řeší složitě a nepochopitelněNapříklad? (neříkám, že tam nejsou)
Nov STL moc metod není. V rodičích je trochu těžké se vyznat zvláště kvůli použití template, ale má to svůj význam.každá třída má tunu metod a předchůdcůHm, je pravda, že ze standardní knihovny mám (někdy) podobný dojem...
No v základu GC zaručuje jen to, že nejspíš někdy dojde ke smazání instancí, na které nemáš žádnou referenci. To se mi nezdá moc jako spolehlivý memory management.V tom GC se nikdo nevyzná (aspoň nikoho neznám)Co to znamená vyznat se v GC? Jako vyznat se v tom, jak to je implementovaný?
Tak třeba díky nepředvídatelnosti GC je metoda finalize vpodstatě zbytečná. Dokážu si představit velmi malé množství případů, kdy její použití není návrhovou chybou. Proč je Interface něco jiného než abstraktní třída? Je to proto, že Java neumožňuje dědit po více třídách najednou. Jenže pak ten interface není potomkem Objektu i přes to, že každý objekt v Javě musí být potomkem Objektu. Už si nepamatuju, jak se to řeší, ale není to zrovna elegantní. Jazyk na té úrovni, na které se Java snaží mít, by měl mít přetěžování operátorů. Java se tváří, že je hrozně 'oběktově orientovaná', ale bez přetěžování operátorů a bez vícenásobné dědičnosti a dalších věcí to za moc nestojí.a je tam kopa zásadních návrhových chyb, které se pak řeší složitě a nepochopitelněNapříklad? (neříkám, že tam nejsou)
No v základu GC zaručuje jen to, že nejspíš někdy dojde ke smazání instancí, na které nemáš žádnou referenci. To se mi nezdá moc jako spolehlivý memory management.A v C++ to musíte zajistit ručně, což mi přijde ještě méně spolehlivé, když vás nic nehlídá, zda to opravdu uděláte.
C++ obsahuje něco jako strážce pointerů - std::auto_ptr a std::shared_ptr a možná další, pak je správa paměti automatická.Tohle je dost neefektivní (běžný GC bude rychlejší – viz třeba Deutsch-Bobrow) a navíc to nefunguje v přítomnosti cyklů.
Je to asi lepší, než napůl cesty gc v Javě, který uklidí paměť, ale nechává viset zabrané zdroje programu.GC může při finalizaci uvolnit i zdroje, akorát to není deterministické.
Tohle je dost neefektivní (běžný GC bude rychlejší – viz třeba Deutsch-Bobrow)[citation needed], to je hodně divoké tvrzení. Krom toho C++ smart pointery typicky není problém použít způsobem podobným jako Deutsch-Bobrow. Říká ti něco RAII?
a navíc to nefunguje v přítomnosti cyklůOd toho je
std::weak_ptr
. Ale imho je lepší se cyklům vyhnout už při návrhu, pokud možno samozřejmě.
[citation needed], to je hodně divoké tvrzení.Proč myslíte? Chytré ukazatele odpovídají počítání referencí. Počítání referencí s DB je typicky rychlejší než klasické počítání referencí. Moderní GC, např. ten v JVM, je typicky rychlejší než DB. Empiricky: Boost's shared_ptr up to 10× slower than OCaml's garbage collection
Krom toho C++ smart pointery typicky není problém použít způsobem podobným jako Deutsch-Bobrow.A jak je takové řešení bezpečné?
Říká ti něco RAII?Na co narážíte?
Chytré ukazatele odpovídají počítání referencí.Obecně ne. Chytrý ukazatel
std::unique_ptr
slouží k vlastnění objektu jedním vlastníkem, a tudíž nepotřebuje počítání (totéž jeho ekvivalent boost::scoped_ptr
a starší, nebezepečná varianta std::auto_ptr
také nepočítá reference).
Počítání referencí s DB je typicky rychlejší než klasické počítání referencí.Pro nějaké definice "klasického počítání referencí" určitě...
Empiricky: Boost's shared_ptr up to 10× slower than OCaml's garbage collectionVůbec nechápu smysl toho benchmarku. Proč autor porovnává
shared_ptr
a GC? A co to vůbec znamená, jak to porovnává? Míchá jablka a hrušky. Dělá to na mě dojem, že vzali kód, který používal malloc+free, a nahradili veškeré alokace instancí shared_ptr
. Pokud ano, tak není divu, že výsledek je pomalý. K tomu shared_ptr
ale není určený. Nasazení RAII v doposud non-RAII C++ programu bude typicky vyžadovat trochu víc než jen nahrazení alokací, spíš celkovou změnu návrhu.
Na co narážíte?Na to, že reference counting se typicky použije pouze v případech, kdy to je nutné. V C++ memory managementu je v naprosté většině případů snaha počítání referencí minimalizovat a použít jiné metody (stack-based memory management, move semantics,...).
Vůbec nechápu smysl toho benchmarku. Proč autor porovnává shared_ptr a GC? A co to vůbec znamená, jak to porovnává? Míchá jablka a hrušky. Dělá to na mě dojem, že vzali kód, který používal malloc+free, a nahradili veškeré alokace instancí shared_ptr. Pokud ano, tak není divu, že výsledek je pomalý. K tomu shared_ptr ale není určený.To se vracíme k mé původní výtce, tj., že ruční správa paměti není spolehlivá. Ptám se tedy, jak se v C++ spravuje paměť a zdroje, aby to bylo spolehlivé?
Na to, že reference counting se typicky použije pouze v případech, kdy to je nutné. V C++ memory managementu je v naprosté většině případů snaha počítání referencí minimalizovat a použít jiné metody (stack-based memory management, move semantics,...).Díky za upřesnění. Ale opět to v C++ není spolehlivé. Třeba v Rustu to spolehlivé je, neboť tam to garantuje typový systém. Podobně v ATS.
Pro nějaké definice "klasického počítání referencí" určitě...Počítá se každá reference.
Ale opět to v C++ není spolehlivé.Tak určitě to je výrazně spolehlivější než čistě ruční alokování + dealokování (které je kritizováno v té původní výtce, jestli to dobře chápu), zejména když se používají výjimky. Pokud člověk dodrží příslušná pravidla, mělo by to být celkem rozumně spolehlivé. Ale jinak C++ určitě není známé tím, že by se nějak moc staralo o programátorovu bezpečnost
Finalize pokud vím není ve standardí knihovně snad nikde použité, je to pouze jedna z metod třídy se speciálním významem (který jak píšeš nemá moc význam).finalize() se musí používat všude tam, kde se používají nějaké nativní popisovače apod. Takže aby třeba došlo k zavření souboru, pokud programátor nevolá close() sám. A to v té std. knihovně párkrát bude, ne?
Mel jsem na mysli spis standardni knihovnu javy, stl moc neznam.Hm, je pravda, že ze standardní knihovny mám (někdy) podobný dojem...Nov STL moc metod není. V rodičích je trochu těžké se vyznat zvláště kvůli použití template, ale má to svůj význam.
No v základu GC zaručuje jen to, že nejspíš někdy dojde ke smazání instancí, na které nemáš žádnou referenci. To se mi nezdá moc jako spolehlivý memory management.To je vetsinou všechno co je potreba vedet - dokud mas nekde odkaz na objekt, tak ten dokaz zustane v pameti.
Proč je Interface něco jiného než abstraktní třída? Je to proto, že Java neumožňuje dědit po více třídách najednou. Jenže pak ten interface není potomkem Objektu i přes to, že každý objekt v Javě musí být potomkem Objektu. Už si nepamatuju, jak se to řeší, ale není to zrovna elegantní.Nevim co tim presne myslis, ale nejde vytvorit instanci interfacu. Jenom instanci tridy, takze kazda instance musi byt potomkem Objectu. Vicenasobna dedicnost neni neco co bych potraboval kazdy den, ale nevadilo by mi, kdyby ji do Javy pridali (nebo traity). Pretezovani operatoru a spoustu dalsich veci bych si v Jave taky pral... Java ma od idealniho jazyka hodne daleko, ale je relativne rychla, ma skvelou integraci s ide vcetne staticky analyza kodu a spoustu knihoven. Pro hodne problemu je Java dobra volba. C++ je sice o neco rychlejsi, ale imho to je min produktivni jazyk.
Neudrzuji zpetnou kompatibilitu na urovni syntaxe. To je nejvetsi hnus, co muze nekdo s jazykem udelat.a je tam kopa zásadních návrhových chyb, které se pak řeší složitě a nepochopitelněNapříklad? (neříkám, že tam nejsou)
Za mě určitě C++. Oproti ostatním zmiňovaným tě to naučí i něco navíc než jen syntaxi daného jazyka.To jo. Třeba ocenit, že u ostatních se při návrhu i přemýšlelo :)
C++ není navíc tak zprasené jako C# nebo Java, kde musíte pořád přemýšlet, co se asi tak honilo tvůrcům jazyka hlavou při navrhování jazyka, ale soustředíte se jen na to, co chcete udělat.:D
zase vám to pomůže pochopit i další programovací jazykyMožná to platí pro jazyky odvozené z C++, ale obecně o tom pochybuji. Základní koncepty jsou totiž v C++ velmi omezeny a splácány dohromady.
C++ není navíc tak zprasené jako C# nebo Java, kde musíte pořád přemýšlet, co se asi tak honilo tvůrcům jazyka hlavou při navrhování jazyka, ale soustředíte se jen na to, co chcete udělat.Myslíš to C++, o kterém jeho autor prohlásil něco v tom smyslu, že neočekává,že by ho někdo pochopil celé?
D?
Mam to radsi nez C#.Proč?
Dnešní jazyky jsou naprosto primitivní, a klidně se nový naučíte za den. Zvláště, pokud jsou tak vykuchané na dřeň jako třeba Java, Python nebo C#.Rad se podivam, jak se za den naucite byt jen Python a jeho standardni knihovnu ;)
Redaktor: Tell me about Haskell’s unofficial slogan: avoid success at all costs. What’s the origin of it?
SPJ: I mentioned this at a talk I gave about Haskell a few years back and it’s become quite widely quoted. When a language becomes too well known, or too widely used and too successful - certainly being adopted by Microsoft means such a thing - suddenly you can’t change anything anymore. You get caught and spend ages talking about things that have nothing to do with the research side of things. Success is great, but it comes at a price. I’m primarily a programming language researcher, so the fact that Haskell has up to now been used for just university types has been ideal. Now it’s used a lot in industry but typically by people who are generally flexible, and they are a generally a self selected rather bright group. What that means is that we could change the language and they wouldn’t complain. Now, however, they’re starting to complain if their libraries don’t work, which means that we’re beginning to get caught in the trap of being too successful.
Trochu jsem to prosel a oproti tem zabehnutym jazykum je to jeste v zacatcich.To je ale hodně troufalé tvrzení, po zběžném "projití" Hackage.
Pro moji práci, a to jsem dělal na hodně odlišných projektech, mi dostupné knihovny až na výjimky pokryly všechny potřeby. Pokud můžu srovnat s Pythonem, tak je toho jen o "něco" méně. Zavádějící může být i číslování verzí. Tady verze menší než 1.0 neznamená, že to je neodladěná prealfa, ale většinou je to spolehlivý a plně funkční kód. Dtto platí i pro flag Stability.
hodne problemu je uzitecnejsi divat se imperativne nez funkcionalnejo, to asi jo. Haskell proto pouziva monady a do notatci. imperativni programovani vystavene na funkcionalnich, chcete-li matematickych, zakladech. problematicke budou spis space-leaky -- line vyhodnocovani. a mozna taky obcas komplikovane zpravy prekladace.
Co takhle nejdriv napsat ten program, spustit ho na nejakych datech, z toho urcit jake jsou v nem vlastne datove typy a na zaklade toho poskytnout (mozna i jen aproximativni) dukaz korektnosti algoritmu?Dokazované vlastnosti by byly někde předem specifikovány nebo by se měly automaticky odvodit na základě výstupu programu?
Dalsi typicky priklad je optimalizovani kusu kodu - v Jave mam celkem dobrou predstavu, co se deje na nizsi urovni, takze to jde vetsinou zoptimalizovat tak, ze to neni o moc pomalejsi nez C.Máte pravdu, to je IMO hlavní nevýhoda Haskellu. Nicméně kompilátory Haskellu se stále zlepšují a s určitou podporou v knihovnách se třeba také přiblíží C: Haskell Beats C Using Generalized Stream Fusion nebo What’s in a parser? Attoparsec rewired (2/2)
Cili hodne I/O. V Pythonu to jde krasne jednoduse. Prijde mi, ze v Haskellu se musi vic premyslet...V Haskellu by to mělo jít podobně jednoduše – myslím, že stačí znát základy na úrovni Learn You a Haskell for Great Good!.
Programátor je limitovaný maximálně rychlostí počítače a ten programovací jazyk je vytvořený na základě nějakého vymyšleného matematického modelu. A ty modely se tak liší, že když znáš jeden, tak to pro učení druhého vůbec nemusí být výhoda.V programovacích jazycich se spíš říká paradigma než model, ale jinak je to přesně tak - programátor, který se "naučí myslet" v jednom paradigmatu může mít problém s jinými druhy paradigmat (je to vlastně slabé verze Sapir-Whorfovy hypotézy aplikované pro programovací jazyky). Například někdo, kdo začínal s nízkoúrovňovými jazyky bude mít problém s různými vysokoúrovňovými abstrakcemi a tudíž je (ke své škodě) nebude používat, pokud to nebude nutné (aneb "Opravdoví programátoři dokážou psát ve Fortranu v jakémkoliv jazyce" ), naopak ten, kdo začínal v jazyce s vysokou mírou abstrakce bude mít problém v okamžíku, kdy je postaven před relativně nízkoúrovňový problém, na který chybí předem připravené řešení (a jako důsledek pak páchá pomalé a paměťově nenasytné obludky). Naprotitomu u podobných druhú jazyků bude přechod mnohem jednodušší a hlavním problém bude, jak už tu bylo několikrát napsáno, naučit se znát knihovny a rozličné frameworky, což může trvat roky.
programátor, který se "naučí myslet" v jednom paradigmatu může mít problém s jinými druhy paradigmatTo by mělo být vytesáno v nějakém kameni. OOP se mi do hlavy vtloukat snažili, ale já vůl prostě ne a ne pochopit k čemu takový krám sloužit může.
Tiskni Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.