Scala jako główny język w projekcie

1

Miałem dziś pogadankę z kolegą na temat Scali i z tej rozmowy naszła mnie taka rozkminka

Jakie faktyczne zalety Scali możnaby przedstawić, gdyby przy kick-offie projektu ktoś was zapytał: "dlaczego ten nowy projekt chcecie w Scali, a nie Javie? przeciez w pisanie w Javie idzie nam dobrze, po co wprowadzać nowy język (w dodatku 'trudniejszy')?"

Z takiego punktu widzenia: firma istnieje po to, żeby zarabiać hajs (przynajmniej te tworzące masowo software), więc zmiany muszą być poparte realnymi argumentami. "Biznes" przyjmie coś lub nie jak realnie pokażemy, że warto.

Są firmy gdzie stos technologiczny jest dosłownie dowolny i w 100% zależny od developerów. A choć nawet wtedy czasem ciężko nakłonić kolegów do zmiany tego "javowego comfort zone". W większość firm jednak jakiś stos jest przyjęty, ktoś nad tym czuwa, decyzyjny jest architekt, czy jacyś head devowie.

@Wibowit wołam Cię, bo liczę, że znasz odpowiedź na to pytanie ;)

3

Wideo w temacie
https://vimeo.com/217843501

Dla mnie głównym argumentem za scalą jest łatwość pisania kodu funkcyjnego => czytaj immutables everywhere. W javie się da, ale wychodzą hektolitry literek i średnio to wygląda.
Pisze w obu językach (choć ostatnio więcej w kotlinie) i w Javie czuję się jak przeciętny Javowiec w JS - niby sie da pisac, ale trochę jest jak na polu minowym.
Druga zaletą scali jest mniejsza popularność magicznych frameworków - ludzie radzą sobie bez Autowiredów, Springów i JavaEE. Nie ma beanów!

Trzecia zaleta to zwięzłość języka i api bibliotek(!).
Wystarczy porównać kod : w javie chcemy odpalić komende bash i zapisać wynik do Stringa.
Mamy całe elaboraty na so:
https://stackoverflow.com/questions/5711084/java-runtime-getruntime-getting-output-from-executing-a-command-line-program

w Scali

 val result = "ls -al" !! 

Po prostu w Javie jak ktoś bibliotekę robi to musi zacząć od MyConfiguratoionFactoryBuilderImpl.getIstance().newFactory().build().... nie może po prostu zrobić jednej metody, która by po prostu robiła robotę.

Z przykładów jak ładnie może wyglądać kod w Scali możn np. popatrzeć na testy:
http://www.scalatest.org/user_guide/selecting_a_style

Od pół roku w ramach kompromisu (z zespołem) pisze w kotlinie - to taka Scala--. Nie ma po prostu najtrudniejszych ficzerów. Tak uczciwie dopiero teraz po pół roku naprawdę mi iektórych brakuje. Robie powdrożeniowy refaktoring i chciałem upiększyć nieco kod - kupa (generyki się rozlazły - w kotlinu nie umiem tego poprawić). Tym niemniej nadal jest wiele razy lepiej niż w Javie.
Wiele bibliotek kotlinowych wzoruje się na Scali (np. kotlintest).

5

Primo, ktoś powinien znać Scalę już dobrze, bo inaczej już na starcie narobicie dziadostwa i potem będzie to trzeba długo odkręcać :)

Zakładając, że macie kogoś kto ogarnia Scalę, to zalety są np takie:

  • dobre wsparcie dla programowania funkcyjnego, ale takiego prawdziwego (tzn jest komplet kolekcji niemutowalnych, trwałych, takich gdzie metoda list.add tworzy nową listę, a nie rzuca exceptiona czy modyfikuje istniejącą listę), a nie źle zrozumianego (typu: mam lambdę, więc programuję funkcyjnie),
  • kod jest znacznie zwięźlejszy, przez co szybciej się koduje pomysły i jest mniejsza potrzeba magicznych bibliotek, które refleksją łatają rozwlekłość języka (np Lombok, ale też biblioteki do wstrzykiwania, bo to jest w Javce modne) - brak refleksji i wzbogacania bajtkodu w czasie wykonania oznacza łatwiejsze debugowanie i łatwiejsze zrozumienie mechaniki programu
  • kompozycja jest przyjemna bo można zrobić rzeczy typu:
class Xyz(val abc: Int, val sdf: Int)
class Zxc(parametr: Xyz) {
  import parametr._ // importuję pola z 'parametr'
  def metoda(): Int = abc // nie muszę pisać: parametr.abc, bo zaimportowałem pola z 'parametr'
}

wygodna kompozycja pomaga unikać dziwacznych i niepotrzebnie skomplikowanych hierarchii dziedziczenia

  • zwięzła składnia zachęca też do pisania łatwiej testowalnego kodu
  • solidne i dojrzałe wsparcie dla programowania asynchronicznego, reaktywnego, rozproszonego, klastrów, itp itd za sprawą Akki: https://akka.io/docs/
  • Akka ma sporo modułów, opisywanie ich wszystkich sporo by zajęło, ale generalnie Akka jest praktycznie takim Scalowym odpowiednikiem Springa ze świata Javy, tzn Akka jest tak samo popularna i ważna w projektach Scalowych jak Spring w Javowych
  • na upartego można kodzić w Scali jak w Javie na początku (tzw Jala - Java bez średników) i dopiero z czasem wrzucać coraz więcej Scalowych idiomów,
0

Historia komputerów wskazuje na to że języki super zwięzłe nie są tymi najlepszymi.
Perl - wyeliminowany
C/makra - wszyscy hejtują

A co królowało lub nadal jest używane?

  • COBOL
  • BASIC
  • Pascal, Ada
  • Delphi
  • Java

Te dwa wykrzykniki mogą sugerować że Scala to taki JPerl. Co to oznacza dla tego języka - nie chcę nic mówić, ale to raczej jasne.

0

Perl zdycha, ale Python chyba mu jakoś mocno zwięzłością nie ustępuje

0

Z ciekawości wyguglane - do obejrzenia dla tych co znają Scale:

http://greenteapress.com/thinkperl6/html/thinkperl6015.html

1

Plusy jakie widzę po pół roku komercyjnej pracy w Scali:

  • Potrzeba zdecydowanie mniej czasu na zakodowanie dokładnie tej samej funkcjonalności, a czas to pieniądz
  • Brak magicznych frameworków i annotation driven development - jesteś w stanie zrozumieć kod bez patrzenia w dokumentację co robi dana adnotacja
  • System typów jest na zupełnie innym poziomie co pozwala na pisanie bardzo ogólnych abstrakcji, które później można wykorzystywać w innych miejscach bez większego problemu
  • Programowanie funkcjonalne i wszystkie plusy które z tego wynikają
  • Prostota używania programowania asynchronicznego, czy to poprzez Akke, czy Future'y czy inne Taski (chociaż nie zawsze jest tak pięknie)
  • W większości przypadków kod jest pisany w taki sposób, że otestowanie go nie stanowi żadnego problemu - poprawnie napisany kod w Scali nie wymaga żadnego Mockito czy innego PowerMocka. Cytując Sam'a Halliday'a "Functional programming could be described as Extreme Mocking"
2

Nie do końca się zgodze z tymi kolekcjami niemutowalnymi jako super przewaga Scali, wszakże jest Vavr. Chociaż problem jest taki że trudno Javovców do Vavra przekonac :D

0
Wibowit napisał(a):

Perl zdycha, ale Python chyba mu jakoś mocno zwięzłością nie ustępuje

Jako Pythonowiec - Python ma duże szanse przetrwać i dalej być popularnym - wynika to głównie z tego, że chłopaki tworzący Python'a mają na tyle dużo nerwów, że łamią kompatybilność wstecz i orają błędy projektowe języka i to poprawiają np. ostatnie uporządkowanie programowania asynchronicznego i wprowadzenie async / await np.

Jakie faktyczne zalety Scali możnaby przedstawić, gdyby przy kick-offie projektu ktoś was zapytał: "dlaczego ten nowy projekt chcecie w Scali, a nie Javie? przeciez w pisanie w Javie idzie nam dobrze, po co wprowadzać nowy język (w dodatku 'trudniejszy')?"

Dla mnie jest parę rzeczy do uwzględnienia przy wyborze języka do projektu:

  • czy dany język ma rozwiązanie na mój problem biznesowy (np. zbiór dojrzałych bibliotek)
  • jaki język znam najlepiej/ zna zespół i mam pewność w nim, aby wystartować z nowym produktem?
  • jeśli projekt nie jest jakiś krytyczny i mam dużo dowolność to co nowego chciałbym wypróbować? :)
  • czy język nie jest jakąś porażką jeśli chodzi o jego design
0
Wibowit napisał(a):
  • dobre wsparcie dla programowania funkcyjnego, ale takiego prawdziwego (tzn jest komplet kolekcji niemutowalnych, trwałych, takich gdzie metoda list.add tworzy nową listę, a nie rzuca exceptiona czy modyfikuje istniejącą listę), a nie źle zrozumianego (typu: mam lambdę, więc programuję funkcyjnie),

To jest jakoś sprytnie zaimplementowane, że cała kolekcja nie jest kopiowana przy modyfikacji?

1
student pro napisał(a):
Wibowit napisał(a):
  • dobre wsparcie dla programowania funkcyjnego, ale takiego prawdziwego (tzn jest komplet kolekcji niemutowalnych, trwałych, takich gdzie metoda list.add tworzy nową listę, a nie rzuca exceptiona czy modyfikuje istniejącą listę), a nie źle zrozumianego (typu: mam lambdę, więc programuję funkcyjnie),

To jest jakoś sprytnie zaimplementowane, że cała kolekcja nie jest kopiowana przy modyfikacji?

Jeśli kolekcja jest niemodyfikowalna to tak de facto nie trzeba nic kopiować. Dodanie kolejnego elementu do np. listy to jest stworzenie nowej struktury, gdzie head wskazuje na nowy element, a tail na "starą" liste

3
student pro napisał(a):
Wibowit napisał(a):
  • dobre wsparcie dla programowania funkcyjnego, ale takiego prawdziwego (tzn jest komplet kolekcji niemutowalnych, trwałych, takich gdzie metoda list.add tworzy nową listę, a nie rzuca exceptiona czy modyfikuje istniejącą listę), a nie źle zrozumianego (typu: mam lambdę, więc programuję funkcyjnie),

To jest jakoś sprytnie zaimplementowane, że cała kolekcja nie jest kopiowana przy modyfikacji?

Dokładnie tak. Doklejanie elementu na przód listy jednokierunkowej jest operacją o czasie stałym. Jeśli zbiory i mapy masz oparte o drzewa to stworzenie nowego drzewa ogranicza się do stworzenia nowej ścieżki w drzewie z referencjami do starych poddrzew. Więcej informacji:
https://en.wikipedia.org/wiki/Persistent_data_structure
http://www.vavr.io/vavr-docs/
https://medium.com/@dtinth/immutable-js-persistent-data-structures-and-structural-sharing-6d163fbd73d2

Nie wszystkie operacje daje się efektywnie zaimplementować czysto funkcyjnie, więc np nierzadko spotyka się idiom w którym np doklejamy elementy na przód listy (czyli w odwrotnej kolejności), a na końcu odpalamy list.reverse by powrócić do początkowej kolejności. Zwykle się jednak tego nie robi bo najczęściej wykorzystuje się kombinatory, które tego nie wymagają, typu list.filter, list.map, list.flatMap, list.collect, list.find, list.sorted, list.take, list.headOption, itp itd

Dodatkowo Scala oprócz zestawu niemutowalnych kolekcji ma zestaw mutowalnych kolekcji, więc lokalnie możesz stworzyć sobie mutowalną kolekcję, ale przed zwróceniem jej z metody czy zapisem do pola klasy możesz tę mutowalną kolekcję przekonwertować na niemutowalną. W ten sposób ograniczasz dość mocno generowanie śmieci (tzn krótko żyjących obiektów) przy budowaniu kolekcji w małych krokach, ale jest to już optymalizacja tam gdzie jest to potrzebne (bo np sprofilowałeś kod i zdecydowałeś, że w tym i tym miejscu warto go przyspieszyć).

0

języki super zwięzłe nie są tymi najlepszymi

Masa firm szczególnie w stanach i azji, jedzie od dekady całe projekty tylko w Pythonie. Szczególnie te związane z AI, ale również sporo webdevu itp.

4

Potrzeba zdecydowanie mniej czasu na zakodowanie dokładnie tej samej funkcjonalności, a czas to pieniądz

Trudno mi w to uwierzyć, bo 90% czasu to jest wymyślanie "jak" coś zrobić i nie ma tu znaczenia czy będziesz to klepać w Scali, Javie czy brainfucku. Chyba że liczysz tylko czas "klepania" i bierzesz pod uwagę że w Scali kodu będzie mniej, ale to idiotyczna metryka.

jesteś w stanie zrozumieć kod bez patrzenia w dokumentację co robi dana adnotacja

:D Na pewno, z jakimiś implicitami i cudami na kiju. I call bullshit. Można w Scali napisać takie kilka linijek, że potem godzinę ktoś będzie rozkminiał co tam się dzieje.

2

Trudno mi w to uwierzyć, bo 90% czasu to jest wymyślanie "jak" coś zrobić i nie ma tu znaczenia czy będziesz to klepać w Scali, Javie czy brainfucku. Chyba że liczysz tylko czas "klepania" i bierzesz pod uwagę że w Scali kodu będzie mniej, ale to idiotyczna metryka.

W takim razie nie ma znaczenia czy będziesz klepać w Javie czy w Pythonie czy w C. Ergo, Python jest zbędny, klepmy w C, bo C jest uniwersalne.

:D Na pewno, z jakimiś implicitami i cudami na kiju. I call bullshit. Można w Scali napisać takie kilka linijek, że potem godzinę ktoś będzie rozkminiał co tam się dzieje.

Jak piszesz w notatniku to ci nie podpowie skąd się biorą implicity, ale IntelliJ sobie spokojnie z nimi radzi i może je pokazać.

0
Shalom napisał(a):

Potrzeba zdecydowanie mniej czasu na zakodowanie dokładnie tej samej funkcjonalności, a czas to pieniądz

Trudno mi w to uwierzyć, bo 90% czasu to jest wymyślanie "jak" coś zrobić i nie ma tu znaczenia czy będziesz to klepać w Scali, Javie czy brainfucku. Chyba że liczysz tylko czas "klepania" i bierzesz pod uwagę że w Scali kodu będzie mniej, ale to idiotyczna metryka.

Biorę pod uwagę to, jakie narzędzia oferuje mi język i co jestem w stanie w nim zrobić. Pierwszy przykład z brzegu: oczekuje F[G[]] ale mam G[F[]]. Oczywiście w obu językach jesteś w stanie napisać rozwiązanie, pytanie w którym to zrobisz szybciej.

jesteś w stanie zrozumieć kod bez patrzenia w dokumentację co robi dana adnotacja

:D Na pewno, z jakimiś implicitami i cudami na kiju. I call bullshit. Można w Scali napisać takie kilka linijek, że potem godzinę ktoś będzie rozkminiał co tam się dzieje.

W każdym języku jesteś w stanie napisać kod, którego nikt nie zrozumie. Jeśli używa się implicitów wszędzie gdzie popadnie to zapewne tak się skończy.

0

W takim razie nie ma znaczenia czy będziesz klepać w Javie czy w Pythonie czy w C. Ergo, Python jest zbędny, klepmy w C, bo C jest uniwersalne.

Jeśli chodzi o logikę aplikacji o trochę tak jest. Niemniej akurat C to wysokopoziomowy asembler więc bym go w to nie mieszał. Różnica jest na dostępności bibliotek i możliwości integracyjnych. Dlatego pisze się więcej w C niż w Pascalu, albo w Javie niż w Smalltalku.

Jak piszesz w notatniku to ci nie podpowie skąd się biorą implicity, ale IntelliJ sobie spokojnie z nimi radzi i może je pokazać.

To samo można powiedzieć o magicznych adnotacjach ;) Pytanie tylko czy to nadal jest czytelny kod, jeśli potrzeba skomplikowanych narzędzi żeby go czytać ze zrozumieniem?

Ja nie chce tu być brany jako anty-skalowy, technologia to technologia, ani lepsza ani gorsza. Odnoszę się tylko do tego, ze podane argumenty za "lepszością skali" są śmieszne.

0

Jeśli chodzi o logikę aplikacji o trochę tak jest. Niemniej akurat C to wysokopoziomowy asembler więc bym go w to nie mieszał. Różnica jest na dostępności bibliotek i możliwości integracyjnych. Dlatego pisze się więcej w C niż w Pascalu, albo w Javie niż w Smalltalku.

Z poziomu Scali możesz korzystać z wszelkich bibliotek Javowych i to bez konieczności pisania glue-code. Podobnie z poziomu Scali.js możesz korzystać z wszelakich bibliotek JavaScriptowych bez glue-code, aczkolwiek w tym przypadku glue-code jest potrzebny do poprawnego otypowania.

To samo można powiedzieć o magicznych adnotacjach ;) Pytanie tylko czy to nadal jest czytelny kod, jeśli potrzeba skomplikowanych narzędzi żeby go czytać ze zrozumieniem?

Podejrzenie skąd się bierze implicit to dwie sekundy: https://blog.jetbrains.com/scala/2011/10/25/show-implicit-parameters-action/

Jak w dwie sekundy sprawdzić jak wygląda kod wygenerowany z kodu z adnotacjami?

1

Z ciekawostek, trochę w tej Scali już pisałem, ale wyszukiwania skąd się bierze implicit potrzebowałem prawie raz.

Implicity w scali służą do rozwiązywania podobnych rzeczy co adnotacje w Springu, tylko że jest jedna, kolosalna różnica.
Implicity rozwiązuje kompilator i jak coś walniesz to kompilator Ci oświadczy. Bytecode wygenerowany jest jeden i jego działanie nie zależy od humoru kontenera, wersji bibliotek i wpakowanych do projektu jarów, ani czy komuś się nie zapomni i wywoła this.iAmCallingMethodWithAnnotationButSomehowIHaveNoLuck().
Krótko mówiąc adnotacje kontenerowe to bardzo niebezpieczna i biedna wersja impicitów. Z jednych i drugich lepiej przesadnie nie korzystać.

1

Mało kto poruszył kwestie biznesowe, ale tak na poważnie...

Weźmy scenariusz, że projekt zaczyna, znacie sobie Scale i dostajecie deadline + budżet + sznurek na wasze jajka w razie, gdyby dwa pierwsze się nie zgrały w linii czasowej.
W czasach, gdy programistów Javy łapie się z przypadku jak motyle w siatkę na słonecznej łące pewnie oni będą pierwszym wyborem. Bo Java, bo JVM, liby, devy, itp. Bo nikt, komu cenne jego jajka i spokojny sen, nie będzie szukał sobie miesiącami kilku geeków w Scali, a po roku będzie na skraju załamania nerwowego, że znalazł tylko 2 (z 10 wymaganych do projektu dajmy na to), których budżet przekracza i tak 6 "zwykłych" programersów w Javie. Niechby i nawet 2 programowało za 4, ale kto żyw, zrozumie swój błąd i pewnie zatrudni tych od Javy ukradkiem i później będzie ich błagał codziennie o naukę Scali licząc na mniejsze skarcenie od losu, że za argumenty typu "też jvm", "funkcyjne" albo "lepsza Java" może się łaskawie dadzą przekonać przy 101 pizzy integracyjnej w biurze. Do tego dochodzi kwestia dostępności bibliotek, kwestia rotacji zespołu (wszakże jednemu Scalowcowi może nie spodobać się kolor sufitu, drugiemu kąt nachylenia jego biurka stojącego). A mówimy tu tylko o nowym projekcie, co do którego mamy swobodę wyboru technologii, byle zrobić i zmieścić się w budżecie...

0

To jest jakiś szczególny problem ze Scalą czy może dotyczy każdego języka innego niż Java?

Od siebie dodam historię z firmy w której pracuję, czyli HSBC. Oferta pracy napisana przez kierownika + HRy była strasznie kiepska i dlatego wiele miesięcy szukaliśmy nowego Scalowca. Kierownik zachorował, więc wziąłem tę ofertę, poprzerabiałem, potem dołączyli do mnie koledzy z zespołu (razem kmniliśmy nową wersję) i z tą nową ofertą pracy kandydaci znajdowali się bardzo szybko. Od wielu miesięcy nie prowadzimy rekrutacji na kolejnego Scalowca, bo nie ma na niego budżetu (mimo iż cały zespół pracuje w Scali).

0
TurkucPodjadek napisał(a):

Mało kto poruszył kwestie biznesowe, ale tak na poważnie...

Weźmy scenariusz, że projekt zaczyna, znacie sobie Scale i dostajecie deadline + budżet + sznurek na wasze jajka w razie, gdyby dwa pierwsze się nie zgrały w linii czasowej.
W czasach, gdy programistów Javy łapie się z przypadku jak motyle w siatkę na słonecznej łące pewnie oni będą pierwszym wyborem. Bo Java, bo JVM, liby, devy, itp. Bo nikt, komu cenne jego jajka i spokojny sen, nie będzie szukał sobie miesiącami kilku geeków w Scali, a po roku będzie na skraju załamania nerwowego, że znalazł tylko 2 (z 10 wymaganych do projektu dajmy na to), których budżet przekracza i tak 6 "zwykłych" programersów w Javie. Niechby i nawet 2 programowało za 4, ale kto żyw, zrozumie swój błąd i pewnie zatrudni tych od Javy ukradkiem i później będzie ich błagał codziennie o naukę Scali licząc na mniejsze skarcenie od losu, że za argumenty typu "też jvm", "funkcyjne" albo "lepsza Java" może się łaskawie dadzą przekonać przy 101 pizzy integracyjnej w biurze. Do tego dochodzi kwestia dostępności bibliotek, kwestia rotacji zespołu (wszakże jednemu Scalowcowi może nie spodobać się kolor sufitu, drugiemu kąt nachylenia jego biurka stojącego). A mówimy tu tylko o nowym projekcie, co do którego mamy swobodę wyboru technologii, byle zrobić i zmieścić się w budżecie...

Jeśli ktoś wybiera język do danego projektu "bo tak" to już nie wróży nic dobrego ;) Wiadomo, że jeśli aplikacja ma być np. typowym CRUDem to nie ma sensu brać Scali. Tak samo jeśli z góry wiadomo, że nie ma się zespołu który mógłby rozkręcić taki projekt, a jednocześnie ciężko jest znaleźć programistów danego języka w mieście. Trzeba dostosować wybór technologii do tego co się chce robić i warunków które aktualnie panują na rynku pracy.

Przeglądając oferty pracy w Scali to głównie jest to Big Data lub projekty, które już zostały rozpoczęte i potrzeba kolejnych osób (w tym takich, które chcą się nauczyć Scali, a niekoniecznie ją jeszcze znają). W obu przypadkach można założyć, że nacisk kładziony jest na co innego niż w projekcie typu "macie deadline do XX.XX i ani dnia dłużej"

4

Te argumenty za dostępnością programistów itp. to w dużym stopniu mity.

  1. Sam należe do grupy programistów, która babra sie w Javie i Kotlinie, mimo, że w Scali pisze za niższą stawkę - jesli znajde projekt (miesiąc /półtora na rok mi wychodzi). Znam takich jak ja kilku. Mam wrażenie, że jest wręcz nadpodaż scalowców,
    pamiętam jeszcze jak parę lat temu firmy w rekrutacji wstawiały Scalę od czapki, żeby przyciągnać ludzi (fakt, że już tego nie robią).
  2. Rozsądnego javowca jest znaleźć bardzo trudno. Fakt, że mięso armatnie się da - tylko pytanie czy w krytyczny projekt chcesz wzucać takie mięso. (mamy z tym problem)
  3. Jeśli się da zrobic nieco mniejszą liczbą ludzi to samo to zwykle warto, bo oprócz oszczędności na kasie dochodzą oszczędności na komunikacji.
  4. Fakt ,że logika biznesowa jest nudna i moim zdaniem pisze ją się tak samo żmudnie w Scali, jak w Javie - to na takim middleware i glue kodzie się raczej oszczędza. (tu Paweł Szulc by mnie zastrzelił, ale ja po prostu nie dorosłem do Free Monad).
  5. Róznice są dopiero na utrzymaniu. W scali każde dodanie nowego ficzera, nie grozi wywaleniem całego projektu, bo się przestaną obiekty do bazy zapisywać w JPA (to taki stary case, który kiedyś widziałem). Choć tu jest po części efekt fp, a po części mniejszej magiczności frameworków.

Z wad scali, o których warto wiedzieć.

  1. Czasy kompilacji - są juznawe specjalne kompilatory (komercyjne), ale trzeba wiedzieć , że są i trzeba umieć stosować - master od sbt, + hydra w większym projekcie się przyda.
  2. League of legends - Bruce Eckel atakuje Scalowe community tu https://vimeo.com/110827281 (28 minuta mniej więcej) i to niestety prawda, znam już historie gdzie projekty jęczały przez to, że chłopaki kłócili się o powiedzmy czystość rozwiązań. Plus przepisywanie z Lift na Play, a potem na Akkę - bo stare niemodne (trochę jak w JS).
  3. Tooling - W Scali jest trochę gorszy, kiedyś był dramat - teraz jest po prostu mniej dojrzały - tu chodzi o toole do np. sprawdzania stylu itp., jakość IDE itp.
  4. Niekompatybilności - dramaty z przejściem od jednej wersji scali do drugiej się zdarzają niestety - czasem nie da się łatwo zmigrować całego projektu, bo pare durnych bibliotek nadal jest tylko dla scali 2.11 i na 2.12 nie idą. (to chyba już przeszłość , ale wlezie 2.13 czy jeszcze zabawniej Scala 3.0 i będzie dramat znowu pewnie). Do tego wszestkie kwestie związane z tym, że pod spodem jest jvm, które też ma wersje...
  5. Nie ma tyle dziwnych błedów w runtimie co w javowych cudach, ale za to czasem rozkminianie błedu kompilatora potrafi zając dużo czasu. To się poprawia, ale wolno. Był nawet tool tlumaczący popularne błędy na ludzki - ale chyba ostatnio się nie rozwija. https://github.com/softwaremill/scala-clippy
  6. Nigdy jeszcze nie zajmowałem sie optymalizacją wydajnościową kodu Scalowego, nie wiem jak by sie cały mój tooling, który znam do javy sprawdził. I w javie często profiler pokazuje bzdury, jak się na to dołoży kolejna warstwę - to może być ciężko.
0

A moze spójrzcie na to z biznesowego punktu widzenia.
Jesli programistów SCALi jest Malo, a do tego nie sa jakos bardzo doświadczeni to pozyskanie programisty z rynku bedzie droga przez mękę. Tak wlasnie pracuje w takim projekcie. Kierownik projektu wymysla powody dla których ruby jest lepszy od o wiele popularniejszych języków. Ciągle jakies telefony, dywaniki itd. Bledy biznesowe tez często się ciągną za projektem. A pisanie w czymś co za kilka miesięcy będzie trzeba zmienić bo okaże sie ze jest masa błędów jest zwyczajnie bez sensu.

0

@kate87
Zawsze zastanawiałem się jaki imbecyl biznesowy zaczął zatrudniać tych wszystkich javowców w roku mniej więcej 1999. Nie dość, że ta java wtedy to była biedna i wolna, microsoft promował skutecznie nikompatybilną wersję (J++), to jeszcze programistów javy praktycznie nie było, a jeśli już, to z zerowym doświadczeniem.
W odróżnieniu od C++ na przykład, żeby nie było: jestem dokładnie C++owcem, który dostał pracę w javie. Myślałem, że to taka śmieszna odskocznia na trochę, potem wrócę do poważnego programowania .

0

Java na początku swojej kariery (lata 90-te) w stosunku do C++ miała kilka znaczących zalet:

  • wielowątkowość (C++: 2011)
  • przenośność między systemami bez wymogu rekompilacji
  • większa czytelność kodu (np. tablice, łańcuchy - zawsze są obiektami a nie tylko czasami - C++: array - 2011, string_view - 2017)
  • brak wszelkiego rodzaju pułapek znanych z C++ (nie było nawet generyków, nie ma unsigned, preprocesora)
  • możliwość włączania rozszerzeń obiektowych w czasie runtime do aplikacji - wbudowana w środowisko (ClassLoader)
  • prawdziwe moduły a nie pliki includowane (co po stronie C/C++ jest zdaje się pomysłem typu "bo tak!")

A co ma takiego dzisiaj Scala żeby zawalczyć o prym z Javą? FP?

0
vpiotr napisał(a):

A co ma takiego dzisiaj Scala żeby zawalczyć o prym z Javą? FP?

Dokładnie:
FP ,niemutowalne struktury i obiekty - najważniejsze.

Dodatkowo:
Ekspresywność: przez co nie trzeba pisać tony innych jezyków, żeby np. robić sensowne testy (see w javie cucumber, groovy spock itd.). DSLe to chyba praktycznie jeden z najważniejszych biznesowo featurów.
Brak potrzeby polegania na refleksji - prawie wszystko zrobi kompilator. kompilator powie, że obiekt nie da rady zserializować do json, zanim to się wywali na produkcji.
Sensowniejszy system typów. Generyki javowe to ani nie wyszły tak proste, jak twórcy chcieli, ani mocne (ale to akurat nie było celem).

Tony rzeczy mozna by wymieniać. Tak jak Java łatała problemy zoabserwowane przy pracy z C++ nad dużymi projektami sieciowymi (np. w CORBIE), tak Scala miała łatac problemy zaobserwowane w projektach biznesowych w Javie (następny krok).
Kotlin to z kolei wersja dla tych, którzy przestraszyli się ile tego w Scali jest :-)

6

Ja tu myślę, że warte podkreślenia jest to, że nawet najlepszy język czy technologia nie sprawi, że projekty zaczną firmie wychodzić, dlatego o ile firmy muszą świadomie ponosić ryzyko dotyczące mniejszej liczby dostępnych programistów. Tak to to w przypadku programisty taka sytuacja jest jak najbardziej OK: spoko ludzie, dobra kasa i ciekawe technologie:

  1. Pracując w technologiach, które nie trafiają do klapaczy gratis otrzymujesz możliwość pracy bez klepaczy.

  2. Gdy jest mało programistów to próg wejścia na rekrutacji jest niższy i jednoczesnie łatwiej można wynegocjować spoko warunki.

  3. To, że scala jest mało popularna to akurat plus dla programistów, którzy chcą robić w niej coś więcej niż crudy i utrzymywanie enterprajsowego shitu.

  4. W pewien sposób zabezpieczasz tyły, bo nie jesteś łatwym trybikiem do wymiany.

PS, żeby nie było w tym hipokryzji. To startuję ze Scala dziś :-)

2

No to bardzo ciekawe i nowe wideo od Johna w temacie. Właśnie oglądam i jest mocne:

John to jeden z najciekawszych gości w FP. Dośc powiezieć, że to guru Pawła Szulca (a Paweł jest moim :-) ).

0

@jarekr000000: nie oglądałem całego, pare fragmentów sprawidziłem tylko, jak będę miał więcej czasu to obejrze całośc ale no ten początek optymistyczny nie jest. Nie mniej co do "reified generics" to nie słyszalem żeby miało to być w JDK 11 wprowadzone

1 użytkowników online, w tym zalogowanych: 0, gości: 1