Wątek przeniesiony 2021-03-22 10:23 z Nietuzinkowe tematy przez cerrato.

Programowanie funkcyjne - Haskell, Lisp etc.

7

To może kilka wyjaśnień.

Haskell już od kilku lat nie jest językiem akademickim tylko wlazł do biznesu - nawet do mnie docierają oferty pracy w Haskellu - Polska (Warszawa) lub Zurich głównie.
Scala funkcyjna jest już w biznesie od dawna - można nawet powiedzieć, że przetarła szlaki Haskellowi trochę - otworzyła oczy niedowiarkom.

Dlaczego:
Głównie dlatego, żeby wbrew wszelkim przesądom móc o 15:55 w piątek puścić release na produkcje i spokojnie jechać na narty - nie patrząc nawet na to co leci w konsoli.
Kod funkcyjny, wsparty typami powoduje, że wiele błędów nawet nie da się popełnić (albo trzeba się postarać). Jak się skompiluje to musi działać.
Testów trzeba pisać dużo mniej, bo testujemy zasady biznesowe, a nie czy wszystko razem do kupy działa.

Czyste funkcje się zajebiście i bezproblemowo komponują.
Dla takich staruchow jak ja, którym się nie chce wysilać przy każdej linijce kodu - co też tu moze pójść nie tak - fp jest idealne - kompilator się wysila i robi mi review.
Killer feature fp to właśnie komponowalność, a w związku z tym bezpieczeństwo.

FP przyjęło sie w finansach, blockchain itp. - wszędzie tam, gdzie drobna pomyłka i masowo przelewamy pieniądze nie tym ludziom co trzeba, albo masowo kupujemy po nie tej co trzeba cenie.

Obecnie, co prawda większość kodu piszę w kotlinie, wbrew temu co napisano kotlin nie ma problemu z adaptacją wygryza javę nawet w korporacjach (oczywiście na pewno nie wszędzie), ale przynajmniej piszę funkcyjnie w tym kotlinie (Scala--) (dorobiłem nawet plugin do lintera, który czystość sprawdza).

1

FP przyjęło sie w finansach, blockchain (...)

Rzut okiem na Solidity pokazuje że tego funkcyjnego podejścia tam jednak brakuje: https://docs.soliditylang.org[...]html#scoping-and-declarations

Sam bitcoin naklepany w C++ (no jak oni mogli!): https://github.com/bitcoin/bitcoin a ETH w Go: https://github.com/ethereum/go-ethereum

Z ciekawości NoFluffJobs:

Ofert w Scali jest nieco więcej ale większość to nie programowanie tylko big data. Co ciekawe stawki na stanowiska dla Scalowców (nie big data) mizerne (przykłada od SM: https://nofluffjobs.com/pl/jo[...]-softwaremill-remote-apn7hgqc widły 11k - 17k, bez szału choć język znacznie bardziej trudny i wymagający). Pokazuje to jak biznes szanuje programowanie funkcyjne.

W erlangu jest nico ciekawiej (https://nofluffjobs.com/pl/jobs?criteria=erlang), w sumie ta oferta od blockfi nawet przykuła moją uwagę. Niemniej widać że funkcyjniaki to < 10% rynku.

0
0xmarcin napisał(a):

FP przyjęło sie w finansach, blockchain (...)

Rzut okiem na Solidity pokazuje że tego funkcyjnego podejścia tam jednak brakuje: https://docs.soliditylang.org[...]html#scoping-and-declarations

DAML się ładnie wpasowuje https://daml.com/

https://www.juspay.in/ to jeden z większych graczy w temacie fp.

Generalnie szukanie takiego stosu w pl mija się z celem.

1

Świetnie, że wytrzasnąłes solidity, ale czego to dowodzi? Czy to nie w solidity ktoś się kiedyś rypnął i stąd mamy split w Ethereum?
Jest również ileś funkcyjnych w okolicy smart contracts - ostatnio obiłem się o daml.

https://github.com/digital-as[...]/RefApps/Bond/Redemption.daml

Co do stawek to pełna racja - obecnię pracuje z dodatkiem za szkodliwe warunki pracy (czyli okazyjne potykanie się o javę i imperatywnego kotlina).

Paradoksalnie jeszcze grzebie czasem w TS, który jeśli się używa Reacta to potrafi być zupełnie czysto funkcyjny i nawet przyjemny.

Oferty na Haskell czy Scala są faktycznie słabsze, więcej dobrych ludzi chce w tym pracować i godzi się na niższe pensje (jak trafię kiedyś jeszcze na dłużej do jakiegoś Springa lub czegoś podobnego to też taki krok przemyśle).

2

Struktury niemutowalne zwykle wprowadzają znaczny narzut w porównaniu z odpowiednikami mutowalnymi.

@Krolik Niby tak, ale w praktyce:
1) Kolekcje w kodzie biznesowym sa małe
2) Często i tak list, tablic etc nie zmieniasz. Np. jak ładujesz 20 pierwszych operacji z histori karty to będziesz dalej przepychał te 20 operacji do frontendu czy jakiegoś SOAPA ;)
3) Można stosować lokalne mutowanie, nawet "ukryte". Np. jak masz Collector w Javie który tworzy kolekcję ze strumienia to możesz stosować lokalnie mutowalny buildier ArrayList a zwróci Ci niemutowalną kolekcję
4) W praktyce największym kosztem są operacje IO, głównie bazodanowe i nieumiejętne stosowanie albo po prostu stosowanie ORM i np. wczytanie całych encji mimo że potrzebujesz 3 pól z 20, albo N+1.
Dodatkowo refleksja o którą oparte są runtimowe frameworki też jest kosztowna pod wzlędem czasu.

5

No FP ma trochę zastosowań:

  • Lispy
    • gamedev (Naughty Dog)
    • webdev (kiedyś Reddit, Hacker News)
    • grafika/projektowanie (AutoCAD, GIMP)
    • sysops (Puppet, Guix)
    • testowanie (Jepsen)
  • BEAM (Erlang, Elixir i ferajna)
    • komunikacja (ejabberd, Discord, WhatsApp)
    • e-commerce (PepsiCo, Klarna)
    • hazard (bet365)
    • bazy danych (RabbitMQ, Mnesia, Riak, CouchDB, BarrelDB)
    • testowanie (QuviQ QuickCheck)
    • telco (Ericsson, Cisco)
  • ML
    • dowodzenie i weryfikacja (Coq, Isabelle)
    • generowanie kodu (FFTW)
    • implementacja języków (Coq, Haxe, Hack, ReasonML)
    • analiza statyczna programów (Infer, Frama-C, Flow)
  • Haskell
    • parsery (Pandoc, Corrode)
    • statyczna analiza (ShellCheck)
    • systemy kontroli wersji (git-annex, Darcs)
    • webdev (PostgREST)
2

Ja to widzę tak. Języki funkcyjne w pewnym sensie przydeptują swój własny wąż z tlenem.
Ich problem polega właśnie na tym, że ich zalety są doceniane. O co chodzi?
Współczesne języki głównego nurtu są w dużym stopniu hybrydowe.
To znaczy - w wielu już teraz popularnych językach można sobie pisać w miarę funkcyjnie (Scala, Kotlin, C#). I ten trend raczej się nasila, niż słabnie.

No to po co ktoś ma przestawiać się na język silniej związany z nurtem FP - jak na przykład F# - skoro co lepsze kąski i tak wpadną mu do C#?

Purystom to oczywiście nie wystarczy, ale purystów zawsze jest mało.

2

To znaczy - w wielu już teraz popularnych językach można sobie pisać w miarę funkcyjnie (Scala, Kotlin, C#). I ten trend raczej się nasila, niż słabnie.

Ty chyba nie wiesz co to FP jesli wymieniasz tutaj C#.

Podpowiem: FP nie polega na pisaniu lambd.

EDIT: to znaczy nie jest to warunek wystarczajacy ani nawet konieczny * ;)

0
V-2 napisał(a):

Ich problem polega właśnie na tym, że ich zalety są doceniane. O co chodzi?
Współczesne języki głównego nurtu są w dużym stopniu hybrydowe.

Ludzie po prostu odkryli na nowo, że w oop też możesz mieć lambdy. Właściwie zatoczyliśmy koło smalltalk -> java -> statycznie typowany smalltalk.

No to po co ktoś ma przestawiać się na język silniej związany z nurtem FP - jak na przykład F# - skoro co lepsze kąski i tak wpadną mu do C#?

Na F# po nic, bo akurat w nim programowanie obiektowe jest jedyną opcją. Nie ma funktorów z ocamla, nie ma type classes, nie ma nic... Już C++ ma więcej możliwości do budowania funkcyjnych abstrakcji.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0