Příspěvky

1081

Vývoj / Re:Rust vs. C++ (funkcionální vs. OOP)

« kdy: 15. 03. 2016, 13:45:11 »

Matika je typicky o učení nazpaměť. Reálné projekty v IT jsou typicky o hlubokém pochopení. Ty preferuješ to první a píšeš jako kdybys opravdu preferoval to první. Podle mě je to docela jasné a Mirek to několikrát naznačoval. Ale s trollením souhlasím, jen je problém, že ty se pak na něj vždy můžeš vymluvit. Že jsi vlastně tak nemyslel a tak. Kdo ví, jak to vlastně je...

Matika je o abstraktních strukturách a vztazích mezi nimi. Zkus se ponořit třeba do té zmíněné teorie kategorií, je to docela zajímavé a otvírá to nové obzory

1082

Vývoj / Re:Rust vs. C++ (funkcionální vs. OOP)

« kdy: 15. 03. 2016, 13:35:20 »

aby člověk programoval na nějaké profi úrovni FP, tak musí umět nejspíš category theory, jinak je to patlal. Přičemž ale IMO na 90% kódu knihoven, které člověk v haskellu používá, nepotřebuje znát v podstatě žádnou category theory (resp. potřebuje znát, jak to funguje prakticky, nikoliv tu teorii za tím).

To si jenom zboj opět honí triko, můžeš to s klidem ignorovat

Hlavně neexistuje ani nějaká studie na podobné věci. Učte se matiku, budete lépe programovat.

Ale z pozorování a hloupého českého školství se dá poměrně dobře usuzovat, že znalosti jsou u nás pořád docela ceněné. Takže kdo neumí Babičku nazpaměť, ten nikdy nebude umět programovat. A nebo cokoli dalšího, co se jen někdo naučil nazpaměť a pak to cpe na fórech jako jedinou možnou cestu. Nesouvisející věci ale prostě souviset nemůžou, tak ani létání s letadlem moc nevylepší styl architektury člověka programujícího v Haskell.

Chápu, že pro některé je patlal prostě ten, co neumí nazpaměť to stejné co on. Říká to ale docela dost o autorovi, pokud si samozřejmě nedělá jen srandu.

Rozlišuj mezi "učit se nazpaměť" a "pochopit do hloubky". Pak třeba přijde osvícení Jinak sranda patří k životu

1083

Vývoj / Re:Rust vs. C++ (funkcionální vs. OOP)

« kdy: 14. 03. 2016, 17:20:40 »

Stěžuji si, že článek žádný takový případ neukazuje. Kód v C++, který autor převádí do Haskellu, dědičnost nepoužívá - článek tedy neukazuje, jak se problém, který se v OOP řeší dědičností, vyřeší v FP jinak.

Kód: [Vybrat]

class Base
{
    public:
        virtual ~Base() {}
        virtual void step(int delta) = 0;
        virtual std::string display() const = 0;
};
class Foo : public Base
{
    public:
        Foo(const int i) : intVal_(i) {}
        // Add delta to internal state.
        void step(int delta) override { intVal_ += delta; }
        std::string display() const override { return std::to_string(intVal_); }
    private:
        int intVal_;
};

To myslíte vážně?

Ano. Od Base se nedědí vůbec nic. V příkladu jde jen o to, aby ukazatele (reference) na Foo šlo bezpečně použít tam, kde jsou očekávány ukazatele (reference) na Base - jde jen o podtypový polymorfismus - dědičnost je něco jiného.

Jak je to tedy přesne s tím (pod)typovým polymorfismes v C++; tedy není implementován dědičností? Děkuji.

Když Base nemá vlastnosti a všechny metody jsou virtuální, tak se nic nedědí a jde vlastně o rozhraní/protokol (jež C++ explicitně nemá).

1084

Vývoj / Re:Rust vs. C++ (funkcionální vs. OOP)

« kdy: 14. 03. 2016, 10:56:27 »

Pokud nehodláš psát další Lens knihovnu nebo implementovat nějakou TypeInType extension v GHC, tak bych řek, že je to úplně jedno.

Takový přístup odlišuje profíka od patlala.

Hádám, že máš category theory v malíčku, viď?

Mám.

1085

Vývoj / Re:Rust vs. C++ (funkcionální vs. OOP)

« kdy: 13. 03. 2016, 23:06:17 »

Akorát že FP je abstraktnější a málokdo chápe formální aparát za ním.

Což ale není překážka v tom programovat. Obdivuju lidi, kteří to celé jsou schopni formálně popsat a využívat - ale vůbec není problém se na to dívat prakticky a chápat to taky.

To většinou platí, ale je lepší chápat to do hloubky.

Pokud nehodláš psát další Lens knihovnu nebo implementovat nějakou TypeInType extension v GHC, tak bych řek, že je to úplně jedno.

Takový přístup odlišuje profíka od patlala.

1086

Vývoj / Re:Rust vs. C++ (funkcionální vs. OOP)

« kdy: 13. 03. 2016, 21:16:19 »

Akorát že FP je abstraktnější a málokdo chápe formální aparát za ním.

Což ale není překážka v tom programovat. Obdivuju lidi, kteří to celé jsou schopni formálně popsat a využívat - ale vůbec není problém se na to dívat prakticky a chápat to taky.

To většinou platí, ale je lepší chápat to do hloubky.

1087

Vývoj / Re:Rust vs. C++ (funkcionální vs. OOP)

« kdy: 13. 03. 2016, 20:15:48 »

Mám třády ApplicationElement, UIElement, GenericStack, PartStack, kdy následující třída vždy dědí z předchozí.
V C++ žádný problém, ale v Rustu bych musel vše řešit buď kompozicí nebo traity.
U kompozice bych pak musel psát něco jako partStack.genericStack.uiElement.applicationElement pokud bych chtěl volat něco z implementace ApplicationElement a traitu je zase šílenost pro každou strukturu imlementovat všechny ty traity.

Evidentně dědičnost nějak rozumně nahradit nejde a jestli ano, tak za cenu flexibility => ve výsledku nemá cenu na něco se složitým datovým modelem používat funkcionální jazyk tohohle typu. Souhlasíte?

Pokud chceš používat FP, musíš se na problém "podívat jinak".  Často tě pak ten jiný pohled zavede směrem, kdy máš pocit, že dědičnost vůbec nepotřebuješ. Docela často nejde třeba o dědičnost, ale spíše o "Interface", a to už se dá implementovat docela jednoduše. Rust neznám, ale třeba tohle je docela hezký článek na téma dědičnost vs. haskell nebo elm.

https://github.com/Dobiasd/articles/blob/master/from_oop_to_fp_-_inheritance_and_the_expression_problem.md

Akorát že FP je abstraktnější a málokdo chápe formální aparát za ním.

1088

Vývoj / Re:Rust vs. C++ (funkcionální vs. OOP)

« kdy: 13. 03. 2016, 16:32:37 »

Rust neumím. Ale píšu dost věcí v céčku a když se bavám s vývojáři, co používají C++, tak mi přijde, že mají tendenci jeho vlastnosti přeceňovat. Céčko je maximálně flexibilní a udělá se v něm cokoliv, na co je v C++ syntaktický cukr, i na co není. Předpokládám, že to v Rustu půjde zrovnatak, ale není mi úplně jasné, co všechno půjde dělat bezpečným způsobem. Takže bude potřeba neporovnávat schopnosti jazyků, ale spíše vlastnosti best practices těch jazyků. Další věc je, že mnozí céčkaři zvládají normálně psát kód a přitom udržovat kompatibilitu API/ABI, zatímco v C++ nevím o nikom, kdo by vůbec vědě, jak se to dělá. Taky v C++ projektech (například squid) narážím na velmi kryptické chyby týkající se volání destruktorů.

http://www.abclinuxu.cz/blog/pavlix/2016/2/abi-kompatibilita

Jo tak v C++ je těch problému s ABI kompatibilitou daleko víc a je to hlavně kvůli virtuálním metodám. Např. přidám novou virtuální metodu do rodičovské třídy a už jsem v zadeli, protože se mi změní indexy virtuálních metod v TVM.
Taková funny věc v C++ je třeba to, že když člověk volá virtuální metodu v konstruktoru, tak to může, ale i nemusí fungovat, podle toho jestli už je nastaven správný ukazatel na TVM. Kvůli takovým věcem by se vyplatilo switchnout na jiný jazyk kompilovaný do nativního kódu a nemající GC (v podstatě asi jediná možnost je právě Rust).
Já mám ale problém s tím, za jakou cenu budu nahrazovat tu dědičnost pomocí jiných vlastností nějakého jazyka. Řekl bych, že je tady prostor pro jazyk typu něco mezi C++ a Rustem.

Druhá možnost je Swift, má dědičnost a nemá GC. Nicméně stabilní ABI plánují až od verze 3 (teď je na Linuxu aktuální 2.2).

Jaká je situace s knihovnami a vývojovými prostředími na Linuxu? Případně na Windows?

Swift může přímo volat kód (knihovny) v C (podobně jako Go), takže stačí dynamicky linkovat. IDE nepoužívám, tak nevím, vi to jistí.

Díky. Spíše jsem ale myslel, jaké knihovny bude Apple portovat na tyto platformy?

Swift má svou "standard library" a Apple portuje na Linux Foundation (přepisuje ji z ObjC, ale ještě tam pár věci chybí, myslím, že cíl je mít úplný port v 3.0).

1089

Vývoj / Re:Rust vs. C++ (funkcionální vs. OOP)

« kdy: 13. 03. 2016, 16:20:46 »

Rust neumím. Ale píšu dost věcí v céčku a když se bavám s vývojáři, co používají C++, tak mi přijde, že mají tendenci jeho vlastnosti přeceňovat. Céčko je maximálně flexibilní a udělá se v něm cokoliv, na co je v C++ syntaktický cukr, i na co není. Předpokládám, že to v Rustu půjde zrovnatak, ale není mi úplně jasné, co všechno půjde dělat bezpečným způsobem. Takže bude potřeba neporovnávat schopnosti jazyků, ale spíše vlastnosti best practices těch jazyků. Další věc je, že mnozí céčkaři zvládají normálně psát kód a přitom udržovat kompatibilitu API/ABI, zatímco v C++ nevím o nikom, kdo by vůbec vědě, jak se to dělá. Taky v C++ projektech (například squid) narážím na velmi kryptické chyby týkající se volání destruktorů.

http://www.abclinuxu.cz/blog/pavlix/2016/2/abi-kompatibilita

Jo tak v C++ je těch problému s ABI kompatibilitou daleko víc a je to hlavně kvůli virtuálním metodám. Např. přidám novou virtuální metodu do rodičovské třídy a už jsem v zadeli, protože se mi změní indexy virtuálních metod v TVM.
Taková funny věc v C++ je třeba to, že když člověk volá virtuální metodu v konstruktoru, tak to může, ale i nemusí fungovat, podle toho jestli už je nastaven správný ukazatel na TVM. Kvůli takovým věcem by se vyplatilo switchnout na jiný jazyk kompilovaný do nativního kódu a nemající GC (v podstatě asi jediná možnost je právě Rust).
Já mám ale problém s tím, za jakou cenu budu nahrazovat tu dědičnost pomocí jiných vlastností nějakého jazyka. Řekl bych, že je tady prostor pro jazyk typu něco mezi C++ a Rustem.

Druhá možnost je Swift, má dědičnost a nemá GC. Nicméně stabilní ABI plánují až od verze 3 (teď je na Linuxu aktuální 2.2).

Jaká je situace s knihovnami a vývojovými prostředími na Linuxu? Případně na Windows?

Swift může přímo volat kód (knihovny) v C (podobně jako Go), takže stačí dynamicky linkovat. IDE nepoužívám, tak nevím, vi to jistí.

1090

Vývoj / Re:Rust vs. C++ (funkcionální vs. OOP)

« kdy: 13. 03. 2016, 15:55:38 »

Rust neumím. Ale píšu dost věcí v céčku a když se bavám s vývojáři, co používají C++, tak mi přijde, že mají tendenci jeho vlastnosti přeceňovat. Céčko je maximálně flexibilní a udělá se v něm cokoliv, na co je v C++ syntaktický cukr, i na co není. Předpokládám, že to v Rustu půjde zrovnatak, ale není mi úplně jasné, co všechno půjde dělat bezpečným způsobem. Takže bude potřeba neporovnávat schopnosti jazyků, ale spíše vlastnosti best practices těch jazyků. Další věc je, že mnozí céčkaři zvládají normálně psát kód a přitom udržovat kompatibilitu API/ABI, zatímco v C++ nevím o nikom, kdo by vůbec vědě, jak se to dělá. Taky v C++ projektech (například squid) narážím na velmi kryptické chyby týkající se volání destruktorů.

http://www.abclinuxu.cz/blog/pavlix/2016/2/abi-kompatibilita

Jo tak v C++ je těch problému s ABI kompatibilitou daleko víc a je to hlavně kvůli virtuálním metodám. Např. přidám novou virtuální metodu do rodičovské třídy a už jsem v zadeli, protože se mi změní indexy virtuálních metod v TVM.
Taková funny věc v C++ je třeba to, že když člověk volá virtuální metodu v konstruktoru, tak to může, ale i nemusí fungovat, podle toho jestli už je nastaven správný ukazatel na TVM. Kvůli takovým věcem by se vyplatilo switchnout na jiný jazyk kompilovaný do nativního kódu a nemající GC (v podstatě asi jediná možnost je právě Rust).
Já mám ale problém s tím, za jakou cenu budu nahrazovat tu dědičnost pomocí jiných vlastností nějakého jazyka. Řekl bych, že je tady prostor pro jazyk typu něco mezi C++ a Rustem.

Druhá možnost je Swift, má dědičnost a nemá GC. Nicméně stabilní ABI plánují až od verze 3 (teď je na Linuxu aktuální 2.2).

1091

Vývoj / Re:Rust vs. C++ (funkcionální vs. OOP)

« kdy: 12. 03. 2016, 14:20:35 »

Evidentně dědičnost nějak rozumně nahradit nejde a jestli ano, tak za cenu flexibility => ve výsledku nemá cenu na něco se složitým datovým modelem používat funkcionální jazyk tohohle typu. Souhlasíte?

Nahradit nejde, ale s flexibilitou to nijak nesouvisí. Lepší je používat protokoly a je implementující třídy nebo struktury (podobně jako v Go nebo Swiftu). Rust podrobně neznám, tak nevím, nakolik umožňuje podobné paradigma.

1092

Vývoj / Re:Menší opravy v PHP - nezájem programátorů?

« kdy: 11. 03. 2016, 15:49:36 »

Kdyz vydim zdejsi diskuzi je to smutne,

dejte sem na Vas nejaky kontakt at se muzeme dohodnout.

Pokud tu nechcete zverejnovat email napiste mi na aa082173@gmail.com

Když "vydím", jak píšeš, tak určitě nemáš ani základku.

1093

Software / Re:Linuxový SW na tvorbu publikací

« kdy: 11. 03. 2016, 12:33:54 »

Nejlepší sazbu dělá TeX, tak pokud nechce psát přímo zdroják, tak bych doporučil nějaký přívětivější editor pro LaTeX.

1094

Server / Re:Nejúspornější web technologie na malý VPS

« kdy: 10. 03. 2016, 13:26:12 »

Jakou technologii (programovaci jazyk, http server, db server) byste zvolili, kdybyste chteli hostovat webove aplikace na VPS s nizkymi parametry (1 jadro, 1GB ram) s ohledem na to, aby to zvladlo co nejvetsi moznou zatez.

Nejvhodnější je Go, má hodně dobrý GC (od verze 1.5). Jinak jak už zaznělo, ideální je přesunout co nejvíce práce na klienta (JS).

1095

Studium a uplatnění / Re:Výběr katedry aplikované lingvistiky

« kdy: 07. 03. 2016, 22:42:07 »

Čtu teď Mathematical methods in linguistics (Partee a spol.), jsem u logiky a není mi jasné, co to je "úplnost". Může mě někdo nakopnout správným směrem?

Tak to se podívej jako na první stopu kudy se vydat sem:
https://cs.wikipedia.org/wiki/G%C3%B6delovy_v%C4%9Bty_o_ne%C3%BAplnosti
Ber to jako směr kudy se vydat, ohledně neúplnosti. V žádném případě ten odkaz neber jako materiál ke studiu.

Věty o neúplnosti nejsou o úplnosti. Spíše se podívej sem: https://cs.wikipedia.org/wiki/G%C3%B6delova_v%C4%9Bta_o_%C3%BAplnosti_predik%C3%A1tov%C3%A9_logiky

V logice jsou dvě úplnosti. Buď je úplná nějaká teorie, což znamená, že každé její rozšíření je sporné. Nebo může být úplný nějaký logický systém, což znamená, že každá bezesporná teorie má model. Například predikátová logika prvního řádu (FOL) je úplná. Úplnost se dokazuje pro každý systém zvlášť, například modální logika (třeba S5) je fragmentem FOL, ale z úplnosti FOL neplyne úplnost S5, jen že každé pravdivé tvrzení má důkaz ve FOL. Pro úplnost je třeba dokázat, že má důkaz v rámci modální logiky. Podobně pro rovnostní logiku a jiné fragmenty FOL. Doporučuji seznámit se s Henkinovou verzí důkazu úplnosti (jež vychází z Birkhoffovy metody), je to dost poučné.