🚀 go-pugleaf

A.L. <fela@2005.com> napisał(a): 

> Zadziwiajaca kariere robi Groovy. Jak patrze na lewo i prawo to
> wypiera Perl, nie tylko "podziemnie" ale i oficjalnie. Na moim
> komputerze wyparl - latwiej mi robic rozne rzeczy przy pomocy Groovy
> niz Perla, glownei dlatego ze jak tak doskonale zintegrowany z Java. 
> 
> Wyglada na to ze wypiera JavaScript.
> 
> Praktyka zas wykazala ze scripting engine w Java 1.6 jest taki sobie i
> z Groovy nie ma startu...
> 

Chcialbym wierzyc ze Groovy wyprze Perl (wyjatkowe paskudstwo o zadziwiajacej 
pozycji na rynku), ale to chyba na razie w powijakach. JavaScript? A 
JavaScript jest uzywany gdzie indziej niz w browserze (powaznie pytam)?

Jakies dane o popularnosci Groovy?

Ale Groovy rzeczywiscie ma jedna bardzo mocna strone - integracje z Java (nie 
dziwota, to przeciez srodowisko Codehaus). To oznacza bezbolesne korzystanie 
ze wszystkich bibliotek, bezbolesne odpalanie wszedzie na JVM, mniejszy koszt 
wprowadzania dodatkowego jezyka do projektu (w przypadku, gdy glownym 
jezykiem jest Java) itd.

Na ile to moze byc waznym dla nowego opensource'owego jezyka skryptowego? 
Pokaze na przykladzie Ruby. Ostatnio bylo glosno o tzw Twitter (aplikacja 
webowa, oczko w glowie community Ruby). Aplikacja odniosla wzgledny sukces, 
przyszly problemy z wydajnoscia. Jak to zwykle bywa z web aplikacjiami uparli 
sie w sciane pt "scentralizowana baza danych". Zdecydowali sie miec kilka baz 
danych. Niestety nie bylo dla Ruby _niczego_ gotowego do gadania z kilkoma 
bazami danych (co mnie zadziwia: coz za kieszonkowe aplikacje musieli 
wczesniej pisac w Rubym, skoro nikt tego problemu nie spotkal). Groovy 
takiego problemu (ani innych podobnych) by nie mial. Procz tego dochodzi 
natura srodowisk open source - najczesciej sie pisze rzeczy latwe (jak 
kolejny web framework) albo seksowne (prosze wstawic cokolwiek kogokolwiek 
pociaga), gorzej jest z rzeczami nudnymi, potrzebnymi, ale skomplikowanymi. 
Jak np transakcje rozproszone; w swiecie Java temu odpowiada JTA. Do niedawna 
nie bylo ZADNEJ (nadajacej sie do uzycia) open source implementacji JTA. 
Obecnie jest JEDNA, i to nie byle jaka - jest to komercyjna implementacja 
WYKUPIONA (nie napisana) przez firme JBoss i udostepniona jako open source.


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

On Tue, 1 May 2007 09:16:48 +0000 (UTC), "Aleksander Galicki"
<tretete@WYTNIJ.gazeta.pl> wrote:

>Chcialbym wierzyc ze Groovy wyprze Perl (wyjatkowe paskudstwo o zadziwiajacej 
>pozycji na rynku), ale to chyba na razie w powijakach. JavaScript? A 
>JavaScript jest uzywany gdzie indziej niz w browserze (powaznie pytam)?
>

Raczej nie.

>Jakies dane o popularnosci Groovy?
>

Z wlasnego podworka, poki co...

>Ale Groovy rzeczywiscie ma jedna bardzo mocna strone - integracje z Java (nie 
>dziwota, to przeciez srodowisko Codehaus). To oznacza bezbolesne korzystanie 
>ze wszystkich bibliotek, bezbolesne odpalanie wszedzie na JVM, mniejszy koszt 
>wprowadzania dodatkowego jezyka do projektu (w przypadku, gdy glownym 
>jezykiem jest Java) itd.
>

Wlasnie.  

A.L.

"Aleksander Galicki" <tretete@WYTNIJ.gazeta.pl> writes:

[...]

> Chcialbym wierzyc ze Groovy wyprze Perl

Groovy nie ma jednej, podstawowej zalety: bloki kodu nie są w nim
rozgraniczane wcięciami.

Dnia Tue, 01 May 2007 09:16:48 +0000, Aleksander Galicki napisał(a):

> JavaScript? A JavaScript jest uzywany gdzie indziej
> niz w browserze (powaznie pytam)?

Pod Windows da się w tym pisać skrypty powłoki [podobnie
jak w Visual Basicu] ;P

-- 
SasQ

Aleksander Galicki wrote:
> A JavaScript jest uzywany gdzie indziej niz w browserze (powaznie pytam)?

Mozna oskryptowac PDF-y, ale zadziala tylko w Adobowych przegladarkach;
inne, jak xpdf, nie implementuja pelnego standardu PDF.

w.

Cześć,

Trochę off-topic, ale z tą "nie byle jaką" implementacjąJTA to chyba
trochę rozdmuchałeś. O ile wiem (od ludzi, którzy w firmie tym tematem
zajmują się od 15 lat), to Arjuna którą JBoss kupił była takim
kukułczym jajem i wielu systemów to na niej nie ma (mówi się o max.
30). Dobrych implementacji monitorów transakcyjnych jest niewiele -
swoją drogą widziałem już też przewrócenie się b. dużego projektu w
Polsce "dzięki" implementacji JTA w jednym komercyjnym serwerze
aplikacyjnym dużej firmy (spoza czołowej dwójki)... Transakcje
(zwłaszcza rozproszone) to niełatwy temat...

Pozdrawiam,
Waldek Kot
BEA

waldemar.kot@bea.com napisał(a): 

> Cze=B6=E6,
> 
> Troch=EA off-topic, ale z t=B1 "nie byle jak=B1" implementacj=B1JTA to chyba
> troch=EA rozdmucha=B3e=B6.

Mialem na mysli, ze nie jest to zwyczajnie open source implementacja - bazuje 
sie na implementacji closed source, a nie napisana przez JBoss od poczatku.

> O ile wiem (od ludzi, kt=F3rzy w firmie tym tema=
> tem
> zajmuj=B1 si=EA od 15 lat), to Arjuna kt=F3r=B1 JBoss kupi=B3 by=B3a takim
> kuku=B3czym jajem i wielu system=F3w to na niej nie ma (m=F3wi si=EA o max.
> 30). 

A te informacje to sa od pracownikow BEA? Wiadomo jak sie nalezy odnosic do 
informacji o JBoss od pracownikow BEA (i odwrotnie - do informacji o WebLogic 
od pracownikow JBossa) - ignorowac. 
Jakby nie bylo na Arjuna bazuje sie JBossTS, a na tym stoi juz caaalkiem 
sporo duzych aplikacji. Kolega ktory siedzi obok mnie (zwykle, bo dzis jest 
chory) byl jednym z osob odpowiedzialnych za przeprowadzenie certyfikacji 
J2EE dla JBossa, zapytam go o Arjuna jak wyzdrowieje.


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

On 3 May 2007 14:23:23 -0700, waldemar.kot@bea.com wrote:

>Cześć,
[..]...
>
>Pozdrawiam,
>Waldek Kot
>BEA

Ja wiem ze BEA najlepsza.

A.L.

Cześć,

Tak od pracowników BEA (czego nie ukrywałem). Co do certyfikacji J2EE:
niestety, ale testy podczas certyfikacji J2EE nie testują jakości
implementacji, a tylko czy spełnia ustalone API. Różnice między
implementacjami są spore - nawet (a może zwłaszcza) w tak wydawałoby
się oczywistych zagadnieniach jak transakcje rozproszone. Problem nie
dotyczy oczywiście tylko JBoss-a (mój przykład z życia wzięty dotyczył
komercyjnego app serwera). Myślę, że po prostu dobra implementacja
transakcji rozproszonych wymaga trzech rzeczy: czasu, dużej liczby
zastosowań typu mission-critical (np. transakcje bankowe) i
maniakalnego podejścia do szczegółów. Do tego dochodzi jeszcze
konieczność testowania z różnymi menedżerami zasobów (różne bazy
danych, systemy kolejkowe, itd.). Znowu coś czego testy J2EE nie
obejmują. Być może stąd bierze się sytuacja na rynku monitorów
transakcyjnych i serwerów aplikacyjnych w zastosowaniach poważnych,
gdzie liczy się 3 może 4 graczy...

Nie chciałem wywoływać flamewar'a, ale też czytający powinni mieć
właściwy obraz rynku - niestety jedni zajmują się szlifowaniem
technologii a inni marketingiem internetowym... co robić, takie
czasy...

Pozdrawiam,
Waldek Kot
BEA

waldemar.kot@bea.com wrote:

> Cześć,
> 
> Tak od pracowników BEA (czego nie ukrywałem). Co do certyfikacji J2EE:
> niestety, ale testy podczas certyfikacji J2EE nie testują jakości
> implementacji, a tylko czy spełnia ustalone API. (...)

Mam wrażenie, że na _tej_ grupie Twoje wypowiedzi bardziej szkodzą niż
służą Twojej firmie. Rada od bliźniego: nie brnij...

-- 
Mariusz Lotko

On Fri, 04 May 2007 21:15:18 +0200, Mariusz Lotko
<imie.nazwisko@wp.pl> wrote:

>waldemar.kot@bea.com wrote:
>
>> Cześć,
>> 
>> Tak od pracowników BEA (czego nie ukrywałem). Co do certyfikacji J2EE:
>> niestety, ale testy podczas certyfikacji J2EE nie testują jakości
>> implementacji, a tylko czy spełnia ustalone API. (...)
>
>Mam wrażenie, że na _tej_ grupie Twoje wypowiedzi bardziej szkodzą niż
>służą Twojej firmie. Rada od bliźniego: nie brnij...

Druga rada: za podpisanie sie nazwa firmy bez posiadania autoryzacji i
uzgodnienia z marketingiem mozna wyleciec z pracy w milisekunde. Co
prawda, nie wiem jak to by bylo w polskiej firme, ale BEA bynajmniej
nie jest polska...

A.L.

Dzięki za "radę". Polecam: http://dev2dev.bea.com/community/blogs/policy.html

Pozdrawiam,
Waldek Kot
BEA

A tak merytorycznie ?

Pozdrawiam,
Waldek Kot
BEA

waldemar.kot@bea.com napisał(a): 

> Cze=B6=E6,
> 
> Tak od pracownik=F3w BEA (czego nie ukrywa=B3em). Co do certyfikacji J2EE:
> niestety, ale testy podczas certyfikacji J2EE nie testuj=B1 jako=B6ci
> implementacji, a tylko czy spe=B3nia ustalone API. 

Prosze zauwazyc, ze ja w ogole nie mowilem o jakosci ani JBossa ani czegos 
innego. Ale powtarzanie plotek o konkurencji BEA, zaslyszanych od pracownikow 
BEA niczemu dobremu raczej nie sluzy. Kazdy, kto cokolwiek sledzi rynek app 
serverow, wie, ze BEA i JBoss posiadaja proven track record polewania sie 
nawzajem blotem, siania FUD i takich tam. Co nie dziwne, bo w przypadku BEA i 
JBoss to walka o przezycie (IBM i Oracle moga przezyc i bez app serverow).
Nawiasem mowiac - ja uczestniczylem w projektach zarowno z JBoss jak i z 
WebLogic. I musze powiedziec ze JBoss przeszedl dluga droge od softu o dosc 
koszmarnej jakosci (ze 4-5 lat temu) do softu, ktory powoduje, ze wiele osob 
zaczyna watpic dlaczego musza placic dosc kosmiczne kwoty za np WebLogic.


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Mam odmienną opinię od Twojej. Proponuję zakończyć temat, bo robi się
emocjonalnie, zamiast rzeczowo. Szkoda czasu czytelników tego wątku.

Pozdrawiam,
Waldek Kot
BEA

On 4 May 2007 13:00:32 -0700, waldemar.kot@bea.com wrote:

>Dzięki za "radę". Polecam: http://dev2dev.bea.com/community/blogs/policy.html
>
>Pozdrawiam,
>Waldek Kot
>BEA

Think about the consequences - the potential readers of your blog
include other developers, architects, IT managers, business partners
and clients. Think about what you say, and how it will affect them and
BEA's relationship with them. Don't embarrass us, or yourself. 

A.L.

On 4 May 2007 14:37:15 -0700, waldemar.kot@bea.com wrote:

>Mam odmienną opinię od Twojej. Proponuję zakończyć temat, bo robi się
>emocjonalnie, zamiast rzeczowo. Szkoda czasu czytelników tego wątku.
>
>Pozdrawiam,
>Waldek Kot
>BEA

Slusznie. To nei jest meijsce na reklamy zadnej konkretnej firmy.
reklamy razdko kiedy sa merytoryczne.

A.L.

waldemar.kot@bea.com napisał(a): 

> Mam odmienn=B1 opini=EA od Twojej. Proponuj=EA zako=F1czy=E6 temat, bo robi=
>  si=EA
> emocjonalnie, zamiast rzeczowo. Szkoda czasu czytelnik=F3w tego w=B1tku.
> 

Odmienna opinie? Ale na temat czego: plotek o konkurencji czy czegos innego? 
A moze chodzi o kwalifikacje stwierdzen ktore padly? Stwierdzenie ze "produkt 
konkurencji to takie kukulcze jajo i malo kto go uzywa" to jest plotka. Nie 
plotka byloby np. pokazanie jak ow produkt konkurencji sie wywraca w tych czy 
innych warunkach.
Zreszta, ja jestem bardzo daleki od traktowania serwerow aplikacji 
emocjonalnie. Moj obecny produkt chodzi wlasnie na WL 9.1 (bedzie tez 
portowany na inne platformy, ale to inna historia).


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Aleksander - Po pierwsze wyraziłem opinię, nie plotkę. Podałem fakt -
coś, czego sam doświadczyłem (dokładnie to co napisałeś: wywracający
się produkt konkurencji - i nie był to JBoss - i to z powodu
wydawałoby się tak dobrze rozpoznanego tematu jak JTA). Przytoczyłem
także opinię o popularności Arjuny - opinię, która pochodzi z raczej
merytorycznej strony - jednego z ludzi, którzy stworzyli standard
transakcji rozproszonych XA (nawet nie śmiem podważać tego rodzaju
opinii). Nie lubię bigoterii - nie ukrywałem gdzie pracuję i czym się
zajmuję - także po to, aby czytelnik mojej opinii nie czuł się
oszukany. Doskonale wiem, że takie podejście czasem (na szczęście
rzadko) wyzwala podejrzenie o spam - nie znam metody, aby się przed
tym ustrzec - w każdej dyskusji potrzebna jest odrobina zaufania, aby
strony się nawzajem słuchały. Przykro mi, że Ty i A.L. założyliście
inaczej (A.L. nawet mnie postraszył, że z firmy wylecę - co było
kompletnie off-topic...).

Po drugie, nigdzie nie pojawiło się z mojej strony wychwalanie mojej
firmy - starałem się opisać merytorycznie sytuację na rynku tak, jak
JA ją widzę. Wyraziłem opinię dlaczego (moim zdaniem) jest jak jest. W
tym sensie moja wypowiedź nie różniła się od Twojej - ot, dwie opinie
dwóch różnych osób. Na szczęście (!) jest wielu dostawców i można
wybierać. Nie wierzę, że da się ludzi "ogłupić" ładnymi slajdami na
prezentacji, albo spamem...

Po trzecie, mam odmienną opinię co do "obrzucania się błotem", bo jest
"walka o przeżycie". Ja tego "obrzucania" ze strony mojej firmy nie
widzę. Są inne sposoby walki na konkurencyjnym rynku. Na ekonomii mnie
uczyli, że z ofertą można iść wszerz (efekt skali), można też wgłąb
(specjalizacja). Obserwuję ten rynek od ładnych 5 lat - u dwóch
różnych dostawców middleware. Middleware stał się dużym rynkiem i
obejmuje sporo tematów - nie tylko app serwery - a i te się mocno
dywersyfikują. Różne firmy po prostu wybierają różne strategie -
wyniki finansowe są chyba najlepszym miernikiem sukcesu lub porażki
danej strategii. A z tym w BEA nie jest źle.

Po czwarte - co do wyboru darmowy app serwer versus płatny app serwer
- cena odzwierciedla wartość dla Klienta. A klienci mają różne
oczekiwania, Na przykład dla jednych wartością jest posiadanie
wsparcia technicznego - i są gotowi za to zapłacić. Dla jednych ważna
jest oficjalna certyfikacja Spring, dla innych nie. Niektórzy mają
bardzo wysokie oczekiwania co do wydajności - w innych projektach
"good-enough" wystarczy. Sprawa jakości transakcji rozproszonych od
których zaczęliśmy ten wątek - jedni tego chcą i są gotowi zapłacić,
inni - nie. Dla jednych dostęp do kodu jest b. ważny - dla innych nie,
bo liczy się przede wszystkim niezawodność. Takich przykładów
oczekiwań jest wiele. Moja mądra żona często mi powtarza, że gdyby
jedynym kryterium wyboru była cena, to wszyscy chodzilibyśmy w
chińskich tenisówkach i jeździlibyśmy maluchami.

Sprawa staje się jeszcze ciekawsza dzięki temu, że oczekiwania ciągle
się zmieniają - coś co kiedyś było oczekiwaniem typu cutting edge, za
parę lat staje się commodity. Ale pojawiają się nowe oczekiwania -
okno zmian stale się przesuwa w czasie. Middleware też nie stoi w
miejscu.

Wierz mi - ja się bardzo cieszę, że ludzie mają wybór - BEA także
wspiera społeczność open source (zwłaszcza Apache Software Foundation
i Eclipse - głównie z racji ich merytokratycznej kultury), bo jest to
świetny sposób na sprawdzenie i rozpropagowanie określonej
technologii. Przykład - przekazanie do Apache Geronimo kodu źródłowego
Kodo i utworzenie OpenJPA. Na tym darmowy Geronimo bardzo mocno
skorzysta. Ale przy tym zatrzymanie pewnych funkcjonalności
"enterprise" i zaoferowanie ich jako płatnych w WebLogic Server - z
przekonaniem, że dla OKREŚLONEJ grupy klientów będzie to stanowiło
wartość, uzasadniającą wydanie pieniędzy.

OK - na koniec - najważniejsze - powrót do wątku o Groovy :-) Jak dla
mnie bardzo fajna sprawa, bo pozwala zrobić wiele rzeczy znacznie
prościej, a przy tym ciągle w odwodzie ma się Java (a zwłaszcza jej
infrastrukturę J2EE/JEE oraz frameworki - typu Spring). W sumie to
ciekawe, że tak w sumie niewiele dodatków - typu closures,
metaclass'y, dynamiczne typowanie, dynamiczne budowanie klas,
builder'y czy wbudowana obsługa Map/Lists/Ranges - potrafiły tak
poprawić zwięzłość Java. Poza tym Groovy (a także Ruby/JRuby) zmusza
ludzi decydujących o rozwoju Java do odświeżenia tego języka (mam
nadzieję, że będzie miało to taki pozytywny efekt jak Spring na J2EE/
JEE).
Przyglądam się także od dosyć długiego czasu Grails - b. fajne - z
niecierpliwością czekam na ustabilizowanie się w postaci 1.0. Na razie
to myślę, że "bezpiecznie", to można jedynie poeksperymentować - ale i
tak warto.

Pozdrawiam,
Waldek Kot
BEA

waldemar.kot@bea.com napisał(a): 

> Aleksander - Po pierwsze wyrazi=B3em opini=EA, nie plotk=EA. Poda=B3em fakt=
>  -
> co=B6, czego sam do=B6wiadczy=B3em (dok=B3adnie to co napisa=B3e=B6: wywrac=
> aj=B1cy
> si=EA produkt konkurencji - i nie by=B3 to JBoss - i to z powodu
> wydawa=B3oby si=EA tak dobrze rozpoznanego tematu jak JTA). Przytoczy=B3em
> tak=BFe opini=EA o popularno=B6ci Arjuny - opini=EA, kt=F3ra pochodzi z rac=
> zej
> merytorycznej strony - jednego z ludzi, kt=F3rzy stworzyli standard
> transakcji rozproszonych XA (nawet nie =B6miem podwa=BFa=E6 tego rodzaju
> opinii). Nie lubi=EA bigoterii - nie ukrywa=B3em gdzie pracuj=EA i czym si=
> =EA
> zajmuj=EA - tak=BFe po to, aby czytelnik mojej opinii nie czu=B3 si=EA
> oszukany. Doskonale wiem, =BFe takie podej=B6cie czasem (na szcz=EA=B6cie
> rzadko) wyzwala podejrzenie o spam - nie znam metody, aby si=EA przed
> tym ustrzec - w ka=BFdej dyskusji potrzebna jest odrobina zaufania, aby
> strony si=EA nawzajem s=B3ucha=B3y. Przykro mi, =BFe Ty i A.L. za=B3o=BFyli=
> =B6cie
> inaczej (A.L. nawet mnie postraszy=B3, =BFe z firmy wylec=EA - co by=B3o
> kompletnie off-topic...).
> 
> Po drugie, nigdzie nie pojawi=B3o si=EA z mojej strony wychwalanie mojej
> firmy - stara=B3em si=EA opisa=E6 merytorycznie sytuacj=EA na rynku tak, jak
> JA j=B1 widz=EA. Wyrazi=B3em opini=EA dlaczego (moim zdaniem) jest jak jest=
> .. W
> tym sensie moja wypowied=BC nie r=F3=BFni=B3a si=EA od Twojej - ot, dwie op=
> inie
> dw=F3ch r=F3=BFnych os=F3b. Na szcz=EA=B6cie (!) jest wielu dostawc=F3w i m=
> o=BFna
> wybiera=E6. Nie wierz=EA, =BFe da si=EA ludzi "og=B3upi=E6" =B3adnymi slajd=
> ami na
> prezentacji, albo spamem...

Po raz ostatni: pretensje sa o to, ze krytykujesz produkt konkurencji (Arjuna 
- JBoss) podajac jedynie opinie pracownikow wlasnej firmy i zadnych, ale to 
zadnych, szczegolow. Ze ktos pracowal nad XA? No to niech sie popisze swoja 
wiedza i poda taka merytoryczna krytyke Arjuny. Bo na razie to tylko i 
wylacznie FUD. Ja nie potrafie tego jasniej napisac - jesli sie wypowiada o 
bezposredniej konkurencji to obowiazuje nieco wyzsze standardy niz zwyczajnie.


Co do oglupiania - obawiam sie ze oglupianie to wciaz najbardziej powszechna 
forma marketingu w IT. Z mojego punktu siedzenie wynika, ze w procesie 
podejmowania decyzji  korporacyjnych enterprise astronauts kolorowe slajdy 
graja nie ostatnia role. Prosze popatrzec jak takie firmy jak IONA i BEA 
probuja ze swoimi kolorowymi slajdami wskoczyc na pociag pt SOA (ilez kasy 
mozna zarobic poki ludzi nie odkryja czym SOA jest naprawde - http://
soafacts.com/).

> Po trzecie, mam odmienn=B1 opini=EA co do "obrzucania si=EA b=B3otem", bo j=
> est
> "walka o prze=BFycie". Ja tego "obrzucania" ze strony mojej firmy nie
> widz=EA. S=B1 inne sposoby walki na konkurencyjnym rynku. Na ekonomii mnie
> uczyli, =BFe z ofert=B1 mo=BFna i=B6=E6 wszerz (efekt skali), mo=BFna te=BF=
>  wg=B3=B1b
> (specjalizacja). Obserwuj=EA ten rynek od =B3adnych 5 lat - u dw=F3ch
> r=F3=BFnych dostawc=F3w middleware. Middleware sta=B3 si=EA du=BFym rynkiem=
>  i
> obejmuje sporo temat=F3w - nie tylko app serwery - a i te si=EA mocno
> dywersyfikuj=B1. R=F3=BFne firmy po prostu wybieraj=B1 r=F3=BFne strategie -
> wyniki finansowe s=B1 chyba najlepszym miernikiem sukcesu lub pora=BFki
> danej strategii. A z tym w BEA nie jest =BCle.
> 
> Po czwarte - co do wyboru darmowy app serwer versus p=B3atny app serwer
> - cena odzwierciedla warto=B6=E6 dla Klienta. A klienci maj=B1 r=F3=BFne
> oczekiwania, Na przyk=B3ad dla jednych warto=B6ci=B1 jest posiadanie
> wsparcia technicznego - i s=B1 gotowi za to zap=B3aci=E6. Dla jednych wa=BF=
> na
> jest oficjalna certyfikacja Spring, dla innych nie. Niekt=F3rzy maj=B1
> bardzo wysokie oczekiwania co do wydajno=B6ci - w innych projektach
> "good-enough" wystarczy. Sprawa jako=B6ci transakcji rozproszonych od
> kt=F3rych zacz=EAli=B6my ten w=B1tek - jedni tego chc=B1 i s=B1 gotowi zap=
> =B3aci=E6,
> inni - nie. Dla jednych dost=EAp do kodu jest b. wa=BFny - dla innych nie,
> bo liczy si=EA przede wszystkim niezawodno=B6=E6. Takich przyk=B3ad=F3w
> oczekiwa=F1 jest wiele. Moja m=B1dra =BFona cz=EAsto mi powtarza, =BFe gdyby
> jedynym kryterium wyboru by=B3a cena, to wszyscy chodziliby=B6my w
> chi=F1skich tenis=F3wkach i je=BCdziliby=B6my maluchami.

Cena rzeczywiscie odzwierciedla wartosc dla klienta, ale troche nie zgadzamy 
sie co do mechanizmu wyceny. 

> Sprawa staje si=EA jeszcze ciekawsza dzi=EAki temu, =BFe oczekiwania ci=B1g=
> le
> si=EA zmieniaj=B1 - co=B6 co kiedy=B6 by=B3o oczekiwaniem typu cutting edge=
> , za
> par=EA lat staje si=EA commodity. Ale pojawiaj=B1 si=EA nowe oczekiwania -
> okno zmian stale si=EA przesuwa w czasie. Middleware te=BF nie stoi w
> miejscu.
> 
> Wierz mi - ja si=EA bardzo ciesz=EA, =BFe ludzie maj=B1 wyb=F3r - BEA tak=
> =BFe
> wspiera spo=B3eczno=B6=E6 open source (zw=B3aszcza Apache Software Foundati=
> on
> i Eclipse - g=B3=F3wnie z racji ich merytokratycznej kultury), bo jest to
> =B6wietny spos=F3b na sprawdzenie i rozpropagowanie okre=B6lonej
> technologii. Przyk=B3ad - przekazanie do Apache Geronimo kodu =BCr=F3d=B3ow=
> ego
> Kodo i utworzenie OpenJPA. Na tym darmowy Geronimo bardzo mocno
> skorzysta. Ale przy tym zatrzymanie pewnych funkcjonalno=B6ci
> "enterprise" i zaoferowanie ich jako p=B3atnych w WebLogic Server - z
> przekonaniem, =BFe dla OKRE=A6LONEJ grupy klient=F3w b=EAdzie to stanowi=B3o
> warto=B6=E6, uzasadniaj=B1c=B1 wydanie pieni=EAdzy.

Firma BEA wspiera open source ze wzgledu na "ich merytokratyczna kulture"? I 
dlatego wspiera Eclipse, przekazuje cos Apache? Obawiam sie, ze istnieja 
uzasadnienia mniej sprzeczne ze zdrowym rozsadkiem. Jeszcze zadna firma 
komercyjna nie wspierala open source z powodow innych niz biznesowe. Powiem 
tak: BEA wspiera Eclipse, bo musi, bo nie ma innego wyboru, bo musi miec 
narzedziowe wsparcie dla swoich produktow a nie jest w stanie wyprodukowac 
narzedzia rownie popularnego co Eclipse. Bez Eclipse narzedzia BEA bylyby 
niewiele warte i zupelnie zmarginalizowane.
OpenJPA? Oddaja bo: a) i tak nie potrafiliby tego sprzedac (skoro Hibernate 
jest calkiem niezle i darmowe) b) probuja oslabic pozycje JBoss (ktorego 
mocnym punktem zawsze byl Hibernate) i c) zarobic pare punktow u Apache - 
najbardziej vocal open source community w Javaland. (A co do merytokratycznej 
kultury Apache - na ten temat mam zdanie podobne do zdania Haniego Suleimana, 
ktorego doslownie nie powtorze bo nie wypada..) Nawiasem mowiac, pracowalem z 
Kodo jeszcze zanim zostalo kupione przez BEA. Z Toplinkiem tez pracowalem i 
tez zostalo przez Oracla oddane - z podobnych powodow.

Gdyby naprawde chcieli wspierac open source - oddaliby swoja implementacje 
JTA i swoj clustering :-)

> OK - na koniec - najwa=BFniejsze - powr=F3t do w=B1tku o Groovy :-) Jak dla
> mnie bardzo fajna sprawa, bo pozwala zrobi=E6 wiele rzeczy znacznie
> pro=B6ciej, a przy tym ci=B1gle w odwodzie ma si=EA Java (a zw=B3aszcza jej
> infrastruktur=EA J2EE/JEE oraz frameworki - typu Spring). W sumie to
> ciekawe, =BFe tak w sumie niewiele dodatk=F3w - typu closures,
> metaclass'y, dynamiczne typowanie, dynamiczne budowanie klas,
> builder'y czy wbudowana obs=B3uga Map/Lists/Ranges - potrafi=B3y tak
> poprawi=E6 zwi=EAz=B3o=B6=E6 Java. Poza tym Groovy (a tak=BFe Ruby/JRuby) z=
> musza
> ludzi decyduj=B1cych o rozwoju Java do od=B6wie=BFenia tego j=EAzyka (mam
> nadziej=EA, =BFe b=EAdzie mia=B3o to taki pozytywny efekt jak Spring na J2E=
> E/
> JEE).

Nie jestem specjalnym fanem dynamicznego typowania dla typowych bisnesowych 
projektow. Mam w firmie pare starych smalltalkowcow kompletnie nawroconych na 
statyczne typowanie. Zwiezlosc tez mnie nie grzeje ani nie ziebi. Closures 
najprawdopodobniej zostana dodane do Java 1.7, ale prawde mowiac na porzadku 
dziennym w Java sa powazniejsze problemy niz syntactic sugar (choc closures 
milo byloby miec). Np naprawa formatu JAR (JSR-277 (Java Module System)) czy 
JSR 291.


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

waldemar.kot@bea.com wrote:

> A tak merytorycznie ?

Jeśli potrzebujesz dalszych wyjaśnień, to chyba nie mogę
Ci pomóc.

Powodzenia.

-- 
Mariusz Lotko

A.L. <fela@2005.com> writes:

[...]

> Slusznie. To nei jest meijsce na reklamy zadnej konkretnej firmy.

No, chyba że D-Wave :>

Wyrażasz bardzo radykalne opinie.
Co do ogłupiania slajdami, to cóż - ja mam inne doświadczenia i w
możliwość przekonania kogoś do technologii w taki sposób nie wierzę.
Co do SOA - jeśli tak rozumiesz SOA, to widać nie masz takich
problemów, jakie SOA próbuje zaadresować. Ale wielu innych ludzi ma i
próbuje szukać jak te problemy wyeliminować albo przynajmniej
zminimalizować. Im to jest potrzebne.
Co do Eclipse - widzisz - słyszę różne opinie od klientów. Dla jednych
jest to krok wstecz, bo - jak twierdzą - znacznie trudniej jest im
budować aplikacje. Zdaniem innych - zwłaszcza deweloperów - był to
bardzo dobry krok, bo mogą budować aplikacje w znanym środowisku.
Opinie są różne.
Co do OpenJPA - tu znowu bardzo radykalnie to widzisz - ja mam inne
zdanie. Kodo było (i jest) całkiem dochodowym biznesem. Na pewno nie
było tak popularne jak Hibernate i nic dziwnego - Kodo (podobnie jak
TopLink) zawsze były przede wszystkim skierowane do rynku enterprise.
Rynek enterprise to jest inny świat i kieruje się moim zdaniem zupełne
innymi kryteriami wyboru - to co napisałem we wcześniejszym poście -
cena nie jest jedynym kryterium wyboru. Twoje oczekiwania mogą być
zupełnie inne - OK, ale oczekiwania innych trzeba uszanować. Java nie
jest monokulturowa jak choćby środowisko Microsoft-u i zakłada wielość
implementacji rozwiązania tego samego problemu oraz wolność wyboru - w
czym mają pomóc m.in. standardy (zarówno de jure - np. JCP, jak i de
facto - np. Spring). Ja osobiście się z tego cieszę, że jest wiele
implementacji i ludzie mają możliwość wyboru, choć wybór jest
trudniejszy. OT - inna filozofia.
Co do JBoss - pewnie zdziwisz się, ale mi oni nie przeszkadzają (przez
te ostatnie 5 lat może ze 3 razy się spotkaliśmy). Powiem więcej -
widać branża jest zdrowa - są i Fiaty i Mercedesy - jest kilka low-
end'owych app serwerów, kilka high-endowych i to dobrze. Fiat jest
bardziej popularny od Mercedesda ? Na pewno. I co z tego ? Inne są
potrzeby kupujących Fiaty, inne Mercedesy.
Co do Apache - wielu ludziom (także spoza świata komercyjnego) właśnie
ta merytokratyczność Apache podoba się - i mają problemy, żeby
odnaleźć ją w innych społecznościach, mimo iż ASF nie jest ideałem
(czy cokolwiek jest ?). Ale taki jest ich wybór i trzeba to uszanować.
Co do JTA i clusteringu - zobaczymy, jeśli opisane wcześniej "okno
zmian" przesunie się to kto wie.

Co do dynamicznego typowania w Grooviem - to co mi się podoba, to
możliwość wyboru :-), bo Groovie dopuszcza zarówno statyczne, jak i
dynamiczne typowanie. Dodatkowo, dzięki integracji z Java, zawsze
można skorzystać z tego co Java oferuje (i to jest także wielki atut
JRuby). To co pewnie się zmieniło przez te ostatnie kilka lat, to to,
że już nawet do mainstream'u trafiło przekonanie o absolutnej
krytyczności tworzenia unit testów (i innych form testowania) i
traktowania testowania na równi z kodowaniem. Bez takiego podejścia,
to rzeczywiście można się bardzo pokaleczyć o dynamizmy. Z takim
podejściem, to pewnie za jakiś czas kompilacja bardziej będzie
przypominać unit test - jeden z wielu.
Zgadzam się z Tobą, że wykorzystanie Grooviego, Grailsów (i podobnych)
DZISIAJ to dodatkowe ryzyko dla projektu - podobnie było z Java 10 lat
temu, czy wcześniej z C++ . Pobawić się i poeksperymentować warto -
ostatnio rozmawiałem z jednym znajomym, który powiedział, że - zabawne
- ale dzięki Grailsom lepiej zrozumiał MVC i IoC - cóż wiele dróg
prowadzi do celu.

Co do wymienionych przez Ciebie JSR - absolutna zgoda - choć pewnie
droga będzie wiodła poprzez OSGi, a potem usankcjonowanie w postaci
standardów JCP. Jaskółki zmian i stosowania OSGi już widać - choć
ciągle chce się więcej.

Pozdrawiam,
Waldek Kot
BEA

waldemar.kot@bea.com napisał(a): 

> Wyra=BFasz bardzo radykalne opinie.
> Co do og=B3upiania slajdami, to c=F3=BF - ja mam inne do=B6wiadczenia i w
> mo=BFliwo=B6=E6 przekonania kogo=B6 do technologii w taki spos=F3b nie wier=
> z=EA.
> Co do SOA - je=B6li tak rozumiesz SOA, to wida=E6 nie masz takich
> problem=F3w, jakie SOA pr=F3buje zaadresowa=E6. Ale wielu innych ludzi ma i
> pr=F3buje szuka=E6 jak te problemy wyeliminowa=E6 albo przynajmniej
> zminimalizowa=E6. Im to jest potrzebne.


Po odsianiu markitingu od SOA zostaje zwykle coarse grained interface + loose 
coupling. Ludzi tak od zarania dziejow systemy pisali. Ale teraz to nazwali 
SOA i nawet sprzedaja za grube pieniadze.

> Co do Eclipse - widzisz - s=B3ysz=EA r=F3=BFne opinie od klient=F3w. Dla je=
> dnych
> jest to krok wstecz, bo - jak twierdz=B1 - znacznie trudniej jest im
> budowa=E6 aplikacje. Zdaniem innych - zw=B3aszcza deweloper=F3w - by=B3 to
> bardzo dobry krok, bo mog=B1 budowa=E6 aplikacje w znanym =B6rodowisku.
> Opinie s=B1 r=F3=BFne.

Z mojego punktu siedzenia narzedzia developerskie BEA nie byly wykorzystywane 
zupelnie - zanim jako tako nie wprowadzili support dla Eclipse. Obecnie 
programisci Javy uzywaja glownie Eclipse, IntelliJ i NetBeans i nikt zdrowy 
na umysle nie bedzie przekonywal developerow do uzywania jeszcze jakiegos 
home-made IDE "tylko dla naszego ukochanego app servera". BEA jest zdrowa na 
umysle i zrobila to co bylo jedynie wlasciwe.

> Co do OpenJPA - tu znowu bardzo radykalnie to widzisz - ja mam inne
> zdanie. Kodo by=B3o (i jest) ca=B3kiem dochodowym biznesem. Na pewno nie
> by=B3o tak popularne jak Hibernate i nic dziwnego - Kodo (podobnie jak
> TopLink) zawsze by=B3y przede wszystkim skierowane do rynku enterprise.

Rynek enterprise - to brzmi groznie. Ja tam nie wiem - z mojego punktu 
siedzenia od paru lat uzywa sie Hibernate - prawie wszedzie. W bankach, 
instytucjach finansowych, w telco, w projektach rzadowych, w moim projekcie. 
Jak sie patrzy na job offers to sie widzi Hibernate, nie Kodo, nie Toplink. 
Kodo i Toplink od paru lat jakby nie istnieja na rynku i to z dobrych 
powodow. 
Funkcjonalnosc jest wzglednie taka sama, ale, Hibernate ma spore community, 
dobra dokumentacje i jest to zywy, ewolujacy produkt. Roznica pomiedzy 
wyborem WebLogica a Kodo jest taka, ze WebLogic (jak rowniez konkretna baza 
danych, system operacyjny i inne podobne) jest czesto odgornie narzucony 
przez corporate policies klienta, umowy miedzyfirmowe klienta i najczesciej 
wybor WebLogica jest koniecznoscia biznesowa nie technologiczna. Wybor OR 
mappera nie jest zwykle regulowanany ani owymi corporate policies ani zadnymi 
umowami - jest calkowicie w gestii osob odpowiedzialnych za implementacje. I 
tu wlasnie liczy sie to w czym Hibernate bije na glowe Kodo - popularnosc, 
community acceptance, fakt, ze na rynku da sie znalezc osoby z doswiadczeniem 
w Hibernate, ale nie da sie tych od Kodo.

> Rynek enterprise to jest inny =B6wiat i kieruje si=EA moim zdaniem zupe=B3ne
> innymi kryteriami wyboru

To wyglada jak poczatek bajki o zelaznym wilku, albo zajawka nowej post-
nuclear adventure. Wszyscy jestesmy w enterprise - tam gdzie sie pieniadze 
robia. Niektorzy poprostu nieproporcjonalnie dumni sa z tego epitetu. I 
Hibernate jest dzisiaj bardziej enterprise i mainstream niz Kodo - takie 
zycie.

>  - to co napisa=B3em we wcze=B6niejszym po=B6cie -
> cena nie jest jedynym kryterium wyboru. Twoje oczekiwania mog=B1 by=E6
> zupe=B3nie inne - OK, ale oczekiwania innych trzeba uszanowa=E6. Java nie
> jest monokulturowa jak cho=E6by =B6rodowisko Microsoft-u i zak=B3ada wielo=
> =B6=E6
> implementacji rozwi=B1zania tego samego problemu oraz wolno=B6=E6 wyboru - w
> czym maj=B1 pom=F3c m.in. standardy (zar=F3wno de jure - np. JCP, jak i de
> facto - np. Spring). Ja osobi=B6cie si=EA z tego ciesz=EA, =BFe jest wiele
> implementacji i ludzie maj=B1 mo=BFliwo=B6=E6 wyboru, cho=E6 wyb=F3r jest
> trudniejszy. OT - inna filozofia.
> Co do JBoss - pewnie zdziwisz si=EA, ale mi oni nie przeszkadzaj=B1 (przez
> te ostatnie 5 lat mo=BFe ze 3 razy si=EA spotkali=B6my). Powiem wi=EAcej -
> wida=E6 bran=BFa jest zdrowa - s=B1 i Fiaty i Mercedesy - jest kilka low-
> end'owych app serwer=F3w, kilka high-endowych i to dobrze. Fiat jest
> bardziej popularny od Mercedesda ? Na pewno. I co z tego ? Inne s=B1
> potrzeby kupuj=B1cych Fiaty, inne Mercedesy.

Obawiam sie, ze opowiesc o tym, ze Kodo to Mercedes, a Hibernate to Fiat 
raczej sie dzis nie sprzeda. BEA o tym chyba dobrze wie - stad OpenJPA.


> Co do dynamicznego typowania w Grooviem - to co mi si=EA podoba, to
> mo=BFliwo=B6=E6 wyboru :-), bo Groovie dopuszcza zar=F3wno statyczne, jak i
> dynamiczne typowanie. Dodatkowo, dzi=EAki integracji z Java, zawsze
> mo=BFna skorzysta=E6 z tego co Java oferuje (i to jest tak=BFe wielki atut
> JRuby). To co pewnie si=EA zmieni=B3o przez te ostatnie kilka lat, to to,
> =BFe ju=BF nawet do mainstream'u trafi=B3o przekonanie o absolutnej
> krytyczno=B6ci tworzenia unit test=F3w (i innych form testowania) i
> traktowania testowania na r=F3wni z kodowaniem. Bez takiego podej=B6cia,
> to rzeczywi=B6cie mo=BFna si=EA bardzo pokaleczy=E6 o dynamizmy. 

Ale unit testy nie zastapia statycznego typowania. W projekcie z >4 osobami 
statycznie typowane interface'y pomiedzy poszczegolnymi komponentami poprostu 
znacznie ulatwiaja development. Ja sam jak dla siebie cos pisze w jezyku bez 
statycznego typowania i za pare miesiecy do tego kodu wracam to pierwszym  
pytaniem czesto jest "Ale co autor mial na mysli?".


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

> Użytkownik <waldemar.kot@bea.com> napisał w wiadomości:

Czyzby niestabilny i zupelnie jeszcze raczkujacy Groovy
byl przez Javowcow uzywany czesciej niz okrzeply Jython ?
Az mi sie nie chce wierzyc.

W kilku znanych mi formach od lat uzywa sie Jythona
wiec Groovy nie jest tu czyms nowatorskim.

Na dzien dzisiejszy nie polecam Groovyego.
A juz najmniej JRubyego

AK

Użytkownik "Aleksander Galicki" <tretete@WYTNIJ.gazeta.pl> napisał:

> Ale unit testy nie zastapia statycznego typowania. W projekcie z >4 
> osobami
> statycznie typowane interface'y pomiedzy poszczegolnymi komponentami 
> poprostu
> znacznie ulatwiaja development.

Owszem.
Interfaces znacznei ulatwiaja development.
Zwlaszac wtedy gdy tycza szerszego spektrum niz zwykly typing
znany z C++ czy Javy.

> Ja sam jak dla siebie cos pisze w jezyku bez
> statycznego typowania i za pare miesiecy do tego kodu wracam to pierwszym
> pytaniem czesto jest "Ale co autor mial na mysli?".

W jezykach dynamicznych istnieja o wiele lepsze
mozliwosci uzyskania wszelkich "constraints".
Rowniez na typy.
Smieszy mnie conieco traktowanie statycznego
typowania jako antidotum na wszelkie zlo.
No moze nawet nie conieco. Bardzo mnie smieszy.

AK

Nie żebym się za Javowców wypowiadał, ale U MNIE to zainteresowanie (na
razie czysto "for fun") przebiega(ło) tak: Ruby on Rails -> Ruby -> 
JRuby -> Grails -> Groovy.
Szybkość budowy aplikacji (czy prototypów aplikacji) jaką widać w
Railsach dzięki convention-over-configuration skłoniła mnie do przyjrzenia 
się czy coś podobnego można zastosować w Javie. Na pewno także pomogła w tym 
kula snieżna, która została uruchomiona (i to głównie przez dawnych Java 
guru) wokół Ruby i Rails. Groovy (oraz Grails), przy opisanych wcześniej 
zastrzeżeniach (stabilność, itd), mnie póki co zachęcają aby im się 
poprzyglądać, bo uzupełniają Java (polityka "małych kroczków"), działają na 
JVM i bardzo dobrze integrują się (w obie strony) z istniejącym kodem 
(biblioteki Java, J2EE/JEE i choćby Spring). 
Jython IMHO jest OK choć do pisania w nim aplikacji (lub ich składowych) się 
nie przekonałem (ale już np. skryptów administracyjnych tak - tu zresztą 
Groovie myślę najprędzej będzie konkurował z Jythonem - choćby na początek 
dzięki łatwiejszemu tworzeniu skryptów Ant-a).
Co do JRuby - ja liczę, że trochę przysypie rów między Javowcami a 
Rubyistami (oraz ludźmi którzy przeszli do Ruby/Rails - a jest tu wielu 
PHPowców). Dochodzi także, taki drobny patriotyzm, bo w JRuby jednym z 
core commiterów jest Polak :-)

Pozdrawiam,
Waldek Kot

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Adam Karpierz <karpierz@_NOSPAM_python.pl> napisał(a): 

> Użytkownik "Aleksander Galicki" <tretete@WYTNIJ.gazeta.pl> napisał:
> 
> > Ale unit testy nie zastapia statycznego typowania. W projekcie z >4 
> > osobami
> > statycznie typowane interface'y pomiedzy poszczegolnymi komponentami 
> > poprostu
> > znacznie ulatwiaja development.
> 
> Owszem.
> Interfaces znacznei ulatwiaja development.
> Zwlaszac wtedy gdy tycza szerszego spektrum niz zwykly typing
> znany z C++ czy Javy.
> 
> > Ja sam jak dla siebie cos pisze w jezyku bez
> > statycznego typowania i za pare miesiecy do tego kodu wracam to pierwszym
> > pytaniem czesto jest "Ale co autor mial na mysli?".
> 
> W jezykach dynamicznych istnieja o wiele lepsze
> mozliwosci uzyskania wszelkich "constraints".
> Rowniez na typy.
> Smieszy mnie conieco traktowanie statycznego
> typowania jako antidotum na wszelkie zlo.
> No moze nawet nie conieco. Bardzo mnie smieszy.
> 

Smiech to zdrowie. Tylko kto traktuje statyczne typowanie jako "antidotum na
wszelkie zlo"? Ja takich ludzi jeszcze nie spotkalem. Zwyczajnie bardzo
uzyteczny element przy produkcji oprogramowania. W wiekszosci przypadkow nie
widze pozytywnych rzeczy z rezygnacji z tego elementu, czesciej widze negatywne. 
Nie wiem tez o co chodzi z tymi constraints i jak je uzyskac i jaki to ma
zwiazek z tym o czym pisalem.


A.

-- 
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

Użytkownik "Waldek Kot" <waldemar_kot@WYTNIJ.gazeta.pl> napisał:

> Na pewno także pomogła w tym  kula snieżna, która została uruchomiona
> (i to głównie przez dawnych Java  guru) wokół Ruby i Rails.

Smiac mi sie chce z tego calego szumu wokol RoR :(

AK 

On Sun, 6 May 2007 22:29:39 +0200, "Adam Karpierz"
<karpierz@_NOSPAM_python.pl> wrote:

>> Użytkownik <waldemar.kot@bea.com> napisał w wiadomości:
>
>Czyzby niestabilny i zupelnie jeszcze raczkujacy Groovy
>byl przez Javowcow uzywany czesciej niz okrzeply Jython ?
>Az mi sie nie chce wierzyc.
>

Tak. Jak juz pisalem i  powtorze, w USA Python jest praktycznie
nieznany. Wokol Groovy jest natomiast pewien szum, na zasadzie
"scripting w java 1.6 jest taki sobie, a co jest lepszego?" Okazuje
sie ze Groovy.

>W kilku znanych mi formach od lat uzywa sie Jythona
>wiec Groovy nie jest tu czyms nowatorskim.
>
>Na dzien dzisiejszy nie polecam Groovyego.

A ja polecam. Co wiecej, zaczalem uzywac go dosyc intensywnie.

A.L.

On Sun, 6 May 2007 22:29:39 +0200, "Adam Karpierz"
<karpierz@_NOSPAM_python.pl> wrote:

 
>
>Na dzien dzisiejszy nie polecam Groovyego.
>A juz najmniej JRubyego

Bye the way, na podstawie jakichs praktycznych dowiadczen? czy
teoretycznych rozwazan?

A.L.

Użytkownik "A.L." <fela@2005.com> napisał:

> Tak. Jak juz pisalem i  powtorze, w USA Python jest
> praktycznie nieznany.

A to Ci niespodzianka.
W drugiej amerykanskiej firmie w ktorej pracuje
akurat Jython jest uzywany a o groovym nikt nie slyszal.
(Groovy to tez python - tyle ze nie wiadomo po co
 "wymyslony" od nowa przez co oczywiscie zepsuty).
I to pomimo to ze firmy byly raczej TCLo i Perlo centric.

Po za tym niech sie Pan nie wypowiada za cale USA
bo naraza sie Pan na nieprzyjemny przymiot
bycia alfa i omega.
I to omylna alfa i omega.

>>Na dzien dzisiejszy nie polecam Groovyego.
>
> A ja polecam.

Zdecydowanie nie polecam.
To wymyslanie kola od nowa.
W dodatku poki co niestabilne wymyslanie.

> Co wiecej, zaczalem uzywac go dosyc intensywnie.

Wie Pan , Pan zaczal sobie uzywac Groovy intensywnie od
"kilku dni" a ja w Pythonie i jezykach pythonopodobnych
"siedze" dobrych kilka lat wiec poki co Panskie zdanie ma
ma tu mala moc przekonujaca.

Dopuki Groovy nie bedzie mail wesji 2.48 (a chyba jeszcze
sie nie ukazala stabilna 1.0 - bawilem sie Groovy pol roku temu)
mozna o Groovym zapomniec do powazniejszych zastosowan.

AK

Uzytkownik "A.L." <fela@2005.com> napisal:

>>Na dzien dzisiejszy nie polecam Groovyego.
>>A juz najmniej JRubyego
>
> Bye the way, na podstawie jakichs praktycznych dowiadczen?
> czy teoretycznych rozwazan?

Na podstawie _praktycznych_ doswiadczen.
Bardzo krotkich zreszta (nie bylo potrzeby wiecej).
Na razie to w jezykach pythonopodobnych to raczej
Pan rozwaza teoretycznie.

PS: Owszem. moje doswiadczenia z Groovym moga
      sie polepszyc, ale nie sadze aby szybko.
      Groovy sie slimaczy w sense stabilnosci.

AK