Dalszy rozwój ... :: 4programmers.net

0

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 :)

0

A może Scala?

0

Scala.

0

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

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ą !

0

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.

0

Scala. Niektóre powody:

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

0

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? ;>

0

@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.

0

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)

0

@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.

0

@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 ?

0

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.

0

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 :)

0

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

0

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.

0

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.

0

@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.

0

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.

0

@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ł.

0

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.

0

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..

0

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.