Ja osobiście jestem zwolennikiem mieszanych paradygmatów. Puryzm paradygmatyczny jest dla mnie mocno ograniczający, bo niektóre rzeczy łatwiej wyrazić funkcyjnie (przepływ i transformacja danych), inne obiektowo (struktury typu DOM). Mój kod często ma bebechy mocno funkcyjne, natomiast publiczne API - obiektowe. Najważniejsze to nie popadać w dogmatyzm i nie odrzucać jakiegoś paradygmatu właśnie z powodu dążenia do puryzmu w kodzie. Kod ma przede wszystkim rozwiązywać problem i być czytelny dla różnych programistów. A to, czy będzie funkcyjny, obiektowy, czy mieszany, to już kwestia wtórna.
Nie mogłbym zgodzić się bardziej 👏. Z czystej ciekawości, mam pytanie o te kawałki funkcyjne o których wspominasz. Jak bardzo funkcyjne są? Ograniczasz się do immutable struktur danych, czystych funkcji i izolacji stanu (generalnie rzeczy, które wydają mi się dość praktyczne) czy używasz też bardziej zaawansowanych mechanizmów z teorii kategorii?
@@JZP raczej takie podstawowe rzeczy. Chociaż kusi mnie, by zacząć eksperymentować z wprowadzaniem do części projektów np. monad Maybe, bo koncept wydaje się mocno praktyczny.
Dopiero uczę się front-endu więc nie chcę udawać znawcy, bo nim nie jestem, ale doświadczeni frontendowcy, których znam często wspominają, że popularność programowania funkcyjnego w JS wynika z faktu, że najpopularniejsze frameworki JS (React, Angular, Vue) sprzyjają paradygmatowi funkcyjnemu. Jakie jest Wasze zdanie w tym temacie, bo w ogóle nie poruszyliście tej kwestii w nagraniu?
Bardzo ciekawe pytanie! Również spotkałem się z opinią, że frameworki JS ułatwiają programowanie funkcyjne. Osobiście się z nią nie zgadzam - dlatego nie poruszyłem tego tematu w filmie. Ale pozwól, że trochę rozwinę i powiem dlaczego kiedyś to twierdzenie mogło mieć w sobie ziarno prawdy. Frameworki front-endowe często skupiają się głównie na ułatwieniu obsługiwania efektów ubocznych - requestów HTTP, modyfikacji DOM, obsługi błędów itd. Więc już trochę z definicji nie mogą być funkcyjne. Tutaj trzeba przyznać, że wiele frameworków promowało "funkcyjny styl" programowania do obsługiwania danych czy stanu aplikacji. Styl ten używa podobnych technik jak programowanie funkcyjne (stylem funkcyjnym jest np. przykład z owocami z filmu). Nie jest to jednak czyste programowanie funkcyjne. Warto wspomnieć, że jeśli będziesz pisać funkcyjne komponenty w Reakcie, które nie używają hooków ani stanu - to możesz osiągnąć funkcyjny UI. Może się tylko okazać, że jest on dość mało użyteczny. Mam nadzieję, że trochę rozjaśniłem! Daj znać, jeśli chciałbyś się dowiedzieć więcej.
![Blox Fruits Dragon Rework Update [Full Stream]](http://i.ytimg.com/vi/EqDAp8udhm0/mqdefault.jpg)
A Ty lubisz / znasz / stosujesz programowanie funkcyjne? Daj znać w komentarzu 👇
Naprawdę świetne i wartościowe materiały robisz :)
Dzięki 🙌
Świetna robota 😁
Dzięki 🙌
Ja osobiście jestem zwolennikiem mieszanych paradygmatów. Puryzm paradygmatyczny jest dla mnie mocno ograniczający, bo niektóre rzeczy łatwiej wyrazić funkcyjnie (przepływ i transformacja danych), inne obiektowo (struktury typu DOM). Mój kod często ma bebechy mocno funkcyjne, natomiast publiczne API - obiektowe.
Najważniejsze to nie popadać w dogmatyzm i nie odrzucać jakiegoś paradygmatu właśnie z powodu dążenia do puryzmu w kodzie. Kod ma przede wszystkim rozwiązywać problem i być czytelny dla różnych programistów. A to, czy będzie funkcyjny, obiektowy, czy mieszany, to już kwestia wtórna.
Nie mogłbym zgodzić się bardziej 👏. Z czystej ciekawości, mam pytanie o te kawałki funkcyjne o których wspominasz. Jak bardzo funkcyjne są? Ograniczasz się do immutable struktur danych, czystych funkcji i izolacji stanu (generalnie rzeczy, które wydają mi się dość praktyczne) czy używasz też bardziej zaawansowanych mechanizmów z teorii kategorii?
@@JZP raczej takie podstawowe rzeczy. Chociaż kusi mnie, by zacząć eksperymentować z wprowadzaniem do części projektów np. monad Maybe, bo koncept wydaje się mocno praktyczny.
Dopiero uczę się front-endu więc nie chcę udawać znawcy, bo nim nie jestem, ale doświadczeni frontendowcy, których znam często wspominają, że popularność programowania funkcyjnego w JS wynika z faktu, że najpopularniejsze frameworki JS (React, Angular, Vue) sprzyjają paradygmatowi funkcyjnemu. Jakie jest Wasze zdanie w tym temacie, bo w ogóle nie poruszyliście tej kwestii w nagraniu?
Bardzo ciekawe pytanie! Również spotkałem się z opinią, że frameworki JS ułatwiają programowanie funkcyjne. Osobiście się z nią nie zgadzam - dlatego nie poruszyłem tego tematu w filmie.
Ale pozwól, że trochę rozwinę i powiem dlaczego kiedyś to twierdzenie mogło mieć w sobie ziarno prawdy. Frameworki front-endowe często skupiają się głównie na ułatwieniu obsługiwania efektów ubocznych - requestów HTTP, modyfikacji DOM, obsługi błędów itd. Więc już trochę z definicji nie mogą być funkcyjne. Tutaj trzeba przyznać, że wiele frameworków promowało "funkcyjny styl" programowania do obsługiwania danych czy stanu aplikacji. Styl ten używa podobnych technik jak programowanie funkcyjne (stylem funkcyjnym jest np. przykład z owocami z filmu). Nie jest to jednak czyste programowanie funkcyjne.
Warto wspomnieć, że jeśli będziesz pisać funkcyjne komponenty w Reakcie, które nie używają hooków ani stanu - to możesz osiągnąć funkcyjny UI. Może się tylko okazać, że jest on dość mało użyteczny.
Mam nadzieję, że trochę rozjaśniłem! Daj znać, jeśli chciałbyś się dowiedzieć więcej.
4:28 cięcie na poprawę fryzury :D
Trzeba dobrze wyglądać na planie! :D