Dlaczego te próby zlikwidowania Scali za pomocą Xtend i Kotlin? [Zamknięte]


26

Teraz Eclipse oferuje Xtend, a JetBrains oferuje Kotlin - oba wydają się być rozwodnioną wersją Scali. Moje pytanie brzmi: dlaczego? Grałem trochę ze Scalą i nie jest to takie trudne. Czy to tylko reakcja na nieodłączną trudność przejścia z trybu imperatywnego na funkcjonalny, czy może działa tu jeszcze coś innego?


EDYCJA: Przeprosiny. Ponownie czytając pytanie, jak je pierwotnie opublikowałem, widzę, że brzmi to trochę jak trolling. Sposób, w jaki sformułowałem pytanie, wydawał się po prostu najlepszym sposobem na zadanie pytania. Widziałem posty na blogu, że efekt „Scala jest zbyt trudna / Scala jest zbyt złożona”, a także „Kotlin to próba zrobienia Scali, ale prostsza”. Zostawię frazowanie tak, jak było na początku, ale szczerze mówiąc, nie próbowałem trollować.


20
Wydaje mi się, że jestem wielkim fanatykiem po prostu zakładając, że nowy język, który ma pewne podobieństwo do Scali, musi być „rozwodnioną wersją Scali” napisaną przez ludzi, dla których Scala jest zbyt trudna. Mniej prawdopodobne jest, że otrzymasz dobrze przemyślane odpowiedzi, stawiając takie pytanie.
Michael Borgwardt,

8
Montaż to tylko rozwodniona wersja kodu maszynowego, prawda?
Ben Brocka,

6
@BenBrocka: Nie, jest izomorficzny w stosunku do kodu maszynowego;)

4
Scala jest świetna. Jeśli chodzi o mnie, uważam, że ludzie powinni zrezygnować z nekromancji na Jawie i odkrywania rowerów (wszystkie te nowe języki, wspomniane i nie) i po prostu używać i ulepszać Scalę. MOIM ZDANIEM.
Ivan

2
@MichaelBogwardt uczciwy punkt. Opieram to twierdzenie na tym, co widziałem wokół blogosfery. „Scala jest zbyt trudna” i „Scala jest zbyt złożona” wydają się być stosunkowo częstymi skargami.
Onorio Catenacci,

Odpowiedzi:


39

IMHO od kogoś, kto programuje w Javie przez ostatnie 7 lat i jest moim najsilniejszym językiem, uważam Scalę za obcą i trudno mi się przyzwyczaić.

Xtend czuje bardziej jak Javie i mógł napisać prostą aplikację z nim znacznie szybciej. To prawda, że ​​nie poświęciłem sobie wystarczająco dużo czasu ze Scalą, ale z pewnością rozumiem, dlaczego niektórzy mogą go wyłączyć.

Powiedziawszy to, ludzie wybiorą znane piekło nad nieznanym niebem.


19
+1: „ludzie wybiorą znane piekło nad nieznanym niebem”.
Giorgio

18

JetBrains ma stronę wiki porównującą Scalę do Kotlina i wydaje się, że Kotlin robi kilka rzeczy, a Scala nie:

  • Zero-napowietrzne zerowe bezpieczeństwo. Scala ma opcję, która jest opakowaniem składniowym i wykonawczym
  • Inteligentne obsady
  • Funkcje rozszerzenia statycznego. Zamiast owijania w czasie wykonywania
  • Funkcje Inline Kotlina ułatwiają nielokalne skoki
  • Szablony ciągów. Istnieje trzecia wtyczka kompilatora dla Scali o podobnej funkcjonalności: ScalaEnhancedStrings
  • Pierwszorzędna delegacja. Zaimplementowane również za pośrednictwem wtyczki innej firmy: Moduły Autoproxy

Tak więc nazywanie Kotlina wodą ze Scali jest prawdopodobnie nadmiernym uproszczeniem. Jeśli chodzi o Xtend, myślę, że jest skierowany głównie do użytkowników Xtext, a nie do szerszej publiczności. Główną różnicą w stosunku do Scali jest to, że Xtend kompiluje się do Javy zamiast kodu bajtowego.

Kolejnym językiem „zabójcy Java”, który powinieneś dodać do swojej listy, jest Cejlon Red Hata , chociaż nie mam pojęcia, czy i jak to się ma do Scali.


13
Automatyczne rzuty brzmią przerażająco.
Jonas,

14
Branża ma te cykliczne rewolucje, w których programiści będą przechodzić od jednego ekstremum i w kółko. Bogate w funkcje języki koderów mocy były dobre, a potem idioci napisali zły kod i znaleźliśmy niebezpieczeństwa, więc ludzie gromadzili się w postrzeganym bezpieczeństwie Javy, teraz znów w koderach mocy. Spójrz, jak JavaScript i przeglądarka były dobre, potem pojawiły się aplety i RIA z wtyczkami do przeglądarek były dobre, a JavaScript źle, potem pojawiły się nowoczesne frameworki AJAX i wtyczki były niepewne i złe, a potem przyszedł Silverlight i ludzie powiedzieli, że AJAX nie żyje, TERAZ HTML5 jest modna i wtyczki znowu źle! :)
wałek klonowy

3
@Jonas ja nawet nie wiem, czy mogę się z tym zgodzić, ale jest to zjawisko, które zauważyłem. Z pewnością z każdą rewolucją pojawia się bardziej wyrafinowane rozwiązanie, jednak każde rozwiązanie ma zawsze piętę achillesową. Rozwiązanie problemu z piętą powoduje, że niektórzy patrzą wstecz na poprzednie rozwiązania pomysłów, ale z czasem ludzie zapominają, dlaczego te stare rozwiązania zostały pierwotnie porzucone. Z czasem jednak z każdą rewolucją pięta staje się coraz mniejsza. Java + XTend może z pewnością nie być tak wyrafinowany jak Scala, jednak problemy są mniejsze niż inwestycja polegająca na całkowitym przejściu na nowy język.
wałek klonowy

2
@Jonas Cóż, tylko ekstremalne nadmierne uproszczenie ewolucji technologicznej mieściłoby się w komentarzu. Zgadzam się z maple_shaft choć ewolucja technologiczna ma iteracyjny dotyk .
yannis,

3
@Jonas te obsady nie są automatyczne, ale inteligentne obsady: jeśli spojrzysz w siebie, zobaczysz, że to nie jest to samo: kotlinlang.org/docs/reference/typecasts.html
cy6erGn0m

11

Używam Scali jako mojego głównego języka przez ostatni rok (z Javą jako drugą sekundą, obie w dużej bazie kodu Java). Nadal muszę szukać dość podstawowych funkcji, jeśli nie użyłem ich w podczas. Jasne, może napisać Scala szybko, ale jest to język bardzo bogate, a to zajmuje dużo czasu do opanowania.

Co więcej, jego złożoność jest nie tylko problemem dla ludzi, ale także dla IDE i kompilatorów. Zarówno Celyon, jak i Kotlin kompilują się bezpośrednio do dość czystego JavaScript. Scala może generować JavaScript za pośrednictwem GWT, chociaż dotarcie do niego jest skomplikowane, a wynik GWT nie jest czytelny ani zaprojektowany tak, aby działał dobrze z zewnętrznym JavaScript lub HTML.

Jestem zdecydowanie bardziej produktywny w Scali niż w Javie, a kod jest bardziej zwarty i czytelny (jeśli znasz trochę Scalę). Jednak jego złożoność sprawia, że ​​waham się polecać go innym. Język o 20% złożoności, ale 80% umiejętności, byłby pożądaną alternatywą.

[Edytowane w celu usunięcia wzmianki o starszym kodzie, patrz komentarz poniżej.]

[Dodatek 2017: Scala obsługuje teraz JavaScript jako cel kompilacji, podczas gdy Kotlin nadal dodaje funkcje, które mają sens dla podobnej do Scali zamiany Java / Groovy / JavaScript. Są to teraz bardziej charakterystyczne języki niż wtedy, gdy to napisałem.]


Czy mógłbyś bardziej szczegółowo rozwinąć „część opóźnioną”? Na przykład, jakie masz na myśli metody, które pobierają Listy, a nie Sekwencje?
kiritsuku

Zamierzam edytować to, ponieważ standardowa biblioteka Scali po refleksji rzadko tak robi. JSONArray pobiera Listę, ale większość konstruktorów nie. Niezależnie od tego, w dokumentacji do List wciąż występuje odchylenie, szczególnie od czasu programowania w Scali, wydanie 2, dotyczy tylko Scali 2.8, która poprzedza wektory. Przykłady kodu mają zwykle konstruktory, które pobierają Listę, gdzie Seq byłby lepszy.
David Leppik

Tak, dla 2.10 niektóre rzeczy są lepsze ( +:na przykład ekstraktory). Mam nadzieję, że programowanie w Scali zostanie zaktualizowane w najbliższej przyszłości. W wersji 2.11 niektóre rzeczy ulegają dalszej poprawie. Stdlib jest już wolny od deprecjacji i również trochę się zmniejszy. Być może scala.util.parsingzostanie również przeniesiony poza stdlib. Zobaczymy ...
kiritsuku

1
Powinienem dodać, że moim prawdziwym problemem z listami vs. wektorami jest to, że dodawanie elementów do listy (tj. Seq in Scala) jest bardzo podstawową operacją i istnieje zbyt wiele równoważnych sposobów, aby to zrobić, wszystkie z zabawnymi symbolami, które trudno jest Zapamiętaj. Kanoniczny sposób jest ::, ::=lub +:=które prepend, ale większość ludzi chce :+=którego dołącza, ale to nie jest skuteczny na liście.
David Leppik

10

JetBrains bardzo jasno określił swoje cele dla Kotlin :

Chcemy być bardziej produktywni, przechodząc na bardziej ekspresyjny język. Jednocześnie nie możemy zaakceptować kompromisów ani pod względem interoperacyjności Java (nowy język będzie wprowadzany stopniowo i trzeba płynnie współpracować z istniejącą bazą kodu), ani szybkości kompilacji (nasza baza kodu wystarczająco długo kompiluje się z javac i nie możemy sobie pozwolić na spowolnienie). Następna sprawa jest również dość prosta: spodziewamy się, że Kotlin będzie napędzał sprzedaż IntelliJ IDEA.


8

Użyłem Scali przez kilka miesięcy w Eclipse z Play Framework. Lubię język, ale są też rzeczy, których nie lubię.

Dla mnie powodem przejścia z Javy na inny język jest większa produktywność.

Do tej pory nie byłem bardziej produktywny ze Scalą. Jednym z powodów jest brak dobrego wsparcia dla Scali w Eclipse, wtyczka Scala jest zła (np. Wcięcie się nie udaje) i nie ma jeszcze wielu funkcji (np. Brak „Hierarchii otwartych połączeń”). Kompilator Scala jest również powolny, nie może to stanowić problemu, ale używam Scala z Play Framework, który kompiluje kod dla każdego żądania, i tam szybkość kompilatora jest ważna.


2
Może nie nauczyłeś się wystarczająco dużo idiomów Scali. Używam Scali do małych projektów (narzędzi) i jestem zdecydowanie bardziej produktywny w Scali niż w Javie, chociaż mam znacznie większe doświadczenie w Javie (> 10 lat) niż w Scali (<2 lata).
Giorgio

4

Nie wiem o Kotlinie, ale Scala i Xtend to dwie bardzo różne bestie.

W przeciwieństwie do powszechnych powiedzeń, Scala NIE jest lepszą Javą. Scala jest językiem o wiele bardziej funkcjonalnym niż Java, z własną składnią i semantyką oraz własną biblioteką bibliotek podstawowych.

Xtend JEST lepszą Javą. Utrzymuje semantykę Java i poprawia jej składnię. Każda linia kodu Xtend może być bezpośrednio przetłumaczona na kilka linii kodu Java. Nie ma też żadnego dodatkowego środowiska uruchomieniowego.

Myślę, że oba podejścia są słuszne, choć różne. Nie lubię Scali (jako języka), ale nie lubię dodawać słoików Scali do moich projektów. Nie mogę również poprawnie używać Scali w Androidzie (powoduje to problemy z wagą i wydajnością). Xtend nie jest tak bardzo polecany, ale dla mnie jest ok (warto go używać niż język Java) i działa na każdej platformie, jak gdybym pisał bezpośrednio w Javie.

Uważam, że oba języki obejmują różne nisze i mogą ze sobą współistnieć, nie zakłócając się nawzajem. IMHO, Scala jest po prostu zbyt skomplikowana, nie dodając nic nowego. Jeśli chcesz przejść na bardziej funkcjonalny i mniej OO, wybierz jeden z wielu prostszych języków funkcjonalnych, takich jak Clojure lub JHaskell. Jeśli chcesz po prostu Java z lepszą składnią i odrobiną funkcjonalnego programowania, Fantom byłby tak świetny jak Scala (bardzo przypomina C #).

Ale uważam, że Xtend znajduje się w słodkim punkcie pomiędzy tymi wszystkimi językami. Dodaje wszystkie wzorce składniowe, które chciałem dla Javy, zachowując dobre części Javy (jej semantykę). Pomyśl o tym jako o Coffescript for Java.

Obsługa Eclipse jest znakomita ...


… I jest obsługiwany tylko w Eclipse. Dobrze? A Eclipse to piekło…
Sarge Borsch

Xtend ma dodatkowy czas działania. Ostatnie 3 MB sprawdziłem.
mm2001

@ mm2001 Tak, istnieją zależności: około 300 Ko dla xtend i 2 Mo dla guawy w moim małym projekcie testowym ( github.com/pdemanget/examples/tree/master/xtend/message-send ) Ale to nie jest środowisko wykonawcze, są one dodatkowe klasy dla rzeczy takich jak InputOutput, dodatkowe adnotacje. Nie oznacza to, że Scala i Xtend to dwa bardzo różne języki, jak powiedziano w tej odpowiedzi.
pdem,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.