Příspěvky

376

Vývoj / Re:CPS a bind

« kdy: 28. 04. 2017, 14:05:45 »

Ahoj, učím se FP, abych byl aspoň schopen porozumět článkům o funkcionálním přístupu, a celkem chápu třeba Maybe. Teď jsem se dočetl, že kontinuace je také monáda, ale zaboha nejsem schopen napsat pro ni bind, tedy když mám hodnotu typu (A->R)->R, abych ji mohl dát do funkce beroucí na vstupu hodnotu typu A. Jde mi o vyjádření v nějakém ne čistě funkc. jazyce.

Tak například ve Swiftu to je easy-peasy:

Kód: [Vybrat]

func contUnit<T>(_ x:T) -> ((T)->Any)->Any {
    return { $0(x) }
}

func contBind<T1,T2>(_ m:@escaping ((T1)->Any)->Any, _ f1:@escaping (T1)->((T2)->Any)->Any) -> ((T2)->Any)->Any {
    return { f2 in m{ f1($0)(f2) }}
}

377

Studium a uplatnění / Re:Dochadzkovy system - vlastny projekt

« kdy: 28. 04. 2017, 12:01:06 »

vazne? lebo napr. pre C# som nasiel nieco taketo http://playground.arduino.cc/Interfacing/Csharp, ale neviem teda, ci je to pouzitelne. Tak potom ma vacsi zmysel uvazovat nad RPi?

RPi je jednodušší na použití, je tam Linux, větší výběr jazyků a typicky i Wi-Fi nebo BT (u nových modelů včetně Zera). Pokud nevadí trochu vyšší příkon, je to schůdnější.

378

Vývoj / Re:CPS a bind

« kdy: 27. 04. 2017, 18:48:21 »

Ahoj, učím se FP, abych byl aspoň schopen porozumět článkům o funkcionálním přístupu, a celkem chápu třeba Maybe. Teď jsem se dočetl, že kontinuace je také monáda, ale zaboha nejsem schopen napsat pro ni bind, tedy když mám hodnotu typu (A->R)->R, abych ji mohl dát do funkce beroucí na vstupu hodnotu typu A. Jde mi o vyjádření v nějakém ne čistě funkc. jazyce.

bind(m,f)=λg.m(λx.f(x)(g))

379

Vývoj / Re:Node.js a multiplexed IO obecně

« kdy: 27. 04. 2017, 14:12:12 »

Chci-li vlastnosti ekvivalence, tak nebudu ignorant a použiji ===. 

Jasný. A pokud chci testovat objekt na null, tak použiju !!, protože všude jinde normální if (object) taky nefunguje.

A pokud chci ... tak musím ... . Ale je potřeba vědět, že ... a ... . Pochopitelně jenom v případě že ... . Což ví všichni, kdo nejsou ignoranti.

Fakt je to tak těžký, přiznat si "jo, je to dost zmršenej jazyk, ale i tak ho mám rád"? Co je na tom špatnýho, vyloučili by tě ze sekty?

Třeba mě se JS mimořádně nelíbí, definici relace == považuju za pitomou, rozhodnutí pojmenovat normální ekvivalenci === taky za pitomý, ale tak prostě se tak v JS rozhodli, a nedává mi moc smysl nadávat že == se nechová jako ekvivalence, když ekvivalence se v JS jmenuje ===.

Tak nějak, nemá smysl to řešit, stejně jako proč v asm po cmp %rax, %rbx pak jl skočí, když rbx<rax.

380

Studium a uplatnění / Re:Jsem javista a nechci pořád vyvíjet pro banky a korporace!

« kdy: 27. 04. 2017, 13:09:13 »

Krom absence VM má Go GC, jehož efektivity Java z principu nikdy nedosáhne, to je hlavní přednost Go. C++ se v podstatě hodí na to samé, co Go, dosahuje stejné efektivnosti, ale ve většině případů bude kód složitější a nepřehlednější. Java je prostě jen relikt.

Proc na Go GC Java *nikdy* nedosahne?

Je to způsobem implementace GC a správy paměti obecně. V některých případech musí Java dealokovat řádově více objektů, kde je v případě Go jen jeden velký objekt (jenž navíc ani nemusí být na haldě, ale předpokládejme, že je). Poměrně srozumitelně to je vysvětlené přímo v interní dokumentaci k runtimu.

381

Studium a uplatnění / Re:Studium mimo IT

« kdy: 27. 04. 2017, 11:01:17 »

Znovu, jako malým dětem, opakuji, že tazatel se ptá po dalším studiu v jiném oboru, protože se CHCE NAUČIT NĚCO V NOVÉM/JINÉM OBORU. Celá PhD část diskuze je tudíž zcela jalová. Já přiznávám svůj díl viny na tom, že tady ta jalová diskuze je, ale já jsem ten, kdo říká, že jdete špatně a kdo se snaží poukazovat na původní zadání.
Teoretizování je přesně tvůj přístup, kdy píšeš obecné, teoreticky platné věci, které ale nezapadají do reality zadání od původního tazatele.

Připojím osobní zkušenost. Vystudoval jsem PhD v oboru biomedicínská informatika. Znalosti z biologie a medicíny jsem měl jen středoškolské, Mgr v IT. Svoboda výběru předmětů byla zcela na mne, ale musel jsem mít sebekázeň a sám si vybrat kurzy nebo předměty z biologie a medicíny, které mne zajímali a zároveň byli relevantní pro projekty ostatních PhD studentů a výzkumných skupin. Docházel jsem klidně na přednášky se studenty medicíny, nebo Bc. Mgr. studia biologie. Důležité je dostat se na takovou úroveň, že rozumíš ostatním z oboru a pak ti přijmou článek v oborovém časopisu. Kolega měl třeba štěstí a dělal výpočetní systém pro nano materiály, a po několika letech mu vyšel článek v Nature, kde figuroval jako druhý autor. Já měl podobné štěstí a vyšel mi článek (opět druhý autor) v jiném oborovém časopise - ne zas tak slavný jako Nature. Když jsem měl grant, nebo jsem se přidal na nějaký projekt, měl jsem i finance na nějaké konference, po Evropě je jich habaděj. Nejdále jsem byl v Japonsku, nebo na měsíční stáži v USA.

Jediné nebezpečí, je že po studiu skončíš jako vysoce kvalifikovaný - někdy se též říká překvalifikovaný, v česku se po tobě mohou dívat trochu podezřele po aférách s rychlodoktoráty některých potentátů. Ale buď narazíš na firmu v oboru, do které zapadneš, nebo pokračuješ ve vědecké dráze - na západě jsou platy v akademické sféře tak o 10-30% menší než v komerční, u nás je věda podfinancována a celkově s horším řízením - ale vyjímky existují a časy se lepší.

Zajímavé. Z jaké školy je to PhD?

382

Vývoj / Re:Node.js a multiplexed IO obecně

« kdy: 27. 04. 2017, 10:33:39 »

Člověk musí být hodně mimo, aby podporoval svoje argumenty nefunkčním a neuvěřitelně debilním kódem, zvlášť když existuje playground. Fakt diskuse na úrovni.

napiš lepší.

Napiš si to sám, jsou to 3 řádky kódu. Když se to tentokrát aspoň přeloží, můžu ti pak říct, jestli to je dobrý kód nebo kravina.

383

Vývoj / Re:Node.js a multiplexed IO obecně

« kdy: 27. 04. 2017, 10:18:57 »

obecné generátory se bez yield píší špatně, ale to lze považovat také za syntaktický cukr.

Píší se bez yield naprosto v pohodě, pokud mám k dispozici channely, které fungují prakticky stejně jako yield. Navíc oproti yield se práce s channelem dá snadněji paralelizovat. Pokud bych si měl vybrat mezi yield a channelem, určitě bych volil channel.

Paralelní generátory jsou IMHO nanic. Jdou psát i v pythonu.

Tento generáror

Kód: [Vybrat]

 func generateRandomNumbers (n int) {
    ch := make (chan float)
    sem := make (semaphore, n)

    for i := 0; i < n; i++ {
        go func () {
            ch <- rand.Float()
            close(ch)
        } ()
    }

    // launch extra goroutine to eventually close ch
    go func () {
        sem.Wait(n)
        close(ch)
    }
   
    return ch
}

Kterej osel to psal? Ani se to nepřeloží, a i kdyby, je to plné sémantických chyb.

http://www.golangpatterns.info/concurrency/generators

Člověk musí být hodně mimo, aby podporoval svoje argumenty nefunkčním a neuvěřitelně debilním kódem, zvlášť když existuje playground. Fakt diskuse na úrovni.

384

Vývoj / Re:Node.js a multiplexed IO obecně

« kdy: 27. 04. 2017, 10:09:21 »

obecné generátory se bez yield píší špatně, ale to lze považovat také za syntaktický cukr.

Píší se bez yield naprosto v pohodě, pokud mám k dispozici channely, které fungují prakticky stejně jako yield. Navíc oproti yield se práce s channelem dá snadněji paralelizovat. Pokud bych si měl vybrat mezi yield a channelem, určitě bych volil channel.

Paralelní generátory jsou IMHO nanic. Jdou psát i v pythonu.

Tento generáror

Kód: [Vybrat]

 func generateRandomNumbers (n int) {
    ch := make (chan float)
    sem := make (semaphore, n)

    for i := 0; i < n; i++ {
        go func () {
            ch <- rand.Float()
            close(ch)
        } ()
    }

    // launch extra goroutine to eventually close ch
    go func () {
        sem.Wait(n)
        close(ch)
    }
   
    return ch
}

Kterej osel to psal? Ani se to nepřeloží, a i kdyby, je to plné sémantických chyb.

385

Vývoj / Re:C++ naco jsou hlavičkové soubory když budu psát OOP?

« kdy: 27. 04. 2017, 09:00:27 »

c++11 je pomerne kompletni a da se v nem psat velmi rychle. driv vadila ona nekompletnost pro jednoduche veci, casto nahrazovana boostem a jinymi knihovnami, dnes je to nejen vykonny jazyk ale pise se v nem kod uplne stejne rychle jak v vyssich jazycich. bezne pisu multithread skoro kazdou blbinu, protoze tam neni prakticky zadna rezie navic, pokud timto zpusobem jste zvykli i premyslet

V C++11 ještě pár věcí chybělo, řekl bych, že uspokojivého stavu dosáhlo C++14. A teď je za dveřmi C++17.

386

Vývoj / Re:Node.js a multiplexed IO obecně

« kdy: 27. 04. 2017, 08:46:44 »

Kód: [Vybrat]

g = (i*i for i in range(100))

- fakt, že v Go se takhle jednoduchý generátor nedá (?) napsat stručně [...]

On Go nezná, jen se hádá z principu.

Je toto dostatečně jednoduché?

Kód: [Vybrat]

g := gen(0, 100, func(i int) int { return i * i })

387

Vývoj / Re:C++ naco jsou hlavičkové soubory když budu psát OOP?

« kdy: 27. 04. 2017, 02:27:27 »

no nevim, pohybuju se kolem grafiky a tam naopak neexistuje prakticky jiny jazyk nez c++. jeho zastoupeni tipuju na 99%.

nemyslim ze z soucasnych jazyku se da poskladat alternativa, a kdyz za 2 roky vznikne, tak stejne v produkcni kvalite bude tak za 10 let. hlavne ani nevidim zadne tendence a uvahy o tom ze existuje i neco jineho nez c++, teda krome kousku cuda,opencl,hlsl,glsl kde se vyuzije zpetna kompatibilita s c.
osobne v c++ napisu rychleji i jednorazovky na urovni shellovych scriptu, urcite to neni ani pomaly jazyk na prototypovani....

To je o zvyku a zkušenostech, někdo v C++ během chvilky napíše kdeco, jiný (pseudoprogramátor à la Javista) si vytrhá všechny vlasy nad první třídou.

Pry pseudoprgramator ala Java, a kdyz se v C++ musis stvat se zavislostma protoze nemate nic jako je Maven, musíš vyplňovat stohy zbytečných .h hlaviček a stohy dalších věcí, o nichž se vsadím, že v tomto tématu byla řečena pouze malá část, tak to si potom teprve budeš připadat jako ten pravý programátor? A jak se cítíš, když ti přijde výplatní páska a na ní máš míň než tvůj ekvivalent pracující v Javě - nejsi potom tak trošku z toho zamindrákovaný, že tu svou efektivitu práce vidíš i na výplatě? No to se ale nesmiš divit, uklízečce taky nikdo nezaplatí víc, když bude pečlivě čistit záchody zubním kartáčkem.

Necítím se nijak, mám svou firmu (za mořem), kde se dělá v Javě i C++.

388

Vývoj / Re:C++ naco jsou hlavičkové soubory když budu psát OOP?

« kdy: 27. 04. 2017, 01:24:58 »

no nevim, pohybuju se kolem grafiky a tam naopak neexistuje prakticky jiny jazyk nez c++. jeho zastoupeni tipuju na 99%.

nemyslim ze z soucasnych jazyku se da poskladat alternativa, a kdyz za 2 roky vznikne, tak stejne v produkcni kvalite bude tak za 10 let. hlavne ani nevidim zadne tendence a uvahy o tom ze existuje i neco jineho nez c++, teda krome kousku cuda,opencl,hlsl,glsl kde se vyuzije zpetna kompatibilita s c.
osobne v c++ napisu rychleji i jednorazovky na urovni shellovych scriptu, urcite to neni ani pomaly jazyk na prototypovani....

To je o zvyku a zkušenostech, někdo v C++ během chvilky napíše kdeco, jiný (pseudoprogramátor à la Javista) si vytrhá všechny vlasy nad první třídou.

389

Vývoj / Re:Node.js a multiplexed IO obecně

« kdy: 27. 04. 2017, 01:07:26 »

Ahhhh, moje chyba, myslel jsem, ze komunikuji pres sockety.

"posilaj si mezi sebou async zpravy" samo o sobe nerika nic. Muze to byt paradni vec jako v Erlangu a muze to byt zoufalost jako radobyparalelismus v Rku nebo v pythonnim multiprocessing, ktery jenom zoufale obchazi GIL.

However, in the case of multi-threaded implementations, many browsers implement a structured cloning algorithm to copy the message into the receiving thread’s context
JS runtime musi predavane objekty serializovat a deserializovat. Je s tym spojeny overhead a nedokaze passnut referenciu na priamo.

Takže to je efektivně nepoužitelné...

390

Vývoj / Re:Node.js a multiplexed IO obecně

« kdy: 27. 04. 2017, 00:33:33 »

Jde to snadněji pomocí uzávěru. Ale pořád je to horší než first class generátory.

...a generatory jsou o rad horsi nez kontinuace.

Kontinuace je univerzálnější, ale taky abstraktnější (a někdy to je dost zmatek, stačí zkusit si pro kontinuaci napsat >>=). Nejlépe se tento typ kódu píše v CSP, je to triviální a univerzální.

CSP alebo CPS? Nemysleli ste CPS? Poviem vam, ze uz dost dlhu chvilu rozmyslam, ci ste naozaj nemysleli CSP (spominali sa tu kanaly a Go).

Myslel jsem CSP. CPS mi v tomto případě nepřijde úplně ideální.