Funkcionální programování ve Scale 1.

13. 4. 2015 | Redakce | Návody | 11133×

Knihovna scalaz-stream slouží ke zpracování proudů dat v programovacím jazyce Scala. V úvodním článku si řekneme, co to proud dat je, kde se proudy dat vyskytují a jak je knihovna scalaz-stream užitečná při jejich zpracování.

Scalaz-stream 1: Začínáme

Proud dat je posloupnost dat, kde data přicházejí postupně a může jich být i nekonečně mnoho. Příkladem proudu dat je proud řádků ze souboru nebo proud z databáze s výsledky dotazu. Skládá-li se aplikace z komponent, jenž komunikují zasíláním zpráv, máme proudy zpráv mezi komponentami.

To všechno jsou příklady proudů, s kterými knihovna scalaz-stream může manipulovat. Nicméně čtení ze souborů řeší BufferedReader, chceme-li mít aplikaci složenou z komponent, jenž si posílají zprávy, můžeme použít aktory z knihovny Akka. Proč tedy používat knihovnu scalaz-stream?

• Jednotnost. S různými proudy lze pracovat stejným způsobem. Nezáleží na tom, zda je proud synchronní nebo asynchronní, zda je konečný nebo nekonečný, zda přichází ze souboru, z databáze nebo z fronty zpráv. Jednotnost zvyšuje znovupoužitelnost kódu.
• Automatická správa zdrojů. Některé proudy bývají spojeny se vzácným zdrojem – např. otevřeným souborem nebo spojením do databáze. Knihovna scalaz-stream se automaticky postará o otevření a včasné uzavření zdroje. Díky tomu chyby, kdy čteme z neotevřeného zdroje nebo zdroj neuzavřeme, nemohou nastat.
• Množství kombinátorů. Knihovna scalaz-stream obsahuje řadu funkcí, pomocí nichž je možné proudy transformovat a kombinovat.

Nyní si knihovnu scalaz-stream předvedeme na jednoduchém příkladu. Poté se podíváme na srovnání knihovny scalaz-stream s jinými knihovnami pro zpracování proudů dat.

Příklad: Čtení řádků ze souboru

Začneme programem, který vypíše řádky souboru na standardní výstup:

io.linesR("countries.txt")
  .to(io.stdOutLines)
  .run.run

Výraz io.linesR("countries.txt") reprezentuje proud řádků ze souboru countries.txt. Metodou to pošleme obsah proudu na standardní výstup. Výraz io.linesR("countries.txt").to(io.stdOutLines) je popis toho, co se má stát. Aby se to stalo, musíme popis spustit, což se provede dvojím voláním run.

Některé funkce známé z kolekcí lze aplikovat i na proudy (např. filter, map, collect, zip, take, ++, …). Následující kód vypíše hlavní město České republiky (jsou-li v souboru capitals.txt právě hlavní města zemí ze souboru countries.txt a to navíc ve stejném pořadí):

io.linesR("countries.txt")
  .zip(io.linesR("capitals.txt"))
  .collect { case ("Czech republic", capital) => capital }
  .once
  .to(io.stdOutLines)
  .run.run

zip udělá z proudu zemí a proudu hlavních měst jeden proud, jenž obsahuje dvojice (země, hlavní město). collect dostane proud vytvořený funkcí zip a napřed z něj vyfiltruje dvojice tvaru ("Czech republic", capital), z nichž poté vybere hlavní města. once je zkratka za take(1) – z proudu vezme první prvek.

Ekvivalentní kód v Javě vypadá následovně:

try (
  BufferedReader countries = new BufferedReader(new FileReader("countries.txt"));
  BufferedReader capitals = new BufferedReader(new FileReader("capitals.txt"))
) {
  String country, capital;
  while ((country = countries.readLine()) != null && (capital = capitals.readLine()) != null) {
    if (country.equals("Czech republic")) {
      System.out.println(capital);
      break;
    }
  }
}

Srovnání s dalšími knihovnami pro zpracování proudů

Pojďme se podívat, čím se knihovny pro zpracování proudů liší:

• Možnosti. Jak moc nás knihovna omezuje?
• Jednoduchost. Jak těžké je naučit se knihovnu používat?
• Automatická správa zdrojů. Musí se o uzavírání zdrojů starat uživatel knihovny?
• Časová složitost. Jaká je časová složitost operací s proudy?
• Rozšířenost. Kolik má knihovna uživatelů?

Iterátory (synchronní kolekce) a reactive extensions (asynchronní kolekce)

V Javě i jiných programovacích jazycích můžeme pracovat s proudy dat pomocí iterátorů. Na rozdíl od knihovny scalaz-stream se iterátory nepostarají o uzavírání zdrojů, to zůstane stále na programátorovi. Další nevýhodou iterátorů je, že nepodporují asynchronní proudy – například při čekání na výsledky z databáze zablokuje iterátor vlákno, v němž běží.

Iterátory mají rozhraní Iterable. Knihovny z rodiny reactive extensions přináší duální rozhraní Observable, které slouží pro asynchronní proudy. Bohužel ani Observable se nepostará o uvolňování zdrojů. Navíc oddělením synchronních proudů od asynchronních proudů vzniká problém se znovupoužitelností kódu – kód napsaný pro rozhraní Iterable nebude fungovat s rozhraním Observable a naopak.

Kromě toho mají obě rozhraní problém s časovou složitostí některých operací. Například časová složitost zřetězení proudů bude záležet na uzávorkování: zřetězení uzávorkované doleva (tj. (a ++ b) ++ c) bude mít kvadratickou časovou složitost a zřetězení uzávorkované doprava (tj. a ++ (b ++ c)) bude mít lineární časovou složitost. S knihovnou scalaz-stream na uzávorkování nezáleží, zřetězení má vždy lineární časovou složitost.

Knihovny založené na principu inversion of control

Jak vyřešit problém s uvolňováním zdrojů? Jednoduše, nedat uživateli možnost zdroje alokovat ani uvolňovat. Příkladem je funkce

def eachLine(path: String, f: String => Unit): Unit

jenž otevře soubor path, pro každý jeho řádek zavolá funkci f a poté soubor zavře. Tato funkce řeší problém s uvolňováním zdrojů. Cenou za to je ztráta kontroly – například není možné načítání řádků předčasně zastavit, vždy budou načteny všechny řádky souboru.

Principu, na němž je funkce eachLine založena, se říká inversion of control. Na tomto principu funguje i knihovna scalaz-stream a celá řada dalších knihoven pro zpracování proudů s automatickou správou zdrojů. Srovnání těchto knihoven lze najít v prezentaci o knihovně Machines, přičemž knihovnu scalaz-stream lze považovat za vylepšené Machines.

Závěr

V tomto článku jsme se podívali, co knihovna scalaz-stream nabízí. Příště se naučíme používat základní kombinátory z knihovny scalaz-stream.

       

Komentáře

[my sme piestany]

daju sa v tej scale robit aj normalne exace? abo len jarka?

[aubi]

Exace se daji delat jenom z asm nebo c/c++. Vsechny novejsi jazyky pouzivaji runtime - Java, c#, nodejs. Uz VB bez runtime nebezel, dtto Lisp, Prolog... A jestli tomu dobre rozumim, tak runtime pri c je libc, jen je nastesti v systemu

Scala patri do rodiny jazyku postavenych nad Java virtual machine.

[Radek Miček]

Vsechny novejsi jazyky pouzivaji runtime

Naštěstí to tak není.

[aubi]

Na Tvem blogu jsem nasel Python a Haskel...

Ktere jazyky se tedy kompiluji do exe bez potreby runtime?

[Bystroushaak]

Například D. Jinak i Lisp má verze, které se dají přímo kompilovat do strojáku, dokonce i subset pythonu rpython se dá kompilovat (viz taky micropython, The 3 different code emitters, The 3 different code emitters, part 2).

Jinak to že má něco interpreter ještě neznamená, že se z toho nedá udělat spustitelná binárka.

[pavel]

Z cehokoliv lze udelat exe: zabalis do toho interpretr a mezikod (.class|.pyc|.pyo apod..). Pri spusteni se to rozbali v pameti a spusti. Podobne jako fungovaly samorozbalovaci zip, ale vse se odehraje neviditelne v pameti.

[aubi]

Diky, odkazy jeste proctu podrobneji.

Myslis, ze by se z D mohl stat velky hrac velikosti Javy nebo aspon Pythonu? Mam na mysli komercni aplikace, web a serverside.

[Bystroushaak]

Myslis, ze by se z D mohl stat velky hrac velikosti Javy nebo aspon Pythonu? Mam na mysli komercni aplikace, web a serverside.

Nevím jestli stejné velikosti (to záleží hlavně na tom, jestli se ho chytne nějaká velká firma), ale stejné užitečnosti určitě ano. Psát v D je velmi podobný pocit, jako psát v pythonu - je to dobře navržené a na podobné úrovni abstrakce. Přitom je to stále "lowlevel" systémový jazyk.

Docela se mi líbí, že D si poslední dobou začínají všímat i lidi z /r/programming, viz třeba Excited About D, či The D Language: A sweet-spot between Python and C, nebo The State of D in 2015.

[Květináč]

Systémový jazyk to není !! další lež tvůrců jazyka. Sem v tom chtěl napsat primitivní kernel a VIDA? Musel bych přepsat D runtime (běhovou platformu podle mojí terminologie) aby to běželo ... takže sorry, snažší je C/C++ na low level vývoj. A D trpí také tím, že plno vlastností jazyka závisí na GC, takže není možné jen tak GC vypnout. Celkově když sem se na D koukal před asi rokem, tak mne zklamal ...

[Bystroushaak]

Taková zhrzenost :D

Musel bych přepsat D runtime (běhovou platformu podle mojí terminologie) aby to běželo ...

Přepsat bys jí nemusel, jen momentálně moc nechce fungovat bez garbage collectoru. Garbage collector je jedna z věcí, o které psal Andrei, že jí v dohledné době přepíše a celkově co jsem tak četl, tak se pracuje na odproštění phobosu od něj co to jen půjde.

A D trpí také tím, že plno vlastností jazyka závisí na GC, takže není možné jen tak GC vypnout.

Vážně, vlastností? Vím o tom že systémová knihovna na tom záleží, ale vlastnosti, to je pro mě novinka. Můžeš nějaké jmenovat?

[Květináč]

Super, takže přepsat bych runtime nemusel, ale bez GC nic neběží ... Kurva, ty si řek sračku. Víš to? Asi jo, ale prostě si jen chtěl nesouhlasit. To blbý runtime bych musel celí přepsat, od správy paměti až po definice primitivních operátorů. Proč? Protože OS je opravdu lepší psát bez GC. Ano, v historii byla Genera která běžela pod GC, jenomže procesorová architektura LISP machines ho podporovalo, takže to bylo rychlí.

A co se týče těch vlastností. Je dost možné že jsem zvolil špatné slovo. Když se koukneš hlouběji do runtime na definice primitivních operátorů, zjistíš že mnoho z nich závisí na GC.

A pozor, kdybych se přece jenom rozhodl ten OS s GC napsat, stejně bych musel to blbý runtime přepsat, protože GC z něčeho musí paměť čerpat. U OS je problém, že velká část samotného jádra (bez driverů) je tvořena managementem paměti (virtualizace, alokace). Takže by to vyžadovalo napsat v D bez GC dost kódu. A to by nešlo, kdyby bylo runtime závislí na GC. Takže se vracíme na začátek. MUSEL bych to celí přepsat. A to nemluvím o tom, že by se v případě GC muselo ještě dost srát s hledáním kořenů.

Takže závěr? Jo sem zhrzenej z D, na první pohled to byl fakt zajímavej jazyk. Sice dost přeplácanej ale to je fuk. Ještě furt má D tak pomalej GC?

A taková rada, klidně nesouhlas, ale aspoň o tom něco znej a nemel sračky. kdybys v tom něco lowlevel psal či se o to pokoušel, věděl bys že v aktuálním stavu je D absolutně napíču, pokud teda zrovna nemá člověk chuť se přepisovat s druntime.

[Bystroushaak]

To blbý runtime bych musel celí přepsat, od správy paměti až po definice primitivních operátorů. Proč? Protože OS je opravdu lepší psát bez GC. Ano, v historii byla Genera která běžela pod GC, jenomže procesorová architektura LISP machines ho podporovalo, takže to bylo rychlí.

Tady je místo, kde se hádám.

A pozor, kdybych se přece jenom rozhodl ten OS s GC napsat, stejně bych musel to blbý runtime přepsat, protože GC z něčeho musí paměť čerpat. U OS je problém, že velká část samotného jádra (bez driverů) je tvořena managementem paměti (virtualizace, alokace). Takže by to vyžadovalo napsat v D bez GC dost kódu. A to by nešlo, kdyby bylo runtime závislí na GC. Takže se vracíme na začátek. MUSEL bych to celí přepsat. A to nemluvím o tom, že by se v případě GC muselo ještě dost srát s hledáním kořenů.

Zde vedu nějaké argumenty, rozpaluji se, posílám odkazy a tak.

.. runtime bych musel celí přepsat .. takže to bylo rychlí .. runtime závislí na GC .. MUSEL bych to celí přepsat

Teď si do tebe kopnu za prasáckou češtinu, kop, kop. Použiju taky trochu CAPSLOCK, abych tomu dodal váhu a vykřičník! Vykřičník jak hrom!!

A taková rada, klidně nesouhlas, ale aspoň o tom něco znej a nemel sračky. kdybys v tom něco lowlevel psal či se o to pokoušel, věděl bys že v aktuálním stavu je D absolutně napíču, pokud teda zrovna nemá člověk chuť se přepisovat s druntime.

Místo tohohle si představ nějaký závěr a tak podobně.

Super, takže přepsat bych runtime nemusel, ale bez GC nic neběží ... Kurva, ty si řek sračku. Víš to? Asi jo, ale prostě si jen chtěl nesouhlasit.

S takhle hustým přístupem si diskutuj s někým, kdo ti na to skočí. Asi jsem dospěl, nebo co, ale nebudu ztrácet čas obhajobou něčeho, co je mi napůl ukradené, ale s čím mám náhodou osobní zkušenosti. Prostě mě za to nestojíš, pokud tě zajímá, jak to fakt je, tak si to vygoogli, pokud ne, hejtuj dál, nemám náladu klesat na tvojí úroveň diskuze. Koneckonců můj problém to není.

[pavlix]

:)

[květináč]

Lišáčku, fakt jsi mě zklamal. Myslel jsem že jsi inteligentní a vzdělaný. Teď cos napsal mne vyvedlo z omylu. Fakt, napsal si proud sraček bez jediný informační hodnoty. Jsi úplně mimo. Víš o tématu v kterém si ze mě chtěl udělat blbce úplný hovno. Sem myslel že si jinej, ale si jako ostatní sbírka postaviček tady. Arogantní, všechno víš a všude si byl dvakrát. A taky si ani pořádně nepochopil co sem napsal, jinak bys nepsal "je to tvůj problém" ale "byl to tvůj problém". A ta rada abych začal googlit perfektně sedí na tebe lišáčku.

[Bystroushaak]

Jo, je to spiknutí, kde je cílem udělat z tebe blbce. Ještě že jsi to odhalil *mrk*, *mrk*.

[pavlix]

Ahoj postavičko z Abclinuxu. :)

[Bystroushaak]

To je tuším taky diagnóza, kdy vnímáš okolní lidi jako méněcenné postavy. Většinou to docela dost vypovídá o člověku, který to používá, určitě ve smyslu arogance a sebevědomí. Jílek by nám o určitě pověděl víc.

Stejně tak je zajímavý způsob argumentace, který použil; že je zklamaný, protože si o mě myslel, že jsem vzdělaný a inteligentní. Argument jako kdyby mi snad mělo být líto, že si o mě vytvořil nějakou představu a teď jí neodpovídám. K tomu ještě nulová sebereflexe, vulgárnost a pocit, že mu ostatních chtějí uškodit. Fakt ideální kombinace do diskuzí, ten se jen tak neztratí.

[pavlix]

Je hezké, jak se každý zaměřujeme na něco úplně jiného. Tebe nejvíc zaujaly psychologické a sociální aspekty daného deprivovaného jedince a jejich projevy v diskuzi, zatímco mně ze všeho nejvíc baví ta nelogičnost počínání, kdy si člověk vybere místo nebo skupinu lidí, která ho nejvíce zajímá, a snaží se je urážet a vysvětlit jim, že jsou pro něj úplně nezajímaví. Nedávno jsem takhle viděl babu, co si vybrala pražskou lékárnu k tomu, aby nadávala na pražáky.

[Bystroushaak]

Na to už jsem si tak nějak zvykl.

[xkucf03]

Bezva, příště místo srazu uživatelů budeme pořádat sraz postaviček

[little.owl]

Tak takovahle imlementace jazyka a runtime libraries je celkem slusny show stopper i pro pouziti v aplikacich, o systemovem programovanim nemluve.

V posledni dobe zacinam mit pocit, ze psat cokoliv co ma byt dlouhodobe udrozovano v jazycich, ktere nemaji ISO/ANSI standard je uplne na pytel, i kdyz jsou to z vyjimkou C++ spise stojate vody.

[Bystroushaak]

Tak takovahle imlementace jazyka a runtime libraries je celkem slusny show stopper i pro pouziti v aplikacich, o systemovem programovanim nemluve.

Já bych hlavně moc nedal na květináče, protože, jak už jsem naznačil, jeho informace nejsou úplně kvalitní a v posledním ~roce se to hodně mění.

V posledni dobe zacinam mit pocit, ze psat cokoliv co ma byt dlouhodobe udrozovano v jazycich, ktere nemaji ISO/ANSI standard je uplne na pytel, i kdyz jsou to z vyjimkou C++ spise stojate vody.

Pokud ti jde o stálost, tak nemá smysl si vybírat takového nováčka, jako je D. Sice může nabízet sexy featury, ale API systémové knihovny se stále mění. Nedokážu říct, jestli je to dobře, nebo špatně - sám za sebe jsem rád, protože to znamená, že stále probíhá vývoj, než si to „sedne“ a tedy že „dospělá“ verze bude o to lepší. Já ovšem obecně preferuji rychlost vývoje před ostatními vlastnostmi, tak chápu, že to může vadit.

[little.owl]

a v posledním ~roce se to hodně mění.

Z vlakna:

Unfortunately, I doubt @nogc exception support will be ready for 2.068 (there isn't even any plans for it at the moment), and @nogc is still unusable until that's taken care of.

Pokud ti jde o stálost, tak nemá smysl si vybírat takového nováčka, jako je D. Sice může nabízet sexy featury, ale API systémové knihovny se stále mění.

Takze je to na ****** .

a tedy že „dospělá“ verze bude o to lepší.

A Godot stale neprichazi ...

Já ovšem obecně preferuji rychlost vývoje před ostatními vlastnostmi,

Jako pouzitelnosti?

Standardizovany jazyk ma vyhodu definovaneho chovani, zmeny standardu vetsinou nejsou tak radikalni a jsou [vetsinou] zpetne kompatibilni. To ma celou kupu praktickych dopadu, od stabilnich knihoven po udrzbu aplikaci ci zvladnuti jazyka na urovni, kdy si je clovek schopen poradit s jeho slabsimi strankami. To mi nejake nedopecene sexy featury novych jazyku, kterych je v posledni dobe v alejich nablito plno, nevykompenzuji, a to ani u throw away kodu.

A jazyk D? Pokud se neprosadil dodnes, tak se uz asi neprosadi, uz jen kvuli C++17 ci i treba Rustu.

[Radek Miček]

zvladnuti jazyka na urovni, kdy si je clovek schopen poradit s jeho slabsimi strankami

Pokud je specifikace jednoznačná, dostatečně detailní a není příliš složitá.

[little.owl]

To ma vice spolecneho se skutecnosti, ze jazyk je stabilni - ve smyslu kompatibility, nemeni se vam rychle pod rukama a nezahazujete pracne a nekdy bolestne ziskane zkusenosti.

Pripomina mi to kolegu ktery v C/C++ programuje od roku 1983, po precteni tohoto cisla Byte venovaneho C jazyku (stoji za to projit, 580 stran, vcetne clanku od Kernighan, Unix tutorialu ci review/benchmark tehdejsich C kompilatoru na tehdejsim HW).

[Bystroushaak]

Takze je to na ****** .

Prostě to bude chvíli trvat. Neznamená to, že to nemůžeš používat ihned, jen že to ihned nemůžeš používat s plnou podporou phobosu (jsou i jiné knihovny).

Já ovšem obecně preferuji rychlost vývoje před ostatními vlastnostmi,

Jako pouzitelnosti?

Stabilitou (ve smyslu změn v API, ne padání), rychlostí, do jisté míry i dokumentací.

A jazyk D? Pokud se neprosadil dodnes, tak se uz asi neprosadi, uz jen kvuli C++17 ci i treba Rustu.

Co se mě týče, tak je to jasná volba, pokud potřebuji sáhnout po něčem kompilovaném, protože mi garbage collector ve většině věcí nevadí.

[little.owl]

protože mi garbage collector ve většině věcí nevadí.

Hlavne treba psat kompilovane programy tak, abyste ho nepotreboval, C++11 vyse vam dava plno nastroju.

[Bystroushaak]

Já se nechci přít, protože se očividně pohybujeme v úplně jiných kruzích vývoje. Pro mě je prostě vhodnější D, i díky tomu, že neohrožuje mojí příčetnost.

[Radek Miček]

Ktere jazyky se tedy kompiluji do exe bez potreby runtime?

Je otázkou, čemu přesně budeme říkat runtime.

Třeba některé implementace nízkoúrovňových jazyků nepotřebují prakticky nic. Například C– nebo LLVM IR.

Krom toho mnoho implementací (např. GHC Haskell, OCaml, MLton, Ur/Web, …) umí přibalit runtime přímo do spustitelného souboru – runtime je často realizován jako obyčejná knihovna, takže ho stačí staticky přilinkovat.

[pavlix]

Vsechny novejsi jazyky pouzivaji runtime

To asi těžko, že. Nehledě na to, že ani C a C++ nejsou v pravém smyslu staré jazyky, stále se vyvíjejí.

A jestli tomu dobre rozumim, tak runtime pri c je libc, jen je nastesti v systemu

Nikoli, je to jen knihovna.

[aubi]

Aspon od Tebe bych cekal odpoved -- ktere jazyky delaji exace?

Ad C++ - novym jazykem bych to asi nenazyval ani pres jisty vyvoj. Zacinal jsem na nem, bude to tak dvacet let. A treba na mainframech je na tom C++ stejne jako Java - bez runtime nebezi.

[pavlix]

Aspon od Tebe bych cekal odpoved -- ktere jazyky delaji exace?

Jen si počkej na odpověď mistra programovacích jazyků výše, má mnohem větší přehled. Mimochodem, jazyk a toolchain jsou dvě zcela odlišné věci, nemá smysl jazyku přisuzovat vlastnosti, které má toolchain, jazyk nevytváří binárky ani nutně neurčuje všechny vlastnosti toolchainu.

A treba na mainframech je na tom C++ stejne

Přiznám se, že ani nevím, co se zde snažíš sdělit. Na mainframech běhá ledacos, takže bude většina kategorických tvrzení už z principu chybná.

[Fluttershy, yay!]

Aspon od Tebe bych cekal odpoved -- ktere jazyky delaji exace?

Jazyky? Exáče? Me gusta. Třeba Python: py2exe. ^_^

[:::]

Tady je nejakej seznam:

http://en.wikipedia.org/wiki/Compiled_language

asi nenu uplne kompletni...

[květináč]

Neplést runtime, běhovou platformu a knihovnu ano? C nemá nic, jen std knihovnu. C++ to samé. Haskell má běhovou platformu ale nikoli runtime (pro větší přehlednost tomu ale runtime říkají ...). Java, C# a spol mají všechno. To znamená i runtime (interpretr, je jedno jestli AST a nebo bytecodu). No, a LISPi sou kompilovany, některý implementace ne, ale to je fuk. A s modernosti opatrně ano? Napiš mi v Jave třeba OS, rychlí interpretr, real time řídící systém, hru s low nároky, AI většího rozsahu, simulaci atp...

[aubi]

Neni mi jasny, v cem je rozdil mezi runtime a behovou platformou (ktere taky rikaji runtime)?

Java ma virtualni stroj, ktery malo frekventovany kod interpretuje a casto frek. kompiluje do strojaku na zaklade presne informace o procesoru a statistice treba podminenych skoku, takze potencialne lip nez C. Minus drobny cas na kompilaci, samozrejme. Moje testy stejneho programu ukazaly stejny vykon Javy a optimalizovaneho C.

Moje oblibena hra IL2 je v Jave a soude podle stacku pri prvnich pokusech o beh pod wine ma na starosti i kresleni. On cpu stejne jenom natlaci data do gpu. Jo a to tam je pribalena java 1.3, ktera opravdu interpretovala.

U operacniho systemu (teda Linuxu) na kazdy kousek kodu koukaji stovky kritiku, viz diskuze exceptions vs. return codes. Jinak se radsi spolehnu na vymozenosti, ktere prosadila Java.

S interpretem taky muzu slouzit - kolega testoval rychlost parseru v Jave (Derby) proti jednomu v assembleru. Dvojnasobne rychlejsi Java. Assembleristi a ceckari se opaji blizkosti k hardware, ale unikaji jim jakekoliv struktury slozitejsi nez pole.

Koukam, ze bych si tady mel zalozit blog.

[pavlix]

Moje testy stejneho programu ukazaly stejny vykon Javy a optimalizovaneho C.

O tomto fenoménu jsem zatím slyšel jen v testech, nikdy v hodnocené reálného software, možná škoda.

S interpretem taky muzu slouzit - kolega testoval rychlost parseru v Jave (Derby) proti jednomu v assembleru. Dvojnasobne rychlejsi Java.

Což má ovšem nulovou vypovídací hodnotu.

Assembleristi a ceckari se opaji blizkosti k hardware, ale unikaji jim jakekoliv struktury slozitejsi nez pole.

To jistě. Když dneska začneš psát v céčku tak se ti do pozítří z hlavy vykouří všechny znalosti datových struktur.

Koukam, ze bych si tady mel zalozit blog.

Tipuju, že už tu alespoň jeden máš.

[Květináč]

Runtime jazyka je v dnešní době blbě definovaný slovo. Může to být interpret, může to být i podpůrná platforma jazyka. A nebo obojí. Interpret je jasnej. A je jedno jestli interpretuje AST nebo bytecode. A JIT je jen optimalizace interpretru. Podpůrná platforma může být GC, zabudovaný háčky pro debuger, profiler, podpora pro Lazy evaluation či něco na tendle způsob (třeba podpora reaktivity, FRP). V dnešní době se prostě musíme kouknout na jazyk, popřípadě na jeho implementaci, a zistit, do jaký kolonky to "runtime" patří. Takže tak.

No a teď rychlost Javy a C. To je hruuuuza. Java je fajn jazyk (na něco). Ale táhne ji ke dnu banda evangelistů, ochotna pro zdůraznění rychlosti Javy udělat cokoli. Stejný trend sleduju bohužel i u Haskellu. Sakra probuďte se doprdele. Abys mohl porovnat rychlost C a Javy, musíš mít oba jazyky stejně rád a být v obou jazycích stejně dobrý, pak napsat program a porovnávat. Bohužel, takový evangelista je hotovej z Javy a schválně program v Cčku zkurvý. Buď schválně a nebo proto že je debil. A tak vznikaj výsledky jako že Java je 3 krát rychlejší než C. Jako viděl sem i případ kdy evangelista v Haskellu ukázal že je Haskell rychlejší než C. Pomoh si zmenšením počtu iterací algoritmu v Haskellu. Stejně je to i v Javě. Takže klid.

A ta rychlost JIT. Kompilace kódu dost času sežere, a samotné zjišťování který kód se hodí pro kompilaci taky. Takže bohužel je to dost nezanedbatelný zdržení. Jen pomysli co potřebuješ. Kód musíš rozdělit na bloky. Každý blok musí mít ňáký counter použití. Ten counter musí být zamykaný, protože máme paralelní programy žejo ... dále před každým blokem musíme mít kód, který se rozhodne jestli to zkompilovat a nebo interpretovat. A ta kompilace není žádnej med, plus ještě dynamický linkování. A jakýkoli snahy o větší optimalizaci za běhu obvykle víc sežerou než dají.

Takže ve výsledku, ano, když aplikace poběží dlouho, JIT interpretr bude takřka tak rychlí jako nativní kód. Ale to je pouze teorie. Praxe je jinde co tak sleduju programi v Jave a C# (GC v imperativních jazycích dělá svý, to taky ...).

A naposledy, to že je něco napsanýho ručně v ASM pomalí není žádný div. V ASM je kurva těžký něco rychlího udělat. Ona to není sranda. Nemám tady teď ani čas a ani chuť psát proč, ale zkušenější mi daj za pravdu, že napsat v ASM něco rychlího vyžaduje fakt dokonalou znalost daný architektury a všech jejích zákoutí.

Jo a ten kec o poli na konci ukazuje na tvoji neznalost. Naše imperativní architektury neznaj nic efektivnějšího než pole. Maj dobrou cache locality a naše paměť je jedno velký pole. Třeba takový Hash tabulky sou mnohem rychlejší na dnešních architekturách než search trees (rekurzivní struktury -> funkcionální struktury ...). Pole má přístup O(1), stromy O(LOG N). Až bude nějaká funkcionální počítačová architektura, bude to jinak, ale není. Zatím.

[koudy]

Výborně napsané!

Tak jako nemůžu jít s bouracím kladivem okopávat macešky, nemá moc velkou logiku psát OS v něčem co má GC. Naopak nějaké jednoduchý filtr textu zas nebudu psát v ASM.

(myšleno jednoduché echo "burak" | sed sabaca > to_neni_o_vas_pane_reditely.txt )

Aneb jak říká lidové moudro: "Pokud znáš jen kladivo, ke všemu budeš přistupovat jako ke hřebíku."

[pavlix]

burak

Co to má prosím být?

[koudy]

Burák = burský ořech (neboli podzemnice olejná, latinsky: opravdu netuším :) )

Nebo taky: http://www.tapetynaplochu.org/tapety/tapetynaplochu-org-1024x768-02082008123028.jpg

[deda.jabko]

nemá moc velkou logiku psát OS v něčem co má GC

Zahraju si dablova advokata a zeptam se: "Proc?"

Kdyz si vemu klasicky mikrokernelovou architekturu, tak je absolutne jedno, jak funguji jednotlive servery a jak pracuji s pameti.

Mimochodem, hromada vyzkumu v oblasti OS jde smerem, ze se upousti od low-level prace s pameti ala struct+malloc a pracuje se s objekty na vyssi urovni abstrakce, aby sla dokazovat korektnost a dalsi vlastnosti OS.

[koudy]

Nebudu si tu hrát na experta v OS a ani v programování, rád svuj názor zmením, poté co se dozvím nové informace :)

 

Dle mého není dobré mít GC v kernelu z techto duvodu:

Garbage collector si musí nejak uchovávat ukazatele na všechna alokovaná pole, což pro celý systém bude mít urcitou pametovou nárocnost a to pole musí procházet a uvolnovat - vytežuje CPU.

Pokud budete GC delat u neceho jako síte - pokud bude každý paket dynamický, mužete vyhradit 1 procesor jen na uvolnování sítového provozu.

(to asi preháním a muselo by to být velmi špatne navržené, ale tušíte kam mírím? - malé pametové (de)alokace x set/tisíc/... krát za sekundu - jde to rešit lépe, ale když má clovek možnost udelat neco rychle, nebo správne, jsou tací, kterí to udelají správne, ale urcite to nejsou všichni)

 

Pro více procesorový systém musíte rešit, zda má GC bežet na každém CPU samostatne, nebo zda má bežet jedno pro všechna CPU/kde a jak budou uloženy struktury pro GC. (je vubec možné udelat GC vícevláknové pro každý procesor zvlášt?)

Na to samozrejme navazuje problém se synchronizací mezi CPU, lokováním sdílených struktur.

Hlavne si ale myslím, že bez GC je to rychlejší a méne nárocné na pamet.
To je jen pár drobností které mne ted napadají.

Všechny problémy jdou samozrejme rešit, ale nevím zda není jednodušší si proste pamet (od)alokovat dle potreby.

Microsoft napsal OS v C# (singularity), ale presto nízkoúrovnové veci jsou v ASM/C.
Trošku na me Singularity pusobí jako Hurd - obojí to je spíš akademická debata než OS a obe OS vyjdou ve stejnou dobu - až zamrzne peklo :)

Omlouvám se za diakritiku - nějaká chyba ctrl+insert shift+insert.

[Radek Miček]

(je vubec možné udelat GC vícevláknové pro každý procesor zvlášt?)

Pokud procesory nesdílí paměť, pak ano.

Na to samozrejme navazuje problém se synchronizací mezi CPU, lokováním sdílených struktur.

Pokud sdílíte paměť, tak tyto problémy nastávají i bez GC – např. malloc to také musí řešit.

Hlavne si ale myslím, že bez GC je to rychlejší a méne nárocné na pamet.

Záleží, jak je to implementované.

Všechny problémy jdou samozrejme rešit, ale nevím zda není jednodušší si proste pamet (od)alokovat dle potreby.

Jednodušší to není, nicméně v některých situacích to může být nutné.

[koudy]

Pokud procesory nesdílí paměť, pak ano.

To má logiku :)

Pokud sdílíte paměť, tak tyto problémy nastávají i bez GC – např. malloc to také musí řešit.

Měl jsem na mysli i to, že GC musí procházet paměťové bloky se kterými nyní pracuje jiná část systému, ten blok se může měnit, zatímco ho chce GC číst a podobné synchronizační vychytávky.

Free většinou volá přímo ten kdo vytvářel data, většinou přímo ten samý proces, takže nedochází ani k přepnutí procesů.

Pokud už uvolňuje paměť někdo jiný než ten kdo ji vytvářel, většinou ten jiný proces s alokovanými daty pracoval, takže je má v cache a nemusí je odnikud tahat.

Záleží, jak je to implementované.

S tím si dovolím nesouhlasit - můžete to udělat méně náročné na procesor, ale pak to bude stát více paměti a naopak, ale nikdy to neuděláte rychlejší a zároveň méně paměťově náročné než malloc/free způsob uvolňování, pokud ty implementace budou kvalitativně stejné.

Já vím, nikdy neříkej že něco nejde, protože se najde nějaký *** který neví že to nejde a udělá to, ale tady jsem si celkem jistý... [Citation needed] (sorry Randall Munroe, ale musel jsem :) )

Jednodušší to není, nicméně v některých situacích to může být nutné.

Jj to je fakt, jako líný programátor bych občas dal za GC zlatý prase :)

[Radek Miček]

S tím si dovolím nesouhlasit - můžete to udělat méně náročné na procesor, ale pak to bude stát více paměti a naopak, ale nikdy to neuděláte rychlejší a zároveň méně paměťově náročné než malloc/free způsob uvolňování

S GC můžete snadno sdílet části datových struktur a tím ušetřit paměť (a někdy i čas).

Například s GC můžete implementovat hash consing – sdílení (strukturálně) stejných hodnot. Často se to používá v dokazovačích (implementuje se vlastní GC) a například autor dokazovače E píše, že tím ušetří 80% až 99,99% uzlů pro termy. Navíc tím ušetří i čas, neboť statistiku pro stejné termy nepočítá vícekrát.

[koudy]

Nešlo by něco takového implementovat i bez GC?

[Radek Miček]

Nevím, jak. Abyste sdílenou datovou strukturu mohl bezpečně uvolnit, musíte vědět, že ji už nikdo nepoužívá – např. si průběžně vést evidenci, kdo ji používá (počítání referencí), nebo se vždy podívat, zda ji někdo nepoužívá (mark & sweep).

[koudy]

Díky, nechtělo se mi číst to pdf celé.(možná že se začtu, jen na to teď není klid a čas) :)

Jak jsem psal už jinde - správné nástroje na správné věci. V tomhle případě je to určitě zjednodušení.

[Radek Miček]

V tom PDF jsou relevantní slajdy 49, 64-74.

[koudy]

Ještě jednou díky, přečtu si to ještě podrobněji, ale překvapilo mě:

"Allocating and chopping up large blocks does not pay off!"

[Radek Miček]

Mj. E pro banku termů používá mark & sweep.

[deda.jabko]

Měl jsem na mysli i to, že GC musí procházet paměťové bloky se kterými nyní pracuje jiná část systému, ten blok se může měnit, zatímco ho chce GC číst a podobné synchronizační vychytávky.

Nemusi. Protipriklad: mikrokernel. Jednotlive casti OS jsou v oddelenych pametovych prostorech, takze prochazet pametove bloky cizich casti systemu evidentne nemusis.

ale nikdy to neuděláte rychlejší a zároveň méně paměťově náročné než malloc/free způsob uvolňování, pokud ty implementace budou kvalitativně stejné.

Protipriklad: Vezmi si ve smycce milionkrat free(malloc(20)) a pak to zkus zamenit za milionkrat (nejake) gc_malloc(20) + jednou full gc.

[koudy]

Dobré připomínky. Beru v potaz :)

[deda.jabko]

Garbage collector si musí nejak uchovávat ukazatele na všechna alokovaná pole, což pro celý systém bude mít urcitou pametovou nárocnost a to pole musí procházet a uvolnovat - vytežuje CPU

Ty ukazatele neni potreba uchovavat. Ona i bezna alokace ma nejakou rezii, jen to neni tak na ocich. Pocitani odkazu, ktere se bezne pouziva, je technicky vzato jen chudy pribuzny GC.

Pokud budete GC delat u neceho jako síte - pokud bude každý paket dynamický, mužete vyhradit 1 procesor jen na uvolnování sítového provozu.

(to asi preháním a muselo by to být velmi špatne navržené, ale tušíte kam mírím?

Ne, netusim.

Pro více procesorový systém musíte rešit, zda má GC bežet na každém CPU samostatne, nebo zda má bežet jedno pro všechna CPU/kde a jak budou uloženy struktury pro GC. (je vubec možné udelat GC vícevláknové pro každý procesor zvlášt?)

Ne, nemusis. Navic muzes jit i tak daleko, ze muzes mit GC pro jednotlive moduly -- sitovani, FS, atp.

Na to samozrejme navazuje problém se synchronizací mezi CPU, lokováním sdílených struktur.

To je obecny problem i bez GC.

Hlavne si ale myslím, že bez GC je to rychlejší a méne nárocné na pamet.

Byly doby, kdy si lide mysleli, ze operacni system se da psat jen v ASM.

Microsoft napsal OS v C# (singularity), ale presto nízkoúrovnové veci jsou v ASM/C.

Toho nizkourovnoveho kodu tam bylo pomalu.

Trošku na me Singularity pusobí jako Hurd - obojí to je spíš akademická debata než OS

Singularity byl vyzkumny projekt, takze se opravdu nediv, ze kolem toho byla akademicka debata... Srovnani s Hurdem notne pokulhava.

[koudy]

Ty ukazatele neni potreba uchovavat.

Nějak snad musíte vědět, kterou paměť máte volnou a kterou někdo používá + alespoň velikosti alokovaných polí? (něco takového má samozřejmě i malloc)

Ne, nemusis. Navic muzes jit i tak daleko, ze muzes mit GC pro jednotlive moduly -- sitovani, FS, atp.

Není to pak zas o něco pomalejší? Pokud se GC musí rozhodovat jaký typ GC pro každé uvolnění použít? Nebo běží takové GC v rámci stejného vlákna/objektu? (něco na způsob contructor x destructor - jako že si každý uklízí sám po sobě)

Byly doby, kdy si lide mysleli, ze operacni system se da psat jen v ASM.

Point taken :)

Srovnání singularity X hurd bylo spíš myšleno jako b*bý vtip, měl jsem ještě kocovinu a přišlo mi to vtipné (očividně pouze mě) ;)

[xkucf03]

Pokud budete GC delat u neceho jako síte - pokud bude každý paket dynamický, mužete vyhradit 1 procesor jen na uvolnování sítového provozu.

(to asi preháním a muselo by to být velmi špatne navržené, ale tušíte kam mírím? - malé pametové (de)alokace x set/tisíc/... krát za sekundu - jde to rešit lépe, ale když má clovek možnost udelat neco rychle, nebo správne, jsou tací, kterí to udelají správne, ale urcite to nejsou všichni)

Tohle by mělo jít řešit tím, že na různých úrovních budu používat různé (vhodné) nástroje, ne? Síťový provoz, tahání dat z disku a spousta dalších věcí by se řešila klasicky. A jinde, kde tolik nezáleží na rychlosti a nejde o milionkrát opakované činnosti, ale naopak je tam složitější byznys logika, by se používaly objekty, GC, RAII, výjimky a různé další vymoženosti. Někdo asi řekne, že tohle má řešit až aplikační logika, ale podle mě by to bylo užitečné už v tom OS resp. na rozhraní mezi OS a aplikacemi.

[koudy]

Tady to bylo myšleno (teda já to myslel) napsat celý kernel s GC.

Jinak samozřejmě nevidím problém to udělat, postup jaký navrhujete Vy, mi přijde rozumný.

Na druhou stranu je otázka zda není lepší napsat drivery a podobné věci nízkoúrovňově a ovládání nechat systémovým knihovnám, kde může být GC, objekty atd.

[koudy]

Ok, přesvědčily jste mě, že by to asi bylo proveditelné...

Existuje nějaký takový projekt?

Slovy Linuse: Show me the code :)

[koudy]

Dobře, možná to mohlo být o trošku méně arogantně, ale jinak souhlas :)

[R]

Ani z Javy nemusism mat JAR, da sa tiez skompilovat do binarky. Vid gcj.

[ava]

Ja dělám triviálně z javy "exáče" pomoci proguard + launch4j. Samozřejmě to stále vyžaduje k běhu JRE...

[ava]

Díky moc za parádní článek! Sám používám RxScala (binding RxJava do scaly), tak jsem nesmírně rád za možnost srovnání s scalaz-stream.

Chtěl jsem se zeptat na tvrzení o časové složitosti(cituji: "Například časová složitost zřetězení proudů bude záležet na uzávorkování: zřetězení uzávorkované doleva (tj. (a ++ b) ++ c) bude mít kvadratickou časovou složitost a zřetězení uzávorkované doprava (tj. a ++ (b ++ c)) bude mít lineární časovou složitost."). Jak to myslíte? Podle mě časová složitost bude vždy stejná, (pokud se bavím o RxJava), tak se vždy budou emitovat prvky nejprve z Observable a, pak b, pak c. Časová složitost podle mě bude vždy prostý součet složitostí jednotlivých observables, v čem se podle vás časová složitost liší?

Jinak co se týče správy zdrojů, v RxJava je na ni operátor using.

Těším se na popis terminologie (tak nějak očekávám, že tam budou nějaké zdroje, operátory a sinky, ale těším se na ucelené vysvětlení).

Také jsem zvědavý na vytváření vlastních observables (či jak se to v scalaz-stream jmenuje :). Byl bych vděčný za příklad, kdy by se vytvářel stream unit-ů reprezentujících např. kliky ve swingovém tlačítku. V RxJava si můžu vybrat, zda chci přidat actionlistenera pro každého, kdo se o kliky zajímá, nebo zda se má přidat actionlistener pouze pokud je více než 0 posluchač, a kliky se multicastují (operator share), jak se něco podobného dělá v scalaz-stream? I když možná moc předbíhám ve výkladu :)

Zrovna jsem se chystal, že bych si měl konečně přečíst Genuinely Functional User Interfaces od Antony Courtneyho a Conala Elliotta, tak to snad do příště stihnu, ať se trochu orientuji :)

Tak se velmi těším, díky!

[Radek Miček]

Chtěl jsem se zeptat na tvrzení o časové složitosti(cituji: "Například časová složitost zřetězení proudů bude záležet na uzávorkování: zřetězení uzávorkované doleva (tj. (a ++ b) ++ c) bude mít kvadratickou časovou složitost a zřetězení uzávorkované doprava (tj. a ++ (b ++ c)) bude mít lineární časovou složitost."). Jak to myslíte?

Byly myšleny dlouhé sekvence ++. Každé ++ vytvoří nové Observable. Čtete-li z ((a ++1 b) ++2 c) ++3 d (++ jsem očísloval), tak prvky z a jdou do Observable, jenž vytvořilo ++1, pak do Observable, jenž vytvořilo ++2, a nakonec do Observable z ++3. Takže, když těch ++ tam bude třeba milión, tak každý prvek z a musí projít miliónem Observable, ne?

V RxScala to simuluje následující kód:

import rx.lang.scala.Observable

object HelloWorld {
  def leftAssoc(i: Int, acc: Observable[Int] = Observable.empty): Observable[Int] =
    if (i > 0)
      leftAssoc(i - 1, acc ++ Observable.just(i))
    else
      acc

  def rightAssoc(i: Int, acc: Observable[Int] = Observable.empty): Observable[Int] =
    if (i > 0)
      rightAssoc(i - 1, Observable.just(i) ++ acc)
    else
      acc

  def f(i: Int): Unit = {
    val l = leftAssoc(i)
    val r = rightAssoc(i)

    println("i = " + i)
    println("startingl")
    val x = System.nanoTime()
    l.subscribe(i => (), e => (), () => ())
    val x2 = System.nanoTime()
    println("startingr")
    val y = System.nanoTime()
    r.subscribe(i => (), e => (), () => ())
    val y2 = System.nanoTime()
    val bil = 1000 * 1000 * 1000
    println((x2-x) / bil,(y2-y) / bil)
  }

  def main(args: Array[String]): Unit = {
    Seq.range(1, 5).map(_ * 10000).foreach(f)
  }
}

Podle výstupu to však vypadá, že složitost je bohužel kvadratická, ať to uzávorkujete zleva nebo zprava:

i = 10000
startingl
startingr
(1,1)
i = 20000
startingl
startingr
(9,9)
i = 30000
startingl
startingr
(24,30)
i = 40000
startingl
startingr
(68,60)

Navíc jsem si musel s RxScala zvětšit velikost zásobníku, aby mi to nepadalo. Analogický kód pro scalaz-stream je:

import scalaz.concurrent.Task
import scalaz.stream._

object HelloWorld {
  def leftAssoc(i: Int, acc: Process[Task, Int] = Process.empty): Process[Task, Int] =
    if (i > 0)
      leftAssoc(i - 1, acc ++ Process(i))
    else
      acc

  def rightAssoc(i: Int, acc: Process[Task, Int] = Process.empty): Process[Task, Int] =
    if (i > 0)
      rightAssoc(i - 1, Process(i).toSource ++ acc)
    else
      acc

  def f(i: Int): Unit = {
    val l = leftAssoc(i)
    val r = rightAssoc(i)

    println("i = " + i)
    println("startingl")
    val x = System.nanoTime()
    l.run.run
    val x2 = System.nanoTime()
    println("startingr")
    val y = System.nanoTime()
    r.run.run
    val y2 = System.nanoTime()
    val bil = 1000 * 1000 * 1000
    println((x2-x) / bil,(y2-y) / bil)
  }

  def main(args: Array[String]): Unit = {
    Seq.range(1, 5).map(_ * 10000).foreach(f)
  }
}

Dává to výstup

i = 10000
startingl
startingr
(0,0)
i = 20000
startingl
startingr
(0,0)
i = 30000
startingl
startingr
(0,0)
i = 40000
startingl
startingr
(0,0)

[ava]

Hmm, máte pravdu, že kód se zpomaluje alespoň kvadraticky s ++. Celkově je to pomalý šíleně (i když to asi není zrovna typický use-case). Zajímalo by mě, co to brzdí..

Je váš scalaz-stream kód opravdu ekvivalentní? V RxScala řetězíte Observable.just, ale v scalaz-stream Process.empty, to asi nedělá to samé? Jinak není to nikde vyřčeno, ale pochopil jsem správně, že se scalaz-stream vám zásobník nepřetéká? Jak je to možné?

[Radek Miček]

Jinak není to nikde vyřčeno, ale pochopil jsem správně, že se scalaz-stream vám zásobník nepřetéká? Jak je to možné?

Ano, nepřetéká. Obecně lze použít trampolíny a vlastní kód transformovat tak, že nebude potřebovat více než jedno volání na zásobníku. Myšlenka je jednoduchá: Funkce, které budete psát, nebudou volat žádné jiné funkce – místo toho, když budete chtít zavolat funkci, tak vrátíte nějaký objekt, který říká, co chcete zavolat. Když máte výsledek, vrátíte jiný objekt, který říká, že už nechcete nic volat. Tj. vracíte

trait ReturnVal[A]
// Vracím, když jsem skončil a mám výsledek.
case class Result[A](a: A) extends ReturnVal[A]
// Vracím, když ještě nemám výsledek a chci zavolat další funkci, která ho možná spočte.
case class Cont[A](f: () => ReturnVal[A]) extends ReturnVal[A]

K tomu napíšete interpretr – např. while cyklus nebo tail rekurzivní funkci, která bude opakovaně volat funkce vracející ReturnVal, dokud nedostane Result. Jediný, kdo něco volá, je tedy interpretr, takže hloubka volání je 1.

To je jeden z triků, co se tam používá – je to ve třídách Trampoline a Task ze scalaz. Je to také popsáno v článku Stackless Scala With Free Monads.

Bohužel důsledkem trampolín je ztráta výkonu a zvýšená alokace (alokace ReturnVal). Navíc máte jinou konvenci volání – trampolínované funkce nejsou kompatibilní s ostatními funkcemi.

[ava]

Díky za vysvětlení. A ta ekvivalence kódu RxScala a scalaz-stream? :)

[Radek Miček]

Je váš scalaz-stream kód opravdu ekvivalentní? V RxScala řetězíte Observable.just, ale v scalaz-stream Process.empty

Pokud se nepletu, tak leftAssoc(3), vytváří

((Observable.empty ++ Observable.just(3)) ++ Observable.just(2)) ++ Observable.just(1)

resp.

((Process.empty ++ Process(3)) ++ Process(2)) ++ Process(1)

což je stejné.

[ava]

Ajo, nějakou selektivní slepotou jsem nedokázal vidět to volání Process(i) v *assoc, nechápu jak je to možné. Souhlasím, vypadá to stejně, díky.

[xkucf03]

Ekvivalentní kód v Javě vypadá následovně:

Jaký má smysl srovnávat na jedné straně Scalu + externí knihovnu a na druhé straně čistou Javu (jen standardní knihovnu)? Pro Javu existují spousty knihoven a není důvod, proč by v ní ten kód měl vypadat složitěji.

BTW: kdo je autorem článku? Bývalo zvykem tu uvádět jména nebo přezdívky.

[Saljack]

Nehlede na to ze Java 8 to jde zapsat naprosto stejne pomoci streamu.

[xkucf03]

O tom jsem nedávno psal

Java 8: Stream API

[Radek Miček]

Jaký má smysl srovnávat na jedné straně Scalu + externí knihovnu a na druhé straně čistou Javu (jen standardní knihovnu)?

Cílem bylo ukázat klasický imperativní zápis – je na něm vidět, co všechno kód ve Scale dělá (například se postará o otevření a uzavření zdrojů nebo nemusí číst soubory až do konce). Pro tento kód jsem zvolil Javu, neboť Scala standardně nemá break a ani speciální syntax pro automatickou správu zdrojů.

[xxxs]

tiez ma zaujima autor.

[MR]

Redakci jsem pozdal o doplneni autora, kterym je Radek Miček

[:::]

Začneme programem, který vypíše řádky souboru na standardní výstup ...

open(F, "countries.txt");
print <F>;

Pokud by to teda nekdo chtel pomoci cyklu, tak:

open(F, "countries.txt");
while (<F>) {
        print $_;
}

myslim ze zustanu u perlu...

[pavlix]

Perl se mi moc líbil, když jsem ho zkoušel, ale psát programy bych v tom nechtěl.

[spam]

I personally like your post; you have shared good insights and experiences. Keep it up. waxing baton rouge la

[spam]

I really loved it here but are there any recent updates? Thanks charlottenchairextensions.com

[spam]

Well this is great site! Would definitely recommend this to my friends. Love the read www.boudoirphotographylongbeach.com

[spam]

INTERESTING POST! KEEP POSTING MORE! deckbuildersspartanburg.com

[spam]

I really loved it here but are there any recent updates? Thanks life lesson

[Thomas]

The information addresses an "occasion" or an adjustment of express that has happened in the business and is helpful for the business to be aware of and examine, frequently continuously. A few instances of information streams incorporate sensor information, action logs from internet browsers, and monetary exchange logs.

In line with this I came across a concrete repair site which caught my attention. check this out:

concrete repair

[expanding foam - Alden]

Looks like there so many things that have been brought up already in this page. expanding foam - Alden