Czy byłoby dobrze, gdybym zdecydował się napisać cały mój Ruby tak, jakby to był Haskell?

10

Biorąc pod uwagę, że Ruby ma wbudowane dobre funkcje operacji na liście - redukuj, mapuj, zaznaczaj, zbieraj itp. Ma Procs, Blocks i Lambdas i ma ładne wsparcie iteracji ( eachrodzina), czy byłbym złą decyzją projektową, jeśli spróbuję napisać wszystkie moje ruby w jak najbardziej funkcjonalny sposób? Czy jest to szczególnie przydatne w przypadku kodu, który ma niewielką liczbę operacji wejścia / wyjścia (lub mniej takich efektów ubocznych)?

Uczyłem się Haskell (zwanego „prawdziwym” językiem hakera) i jestem zakochany w tym, jak to robić - uwielbiam Ruby, ale myślę, że może być jeszcze fajniej, gdy napłynie do niego więcej ducha Haskell (cóż, nie Ruby przede wszystkim pożycza / uczy się dużo?)

Konstruktywne wskazówki są mile widziane ...

ruby haskell functional-programming

— nemesisfixx
źródło

13

Dlaczego więc nie napisać po prostu w języku Haskell?

1

Pisałbym sam w Haskell, ale Ruby nie jest taka zła, że zasługuje na całkowite wyrzucenie. Podoba mi się fakt, że mogę go używać podczas pisania skryptów, a do wielu szybkich eksperymentów lubię hakować razem, ucząc się sztucznej inteligencji. Ale prawdopodobnie także dlatego, że właśnie zacząłem uczyć się Haskell, może w końcu pójdą za tobą :-)

— nemesisfixx

2

Nie rozumiem, dlaczego pytasz o pozwolenie na przepełnienie stosu. Jeśli piszesz kod, który chcesz udostępnić innym członkom zespołu, i tak będziesz musiał skoordynować swoje style kodowania. W przeciwnym razie, co to ma znaczenie?

— Mike Daniels

Dlaczego pytam SO? ponieważ szanuję uczciwą opinię doświadczonych hakerów i programistów. Korzystanie z czysto funkcjonalnego podejścia do programowania może przynieść korzyści, które doświadczone umysły mogłyby podzielić się ze mną (i innymi podobnymi do mnie).

— nemesisfixx

Biorąc pod uwagę, że istnieją obiektywne powody „nie”, jest to uzasadnione pytanie.

— Andrew Grimm

16

Robiłem to z Pythonem. Uważam, że nieporęczne jest pisanie w dziedzicznie czystym stylu funkcjonalnym w języku, który nie został do tego zaprojektowany. Na przykład, kontrast dwóch definicji in_order :

def in_order(xs):
    for i in range(1,len(xs)):
        if xs[i] > xs[i+1]:
            return False
    return True

inOrder :: (Ord a) => [a] -> Bool
inOrder xs = and $ zipWith (<=) xs (tail xs)

Pisanie in_orderHaskella w pythonie będzie zarówno pełne (ponieważ pyton nie obsługuje bardzo dobrze niezbędnych idiomów), jak i wolne (przestrzeń liniowa zamiast stałej przestrzeni Haskella z powodu lenistwa).

Miałem jednak sukces w tworzeniu programów w języku Python z funkcjonalną organizacją i idiomatyczną implementacją każdej funkcji. Pomysł, że jest to dobry sposób na programowanie, jest w rzeczywistości tezą stojącą za moim projektem katalogu kodów . Więc moje komponenty są zorientowane na abstrakcje i działające na nich funkcje (z czystym interfejsem ), a nie na klasy ze stanem, i ładnie się ze sobą łączy. W rzeczywistości kod zorganizowany w ten sposób wydaje się być bardziej elastyczny do ponownego wykorzystania niż kod zorganizowany z klasami. Może to być jednak osobiste nastawienie, ponieważ wciąż jestem wielbicielem Haskell.

Powiedziałbym więc, że odpowiedź na twoje pytanie jest dość . Użyj swoich funkcjonalnych korzeni, aby pomóc ci myśleć, ale nie przesadzaj. Na przykład. symulowanie leniwych list w Rubim dla samego idiomu będzie prawdopodobnie bardziej kłopotliwe niż warte.

— luqui
źródło

W jakiś sposób twój opis przypomniał mi Pascala.

— rasjani

@rasjani, oh? Jakiś powód dlaczego?

Nie wiem, może to brak zrozumienia angielskiego lub to, co opisałeś, pasuje do tego, jak (przynajmniej) rzeczy były ułożone / zbudowane w jednostkach pascal. Po prostu rodzaj mentalnego połączenia, może nie mieć żadnego prawdziwego związku z powodu pierwszej opcji;)

— rasjani 27.04.2011

1

Stwierdzenie „przestrzeń liniowa zamiast stałej przestrzeni Haskella z powodu lenistwa” nie jest dokładne. Lenistwo wciąż implikuje porządek liniowy. Rozumiem jednak twój punkt widzenia.

3

@aromero, jednak nie rozumiem twojego. Co ma z tym wspólnego porządek? Stała przestrzeń pochodzi od śmieci Haskell zbierających głowy list porównań po andich zużyciu; będzie się zachowywał jak pętla. Podczas gdy lista porównań Pythona będzie musiała zostać wygenerowana w całości, zanim analog andwyświetli jakiekolwiek z nich (chyba że użyjesz generatorów ... co, jak przypuszczam, jest możliwe).

7

Możesz pisać kod Ruby w funkcjonalnym stylu, jakby to był Schemat, a nie Haskell. Aby napisać to tak, jakby to był Haskell, potrzebowałby systemu typu Haskell oraz wszechstronnej, leniwej oceny.

— pocieszyć
źródło

1

Odkryłem, że zrozumienie programowania funkcjonalnego, a zwłaszcza Haskella, jest dla mnie pomocne w pewnych sytuacjach, które spotkałem w Ruby. Ale im więcej się uczę Haskella, tym bardziej zdaję sobie sprawę, jak daleko Ruby jest w stanie być podobnym do Haskella.

Po pierwsze ładowanie modułu / kodu jest fatalne. Bieżący interpreter nie ma włączonej optymalizacji wywołania ogona, więc nie można używać rekurencji tak jak w Haskell. A kiedy wejdziesz w Monady, naprawdę nie ma porównania poziomów abstrakcji, które możesz osiągnąć w Haskell vs. Ruby.

Jeśli jesteś zainteresowany, w trakcie nauki zamieszczałem kod porównawczy Ruby / Haskell na gist.github.com .

Najlepszą techniką, którą nauczyłem Ruby, jest znajdowanie czystych funkcji tam, gdzie mogę, i to brzmi, jakbyś próbował.

W jednym z moich testów Smalltalk: self assert: ((m >>= f) >>= g) equals: (m >>= [:x | (f value: x) >>= g]). Nie ma żadnego powodu, dla którego nie można świadomie korzystać z monad, w przeciwieństwie do korzystania z nich, nawet nie wiedząc, że ich używasz (jak listy).

— Frank Shearar,

0

Powiedziałbym tak". To, o czym mówię, to funkcjonalny wpływ programowania w języku ruby. Funkcjonalny paradygmat ma kilka naprawdę fajnych koncepcji, które uzupełniają się lub pokrywają z obiektowym (w szczególności brak efektów ubocznych).

Wspaniałą rzeczą w Ruby jest to, że umożliwia on kodowanie w stylu liniowym, zorientowanym obiektowo lub funkcjonalnie, lub w kilku kombinacjach. A twój prosty, liniowy skrypt może przekształcić się w styl OO / funkcjonalny, jeśli i kiedy jego złożoność wzrośnie.

— Robert Brown
źródło

0

To zależy od tego, czy będziesz współpracować z innymi. Jeśli pracujesz nad kodem sam, użyj stylu, który najbardziej ci odpowiada. Jednakże, jeśli pracujesz z innymi programistami Ruby, mogą nie być przyzwyczajeni do czysto funkcjonalnego stylu programowania i dlatego mogą być mylone przez twój kod. Z drugiej strony, jeśli twoi współpracownicy są również programistami Haskell, którzy przeprowadzili migrację do Ruby, możesz nie mieć tego problemu.

— Zhehao Mao
źródło