Ktoś może powiedzieć czemu w Javie jest taki pi*rdolnik w bibliotece standardowej w przeciwieństwie do np. .NET'a ? Tryliard frameworków o dupe potłuc.
1
1
Bo to Java.
Osobiście nienawidzę tego języka. Weź się za C++.
3
Bo to Java. Masz wolny wybor co chcesz uzyc. Nie ma jednego framewowka ktory zadowala wszystkich, spelnia wszystkie potrzeby. Jest wiele takich ktore robia swoja rzecz dobrze. Nikt nit zmusza mnie to uzywania tylko jednego, platnego i zamknietego frameworka.
Dlaczego w .NET sa 2 hierarchie kolekcji, jedna dla generikow druga gola? Pierolnik.
0
To się liczy:
3 Billion devices run Java ME in the world today
0
Aha i jak porównywać C++ do Javy? Wydaje mi się, że namawianie do nauki C++ kosztem Javy, to raczej po pierwsze głupota a po drugie to zwrot w zupełnie innym kierunku..
1
fujfuj napisał(a)
Ktoś może powiedzieć czemu w Javie jest taki pi*rdolnik w bibliotece standardowej w przeciwieństwie do np. .NET'a ? Tryliard frameworków o dupe potłuc.
To w końcu w bibliotece standardowej czy we frameworkach?
Jest Java ME, Java SE i Java EE, przy czym Java ME to mocno okrojona Java SE, a Java EE to Java SE + oficjalne frameworki od twórców Javy.
To, że dla Javy jest milion frameworków to nie jest przecież wada, no chyba, że dla wyznawców "jedynego słusznego systemu", a co za tym idzie "jedynych słusznych rozwiązań". Dla C++, Pythona, Delphi czy jakiegokolwiek innego języka jest mnóstwo frameworków rozwiązujących z grubsza te same problemy. Dla .NETa jest, jak mi się wydaje, tak samo. Xamarin (czyli firma Miguela de Icazy) przeportował nawet .NETa na Linuksa (Mono), Androida czy iOSa, a jak wiadomo te systemy nie są w 100% zgodne z Windowsem (czyli niektóre rozwiązania są siłą rzeczy inne niż w Windowsie).
11
Przechodzenie z Javy na C++ bo jest "pierdolnik", to jak wbieganie z deszczu pod rynnę i wypierdolenie się na ryj o kamień...
0
[CIACH!]? To się nazywa bogactwo języka. A tak swoją drogą to naprawdę nie rozumiem o co chodzi. Z mojego punktu widzenia wygląda to tak, że ktoś się nauczył najpierw C# i potem przesiadł się na Javę i narzeka, że ona nie jest ceszarpem.
0
Ja bym poprawil i powiedzial ze to sie nazywa 'bogactwo community' lub 'bogactwo platformy'. Java jako jezyk jest tak biedna ze zal dupe sciska. Ale sa inne jezyki ktore wypelniaja luke, a frameworki mozna uzywac i tak. I to jest wlasnie piekne.
0
Dla mnie jezykiem bogatym jest jezyk ktory jest ekspresywny. Np. Ruby, Scala, Groovy czy Python. C# oraz F# rowniez. Java to bieda, ile trzeba sie nameczyc zeby napisac cos srednio-zaawansowanego.
0
@mućka, jakiś przykładzik... na razie tylko mówisz bez podania przykładów.
0
Dodanie do stringa tej tyle newlinow ile jest elementow w jakiejstam kolekcji (przyklad z zycia wziety, ale uproszczony):
Java:
String val = "costam";
for (int i = 0; i < col.size(); ++i) {
val += "\n"
}
return val;
(nie zaczynaj nawet z StringBuilderami, albo jakimis cudami typu Arrays.fill i pozniej sklejanie, tak czy siak petli nie unikniesz)
Groovy:
return "costam" + "\n" * col.size()
(return mozna pominac jesli to jest ostatnia linkjka w funckji, ale to jako programista Scali znasz)
Czytamy glosno: zwroc napis "costam" plus tyle \n ile jest elementow w kolekcji col. Identyko z zadaniem podanym na wstepie? Jedna linijka, a ile znaczy? Latwo sie czyta? Nie ma zadnej petli, ktorej nie rozumie nikt poza programistami jezykow C-pochodnych?
To tylko 1 przyklad. Jesli nie widzisz biedy Javy i przykladow takich jak ten, to przykro mi.
Ja ostatnio pisalem DSL ktory maja czytac nie tylko programisci. Napisalem go w Groovy, i jest kilka standardowych funkcji ktore wzogacone moga byc o wlasny kod w {} czyli closures. Cos w stylu:
value 'some.path' postProcess { value * 100 } format ',###.00' decorate { "€ $value ,-" }
Sprobuj przeczytac ta linijke, zobaczymy czy zrozumiesz. A teraz wersja Javowa (z ladnym hipotetycznym API):
value("some.path").postProcess(new Function<Integer, Integer>() { Integer call(Integer arg) { return arg.intValue() * 100; } }).format(",###.00").decorate(new Function<String, String>() { String call(String arg) { "€ " + arg + " ,-"; }})
Brzydko? No to formatujemy:
value("some.path").postProcess(new Function<Integer, Integer>() {
Integer call(Integer arg) {
return arg.intValue() * 100;
}
}).format(",###.00").decorate(new Function<String, String>() {
String call(String arg) {
return "€ " + arg + " ,-";
}
})
Yhy.... Pomijam ze takie API musi zwracac rozne wrappery (np. value() musi zwracac cos co ma postProcess itp. itd.), implementacja tego jest trudna a i sam efekt koncow katastrofalny.
Spojrz na ten prosty kod i powiedz mi w ktorym stosunek kodu do problemu ktory ma rozwiazac jest blizszy 1? A to jest wlasnie ekspresywnosc jezyka.
Teraz wyobraz sobie taki skrypt z 20-30 takimi linijkami (zamist 'value' daj sum, join, count i rozne takie) - prosty eksport danych, ktory sie okazuje calkiem zaawansowany.
Nasi uzytkownicy / support musza umiec to czytac, sami rowniez proste rzeczy pisac (bez jakichs zaawansowanych Closures).
Powiedz mi teraz, co jet dla takich osob bardziej zrozumiale? Ja przeprowadzilem 'badania' na mojej dziewczynie, starych itp. Wszyscy wymiekali przy obu przykladach, ale po powiedzeniu 'przeczytaj na glos' od razu czaili o co chodzi w tym przykladzie w groovy. Petle nie ma szans zrozumiec normalny czlowiek. To jest wlasnie ekspresywnosc jezyka.
0
@Mucka, weź...
import java.util.Arrays;
public class ManyLines {
/**
* @param args
*/
public static void main(String[] args) {
String var ="coś";
char k[] = new char[10];
Arrays.fill(k, 'd');
System.out.println(var+new String(k));
}
}
trochę zmienione, bo daję 'd' by można było sobie policzyć. W dodatku bez pętli. Da się? Da. Trochę inna składnia, ale java ma statyczne typowanie.
Co do DSLi w javie to można tak:
value = get("some.path") // zwraca Value
.multiply(100) // zwraca Value
.format("###.00") // nadal zwraca Value
.decore("€ %s ,-"); // nadal mamy Value
implementację zamykasz w poszczególnych metodach.
Pomijam ze takie API musi zwracac rozne wrappery (np. value() musi zwracac cos co ma postProcess itp. itd.), implementacja tego jest trudna a i sam efekt koncow katastrofalny.
w groovym trudności mają twórcy języka.
0
Koziolek, wez przeczytaj ten kod ktory napisales. Tablica charow? Kto to rozumie poza Toba, mna i paroma innmi? Nie klient, nie koles od supportu.
Te postProcess i decorate to nie jest to samo co ja napisalem - u mnie to jest dowolny kod, u ciebie jest multiply. Co jesli chcesz add? subtract? divide? albo wszystko naraz? albo zamienic wartosc calkowicie? To samo w decorate, chociaz to jest nieco blizej. Ale co jesli format wg ktorego chcesz dekorowac jest obliczany w zaleznosci od innych czynnikow? Wez daj se spokoj.
Koziołek napisał(a)
w groovym trudności mają twórcy języka.
Co to oznacza? Poza tym, groovy to tylko przyklad. Ruby czy Python maja wiele ciekawszych mozliwosci.
Co do przykladu, nie wiem co ma tutaj statyczne typowanie. Jak wiesz, Scala jest statycznie typowana, a jednak mozesz sobie napisac implicita ktory robi to samo.
5
Kto to rozumie poza Toba, mna i paroma innmi? Nie klient, nie koles od supportu.
Tak z ciekawości, po cholerę klient lub koleś od supportu ma rozumieć kod aplikacji? Od tego są programiści. Już widzę jak dyrektor banku rozsmakowuje się w ekspresywności języka programowania. Albo studentka w callcenter mówi do klienta: proszę chwilkę poczekać, mamy taki ekspresywny język, zaraz poprawię i będzie panu działać.
0
To nie jest kod aplikacji, to jest definicja raportu / exportu danych ktore klient sobie sam moze napisac. Nie slyszales nigdy o aplikacjach ktore mozna zmieniac juz po deploymencie, wlasnie za pomoca skryptowania? Ja slyszalem.
Sa u nas rozni goscie: hardkorowi programisci ktorzy pisza parser Lispa w dzien; tacy, ktorzy pisza to co im sie kaze, byle byla specyfikacja; i sa ludki ktorzy biora od klienta wymagania i pisza skrypcik do eksportu danych. Ci ostatni sa tani jak barszcz i jest ich na peczki, tych srodkowych nieco mniej, a tych pierwszych jest naprawde malo. Wolimy, aby takie skrypciki pisali nam czlonkowie tej ostatniej grupy niz tej pierwszej. Poczatkowo ci pierwsi musiali napisac framework skryptowania dla tych ostatnich, ale teraz setki klientow maja super szybka implementacje takich specyficznych dla nich funkcjonalnosci, a rowniez moga sami ja pisac (oczywiscie, nie kazdy).
0
@mućka, tak będę dawał dowolny zestaw metod ponieważ piszę DSLa, czyli coś co jest ograniczone z definicji i jeżeli pani Basia z księgowości będzie potrzebować zrobić przekręt to dostanie metodę zróbPrzekręt. To, że java nie pozwala na nazwanie metody + albo -, generalnie nie daje możliwości przeładowania operatora to już zależy od upodobań. Mi czasami tego brakuje, ale w sumie czy metoda nazywa się + czy add... co za różnica. To, że język nie daje np. możliwości dynamicznej interpretacji kodu... zresztą co nie daje? Przecież są biblioteki pozwalające na dynamiczne pisanie w Javie. Na przykład napisany w javie Groovy.
mućka napisał(a)
Co to oznacza? Poza tym, groovy to tylko przyklad.
Oznacza to tyle, że taki kod jak ty napisałeś pisze ktoś inny.
mućka napisał(a)
Kto to rozumie poza Toba, mna i paroma innmi? Nie klient, nie koles od supportu.
A kto zrozumie kod w groovy? Pisząc dowolnego DSLa i tak musisz nauczyć użytkownika jak z niego korzystać. Zresztą kto każe pisać tablicę char? Może być tablica Stringów.
0
DSL jest napisany tak zeby target grupa go zrozumiala. Np. DSL to SQL - nie musza go rozumiec programisci, ale DBA juz tak. Tak samo u nas, 'opiekunowie klientow' / konfiguratorzy nie musza pisac w Javie nie wiadomo czego, ale takie skrypciki juz sa w stanie spokojnie pojac i pisac. Mnozenie metod w Javie nie jest ani skalowalne, ani elastyczne.
Teraz przeciazanie operatorow - mowisz ze bez roznicy czy add czy +. Widac nie napisales nigdy kodu ktory uzywa BigDecimal / BigInteger. Ogolnie nie jestem wielkim fanem przeciazania, ale czasami sie przydaje. Tworcy Scali i bibliotek poszli w zlym kierunku, tam to jest koszmar - czytasz kod i nie wiesz co on robi. Ale mozna to robic razsadnie, jak + dla Stringow w Javie, mnozenie stringow, minusy dla Date dajace roznice w czasie, i wiele innych przykladow.
Ok, powiedzcie mi ze wolicie petle i sklejanie stringow niz 'aaa' + 3 * 'b' jako kod ktory ma utworzyc pewien string, to pokajam sie i pojde do kata. Powiedzcie mi ze wolicie implementowac anonimowe klasy zagniezdzone niz wsparcie dla closures, a dam spokoj. Powiedzcie, ze wolicie:
Map<String, List<Integer>> m = new HashMap<String, String>();
m.put("a", Arrays.asList(1, 2, 3));
m.put("b", Arrays.asList(4, 5, 6));
od
Map m = ['a': [1, 2, 3], 'b': [4, 5, 6]]
(pomijam statyczne typowanie, nie o to chodzi w tym offtopie)
Kod masz glownie czytac. Masz go rozumiec jak na niego spojrzysz za 6 miesiecy. Ma byc zwiezly i jednoczesnie jak najblizej opisywac problem ktory ma rozwiazac. Swietnym przykladem jest to sklejanie stringow - ktory jest bardziej czytelny i ... 'ekspresywny'? Jesli tak kochacie Jave, to co powiecie na to, ze sie rozwija, i np. w Javie 7 jest 'diamond' (nie trzeba powtarzac informacji generycznych jak w powyzszym przykladzie new HashMap<>), Java 8 ma miec Closures, sa niezliczone biblioteki ktore pozwalaja pisac zwiezly kod (guava, anybody?). Czy ktos z Was widzial kiedykolwiek .Net-owr LINQ w akcji? Nie ma jawnych iteracji po kolekcjach. Scala tez tego nie ma. Niskopoziomowe, zagmatwane operacje odwracaja uwage od problemu, to jest zwyczajny halas, od ktrego sie odchodzi, wskazuja na to nowe trendy. Szkoda ze tego nie rozpoznajecie. Ale spoko, siedzcie sobie w grajdolku, tym lepiej dla mnie.
2
Czy naprawdę uważasz, że użytkownik końcowy napisze coś takiego:
value 'some.path' postProcess { value * 100 } format ',###.00' decorate { "€ $value ,-" }
?
Oni potrzebują GUI.
Poza tym, jeżeli nie panujesz nad tym, co przekazuje użytkownik (w nawiasach {}), to tworzysz lukę bezpieczeństwa - może tam być przecież przekazany dowolny kod.
Ja bym użył Spring Expression Language:
http://static.springsource.org/spring/docs/current/spring-framework-reference/html/expressions.html
Szczególnie polecam punkt 6.5.11 "Functions", który opisuje jak rozszerzyć SpEL o własne funkcje.
0
Nie mowie ze ma pisac takie cos, ma to umiec czytac - to jest glowny cel DSL. Poza tym, tak uwazam ze sa ludzie ktorzy nie umieja programowac ale takie rzeczy napisac umieja, znam wiele przykladow, i swietnie im idzie.
Skad wiesz ze tam sa luki bezpieczenstwa? Akurat caly kod jest uruchamiany jako pewien konkretny code source, dla ktorego jest zestaw uprawnien i ich przekroczyc sie nie da, wymusza to model bezpieczenstwa Javy.
Co mozna napisac w closures ograniczamy (jak wspomnialem wyzej) oraz panujemy nad tym - akurat Groovy pozwala nad tym ladnie panowac, dodatkowo umozliwiajac ustawianie tzw. 'delegatow' ktore moga dostarczac dodatkowe funkcje i zmienne tam dostepne. Moge np. powiedziec: 'nie, nie wolno ci w tej closure zdefiniowac zadnej zmiennej ani funkcji, wolno ci wolac tylko te i te metody, oraz czytac ta i ta property'. Naprawde daje wiele mozliwosci. System.exit(0) nie wywolasz bo nasz SecurityManager nie pozwala, chyba ze klient sobie zarzyczy zero ograniczen, ich sprawa. Uzywanie Java Security pozwala na taka elastycznosc, nie ma problemu.
Spring EL to zdecydowanie za malo. Akurat tak sie sklada ze value 'a.b.c' uzywa Spring EL do 'ewaluowania' sciezek w grafie obiektow i wydobywania wartosci. Nie jest jednak tak elastyczny jak potrzebujemy - klienci czasem potrzebuja naprawde 'dziwnych' rozwiazan, ktore sa dopisywane juz po deployu, zmieniane, updatowane, usuwane. Ale aplikacja ma lazic bez przerwy.
GUI - owszem, ale poki co nie ma czasu. Time to market jest krotki, i na razie mamy to na co nas obecnie stac, czyli takie skryptowanie. GUI bedzie mialo swoja kolej. Nie wszystko jednka da sie jednak zrobic z GUI - definicje danych do eksportu moze i tak, ale nasza palikacja ma pewne hooki ktore mozna dowolnie (w miare) oprogramowac, i tak GUI nic nie da, mamy za to caly plugin do eclipse ktory pozwala pisac i testowac ten 'custom code' (nazwa wew.). Co do eksportu, jest np JasperReports ktory pozwala definiowac raporty w XML, ale pewne dodatkowe operacje i tak trzeba pisac w Javie lub innym wspieranym jezyku, wiec do kodu i tak trzeba zajrzec.
Do takich rozszerzen Java sie po prostu nie nadaje, jest zbyt skomplikowana, ma skladnie ktora nie pozwala sie skupic na problemie. Poza tym tak, juz ktos pytal, ale owszem, nasi klienci potrafia sami pisac sobie takie wstawki - maja od nas dokumentacje oraz API, maja wsparcie IT (swoje dzialy, zew. firmy) ktore taki kod potrafia dla nich napisac. I sa bardzo zadowoleni z tekiego designu. Inaczej nasza aplikacja nie ma prawa bytu. Poczytajcie prosze o genezie i zastosowania DSL, wtedy mozemy dalej porozmawiac. Poki co mowie 'macie racje, pierdo1e glupoty'. Ktos musi w koncu offtop zakonczyc.
0
Zgadzam się z tobą mućka, lecz prowadzenie rozmowy z zaawansowanym programista języka niesie w sobie ten sam problem, co rozmowa z wyznawcą wybranej religi na temat wyższości pozostałych wyznań. Dość łatwo idzie w tym zgubić sens rozmowy.
W moich odczuciach Java jest poteżnym językiem, ale brak mu ekspresji. Dla mnie ta cecha jest siłą, która pozwala wyrażać złożone konstrukcje w sposób bajkowo oczywisty. Nie umiem dokładnie opisać jakich detali konkretnie brak w javie, ale wiem, że stosowanie tego języka niesie w sobie mniej uciech w przeciwieństwie do Python/Ruby/C#. Poza samym językiem nie podoba mi się także struktura standardowych bibliotek, a także overhead jaki ponosi osoba chcąca kodować usługi webowe.
0
mućka napisał(a)
Nie mowie ze ma pisac takie cos, ma to umiec czytac - to jest glowny cel DSL. Poza tym, tak uwazam ze sa ludzie ktorzy nie umieja programowac ale takie rzeczy napisac umieja, znam wiele przykladow, i swietnie im idzie.
Oczywiście napiszą o ile się nauczą. Można dać im Groovy (żeby było jeszcze śmieszniej jest to po prostu część szerokiej specyfikacji javy - JSR241). Można dać Drools. Można w końcu dać API w "czystej" javie. Laikowi wszystko jedno czy napisze add czy da +. I tak nie będzie wnikał w szczegóły bo mu to wisi. Składnia to nie problem w tym przypadku. Zresztą dowodem na to jest projektowany "pod biznes" COBOL.
mućka napisał(a)
Poczytajcie prosze o genezie i zastosowania DSL, wtedy mozemy dalej porozmawiac
DSL u swoich podstaw ma umowność i specjalizację. Zatem mówienie "w javie to jest głupio, wolę groovy" jest pozbawione sensu. Mam w zespole faceta, który programuje dłużej niż ja żyję. Gość zna COBOLa, ALGOLa i jeszcze kilka innych tego typu wynalazków. Za to nie za bardzo idzie mu z Javą. Przygotowaliśmy mu więc DSLa opartego o Javę, który pozwala na dostęp do danych "jak w COBOLu". Sa metody fetchEvery, openCursor czy flush. I to sobie działa. Dostał do ręki dokumentację i pisze. Tworząc DSL musisz uwzględnić "Domain Specific". U ciebie sprawdza się Groovy, bo pewno działy it u klienta do admini oderwani siłą od kabli, którzy oczekują "czegoś podobnego do basha". Groovy może być OK. Dynamicznie interpretowany, o bashopodobnej składni. Ja mam przykład DSLa dla COBOLowca, który będzie rozpatrywał przez pół dnia czy w danym miejscu lepsze jest użycie pre czy post inkrementacji choć nie ma to znaczenia. O czymś takim jak zmienna lokalna mówi, że to herezja. Tu sprawdza się odpowiednio przygotowane API w javie z przyjaznymi nazwami metod (gt, eq, ne), które tego gościa nie będą odstraszać. Tyle w temacie.
0
Java to nie jedyny język na JVM, jest przecież Scala, Clojure, JRuby, Groovy, itp itd W 2013 wejdzie Java 8 z domknięciami, defender methods i innymi bajerami, więc dystans się zmniejszy.
0
@Wibowit: nie wiem w sumie co ten komentarz oznacza i ktora strone dyskucji popierasz. Jedna sprawa - closures w Java 8 ta beda kadlubki, jesli czytales specyfikacje i proposale. Nie ma o czym mowic.
Osobiscie jestem zdania ze Java ma zostac czym jest. Ma byc asemblerem 21. wieku Ma byc niskopoziomowa. Ma byc szybka, super szybka (jak na JVM). Od wysokopoziomowych rzeczy maja byc inne, nowe jezyki. Scala, Groovy, Clojure, Jython, Gosu, Fantom, Xtend i wiele innych (Cotlin? Ceylon?). One nie sa tak skostniale jak Java, nowe ficzery nie musza pokonac tylu przeciwienstw, miec osobnych JSR (ktore i tak sa nic nie warte, Oracle i tak robi co chce, co juz pokazal), sa bardziej elastyczne. To tylko moje zdanie.
@koziolek: nie znam cobola i nie poznam raczej nigdy, ale widzialem w Scali DSL ktory symulowal VB. Teraz wez Jave i wykonaj w nim taka symulacje - nie da sie. W Scali czy Groovy - owszem. Ruby tez da rade.
Groovy u nas to tylko przyklad. Akurat tak sie sklada, ze nasz system dziala z wieloma jezykami: mamy specjalne DSL dla Scali, (J)Ruby, Groovy, plus wspieramy generycznie JSR 223 i wszyskie jezyki ktore maja swoje pluginy. Kazdy z tych jezykow jest lepszy niz Java w tej dziedzinie - upublicznienie latwego, przyjemnego API. Scala troche kuleje bo jest statycznie typowana, a nasi klienci i starsi wspolpracownicy maja wiele doswiadczenia w VB.
Jesli twierdzisz, ze Java jest koncem swiata i nie ma miejsca na inne jezyki, ktore sa duzo bardziej czytelne (to nie podlega zadnej dyskusji moim zdaniem, chyba ze sie jest ograniczonym i nie zna nic innego), to jest mi jedynie przykro. Tym bardziej ze zdaje sie masz na forum renome.
Wibowit napisał(a)
Java to nie jedyny język na JVM, jest przecież Scala, Clojure, JRuby, Groovy, itp itd W 2013 wejdzie Java 8 z domknięciami, defender methods i innymi bajerami, więc dystans się zmniejszy.
Sadzac po tempie rozwoju Javy i np. Scali, dystans sie zwieksza z dnia na dzien, sam wiesz o tym doskonale. W 2013 nikogo moga nie obchodzic defender methods czy biedne closure (SAMy) w Java. Tego zycze sobie i Wam!
0
Java to język dla mas, jeszcze łatwy do zrozumienia, przewidywalny jeśli chodzi o wydajność. Ludzie narzekają na Scalę, że jest zbyt trudna - ale przy tradycji utrzymywania kompatybilności w Javie to niedługo Java może stać się tak trudna jak Scala. I w sumie te "trudne" języki stają się coraz bardziej popularne, skoro ich trudność przestaje przerażać.
Jest jakiś język, który jest łatwy w zrozumieniu (nawet kod frameworków), zwięzły, łatwy do optymalizacji (tzn z wydajnymi implementacjami), skalowalny (w sensie takim, że dodawanie funkcjonalności do coraz większego frameworka nie robi się szybko coraz bardziej pracochłonne) i bez masy kruczków językowych?
0
@mućka, wyczuwam u ciebie skrajny fanboizm. Po pierwsze jeszcze raz powtórzę. Język dobieramy do problemu. W czystej Javie zapewne też dało by się napisać VB-podobny DSL. Jednak jeżeli chcesz mieć kropka w kropkę składnię to można napisać interpreter. Też będzie dobrze. Można też wybrać Scalę i napisać DSLa. Z drugiej strony w Scali obrzydliwie pisze się kod pracujący na plikach. Sorry to nie to, bo jak byś nie kombinował wychodzi java.
Po drugie to kwestia udostępnionego API. Jeżeli jest ono dobre, to w sumie nie jest istotne czy jest to scala, groovy czy kompilowana w tle java. Naprawdę pomiędzy:
Czytelnik.get("Jan","Kowalski").wypożycza("Kamasutra");
a
Czytelnik("Jan Kowalski") wypożycza "Kamasutra"
nie ma żadnej różnicy dla klienta. Ja rozumiem, że dopuszczenie spacji zamiast kropek jest fajne, ale już taki numer kiedyś inżynierowie Apple zrobili z nazwami plików (jakby raport_roczny.xls był nie do odczytania w porównaniu z raport roczny.xls) i jesteśmy im za to wdzięczni za każdym razem pisząc skrypty w bashu.
Wszystko jest kwestią umowną. W javie też można pisać ładne DSLe, które są wygodne w użyciu. Tak samo jak w groovym można napisać DSL, na którego widok ludzi będzie odrzucać.
0
Nie wiem dlaczego fanboizm, skoro wypowiadam sie negatywnie na temat Javy, a nie na temat zadnego innego konkretnego jezyka.
Czytelnik.get("Jan","Kowalski").wypożycza("Kamasutra");
a
Czytelnik("Jan Kowalski") wypożycza "Kamasutra"
a
Czytelnik "Jan Kowalski" wypożycza "Kamasutra"
Jest roznica, i to wielka moim skromnym zdaniem. Po kiego te nawiasy i kropki, jakies gety i sredniki? Ba, da sie i tak:
Czytelnik Jan, Kowalski wypożycza Kamasutra
albo:
buy 100 actions of IBM for 100 eur
(oszukaj sobie prawdziwych przykladow prawdziwych DSL, a nie jakies Javowe API)
czyli bez apostrofow - ale to juz wieksza magia ktora umiem zrobic tylko w Groovy poki co (podpowiedz: propertyMissing oraz methodMissing, jesli kogos interesuje).
Co maja kropki czy spacje w lancuchac metod do spacji w nazwie plikow? Twierdzisz, ze kropki sa dobre a spacje zle? A co to za roznica dla parsera, z wyjatkiem zmiany znaku? A czytelnosc dla pospolitego Johna Doe jest znacznie lepsza. Analogia do plikow chybiona, przeciez w lancuchach wywolan nie ma co escapowac ani nic. Swoja droga co to ma do Appla? Takie samo escapowanie jest wszedzie. Jesli juz to wina shella ze jest ograniczony albo niewygodny.
Fakt ze wszystko to i tak bytecode JVM jest genialna sprawa. To jak ten bytecode powstaje jest roznica, i Java w takich DSL jest czesto najgorszym rozwiazaniem.
Swietny przyklad dla DSL: cucamber, rspec, easyb dla BDD - scenariusze pisza osoby nie-do-konca-techniczne, sa tzw. 'executable specification'. Co wiecej, jak ty je napiszesz, to oni moga taki scenariusz wziac, przeczytac i stwierdzic czy to ma w ogole sens biznesowy.
0
Dzieki, wlasnie brakowalo mi tego slowa ;d
1
mucka napisał(a)
return "costam" + "\n" * col.size()
Przecież doskonale wiesz, co powstaje z takiego kodu. A co?
A pętla.
Jednak w Groovy używając takiej konstrukcji jestem zmuszony wykorzystać jedną słuszną implementację. A mi może robić różnicę jaka ta implementacja będzie.
W Javie też tak sobie mogę jak w Groovy. Co za problem napisać sobie:
newliny("cośtam").z(col);
Trudne? Nie sądzę.
Niejasne? Nie wydaje mi się.
A przecież to cholerstwo, które odpalę będzie mogło sobie siedzieć gdzieś w sofcie na jakimś satelicie, albo w sterowniku jakiejś wirówki w Iranie. ;)
Dopóki nie obchodzi mnie to, a robi to co powinno, to nie ma żadnej różnicy czy napiszesz to w Groovy czy Javie.
Ale jeżeli zacznie mnie to obchodzić bo gdzieś tam brakuje milisekundy, to nie załamię rączek jak w super-duper wysokopoziomowych językach, ale po prostu przerobię to sobie na wersję, która dodatkowo będzie mnie drapała po tyłku przy pomocy jakiegoś hardware'u. Wciąż nie zmieniając ani jednego znaku kodu u klienta.
Oczywiście zawsze można napisać też to samo w super wysokopoziomowym bashu. Tylko potem trzeba ludziom kupować pizzę po nocach, żeby szukali durnej literówki bo soft fiksuje gdzieś u klienta, klienta jego klienta skąd kiedyś wzięło się parę zielonych.
Java nie jest biedna tak samo jak biedny nie był C. Doskonałe nie jest to czego nie można powiększyć, ale to z czego nie można już nic ująć.
0
Co do osob twierdzacych ze klient / support nigdy nie pisze kodu bo i po co, mam mala podpowiedz. Wiecie co to np. Microsoft Office? Pewnie wiecie, i wasze mamy pisza w tym listy zakupow czy cokolwiek. Wiele firm tworzy w tym bazy danych (excel, anybody ;d), jeszcze inni tworza jakies prezentacje. Nie sa to najczesciej zaawansowani uzytkownicy, i klikaja to na co Ms pozwolil.
Jest inna grupa userow, tzw. power userzy. Oni to wiedza ze pakiet Office pozwala na pisanie makr w VBA, ktore otwieraja zupelnie nowe mozliwosci. Jest pewien problem - wymagane dosc duze umiejetnosci programowania. A co jesli zostalyby w VBA stworzone DSL do tego i owego (jak chociazby funkcje w excelu - tak, wolasz formulki, najczesciej zakresy kolumn / wierszy wpisujesz z palca a nie klikasz CTRL_SHIFT_costam po arkuszu bo tak jest o wiele szybciej i sprawniej), dzieki ktoremu nie tylko power userzy, ale rowniez sredniozaawansowani moga cos nowego stworzyc?
No i teraz pytanie: wolicie zeby taki szef dzialu HR (wasz klient, jakis end user) pisal jawna petle for z licznikami, czy ten przyklad ktory podalem, z mnozeniem stringow? Tak, Olomogato, wiem ze tam jest petla, ale ja jestem devem, moj tata jest lekarzem, nie wie nic o petlach i go to nie obchodzi, a uzywa tak sprawnie jak ja. Powtorze po raz n-ty, ze to mnozenie to tylko przyklad. Kto w Was Javowcow nigdy nie zapuscil sie w busz Ruby, Groovy, Scali, Pythona a nawet makr Lisp pewnie sobie nie wyobraza nic innego niz petle, liczniki, wywolania funkcji z nawiasami i bloki z klamrami, ale przytoczona wczesniej ladna i ekspresywna skladnia do manipulacji stringow to tylko czubek gory lodowej.
Tym oto akcentem chcialbym pozegnac stary rok na tym forum. Wam zycze odwagi wyprobowania czegos czego nie znacie i otwartosci umyslu, a nie od razu gniecenie tego co nowe (choc wcale nie, idea DSL jest od wielu lat aktualna, Fowler zdaje sie pisal o tym w 2003-2004, a ostatnio (2010?) wydal cala ksiazke).