🚀 go-pugleaf

"Jacek Konieczny" <jajcus@bnet.pl> wrote:

> Język ten wygląda na funkcyjny i zapewne jest funkcyjny, chociaż nigdzie
> w widocznym miejscu tego wyraźnie nie napisali ;-)

Erlang nie mial byc "funkcyjny".

Erlang nie mial byc "zajebisty".

Erlang mial byc brakujacym narzedziem do pewnego rodzaju programowania
wspolbieznego (swoja droga, najsensowniejszy jezyk ostatnich lat).


Funkcyjnosc Erlang'owi dorobiono pozniej. Nie wiem w jakich
okolicznosciach, calkiem mozliwe, ze pod wplywem inteligencji widaomego
folkloru:

"Buuu.... Haskell ma jescze A... Z, Haskell jest zajebistszy !"


mp

Jacek Konieczny <jajcus@bnet.pl> wrote:
> Przymierzam się do przestawienia mojego serwera Jabberowego na ejabberd.
> W tym celu musiałem sobie skompilować Erlanga (http://www.erlang.org/).
> Język ten wygląda na funkcyjny i zapewne jest funkcyjny, chociaż nigdzie
> w widocznym miejscu tego wyraźnie nie napisali ;-)
> Najciekawsze jego możliwości to chyba możliwość tworzenia programów, czy
> właściwie systemów rozproszonych i współbieżnych -- nie dziwne, że ktoś
> to wybrał do tworzenia serwera Jabbera, najprawdopodobniej
> najpoważniejszego z tych Open Source aktualnie dostępnych.
> 
> Zna ktoś? Używa ktoś? Jakie wrażenia?
	... pewnie wszystcy uzywamy:) Jest tego kupe w sprzecie
telekomunikacyjnym ericksona:) Podobno mozna na tym robic nawet 
rozwiaznia Real Time bo jakos odsmiecanie ma odpowienio zrobione.
Przyznam, nie znam tego jezyka:( Z powazaniem
								Adam Przybyla

"Michal Przybylek" <pkmichal@poczta.onet.pl> writes:

> Erlang nie mial byc "funkcyjny".

Mylisz się, od początku miał mieć taki charakter jak ma. Prawda, że
lambdy dodano stosunkowo niedawno, ale to drobiazg.

http://www.erlang.org/course/history.html

"1982 - 1985
Experiments with programming of telecom using > 20 different
languages. Conclusion: The language must be a very high level symbolic
language in order to achive productivity gains ! (Leaves us with:
Lisp, Prolog, Parlog ...)

1985 - 86
Experiments with Lisp,Prolog, Parlog etc. Conclusion: The language
must contain primitives for concurrency and error recovery, and the
execution model must not have back-tracking. (Rules out Lisp and
Prolog.) It must also have a granularity of concurrency such that one
asyncronous telephony process is represented by one process in the
language. (Rules out Parlog.) We must therefore develop our own
language with the desirable features of Lisp, Prolog and Parlog, but
with concurrency and error recovery built into the language.

1987
The first experiments with Erlang."

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

"Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> wrote:

> > Erlang nie mial byc "funkcyjny".
>
> Mylisz się, od początku miał mieć taki charakter jak ma.

Nie rozumiem, w ktorym miejscu cytowany przez Ciebie fragment przeczy temu
co napisalem.

Nie rozumiem, po raz kolejny, zwiazku Twoich argumentow z konkluzja. Nie
rozumiem, na co mialo zwracac uwage zdanie:

> Prawda, że lambdy dodano stosunkowo niedawno,
> ale to drobiazg.

ktore w mysl Twoich poprzednich definicji "funkcyjnosci" zdaje sie dokladnie
potwierdzac to, ze Erlang nie byl "funkcyjny".


mp

ps. Swoja poprzednia wypowiedz oparlem, na przeczytanym kiedys artykule
tworcow Erlang'u, w ktorym omawiali swoje "design principles" i IIRC jednym
z glownych punktow, bylo to, aby nie wprowadzac mechanizmow, ktore, ich
zdaniem, nie sa niezbedne. Jednym z owych mechanizmow byly wlasnie
domkniecia funkcji (i kilka innych udogodnien znanych z jezykow
funkcyjnych)...

Michal Przybylek wrote:
[..]

Z Twojego posta wynika (dla mnie), ze masz problemy z rozumieniem 
otaczajacej Cie rzeczywistosci. Lubisz na sile rozumiec rzeczy po 
swojemu. Sprawia Ci to pewnie jakis rodzaj przyjemnosci. Nawet nie 
chodzi o to czy masz racje czy nie..

-- 
Przemek Wiśniewski

"Przemek Wiśniewski" <ja@fasdfasdf.cx> wrote:

> Z Twojego posta wynika (dla mnie), ze masz problemy z rozumieniem
> otaczajacej Cie rzeczywistosci. Lubisz na sile rozumiec rzeczy po
> swojemu. Sprawia Ci to pewnie jakis rodzaj przyjemnosci. Nawet nie
> chodzi o to czy masz racje czy nie..

Nie rozumiem...


mp

Michal Przybylek wrote:
> "Przemek Wiśniewski" <ja@fasdfasdf.cx> wrote:
> 
> 
>>Z Twojego posta wynika (dla mnie), ze masz problemy z rozumieniem
>>otaczajacej Cie rzeczywistosci. Lubisz na sile rozumiec rzeczy po
>>swojemu. Sprawia Ci to pewnie jakis rodzaj przyjemnosci. Nawet nie
>>chodzi o to czy masz racje czy nie..
> 
> 
> Nie rozumiem...

No wlasnie widac..

-- 
Przemek Wiśniewski

Dnia Tue, 31 Aug 2004 16:09:00 +0200, Michal Przybylek skrobie:
> "Marcin 'Qrczak' Kowalczyk" <qrczak@knm.org.pl> wrote:

>> > Erlang nie mial byc "funkcyjny".
>>
>> Mylisz się, od początku miał mieć taki charakter jak ma.

> Nie rozumiem, w ktorym miejscu cytowany przez Ciebie fragment przeczy temu
> co napisalem.

Na przykład ten, w którym podawano przykłady języków, na których zamierzają
się w opracowaniu Erlanga opierać. Poza tym, jak się przyjrzałem, język ten ma
dość zbliżony do nich charakter - chyba że w programowaniu funkcyjnym jest
dokładnie to samo, co w obiektowym: każdy co innego przez to rozumie, inny
zestaw cech, język który którejś z tych cech nie posiada nie jest naprawdę
funkcyjny itd.

> ps. Swoja poprzednia wypowiedz oparlem, na przeczytanym kiedys artykule
> tworcow Erlang'u, w ktorym omawiali swoje "design principles" i IIRC jednym
> z glownych punktow, bylo to, aby nie wprowadzac mechanizmow, ktore, ich
> zdaniem, nie sa niezbedne. Jednym z owych mechanizmow byly wlasnie
> domkniecia funkcji (i kilka innych udogodnien znanych z jezykow
> funkcyjnych)...

No więc chodzi o cechy pożądane, czy cechy dodatkowe? Które z cech dodatkowych
faktycznie determinują programowanie "funkcyjne"? Nie oszukujmy się - lambda
stanowi jedynie skrócenie zapisu, a "domknięcia", cecha wymagana w przypadku
istnienia funkcji lokalnych, to tylko bindowanie wartości. Można powiedzieć,
"mała rzecz, a cieszy". :)


-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethourhs(O)wp.pl>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx

"Sektor van Skijlen" <ethouris@pl.spamu.lubie.nie.wp.invalid> wrote:

> >> > Erlang nie mial byc "funkcyjny".
> >>
> >> Mylisz się, od początku miał mieć taki charakter jak ma.
>
> > Nie rozumiem, w ktorym miejscu cytowany przez Ciebie fragment przeczy
> > temu co napisalem.
>
> Na przykład ten, w którym podawano przykłady języków, na których
> zamierzają się w opracowaniu Erlanga opierać.

Czy byli byscie, w koncu, uprzejmi przedstawic rozumowanie, ktore pozwolilo
wam wykonkludowac z przedstawianych "argumentow" teze ? Na razie nie ma
_jakiegokolwiek_ rozumowania. Jest kilka zdan okraszonych wnioskiem (BTW: z
wymienionych jezykow najblizej Erlang'owi do Prolog'u i Parlog'u, ktore to
jezyki "funkcyjne" raczej nie sa ; czy z faktu, ze Erlang byl oparty na
Prolog'u mozna wywnioskowac, ze Erlang mial byc "logiczny" ? czy, moze,
tylko "funkcyjnosc" jest jakas diabelnie zarazliwa skaza, ktora zakaza przy
najmniejszym nawet zetknieciu... ?).

Nie chodzi mi tu o "czepianie sie". Po prostu dyskusja w ten sposob ma
znamiona ostrego skurwysynstwa - pozwala na manipulowanie faktami i
przeforsowywanie tez przy pomocy wlasnej przewagi w intelekcie/wiedzy.


Coraz rzadziej czytuje juz grupy dyskusyjne i chyba przestane je czytywac w
ogole...

> Które z cech dodatkowych faktycznie determinują programowanie "funkcyjne"?

Moim zdaniem - zadne. To Qrczaka twierdzi, ze cechy jezykowe moga
determinowac "funkcyjnosc".

Jakies 3 lata temu definiowalem (zdaje sie, tutaj) "jezyk funkcyjny" jako
jezyk wspierajacy "paradygmat programowania funkcyjnego". Przez "paradygmat
programowanie funkcyjne" rozumialem paradygmat, w ktorym dekomponuje sie
problem za pomoca matematycznych funkcji. Okazalo sie, ze jestem oszolomem,
bo przecierz, oczywiscie, "jezyk funkcyjny" to taki jezyk, ktory ma
leksykalne domkniecia funkcji, dobre odsmiecanie, wygodna skladnie (np. nie
trzeba czesciowych wynikow pamietac w zmiennej, a mozna bezposrednio
przekazywac dalej), jest deklaratywny, itd...


mp

"Michal Przybylek" <pkmichal@poczta.onet.pl> writes:

> (BTW: z wymienionych jezykow najblizej Erlang'owi do Prolog'u
> i Parlog'u,

Nie powiedziałbym, że jest tak podobny do Prologu; najwyżej składniowo
i w nieznaczących drobiazgach (przeciążanie funkcji według arności).

Nie stosuje ani nawracania, ani niezwiązanych zmiennych jako elementów
termów. A to są właśnie najistotniejsze cechy, które różnią Prolog od
innych języków. Erlang ma model obliczeń gorliwych języków funkcyjnych:
obliczanie wyrażeń zawierających m.in. aplikacje funkcji, wzbogacony
tylko o wątki.

Te algorytmy zapisane w Prologu, które nie są transliteracją algorytmu
z programowania funkcyjnego pierwszego rzędu (z termami, czyli typami
algebraicznymi, ale bez funkcji wyższych rzędów), nie przekładają się
bezpośrednio na Erlang. Te, które są, oczywiście się przekładają, bo
używają tylko najmniejszego wspólnego mianownika programowania
deklaratywnego.

> Jakies 3 lata temu definiowalem (zdaje sie, tutaj) "jezyk funkcyjny"
> jako jezyk wspierajacy "paradygmat programowania funkcyjnego". Przez
> "paradygmat programowanie funkcyjne" rozumialem paradygmat, w ktorym
> dekomponuje sie problem za pomoca matematycznych funkcji.

Ja przez "programowanie funkcyjne" rozumiem paradygmat, w którym
wartości są zazwyczaj immutable. Erlang to spełnia.

Drugą cechę, używanie funkcji jako wartości, też spełnia, choć kiedyś,
o ile pamiętam, nie pozwalał na lokalne funkcje.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

Michal Przybylek wrote:

> Jakies 3 lata temu definiowalem (zdaje sie, tutaj) "jezyk funkcyjny" jako
> jezyk wspierajacy "paradygmat programowania funkcyjnego". Przez "paradygmat
> programowanie funkcyjne" rozumialem paradygmat, w ktorym dekomponuje sie
> problem za pomoca matematycznych funkcji. Okazalo sie, ze jestem oszolomem,
> bo przecierz, oczywiscie, "jezyk funkcyjny" to taki jezyk, ktory ma
> leksykalne domkniecia funkcji, dobre odsmiecanie, wygodna skladnie (np. nie
> trzeba czesciowych wynikow pamietac w zmiennej, a mozna bezposrednio
> przekazywac dalej), jest deklaratywny, itd...

To zalezy jak na to spogladasz, dla Qrczaka, ktorego interesuje 
implementacja kompilatora beda sie liczyc wlasnie domkniecia, 
odsmiecanie itp. Ciebie interesuja matematyczne definicje. W sumie obaj 
macie racje. Tego nie potrafisz przelknac.

Negujac jego argumenty odrywasz sie od rzeczywistosci, bo wiekszosc 
kompilatorow/interpreterow jezykow uwazanych za funkcyjne ma odsmiecanie 
i domkniecia. Nie jest w zadnej madrej ksiazce napisane, ze jezyk 
funkcyjny musi miec takie cechy, ale malo jest chetnych do 
"dekomponowania problemu za pomoca matematycznych funkcji" w jezykach 
nie uwazanych za funkcyjne, bo to jest poprostu nienaturalne.

Wydaje mi sie, ze probojesz walczyc z wiatrakami.

-- 
Przemek Wiśniewski