Příspěvky

166

Odkladiště / Re:Vlastní operační systém.

« kdy: 05. 01. 2017, 08:09:28 »

Jak jsem psal vyse, to neni problem Linuxu, ale softu treti strany. Podobne bych mohl nadavat Widlim, ze neumi poradne pripojit sitovej disk pres ssh (nebo uz ten polomrtvej projekt snad prekrocil prah extremni nestability a je nyni jen nestabilni?), nejdou pripojit oddily v Linuxich FS nebo ze me tam nefunguje hra zkompilovana pro Linux.

Po pravde, pokud se bavime o vyvojarich, tak jedinny duvoch proc zustavat u Widli vidim v tom popsanem vendor locku. Ostatne proto jsem se uplne preorientoval na pouzivani technologii, ktere jsou multiplatformni (a idealne i svobodne) - zacatkem VS jsem byl poblouznen C#, Visual Studiem, atp. Postupne jsem ale z vseho toho MS sveta "pro sebe" vyrostl a presel k otevrenejsim technologiim, kde je spousta moznosti a ne jen ten MS-approved-way (proto take nemam asi rad Python, ma vlastne stejny pristup a proto je v nem napr. FP tak krkolomne).

OP to bude mit s vlastnim "OS" tezke - staci se podivat na toto vlakno, jak dva/tri moloch OS, ktere meli desitky let casu, kamiony penez, stovky vyvojaru a presto jsou stale problematicke.

167

Odkladiště / Re:Vlastní operační systém.

« kdy: 04. 01. 2017, 15:55:31 »

Jinak odkazovat se na dotazy na fórech pro BFU, kterým radí další BFU, je trochu nefér. Doktor taky nebude argumentovat odpověďmi nějakých negramotných léčitelů a vydávat je za fakta, když se mu to hodí.

Jsem si celkem jisty, ze slo o to oficialni support forum nebo co to je. Kazdopadne jak to, ze na Linuxu se takova vec nedeje? Vzdyt tam uz tuplem neni zadne ofiko forum, ktere se plati z koupi softu. Reseni problemu s Linuxem (Ubuntu, Debian, CentOS) hledam po forech a ruznych QA sitich a vychazi to lip, nez rady ophledne oprav Widli, ktere davaji "otitulovani" lidi na ofiko foru.


Asi me tu ukamenuji, ale i to nemenne prostredi 10ek se mi celkem libilo. Presto bych ocenil lepsi moznosti u oken, treba nastavit si, ze tuto aplikaci bude poustet defaultne na tomto monitoru. Nebo vice ploch a moznost nastavit si, ze se urcita aplikace spousti na dane plose.

Win 7 jsem mel take dlouho. Sice fungovaly dlouho, ale zpomaleni bylo citelne, hlavne startu a vypinani. To se me zatim s Linuxem nestalo - na tom "servru" bezel na mnohem horsim HW dele nez ty 7my u me na desktopu a start byl vzdy rychlejsi ("server" v uvozovkach, protoze tam bylo i graficke rozhrani dostupne pres VNC atp., takze spis slo o stale-jedouci desktop ovladany vzdalene).

IDEA nemela nejake IDE pro C++?

A abych neco prispel k tematu, zacal bych hodne zlehka, tj. sepsani si ficur, co chci, hezky mock toho, jak to ma vypadat, hodil to treba na github a zkusil se poptat po redditech a forech, co si o tom lidi mysli. Pak bych nejdrive zkusil existujici reseni, jak tu nekteri uz napsali, a az kdybych zjistil, ze to s temi nejde, tak bych sel implementovat toolkit po svem a spise ocekaval, ze to nikdy nedodelam a pokud to dodelam, ze se to nikdy nechytne. IMO nejvetsi sanci to ma, pokud se to nejdriv udela jen jako "theme" neceho stavajiciho, nabali se uzivatele/prispevatele a az pak se zacne delat na necem ambicioznejsim, jako prepisu toolkitu a portovani skinu.

168

Odkladiště / Re:Vlastní operační systém.

« kdy: 04. 01. 2017, 14:29:53 »

Ja chapu, ze problemy budou, ale (nejen*) moje zkusenost je, ze opravit Linux stroj byva jednoduche, kdezto opravit Widle byva casto nemozne. Napr. to zname zpomalovani - bobtnani registru a nesmyslne nepromazavani starych updatu (u 7 to byly desitky giga, to na SSD boli). Navic se mi skoro nestava, ze se clenu rodiny zadari rozbit Linuxovy stroj, coz o Widlich neplati (neni to nejaka piratska neupdovana "edice"). Podobne nesnasim umele tlaceni novych verzi Widli pomoci DirectX, IE/Edge, MS store (nebo jak se to jmenuje) atp.

Jednu instalaci Linuxu jsem na servru provozoval vice nez 5 let (dvakrat upgrade systemu). Widle, kdyz se pokusim upgradovat, tak to dopadlo tak, jak pisu vyse (ten problem s explorerem, jde o 8->10 upgrade). A celkove jsou s upgrady widli velke problemy a doporucuje se je nedelat - opet, na forech radi vzdy reinstall, kdyz zminite, ze jste upgradovali. Tohle jsem treba u Debianu nikdy nevidel, ze by v pripade, ze tazatel upgradoval distro, tak mu doporuci reinstall jako bezne a nejlepsi reseni.

Pokud by Widle byly zadarmo, tak bych je bral jako rovnocenou alternativu Linuxu (pro bezna BFU, pro vyvojare jsou moc uzavrene a omezene). Problem je, ze zadarmo nejsou. Takze zatimco u Linuxu bych asi prekousl i nejakou vetsi krpu (musim zaklepat, zatim jsem nezazil, pravdepodobne protoze pouzivam spise stabilnejsi veci), tak u Widli mi samovolne rozbijeni se oficialnimi updaty dost vadi, protoze jsem si za "kvalitu" zaplatil, a narozdil od Linuxu to neni hypoteticky scenar.

169

Odkladiště / Re:Vlastní operační systém.

« kdy: 04. 01. 2017, 12:03:20 »

Muj pristup je pristup pokrocileho uzivatele, ktery ocekava, ze OS vydrzi dele nez par mesicu.

Posledne (asi pul roku zpet) mi Widle 10 umirali pri updatovani - stahl se update, po restartu se zacal aplikovat, selhal, provedl se rollback a tak porad dokola. Zkousel jsem psat na ruzna fora a zkousel to ruzne resit, ale bez uspechu. Kvuli tomu nesly nainstalovat ovladace grafiky (pri neaktualnim systemu instalace spadne) a musel jsem preinstalovat cely OS. Az zpetne jsem zjistil, ze Widle mi zamlcely, ze se i kupa dalsich updatu nezvladla nainstalovat. Hlavne aby uzivatel nebyl moc zmateny, ze, tak nechame par bezpecnostnich updatu neaplikovanych a nic nerekneme...

Widle jsou slaby OS. Na to, kolik penez do nich tece a kolik chteji zaplatit, je to tragicke. Od Linuxu dostavam ve vetsine ohledech lepsi produkt a jedinne co mi chybi je kompatiblita s vice SW, za coz ale Linux jako takovy nemuze.

Historka z posledni doby - pres 2 mesice se mi skoro ciste Widle na SSD vypinaly 5-10 minut (pouzivam je pouze jako spoustec her - je tam v podstate jen steam, battle .net klient a firefox). Nic nebylo zatizene (disk ani CPU), proste po kliknuti na vypnout ze startu se nic nestalo. Az spise omylem jsem prisel na to, ze staci pockat 10 minut, aby se Widle vyply. Jako WTF? Ani nic nezobrazi, ze se vypinaji, zadne varovani, ze neco nejde zavrit. Ne, radeji nic neudelame - po kliknuti na vypnout zavreme start a tvarime se, jako ze se nic nedeje.

Dost otravne je i to skemrani o restart po updatu, v nekterych pripadech mam pocit, ze to ani nejde vypnout (tusim jen ty vyssi edice a navic se to musi resit nekde pres policy editor).

A tohle ze ma byt ten OS vhodny na praci? Bezproblemovy? Nechapu, za co jsem si zaplatil, kdyz od Linuxu dostavam zadarmo lepsi sluzby.

Problemy s vymenou HW a Widlemi nemusim asi dlouze vysvetlovat. Drive je rozbijelo skoro cokoliv - vymena systemoveho disku, procesoru, zakladovky. Psal jsem to tu uz nekolikrat - v domacim serveru jsem upgradoval HW po dobu nekolika let, zmenily se vsechny disky, zakladovka, procesor i vyrobce procesoru, v podstate zustala pouze bedna. Stale si tam spokojene chrochtal Debian upgrovany po nekolik verzi. Widle mi pravidelne umiraly pri vymene zakladovky, systemoveho disku i pri prechodu na jineho vyrobce procesoru.

Samozrejmne pokud se bavime o vyovji, tak musim podotknout, ze nastroje z prikazove radky jsou v Linuxu a Jabku velmi efektivni a malokdy nejake klikatko pod Widlemi zvlada vse, co lze pohodlnet udelat trivialni kombinaci par konozolovych utilit. Ostatne i drive pod Widlemi jsem pouzival porty tech konzolovych Linuxovych nastroju.

lol, krome stylu - zaplatuj si sam, je samozrejme na widlich vetsinou mozne uplne stejne se vrtat v konfigach, ci nastavenich.

MS se dost veci neobtezuje vystavovat nekde v registrech nebo politikach. Co takova moznost prizpusobit si vzhled? Kdyz jsem presel z Widli na KDE, tak jsem byl jak v risi divu, co vsechno si jde nastavit (a to jsem videl pouze klikaci nastaveni).

Pokud resite problemy stylem preinstaluju to a ono se to spravi, tak je pouze ten problem, ze tomu nerozumite.

To mi bylo doporuceno na tech forech. A pokud vim, tak i MS support to takhle resi, na ofiko forech to tam vidim vsude.

Veci ktere se daji resit reinstalaci lze poresit i konfiguraci.

O tom mam sve pochybnosti. Dohledavat v closed sourced produktu jako Widle, co kde nejede, je problem. Logy maji casto akorat nejake obecne cislo chyby, chybova hlaseni byvaji vagni (generic error apod.) a treba tu modrou smrt fakt skvele vylepsili. Je zajimave, ze kdyz nece nefunguje pod Tuxem, tim skoro nepouzivanym OS, tak kouknu do logu, dam googlit a casto to mam opravene za par minut. S Widlema je to loterie, cast veci lze opravit, cast je feature a zmenit nejde a vetsinu neresi, pokud se to opravi reinstallem. Tu vyspelost Widli 10 vidim u jednoho clena rodiny. Ma mid-end herni PC a proces explorer se mu obcas (zhruba kazdych par hodin) dostane do stavu, kdy vytezuje naplno procesor. Nepomuze zabiti, pouze restart. Zkouselo se bambilion ruznych mouder z for a nic nefunguje, asi take skonci u reinstallu.

170

Odkladiště / Re:Vlastní operační systém.

« kdy: 04. 01. 2017, 10:30:26 »

Mozna ten jeho cas je drahy, ale pokud mu M$ machri neopravi nejaky vzacny bug ve Widlich, tak jeho hodina prace muze mit hodnotu 0 nebo tisice Kc a stejne s tim nic neudela. V Linuxu pokud clovek narazi na neco problematickeho, tak se poreje v konfigu, zkusi alternativy nebo si to sam zaplatuje. Vetsinou nic z toho nelze v Mrkvosvete realizovat.

Ten pristup reseni problemu ve Widlich je hrozny, na vsechno je odpoved "preinstaluj Widle". Je to smutne, ale v MS svete je to opravdu nejefektivnejsi moznost.

171

Vývoj / Re:Scala vs. Java 8.

« kdy: 29. 12. 2016, 07:02:22 »

...
Takže sečítat Nothink s číslem je v pořádku, ale řetězec obsahující číslo s číslem už ne?

Nothing se nikde s cislem nesecita . Operator "<-" (prepise se na operaci bind) to z Maybe monady "vybali" a scita se cislo s cislem.

172

Vývoj / Re:Scala vs. Java 8.

« kdy: 28. 12. 2016, 11:15:52 »

K tomu vyjadreni position i velocity jako vector - moc se mi to nelibi, uz jen proto, ze pak je validni priradit postion do velocity. Navic v tom mem projektu (ktery neni modelovani realneho sveta), je dost mozne, ze dospeju do stavu, kdy position bude nad celymi cisly, ale velocity ne. Pripadne position dostane dalsi field (napr. level ci dimension).

...
Ale tady byla otázka "rychle prohledat nějaký JSON, který možná obsahuje klíč user-agent" - tak kvůli tomu asi nemá smysl vyrábět nový datový typ. Jinak aeson samozřejmě podporuje automatické generování (de)serializačního kódu.

Mně ani tak nešlo o to, jak rychle dospět k nějakému cíli, ale jak pochopit Haskell jako jazyk. Samozřejmě se nechci vyhýbat Network.HTTP nebo Data.Aeson, ale třeba Lens mi už připadá jako zbytečnost navíc. Tedy zatím.

IMO pokud to myslite s FP vazne, tak se lens nevyhnete, protoze jinak musite psat a udrzovat haldy boilerplate kodu. Proto jsem se se ptal, jestli pro Javu nejaka lens knihovna existuje, protoze bez toho si FP nedovedu moc predstavit. Pro Scalu jsem priklady uvedl - obe knihovny umi i autogenerovani, takze kodu navic je minimum.

173

Vývoj / Re:Scala vs. Java 8.

« kdy: 27. 12. 2016, 18:36:23 »

Tak jsem se na to podíval - je na to makro makeFields, viz http://stackoverflow.com/questions/34617973/make-lenses-th-with-the-same-field-name-using-makeclassy. Tohle problém vyřeší a není to "bad practice"

Jj, po predchozich postech jsem to taky nasel a zacal na to prechazet. Je to lepsi, nez tuna qualified importu a neprehledny zapis kompozice lens, ale zase takova vyhra to taky neni. Je treba skarede pojmenovavat fieldy recordu (prefixovat jmenem recordu), takze kdyz se to vytvari pres record syntax, tak je to pekne ukecane (co teprv, kdyz se jmeno recordu sklada z nekolika slov, fuj). Dalsi nevyhoda je, ze si to samo nehlida, zda uz to v projektu danou type classu nevytvorilo, kontroluje se jen aktualni soubor, takze pak dochazi k takovym podivnostem, jakoze musim importovat do modulu s velocity modul s position, prestoze z nej nic "viditelne" nepouzivam, protoze oba pouzivaji stejny field a jinak se vytvori type class dvakrat a samozrejmne to umre. Stale mi to pripada spise jako hack, ale je to rozhodne pouzitelnejsi, protoze lens pouzivam casteji nez vytvareni noveho zaznamu.

174

Vývoj / Re:Scala vs. Java 8.

« kdy: 25. 12. 2016, 07:45:50 »

Wow, dik za tip, to vypada dost dobre. Se moc v Java knihovnach neorientuju (uz vubec ne v tech, co maji stejnou funkcionalitu jako Scala), ale obe knihovny vypadaji solidne. Pokud nekdy budu donucen delat v Jave, tak alespon vim, po cem sahnout .

175

Vývoj / Re:Scala vs. Java 8.

« kdy: 25. 12. 2016, 07:07:25 »

Ale to pak budu ten samy problem s "x" resit v modulu OrbState (je tam "position" a "velocity", oboje maji fieldy "x" a "y"). Navic si takhle budu muset rucne vyrabet getter funkce pro kazdy vnoreny field kazdeho record co OrbState obsahuje? A co pak setter funkce? To uz jsme jak v Jave... K tomu jsou ty lenses, aby se to nemuselo psat rucne. I kdybych pouzil "velocityX" reseni a smiril se s rucnim psanim vsech kombinaci getteru a setteru, tak ani to neni moc slavne reseni, protoze to predpoklada, ze vsude, kde budu pouzivat ten OrbState, tak nebude nic mit jedinny field stejny jako v OrbState (napr. Velocity), protoze pak by jmeno rucne vytvoreneho getteru (napr. "velocityX") samozrejmne kolidovalo s getterem toho druheho zaznamu pro jeho x ve velocity...

Ta ^. je jeden operator (getter), jmeno promenne je orb. To "Orb.velocity . Vel.x" znaci skladani lens, tj. z "OrbState" se zamer na "velocity" field a v nem na "x" field.

Jeste to zkusim pogooglit, jestli neco nenajdu. Posledne kdyz jsem to resil, tak jsem akorat nasel reseni prefixovat si vsechny fieldy jmenem recordu, coz me prijde hnusne a v podstate stejne, jako druhe reseni, tj. qualified importy. Bych prisahal, ze jsem nekde videl nejake reseni, ktere me ale dost desilo, protoze zapinalo dost lang. features a ja se v nich zatim nevyznam a nektere mohou vest k celkem velkym problemum (zmeni se semantika a/nebo syntaxe jazyka).

176

Vývoj / Re:Scala vs. Java 8.

« kdy: 24. 12. 2016, 21:43:27 »

Omlouvam se za predchozi off-topic, ted se pokusim o neco vice on-topic.

Funkcionální programování - nevím jestli s příchodem Javy 8 a třídy java.util.Stream to je ještě nějaká výhoda oproti Javě.

Ok, tak napr.: Ma Java nejakou lens knihovnu pro immutable typy? Scala ma treba Monocle (mnoho funkcionality, nejen lenses, ale take narocnejsi na nauceni se) nebo QuickLens (jednoduche, primocare, funkcni).

Immutable typy - taky věc, co se dá udělat i v Javě, prostě budu mít jen konstruktory a žádné metody na modifikaci.

Jiste, "da" se udelat, asi jako OOP v C, nebo garbage collector pro ASM...

A jak budete resit treba takovou prkotinu jako vytvareni noveho objektu se zmenenym jednim fieldem? Rucne si psat potrebne metody vracejici kopii objektu se zmenou? Ve Scale to za vas udela prekladac copy metodou, kterou navic muzete "zmenit" v kopii vice fieldu. Nebo pouzivat Lombok? Ktery ma nevyhody, jako napr. ze IDE s nim muze mit problemy, nebo ze i pres znacne usnadneni tam stale je boiler-plate (co jsem se dival, tak pro to kopirovani dve volani metody navic).

Actor model - po vzoru Erlangu lze mít objekty, které čekají na zprávy a ty potom zpracovávají. Tipuju, že to bude implementované teda nějak tak,
že po spuštění aplikace napsané ve Scale tam bude několik vláken, které budou sloužit pro zpracovávání zpráv z front jednotlivých Actorů.
Tohle by mělo být normálně možné udělat i v Javě, není to jakoby  vlastnost, které v Javě nelze docílit.

<Copy&paste prvni odstavec odpovedi k predchozimu bodu.>

Kód: [Vybrat]

    public static class Greeter extends UntypedActor {
        String greeting = "";

        public void onReceive(Object message) {
            if (message instanceof WhoToGreet)
                greeting = "hello, " + ((WhoToGreet) message).who;

            else if (message instanceof Greet)
                // Send the current greeting back to the sender
                getSender().tell(new Greeting(greeting), getSelf());

            else unhandled(message);
        }
    }

Kód: [Vybrat]

class Greeter extends Actor {
  var greeting = ""

  def receive = {
    case WhoToGreet(who) => greeting = s"hello, $who"
    case Greet           => sender ! Greeting(greeting) // Send the current greeting back to the sender
  }
}

To vam fakt ta Javi verze prijde hezci a lepe citelna? Me rozhodne ne.

Klíčové slovo val, kdy pak není možné měnit proměnnou - Java má final

val ve Scale je vychozi a kratke, naopak pokud mame neco jako "Int final a = 4;" tak to final je navic a tudiz vychozi stav je mutable, coz znaci, ze FP je v jazyku neco navic => neni pro FP prizpusoben.

Akademická syntaxe - ta syntaxe je prostě taková, aby to nevypadalo jako Java

Ciste subjektivni. Cilem naopak bylo, aby to bylo hodne podobne Jave, coz pri nepouzivani FP a jen OOP celkem funguje (syntaxe je v tom pripade pomalu 1:1). Jako jestli mate problem s tim, ze genercike typy maji parametry v [] misto <>, nevim, pripada mi to jako prkotina. Nepovinne stredniky mi prijde velmi sympaticke v kazdem jazyce. Rozdily na teto nejnizsi urovni jsou opravdu velmi male.

Nechci, aby to vypadalo jako nějaký hejt Scaly

Tak to presne pusobi - vetsina bodu akorat znaci uplnou problematiky a/nebo Scaly.

, ale opravdu by mě zajímalo, proč bych to měl chtít na něco použít místo Javy, když bych si musel zvykat na tu syntaxi.

To zni jako nejake narky studentika, vzdyt ta zakladni syntaxe je, jak jsem psal, pomalu 1:1 mapovani na Javu. Vetsina (vse?) je akorat kratsi, je mene zavorek, slozenych zavorek, stredniku a dalsi nevyznamove omacky. Jiste, pokud mluvite o implicits, path-depedent typech a dalsi magie s typy, tak tam se to bude lisit, protoze Java nic takoveho nema .

Samozřejmě můžu dát pročítat články na netu, ale nějaká diskuze nemusí být od věci .

Doporucil bych si nejdrive precist o zakladech FP, protoze z vaseho prispevku je patrne, ze vam zalostne chybi (ne, pouzivani funkcni/metod nutne neznamena FP pristup). Take bych rad poznamenal, ze FP ve Scale bez dalsich knihoven je myslim spise zakladni (tvurce to zamyslel pro bezne vyvojare, nechtel z toho mit dalsi Haskell). Pokud chcete videt poradne FP, tak se podivejte na ScalaZ .

177

Vývoj / Re:Scala vs. Java 8.

« kdy: 24. 12. 2016, 20:40:12 »

Kód: [Vybrat]

oldVelX = orb^.Orb.velocity.Vel.x

Haskell se teprve učím, ale měl jsem spíš takovou představu:

Kód: [Vybrat]

oldVelX = orb^.Vel.x

Pleonasmy při programování totiž moc rád nemám a vyhýbám se jim, jak jen to jde.

Otázkou samozřejmě je, zda by to v této podobě fungovalo. Proč oldVelX není součástí modulu Vel? Pak by to bylo jen

Kód: [Vybrat]

oldX = x

Ehm, asi nechapu. Ten zapis nelze zjednodusit (ne bez upravy importu, pripadne modulu s recordy), "Orb.velocity" je lens pro field "velocity" v "OrbState" record a "Vel.x" je lens pro field "x" ve "Velocity" record. Vzhledem k tomu, ze mam vice zaznamu, kde se vyskytuje field "x" (v mem pripade to "x" je lens, ale to je celkem jedno, ikdybych nepouzil lens tak chci "getter" a ten se bude jmenovat stejne), tak nemohu importovat vse z "Velocity" modulu, protoze bych dostal i "x :: Velocity -> Int" a to by kolidovalo s jinou fkci pro ziskani "x" z jineho zaznamu, napr. "x :: FilePos -> Int".

Mozna bych to mohl vysperkovat pouzitim mezer, ale porad je to IMO tezkopadne a hure prehledne.
Verze se zduraznenim, co je get operace a kompozice a co je namespace (ty jsou bez mezer).

Kód: [Vybrat]

oldVelX = orb ^. Orb.velocity . Vel.x

"oldVelX" se pouziva pri vypoctu zmeny stavu interpretu (neni to top level funkce) a tak mi prislo vhodnejsi umistit fci vedle ostatnich funkci interpretu, ktere se take zabyvaji zmenou stavu. A stejne to neresi problem, pokud se v "OrbState" pouziva dalsi zaznam, ktery ma field "x" (nebo jiny kolidujici), akorat jsem problem presunul jinam - z vyssi vrsty do nizsi vrstvy - do modulu s "OrbState" funkcemi.

Mozna se vyjadruju blbe. Jak pisu, taky se to ucim .

PS: Tady jsou ty importy:

Kód: [Vybrat]

import           Runtime.Data.OrbState              -- pouze typ, aby se nemuselo psat OrbState.OrbState
import qualified Runtime.OrbState            as Orb -- pomocne veci. qualified proto, aby napr. fce "position" nekolidovala s jinou fci pojmenovanou "position"

178

Vývoj / Re:Scala vs. Java 8.

« kdy: 24. 12. 2016, 19:22:52 »

Co se tyce knihoven, tak celkem dost jich lze ve Scale pouzivat normalne jak z Javy. Na ty bezne veci jsou casto knihovny primo pro Scalu, se kterymi se ze Scaly pracuje prijemneji (napr. zadne null, Scali kolekce, DSL atp.). Co jsem se dival a zkousel (a cetl, osobne nevyvijim ve Scale pro penize), tak treba webove veci s Play si lidi pochvalovali, podobne treba DB pristup se Slick, vetsina i Akku. Kdo chce vice hardcore FP tam ten muze sahnout po ScalaZ, Cats, Shapeless atp. Ale nejak do hloubky to zhodnotit nedokazu, pouze muzu rict, ze jsem zatim na to domaci vyvijeni* nenarazil na pripad, ze by Java knihovnu mela a Scala ne (at uz nativni, nebo stejnou Javi, ikdyz ty byvaji celkem otravne na pouzivani, kdyz jste zvykli na lepsi).

*: Normalni veci typu web crawler, multiplatformni GUI klikatko, pristup k souborum, JSON, Android (predevsim libGDX), jednoducha server-client aplikace.

Jak jsem psal vyse, pokud najimate hloupe nebo line vyvojare, nebo je nechcete zaucovat do lepsiho jazyka, ktery v zaveru poskytne nepreberne vyhod (vyssi abstrakce = mene kodu, lepsi citelnost, znovupouzitelnost), tak IMO najimate jen "lopaty" a casem se vam to vymsti. Podobne tragicky to vidim, kdyz se nesmi psat testy (o to horsi, pokud jde o dynamicke jazyky). Ano, muzete prejit na Go a najmout prvni skupinu mladych uchazecu, kteri v tom umi napsat Hello world, ale podle toho pak budou vypadat vase aplikace. Prasit se da ve vsem. Treba nedavno jsem videl kod na zjisteni kolize bodu vuci trojuhelniku v 2D v celych cislech, bylo to tusim v Jave a bylo to resene cykly pres vsechny body trojuhelniku...

Si hraju s prekladacem a intepretem jazyka v Haskellu a treba records jsou dost za trest - Haskell nepodporuje (primo) pretezovani funkci, takze v jednom namespacu zadny record (neco jako struct nebo case class) nesmi mit stejne pojmenovane fieldy, protoze pak koliduji jmena getteru (pripadne jmena lens). (Ano, vim, jde pouzit type classy, ale co jsem cetl, tak je to bad practice. Pouzivam kombinaci importu a qualified importu a kvuli tomu pribylo dost boiler platu a navic s kazdym novym record se musi upravovat build file

Recordy v haskellu jsou takové, jaké jsou, protože nikdo neví, jak to udělat líp

Co takhle je umístit do různých namespace?

No, to ted pouzivam, ale neni to zadna slava:

Pouzivam kombinaci importu a qualified importu a kvuli tomu pribylo dost boiler platu a navic s kazdym novym record se musi upravovat build file

Jsem tak trochu rozmazleny z Java sveta (ve Scale je to stejne), ze pridam soubor a on se sam prida do buildu. Kdyz se pak pracuje s lens (nebo i jen temi "getter" funkcemi), tak se musi pouzivat qualified import na ne a je otravne a IMO celkem neprehledne.

Priklad jak to mam nyni (Orb a Vel jsou qualified imports, IMO to celkem kazi retezeni lens, ktere mohlo byt krasne intuitivni - nyni je tecka oddelovac importu i kompozice funkci):

Kód: [Vybrat]

oldVelX = orb^.Orb.velocity.Vel.x

A jak by to mohlo vypadat, kdyby Haskell umel pretezovani funkci (to by pak ty recordy byly i normalne pouzitelne):

Kód: [Vybrat]

oldVelX = orb^.velocity.x

Pouzivat type classy k tomuto ucelu mi prijde dost neprakticke (navic ani nevim, zda to vyresi problemy s kolizemi jmen auto-generovanych lens, tipl bych, ze spis nevyresi) a jak jsem psal, na vice mistech jsem cetl, ze pouzivat je vylozene k pretezovani funkci je bad practice, tak nevim...

Jako mozna neco delam a/nebo chapu spatne, jsem vecny Haskell zacatecnik, ktery se v tom pro zabavu placa .

179

Vývoj / Re:Scala vs. Java 8.

« kdy: 24. 12. 2016, 11:15:58 »

Prasata mate vsude, to neni nejaka nevyhoda jazyka. I v tom hloupouckem a omezenm Go se prasi pomoci reflexe, aby se prekonaly omezeni jazyka. Ja budu mit radeji jazyk, kde mam vetsi volnost a nemusim prasit z duvodu, ze to jinak nejde.

Jste si asi neprecetl vyse, co vsechno Java 8 pro rozumne praktikovani FP postrada. Jiste, pokud nechcete FP, vice ficur, expresivnejsi jazyk, lepsi typovy system, tak Scala moc neprinese, ale to jste v prve rade Scalu ani nemusel zvazovat, kdyz vam vyhovuje uzvanena Java se svymi omezenimi (o tom snad tento topic neni).

Ano, ve vetsine benchmarku je Scala o neco malo pomalejsi (nic dramatickeho), ale to se da cekat. Musim (spise pro pobaveni) ale rict, ze existuji i benchmarky, kdy je Scala rychlejsi nez Java (tusim, kdyz se benchmark lepe strefi do datovych struktur a optimalizaci prekladace Scaly).

180

Vývoj / Re:Scala vs. Java 8.

« kdy: 24. 12. 2016, 10:55:07 »

Jiste, kolekce ve Scale nejsou dokonale (ostatne typovy system zaplatil cenu za snahu byt nejak kompatibilni s Javou a nutnosti behu na JVM), ale co do pouzitelnost jsem opravdu nenasel lepsi. Rozsirovat nejakou Scala kolekci neni take uplne primocare a bez znalosti implementacnich detailu celkem obtizne (ano, i to jsem si zkusil ). K tomu vykonu - nepouzivaji se v pripade opravdove starosti o vykon spise specializovane knihovny?

Jeste jsem zapomnel na to, ze v Jave jsou lambdy, kdezto ve Scale closure (doufam, ze jsem to neprohodil). V Jave se v lambde nemuzete odkazovat na vnejsi promennou (myslim funguje pouze pro final, nebo takove podobne omezeni), ve Scale to neni problem (podobne jako v JavaScriptu).

Moc jsem Go ani Kotlin nestudoval, ale neprisly mi nicim moc vyjimecne. Prinasi neco navic oproti treba te Scale? Jedinne o cem v Kotlinu vim, co vypada dobre, je podpora proxy primo v jazyce (potreboval jsem to nekolikrat pri praci s Javovskymi tridami, ktere jsem nemohl upravovat). Go vypada jako tuctovy jazyk, podle slov jejich vyvojaru zamereny na rychle nauceni se, coz moc jako kvalitu nevnivam. Proc mit dalsi Python (nebo cokoliv jineho), kdyz nauceni se jazyka mi potrva zlomek casu (treba tyden/mesic), nez samotna prace v jazyce (roky)?

The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.
– Rob Pike

Jazyk pro lopaty?

PS: Psani sem me donutilo si neco o Go precist a teda ten jazyk je tak neuveritelne zpatecnicky, ze se az divim, ze s tim prisel Google.
Why Go’s design is a disservice to intelligent programmers