🚀 go-pugleaf

On Sun, 6 Apr 2003 22:03:29 +0200, Aleksander Motyka wrote:
> Kiedy możemy powiedzieć, że programowanie jest funkcyjne albo że język jest
> funkcyjny?

To dość niefortunne pytanie --- definicję każdy ma taką jaka mu
pasuje.  Generalnie w programowaniu funkcyjnym wykonanie programu
jest mniej więcej obliczaniem wartości określonych wyrażeń,
a języki funkcyjne traktują funkcje jako pełnoprawne obiekty,
tzn. takie, które mogą być dynamicznie tworzone, przekazywane
do funkcji i zwracane z funkcji.


-- 
<>> kristof@swissmail.org <Krzysztof Parzyszek>    9/2/2002
<<> "If you can't convince them, confuse them" -- HS Truman

"Aleksander Motyka" <Aleksander.Motyka@interia.pl> wrote:

> Kiedy możemy powiedzieć, że programowanie jest funkcyjne albo że język
> jest funkcyjny?

To dosc niefortunne pytanie - definicje kazdy ma taka jaka mu pasuje.
Podobnie niefortunnym pytaniem jest pytanie o wyzszosc paradygmatu/jezykow
funkcyjnych nad obiektowymi. Fakt zas, ze:

a) jezyki funkcyjne to takie, ktore maja:
- pozadny odsmiecacz,
- wygodne leksykalne domkniecia funkcji,
- silny system typow (najczesciej statyczny),
- zwiezla i wygodna skladnie,

b) programy pisane w jezykach funkcyjnych sa duzo krotsze, mniej podatne na
bledy i latwiejsze w utrzymaniu, niz odpowiadajace im wersje obiektowe,

c) w jezykach funkcyjnych szybko podczas kodowania wychodzi zle zrozumienie
problemu,

d) jezykom obiektowym brakuje wielu mechanizmow, dostepnych w jezykach
funkcyjnych.

e) jezyki funkcyjne sa tak zadko uzywane w praktyce, bo:
- ludzie kierujacy projektami sa niedoksztalceni (lub po prostu glupi),
- Microsoft i Sun uknuly przeciwko nim spisek i inwestuja miliony dolcow w
promocje jakichs wlasnych gniotow.


mp

Użytkownik "Michal Przybylek" <pkmichal@poczta.onet.pl> napisał w wiadomości
news:b6v4v3$kqv$1@nemesis.news.tpi.pl...
> a) jezyki funkcyjne to takie, ktore maja:
> - pozadny odsmiecacz,

Nie wiem czy _wszystkie_ JF* maja - ale zapewne nie jest to cecha
ktora stanowi o rodzaju jezyka.
* - jezyki funkcyjne

> - wygodne leksykalne domkniecia funkcji,
> - silny system typow (najczesciej statyczny),
> - zwiezla i wygodna skladnie,
>
Rodzaj skladni takze nie jest zadnym wyroznikiem.

> b) programy pisane w jezykach funkcyjnych sa duzo krotsze, mniej podatne
na
> bledy i latwiejsze w utrzymaniu, niz odpowiadajace im wersje obiektowe,
>
Czy aby na pewno _zawsze_ sa krotsze (ze o 'duzo' nie wspomne)? Watpie.

> c) w jezykach funkcyjnych szybko podczas kodowania wychodzi zle
zrozumienie
> problemu,
>
??? Mozna jasniej - co niby sprawia ze tak sie dzieje?

> d) jezykom obiektowym brakuje wielu mechanizmow, dostepnych w jezykach
> funkcyjnych.
>
Poprosze o jakies konkretne przyklady.

> e) jezyki funkcyjne sa tak zadko uzywane w praktyce, bo:
> - ludzie kierujacy projektami sa niedoksztalceni (lub po prostu glupi),
> - Microsoft i Sun uknuly przeciwko nim spisek i inwestuja miliony dolcow w
> promocje jakichs wlasnych gniotow.
>
Oczywiscie przesadzasz mowiac o glupich projektantach
i o spisku ale faktem jest ze JF sa bardzo rzadko wykorzystywane
w profesjonalnych projektach. A bierze sie to stad ze o
ich istnieniu wie zbyt malo osob - wszyscy wiemy czego ucza
na uczelniach. No i ten nieszczesny mit ze C/C++ jest dobre
do wszystkiego - az przykro sluchac.
Wracajac jeszcze do sedna sprawy - mysle ze Krzysztof
byl blizszy prawdy piszac o cechach jakie posiadaja JF.
Dla potwierdzenia tej tezy proponuje przeczytac FAQ grupy
comp.lang.functional - punkt 2.1.
Pozdrawiam,
soovack
--
"Komputer to nic innego jak taki bardzo sprawny idiota."
(Hugo Steinhaus)

On Sun, 06 Apr 2003 22:03:29 +0200, Aleksander Motyka wrote:

> Kiedy możemy powiedzieć, że programowanie jest funkcyjne albo że język
> jest funkcyjny?

Moje kryterium techniczne funkcyjnego stylu:

1. Praca na wartościach niezmiennych w czasie i stałych wiązaniach nazw do
   obiektów, a nie obiektach ze zmieniającym się stanem ani zmieniających
   się zmiennych.

2. Traktowanie funkcji jako obiektów, w tym lokalnych funkcji odwołujących
   się do lokalnego środowiska z miejsca swojej definicji.

Język funkcyjny to język, w którym można łatwo programować w funkcyjnym
stylu. (Z tradycyjnie uznawanych za niefunkcyjne dobrze sprawuje się na
przykład Ruby.)

Reszta to konsekwencje. Na przykład odśmiecanie jest konieczne, żeby jedno
i drugie działało. To, że wynik funkcji zależy tylko od wartości
argumentów, jest konsenwencją tego, że nie ma od czego innego zależeć.
Typy algebraiczne nie są konieczne (Lisp ani Erlang nie mają), ale są
częste, bo to narzucający się sposób reprezentacji danych. Listy w stylu
Lispa są powszechne. Statyczny system typów jest częstszy niż przy
innych językach, bo systemy typów dla takich języków są dużo łatwiejsze
do zaprojektowania.

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

In article <b6v4v3$kqv$1@nemesis.news.tpi.pl>, Michal Przybylek wrote:
> a) jezyki funkcyjne to takie, ktore maja:
> - pozadny odsmiecacz,
co to ma do funkcyjności języka?

> - wygodne leksykalne domkniecia funkcji,
tego po prostu nie rozumiem

> - silny system typow (najczesciej statyczny),
jakoś łatwo mogę sobie wyobrazić język funkcyjny ze słabym typowaniem,
więc to też żaden wyróżnik

> - zwiezla i wygodna skladnie,
tu też może być różnie

Rozumiem, że to miało brzmieć: mój ulubiony język funkcyjny ma
następujące cechy: ....

Pozdrowienia,
        Jacek

> Czy aby na pewno _zawsze_ sa krotsze (ze o 'duzo' nie wspomne)? Watpie.

powiedziałbym że zawsze są <= niż w innych językach
a w wielu przypadkach to "dużo" jest bardzo uzasadnione - 
im większy projekt, tym większa owa różnica

> 
>> c) w jezykach funkcyjnych szybko podczas kodowania wychodzi zle
> zrozumienie
>> problemu,
>>
> ??? Mozna jasniej - co niby sprawia ze tak sie dzieje?

to, że programy w językach funkcyjnych są "bliższe" matemetycznych
definicji problemów i algorytmów. Często pisząc w C skupiasz się
na szczegółach implementacji struktur danych (aha, jak przeniosłem
ten węzeł tutaj, to teraz ten wskaźnik przepisuję tutaj, a o tym 
zapominam... a może odwrotnie...), zamiast na istocie problemu
Poza tym im bardziej algorytm jest do ogranięcia wzrokiem, tym
lepiej się go analizuje i znajduje błędy. 

> 
>> d) jezykom obiektowym brakuje wielu mechanizmow, dostepnych w jezykach
>> funkcyjnych.
>>
> Poprosze o jakies konkretne przyklady.

let change_units_positions by_vector make_also_update =
  let move_by_vector = move by_vector in
  let process_function =
    if make_also_update then
      fun x -> (move_by_vector x; update x)
    else 
      fun x -> update x
  in
    List.iter process_function units_list;;

mam na myśli przede wszystkim tworzenie funkcji ze złożeń
innych funkcji, otrzymując nowy algorytm 

> ich istnieniu wie zbyt malo osob - wszyscy wiemy czego ucza
> na uczelniach. No i ten nieszczesny mit ze C/C++ jest dobre
> do wszystkiego - az przykro sluchac.
> Wracajac jeszcze do sedna sprawy - mysle ze Krzysztof
> byl blizszy prawdy piszac o cechach jakie posiadaja JF.

absolutnie się zgadzam


-- 
nazgul - Wroclaw University - computer science student