Witam

Od jakiegoś czasu programuje w językach obiektowych/imperatywnych. Z typowej
matematyki znam pewnie arytmetykę: mnożenie, dzielenie, potęgowanie,
pierwiastkowanie, podstawy logiki, pamiętam co to funkcja liniowa :) W zasadzie nigdy
żadne zaawansowane zagadnienia matematyczne nie były mi w trakcie programowania w
PHP, czy Javie potrzebne.

No i naszła mnie chęć na naukę jakiegoś języka funkcyjnego, zmianę paradygmatu.
Pewnie postawię na F#, bo jest open source, dostępny na Linuksa/Windows/MacOSX i nie
jest tak "ortodoksyjny" jak Haskell. Zastanawiam się teraz, czy żeby sprawnie poznać
te języki, faktycznie powinienem ogarniać matematyczny rachunek lambda, matematyczne
przekształcanie, "zwijanie" i "rozwijanie" funkcji itd? Zakładając że nie będę
zajmował się "optymalizacją algorytmów" czy stricte matematycznymi zagadnieniami, a
po prostu programowaniem użytkowym?

Zasadniczo jak się spojrzy na różne książki/przykłady, to lambda jest w zasadzie
funkcją anonimową, a zwijanie funkcji (currying) w językach funkcyjnych - to w
zasadzie przekształcenie funkcji, która przyjmuje wiele argumentów, na taką która
zwraca 1 argument. Ot najprostszy przykład:

max 4 5
(max 4) 5

Wiadomo że trzeba zmienić podejście w myśleniu o strukturach danych, ale czy Waszym
zdaniem osoba która chce programować w takim F#, OCaml czy Haskellu powinna wziąć
korki z matmy i poznać dobrze np. wspomniany rachunek lambda w matematyce?

P.
Paweł

do góry

> Zastanawiam się teraz, czy żeby sprawnie poznać te języki, faktycznie powinienem
ogarniać matematyczny rachunek lambda, matematyczne przekształcanie, "zwijanie" i
"rozwijanie" funkcji itd?

Nie potrzeba znać rachunku lambda, żeby zrozumieć wyjaśnienia i przykłady z
podręcznika czy tutoriala do konkretnego języka programowania. Tak samo jak nie
trzeba znać teorii funkcji z matematyki, żeby zrozumieć, jak działają funkcje w
programowaniu. Ta teoria nawet nie zawsze pomaga, nie mówiąc o tym, że nie zawsze
teoria z lat 50'tych pasuje 1:1 w pojęcia zaimplementowane w konkretnym dzisiejszym
języku.

> Zasadniczo jak się spojrzy na różne książki/przykłady,

Tak. Oprócz lambdy zainteresuje Cię jeszcze taka koncepcje jak domknięcie (zwłaszcza
tzw. upward closure), bo i tak często lambdę robi się właśnie po to, żeby zrobić
domknięcie. Ale pewnie widziałeś już jakiś przykład w tych podręcznikach. Co ciekawe,
domknięcie nie jest pojęciem matematycznym, tylko raczej implementacyjnym i związanym
z zakresem widoczności symboli oraz czasem ich życia, co tym bardziej pokazuje, że
nie ma po co się zbytnio rozwodzić nad "czystą" teorią, bo ostatecznie to nie czysta
teoria wykonuje program.

> ale czy Waszym zdaniem osoba która chce programować w takim F#, OCaml czy Haskellu
powinna wziąć korki z matmy

Obstawiam, że skoro zainteresowałeś się tym tematem, to mógłbyś korki z matmy dawać a
nie brać. :-)

BTW - bardzo ciekawym językiem z tych okolic (tzn. z zacięciem matematycznym) jest
Wolfram:

http://www.wolfram.com/language/video.html

W szczególności w temacie:

http://reference.wolfram.com/language/guide/Function
alProgramming.html

--
Maciej Sobczak * http://www.inspirel.com

do góry

W dniu środa, 18 stycznia 2017 14:46:18 UTC+1 użytkownik Maciej Sobczak napisał:
> > Zastanawiam się teraz, czy żeby sprawnie poznać te języki, faktycznie powinienem
ogarniać matematyczny rachunek lambda, matematyczne przekształcanie, "zwijanie" i
"rozwijanie" funkcji itd?
>
> Nie potrzeba znać rachunku lambda, żeby zrozumieć wyjaśnienia i przykłady z
podręcznika czy tutoriala do konkretnego języka programowania. Tak samo jak nie
trzeba znać teorii funkcji z matematyki, żeby zrozumieć, jak działają funkcje w
programowaniu. Ta teoria nawet nie zawsze pomaga, nie mówiąc o tym, że nie zawsze
teoria z lat 50'tych pasuje 1:1 w pojęcia zaimplementowane w konkretnym dzisiejszym
języku.


Wielkie dzięki. Również za link do Wolframa, bo wygląda to nieziemsko (szczególnie w
zakresie wizualizacji danych, pracy z tablicami itd). Właśnie szukam czegoś "innego"
niż typowy język z którym pracuje na co dzień, trochę dla sportu, a trochę dla
własnego rozwoju.

Zapytałem o tę matematykę, bo znajomy który pisał swojego czasu sporo w Prologu
(komercyjne tematy, używał do tego Sicstusa), powiedział mi kiedyś, że żeby w takim
Prologu w ogóle sensownie podejść do zamodelowania jakiegoś problemu (co często jest
już półmetkiem implementacji), to bez dobrej znajomości rachunku predykatów i dobrego
"czucia" algorytmów z teorii grafów, nie ma co się nawet do tego zabierać, bo można
się utopić. Nie wiem jak jest z Prologiem, ale pomyślałem - że może bez znajomości
matematycznego rachunku lambda i matematycznego "składania funkcji", po prostu będę
miał problem z językami funkcyjnymi i wyczuciem "kiedy i jak" taką funkcję złożyć,
jak coś zdekomponować na zestaw funkcji itd...

pozdrawiam
Paweł

do góry