Jakie są dobre praktyki w nauczaniu programowania deklaratywnego programistom-programistom?

Zaproponowałem trochę szkolenia w F # w mojej firmie i wydawało się, że wykazują pewne zainteresowanie. Na ogół są to programiści VB6 i C #, którzy z pasją nie podążają za programowaniem. Biorąc to pod uwagę, wydaje mi się, że łatwiej jest napisać poprawny kod, gdy myślisz o kwestii funkcjonalnej, więc zdecydowanie powinni z niego skorzystać.

Czy ktoś może udzielić porady, jak powinienem do tego podejść?

Pomysły

• Nie skupiaj się na składni, zamiast tego skup się na tym, jak można używać tego języka i idiomów, które promuje.
• Spróbuj pomyśleć o przykładach, które pisanie w sposób imperatywny jest uciążliwe, ale przekłada się na elegancki kod, gdy jest napisany w sposób deklaratywny.

Programowanie funkcjonalne jest dla mnie dziwną bestią. Nauczyłem się F # i Haskell, napisałem kilka prostych programów i uwielbiam ich używać, ale nigdy nie miałem „błysku objawienia”, o którym niektórzy mówią. Ale powoli zauważyłem, że coraz więcej piszę kod, który miał być niezmienny, dzieląc zadania na więcej, mniejsze funkcje i próbując używać delegatów o wiele więcej. Jeśli ci się spodoba, wkrada się do twojej pracy, ponieważ wartość tych technik jest oczywista.

Teraz, bardziej praktycznie, do treningu: uważam, że dwie koncepcje naprawdę mi się podobają do programowania funkcjonalnego.

Po pierwsze, styl FP oparty jest na strukturze danych, a nie na składzie jak w OOP. Patrzyłem na coś takiego jak List w C # jako sprytną sztuczkę do generowania list bezpiecznych dla typu, coś, co skomponowało typ (ciąg znaków) do innego typu (lista). Po nauczeniu się FP patrzę teraz na generyczne bardziej jak Monady. List to ustrukturyzowana forma, którą kod może przyjąć i ozdabia ciągi.

Po drugie, być może bardziej przydatny dla programistów C # / ASP, jest pomysł, że FP działa na rekurencję i powtarzanie, podczas gdy OOP działa na zmienność i zapętlanie. Myślę, że cykl życia strony ASP jest teraz rodzajem FP: każde żądanie jest przetwarzane od zera przez cały cykl życia, więc cała strona jest w efekcie jednym dużym, powolnym programem. Jeśli możesz zawęzić to pojęcie, uzyskasz lepsze pojęcie o tym, jak program imperatywny może być zbudowany wokół pętli funkcji, które pobierają dane, działają nad nim i zwracają nowe dane zamiast modyfikować stare.

Najtrudniejszą przeszkodą, przynajmniej dla mnie, do pokonania przy takim podejściu jest to, że tonące uczucie, że marnujesz mnóstwo zasobów podczas korzystania ze zmiennych obiektów, zaoszczędziłoby mnóstwo pamięci. W GC ufamy i po prostu musiałem nauczyć się rezygnować z problemów z wydajnością, dopóki nie zobaczyłem, że program działa i nie sprawdziłem, czy w ogóle istnieje, a jeśli tak, to użyj profilera, aby zobaczyć dokładnie, gdzie były problemy.

Chciałbym polecić:

• prezentacja Taming Effects with Functional Programming, autor: Simon Peyton-Jones
• książka Real World Functional Programming: With Przykłady in F # i C # autorstwa Tomasa Petricka i Jona Skeeta

Wiele imperatywnych języków programowania (Ada, C / C ++, Turbo Pascal, FoxPro) ma możliwość definiowania wskaźnika do funkcji lub literałów nazw procedur, które można oceniać (i procedur nazwanych po literale wywołanym) w czasie wykonywania.

Tradycyjnym przykładem jest qsort w C. Oprzyj się na założeniu, że możesz definiować algorytmy, które wykonują inne algorytmy na strukturach danych. Oczywiście jest to tylko ułamek tego, czym jest programowanie funkcjonalne. Ale odkryłem, że jest to dobry punkt wyjścia do wprowadzenia pomysłu.

Gdy to się zapadnie, możesz zacząć zagłębiać się w inne rzeczy (niezmienność, brak udostępniania itp.)

Czy ktoś może udzielić porady, jak powinienem do tego podejść?

Pewnie:

• Starannie wybieraj przykłady, aby Twój kod F # nie tylko rozwiązał problem elegancko, ale także znacznie bardziej elegancko niż jest to możliwe w przypadku C # / VB . Dopasowywanie wzorów i wnioskowanie o typie są tutaj Twoimi przyjaciółmi.

• Użyj jednego przykładu, aby podkreślić zalety nowej funkcji znalezionej w języku F #, np. Asynchroniczne przepływy pracy, aktywne wzorce.

• Nie obawiaj się podawać nieczystych przykładów, używając odpowiednich zmiennych danych. F # jest nieczysty z jakiegoś powodu.

• Nie prezentuj F # jako panaceum. Opisz aplikacje, dla których F # nie jest dobrze przystosowany, a także te, dla których jest znacznie lepiej przystosowany niż inne języki .NET.

• Wskaż próbki zabawek, które mogą badać, a także udane projekty w świecie rzeczywistym, w których wykorzystano F # (Bing AdCenter, Halo 3 itp.).

• Wyjaśnij wszystko, w jaki sposób F # może pomóc im w łatwiejszym rozwiązywaniu problemów. Unikaj debat religijnych. Bądź pozytywny na temat F #, a nie negatywny na temat innych języków. Uzbrój je w fakty i dowody, ale pozwól im wyciągnąć własne wnioski.