Reactive Programming - hit czy kit ?

Wedlug mnie na razie kolejny buzzword.

Wielki Mleczarz napisał(a):

Wedlug mnie na razie kolejny buzzword.

Od czasu jak Java 8 dostała elementy funkcyjne, od czasu jak pojawił się LinQ, od czasu jak Scala wyszła z podziemia akademisckiego, od czasu jak pojawia się big data (hadoop, spark) to już nie jest buzzword. To jest ewolucja wymagań stawianych przez biznes i czy się to komuś podoba, czy nie - trzeba iść do przodu :)

krx napisał(a):

Wielki Mleczarz napisał(a):

Wedlug mnie na razie kolejny buzzword.

Od czasu jak Java 8 dostała elementy funkcyjne, od czasu jak pojawił się LinQ, od czasu jak Scala wyszła z podziemia akademisckiego, od czasu jak pojawia się big data (hadoop, spark) to już nie jest buzzword. To jest ewolucja wymagań stawianych przez biznes i czy się to komuś podoba, czy nie - trzeba iść do przodu :)

Co ma Spark i hadoop do reactive? Do czego wykorzystujesz reactive i co to według takiego jest?
Mozna iśc do przodu pod warunkiem, ze użycie tego ma uzasadnienie a nie próbować wrzucać to wszędzie gdzie się da.

Bardziej tutaj widzę bardziej istotne elementy, które już jakiś czas istnieja niż samo reaktive, czyli:

• programowanie funkcyjne
• fast data, spark
• async

A część rzeczy jest dawna tylko nikt temu nie dawał nazwy 'reactive'

https://spring.io/blog/2016/06/07/notes-on-reactive-programming-part-i-the-reactive-landscape
use cases:

• External Service Calls
• Highly Concurrent Message Consumers
• Spreadsheets
• Abstraction Over (A)synchronous Processing

Szczerze mówiąc, jakoś niewiele... + do wielu wcale nie potrzeba żadnego reactive.

@krx ja mam wrażenie że niestety niewielu jest programistów który rozumieją że nie ma panaceum ani żadnego silver bullet w programowaniu. A już na pewno nie jest nim programowanie funkcyjne. Paradygmantów programowania jest wiele i każdy ma jakieś plusy i minusy. Programowanie funkcyjne świetnie sprawdza się w pewnych konkretnych zastosowaniach, ale to nie znaczy nagle że OO to była dziejowa pomyłka i należy o nim zapomnieć. Niestety wielu programistów ma taka hipsterską mentalność że nowe = lepsze (gdzie przez nowe chodzi o koncepcje która ostatnio nie była w modzie, bo oczywiście ani programowanie funkcyjne, ani reaktywne nowe to nie są...). Najlepiej widać to w świecie JavaScriptu, ale niestety nie tylko.
Oczywiście są też tacy którzy uważają za panaceum to co umieją, czyli choćby OO i wpychają je wszędzie, niekoniecznie tam gdzie sie nadaje. To rozszerza się też dalej o użycie takiego czy innego języka albo takiej czy innej technologii. Zgodnie z przysłowiem że jak masz młotek to nagle wszyskto przypomina gwoździe ;)

Widać np. wyżej u kolegi @Złoty Kaczor podniecanie się Future czy wywołaniami Asynchronicznymi, które w takiej Javie są od lat. To że ktoś z nich nie korzystał to jest generalnie jego błąd i brak umiejętności, nic więcej. Tak samo opowiadanie ze:

-nie ma pętli for (za wyjątkiem for comprehension w scala:) )

• if'ów prawie nie ma
• zapomniałem co to jest nullpointerexception

Jest dość zabawne, bo pętla for jest ukryta w map/reduce a if ukryty w optional, filter i pattern matchingu. Co wiecej wielu ludzi pisze nadal słaby kod, tylko sobie zamienia właśnie jedną konstrukcje na drugą i myślą że nagle kod jest magicznie lepszy ;]
Problem z nullpointerexception wynika z tego że ktoś nie rozumie jak używać optional, either oraz wyjątków. Normalnemu człowiekowi zapala sie czerwona lampka jak robi return null albo jak musi zrobić if x == null i technologia nie ma tu nic do rzeczy.

Swoja droga z ostatnich buzzwordow to chwycily np. Mikroserwisy a z tym z nowych rzeczy to np.. docker.

Ogolnie soft napisany na Golangu po prostu ludzie zaczynaja uzywac bez obrzucania sie manifestami...