Fork me on GitHub
#clojure-poland
<
2016-03-10
>
szymon_k08:03:38

@nooga: vaprowave? podrzuć jakiś youtube simple_smile

szymon_k08:03:31

@jedi: dawno temu słuchałem sporo post-rocków, trochę bardziej w kierunku "GY!BE" może niż "God is..."

jan.zy08:03:59

@szymon_k: ^^

nooga09:03:50

zartowalem ;d

szymon_k09:03:25

serio? mega ciekawa estetyka moim zdaniem

jaen09:03:56

Jak już mówimy o postrzeganiu rzeczywistości to ja się zapisuję do szkoły Kanta — tj. że nie możemy postrzegać rzeczywistości samej w sobie, tylko nasza świadomość zbudowana jest w pewien sposób który pozwala nam doświadczać świata empirycznie i na tej podstawie budować sobie jego jakiś fenomenologiczny obraz. I prawdy samej w sobie nie jesteśmy w stanie nigdy poznać, ale możemy budować sobie coraz lepsze teorie w jakiś sposób ją aproksymujące.

jaen09:03:14

A jak chodzi o muzykę to postrock ma mą okejkę, choć progrock też fajny.

jaen09:03:18

A bardziej programistycznie — Wy tutaj jak bardzo w komponenty?

jan.zy10:03:26

rozsądnie

jan.zy10:03:45

czasem wcale czasem bardzo

jan.zy10:03:47

zrobiłem jedną apkę na componentach sierry i jest to fajowa opcja, ale odnoszę wrażenie, że jeśli by miała być naprawdę duża to szukałbym czegoś innego

jan.zy10:03:50

nie wiem czego simple_smile

jan.zy10:03:26

u sierry jak wstaje ci system i gdzieś skopiesz inicjalizację to dostajesz np. mega gigantyczne error message

jan.zy10:03:35

i weź kmiń co się dzieje

szymon_k10:03:45

no tak, ale to tylko jak popsujesz główny komponent nie?

szymon_k10:03:51

ja jak ustawiałem sobie komponenty jak chciałem

szymon_k10:03:53

to potem tego nie ruszałem

jan.zy10:03:00

którykolwiek

szymon_k10:03:11

a (go) i działa to super sprawa moim zdaniem

szymon_k10:03:21

używałem kilka razy i na razie zostaje przy tym

jaen10:03:21

No ja właśnie mam taki problem, że nie umiem się zdecydować jakie stężenie componenta jest dobre

jaen10:03:48

Przykładowo w mojej inżynierce zrobiłem coś takiego, że są komponenty domenowe udostępniające jakieś handlery i komponenty, nazwijmy to architekturalne, które ze swoich zależności filtrują te interesujące je po jakimś protokole i składają z nich np. jakiś dispatch function czy coś. Przykładowo

jaen10:03:40

Bierze, zbiera, wrzuca do multimetody którą potem dispatchuje

jaen10:03:09

I z jednej strony jest to spoko

jaen10:03:27

Bo jak chcesz dodać nową rzecz to ją piszesz, wpinasz i Shit Just Works™

jaen10:03:41

Ale czuję się prawie jakbym pisał Javę z za dużą ilością nawiasów

jaen10:03:58

I mam wrażenie że to jest z kolei przesada z taką segregacją na komponenty

jaen10:03:55

Zwłaszcza, że wtedy albo a) praktycznie każda funkcja musi dostawać interesujące ją komponenty jako argumenty, albo b) musisz je pisać w ciele defrecord aby się domknąć nad polami.

jaen10:03:58

I tak źle, i tak niedobrze.

jaen10:03:18

No i nie wiem jak to lepiej ogarnąć : F

jan.zy10:03:28

robisz komponent jak potrzebujesz przechować jakiś stan

jan.zy10:03:42

nie robisz komponentu jak nie potrzebujesz trzymać stanu

jaen10:03:54

Okej, to brzmi jak jakaś heurystyka

jaen10:03:59

Tylko się wtedy traci to automatyczne składanie systemu jak tylko dołożysz klocek. Chyba że to overengineering żeby coś takiego robić? Kojarzę że podobno niektórzy używają graph z prismaticowego plumbing do podobnych rzeczy, ale nie mam pojęcia jakby to mogło wyglądać w praktyce.

jaen10:03:12

Dobra architektura jest trudna : |

jan.zy12:03:52

nie heurystyka, komponenty są po to żeby trzymać stan

jan.zy12:03:13

przeczytaj manuala do komponentu s. sierry simple_smile

nooga13:03:56

ja sie przestalem martwic i pokochalem mount

jan.zy14:03:43

oo, obadam przy najbliższej okazji

jaen16:03:38

No ale to jednak jest jakaś heurystyka chyba — jeżeli trzymasz stan, to stwórz komponent. W przeciwnym wypadku nie. Tylko mam wrażenie, że enkapsulacja stanu to nie jedyny zysk z componenta — osobiście możliwość opisania systemu jako grafu zależności w jednym miejscu, z zależnościami i ko-zależnościami, opisania komponentu jako funkcji jego zależności i łatwiej podmiany takiego klocka, wydaje mi się równie przydatna. Całkiem możliwe że te rzeczy można też bez componenta osiągnąć i ograniczyć go tylko do stricte zarządzania stanem, ale nie jestem w tym momencie pewien jak by to można było dokładnie zrobić. Mount niby jest ciekawy, ale jakoś mu nie do końca ufam (ot choćby dlatego, że zależności są implicite w strukturze przestrzeni nazw i nie można mieć kilku instancji takiego komponentu), a nie miałem go okazji spróbować w czymś większym, żeby się przekonać czy słusznie czy nie. Podobnie bounce (https://github.com/jarohen/bounce) wydaje mi się ciekawy, ale też nie miałem okazji go w czymś większym spróbować.

jaen16:03:25

To jest w ogóle trochę śmieszne, że mam z tym problem, bo nie jestem zatwardziałym programistą obiektowym ani nic, ale trochę nie umiem ugryźć jak do tego sensownie podejść.

nooga22:03:57

no to troche wyglada jak obiektowka pozniej

nooga22:03:11

mount jak na razie mnie nie ugryzl

nooga22:03:32

chociaz zdaje sobie sprawe z tradeoffów i różnic między nim a componentem