Pár otázek ohledně unixu a programování

ferren

Re:Pár otázek ohledně unixu a programování
« Odpověď #90 kdy: 28. 02. 2013, 15:09:43 »
smoofy: tak ted nevim jestli je to ironicka recnicka otazka a nebo fakt dotaz:-) kazdopadne strucna odpoved, momentalne je programovani jednim z privilegovanych oboru,kde se novy job nehleda na pracaku,ale dokonce jsou i lidi, co aktivne mozne talenty vyhledavaji. danou problematiku docela verne zobrazuje film "Ja to teda beru, sefe!"

rax: admin mozna,programovani neni zas tolik o zkusenostech. a pokud jo, tak v trochu jinem kontextu nez "vydrene zkusenosti". pro me je docela bezne si od jednoho oboru na rok dva odpocinost(dobre,udelal jsem to 2x), delat treba neco uplne jineho (uplne mimo IT) a vratit se az je zpet chut. a nikdy jsem to ani ja, ani pripadny zamestnavatel, nebral jako handicap. spis bych rekl ze na tento pristup pripadni zajemci o me sluzby docela dobre slysi vic nez kdyz se jim hlasi nekdo vycucly a bez fantazie...


Re:Pár otázek ohledně unixu a programování
« Odpověď #91 kdy: 28. 02. 2013, 15:46:25 »
Od začátku to byl akademický projekt, který nikdy neměl analogii v reálném technologickém světě. Všechny komerčně úspěšné počítače na světě jsou hardwarově zařízeny na imperativní programování.
Prosím v následujícím mě nechytej za slovo: pro mě z praktického hlediska, pokud nebudu nějak moc hledět na teorii, filosofii apod. je funkcionální programování především o tom, jak se pracuje s daty - hlavní koncepcí je omezení/neexistence měnitelných dat. V čistějších formách potom omezení/neexistence funkcí s nedlejším efektem. To potom snadno umožňuje dekompozici na úplně samostatné jednotky, protože neexistují dílená data.

...no a tohle mi nepřijde vůbec v kontrastu s imperativním programováním. Jasně, z teoretického hlediska jsou to odlišné koncepty, ale prakticky ne. Třeba ten Erlang je vyloženě "imperativně laděný" - když v něm píšeš, myslíš v krocích, které se mají udělat. Pokud je FP s něčím v rozporu, tak právě s tím OOP a ani to neplatí doslova (procesy v Erlangu mi přijdou jako nejčistější OOP, které znám ;) - nejenom, že se jim posílají zprávy, ale navíc každý běží s vlastním "vláknem").

Ony ty paradigmata jsou jenom taková teoretická typologie - třeba takové multiagentní programování. To je podle tebe něco jiného než imeprativní? ;)

Celkovým rozšířením, drtivá většina aplikací na světě jsou imperativní programy. Zastoupení Erlangu je mizivé, to se dostáváme do čísel Algolu a Prologu, ty jsou také stále zastoupeny v těch nejrenomovanějších firmách :-)
Tak to jo. Rozšířením jo. Dneska je asi většina programů OOP*, ale to nemusí být navěky, že...

* zmršené okleštěné OOP ve stylu C++

No jenže to spolu právě úzce souvisí. Může se lehce stát, že objektové programování tu mnohojadernost nebude moc dobře zvládat... I když těžko říct, jestli to s tou mnohojaderností bude tak žhavé - spíš bych možná čekal pomalé vracení kyvadla zpátky - spíš směrem k úsporným a malým zařízením.

Imperativní programování zvládá mnohojadernost od samého počátku více než 30 let a nezdá se že by s tím byly nějaké zásadní potíže.
Jistěže s tím jsou potíže. Konvenčně napsané programy nemůžou škálovat a neškálují ani zdaleka lineárně k počtu vláken. U programů napsaných funkcionálně (z hlediska práce s daty - viz nahoře) by to aspoň teoreticky mohlo být daleko lepší - a praktická měření tomu celkem odpovídají viz např. http://kth.diva-portal.org/smash/get/diva2:392243/FULLTEXT01 - obrázek 4.1 na straně 58 (vytištěné číslování). (jasně, je to jenom benchmark, vím)

Mnohojadernost samozřejmě leze i do mobilních zařízení, viz 3/4 nových mobilů je vícejaderných a nic nenasvědčuje k nějaké větší změně.
Tady si asi nerozumíme ve slovu "mnoho". Člověk podle mě není živočich s mnoha nohama stejně jako dvoujaderný proocesor není mnohojaderný. Pokud řeknu mnoho, představuju si něco jako třeba 10, 60 nebo 1000... Chtěl bych vidět, jak by konvenčně napsaný (třeba OOP) program škáloval od jednoho po tisíc vláken...

student

Re:Pár otázek ohledně unixu a programování
« Odpověď #92 kdy: 28. 02. 2013, 16:52:31 »
Tady si asi nerozumíme ve slovu "mnoho". Člověk podle mě není živočich s mnoha nohama stejně jako dvoujaderný proocesor není mnohojaderný.
OT: Podla mna nadpriemerny pocet niecoho (napr. noh u cloveka) staci na to, aby sme povedali, ze ich je mnoho, nie?  ;D

Pokud řeknu mnoho, představuju si něco jako třeba 10, 60 nebo 1000... Chtěl bych vidět, jak by konvenčně napsaný (třeba OOP) program škáloval od jednoho po tisíc vláken...
Dost ide o to, co si predstavujes pod takym programom. Ak si zoberies konvencne napisany program, ktory nejakym sposobom skusa rozne moznosti na styl
for (int i=0; i<VELKA_KONSTANTA; i++) { if (rob_neco(i)) { printf("Hledane cislo je %i!\n", i); }}
tak potom to nemusi byt problem paralelizovat a moze to skalovat pomerne dobre. Naopak, ak sa tam robi z principu sekvencny algoritmus s velkymi zavislostami medzi iteraciami, tak ti nepomoze ziadny jazyk alebo sposob programovania.

Někdo

Re:Pár otázek ohledně unixu a programování
« Odpověď #93 kdy: 28. 02. 2013, 17:07:13 »
Mnohojadernost samozřejmě leze i do mobilních zařízení, viz 3/4 nových mobilů je vícejaderných a nic nenasvědčuje k nějaké větší změně.
Tady si asi nerozumíme ve slovu "mnoho". Člověk podle mě není živočich s mnoha nohama stejně jako dvoujaderný proocesor není mnohojaderný. Pokud řeknu mnoho, představuju si něco jako třeba 10, 60 nebo 1000... Chtěl bych vidět, jak by konvenčně napsaný (třeba OOP) program škáloval od jednoho po tisíc vláken...

Na tohle nemá klasické nebo funkcionální programování ale přeci vůbec žádný vliv! Když budu mít dobře paralelizovatelný algoritmus, pustím si imperativně spoustu threadů (kolik změřím že mi OS efektivně zvládá na daném hardware), rozdám jim práci a posbírám výsledky. Zbývá jen pečlivě hlídat místa kde musím přistupovat ke sdíleným datům z více threadů - ale ani to nemusím vymýšlet, zadám do google "work-stealing algorithm" a opíšu co už za mně vymysleli jiní.

Případně kouknu na http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ForkJoinPool.html a mám ještě méně práce, s radostí zjistím že vše potřebné je už implementované v obyčejné Javě. Žádné funkcionální hype se nekoná!

Re:Pár otázek ohledně unixu a programování
« Odpověď #94 kdy: 28. 02. 2013, 17:20:59 »
Ak si zoberies konvencne napisany program, ktory nejakym sposobom skusa rozne moznosti na styl
for (int i=0; i<VELKA_KONSTANTA; i++) { if (rob_neco(i)) { printf("Hledane cislo je %i!\n", i); }}
tak potom to nemusi byt problem paralelizovat a moze to skalovat pomerne dobre.
To je výborný příklad. Pokud to budeš chtít paralelizovat, musíš to udělat explicitně - přidat tam něco ve stylu "if(fork()...){rob_neco()}" - a pak jeste ty vlakna musis zpatky zesynchornizovat, abys vedel, ze probehlo vsechno.

Funkcionálním stylem uděláš něco jako map(rob_neco(X),List) - a tu paralelizaci máš zadarmo, ten program škáluje sám, bez toho, abys na to myslel. A rovnoměrně vytíží všechny jádra (pokud jich není víc než položek seznamu).

Na tohle nemá klasické nebo funkcionální programování ale přeci vůbec žádný vliv! Když budu mít dobře paralelizovatelný algoritmus, pustím si imperativně spoustu threadů (kolik změřím že mi OS efektivně zvládá na daném hardware), rozdám jim práci a posbírám výsledky. Zbývá jen pečlivě hlídat místa kde musím přistupovat ke sdíleným datům z více threadů
No právě - musíš se rozhodnout, kam paralelizaci explicitně dáš a jak. Oproti tomu software, který je napsaný způsobem, který je sám o sobě "paralelní" (jako jsou Erlangové procesy nebo třeba nějaké ty agenty), škáluje "sám o sobě". Nemusíš ho přepisovat, když ti někdo daruje speciální hw se sto jádry. Prostě vezmeš existující kód, který jsi provozoval na jednojádru a spustíš. (samozřejmě takhle úplně ideálně to fungovat nemusí, ale v principu jo)


Rax

Re:Pár otázek ohledně unixu a programování
« Odpověď #95 kdy: 28. 02. 2013, 18:02:35 »
Prosím v následujícím mě nechytej za slovo: pro mě z praktického hlediska, pokud nebudu nějak moc hledět na teorii, filosofii apod. je funkcionální programování především o tom, jak se pracuje s daty - hlavní koncepcí je omezení/neexistence měnitelných dat. V čistějších formách potom omezení/neexistence funkcí s nedlejším efektem. To potom snadno umožňuje dekompozici na úplně samostatné jednotky, protože neexistují dílená data.

Koncepce neměnitelných dat je validní argument, ale to neimplikuje potřebu funkcionálního programování.
Funkcionální programování je o tom že se algoritmy zapisují naprosto jinak, konkrétně ne jako posloupnost příkazů, ale jako matematické funkce.

Jistěže s tím jsou potíže. Konvenčně napsané programy nemůžou škálovat a neškálují ani zdaleka lineárně k počtu vláken.

Škálování už se více než 10 let nedělá přes velký počet vláken, naopak velké množství vláken přímo znemožňuje škálování, kvůli masivnímu přepínání kontextů úloh. Solidní škálovatelná aplikace používá tak dvě vlákna na jádro.

Funkcionálním stylem uděláš něco jako map(rob_neco(X),List) - a tu paralelizaci máš zadarmo, ten program škáluje sám, bez toho, abys na to myslel. A rovnoměrně vytíží všechny jádra (pokud jich není víc než položek seznamu).

To stejné můžeš mít v C/C++/C#/Java, dokonce Windows to od W2K má přímo v jádře.

Re:Pár otázek ohledně unixu a programování
« Odpověď #96 kdy: 28. 02. 2013, 18:10:32 »
Koncepce neměnitelných dat je validní argument, ale to neimplikuje potřebu funkcionálního programování.
To už je jenom terminologická debata, do které se nepouštím. Říkejme tomu, jak chceme, podle mě způsob programování s neměnnými daty má budoucnost, ať se mu bude říkat jak chce.

naopak velké množství vláken přímo znemožňuje škálování, kvůli masivnímu přepínání kontextů úloh.
Pokud jsou to vlákna OS. Což v Erlangu nejsou.

To stejné můžeš mít v C/C++/C#/Java, dokonce Windows to od W2K má přímo v jádře.
Jistě. I v C se dají používat funkcnionální principy (neměnnost dat, izolované moduly bez přehnaných vzájemných závislostí). Jak říkám: je to terminologická debata a slovíčkaření, které je k ničemu. Pointa je v tom, že současný OOP-styl, kde jakákoli data můžou být referovaná kdekoli, nemusí být do budoucna to pravé ořechové.

Re:Pár otázek ohledně unixu a programování
« Odpověď #97 kdy: 28. 02. 2013, 18:13:45 »
P.S. z toho referování "odkudkoli kamkoli" plynou ještě další nepříjemnosti, např. pro konstrukci GC. V Erlangu každá data můžou referovat jenom do starších dat, což GC výrazně zjednodušuje A mimochodem, tímpádem se - aspoň teoreticky - i GC dá paralelizovat. A o tom to právě je - pokud jazyk vynucuje nějaké chování se k datům, ta paralelizace je najednou úplně jiný příběh...

Rax

Re:Pár otázek ohledně unixu a programování
« Odpověď #98 kdy: 28. 02. 2013, 23:16:34 »

OK budeme se věnovat neměnným datům. S neměnnými daty se to částečně zkoušelo v Javě a že by to mělo nějaký zásadní úspěch jsem si nějak nevšimnul. Neměnná data jsou v přímém rozporu s optimálním cacheováním paměti, kvůli nutnosti furt kopírovat. Nejsem přesvědčen že to tolik pomůže, nutnost neustálého kopírování paměti + overhead při alokaci neustále nových bloků na haldě přínosy spolehlivě zabijí.

podlesh

Re:Pár otázek ohledně unixu a programování
« Odpověď #99 kdy: 28. 02. 2013, 23:35:17 »
Případně kouknu na http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ForkJoinPool.html a mám ještě méně práce, s radostí zjistím že vše potřebné je už implementované v obyčejné Javě. Žádné funkcionální hype se nekoná!
Cože? Přávě že koná! Fork Join je typická ukázka funkcionálního přístupu.

Maximálně to ukazuje že funkcionální paradigma není omezené na "funkcionální jazyky" - což ovšem platí obecně a například i pro OOP.

Re:Pár otázek ohledně unixu a programování
« Odpověď #100 kdy: 01. 03. 2013, 07:18:14 »
OK budeme se věnovat neměnným datům.
Já bych už spíš to OT ukončil :)

Někdo

Re:Pár otázek ohledně unixu a programování
« Odpověď #101 kdy: 01. 03. 2013, 09:15:23 »
OK budeme se věnovat neměnným datům. S neměnnými daty se to částečně zkoušelo v Javě a že by to mělo nějaký zásadní úspěch jsem si nějak nevšimnul. Neměnná data jsou v přímém rozporu s optimálním cacheováním paměti, kvůli nutnosti furt kopírovat. Nejsem přesvědčen že to tolik pomůže, nutnost neustálého kopírování paměti + overhead při alokaci neustále nových bloků na haldě přínosy spolehlivě zabijí.

V Javě není problém používat neměnná data (pokud tedy správně předpokládám že to je český překlad pro immutable objects), ale zásadní výhoda proti striktně funkcionálnímu přístupu je že toto je volitelné. Tento přístup umožňuje programovat efektivně - neměnné mít jen to kde je to výhodné (např. kvůli sdílení mezi thready) a zbytek nechat klasický. Ono klasické funkcionální programování je totiž pro spoustu účelů vysloveně nevhodné (a i neefektivní). Rozumný programátor si vezme to co je pro daný úkol výhodnější.

Někdo

Re:Pár otázek ohledně unixu a programování
« Odpověď #102 kdy: 01. 03. 2013, 09:19:01 »
Případně kouknu na http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/ForkJoinPool.html a mám ještě méně práce, s radostí zjistím že vše potřebné je už implementované v obyčejné Javě. Žádné funkcionální hype se nekoná!
Cože? Přávě že koná! Fork Join je typická ukázka funkcionálního přístupu.

Já vím co je fork join a že je to typická ukázka funkcionálního přístupu. Jen píšu že to není žádné hype, že to jde i v tak zatracovaném (a přesto rozšíženém) jazyce jako je Java - není nutné se uchylovat k Erlangu, Lispu nebo podobým exotickým záležitostem.

Re:Pár otázek ohledně unixu a programování
« Odpověď #103 kdy: 01. 03. 2013, 10:54:54 »
ale zásadní výhoda proti striktně funkcionálnímu přístupu je že toto je volitelné.
Tak to já si myslím přesný opak. Když to řeknu obecně, čím víc omezení na kód kladu, tím silnější tvrzení pak o něm platí. Konkrétně už jsem příklad dával: pokud mám v jazyce *jenom* neměnná data, potom se mi zjednodušší GC, protože o datech s jistotou vím určité věci. Pokud ta omezení jsou volitelná, už o kódu (obecně) neplatí nic víc než co by platilo, pokud by tam ta omezení nebyla vůbec. Čili mi to žádnou výhodu tohodle typu nepřinese.

Někdo

Re:Pár otázek ohledně unixu a programování
« Odpověď #104 kdy: 01. 03. 2013, 11:11:34 »
ale zásadní výhoda proti striktně funkcionálnímu přístupu je že toto je volitelné.
Tak to já si myslím přesný opak. Když to řeknu obecně, čím víc omezení na kód kladu, tím silnější tvrzení pak o něm platí. Konkrétně už jsem příklad dával: pokud mám v jazyce *jenom* neměnná data, potom se mi zjednodušší GC, protože o datech s jistotou vím určité věci. Pokud ta omezení jsou volitelná, už o kódu (obecně) neplatí nic víc než co by platilo, pokud by tam ta omezení nebyla vůbec. Čili mi to žádnou výhodu tohodle typu nepřinese.

Nepřinese to sice žádnou výhodu tohodle typu, ale může to přinést jiné výhody které vše bohatě převáží. Konkrétní příklad: čistě funkcionální List ve Scale má přístup k náhodnému prvku O(n) kde n je délka celého listu, oproti tomu ArrayList v Javě má přístup k náhodnému prvku O(1) neboli nejlepší možný - konstantní. K čemu je mi zjednodušení GC, když se mi zásadním způsobem zhorší efektivnost celého programu (protože zrovna potřebuji často používat ty náhodné přístupy)? Proto si myslím že by mělo být na programátorovi aby volil správné postupy a nenechal se šikanovat tím že mu použitá technologie vnucuje postupy které jsou pro řešení daného problému nevhodné.