Argumenty dla programowania funkcjonalnego [zamknięte]

Ostatnio uczyłem się F # dla zabawy (jestem deweloperem VB.NET/C#) i bardzo podoba mi się to, co ma do zaoferowania. Teoretycznie tak jest. Ale mam problem z wymyśleniem scenariuszy, w których wolałbym kodować w F # niż w C #. Jakieś pomysły?

Kilka argumentów za czysto funkcjonalnym programowaniem:

• Łatwiej jest dzielić zadania dla dzisiejszych systemów wielordzeniowych
• Łatwiej jest udowodnić, że Twój program jest poprawny
• Kompozycja funkcjonalna może być niesamowita, zwięzła i potężna

Aby uzyskać pełne leczenie, zobacz Dlaczego programowanie funkcjonalne ma znaczenie i Dlaczego programowanie funkcjonalne ma znaczenie .

Mam problem z wymyśleniem scenariuszy, w których wolałbym kodować w języku F # niż w języku C #. Jakieś pomysły?

Od tutaj :

Serwery asynchroniczne

• Asynchroniczne przepływy pracy dla asynchronicznego we / wy.
• Procesor skrzynki pocztowej do przekazywania wiadomości wątkowo bezpiecznych.
• Typy Unii dla stanu serwera i katalogu komunikatów.
• Dopasowywanie wzorów i rekurencja ogona dla automatów stanowych.

Metaprogramowanie (np. Parsowanie)

• Generatory parsera, takie jak fslex i fsyacc.
• Kombinatory parsera, takie jak FParsec.
• Aktywne wzory dla eleganckich ręcznie zwijanych parserów.
• Algebraiczne typy danych do reprezentowania parsowanych drzew.
• Dopasowywanie wzorów do manipulowania drzewami, np. Zastosowanie etapów optymalizacji.
• Refleksja na temat generowania szybkiego kodu w czasie wykonywania.

Informatyka techniczna

• Funkcje wyższego rzędu dla eleganckiego i szybkiego kodu algorytmicznego.
• Algebraiczne typy danych i dopasowanie wzorców do manipulacji symbolicznych.
• Interoperacyjność dla bogactwa bibliotek .NET.
• Interaktywność za pomocą interaktywnego F #.
• Wyrażenia obliczeniowe do masowania danych.
• Jednostki miary dla poprawy poprawności.

Aplikacje GUI

• Modeluj jako asynchroniczny komunikat przesyłany między kodem interfejsu użytkownika a kodem logicznym aplikacji.
• Funkcje wyższego rzędu umożliwiają deklaratywne definiowanie interfejsów użytkownika.

Programowanie logiki

• Trwałe kolekcje dla łatwego powrotu.
• Ogon wymaga niezawodności.
• Automatyczne uogólnienie dla łatwego programowania ogólnego.

Testowanie

• Przeprowadzaj testy jednostkowe interaktywnie.
• BDD oznacza pisanie tłumacza.
• Dobry język skryptowy do pisania wiązek testowych i wizualizacji wyników.

Wydajność

• inline dla bezpłatnej abstrakcji wyższego rzędu.
• Ogon wzywa do maszyn szybkiego stanu.
• Czysto funkcjonalne struktury danych dla małych opóźnień.
• Metaprogramowanie do generowania zoptymalizowanego kodu.

Oto, do czego służy programowanie w stylu funkcjonalnym - mniej więcej codziennie.

Robimy wiele rzeczy statystycznych i aktuarialnych z dość dużymi zbiorami danych. Dane pobierane z bazy danych to - w zasadzie statyczne, niezmienne obiekty. Nie ma powodu, aby tworzyć klasę za pomocą metod.

Każdy etap obliczeń dodaje kilka dodatkowych szczegółów, ale zasadniczo nie powoduje mutacji obiektu. Na „końcu” rurociągu naprawdę robimy fantazyjne redukcje, aby obliczyć sumy, liczby i inne rzeczy.

Wyobraź to sobie.

for data in summarize( enrich( calculate( some_query( criteria() ) ) ) ):
    print data

Każda „faza” obliczeń jest funkcjonalną pętlą programowania, która wykonuje proste odczyt-obliczanie-wydajność i tworzy złożony obiekt z innymi rzeczami i wynikami.

(Używamy Pythona, stąd programowanie funkcjonalne przy użyciu funkcji generatora).

Łatwiej jest używać bezstanowych, niezmiennych obiektów.

Technicznie nie jest to unikalna właściwość programowania funkcjonalnego, a F # nie jest czystym językiem funkcjonalnym. F #, jako jeden z potomków ML, zapewnia doskonałe dopasowanie wzorca i algebraiczne typy danych. Tak więc dla każdego zadania, które wymaga skomplikowanych struktur danych, F # jest o wiele bardziej wyrazisty i łatwy w użyciu niż C #.

Wyobraź sobie implementację kompilatora w C # i F # - reprezentowanie abstrakcyjnego drzewa składni i przekształcanie się nad nim jest o wiele prostsze, jeśli Twój język zapewnia ADT i dopasowanie wzorca.

Idealny do ograniczania mapy masywnego wielosystemowego i masywnego równoległości wielordzeniowej. Całkiem fajne, biorąc pod uwagę, że obecnie serwery podstawowe mają 48 rdzeni (96 zliczających HT).

Jeśli chcesz w pełni funkcjonalny wypróbować Haskell, Erlang ma również kilka fajnych rzeczy na ten temat.

Simon Payton-Jones powiedział o Haskellu, że chce mieć program, który oczywiście nie ma żadnych błędów, niż nie ma oczywistych błędów.

(Prawdopodobnie wyceniłem trochę cytat, ale masz pomysł)

Ograniczając skutki uboczne, znacznie ułatwiasz sprawdzenie, czy kod jest poprawny.

Niewątpliwą zaletą jest to, że można go znacznie łatwiej sparaliżować.