Názory k článku Erlang: trochu jiný přístup k programování

Ahoj,
díky za fajn úvod do Erlangu, budu se těšit na další díly.

Tesim se na dalsi pokracovani as soon as possible ;-)

Jazyk, koncept, nebo platformu?

Ahoj, myslel jsem OTP a narážím na to, že Erlang schytal kritiku i od lidí, kteří ho používají (zejména co se týče syntaxe vyšlé z Prologu). No a na to, že má někdo furt potřebu vymýšlet věci jako Elixir a LFE.

Takže:

- jazyk Erlang může být navržen skvěle nebo méně šťastně.

- koncepty, které používá (actory, pattern matching apod.) jsou super, ale jsou i jinde ve stejné nebo podobné formě

- OTP je zcela jistě v mnoha věcech super a Erlang k ní patří

Nebyl jsem si ale jistý, zda máš na mysli ten celek nebo i třeba výslovně tu syntaxi a sémantiku jazyka. Dík za odpověď, když to víc rozvedeš Ty nebo někdo jiný, bude to taky fajn.

Ahoj, len 2 male upresnenia, inak dobry clanok:

1) "Data při volání funkce nebo zasílánízprávy jinému procesu se obsahy proměnných nekopírují" - V skutocnosti sa pri posielani sprav inemu procesu (s vynimkou large binaries) obsah premennych kopiruje. Procesy maju oddelenu spravu pamati a vdaka tomu sa pri spusteni garbage collectora nemusi stopnut cela Erlang VM ale len dany proces.

2) "tail rekurzi, kdy je rekurzivní volání sebe sama jako poslední instrukce před opuštěním funkce" - Tail call Optimization (TCO) je len specialny pripad Last Call Optimisation (LCO). Erlang ma LCO, cize tato optimalizacia funguje pri volani lubovolnej funkcie, ak je to posledna insturkcia (nie len sama seba).

Programoval som distribuovany MapReduce framework ako diplomovku tento rok, tak to mam celkom cerstvo v pamati :)

zdroj: http://learnyousomeerlang.com/recursion

Note: tail recursion as seen here is not making the memory grow because when the virtual machine sees a function calling itself in a tail position (the last expression to be evaluated in a function), it eliminates the current stack frame. This is called tail-call optimisation (TCO) and it is a special case of a more general optimisation named Last Call Optimisation (LCO).

LCO is done whenever the last expression to be evaluated in a function body is another function call. When that happens, as with TCO, the Erlang VM avoids storing the stack frame. As such tail recursion is also possible between multiple functions. As an example, the chain of functions a() -> b(). b() -> c(). c() -> a(). will effectively create an infinite loop that won't go out of memory as LCO avoids overflowing the stack. This principle, combined with our use of accumulators is what makes tail recursion useful.

Je pravda ze termin LCO sa moc nepouziva. Ci sa to oznacuje TCO/LCO alebo TCO/[vseobecny] TCO je fakt jedno, hlavne nech sa chape co sa tym mysli.
Ak sa nemyli aj autor tej knihy a ja ho spravne chapem, tak Erlang skutocne vyhadzuje stack aj pri vseobecnej TCO.

A tu poznamku o tom ako je skvele ked opravujuci nevie co hovori si si mohol odpustit.

pekny clanok, vdaka.

zaujalo ma, ze to vysvetluje principy, ktore sa znovuobjavuju v reaktivnom programovani /akka/.

Boos Asio je na prvy pohlad sialene ale ked clovek pochopi co,kde ako tak sa celkom da. Co ma vytaca je ale "schopnost" niektorych prekladacov pri chybe v sablone (co asio+streamy pouzivaju) vyplut milion riadkov chybovuch hlaseni.

da sa nejakou formou prispiet autorovi ako mala motivacia na pokracovanie? :-)
napriklad paypal

připojuji se, rád bych přispěl, kdyby byl zájem. Erlang patří mezi moje koníčky, ten jazyk obdivujia ač v profesním se věnuji jiným jazykům.

Zajímalo by mě, jak je to s těmi poli v Erlangu. V Haskellu se při změně jednoho prvku musí celé pole kopírovat (pokud se nepoužívají monádová pole), jak je to tady? Taky se pole kopíruje, nebo je tam něco chytřejšího?

polem mas na mysli seznam? (syntakticky [] to pripomina cckovsky pole)

Seznamy jsou (stejně jako všechny ostatní hodnoty) neměnné, takže se při změně kopírují, ale protože seznamy obsahují jen ukazatele na hodnoty, tak je to většinou celkem levná operace. Pokud potřebujete seznamy o hodně prvcích, lze použít třeba hashové tabulky, kde se kopíruje akorát seznam kyblíků (bucketů) a ten kyblík, který se změnil.

K funkcionálnímu programování jsem se nejblíže dostal s Lispem, takže mi zřejmě "opravdové funkcionální programování" uniká. Tak nějak jsem žil v domění, že základem jsou právě seznamy a jejich nekonečné změny. Některé funkce seznamy generují, jiné zpracovávají, některé transformují. Všechny ty "head" a "tail" ve mně evokují pocit, že je tam moře seznamů, které se neustále mění.

Čtu tohle vlákno několikrát, ale moc mi to nedochází. Znamená to, že prvky seznamu jsou immutable někde v paměti, ale vlastní seznam je dynamická struktura, která se mění? Ve smyslu že je to pole nebo nějaká jiná struktura pointerů a že se v ní přepisuje, přičemž "neměnná" se vztahuje k jednotlivým prvkům, ale nikoliv seznamům vlastním?

Nebo to doopravdy neustále generuje nové a nové seznamy, kde je jen nižší režie díky tomu, že jsou to odkazy na prvky a tak se bavíme o řádově 4-8 bytech na prvek?

Kupříkladu by mě zajímal Bubble sort nebo Merge sort. Typicky algoritmy měnící pořadí prvků v seznamu. Jestli ten Bubble sort skutečně O(n^2) krát kopíruje seznam.

Díky, už to chápu, snad správně. Je to celé immutable, takže "naivní" bubblesort je katastrofa. Co to umí levně (skoro zadarmo) je práce s head a tail, takže přidávání prvků na začátek nebo jejich odebírání je složitost konstantní. Proto pokud použiji algoritmus, který vystačí s "head a tail", tak bude velmi efektivní. Mimochodem, i ten bubblesort se dá napsat nad linked listem jako O(n^2), takže pokud immutable umí head a tail s konstatní složitostí, tak by to immutable nemělo zhoršit.

Jestli to chápu správně, tak obecně pokud mám kód, který zpracovává seznam jako linked list, tak bude efektivní i při jeho přeskládávání a fakt, že je immutable, to nijak nezhorší. Teprve pokud použiji pole (nebo nějakou jeho "simulaci") tak mám problém. Kreslení do frame bufferu tedy asi nebude typickou aplikací.

Čemu ale vůbec nerozumím je použití částí. Chápu, že když mám nějaký linked list, tak přidat mu prvek na začátek je triviální - udělám nový prvek a dám mu odkaz na původně první prvek. Mám tak dva seznamy, kde jeden je podmnožinou druhého. Jenže v tomhle případě oba končí stejně, jen má jeden něco extra na začátku. Když bych měl seznam linkovaný zpětně, tak můžu takhle přidávat na konec, ale začátek mají stejný. Jak realizovat, abych měl jeden seznam řekněme CDE a druhý ABCDEFG? Tedy jak to realizovat bez toho, že bych měl v paměti seznamy dva? Kdyby byl jen jeden prvek E, jak by poznal, kdy má jako následníka hlásit nic (první seznam) nebo F (druhý seznam)? Bez toho, abych měl dva prvky E (jen položku seznamu, v té bude pointer na datovou strukturu samotného objektu E, v obou seznamech stejný) si to představit nedokážu.

Jinak řečeno umím pochopit konstantní složitost přidání/odebrání prvku na začátku, respektive na konci (ne oboje najednou), ale ne obecné "proste se pouzijou casti ktery se nezmenily". Řečeno na příkladu, pokud mám seznam N prvků a ten na pozici M chci odstranit, tak vše od začátku až po M musím vytvořit znovu, M tam už nepřidám a místo něj tam dám link na tail(M). Takže znovu použití se týká jen části tail(M), vše před tím M musím vytvářet znovu, byť se to vlastně nemění. Jen prostě v mé nové verzi seznamu prvek M-1 linkuje nikoliv na M, ale na M+1. Je právě tohle myšleno tím "části který se nezměnily", nebo mi uniká ještě nějaká jiná vlastnost seznamů?

Heh, pro mě jsou Daemon Tools něco úplně jiného :)
Jinak s tím, že autor tvrdí jinými slovy víceméně že C#/Java je obvykle o několik řádů pomalejší, než kód v C, jaksi nemohu bez důkazů souhlasit...

Pravda, vetsinou je to vic nez nekolik...

Nemusis.suhlasit, to nie je povinne :-)
Len nerozvijaj flame o nepodstatnej veci,na to je tu uz dost rozbehnutych diskusii na fore

Přesně tak. Ještě by tu zase někdo začal násobit matice :)

No to by pak ale neohlásilo chybu při pokusu zadat záporné číslo :)

Přetečení a podtečení celých čísel se řeší tak, že celá čísla jsou nekonečná. Pokud přestanou stačit bity v integeru, použije se automaticky více bajtů.

Dobry clanok ale bolo by fajn keby si uz ludia spravili poriadok v tom co znamena parallel a concurrent.

Erlang NIE je paralelny jazyk, ale JE konkurentny jazyk.

Parallel - pouzitie viacerych CPU na rychlejsie spracovanie JEDNEJ ulohy (praca nad jednymi a tymi istymi datami)

Concurrent - spracovavanie viacerych nezavislych uloh (kazda so svojimi datami) naraz. Jazyk moze byt konkurentny aj ked VM-ka bezi iba na 1 CPU.

Tak jednoduché to není a ani definice dostupné na internetu se neshodnou. Obecně "concurrent" je situace, kdy máte více úloh, které sdílí nějaké zdroje. Mohou to být data, přístup na disk apod. Ale musí tam být nějaký zdroj, o který se přetahují. Pokud jsou úlohy nezávislé, tak si nekonkurují a bavíme se tak maximálně o multitaskingu OS.

Osobně pojmem "parallel program" označuji něco, co umí provozovat více instancí jedné úlohy. Zda sdílí data pro mne není důležité. Za paralelní program považuji i konvertor obrázků, který dokáže vytížit více jader, přestože každé konvertuje jiný obrázek.

No a "parallel execution" je jen popis situace, kdy běží v jednu chvíli více procesů. Jestli to jsou paralelní procesy nebo konkurenční procesy na názvu nic nemění.

Nemas pravdu, pravdu ma predrecnik. Viz http://www.youtube.com/watch?v=cN_DpYBzKso

Tady je tím zdrojem právě CPU.

Pak nemá smysl bavit se o konkurenčním nebo paralelním. Dnes mají CPU více jader, takže i 25 let staré binárky spouštěné pod emulátorem DOSu najednou začaly být paralelní. To tenkrát jejich autora asi ani nenapadlo, mohli to využít pro marketing.

Zkrátka se snažím říci, že CPU je zdrojem z pohledu OS. Pokud aplikace nevytváří žádná vlákna, neřídí zdroje a s ničím se nesynchronizuje, pak prostě není paralelní ani konkurenční. Fakt, že ji pak spustíte na OS, který umí multitasking, na tom nic nezmění.

> Pak nemá smysl bavit se o konkurenčním nebo paralelním.

Ma to smysl, protoze jsou to ruzne veci. Muzete mit paralelismus bez concurrency (napr. vektorove zpracovani nebo pipelining v CPU), i concurrency bez paralelismu (vice threadu na jednom CPU, coz se hodi, jakmile nejake z nich ceka treba na I/O a blokuje).

Přijde mi divné se v definici paralelního programovacího jazyka odkazovat na počet použitých CPU. To je přeci věc implementace, ne?

Spíše bych se zaměřil, jak jazyk popisuje závislosti mezi jednotlivými částmi programu.