Cześć. Zainteresowałem się ostatnio Scalą. Przypadła mi do gustu i nieco się zgłębiłem. Zastanawiam się jednak jaka jest jej przyszłość. Java 8 zniwelowała część większych zalet Scali. Poszperałem trochę w Internecie i frameworki Scalowe nie są uznawane za najlepsze/najwygodniejsze. Patrząc przez wzgląd czasu Scala jest na fali rosnącej, jednak nie jestem przekonany o jej potędze. Uczę się na razie z czystej ciekawości, coś jak odskocznia od Javy, ale zastanawiam się, czy z perspektywy osoby, która jako-tako ogarnia Javę(współbieżność kuleje) i nie pracuje jeszcze jako developer warto poświęcić Scali więcej uwagi.
0
2
Warto, bo to jednak język znacznie mocniej stawiający na paradygmat funkcyjny niż java 8. Zastąpić javy to on nie zastąpi, ale już stał się alternatywą do rozwiązywania pewnej klasy problemów.
1
Też miałem takie wrażenie po wyjściu Javy 8, ale tylko dlatego że o scali tylko czytałem. Teraz widzę że jest sporo fajnych rzeczy których w Javie nie ma. I zauważ że to co doszło w Javie 8, było już w scali od jakiegoś czasu, więc znając ją jesteś parę kroków do przodu.
0
Nie po raz pierwszy słyszę, że JVMowy język umiera bo Java dostała coś nowego :)
"Java dostała Promise'a/CompletableFuture, Clojure już do niczego nie będzie potrzebny"
"Java ma streamy, Scala już do niczego nie będzie potrzebna"
Generalnie:
- Streamy w obecnej formie są mocno niedoskonałe. Brakuje chociażby tupli.
- Streamy w obecnej formie potrafią być mniej wydajne od Scalowalnych odpowiedników, ZWŁASZCZA jeśli pewnych rzeczy się nie wie.
Czyli:
Streamy warto znać, warto używać, lambdy nawet wypada znać... Ale Java to ciągle język obiektowy i wprowadzenie lambd oraz streamów tego nie zmieni.
1
Ponieważ wiele praktycznego programowania polega na obsłudze efektów ubocznych np. wejście i wyjście IMO języki obiektowe i proceduralne będą dominować. Bez sensu komplikować sobie życie, jeśli programista do prostych rzeczy chce zrobić coś, co jest w rzeczywistości efektem ubocznym.
Wydaje mi się, że języki funkcyjne zostaną zamknięte w bibliotekach np. jar, ponieważ odizoluje to świat funkcyjny i obiektowy. I skończy się na tym, że programiści pisząc w Javie będą coraz częściej odpalać biblioteki pisane w Scali / Clojure.
Przeciętny programista pracujący w korporacji nie będzie uczył się Scali tylko po to, aby obiektowo zapisać w krótszy sposób ten sam kod. Dochodzi jeszcze utrudnione przekazywanie wiedzy, co jest minusem. Dlatego wierzę w zwiększenie popularności języków funkcyjnych do tworzenia skomplikowanych bibliotek (które trudno napisać obiektowo a np. łatwo funkcyjne, coś jak map reduce). Nie widzę większego sensu, aby pisać typowe biznesówki w Scali tylko po to, aby troszeczkę zwięźlej zapisać kod, który można napisać w Javie trzymając się standardu. Chyba, że pozwala to na rozwiązanie nowej klasy problemu: wtedy napisać to w egoztycznym języku i zamknąć w bibliotece.
0
@margor90
W Javie 8 dodano lambdy, wskaźniki na metody i streamy właśnie po to żeby można było pisać funkcyjnie. A jeszcze wcześniej ludzie udawali że java jest funkcyjna za pomocą guavy ale to skutkowało masą bolierplate code. Nie wyobrażam sobie żeby ktoś znał programowania funkcyjnego i pisał aplikacje biznesowe, bo wtedy nie będzie rozumiał co piszą jego koledzy.
0
Mam tego świadomość i widzę w jaki sposób mogłoby to ulepszyć moje kody operujące na kolekcjach. Mam świadomość łatwości zrównoleglania i korzyści z leniwego wykonania i na końcu zachłannej operacji (jednej zamiast wielu). Niestety w moich projektach w pracy jeszcze długo pracować będę z JDK 1.7 (to nie ode mnie tylko zależy). Braki Tupli obchodzimy na przykład za pomocą biblioteki (były potrzebne do złożonej logiki):
https://commons.apache.org/proper/commons-lang/javadocs/api-3.1/org/apache/commons/lang3/tuple/package-summary.html
Ogólnie sporo eksperymentuje ze strumieniami i kolekcjami (jak w domu się dokształcam na własną rękę). C# miał to w sumie od dawna, więc to żadna rewelacja, raczej nadgonienie języka konkurencji (MS).
Rezygnacja z pętli na rzecz strumieni mi się osobiście podoba. Nie wiem tylko czy tak od razu przekonałbym starszych kolegów, którzy nie zawsze czas mają nadganiać nowinki (kod piszę się dla ludzi). Więc to raczej zależy od konwencji na projekcie i jak się ludzie umówią.
2
W Scali można mocno zaszaleć. Gadanie, że Java dogania Scalę świadczy tylko o nieznajomości tematu :)
Poszperałem trochę w Internecie i frameworki Scalowe nie są uznawane za najlepsze/najwygodniejsze. Patrząc przez wzgląd czasu Scala jest na fali rosnącej, jednak nie jestem przekonany o jej potędze.
No właśnie. Scala jest jeszcze dość młoda, więc dobre frameworki dopiero się tworzą. Java miała dużo czasu, by powstało w niej coś przemyślanego pod kątem używalności. Stąd np opinie sprzed 5 lat dzisiaj mogą zupełnie nie przystawać do rzeczywistości.
Ponieważ wiele praktycznego programowania polega na obsłudze efektów ubocznych np. wejście i wyjście IMO języki obiektowe i proceduralne będą dominować. Bez sensu komplikować sobie życie, jeśli programista do prostych rzeczy chce zrobić coś, co jest w rzeczywistości efektem ubocznym.
Wydaje mi się, że języki funkcyjne zostaną zamknięte w bibliotekach np. jar, ponieważ odizoluje to świat funkcyjny i obiektowy. I skończy się na tym, że programiści pisząc w Javie będą coraz częściej odpalać biblioteki pisane w Scali / Clojure.
Scala nie utrudnia wywoływania efektów ubocznych. Możesz bezproblemowo pisać imperatywny kod w Scali gdzie tylko zechcesz. Ba, możesz użyć Scali jako Javy bez średników i wyjdzie wtedy JalaTM. Łatwość przeplatania kodu funkcyjnego z imperatywnym daje duże możliwości do pisania jak największej ilości kodu funkcyjnie.
1
Scala nie utrudnia wywoływania efektów ubocznych. Możesz bezproblemowo pisać imperatywny kod w Scali gdzie tylko zechcesz. Ba, możesz użyć Scali jako Javy bez średników i wyjdzie wtedy JalaTM. Łatwość przeplatania kodu funkcyjnego z imperatywnym daje duże możliwości do pisania jak największej ilości kodu funkcyjnie.
Oczywista rzecz: Scala to nie Haskell. Pytanie po co podejmować ryzyko tylko po to aby się pobawić. Bo używanie Scala do pisania imperatywnego kodu to jest jednak zabawa: a bawienie się na produkcji to zbędne ryzyko. W przypadku Play Framework oraz Akka częściej spotyka się aplikacje pisane w Javie niż Scali. Ponieważ łatwiej znaleźć i zatrudnić programistę języka Java. Ponieważ Java jest prostsza: bo jest znana (jak COBOL, który jest wszędzie, ale nikt się tym specjalnie nie chwali, bo po co). A prostota jest dobra. Liczy się zysk ze sprzedaży oprogramowania i niskie koszty utrzymania. Skoro można uniknąć ryzyka IMO warto to robić. Jeżeli Scala pozwala na rozwiązanie biznesowego problemu wydajniej i szybciej to jest wtedy oczywiście lepszym wyborem niż Java. Ja jednak nie wierzę w złote młotki i moim zdaniem te języki będą istnieć obok siebie i wzajemnie się uzupełniać.
Przykład z życia, że to co znane jest prostsze:
- jest sobie dość fajna biblioteka JavaCV
- do biblioteki zostały dodane sample, fajnie
- niestety zostały napisane w Scali:
https://github.com/bytedeco/javacv-examples/tree/master/OpenCV2_Cookbook/src/main/scala/opencv2_cookbook - efekt jest taki, że ich przeczytanie zostaje utrudnione: ktoś miał kaprys i napisał to w Scali. Bo można. Bo czemu nie. Jednak kod pisze się dla ludzi. Dla mnie to było tylko spowolnienie pracy. Poradziłem sobie, ale po co komplikować życie. Kod jest pisany dla ludzi.
- i tak fajnie, że napisał: nie mógł zrobić tego wcale. Może chciał przy okazji poćwiczyć Scale. Szanuje to. Jednak uważam, że to utrudnia przekaz.
Osobiście po dobrym opanowaniu Javy 8 zamierzam zacząć pisać projekty, aby się nauczyć w Scali. Czy ktoś z Was próbował Spring for Scala? Czy zdaniem autorów projekt jest na tyle stabilny, że można myśleć o wykorzystaniu produkcyjnym?
0
Gdzieś, kiedyś czytałem że Java powstała jako język prosty i zapobiegający tworzeniom błędów w porównaniu np. do C++. I faktycznie, Java na samym początku była językiem bardzo prostym składniowo. Wraz z rozwojem dostawała kolejne elementy i możliwości stając się tym samym trudniejsza, ale nawet wersja 8 jest prosta i do ogarnięcia przez ludzi o poziomie poniżej przeciętnego programisty. To co faktycznie podnosi poprzeczkę w tym łatwym języku to masa bogatych frameworków które skutecznie podnoszą poziom. Jeżeli weźmiemy pod uwagę całość, to już nie jest tak prosto i jest wiele łatwiejszych połączeń jak django+python, ROR czy nawet PHP. Dlatego uważam że jeżeli ktoś jest Javowcem i to nie c playerem, to scalę spokojnie ogarnie.
0
W przypadku Play Framework oraz Akka częściej spotyka się aplikacje pisane w Javie niż Scali.
Masz jakieś twarde dane na ten temat?
Bo ja mam twarde dane robione przez nasz dział marketingu odnośnie wykorzystania Sparka i użycie API Sparka wygląda następująco:
Scala - ok. 50%
Python - ok. 30%
Java - ok. 20%
API Akka w Javie jest paskudne, podobnie pisanie w Playu w Javie.
Oczywista rzecz: Scala to nie Haskell. Pytanie po co podejmować ryzyko tylko po to aby się pobawić. Bo używanie Scala do pisania imperatywnego kodu to jest jednak zabawa: a bawienie się na produkcji to zbędne ryzyko.
Scala ma jeszcze jedną potężną przewagę nad czystą Javą - system typów. Scala jest inna niż Haskell, ale pod względem siły systemu typów dość zbliżona.
A co do ryzyka pisania kodu imperatywnego w Scali, to nie bardzo rozumiem. Mógłbyś rozwinąć?
0
Oczywista rzecz: Scala to nie Haskell. Pytanie po co podejmować ryzyko tylko po to aby się pobawić. Bo używanie Scala do pisania imperatywnego kodu to jest jednak zabawa: a bawienie się na produkcji to zbędne ryzyko.
Ja też nie rozumiem tego fragmentu. Jakie ryzyko? Sorry, ale nie da się programować czysto funkcyjnie. W Haskellu są monady IO, które są niby czysto funkcyjne, ale do mnie to nie przemawia (są dla mnie odpychające). Są np bindingi Haskella do GTK - czy to oznacza, że w jakiś magiczny sposób GTK stał się czysto funkcyjny? Niet. Program Haskellowy musi się dogadywać z GTK w taki sam sposób jak każdy inny program, czyli imperatywnie. Podobnie z każdymi innymi operacjami wejścia/ wyjścia, operacjami na buforach (mutable Array), itd