Vlákno názorů k článku Nechte Go plavat, teď sviští Java od hawran.diskuse - A sacra.

No právě. I v Javě pochopili, že funkcionální programování je cesta vpřed.

No a?

"Proč se v nich [funkcionálních jazycích] běžně nepíší operační systémy, kodeky, podnikové aplikace, hry atd?"

1) Nejsou dostatečně kvalitní kompilátory (možná s výjimkou jazyka OCaml)
2) Funkcionální přístup pracuje s daty, ale nikoliv se změnou stavu. Jakmile tedy máte problém kde je nutnost udržovat stav nějaké datové struktury (modelování nějakého systému a nikoliv jen číst měnit a zapisovat proud dat) a tu měnit, tak funkcionální přístup nelze použít.

Pro operační systémy a kodeky je zásadnější bod 1, pro hry a podnikové aplikace spíše bod 2.

> Jakmile tedy máte problém kde je nutnost udržovat [a měnit] stav [..] tak funkcionální přístup nelze použít.

Uhm... aku mas oblubenu farbu?

Java:
http://blog.tmorris.net/posts/dear-java-guy-state-is-a-monad/index.html
https://dzone.com/articles/do-it-in-java-8-state-monad

Scala:
https://www.reddit.com/r/programming/comments/2isa9q/the_state_monad_in_java/cl54f4i/

Clojure:
http://www.clojure.net/2012/02/10/State/

Mám trochu obavy, z té multiparadigmatické budoucnosti, ve světě kde každý řeší jak se co nejrychleji napíše ideálně s použitím funkcionálního přístupu v objektovém jazyce.
Pro mě je cenný jazyk a prostředí, ve kterém budu hravě udržovat systém s milionem řádků kódu, desítkama různých komponent, větším množstvím programátorů co se můžou měnit cca po půl roce . To chce kulturu a jednotnost alespoň v rámci komponenty.
Když si to někdo nepohlídá bude mít od jednoho programátora věci objektově , od druhého ve funkcích a od třetího dohromady.
Z tohoto pohledu mi Java s omezenější množinou jazykových konstrukcí tak nějak okolo 1.5 byla milejší.

"větším množstvím programátorů co se můžou měnit cca po půl roce . "

a chcou to takhle i ti programátoři?

Mno, spis pochopili, ze funkcionalni programovani ma svoji pomerne uzkou niku, kde je uzitecne.

Hlavne v oblasti proudoveho zpracovani dat.

Ze se nekdo snazi narvat pomoci rovnaku na ohybaky funkcionalni pristup na modelovani objektoveho sveta kolem nas, to uz je jiny pribeh.

Zkus si muj prispevek precist este jednou, pomaleji

Spíš OOP je falešný pokus modelovat svět "realisticky". Takže máme objekt kámen, který dostane zprávu a když se rozhodne, že je to vhodné, poletí. Funkcionální přístup je jenom jeden ze způsobů, jak popsat, co se má stát, namísto toho, jak se to má stát. Jenže ta procedurální složka prostě někde být musí, deklarativní popis nestačí, proto "čisté FP" nemá úspěch. Rozhodně to ale neznamená, že OOP je řešení, to je myslím už dnes dostatečně zřejmé.

Komicky blabol.
Pokud nekdo modeluje svet kolem sebe pomoci letajicich kamenu znamena to, ze OOP "neni reseni a je to zrejme"

Genialni logika.

Apropos, zprava objektu je prave popis co se ma stat, jak se to stane je vnitrni problem objektu.

Ostatne root je plny potroubku, co vyrabej OOP modely, kde kartotecni listky samy skacou do sanonu, kameny letaji, pisek aktivne skace na cekajici lopatu.
A pak se divi. Teda nedivi, OOP je k hovnu a je to kazdenu zrejme...

> kartotecni listky samy skacou do sanonu, kameny letaji, pisek aktivne skace na cekajici lopatu.

Presne. Moc hezky receno. Je videt, ze objektovy navrh i v dnesni dobe ne kazdy zvlada. Problem ale je, ze ani Java takovym nepomuze. Tam jde o to byt "in" a o zbytek se postaraji 3rd knihovny a my to uz nejak slepime. A kdyz neco nefunguje, muze za to ta blba knihovna. Jako bych byl zpet u sveho predchoziho zamestnavatele.. :)

Máš jedinečnou příležitost ukázat, co jsi myslel tím "objektovým světem kolem nás". Takto to vypadá, že jsem Tě nachytal a tak jenom planě prskáš.

Nic proti funkcionalnimu programovani, az na to, ze Java je OOP jazyk.

Takze dva lidi, jeden bude tlacit func. Druhy oop, vysledek bude zmatecny kod. Viz napr. C++.

Spíš to ukazuje, že komerční sféra občas nepochopí trolling.

Ono, přiznejme si, říkat, že Java je lepší než Go dává stejný smysl, jako říkat, že Haskell je lepší než Java.