Příspěvky

1876

Vývoj / Re:programovaci jazyk budoucnosti

« kdy: 19. 08. 2015, 17:30:37 »

dam priklad chtel bych udelat agregator top 3 posts ze vsech mych subredditu za poslednich 24 hodin jako jednu html stranku tedy mam problem a mam cil- je tam na to api fce neumim pouzit

Řešením tohoto problému je
1) Naučit se používat ty nástroje
2) Někomu zaplatit

Cortana/Siri apod. jsou jen další pomůcky, které vám umožní udělat něco, co jiný předpřipravil a způsobem, který se autor usmyslel vám "povolit".

Berme to jako výzvu k úvaze, zda dnešní vysokoúrovňovost jazyků by se nedala ještě posunout. A samozřejmě jak.

1877

Vývoj / Re:Funkcionální jazyky.

« kdy: 19. 08. 2015, 15:24:02 »

Getter a setter jsou běžné metody objektu. Zakázat možnost z venku měnit členské proměnné přímo a donutit místo toho volat nějakou metodu je hlavní způsob jak udržet objekt v konzistentním stavu.
Jiná možnost je neustále při každé změně vyrábět novou instanci a řešit to v konstruktoru, to ale není vůbec praktické.

Problémem getterů a setterů je, že nejsou polymorfní. Pokud budu mít ve třídě Article metodu setTitle(), tak taková metoda se mi vůbec nehodí ve třídě Person či Store. Nemohu tedy použít stejné rozhraní.

Což je jedině žádoucí. Article není Person, natož Store. Nejen, že nemůžeš použít stejné rozhranní, ale ani by tě to nemělo napadnout.

Psa se ptáš kolik má blech a zda má obojek nebo nemá. Štěkat zvládne sám.

Hmm. A co mi ten pes odpoví na otázku, kolik má blech, když neumí mluvit?

Sorry, ale to je demagogie nejhlubšího zrna. Chápu to tedy správně, že uznáváš, že máme pravdu? :-)

1878

Vývoj / Re:Funkcionální jazyky.

« kdy: 19. 08. 2015, 15:00:01 »

Co je na getterech, setterech a public atributech tak opravdu objektového?

To je porad dokola - je to moznost, jak zapouzdrit. Casto to neni dobry navrh ale samo o sobe to nic proti OOP neni.

To je pořád dokola - nic z toho se nechová objektově. Copak se ptám psa, jak mám za něho štěkat? To je getter.

To je kravina. Getter je když se ptáš psa, jakou má barvu chlupů. Nebo jestli je mu zima. Nebo jestli má hlad. Prostě cokoliv, co ten pes z principu ví lépe než okolí. Schopnost štěkat není (nemusí být) getter.

1879

Vývoj / Re:Funkcionální jazyky.

« kdy: 19. 08. 2015, 13:26:07 »

Víš dobře, že getterům/setterům se vyhýbám. Jsou to jen berličky pro programátory, kteří neumí psát objektově.

Budeš řvát jak opařená kočka až jednou, za mnoho let zjistíš, že opravdově objektově je to právě s těmi gettery.

1880

Vývoj / Re:Funkcionální jazyky.

« kdy: 18. 08. 2015, 01:01:02 »

Tak jsem se kouknul na Clojure zde ve tutoriálu od p. Tišnovského a při pohledu na první kód

Kód: [Vybrat]

(loop [] (println (eval (read))) (recur))

mě hned napadlo, že je to nepřehledné, prostě na první pohled nevidíte, co je argument čeho.

- zvyk
- je třeba toho méně přečíst, aby si to pochopil

Sice je fajn, že napíšu jeden řádek kódu co dělá spoustu věcí, ale zase u toho člověk musí víc přemýšlet a ve výsledku časově to vyjde třeba nastejno

- No, já bych si troufl tvrdit, že nevyjde. V mnoha jazycích (java například) musíš napsat spoustu balastu, kterej zdržuje při psaní i při čtení. V clojure rovnou píšeš co to má být (názvy rutin) a jediný balast jsou závorky.

1881

Vývoj / Re:K čemu JavaScript generátory?

« kdy: 17. 08. 2015, 11:28:13 »

Jak to chápu:

(a)synchronní znamená, že nějaké dvě věci spolu jsou nebo nejsou sesynchronizovány. Takže když mám dvě zavolání funkcí, jedna zpracovává svůj výsledek déle než druhá, tak není přihlíženo na pořadí volání, ale na délku vykonávání té funkce.

(ne)blokující znamená, že jedna věc (ne)blokuje jinou. Například zavolám první funkci, a hned mohu volat druhou a nemusím čekat na výsledek, protože ten výsledek se mi zpět dopraví jiným způsobem (callbackem).

paralelní znamená, že dvě funkce se vykonávají ve stejný čas (reálně, na více jádrech, ale platí to i když to je jen iluzojní pomocí multitaskingu).

Vychází mi z toho, že často se děje kombinace neblokující asynchronní volání funkce, a když jich zavolám více, tak budou spolu běžet paralelně. Ale neimplikuje to nutnost. Klidně můžu zavolat dvě funkce neblokujíce (s callbackem), oni se mi na sobě nezávisle zavolají (to znamená, že nemám zaručeno, která se spustí první), ale z nějakého implementačního důvodu (http://devel.cz/otazka/async-immutable) se spustí za sebou - takže nejsou paralelní.

Stejně tak bych, když bych se hodně snažil, určitě našel i případ, kdy budu mět asynchronní, blokující, neparalelní...

Správně?

1882

Vývoj / Re:Logické programovací jazyky?

« kdy: 23. 07. 2015, 00:23:01 »

Taky si myslím, nedávno jsem přesně tohle použil: Elixir na výkonnou část, Prolog na dotazování nad daty. Akorát to někdy asi může být trochu problém technickej - interoperabilita různých jazyků nebývá procházka růžovou zahradou

Jsem někde viděl implementaci Prologu (nebo jeho části) v CL. Jak jsi to měl řešené v Elixíru?
V PostgreSQL je to naopak. Základní engine je jakože logické, a ty rutiny můžeš psát v široké paletě jazyků. Java, Python, Lua,...

1883

Vývoj / Re:Logické programovací jazyky?

« kdy: 23. 07. 2015, 00:13:56 »

Existují jazyky, které jsou zaměřeny primárně na logiku než na čísla apod.?

Ano. Akorát teda datové typy mají víceméně stejné, na těch až tak nesejde. Spíš je tam ta logika jako hlavní nástroj pro popis struktury algoritmu a dat. Pro programování obecných věcí se to moc neujalo, nejspíš proto, že to je takové... trochu specifické a ne úplně intuitivní, takže si s tím asi moc programátorů nechce lámat hlavu   V podstatě jde o to, že abys v logickém programovacím jazyku provedl nějaký výpočet o předem daných krocích, musíš mu předhodit nějaká fakta a odvozovací pravidla a svým způsobem odvozovací engine donutit, aby postupoval přesně tou cestou, kterou chceš, aby postupoval, takže je to trochu přes ruku...

A není lepší v takových případech udělat úkrok stranou, a takový imperativní výpočet vytknout do nějaké rutiny... V SQL na to jsou uložené procedury, a přijde mi ta provázanost logického a imperativního celkem fajn.

1884

Studium a uplatnění / Re:Funkcionální programátor

« kdy: 08. 07. 2015, 01:33:30 »

Když budu mět kdekoliv v kódu číslo, tak ho mohu bezezbytku přetavit na Maybe monádu. A naopak. Zatímco když budu mět to samé v IOMonádě, tak se jí, jako jediné, nezbavím. A při všech transformacích ji tam budu tahat jak vocásek. To znamená, že ta substituce se provede - ale s ocáskem. A možná proto bych ji za čistou neprohlásil.

Já pořád nějak nechápu, kde vidíš problém. Pokud fce vrací IO Int, tak prostě vrací nějaká data. Pokaždé stejná pro stejné argumenty. A přesně tak to má být. Kde je problém?

Myslím, že už tě chápu.

1885

Studium a uplatnění / Re:Funkcionální programátor

« kdy: 08. 07. 2015, 01:19:54 »

Jenže stále to neřeší ten problém. Stavím na tom, že substituce výrazů je podmínka pro označení jazyka za (pure) funkcionální. Tím, že jsi to zakázal befelem, jsi tu substituci neumožnil.

Říkám, že v čistém jazyce nemůžeš při dvou volání stejné fce se stejnými argumenty dostat něco jiného. Pokud by runIO existovalo, tak prostě uděláš dvakrát po sobě "runIO a" a pokaždé dostaneš něco jiného. Takže:

jazyk je čistý -> v jazyce nemůže existovat runIO

...ne naopak!

O runIO nejde. Jde o to, že nejde udělat substituci výrazu.

Jazyk je čistý, pokud mohu, mimo jiné, provádět nahrazení výrazu její hodnotou - alespoň takhle jsem to vždycky četl. O runIO tam nic nebylo :-)

Když budu mět kdekoliv v kódu číslo, tak ho mohu bezezbytku přetavit na Maybe monádu. A naopak. Zatímco když budu mět to samé v IOMonádě, tak se jí, jako jediné, nezbavím. A při všech transformacích ji tam budu tahat jak vocásek. To znamená, že ta substituce se provede - ale s ocáskem. A možná proto bych ji za čistou neprohlásil.

1886

Studium a uplatnění / Re:Funkcionální programátor

« kdy: 08. 07. 2015, 01:02:09 »

Ne. Není to možné přesně z opačného důvodu, kdyby taková funkce existovala, tak potom by to čisté nebylo. Teď to čisté je.

Kuc, kuc...

Proč musím? Proč je to tak správně? A proč to znamená, že když by to bylo možné, tak by Haskell čistý nebyl?

Kód: [Vybrat]

unpackMonad :: Maybe Int -> Int
unpackMonad Nothing = 0
unpackMonad Maybe i = i

No protože pokud by tohle šlo udělat s IO monádou, tak bys právě dostal různé hodnoty pro různá volání funkce, a to prostě nesmíš dostat

To už je lepší.

Jenže stále to neřeší ten problém. Stavím na tom, že substituce výrazů je podmínka pro označení jazyka za (pure) funkcionální. Tím, že jsi to zakázal befelem, jsi tu substituci neumožnil.

1887

Studium a uplatnění / Re:Funkcionální programátor

« kdy: 08. 07. 2015, 00:53:07 »

Tu logiku nechápu. Proč bych se nemohl monády zbavit? Maybe, nebo Either se zbavit lze. Jak vzniká souvislost, že: "kdyby to bylo možné, pak by Haskell čistý nebyl. Možné to není a Haskell čistý je."? Naopak mě přijde, že díky tomu, že IOMonádu nelze substituovat, tak to znamená, že není čistá.

Pokud máš někde proměnnou "a" typu IO Num, tak nemůžeš provést něco jako "runIO a", dostat z ní ten integer a dál pokračovat čistě jenom s integerem. Vždycky musíš začít v IO monádě (main fce) - z ní můžeš tímpádem mít větve, které taky provádí IO. Nemůžeš ale IO větev naroubovat na ne-IO větev. Aspoň myslím teda

Proč musím? Proč je to tak správně? A proč to znamená, že když by to bylo možné, tak by Haskell čistý nebyl?

Kód: [Vybrat]

unpackMonad :: Maybe Int -> Int
unpackMonad Nothing = 0
unpackMonad Maybe i = i

 

1888

Studium a uplatnění / Re:Funkcionální programátor

« kdy: 08. 07. 2015, 00:41:25 »

Neexisuje něco jako runIO protože runIO nelze nahradit svým výstupem.

Můžeš tu monádu předávat celým program a vyplivnout ji do main, ale nemůžeš se jí uprostřed programu "zbavit" = "spustit ji" - a to právě proto, že kdyby to bylo možné, pak by Haskell čistý nebyl. Možné to není a Haskell čistý je.

Tu logiku nechápu. Proč bych se nemohl monády zbavit? Maybe, nebo Either se zbavit lze. Jak vzniká souvislost, že: "kdyby to bylo možné, pak by Haskell čistý nebyl. Možné to není a Haskell čistý je."? Naopak mě přijde, že díky tomu, že IOMonádu nelze substituovat, tak to znamená, že není čistá.

1889

Studium a uplatnění / Re:Funkcionální programátor

« kdy: 06. 07. 2015, 21:56:36 »

Vtip je v tom, že nemůžeš.

Proč?

Nepřekračoval by si její (ideovou) zodpovědnost?

1890

Studium a uplatnění / Re:Funkcionální programátor

« kdy: 06. 07. 2015, 21:50:50 »

Zatímco u Unique typingu to ideově vadí.

No a tohle omezení můžeš úplně klidně k monadickému řešení přidat a máš totéž (imho). To je ta pointa.

Vtip je v tom, že nemůžeš.