Názory k článku Erlang: návrhové vzory procesů
-
Pavel TišnovskýZlatý podporovatelObavám se, že na některých školách se stále ze setrvačnosti učí, že OOP je to pravé a jedině řešení všech problémů v IT :-/ (kupodivu se už moc nerozvádí, co to vlastně OOP znamená a jak souvisí a nesouvisí s jinými paradigmaty).
-
Karel (neregistrovaný)
Dobrá zpráva je, že se to učí špatně. S opravdu "objektově orientovanými" vývojáři se setkávám výjimečně. Většina naštěstí používá objektové metodiky jen jako formu strukturovaného kódu.
Slovy našeho učitele: spaghetti kód se čte blbě, ale dá se to vytisknout a vzít si ssebou do autobusu. Objektový kód se číst nedá vůbec, tam potřebujete mapu, buzolu, intuici a kapku štěstí. Ostatně nejpoužívanější funkcí IDE pro objektové jazyky je klik na název metody, který vás přenese k její definici nebo deklaraci. Jako deklarace rozhraní je OOP výborné, ale na implementaci aplikační logiky je to horší.
-
qweett (neregistrovaný)
tym som len chcel povedat, ze pre oo cloveka je to celkom sok. sam by som si erlang chcel skusit ale zo zaciatku je najma ta syntax bariera. zo zaciatku som sa chytal ale tento diel som nedal. neviem ako mam ten kod citat. najma atomy a premenne sa mi zlievaju dokopy kedze sa lisia len prvym pismenom. pre autora to je pohoda kedze do toho pozera denne a asi sa na to da zvyknut ale teda, taky modul procesu by som pisal asi tri dni.
-
Inkvizitor (neregistrovaný)
OK, asi jsem se trochu unáhlil - pochopil jsem to jako kritiku a dost nekonkrétní. Já v Erlangu nedělám, ale párkrát jsem na něj nahlížel a mě ten kód problém moc nedělá - naopak jsem na těch příkladech dost věcí pochopil. Další věc je, že některé věci jako pattern matching znám z jiných jazyků, takže jsem měl tu bariéru menší i z tohoto důvodu.
-
qweett (neregistrovaný)
napr. mi dlho trvalo kym som si zvykol na to ze ten recieve je blokujuci a tak sa teda aj kontroluje beh toho kodu, trocha ma myli pouzitie self() lebo neviem ake self sa mysli ... to sa trochu tazsie vysvetluje. ono to dava zmysel ked to chce clovek fakt pochopit ale teda ... uff :)
este nechapem jednu vec, napr start bere LockName a potom sa priradi do Initparams = [LockName] a preda sa to init-u cez spawn, init bere [InitParams]. otazka je, preco nemoze init zobrat rovno ten atom a preco musi brat list? je to preto, ze mozem potencialne inicializovat proces viacerymi hodnotami a to teda vedie na list?
-
Alois Vitásek (neregistrovaný)
Tyto příklady měly být přípravou na to jak se tyto úlohy programují pomocí knihoven. Což je způsob, jak se to doopravdy dělá. Ukázat jak se daná myšlenka napíše čistě jen v Erlangu, aby bylo všechno jasně vidět a v další fázi si na obecnou část vzít z knihovny a jen napsat aplikační logiku (inicializace, obsluha událostí, terminace, uživatelské API) co se volá pomocí callbacků (stejně jako funkce z modulu handler1).
K InitParams - v knihovnách má funkce init jen jedne parametr a je potřeba jím procpat vše co je potřeba (obvykle více hodnot). Dá se tam dát n-tice, struktura (o tom ještě bude řeč) nebo se často používá pole. V tomto případě jsem použíl pole (čistě jen ze zvyku) k přenesení jedné hodnoty. To je nadbytečná operace daná zvykem, ale přibližje to způsob, jak se to dělá v praxi (aspoň myslím).
-
> paradoxne lze na erlang nahlizet jako na nejcistsi podobu OOP vubec :)
Presne! Teda respektive nejsem si uplne jisty, jestli "nejcistsi", ale urcite "jednu z cistych" :)
A Armstrong se te myslence ani nijak zvlast nebrani:
http://www.infoq.com/interviews/johnson-armstrong-oop
Problem je, ze C++ OOP tak zprasilo, ze dneska si vsichni mysli, ze OOP=hlavne dedicnost, pritom OOP=hlavne posilani zprav :) Bohuzel se to zakorenilo a i se to tak uci, takze OOP slo pomalu ale jiste do kopru... A pritom treba v podobe Smalltalku to vubec nebylo spatny.
-
Inkvizitor (neregistrovaný)
Nevím, zda to v seriálu padlo, ale jestli to chápu správně, je vzájemné rekurzivní volání (např. free a locked) díky tail call optimalizaci bezproblémové (nehrozí přetečení zásobníku apod.). To si myslím, že je pro programátory z mainstreamu dost podstatná informace.
Každopádně díky za seriál, líbí se mi.
-
Alois Vitásek (neregistrovaný)
Děkuji za doplnění. To že nekonečná smyčka pomocí rekurze není problém (stack neroste), pokud je rekurzivní volání jako poslední operace bylo zmíňeno jen v úvodním článku. Zde se navíc volají dvě funcke mezi sebou. To není podstatné, princip je stejný, tzv. tail rekurze tu funguje také.
Stack neroste, protože všechny proměnné jsou lokální, volání dalši funkce (ať už stejné nebo jiné) je poslední operace, takže není důvod lokální proměnné udržovat na stacku pro další využití.
-
klusacek (neregistrovaný)
V uvodu k obsluze udalosti se pise ze na jednu udalost muze byt registrovano vice handleru, ktere se pak volaji v poradi v jakem byly registrovany.
Kdyz se ale podivam na funkce handle_event_handlers(...) a handle_request ({register_hander, HandlerMod, InitData}, StateData), tak se nemuzu ubranit pocitu ze se volaji v poradi presne opacnem....
ČLÁNKY DO MAILU