Příspěvky

871

Vývoj / Re:Komerčné projekty v golang?

« kdy: 06. 06. 2016, 16:08:38 »

Moze mi niekto vysvetlit co mi go prinesie oproti modernym jazykom ako Swift, F#, Rust, Scala?

V com je Go taky uzasny a revolucny?

Go není úžasné ani revoluční, oproti C(++), Swiftu a Rustu má navíc jen GC, což by ani nebyla výhoda, kdyby ten GC nebyl tak efektivní, jak ho Go od verze 1.5 má. Pokud se člověk smíří s některými omezeními (např. absence dědičnosti a generických typů), tak je to prostě jen relativně jednoduchý a rychlý jazyk pro nízkoúrovňové věci. Má také poměrně rozsáhlou standardní knihovnu.

872

Bazar / Re:Sháním knihu "Dokonalý kód" - Stephen McConnell

« kdy: 05. 06. 2016, 01:31:35 »

Zdravím, pátrám po této knize už delší dobu, ale v knihkupectvích a e-shopech bohužel marně. Nenajde se nějaký dobrák, který by ji za rozumnou cenu prodal zde? 

Amazon

873

Vývoj / Re:Komerčné projekty v golang?

« kdy: 04. 06. 2016, 23:15:43 »

Šablonové metaprogramování je na dvě věci. Mnohem užitečnější by byla variance typů nebo extenzivní protokoly.

Možná byste měl tento názor prezentovat autorům standardní knihovny C++ nebo takových chuťovek, jako je boost::msm  Trochu odbočím - zajímalo by mě, jestli je někde jednoduše vysvětlené, jak jsou všechny tyhle objektové a funkcionální vychytávky Swiftu implementované?

Je to v oficiální dokumentaci a kód je open source.

874

Vývoj / Re:Komerčné projekty v golang?

« kdy: 04. 06. 2016, 22:44:27 »

Například nemá varianci typů nebo pattern matching. Taky nemá možnost omezovat generické parametry podle protokolů. O správě paměti se ani nezmiňuju - bez chytrých ukazatelů ani ránu. Reflexe je taky z těchto jazyků nejomezenější (to ovšem neberu jako nevýhodu, ale když už byla zmíněna...).

Variance typů v C++ je docela zamotaný problém kvůli obecnosti mechanismu šablon, kdy se mohou specializace tmplt<B> a tmplt<D> zásadně lišit, i když D je třída odvozená z B. Uznávám, že pattern matching je šikovný syntaktický cukr, ale asi bych ho nepovažoval za zásadní argument pro volbu jazyka. Ohledně správy paměti: v C++ si můžu vybrat z různých mechanismů nebo si implementovat vlastní. Swift mi pro třídy nutí alokaci na haldě a reference counting.

Reference counting je užitečný. Nicméně zásadní je právě flexibilní typový systém a lepší polymorfismus.

875

Vývoj / Re:Komerčné projekty v golang?

« kdy: 04. 06. 2016, 22:34:38 »

Nie ze by to malo nejake prakticke uplatnenie (zatial), ale https://www.reddit.com/r/programming/comments/4l5is8/java_generics_are_turing_complete/

Dík za odkaz, to je zajímavé a nevěděl jsem to. Ale já jsem zmínku o turingovské úplnosti myslel spíš z praktického hlediska. Tedy že v C++ lze při překladu pomocí šablon (a taky constexpr funkcí) něco netriviálního a užitečného rozhodnout nebo spočítat.

Šablonové metaprogramování je na dvě věci. Mnohem užitečnější by byla variance typů nebo extenzivní protokoly.

876

Vývoj / Re:Komerčné projekty v golang?

« kdy: 04. 06. 2016, 21:13:34 »

Jistě. C++ má poněkud omezený polymorfismus. Go sice také, ale úplně jinak (nemá dědičnost, jen rozhraní). Swift má rozhraní, dědičnost (trvá-li na ní někdo) i hodnotové typy, z pohledu OOP je nejflexibilnější. K tomu má ještě mnoho funkcionálních rysů. Prostě v ničem podstatném neomezuje, kdežto v C++ i Go člověk dříve či později narazí a musí začít různá omezení obcházet, což je opruz.

Asi OOP moc nerozumím... V čem je v C++ omezený polymorfismus nebo méně funkcionálních rysů, ať už obecně, nebo v porovnání se Swift? C++ má rozhraní (vícenásobnou dědičnost), dědičnost, i hodnotové typy, k tomu i trochu reflexe. Taky má lambdy, std::function, std::bind a template metaprogramming. Myslím, že turingovsky úplnému (možná jenom skoro) čistě funkcionálnímu compile-time templatovému jazyku v C++ se generické typy ve stylu Swiftu nebo Javy funkčností ani nepřibližují.

Například nemá varianci typů nebo pattern matching. Taky nemá možnost omezovat generické parametry podle protokolů. O správě paměti se ani nezmiňuju - bez chytrých ukazatelů ani ránu. Reflexe je taky z těchto jazyků nejomezenější (to ovšem neberu jako nevýhodu, ale když už byla zmíněna...).

877

Vývoj / Re:Komerčné projekty v golang?

« kdy: 04. 06. 2016, 19:45:54 »

Tak C++ má taky určité problémy. Go je na něco příliš jednoduchý (zmíněná generika) a používám ho jen pro jednodušší servery, ale své výhody má. Nicméně nejlepší je z nativně překládaných jazyků Swift.

Máte na mysli nějaké konkrétní problémy C++, které by řešily Go nebo Swift? Snad každý jazyk má své výhody (a nevýhody). Ale je otázka, jestli ty výhody stojí za tu námahu se dotyčným jazykem zabývat. Tvrzení, že Swift je nejlepší, nemá bez uvedení hodnotících kritérií vůbec žádný smysl.

Jistě. C++ má poněkud omezený polymorfismus. Go sice také, ale úplně jinak (nemá dědičnost, jen rozhraní). Swift má rozhraní, dědičnost (trvá-li na ní někdo) i hodnotové typy, z pohledu OOP je nejflexibilnější. K tomu má ještě mnoho funkcionálních rysů. Prostě v ničem podstatném neomezuje, kdežto v C++ i Go člověk dříve či později narazí a musí začít různá omezení obcházet, což je opruz.

878

Vývoj / Re:Komerčné projekty v golang?

« kdy: 04. 06. 2016, 17:25:00 »

Ne. GO je špatný jazyk a nikdy se nerozšíří.

Nepřináší nic extra navíc oproti ostatním jazykům.

Kdysi jsem si o něm přečetl hezký článek v kterém bylo víc kritiky než chváli a díky němu jsem s ním neztrácel čas.

Bylo pro mne překvapením že jazyk od tvůrců plan 9 je tak fádní.

Souhlasím se vším, kromě toho, že se nerozšíří. Go z technického pohledu nedává moc smysl. Řeší problémy, které C++ vyřešilo lépe nejpozději ve standardu C++11, nebo které by se daly v C/C++ vyřešit lépe a s menším úsilím, než vytvořením nového jazyka. K tomu přidává svoje nové problémy, které se autoři a propagátoři jazyka pokouší zamaskovat. To ale bohužel neznamená, že se nerozšíří z jiných důvodů, např. marketingových.

Tak C++ má taky určité problémy. Go je na něco příliš jednoduchý (zmíněná generika) a používám ho jen pro jednodušší servery, ale své výhody má. Nicméně nejlepší je z nativně překládaných jazyků Swift.

879

Vývoj / Re:Komerčné projekty v golang?

« kdy: 04. 06. 2016, 17:02:22 »

No cloveka ktory dokaze pouzit c++ v spojeni rajska zahradka asi tazko presvedcim a vlastne ma tvoj pohlad na ten jazyk nezaujima. Navyse toto vlakno nie je o tom, ci je to dobry jazyk.

Tento thread ma inspiroval si ten jazyk vcera vyskusat. A ked som v tom zacal pisat, rozculilo ma to tak, ze som sa tu musel trochu vyventilovat. Je lespie dat to zo seba von, ako nosit to v sebe. 
Diky za nastartovanie threadu 

Tak furt to je lepší než Java

Go nemá generika pro uživatelsky definované typy, což ho IMO činí v podstatě nepoužitelným.

Pravda, nemá. Go je záměrně co nejjednodušší.

880

Vývoj / Re:Komerčné projekty v golang?

« kdy: 04. 06. 2016, 15:27:51 »

No cloveka ktory dokaze pouzit c++ v spojeni rajska zahradka asi tazko presvedcim a vlastne ma tvoj pohlad na ten jazyk nezaujima. Navyse toto vlakno nie je o tom, ci je to dobry jazyk.

Tento thread ma inspiroval si ten jazyk vcera vyskusat. A ked som v tom zacal pisat, rozculilo ma to tak, ze som sa tu musel trochu vyventilovat. Je lespie dat to zo seba von, ako nosit to v sebe. 
Diky za nastartovanie threadu 

Tak furt to je lepší než Java

881

Vývoj / Re:Komerčné projekty v golang?

« kdy: 03. 06. 2016, 19:39:25 »

Ahoj. Casto sa tu preberaju rozne alternativne jazyky. Da sa to vobec pred klientom nejako obhajit (a aj na mensie projekty)? Napr by som velmi chcel skusit urobit web v golang, ale ako na to? Nehovorim, ze web kde navstevnost 1 za tyzden, tam skor php a zdielany hosting, ale nieco co ma realnu navstevnost a generuje zisk.

Go je dost dobrý jazyk s kvalitní implementací, nicméně poněkud jednoduchý (záměrně). Má kvalitní GC a hodí se na jednodušší aplikační servery, ale z hlediska řekněme elegance a estetičnosti je mnohem zajímavější Swift. Je možné, že časem budou tyto dva jazyky konvergovat.

882

Vývoj / Re:Má Haskell budoucnost?

« kdy: 21. 05. 2016, 21:51:02 »

Kategorii máme přece jen jednu.

No ano, ale je to prostě mapování odněkud někam a mapuješ funkce. I když prakticky to je aplikace na hodnoty, což je matoucí.

No ať je to jak chce, jdu konečně hrát, hezký zbytek večera

Já to radši shrnu, ať to nějak rozmotáme (tím "liftnutím" se to zamotalo příliš). Mějme

Kód: [Vybrat]

protocol Boxable {}
enum Box {
    case Some(Boxable)
}
extension Int : Boxable {}
let list = [1, 2, 3].map(Box.Some)
print(list)

Na Box.Some se dá dívat jako na morfismus z Boxable na Box, což jsou objekty naší jediné kategorie. Funktor (každý je endofunktorem) může mapovat třeba právě Boxable na Box nebo Box.Some na něco, ale samotné Box.Some funktorem není (v kategorii typů, v Haskellu tedy Hask).

P.S. Užij si hraní

883

Vývoj / Re:Má Haskell budoucnost?

« kdy: 21. 05. 2016, 20:46:20 »

ale funktory se aplikují na morfismy, ne hodnoty. Každopádně tomu asi rozumíme oba a jen se trochu popletla terminologie.

No to sice jo, ale když máš to f: D a -> D b, tak jsi vlastně f (tj. morfismus) liftnul z jedné kategorie ({a,b}) do druhé ({D a, D b}). Nejsem si jistej, jestli je korektní říct o D samotném, že je to funktor. Spíš by na to musel být ještě jiný symbol, označující tu vlastní operaci f -> D(f). Každopádně v Haskellu se functor říká té vlastní věci, která se mapuje přes hodnoty:

Kód: [Vybrat]

class Functor f where
  fmap :: (a -> b) -> f a -> f b

Ale nevylučuju, že to teď motám, momentálně mám v hlavě spíš to, že jsem si koupil http://store.steampowered.com/app/319630/ a nemůžu se dočkat, až si to zahraju

Teď jsi to zamotal ještě víc Kategorii máme přece jen jednu. Mně šlo jen o to, že to D funktor není.

884

Vývoj / Re:Má Haskell budoucnost?

« kdy: 21. 05. 2016, 20:00:06 »

Když na tím teď tak přemýšlím, tak mě zarazilo, že tomu říkáš endofunktor, ten by měl operovat na jiné úrovni, ale třeba jsem to jen blbě pochopil.

No to máš asi pravdu, to byl ukvapenej závěr, jehož problematičnost jsem si hned uvědomil a chtěl poladit tím editem, ale ani tak si nejsem jistej, jestli jsem nenapsal blbost

Pokud bysme měli kategorii haskellovských typů, tak funkce jsou morfismy a datakonstruktorem D můžeš mapovat

f: a -> b

na

f: D a -> D b

takže funktor to je a protože i (D a) je haskellovský typ, tak by to měl být endofunktor.

...ovšem pokud přijmeme, že konstruktor je normální funkce, tak se nám to trochu pomotá a nevím, jestli by to pak takhle šlo říct, protože tímpádem by to byl morfismus.

No, hele, s tím si musíš poradit spíš ty, pro mě je to na pokraji mých znalostí

Pořád si myslím, že mícháš dvě různé věci. "CiselnaHodnota" nebo něco takového je morfismus, ale funktory se aplikují na morfismy, ne hodnoty. Každopádně tomu asi rozumíme oba a jen se trochu popletla terminologie.

885

Vývoj / Re:Má Haskell budoucnost?

« kdy: 21. 05. 2016, 18:51:59 »

Nebo:

Value constructors are actually functions

http://learnyouahaskell.com/making-our-own-types-and-typeclasses

Když na tím teď tak přemýšlím, tak mě zarazilo, že tomu říkáš endofunktor, ten by měl operovat na jiné úrovni, ale třeba jsem to jen blbě pochopil.