[secret_passenger]

mam trochę takie #przemyslenia dotyczące #programowanie a tak konkretnie to #programowaniefunkcyjne

temat jest mi bliski od dłuższego czasu. nie, nie czuję się ekspertem. ale jako że lubię eksperymentować napisałem kilka aplikacji w różnych językach funkcyjnych by "zobaczyć jak to będzie działać". myślę że sama nauka konceptów funkcyjnych pozwoliła mi inaczej pisać w językach imperatywnych. ale to truizmy.

kilka lat temu wydawało mi się, że #programowaniefunkcyjne przebija się do mainstreamu. miałem wrażenie, że było autentyczne zainteresowanie tym by się tego uczyć, opanować i zacząć uzywać. to był czas gdy z wielką uwagą przyglądałem się temu co się działo w świecie JavaScript:
- #react stawał się popularny (#angular 2+ nadal był w planach)
- coraz popularniejsze były biblioteki typu #ramda, #lodash etc
- część ludzi po odkryciu Reacta zaczęła interesować się Elmem, a to z kolei doprowadziło do pewnego zaciekawienia Haskellem

do tego była przecież rosnąca jeśli chodzi o udziały w rynku scala. a oprócz niej: Clojure, F# (używany był - nie wiem czy nadal - choćby przez kilka dużych banków inwestycyjnych w działach Quant Strats), trochę Erlanga (mało) i nieśmiało debiutujący na rynku Elixir (mający zostać RoR-killerem).

dzisiaj patrzę na rynek i mam wrażenie, że jednak myliłem się. #programowaniefunkcyjne tak jak było niszą, tak zostało niszą. jasne, że jest tych firm więcej. nie jest tragicznie na rynku i jest zdecydownie lepiiej niż bylo choćby 10 czy nawet 7 lat temu. jasne. ale powiem tak - 5 lat temu miałem wrażenie że w 2020 będzie to wyglądać znacznie lepiej niż wygląd to dziś.

to co dziś dzieje się na rynku jest całkiem ciekawe - powstają firmy inwestujące w różne języki funkcyjne. Scala nadal jest popularna, ale słyszy się o firmach używających #elixir, #clojure a nawet Haskella (a mówię tutaj nadal o lokalnym rynku - tj. rynku Polskim).

w świecie JavaScriptu (czy raczej: frontu) część osób naprawdę przekonała się do innych języków niż #javascript / #typescript: aplikacje pisane są w #clojurescript czy #reasonml (super rzadko).

naprawdę nie jest źle. nie jest źle. tylko... że mialem wrażenie że był potencjał na coś więcej. i sam nie wiem co poszło nie tak?

* było za mało kandydatów?

* a może kandydaci nie widzieli dla siebie ofert pracy w fp?

* a może jednak "#haskell słabo płaci" (to słyszałem kilka razy)?

słyszę również że część firm mających do tej pory zespoły korzystające głównie ze #scala podejmuje decyzje o tym, by zmienić ją (Scalę) znów na Javę bo "ficzery funkcyjne w Javie w zupełności nam wystarczają".
kończy się zatem "hype" na fp? i faktycznie był to tylko hype?

jakie są wasze przemyślenia w temacie programowania funkcyjnego i jego popularności (nie tylko w Polsce)?

[d.....z]

@secret_passenger: kwestie biznesowe też mają znaczenie (zaczynanie projektu, dostępność programistów, późniejszy rozwój).

Odpowiedz sobie na pytanie: czy jak zależałby od ciebie projekt wieloletni, to wybrałbyś np. Haskella, nie wiedząc, czy uda Ci się znaleźć/zmigrować odpowiednią ilość programistów? I nie wiedziałbyś, że np. w drugim roku trzeba będzie coś wdrożyć, do czego Haskell nie ma kompletnie bibiliotek i albo trzeba pisać własne, albo korzystać z innych języków i wdrażać mikroserwisy?

Funkcyjne, dla

[secret_passenger]

@devopsiarz: piszesz jakby Haskell był jedynym językiem funkcyjnym. to raz.

dwa: Haskell jest naprawdę świetnie "obibliotekowany". ale też należy wybierać język do zastosowań. czy wybierałbym Haskella do pisania systemu aktorowego? nie. do tego będzie znacznie lepszy Erlang/Elixir czy nawet Scala z Akką.

Haskell pojawił się na rynku w 1990 - przed Pythonem i Ruby i długo przed takimi wynalazkami jak C#, F#, a ostatnio TypeScript.

i szczerze to mam wrażenie, że

[edgar_k]

@secret_passenger: Kwestie biznesowe.
Programowanie funkcyjne to... no ideał. Taki nieosiągalny bo komputery nie są funkcyjne, inne systemy nie są funkcyjne, integracje nie są funkcyjne.
Po latach męczenia się ze Scala/Akka powiem, ze to właśnie problem. Leaky abstraction.

[d.....z]

@secret_passenger: patrzysz z czysto programistycznego punktu widzenia, a to nie jest pełen obraz sytuacji. Ta zmienia się, gdy masz budżet do wykorzystania i musisz z niego się spowiadać władzom wyższym, a czasem jeszcze odpowiadasz swoim majątkiem, jak coś nie pyknie. Wtedy może nie być kolorowo, jak np. Twój zespół Haskellowców jest jeszcze nieskompletowany, a inny zespół od Node JS już ma działający produkt i komplet ludzi. Na pewno "biznes" w takiej

[parmezan2004]

@secret_passenger: Ludzie, ludzie, ludzie. Nie ma projektów w językach funkcyjnych, bo nie ma ludzi. Rok temu rekrutowałem na stanowisko senior scala developer, na sześciu kandydatów przysłanych przez HR, czterech nie nadawało się do niczego, dramat. Teraz szukaliśmy regulara, na czterech, dwóch było w miarę ok, ale żaden nie nadawał się, by od razu wystartować, będziemy musieli wybranego ze dwa miesiące poduczyć.
Ma to też dobre strony, odkąd programuję w scali, raczej

[secret_passenger]

@edgar_k: jasne, ale nie chodzi o to by fp pchać wszędzie i na siłę. tak samo jak RDBMS nie jest najlepsze zawsze, nie zawsze najlepsze są transakcyjne silniki, nie zawsze dobra jest 3 postać normalna i nie zawsze sprawdzi się NoSQL. po prostu: to zależy :)

natomiast ogromna część rzeczy możę być pisana w stylu funkcyjnym (nawet niekoniecznie od razu używając języków czysto funkcyjnych). podejście pragmatyczne jak najbardziej, ale wydaje mi

[d.....z]

@secret_passenger: żeby nie było, ja lubię programowanie funkcyjnie, choć mam spojrzenie realistyczne (tak przynajmniej uważam). Uważam, że każdy programista winien mieć jakiś minimalny kontakt z językami typu Haskell właśnie, by mieć szersze spojrzenie, ale zakładam, że to nie nastąpi.

Co do Twojego przykładu - inna jest sytuacja, gdy masz jakiś gotowy produkt i idziesz z nim do klienta/inwestora (i klienta raczej nie obchodzi, że Twój produkt jest w języku funkcyjnym, tylko

[Hauleth]

Moim zdaniem, gdyby równie szybko i bezproblemowo (weźmy ten JS ekosystem do porównania) klepało się apki webowe w funkcyjnych tak jak w nodzie/php/ror

@devopsiarz: Ale tak jest. Elixir + Phoenix jest nie trudniejszy niż RoR/Node.

rynek tych apek szybko by sie na języki funkcyjne przerzucił i przeszkolił nawet najbardziej lewych developerów - każdy chciałby mieć tę przewagę nad konkurencją

Tak samo było np. z układem Dvoraka. Pomijasz całkiem sporo aspektów i

[parmezan2004]

@secret_passenger: Tu nie chodzi o liczbę chętnych, a o poziom. Zarówno w pierwszym jak i w drugim przypadku potrzebny był ktoś, kto zacznie pracę po krótkim wdrożeniu (w pierwszym przypadku, na seniora, był ktoś potrzebny bardzo i na już), a przyszli ludzie, którzy fizbuzz nie potrafili napisać w scali, na stanowisko senior scala developer. Nie miałem jeszcze przypadku, by ktoś programujący w haskellu przyszedł na rozmowę. Zazwyczaj to są java devy

[d.....z]

@Hauleth: idźmy od tyłu: COBOL (bo z bankami miałem do czynienia), a konkretnie jego obecność, to czysto sprawa biznesowa. Bankom zwyczajniej taniej srodze opłacać "dziadków" niż migrować na Javę i dostałem to info z 2 banków, że COBOL będzie jeszcze 2-3 dekady, bo nie ma sensu migrować.

Do pozostałych przypadków nie mogę się odnieść, bo nie wiem co chciałeś nimi pokazać (X vs Y, ja tam nie widzę tylko problemu biznes

[Hauleth]

tylko były od lat i miały szansę zdobywać rynek stopniowo

@devopsiarz: gdyby czas w jakim język jest dostępny miał znaczenie, to ani JS, ani Ruby, ani PHP nie miały by znaczenia, bo wszystkie są z 1995 roku. Natomiast języki funkcyjne są trochę starsze

- Haskell - 1990
- Erlang - 1986
- ML - 1973
- Scheme - 1975
- Common Lisp - 1984

Więc to na pewno nie wiek ma

[edgar_k]

Języki funkcyjne w większości przypadków będą oferowały podobny czas do wdrożenia jednocześnie często oferując lepszą jakość kodu wyjściowego poprzez wymuszenie niektórych zachowań (np. braku stanu) czy pozwolą na lepszą skalowalność aplikacji w przyszłości (ze względu na brak stanu).

@Hauleth: heh, nie do końca. Nie spotkałem jeszcze aplikacji która nie ma stanu, bo taka jest natura przydatnych aplikacji.
Jakbyś się nie starał wszyscy twoi aktorzy z Akki maja stan, dane użytkownika maja

[Hauleth]

@edgar_k: Stan zawsze jakiś będzie, ale w przypadku języków funkcyjnych jego mutacje są z reguły bardziej ograniczone. Chodzi by stan pomiędzy requestami był mniej zmienny, przykładowo zmienne globalne.

Dodatkowo sama zależność, że x = deep_copy(a); foo(a); x == a jest zawsze prawdziwe, jest bardzo przydatna.

[y.....l]

@Hauleth: @edgar_k: @devopsiarz: @parmezan2004: @secret_passenger:
Ja bardzo lubię programowanie funkcyjne i przez kilka lat siedziałem w BigData gdzie prym wiedzie Scala, znam też trochę programistów Scali i firm, gdzie w Scali się pisze. Ja swoje małe rzeczy piszę głównie w Eixirze. Niestety z programowaniem funkcyjnym są problemy:
1. Myślę, że główny problem to brak programistów, jak ktoś wcześniej napisał. Jeżeli chodzi o Haskella, Elixira, Erlanga czy Clojure

[Hauleth]

Jeżeli chodzi o […] Elixira, Erlanga […] to jest bardzo mało devów, którzy w tym piszą.

@yggdrasil: no mniej niż w Javie, ale całkiem sporo ich jest. Zwłaszcza, że teraz dużo dobrych osób często szuka jakiejś odmiany, więc dobrzy programiści z innych języków interesują się właśnie np. Elixirem. Oprócz tego Kraków ma całkiem dobre zagłębie Erlangowe i to właśnie tam powstał Elixir.

Kolejny problem to jakość programistów

Ja bym powiedział, że

[y.....l]

Ja bym powiedział, że średnia jakość programistów FP jest wyższa niż w Javie czy innych.

@Hauleth: Oczywiście masz rację, ale ja mówię o tych, co przychodzą na rozmowy. W większości są to programiści Javy, którzy nauczyli się składni Scali i piszą dalej w Javie, ale z inną składnią. Z doświadczenia to większość programistów Scali to są byli Javovcy.

no mniej niż w Javie, ale całkiem sporo ich jest.

@Hauleth: No

[secret_passenger]

@devopsiarz:

Co do Twojego przykładu - inna jest sytuacja, gdy masz jakiś gotowy produkt i idziesz z nim do klienta/inwestora (i klienta raczej nie obchodzi, że Twój produkt jest w języku funkcyjnym, tylko co on zyska dzięki niemu), inna, gdy u klienta musisz się dostosować do jego stacku i masz ograniczone pole manewru, a jeszcze inna, gdy sam musisz wybrać jak coś zrobić od 0, obracając się w założonym budżecie i

[parmezan2004]

@secret_passenger: Trochę późno zobaczyłem ostatnie pytania.
Ciężko mi mówić o trendach i rynku wrocławskim. W scali pracuję 5 lat i tylko dla dwóch firm. Obecnie zdalnie, dla firmy z siedzibą w Krakowie. Tutaj też był taki czas, że zastanawiali się co z nami zrobić, bo projekty scalowe zostały zamknięte. Były pomysły na wrzucenie nas do Kotlina, bo do Javy nikt nie chciał wracać. Jednak wystartowało ponownie coś, co robiliśmy kiedyś i

[secret_passenger]

@parmezan2004: dzięki za odpowiedź.

ja właśnie się dziwiłem że poszło takie info, że "firmy rezygnują ze Scali na rzecz Javy" i faktycznie widziałem to na 2 przykładach - ale 2 przykłady (czy nawet 3) to żaden trend.

bardzo ciekawe jest to co napisałeś o tym że "nikt nie chciał wracać do Javy" - ja mam trochę podobnych przemyśleń - chyba nie chciałbym wracać do pewnych starych technologii, jakie zostawiłem za sobą.