Dalszy rozwój ...

Witam,

Troszkę już siedzę w Javie .... Chciałbym się rozwinąć i tu pojawia się pewien dylemat. Chciałbym posiłkować się waszym doświadczeniem przy wyborze "przyszłości". Mój wybór waha się pomiędzy dwoma terminami ...

Groovy + Grails vs Django (Python)

Prosiłbym, aby odpowiedz nie była w stylu ... "lepszy bo tak,a ten drugi jest głupi". Proponuje wskazanie wygra pod kilkoma kategoriami:

• Wydajność
• Łatwość
• Rozwój (bardziej przyszłościowa)
• Wady, które utrudniają programowanie
• Uwagi o których nie wspomniałem o warto o nich wiedzieć

Z góry dziękuje za pochwalenie się swoimi doświadczeniami :)

A może Scala?

Scala.

[???] [???] [???]

Normalnie mi kopara opadła ... nie spotkałem się z tym językiem jeszcze. Moglibyście coś więcej powiedzieć. Coś dlaczego deklasuje moje propozycje .... ?

Czekam z niecierpliwością !

Wydajność, łatwa integracja z Javą, wieloparadygmatowość, dynamiczny rozwój, rosnąca popularność. Scala jest stworzona przez gościa, któremu zlecono zrobienie genericsów w Javie (niestety wymusili na nim type erasure). Sam James Gosling, twórca Javy, poleca Scalę, spośród języków pod JVM oprócz Javy: http://www.adam-bien.com/roller/abien/entry/java_net_javaone_which_programming

Scala daje potężne możliwości, ale jest trochę trudna. Jednak skoro znasz Javę, to ze Scalą będzie łatwiej.

Scala. Niektóre powody:

1. Bo działa wydajniej niż Groovy / Python / Ruby. Znacznie wydajniej (spodziewaj się różnic > 20 razy)
2. Bo można korzystać ze wszystkich dobrodziejstw Javy.
3. Bo się świetnie skaluje do dużych projektów i dużych zadań.
4. Bo programuje się równie szybko jak w Pythonie/Rubym.
5. Bo kompilator przy tym wyłapuje znacznie więcej błędów niż w Pythonie/Rubym.
6. Bo ma świetną bibliotekę standardową (http://www.scala-lang.org/archives/downloads/distrib/files/nightly/docs/library/index.html)
7. Bo IntelliJ Idea (http://www.jetbrains.com/idea/)
8. Bo Lift (http://liftweb.net/quotes.html)
9. Bo SBT (http://code.google.com/p/simple-build-tool/)
10. Bo Squeryl (http://squeryl.org/)
11. Bo ScalaCheck i Specs (http://code.google.com/p/scalacheck/, http://code.google.com/p/specs/)
12. Bo LinkedIn, Twitter i Foursquare.

Scala daje potężne możliwości, ale jest trochę trudna

Raczej trzeba się dużo douczyć. Ale nie zauważyłem żeby była trudna. A później programowanie w Scali jest IMHO dużo łatwiejsze niż w Javie.

Musze przyznać, że odpowiedzi mnie bardzo satysfakcjonuje i przekonują do tego języka. Prosiłbym o rozwinięcie kwestii podziału. Już tłumaczę ocb. Java dzieli sie na JEE, JME, JSE - uważam to za sensowny podział ;> Jak się to ma w SCALA ... czy też są takie podziały ? Z tego co przyczytałem wniosukuje to orientujecie sie praktycznie na temat SCALA. Tu nasuwa mi się kolejno pytanie... Czy SCALA również posiada jakieś potęzne narzędzie ułatwiajace prace jak na przykład Django? ;>

@HiT, w javie podział jest trochę inny:

• JVM - maszyna wirtualna jej specyfikacja i implementacje
• Java - Język programowania w skład którego wchodzi kilka(set) specyfikacji np. JSE, JEE, JME, JMX, JavaMail, itd.
• Języki kompilowane do ByteCode - Scala, Groovy, Clojure, Drools i inne.

Wspomniane JSE, JEE itd to specyfikacje, które w wyniku różnych zawirowań historycznych stały się oddzielnymi "językami java". W Scali nie ma takiego podziału, ale można wykorzystywać elementy Java bez ograniczeń. Zatem jak chcesz pisać aplikację EE w której Beany będą w Scali... proszę cię bardzo.

Witam,

Po kilku dniach spędzonych na czytaniu zalet Scala. Natknąłem się na wpis na blogu który sugeruje wyższość Javy nad Scala pod względem szybkości. Posiada ktoś wiarygodną informacje o ile szybszy? Procentowo lub inny test?

p.s. (Pierwszy test napotkany w google mnie średnio przekonuje http://krzychukula.blogspot.com/2010/01/jvm-languages-speed-test-java-vs-scala_18.html)

@HiT i nie jest to nic nadzwyczajnego. Scala jest w pewnym sensie "nakładką na" Javę. Wykorzystuje bardzo mocno mechanizmy refleksji i robi różne magie by można było używać DSLi. Ja bym się tym, aż tak nie przejmował. Test był trochę tendencyjny, bo Java pracowała na prymitywach, a Scala nie dysponuje czymś takim tylko wszystko obudowuje w obiekty Javy, które są baaardzo wolne w porównaniu z prymitywami.

@Koziołek
Tak, zrozumiałem to przy wcześniejszych wypowiedziach. Może to tak "lelawo" napisałem, ale chodziło mi bardziej jak bardzo jest wolniejsza od Javy :). Powiedzmy czy taka różnica jak 1.5 do 1.6 ?

Jak testowałem Scalę jako dostawcę pseudo-DSLa do naszych biznesowych celów (Scala jako dostawca DSL + JPA jako interfejs utrwalania) to czysta Java była jakieś 20-40 razy szybsza jednak kod był bardziej skomplikowany i pogmatwany.

Oooo !

Dokładnie takiej odpowiedzi szukałem. Z tego co czytałem to macie rację, że jeśli chodzio o składnie to ma bardzo łatwo. Bardzo dobrą obsługę kolekcji itd Szukałem własnie jakiejś wady ;) .

Swoją drogą język jest na pewno godny uwagi ;D

Pozdrawiam :)

A jest jakaś sensowna książka/porzadny tutorial do Scali? Oczywiście mogę pogooglować, ale interesuje mnie coś sprawdzonego ;)

Zacznij szukać od scala-lang.org zresztą chyba o tym wiesz. Wydaje mi się że na tej stronie są odnośniki do wszystkich książek/ tutoriali o Scali.

Koziołek napisał(a)

scala jako dostawca DSL + JPA jako interfejs utrwalania

A JPA z anotacjami? Jesli tak to ciekawe, bo dopiero od scali 2.8 jest wsparcie dla zagniezdzonych adnotacji (i to nie od poczatku). Albo Wasz model jest mega prosty, albo robiles to 2 tyg temu, albo sciema.

@ucilala, trochę inaczej. Scala pobierała dobie z Javowego DAO obiekty i na nich pracowała. Działa to tak;

• request z serwera trafia do kontrolera który jest w Scali
• Scala woła na podstawie parametrów z requestu DAO napisane w czystej Javie
• DAO zwraca obiekt POJO i w praktyce jest to JPA, ale mamy też jakiegoś WEBService i JDBC.
• Scala czyni magię
• Wysyła response.
  Trochę to namieszane, bo z DAO korzystają też fragmenty w groovy i Jbolu, ale ważne, że działa.

W porzadku, rozumiem. Ale teraz caly ten 'mini-benchmark' ktorym sie posluzyles jest malo dokladny, poniewaz nie porowujesz calego kodu Javy i Scali, tylko jego czesc (pomijasz DAO, requesty itp). Zatem mozna powiedziec ze porownujesz kod Scali i Javy, ale tylko od momentu otrzymania obiektow z DAO do czasu wygenerowania odpowiedzi, i on jest 20-40 razy wolniejszy, czy tak? W tym przypadku to 20-40 wydaje mi sie strasznie duza roznica.

@ucilala, bo to DSL i jest jeszcze "interpreter" po drodze. Łatwiej nam było napisać proste "reject transaction". Niż odpowiednik javowy w którym metoda reject będzie miała ze 100 linii i będzie sięgać do WS. W dodatku taki kod można dać analitykowi, który będzie pisał logikę za pomocą takich klocków i nie będzie zawracał d**y specyfikacją mającą 300stron z czego dla nas ważne jest może z 2, których bez zrozumienia reszty i tak nie ruszymy. Scala służy do ułatwiania życia po stronie programisty, a nie usera. Inaczej pisalibyśmy wszystko w asmie i mieli super szybki system, ktory by nie działał.

Koziołek:
A gdyby w Javie zrobić coś podobnego jak zrobiliście w Scali to nie działałoby z podobną prędkością?

http://shootout.alioth.debian.org/u64q/scala.php
Z "benchmarków" wynika, że Scala nie musi być wcale wolniejsza niż Java. Z drugiej strony, aby tworzyć "szybkie" programy w Scali trzeba byłoby się ograniczyć co do zasobożernych ficzerów Scalowych i kod wyglądałby niewiele lepiej niż w Javie.

Myślę, że ograniczeniem jest sam bytecode tzn jego ograniczona ekspresywność. Możliwe że wraz z nadejściem JDK 7 bytecode dostanie nowe instrukcje pozwalające na lepsze wykorzystanie zasobów.

Działało by jak w Scali... nawet mamy porównanie bo mamy interpreter COBOLa w Javie. Generalnie Mamy tu konflikt tragiczny albo ładny kod albo duża wydajność. Generalnie JVM nie był pomyślany by robić niektóre rzeczy, które teraz chcemy robić. Może 7 coś zmieni..

7 wyglada na to ze wyjdzie za pare latek, bo jesli szybciej, to nie wprowadza prawie nic nowego. Chociazby ciagle zmiany w lambdach, ich skladni i zastosowaniu. Aktualnie to nawet nie sa lambdy tylko synctatic sugar na tworzenie klas wewnetrznych, ma nie byc typow funkcyjnych itp.
W sumie to i tak jestem przeciwny jakims wielkim zmianom w Javie (jezyku) ale typy funkcyjne bym chetnie widzial. Ale jesli wyjdzie niedlogo z tylko nowym API i tylko nowym invokevirtual to juz duzo.

http://inebium.com/post/java-7-new-release-performance-code <- realse date - septemeber 2010 ;p Ciekawe co tam wtedy pokaża :)

Jeśli stringi we switchu będą zdecydowanie szybsze niż seria ifów to myślę że to znacznie pomoże Scali (pattern matching itd).