W dniu piątek, 25 sierpnia 2017 16:04:09 UTC+2 użytkownik Adam M napisał:

> To jest przyklad tzw. magicznego myslenia - napisze program
> w Erlangu (to nic ze dziadowski algorytm i jest tylko jedno-watkowy)
> ale uruchomie go na 16-to rdzeniowym procesorze i to spowoduje
> magiczne ulepszenie algorytmu i 16-kroty przyrost predkosci.

To jest przykład tzw. programowania deklaratywnego, w którym
mówisz komputerowi co chcesz mieć, a nie -- jak chcesz to
uzyskać, dzięki czemu twórcy narzędzi uruchomieniowych mają
dużo większą swobodę w interpretacji twojego programu.

> > > Jeśli kolega zadaje takie pytanie to tutaj jest link który
> > > może się przydać aby zrozumieć za automatyczne zwalnianie
> > > i odśmiecanie nie zawsze jest dobrym rozwiązaniem:
> > > https://www.dynatrace.com/resources/ebooks/javabook/
impact-of-garbage-collection-on-performance/
> >
> > problem z tą lekturą jest taki, że niewiele z niej wynika.
> > proponuję zerknąć np, tutaj
> > https://scholarship.rice.edu/bitstream/handle/1911/1
6127/8900220.PDF?sequence=1&isAllowed=y
> > albo tu
> > https://www.scss.tcd.ie/Lucy.Hederman/LHMScDissertat
ion.pdf
> > albo tu
> > http://www.pipeline.com/~hbaker1/Share-Unify.html
> > albo tu
> > https://pdfs.semanticscholar.org/5fe3/c770c0dfbb05a1
6fe1b969678c8ee3b1a461.pdf
> >
> > zasadniczo możliwością, którą brak automatycznego odśmiecania
> > przed Tobą otwiera, jest możliwość robienia wycieków pamięci.
>
> Nie uwazam że ośmiecanie jest całkowicie złe - w wielu
? przpadkach daje bezpieczeństwo (zwłaszcza niedoświadczonym
> programistom). Moim nawi ększym problemem jest podejście
> wszystko albo nic do automatycznego zwalniania pamięci
> i odśmiecania - zabiera to wolnosc programiscie w decydowaniu
> jak program ma sie zachowywac.

Tzn. czy ma mieć wyciek pamięci, czy nie mieć?