Příspěvky

601

Vývoj / Re:Dědičnost dnes

« kdy: 30. 01. 2017, 19:26:08 »

Jeho odpovědi nedávají smysl, se slávou to nemá co dělat. Koncept rozdělení dat a funkcí jsem pochopil, neměnitelné stavy dosud neviděl. To tvrdíte vy.
Matici a vektor rozepište.
Možná by bylo vhodné připomenout nevýhody rozdělení ve FP.
V čem spočívá ta chyba tříd?

Nekomu kdo nezna FP, asi nedavaji smysl. To se neda nic delat.

V FP funkce a data nejsou fakticky az tak rozdelene, jak podotkl BoneFlute. Oboji jsou hodnoty nejakeho typu, jediny rozdil je v tom, ze funkci muzeme aplikovat na hodnoty nejakeho daneho typu.

Problem v tridach je v tom, ze pokud se praktikuje FP, jsou proste zbytecne. Tridy fakticky jen zaobaluji promenne (nebo jejich skupiny), abychom zarucili jejich konzistentni stav. Jelikoz v FP promenne nejsou, pouze hodnoty, neni potreba je zaobalovat. Konzistence stavu se vynucuje predevsim pomoci imutability, typovymi omezenimi, a eventualne, jak tu opakovane podotkl v, skrytim konstruktoru.

Ono to souvisí trochu víc, v OOP s generickými třídami jsou v podstatě funktory a v FP se právě funktory používají na to samé, jen OOP se drbe levou rukou za pravým uchem a FP pravou za levým.

602

Vývoj / Re:Prepojenie Raspberry Pi / Arduino a PHP

« kdy: 30. 01. 2017, 18:22:42 »

Zdravím,

chcel by som Vás požiadať o radu.
Potreboval by som prepojiť buď Arduino alebo Raspberry Pi s PHPčkom.

Mám webovú aplikáciu umiestnenú na webhostingu a potreboval by som, aby v prípade úspešného odoslania formuláru odoslalo požiadavok na Raspberry Pi alebo Arduino aby rozsvietil LED diódu.
Našiel som riešenie pre localhost, ale nie pre webovú aplikáciu umiestenú na vzdialenom webhostingu.

Vedel by mi niekto pomôcť ako by sa to dalo vyriešiť?

Ďakujem veľmi pekne za každú radu.

Na to stačí (long) polling, je to příklad jednoduché webové služby (v principu push).

603

Vývoj / Re:Dědičnost dnes

« kdy: 30. 01. 2017, 14:48:44 »

Jadro Armstrongova argumentu je v tom, ze michani funkci a dat neni dobry napad.

Měl jsem za to, že v Haskellu (při troše fantazie) je všechno funkce, nic nejsou data. I takový symbol 42 je jen nulární funkce.

Teoreticky jo, každá konstanta je funkce. Ovšem každé číslo je čistě matematicky taky tenzor a stejně z něj v IT Integer nebo Float nedědí. Proto spíše než dědičnost - abychom se vrátili k tématu vlákna - je lepší používat hierarchii rozhraní, pak můžu Integer nebo Float modelovat třeba jako speciální případ komplexního čísla, což by sice dědičností šlo taky, ale má to v klasicky pojatém OOP dost negativních důsledků.

604

/dev/null / Re:Existuje ve vesmíru inteligentní život?

« kdy: 30. 01. 2017, 14:39:54 »

Na Platóna zapomeň, na anglických školách už ho škrtají z učebnic, protože byl bílý.

To je trochu zavádějící, nic se neškrtá, jen pár idiotů studujících na Škole orientálních a afrických studií napsalo petici požadující, aby se díla Platóna a pár dalších bílých filozofů zasazovala do kritického (kolonizačního) kontextu. Je to stejná blbost, jako když pár blbečků v USA protestuje proti hře zasazené do středověké Prahy, že v ní jsou jen bílé postavy. Už nevím, co to bylo za hru, alu tvůrci jim odepsali, že tam teda přidají pár černých otroků.

605

Vývoj / Re:Dědičnost dnes

« kdy: 30. 01. 2017, 14:07:54 »

Ovšem nic z výše uvedeného nemění nic na faktu, že objektově orientované programování je trošku něco jiného než Java. A že problémy, které jsou představovány jako problémy OOP, jsou ve skutečnosti problémy Javy. Jinou otázkou je, jak moc jsou ty problémy v praxi palčivé a nakolik jsou spíš akademické. Dalším nemilosrdným faktem je taky skutečnost, že průměrný program v Javě je stále mnohonásobně rychlejší a méně náročnější na paměť než program ve Smalltalku, ale i Objective C.

Smalltalk jsem nikdy neměřil, ale pro ObjC to neplatí ani náhodou, rychlost je srovnatelná (někdy vyšší, protože value types), a paměťově náročnější je Java v podstatě vždy (pokud se teda nepoužije ObjC s GC, ale ten už ani Xcode neumí použít a v macOS už taky ani nejsou příslušné knihovny). Zrovna nízká náročnost na paměť je důvodem, proč Apple zahodil svůj celkem pokročilý GC a nasadil statickou analýzu (ARC).

606

Vývoj / Re:Dědičnost dnes

« kdy: 30. 01. 2017, 13:57:52 »

V žádné rozumné implementaci nebude matice implementovaná jako kompozice vektorů, tím by byl přístup jen k řádkům nebo sloupcům. Nejflexibilnější řešení je mít obecnou kolekci pro vícerozměrné pole (pro modelování tenzorů) s metodami charakteristickými pro matice a vektory...

Klidně tenzory nebo fázory, o to tu nejde, podstatou bylo odpálkovat jakékoliv pokusy o hledání specializace/generalizace mezi maticí a vektorem.

Fázory asi těžko. Jinak ta specializace tam samozřejmě je (velice zřetelná), jen u dimenzí v řádech tisíců a více vůbec nic nepřináší.

607

Vývoj / Re:Dědičnost dnes

« kdy: 30. 01. 2017, 13:55:24 »

...
Chápu. Tím se objevuje další otázka, jak se modelují vzájemné závislosti (cykly) v datech.

Rekl bych, ze uplne stejne jako v relacni DB - tj. idcka (ale nejsem zadny guru , tak treba to jde i jinak).

Je to podobné jako problém autoreference v logice, prostě se vytvoří další metaúroveň (akorát se jí tak neříká).

608

Vývoj / Re:Dědičnost dnes

« kdy: 30. 01. 2017, 13:34:16 »

Matici je možno modelovat vektory, pak půjde o skládání!!!

V žádné rozumné implementaci nebude matice implementovaná jako kompozice vektorů, tím by byl přístup jen k řádkům nebo sloupcům. Nejflexibilnější řešení je mít obecnou kolekci pro vícerozměrné pole (pro modelování tenzorů) s metodami charakteristickými pro matice a vektory. Pro různé pohledy na příslušná data se použijí views nebo slices, tedy "něco jako" rozhraní. Nejen že to je takto nejefektivnější, ale zároveň se dodrží myšlenka "čistého" OOP (chceme-li na ní trvat). Praktický problém s takovouto implementací je jen jeden: ve většině jazyků to takto nepůjde (mně známými výjimkami jsou Smalltalk, ObjC a možná Swift).

609

Vývoj / Re:Dědičnost dnes

« kdy: 30. 01. 2017, 09:50:55 »

Každopádně důsledkem je, že vnitřně je modul sice immutable, ale navenek (a to mě v interakci s ostatními zajímá) pochopitelně mutable.

Tady nebezpečně motáš pojmy. Mutabilita se týká dat. Co je "mutabilita modulu", to bysme si museli nějak zadefinovat, jinak to bude plácání o koze a o voze

Tohle by bylo třeba dořešit, protože tu vznikl dojem, že FP je tak nějak celé immutable, což mi bylo hned od začátku jasné, že je to hovadina. Proto jsem se ptal, jak přechází systém (jako celek) mezi stavy.

Čisté FP je immutable.

610

Vývoj / Re:pseudocode-minimalisticka syntaxe

« kdy: 29. 01. 2017, 23:08:44 »

dobry den, nejsem programator, inspirovalo mne cteni par bash scriptu, batch souboru, je to jen takovy napad slo by vytvorit nejakou minimalistickou syntaxi pro pseudocode ktera by mi umoznovala plne se vyjadrit  ?
predpokladam ze nezbytne budou promenne, cykly (for i in X do Y), podminky (if then do X else do Y), while X do Y, goto, gosub, return, start, end, elseif (true, false), pak nejake "get from file nebo load .. nebo read .." pro nacteni dat treba ze souboru a "write to file .. .."pro zapis do souboru

jeste neco co je nezbytne nutne aby to splnovalo to minimalisticke zadani s plnymi vyjadrovacimi schopnostmi ?

v podstate mi jde o jen o absolutne nezbytne zakladni stavebni prvky takoveho pseudojazyka (chtel bych vytvorit slovnik ktery obsahuje prikaz (slovo ci slovni spojeni) - vyznam ), kterym bych byl schopen vyjadrit v podstate jakykoliv algoritmus nebo popsat nejake zadouci chovani, funkci co by pozadovany program mel umet, popsat jakykoliv problem a navrhovane reseni ?

jde mi o vytvoreni "zakladni slovni zasoby" takoveho pseudojazyka, co nejjednodussi, nejprimitivnejsi, minimalisticke

posleze prevedeni z pseudokodu (ktery bych predal i se slovnikem slovni zasoby vysvetlujicim vyznam pouzitych vyrazu)  do opravdoveho programovaciho jazyka bych jiz zadal profesionalovi ktery by na dany problem zvolil nejvhodnejsi prostredek z hlediska produktivity, rychlosti vyvoje pozadovane "aplikace"

Stačí mrknout na Lisp nebo Smalltalk.

611

Vývoj / Re:BSD licence vlastního kódu a zaměstnavatelé

« kdy: 29. 01. 2017, 22:53:55 »

Ahoj,

Jedná se prakticky o dotaz na postup ojebání zaměstnavatele, co si bude nárokovat vlastnictví na můj softwarový "výtvor".

Mám napsané nějaké vlastní knihovny a používám je i na hobby projektech doma a zároveň v práci.

Tyto knihovny jsou použity v nějakém produktu zaměstnavatele. Přijde třeba den, kdy změním zaměstnavatele a jelikož mě u toho nového čeká víceméně to samý, tak tyto knihovny chci používat i tam. Znovu zdůrazňuju, že tyto zdrojáky jsem vyvíjel jenom já - ať už doma jako hobby, na školní projekty nebo v pracovní době ve firmě.

Je jasné, že původní firma nezveřejní zdrojáky produktu. Jde mi třeba o situaci, kdy v nové práci přijde nový kolega, který předtím dělal v té samé firmě, a uvidí tam, že tam vývojáři využívají stejné knihovny napsané mnou v minulé práci a upozornit na to bývalého zaměsnavatele - a já můžu mít průser.

Dá se toto obejít tak, že do zdrojáku naházím texty ohledně BSD licence, uploadnu to například na SourceForge a budu tvrdit zaměstnavateli při odevzdání, že v produktu jsem použil knihovny z tohoto zdroje?

Teoreticky stačí mít vlastní kód (zárodek knihovny) pod LGPL a pak tu knihovnu rozšiřovat v práci. Podle licence se ty změny musí nabídnout. Morální to ale není, pokud o tom zaměstnavatel neví. Na druhou stranu licence si má hlídat a použití LGPL může zakázat.

612

Vývoj / Re:Technologie pro webovou aplikaci

« kdy: 29. 01. 2017, 22:32:25 »

Všude píší, že je to sračka, a lidi to přesto používají.

Teorie vs praxe. Zboj nebo Mirek Prýmek ti místo toho ochotně doporučí nějakou naprosto dokonalou technologii ... která má jedinou vadu ... skoro nikdo jí nepoužívá.

Neco něco kvalitního, co se používá.

613

Vývoj / Re:Technologie pro webovou aplikaci

« kdy: 29. 01. 2017, 22:27:50 »

Samotný jedno node na jednom CPU dokáže utáhnout pěkně velký množství spojení

To umí cokoliv, co používá kqueue nebo epoll.

614

Vývoj / Re:Dědičnost dnes

« kdy: 29. 01. 2017, 22:21:50 »

Definuji vektor a skalární součin jakožto jednu z jeho operací.
Matice bude mít vnitřní reprezentaci pole m×n, budu-li potřebovat přistupovat k řádkovým/sloupcovým vektorům, nabídne je matice ad hoc pomocí vektoru.

To neni uplne idealni, protoze ta matice bude muset pro dany radek/sloupec vytvorit novy vektor.

Nebude, stačí vytvořit něco jako view nebo slice nad jedním řádkem nebo sloupcem (nebo obecně pro podmatici). Úplně nejlepší by ovšem bylo mít jen typ tenzor a veškeré potřebné operace definovat pomocí násobení tenzorů, pak stačí jedna implementace pro vše včetně skalárního součinu. Jediný problém je se skaláry, ty jsou teoreticky taky tenzory, ale implementačně moc ne.

615

Vývoj / Re:Technologie pro webovou aplikaci

« kdy: 28. 01. 2017, 23:52:42 »

Sorry, nevzpomenu si ani co tam přesně bylo, ani kde jsem to četl, ale byl to prostě nějakej blogpost od týpka, co právě psal, jak si to s Node.js maloval a pak ho z toho po nasazení málem jeblo, tak zas radši vycouval

Jo, tak jsem to kupodivu našel (level: Google master! ): https://blog.geekforbrains.com/after-a-year-of-using-nodejs-in-production-78eecef1f65a

Node.js je sračka, ale ta základní myšlenka je dobrá - NIO a jedno vlákno, co víc si přát. Akorát teda mnohem lepší je analogická implementace v C (libevent), C++ (má lambdy), případně s využitím GCD (má lambdy jen při překladu clangem a bez kqueue je pomalé, ale jinak nejlepší) nebo rovnou v Go, které je v tomto ohledu asi nejlepší.

BTW jak se řeší NIO v FP?