🚀 go-pugleaf

Fri, 14 Feb 2003 14:04:10 +0100, Michal Przybylek <pkmichal@poczta.onet.pl> pisze:

> Nie wiem o co dokladni pytasz. Byc funkcyjnym nie jest trudno. Najczescie
> wsytarczy skutecznie utrudnic programowanie obiektowe, aby sie nim stac

Nic podobnego. Do programowania funkcyjnego w moim rozumieniu
technicznie potrzeba co następuje (nie liczę integracji z bibliotekami,
tylko same cechy języka):

1. odśmiecania,
2. lokalnych funkcji ze statyczną widocznością identyfikatorów,
   z możliwością przekazywania takich funkcji jako obiekty (w taki
   sposób, że funkcje o danych typach argumentów i wyników mają ten
   sam typ - to jest trywialnie spełnione przez języki z dynamicznym
   systemem typów),
3. sposobu na wyrażenie typów algebraicznych,
4. możliwości opisania dowolnych wyliczanych wartości przez wyrażenie
   (a nie np. tylko instrukcję zapisującą wynik do zmiennej).

Na przykład C utrudnia programowanie obiektowe, ale funkcyjne tym
bardziej - odpada pod każdym względem.

Z języków tradycyjnie uznawanych za niefunkcyjne można programować
funkcyjnie w Rubym, w Perlu, częściowo w Pythonie (trochę brakuje 4),
w Smalltalku...

Z kolei C++, Java i Eiffel rzucają kłody pod nogi (C++ w każdym punkcie,
Java ma 2,3 zamotane, Eiffel dopiero próbuje wprowadzać 2,3,4).

Obiektowość nie ma tutaj wpływu na łatwość/trudność programowania
funkcyjnego.

> zauwaz tez, ze w druga stone to nie zachodzi - tj. wiekszosc
> "jezykow obiektowych" jest wystarczajaco elastyczna, aby mozliwe
> bylo w nich w miare wygodne programowanie funkcyjne]).

Bzdura. Zrób listę z leniwym ogonem w C++, Javie albo Eifflu -
wyjdzie powtorek.

Obiektowość tradycyjnie jest imperatywna i ma to uzasadnienia
techniczne (nie twierdzę, że decydujące). Otóż jeśli obiekty
zwracają swoje zmienione kopie zamiast zmiany stanu w miejscu,
to wysiada dziedziczenie: w podklasach metody zwracają obiekty nie
tej klasy co trzeba.

Chyba że się nagimnastykujemy i damy językowi odpowiednie mechanizmy
kopiowania obiektów z podmianą niektórych pól i pozostawieniu
nieokreślonego zestawu pozostałych bez zmian. Z języków, które znam,
tylko OCaml tak robi. Z tego powodu w językach tradycyjnie obiektowych
styl funkcyjny nie będzie dobrze integrował się z obiektowością.

Z kolei mieszanie stylu funkcyjnego i imperatywnego jest bezbolesne,
o ile nie oczekujemy funkcyjnej czystości. W dobrym języku sprowadza
się do wyboru konwencji używania struktur danych.

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