🚀 go-pugleaf

Dnia Fri, 25 May 2007 08:46:33 +0200, Piotr 'piter' Hlawski napisał(a):

> that the kind of applications that people are usually allowed to build in
> Ruby don't have the combination of complex legacy data models, complex
> business logic and large deployment scale that characterizes interesting
> projects in the Java world.

Po pierwsze, ten facet nie rozumie, że RoR nie został zaprojektowany aby
konkurować z wielkimi, korporacyjnymi rozwiązaniami operującymi na
skompplikowanych strukturach tabel. 

Po drugie, jest skrzywiony (wielu javowców tak ma) aby wszystko robić
"obiektowo i za pomocą ORM'a". Czyli jak już wdepnąć w ORM to na całego. 

Tu znowu nie rozumie prostej sprawy. Mianowicie, takie totalne operowanie z
bazą tylko za pomocą abstrakcji ORM w wielu przypadkach jest znacznie
bardziej czasochłonne i skomplikowane niż użycie czystego SQL'a. Twórcy
ActiveRecord (i to jest zdaje się napisane w Agile2) wychodzą z założenia
że ORM ma być pomocą a nie kompleksowym lekarstwem na SQL'a. Czyli
zakładają że w pewnych sytuacjach lepiej będzie użyć czystego SQL zamiast
sobie komplikować życie. Dlatego ActiveRecord jest prosty i w ogóle zaletą
całego Rails jest prostota. A jak potrzeba jakiegoś skomplikowanego
zapytania i użycie SQL jest łatwiejsze, to po prostu należy użyć SQL'a. Nie
bez powodu książki o Railsach wydawane są w serii pragmatic programmers. :)


-- 
Jarosław Zabiełło
http://blog.zabiello.com

On 25 Maj, 10:39, Jaroslaw Zabiello <hipertrac...@gmail.com> wrote:
> Dnia Fri, 25 May 2007 08:46:33 +0200, Piotr 'piter' Hlawski napisał(a):
>
> > that the kind of applications that people are usually allowed to build in
> > Ruby don't have the combination of complex legacy data models, complex
> > business logic and large deployment scale that characterizes interesting
> > projects in the Java world.
>
> Po pierwsze, ten facet nie rozumie, że RoR nie został zaprojektowany aby
> konkurować z wielkimi, korporacyjnymi rozwiązaniami operującymi na
> skompplikowanych strukturach tabel.
>
> Po drugie, jest skrzywiony (wielu javowców tak ma) aby wszystko robić
> "obiektowo i za pomocą ORM'a". Czyli jak już wdepnąć w ORM to na całego.
>
> Tu znowu nie rozumie prostej sprawy. Mianowicie, takie totalne operowanie z
> bazą tylko za pomocą abstrakcji ORM w wielu przypadkach jest znacznie
> bardziej czasochłonne i skomplikowane niż użycie czystego SQL'a.

Oczywiście znasz Hibernate i wiesz, że się da w każdej chwili użyć
czystego SQL'a?

http://www.hibernate.org/hib_docs/v3/reference/en/html/objectstate.html#objectstate-querying-nativesql

Mapując sobie w locie na dowolny obiekt.

>Twórcy
> ActiveRecord (i to jest zdaje się napisane w Agile2) wychodzą z założenia
> że ORM ma być pomocą a nie kompleksowym lekarstwem na SQL'a. Czyli
> zakładają że w pewnych sytuacjach lepiej będzie użyć czystego SQL zamiast
> sobie komplikować życie. Dlatego ActiveRecord jest prosty i w ogóle zaletą
> całego Rails jest prostota. A jak potrzeba jakiegoś skomplikowanego
> zapytania i użycie SQL jest łatwiejsze, to po prostu należy użyć SQL'a.

I wiesz też, że Hibernate ma własny język zapytań za pomocą którego
wyrazisz najbardziej pogmatwane struktury danych i jest on niezależny
od silnika baz danych.


Wg mnie w ActiveRecord za dużo jest native sql'a i trzeba uważać na
konstrukcje aby były zgodne z różnymi dialektami.


Climbus

Dnia 25-05-2007 o 13:43:14 climbus <climbus@gmail.com> napisał(a):

> Oczywiście znasz Hibernate i wiesz, że się da w każdej chwili użyć
> czystego SQL'a?

Wiem że można, ale nie o tym mowa. Zarzut autora polegał na tym, że Active  
Record jest za mało dojrzałą implementacją aby obsługiwać bardziej  
skomplikowane sytuacje. I tu ma rację. Nie zrozumiał tylko tego, że Active  
Record nie został stworzony do walki na tym poziomie złożoności. Tzn. cały  
framework Rails nie ma ambicji konkurować z wielkimi, skomplikowanymi  
systemami w Javie. Zadowala się znacznie mniejszą skalą i tu radzi sobie  
bardzo dobrze, znacznie lepiej niż rozwiązania w Javie. One są da duże, za  
skomplikowane, za czasochłonne. I tą niszę szturmem zdobywa Ruby on Rails.

> I wiesz też, że Hibernate ma własny język zapytań za pomocą którego
> wyrazisz najbardziej pogmatwane struktury danych i jest on niezależny
> od silnika baz danych.

Wiem. I co z tego? Czasami znacznie prościej jest używać SQL'a niż tworzyć  
pogmatwany kod tylko dlatego, żeby był "niezależny" od silnika.

Zresztą nie za bardzo chce mi się wierzyć, że jest taki niezależny.  
Poproszę np. abyś mi stworzył definicję XML dla Hibernate dla następująej,  
prostej tabelki (podaję w postaci SQL dla MySQL5):

CREATE TABLE  tabelka (
   `id` int(10) unsigned NOT NULL auto_increment,
   `chapter` smallint(5) unsigned NOT NULL,
   `txt` text NOT NULL,
   `txt_es` text collate utf8_spanish_ci NOT NULL,
   `txt_pl` text collate utf8_polish_ci NOT NULL,
   PRIMARY KEY  (`id`),
   UNIQUE KEY `idx_uniq` (`chapter`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

Chciałbym aby Hibernet, bez używania specyficznego SQL'a potrafił stworzyć  
poprawną strukturę, wstawił i odebrał rekord dla 3 typów baz: MySQL,  
PostgreSQL i MSSQL2000. Jestem ciekaw czy rzeczywiście będzie "niezależny  
od silnika baz danych"...

> Wg mnie w ActiveRecord za dużo jest native sql'a i trzeba uważać na
> konstrukcje aby były zgodne z różnymi dialektami.

Podaj lepiej jakiś przykład, bo nie wiem co masz na myśli.

-- 
Jarosław Zabiełło
http://blog.zabiello.com

Dnia 25-05-2007 o 13:43:14 climbus <climbus@gmail.com> napisał(a):

> I wiesz też, że Hibernate ma własny język zapytań za pomocą którego
> wyrazisz najbardziej pogmatwane struktury danych i jest on niezależny
> od silnika baz danych.

Masz na myśli HQL? Wiele osób go krytykuje. Po pierwsze, trzeba się uczyć  
kolejnego języka, który ani nie jest łatwy ani aż tak elastyczny jak byś  
myślał. Po drugie, SQL jest znacznie łatwiejszy do testowania i  
optymalizacji od HQL'a. Wiadomo, że pewne optymalizacje są specyficzne dla  
danego silnika. Tak samo inne cechy. Podałem ci w drugim poście przykład  
stworzenia pól sortujących się wg reguł języka polskiego i hiszpańskiego.  
Jestem ciekaw jak to zaimplementujesz w HQL aby działało też z PostgreSQL.

Jak jeszcze masz złudzenia co do tego, że Hibernate nie jest niezależny od  
silnika, to proszę abyś wyraził obiektowo, bez uciekania się do  
nieprzenośnej konstrukcji SQL taką kwerendę (tu dla odmiany wziąłem  
przykład dla PostgreSQL, z artykułu  
http://www.throwingbeans.org/postgresql_and_xml.html)

SELECT
      article_id, xpath_string(article_xml,'/beatles/@id') AS beatle_id
 FROM
      t_articles
WHERE
      xpath_bool(article_xml,'/beatles/beatle[@alive="yes"]');

Gdyby Hibernate był faktycznie zapewniał takie uniwersalne, niezależne od  
bazy mapowanie obiektowe, to by ludzie nie wymyślali projektu iBATIS,  
ktory dla odmiany opiera się na czystym SQL zapakowanym me metody  
obiektowe.

-- 
Jarosław Zabiełło
http://blog.zabiello.com

> Masz na myśli HQL? Wiele osób go krytykuje.

Wiele osób krytykuje Railsa

> Po pierwsze, trzeba się uczyć
> kolejnego języka, który ani nie jest łatwy ani aż tak elastyczny jak byś
> myślał.

Rozumiem, że łatwiej nauczyć się kilku dialektów SQL'a.

> Po drugie, SQL jest znacznie łatwiejszy do testowania i
> optymalizacji od HQL'a.

W czym jest łatwiejszy do testowania? Część optymalizacji myślę
(akurat nie jestem pewien) robi Hibernate znając specyfikę danego
dialektu, zna specyfikę silnika.

> Wiadomo, że pewne optymalizacje są specyficzne dla
> danego silnika. Tak samo inne cechy. Podałem ci w drugim poście przykład
> stworzenia pól sortujących się wg reguł języka polskiego i hiszpańskiego.
> Jestem ciekaw jak to zaimplementujesz w HQL aby działało też z PostgreSQL.

Co ma tworzenie tabel z hql? W Hibernate jest dodatkowe narzędzie do
tworzenia tabel ale to jest tylko pomocnik. Mapuje się raczej
stworzone tabele. W tej skali projektach raczej od tworzenia tabel,
testowania i optymalizacji są całkiem inne działy.

>
> Jak jeszcze masz złudzenia co do tego, że Hibernate nie jest niezależny od
> silnika, to proszę abyś wyraził obiektowo, bez uciekania się do
> nieprzenośnej konstrukcji SQL taką kwerendę (tu dla odmiany wziąłem
> przykład dla PostgreSQL, z artykułu  http://www.throwingbeans.org/postgresql_and_xml.html)
>
> SELECT
>       article_id, xpath_string(article_xml,'/beatles/@id') AS beatle_id
>  FROM
>       t_articles
> WHERE
>       xpath_bool(article_xml,'/beatles/beatle[@alive="yes"]');
>

Zawsze można znaleźć jakieś konstrukcje lub ficzery, które nie są
przenośne, lecz nie w tym rzecz. Jeżeli masz projekt, który wiesz na
jakim silniku będzie chodził i używał elementów danego silnika, które
nie są dostępne pod innymi silnikami to spokojnie możesz używać native
sqla. Tylko w takim przypadku gdzie ta moc ROR? Hibernate daje
możliwość mapowania poszczególnych zapytać na dowolne obiekty. RoR też
ma coś podobnego ale dużo bardziej prostego.

> Gdyby Hibernate był faktycznie zapewniał takie uniwersalne, niezależne od
> bazy mapowanie obiektowe, to by ludzie nie wymyślali projektu iBATIS,
> ktory dla odmiany opiera się na czystym SQL zapakowanym me metody
> obiektowe.
>

Z tego co mi sie wydaje to iBatis jest starszy niż Hibernate. Więc jak
czysty SQL jest taki super to poco ludzie tworzyli Hibernate. Z
drugiej strony jeżeli ActiveRecord jest taki super to poco powstał
"iBATIS for Ruby"? Twoje teoria runęła.

>> Wg mnie w ActiveRecord za dużo jest native sql'a i trzeba uważać na
>> konstrukcje aby były zgodne z różnymi dialektami.

> Podaj lepiej jakiś przykład, bo nie wiem co masz na myśli.

Całe "conditions" to zwykły SQL. Przy bardziej skomplikowanych
zapytaniach i warunkach robi się bałagan. Hibernate ma "criteria"
które można łatwo dodawać a wszystko jest parsowane pod względem
typów.


> Po pierwsze, ten facet nie rozumie, że RoR nie został zaprojektowany aby
> konkurować z wielkimi, korporacyjnymi rozwiązaniami operującymi na
> skompplikowanych strukturach tabel.

A jakie środowisko krzyczało, że jest Java killerem. Że Java umiera.
Więc jak Java umiera a Rails nie został zaprojektowany do
skomplikowanych systemów to co ma być zamiast Javy?


A tak na serio. Rails jest prostym frameworkiem do prostych systemów i
ma prostego i łatwego do nauki ORM'a. Hibernate jest skomplikowanym
ORM'em, trudnym do nauki ale też ma o wiele wiele większe możliwości.
Oczywiście też używają innych wzorców projektowych (Rails - Active
record, Hibernate - Data Mapper).

Myślę, ze gościa poruszyła pewność ludzi od Railsa, ze ich framework
jest tak wielki że ho, ho a to cała drewniana Java idzie w odstawkę.
Brakuje w tym środowisku (Rails) trochę skromności i szacunku dla
większych i starszych. Środowisko Javy docenia powiew nowych pomysłów
i przyspieszyli prace nad połączeniem języków dynamicznych z Javą.
Uznane frameworki takie jak Spring wdrażają u siebie takie pomysły jak
"konwencja nad konfiguracją". Ale wszystko odbywa się raczej po cichu.

A to, że wszystko idzie w stronę ORM'a jest raczej pewne. Pokaż mi
współczesny i sprawdzony frameowk, który nie stawia ORM'a na pierwszym
miejscu. Muszę dodać, ze sam miałem i mam wątpliwości co do wyższości
ORM'a nad nativ SQL'em  (za dużo pythonowwego SQLObejct) ale się
powoli ich pozbywam (SQLAlchemy, ActiveRecord).

--
Climbus
http://blog.netstation.pl/

Dnia 26-05-2007 o 19:59:01 climbus <climbus@gmail.com> napisał(a):

>> Masz na myśli HQL? Wiele osób go krytykuje.
>
> Wiele osób krytykuje Railsa

Więcej go chwali.

> Rozumiem, że łatwiej nauczyć się kilku dialektów SQL'a.

Nie są aż tak różne, a HQL to raczej już inny język.

>> Po drugie, SQL jest znacznie łatwiejszy do testowania i
>> optymalizacji od HQL'a.
>
> W czym jest łatwiejszy do testowania?

W tym, że zwykle bazy relacyjne dostarczają narzędzia do optymalizacji i  
testowania SQL'a. A Hibernate ze swoim HQL jest raczej zamkniętym światem  
sam w sobie.

> Część optymalizacji myślę (akurat nie jestem pewien) robi Hibernate  
> znając specyfikę danego
> dialektu, zna specyfikę silnika.

Musisz polegać na czarnej skrzynce Hibernate. Nie możesz wykonać własnych  
optymalizacji lub byłoby to bardzo trudne, bo nie masz żadnych narzędzi  
wspomagających taki proces.

>> Wiadomo, że pewne optymalizacje są specyficzne dla
>> danego silnika. Tak samo inne cechy. Podałem ci w drugim poście przykład
>> stworzenia pól sortujących się wg reguł języka polskiego i  
>> hiszpańskiego.
>>
>> Jestem ciekaw jak to zaimplementujesz w HQL aby działało też z  
>> PostgreSQL.
>
> Co ma tworzenie tabel z hql?

Jak to co? Zamapuj to w Hibernate jak takiś mądry. Tak aby to było  
"niezależne od silnika bazy"

> W Hibernate jest dodatkowe narzędzie do
> tworzenia tabel ale to jest tylko pomocnik. Mapuje się raczej
> stworzone tabele.

No to zamapuj. Jestem ciekaw jak byś to zrobił aby Hibernate działał  
zarówno z MySQL jak i PostgreSQL.

> Zawsze można znaleźć jakieś konstrukcje lub ficzery, które nie są
> przenośne, lecz nie w tym rzecz.

Ano w tym że padła teza że Hibernate potrafi obejść różnice między  
silnikami baz. Nie ma takiego ORM'a i raczej nie będzie. A jeśli nawet  
ktoś podejmie się mapowania bardziej skomplikowanych struktur to kosztem  
złożoności i w takim wypadku SQL jest po prostu znacznie prostszy. To jest  
ogólny problem wszelkich ORM'ów. Dlatego uważam że ich celem jest  
uprościć i pomóc programiście w pracy a nie kompletnie wyeliminować SQL'a.

> Jeżeli masz projekt, który wiesz na
> jakim silniku będzie chodził i używał elementów danego silnika, które
> nie są dostępne pod innymi silnikami to spokojnie możesz używać native
> sqla. Tylko w takim przypadku gdzie ta moc ROR?

Moc całego ROR to czytelność i prostota. Prostota jaka jest nieosiągalna w  
rozwiązaniach dla Javy. Zresztą jak byś określił JRuby on Rails? To  
projekt javowy czy nie? Generuje bytecode JVM i ma dostęp do wszelkich  
bibliotek Javy. Sam Active Record JDBC korzysta z plików JAR.

> Hibernate daje
> możliwość mapowania poszczególnych zapytać na dowolne obiekty. RoR też
> ma coś podobnego ale dużo bardziej prostego.

Tak, i to jest siła Active Record - prostota. Z pewnością siłą Hibernate  
jest zdolność do pracy z bardziej porąbanymi strukturami legacy databases.  
To samo można powiedzieć o SQLAlchemy. Potrafi lepiej obsługiwać złożone  
struktury, coś za coś. Jest bardziej skomplikowany od Active Record (choć  
nie aż tak jak Hibernate przy Active Record)

> Z tego co mi sie wydaje to iBatis jest starszy niż Hibernate. Więc jak
> czysty SQL jest taki super to poco ludzie tworzyli Hibernate.

Czysty SQL nie każdemu odpowiada. Każdy ORM to tylko obiektowa proteza dla  
SQL'a. Prawdziwe bazy obiektowe nie potrzebują ORM, one pracują natywnie  
obiektowo. Np. ZOPEDB.

> Z drugiej strony jeżeli ActiveRecord jest taki super to poco powstał
> "iBATIS for Ruby"?

Zdaje się że ten projekt jest w fazie embrionalnej. Ale widocznie są tacy  
co wolą podejście czystego SQL. Tak jak i są tacy co wolę framework Nitro  
niż Rails. Kwestia gustu.

Active Record i filozofia RoR znacznie upraszcza pracę z bazą relacyjną.  
Mapowanie obiektowe ma w sumie więcej zalet niż wad. Model tabeli może być  
bogatszy i posiadać cechy nieosiągalne zwykłymi kluczami obcymi. Zobacz  
jak w Active Record rozwiązano walidowanie modelu. Bardzo przejrzyste.

>>> Wg mnie w ActiveRecord za dużo jest native sql'a i trzeba uważać na
>>> konstrukcje aby były zgodne z różnymi dialektami.
>
>> Podaj lepiej jakiś przykład, bo nie wiem co masz na myśli.
>
> Całe "conditions" to zwykły SQL.

Toś chyba nie widział pluginu ez_where. Polecam popatrzeć na
http://brainspl.at/articles/2006/01/30/i-have-been-busy

> Przy bardziej skomplikowanych zapytaniach i warunkach robi się bałagan.

Jak są bardzo skomplikowane to zawsze można użyć czystego SQL'a. Będzie  
pewnie prościej niż obiektowe łamańce składniowe.

> Hibernate ma "criteria"
> które można łatwo dodawać a wszystko jest parsowane pod względem
> typów.

A co typy tu mają do rzeczy?

> A jakie środowisko krzyczało, że jest Java killerem. Że Java umiera.

Kup sobie "Więcej niż Java" Helionu to będziesz wiedział co krytykujesz.  
To teza z tej książki. Oczywiście że RoR jest wybawieniem od pogmatwanych  
javowych rozwiązań w sytuacji średniej klasy złożoności gdzie masz  
stworzyć lekki fronton operujący na relacyjnej bazie danych. Martin Fowler  
i szereg znanych postaci ze świadka javowego nie bez powodu chwalą Rubiego.

> Więc jak Java umiera a Rails nie został zaprojektowany do
> skomplikowanych systemów to co ma być zamiast Javy?

Do bardzo dużych, skomplikowanych, rozproszonych systemów, pewnie długo  
nie będzie konkurencji dla Javy. Ale to nie jest dziedzina w ktorą chce  
wedrzeć się Ruby i Rails. Dlatego myślę, że oba podejścia mogą się  
uzupełniać. Np. znam firmę gdzie duży system pracuje w Javie ale szereg  
powiązanych z nim (mniejszych) projektów ma być w Ruby on Rails.

> A tak na serio. Rails jest prostym frameworkiem do prostych systemów i
> ma prostego i łatwego do nauki ORM'a. Hibernate jest skomplikowanym
> ORM'em, trudnym do nauki ale też ma o wiele wiele większe możliwości.
> Oczywiście też używają innych wzorców projektowych (Rails - Active
> record, Hibernate - Data Mapper).

Tak. Z tym się zgodzę. Myślę też, że Python i SQLAlchemy jest tu gdzieś  
pośrodku.

> Myślę, ze gościa poruszyła pewność ludzi od Railsa, ze ich framework
> jest tak wielki że ho, ho a to cała drewniana Java idzie w odstawkę.
> Brakuje w tym środowisku (Rails) trochę skromności i szacunku dla
> większych i starszych.

Sun lansował kiedyś tezę że Java jest dobra na wszystko. Ta teza nie  
wytrzymała próby czasu. Rewolucje zawsze były dziełem młodych i gniewnych  
więc się nie dziw. :) Java z tymi wszystkimi swymi bibliotekami rozrosła  
się do niebotycznych rozmiarów. Można się tym udławić. Latami można się  
tego uczyć. A większość projektów to nie są projekty wielkiej skali i  
wielkiej złożoności. I tu Ruby i Rails jest jak powiew świeżego powietrza.  
Wykosi Javę z takich projektów to pewne.

> Uznane frameworki takie jak Spring wdrażają u siebie takie pomysły jak
> "konwencja nad konfiguracją". Ale wszystko odbywa się raczej po cichu.

Oni też zostali zarażeni pomyślami jakie wprowadził Rails. :) I dobrze.  
Ale nie wiem czy to coś im pomoże. Sam Spring jest pod obstrzałem nowego  
JEE 5.0, pod obstrzałem krytyki ze strony JBoss czy tak jakoś.

Problemem jest sama składnia Javy. Jest toporna i mało dynamiczna.  
Oczywiście można ją zmieniać i dodawać nowe cechy, ale wtedy sama Java  
przestanie być ze sobą kompatybilna wstecz. Myślę, że to droga do nikąd.  
Trzeba świeżego podejścia.

-- 
Jarosław Zabiełło
http://blog.zabiello.com

On 27 Maj, 00:00, "Jaroslaw Zabiello" <hipertrac...@gmail.com> wrote:
> Dnia 26-05-2007 o 19:59:01 climbus <clim...@gmail.com> napisał(a):
>
> >> Masz na myśli HQL? Wiele osób go krytykuje.
>
> > Wiele osób krytykuje Railsa
>
> Więcej go chwali.

Nie widziałem takiego porównania. Popatrz, że  widzisz to z
perspektywy swojego środowiska.

>
> > Rozumiem, że łatwiej nauczyć się kilku dialektów SQL'a.
>
> Nie są aż tak różne, a HQL to raczej już inny język.
>

Ale bardzo upraszczając,  pisząc w tym języku nie musisz wiedzieć pod
jaka bazą będzie chodziła aplikacja. Przy SQL już musisz.

> W tym, że zwykle bazy relacyjne dostarczają narzędzia do optymalizacji i
> testowania SQL'a. A Hibernate ze swoim HQL jest raczej zamkniętym światem
> sam w sobie.
>

Na końcu masz sql więc możesz go sobie do woli testować a potem masz
pełny wpływ na generowany sql wiec możesz go sobie optymalizować.

> > Część optymalizacji myślę (akurat nie jestem pewien) robi Hibernate
> > znając specyfikę danego
> > dialektu, zna specyfikę silnika.
>
> Musisz polegać na czarnej skrzynce Hibernate. Nie możesz wykonać własnych
> optymalizacji lub byłoby to bardzo trudne, bo nie masz żadnych narzędzi
> wspomagających taki proces.

To nie jest czarna skrzynka, masz wpływ na generowany i uruchamiany
sql i tak samo możesz ten sql optymalizować. Jaka  tu przewaga Railsa?

> Jak to co? Zamapuj to w Hibernate jak takiś mądry. Tak aby to było
> "niezależne od silnika bazy"

Tworzenie tabeli zamapować? Tego się nie mapuje. Jak masz stworzoną
tabelę w mysql to już baza dba o sortowanie i nie rozumiem co ma do
tego hibernate?

> > Zawsze można znaleźć jakieś konstrukcje lub ficzery, które nie są
> > przenośne, lecz nie w tym rzecz.
>
> Ano w tym że padła teza że Hibernate potrafi obejść różnice między
> silnikami baz. Nie ma takiego ORM'a i raczej nie będzie. A jeśli nawet
> ktoś podejmie się mapowania bardziej skomplikowanych struktur to kosztem
> złożoności i w takim wypadku SQL jest po prostu znacznie prostszy. To jest
> ogólny problem wszelkich ORM'ów. Dlatego uważam że ich celem jest
> uprościć i pomóc programiście w pracy a nie kompletnie wyeliminować SQL'a.
>

A kto tu mówi o kompletnym wyeliminowaniu SQL. Hibernate daje więcej
możliwości użycia SQL'a i wpływu na generowany SQL niż Active Record.
Jeżeli masz taką potrzebę masz pełną dowolność.

> Moc całego ROR to czytelność i prostota. Prostota jaka jest nieosiągalna w
> rozwiązaniach dla Javy.

Mówimy o samym orm. Jeżeli wywołujesz czysty sql to róznica będzie
minimalna. Tu i tu sql będzie równie czytelny.

> Zresztą jak byś określił JRuby on Rails? To
> projekt javowy czy nie? Generuje bytecode JVM i ma dostęp do wszelkich
> bibliotek Javy. Sam Active Record JDBC korzysta z plików JAR.

Pomyłka?

> Zdaje się że ten projekt jest w fazie embrionalnej. Ale widocznie są tacy
> co wolą podejście czystego SQL. Tak jak i są tacy co wolę framework Nitro
> niż Rails. Kwestia gustu.

Właśnie. Kwestia gustu.


> Toś chyba nie widział pluginu ez_where. Polecam popatrzeć nahttp://brainspl.at/articles/2006/01/30/i-have-been-busy

Implementacja czegos podobnego co Hibernate ma od początku.

> > Przy bardziej skomplikowanych zapytaniach i warunkach robi się bałagan.
>
> Jak są bardzo skomplikowane to zawsze można użyć czystego SQL'a. Będzie
> pewnie prościej niż obiektowe łamańce składniowe.

I prościej do sql injection

> > Hibernate ma "criteria"
> > które można łatwo dodawać a wszystko jest parsowane pod względem
> > typów.
>
> A co typy tu mają do rzeczy?

To że nie włożysz do sql innego typu niż zakładałeś. np jak ma być int
to będzie tylko int.

>
> > A jakie środowisko krzyczało, że jest Java killerem. Że Java umiera.
>
> Kup sobie "Więcej niż Java" Helionu to będziesz wiedział co krytykujesz.
> To teza z tej książki. Oczywiście że RoR jest wybawieniem od pogmatwanych
> javowych rozwiązań w sytuacji średniej klasy złożoności gdzie masz
> stworzyć lekki fronton operujący na relacyjnej bazie danych. Martin Fowler
> i szereg znanych postaci ze świadka javowego nie bez powodu chwalą Rubiego.

Od dawna java nie jest mocna w tym obszarze. Po prostu nie było
niczego lepszego więc używano na siłę Javę.

> Do bardzo dużych, skomplikowanych, rozproszonych systemów, pewnie długo
> nie będzie konkurencji dla Javy. Ale to nie jest dziedzina w ktorą chce
> wedrzeć się Ruby i Rails. Dlatego myślę, że oba podejścia mogą się
> uzupełniać. Np. znam firmę gdzie duży system pracuje w Javie ale szereg
> powiązanych z nim (mniejszych) projektów ma być w Ruby on Rails.

Często się o tym zapomina. Trzeba o tym mówić, że Rails chce skubnąć
trochę rynku w obszarze małych projektów.

> Sun lansował kiedyś tezę że Java jest dobra na wszystko. Ta teza nie
> wytrzymała próby czasu.

To już dawno jest jasne, że sie pomylił. Teraz trzeba poczekać jak
przyjmie próbę czasu Rails.

> Rewolucje zawsze były dziełem młodych i gniewnych
> więc się nie dziw. :) Java z tymi wszystkimi swymi bibliotekami rozrosła
> się do niebotycznych rozmiarów. Można się tym udławić. Latami można się
> tego uczyć. A większość projektów to nie są projekty wielkiej skali i
> wielkiej złożoności.

Z ta większością bym polemizował. Mniejsze projekty dawno przejął php.

> I tu Ruby i Rails jest jak powiew świeżego powietrza.
> Wykosi Javę z takich projektów to pewne.

Skubnie trochę rynku. I tak sztucznie zajmowanego przez Javę bo oprócz
PHP nie było alternatywy.

> Oni też zostali zarażeni pomyślami jakie wprowadził Rails. :) I dobrze.

Oni od początku szukają dobrych i rewolucyjnych rozwiązań.

> Ale nie wiem czy to coś im pomoże. Sam Spring jest pod obstrzałem nowego
> JEE 5.0, pod obstrzałem krytyki ze strony JBoss czy tak jakoś.

Duża firma atakuje drugą dużą. Nic w tym dziwnego. Na razie się dobrze
bronią.


--
Climbus
http://blog.netstation.pl/

Dnia 27-05-2007 o 07:32:49 climbus <climbus@gmail.com> napisał(a):

> pisząc w tym języku nie musisz wiedzieć pod
> jaka bazą będzie chodziła aplikacja.

No chyba nie za bardzo tak całkiem nie musisz wiedzieć. Jak byś zapisał w  
HQL kwerendę wybierającą rekordy za pomocą xpath? Podawałem przykład dla  
PostgreSQL. Poza tym HQL jest skomplikowany i trudny do nauki.

> Na końcu masz sql więc możesz go sobie do woli testować a potem masz
> pełny wpływ na generowany sql wiec możesz go sobie optymalizować.

No sam widzisz, że testować możesz tylko SQL a nie HQL. Jak taki  
zoptymalizowany SQL chcesz zaaplikować w drugą stronę, do HQL, hę?

>> Musisz polegać na czarnej skrzynce Hibernate. Nie możesz wykonać  
>> własnych optymalizacji lub byłoby to bardzo trudne, bo nie maszżadnych  
>> narzędzi wspomagających taki proces.
>
> To nie jest czarna skrzynka, masz wpływ na generowany i uruchamiany
> sql i tak samo możesz ten sql optymalizować.

I co dalej? Zamiast HQL odpalasz tego SQL, tak?

> Jaka  tu przewaga Railsa?

A co ma framework RoR do tego że język HQL nie można optymalizować?

>> Jak to co? Zamapuj to w Hibernate jak takiś mądry. Tak aby to było
>> "niezależne od silnika bazy"
>
> Tworzenie tabeli zamapować?

Innymi słowy, masz taką strukturę opisaną tym SQL i na tej podstawie masz  
utworzyć tabele w MySQL i PostgreSQL za pomocą Hibernate. Jak byś to  
zrobił?

> A kto tu mówi o kompletnym wyeliminowaniu SQL. Hibernate daje więcej
> możliwości użycia SQL'a i wpływu na generowany SQL niż Active Record.

Ale kosztem znaaaacznie większej złożoności i przy założeniu że nauczyłeś  
się tego skomplikowanefgo HQL'a. To ja już wolę proste podejście Active  
Record + SQL tam gdzie jest coś bardziej zagmatwanego.

> Jeżeli masz taką potrzebę masz pełną dowolność.

Aby ostatecznie uruchomoć SQL bo nie da się inaczej? :) Tak i w Active  
Record zrobisz.

>> Moc całego ROR to czytelność i prostota. Prostota jaka jest  
>> nieosiągalna w rozwiązaniach dla Javy.
>
> Mówimy o samym orm.

To nie pisz RoR ale AR.

> Jeżeli wywołujesz czysty sql to róznica będzie
> minimalna. Tu i tu sql będzie równie czytelny.

Jeśli SQL, owszem. Ale nie mówimy tylko o SQL. Acive Record jest znacznie  
prostszy do opanowania. Z tym się na pewno zgodzisz. Poza złożonością HQL,  
dochodzi do tego złożoność Javy dając w efekcie o wiele bardziej  
skomplikowany i trudny do opanowania twór. Z pewnością znajdą się takie  
sytuacje gdzie ma sens uczenie się takiego molocha ze względu na skalę i  
złożoność projektu. Ale w *większości* sytuacji jest on niepotrzebny,  
wystarczy coś prostszego.

>> Zresztą jak byś określił JRuby on Rails? To
>> projekt javowy czy nie? Generuje bytecode JVM i ma dostęp do wszelkich
>> bibliotek Javy. Sam Active Record JDBC korzysta z plików JAR.
>
> Pomyłka?

Hehe. Powiedz to firmie Sun. Dlaczego pomyłka? Masz pełen dostęp do  
bibliotek i driverów w Javie. A przy okazji o niebo prostszą składnię i  
wygodę do budowania aplikacji webowej. Co tu widzisz niestosownego?

>> Toś chyba nie widział pluginu ez_where. Polecam popatrzeć  
>> nahttp://brainspl.at/articles/2006/01/30/i-have-been-busy
>
> Implementacja czegos podobnego co Hibernate ma od początku.

Nie o tym mowa. Obalam tylko tezę że Active Record wymaga klepania dużo  
nieprzenośnego SQL'a.

>> Jak są bardzo skomplikowane to zawsze można użyć czystego SQL'a. Będzie
>> pewnie prościej niż obiektowe łamańce składniowe.
>
> I prościej do sql injection

Chyba sobie żartujesz. Tylko kompletny pacan wywołuje SQL bez parametrów.

> To że nie włożysz do sql innego typu niż zakładałeś. np jak ma być int
> to będzie tylko int.

I co z tego? Active Record pozwala na znacznie bardziej wyrafinowaną  
kontrolę nad budowanym SQL. Np. nie stworzy ci kwerdendy jak jeden z  
prametrów nie będzie spełniał warunków zadanego wyrażenia regularnego.  
http://www.railsapi.org/activerecord-validations-classmethods-validates_format_of  
Poza tym można narzucić różne warunki walidacyjne oddzielnie na tworzenia  
i oddzielnie dla aktualizacji, czy kasowania, rekordu.

-- 
Jarosław Zabiełło
http://blog.zabiello.com

On 27 Maj, 13:08, "Jaroslaw Zabiello" <hipertrac...@gmail.com> wrote:
> Dnia 27-05-2007 o 07:32:49 climbus <clim...@gmail.com> napisał(a):
>
> > pisząc w tym języku nie musisz wiedzieć pod
> > jaka bazą będzie chodziła aplikacja.
>
> No chyba nie za bardzo tak całkiem nie musisz wiedzieć. Jak byś zapisał w
> HQL kwerendę wybierającą rekordy za pomocą xpath? Podawałem przykład dla
> PostgreSQL.

To jest jedynie skrajny przypadek

> > Na końcu masz sql więc możesz go sobie do woli testować a potem masz
> > pełny wpływ na generowany sql wiec możesz go sobie optymalizować.
>

Chyba się nie rozumiemy.

Hibernate pozwala posługiwać się samymi obiektami. Budować zapytania
na samych konstrukcjach obiektowych i od zastostwanych konstrukcji i
ich kolejności zależy wygenerowany kod sql (masz pełny wpływ na sql).

Pozwala też użyć języka hql, który jest pośrednikiem miedzy SQL a
obiektami. Język jest bardzo podobny do SQL więc też masz wpływ na
SQL.

Możesz też swobodnie używać czystego SQL bez żadnych ograniczeń.

Tak więc masz pełny wybór i w każdym wariancie masz pełną kontrolę nad
wywoływanym SQL'em. W przynajmniej 90% przypadków wystarczy model
obiektowy + hql a w tych paru skrajnych procentach używania funkcji
dostępnych tylko pod jednym silnikiem piszesz w czystym SQL.

>> I co z tego? Active Record pozwala na znacznie bardziej wyrafinowaną kontrolę nad budowanym SQL

Bardziej wyrafinowaną? W porównaniu z czym, hibernate? Podaj przykład.

> Innymi słowy, masz taką strukturę opisaną tym SQL i na tej podstawie masz
> utworzyć tabele w MySQL i PostgreSQL za pomocą Hibernate. Jak byś to
> zrobił?

Jeszcze raz: ZA POMOCĄ HIBERNATE NIE TWORZY SIĘ TABEL. Można to zrobić
oddzielną biblioteką hibernate tools.

> --
> Jarosław Zabiełłohttp://blog.zabiello.com

Dnia 27-05-2007 o 15:15:42 climbus <climbus@gmail.com> napisał(a):

>  W przynajmniej 90% przypadków wystarczy model
> obiektowy + hql a w tych paru skrajnych procentach używania funkcji
> dostępnych tylko pod jednym silnikiem piszesz w czystym SQL.

No to wychodzi prawie na to samo. Hibernate zapewnia tylko szerszą obsługę  
obiektową bez konieczności uciekania się do SQL. Tylko że to jest okupione  
duuuużo większą złożonością tego ORM'a. Coś za coś. Nie widzę tu jakiejś  
szczególnej przewagi Hibernate.

>>> I co z tego? Active Record pozwala na znacznie bardziej wyrafinowaną  
>>> kontrolę nad budowanym SQL
>
> Bardziej wyrafinowaną? W porównaniu z czym, hibernate? Podaj przykład.

W porównaniu do tego coś napisał odnośnie kontroli typów, tzn. Hibernate  
pilnuje czy zmienna jest typu integer. Active Record potrafi daleko więcej  
niż to wynika ze statycznej kontoli typów. Potrafi pilnować aby pole było  
poprawnym emailem, zgodne z wyrażeniem regularnym, typu int, float czy  
string, spełniającym pewien zakres wartości itp. itd. Na tym tle statyczna  
kontrola typów wygląda bladziutko.

>> Innymi słowy, masz taką strukturę opisaną tym SQL i na tej podstawie  
>> masz utworzyć tabele w MySQL i PostgreSQL za pomocą Hibernate. Jak byś  
>> to
>> zrobił?
>
> Jeszcze raz: ZA POMOCĄ HIBERNATE NIE TWORZY SIĘ TABEL. Można to zrobić
> oddzielną biblioteką hibernate tools.

No to zrób. Hibernate czy jego narzędzie. Potrafisz? Bo ja myślę, że nie.  
Musisz użyć SQL'a.

-- 
Jarosław Zabiełło
http://blog.zabiello.com

On 27 Maj, 17:30, "Jaroslaw Zabiello" <hipertrac...@gmail.com> wrote:
> Dnia 27-05-2007 o 15:15:42 climbus <clim...@gmail.com> napisał(a):

> No to wychodzi prawie na to samo. Hibernate zapewnia tylko szerszą obsługę
> obiektową bez konieczności uciekania się do SQL. Tylko że to jest okupione
> duuuużo większą złożonością tego ORM'a. Coś za coś. Nie widzę tu jakiejś
> szczególnej przewagi Hibernate.
>
> >>> I co z tego? Active Record pozwala na znacznie bardziej wyrafinowaną
> >>> kontrolę nad budowanym SQL
>
> > Bardziej wyrafinowaną? W porównaniu z czym, hibernate? Podaj przykład.
>
> W porównaniu do tego coś napisał odnośnie kontroli typów, tzn. Hibernate
> pilnuje czy zmienna jest typu integer. Active Record potrafi daleko więcej
> niż to wynika ze statycznej kontoli typów. Potrafi pilnować aby pole było
> poprawnym emailem, zgodne z wyrażeniem regularnym, typu int, float czy
> string, spełniającym pewien zakres wartości itp. itd. Na tym tle statyczna
> kontrola typów wygląda bladziutko.

Po pierwsze: walidacja w frameworkach typu Spring jest oddzielną
warstwą nie będę tu dywagował nad wadami i zaletami takiego
rozwiązania.
Po drugie: Integer jest tylko przykładem, można sobie zrobić jaki
tylko typ sobie życzysz

> > Jeszcze raz: ZA POMOCĄ HIBERNATE NIE TWORZY SIĘ TABEL. Można to zrobić
> > oddzielną biblioteką hibernate tools.
>
> No to zrób. Hibernate czy jego narzędzie. Potrafisz? Bo ja myślę, że nie.
> Musisz użyć SQL'a.

Oczywiście. Aby zrobić coś co jest specyficzne dla jednego silnika
robię to sql'em. A czym miałbym zrobić, młotkiem?

I co tym udowodniliśmy? Że orm nie może blokować używania czystego
SQL'a. Że Rails jest lepszy do mniejszych projektów, ze javowy
hibernate jest bardziej skomplikowany ale ma większe możliwości od AR.

Cały czas twierdzę, że nie są to platformy odpowiednie do porównań.
Rails mógłby sie chwalić, że wykopie PHP i że zagospodaruje kawałek
rynku sztucznie zajmowanego przez Javę.

Ale Rails twierdzi, że Java umiera. Tylko co ma ja zastąpić na rynku,
na którym ma największy udział?

--
Climbus
http://blog.netstation.pl/

Dnia 27-05-2007 o 16:57:27 climbus <climbus@gmail.com> napisał(a):

> Po pierwsze: walidacja w frameworkach typu Spring jest oddzielną
> warstwą nie będę tu dywagował nad wadami i zaletami takiego
> rozwiązania.

Oddzielną, tzn. gdzie ją schowali? Chyba nie wsadzili walidacji modelu do  
kontrolera?

> Integer jest tylko przykładem, można sobie zrobić jaki
> tylko typ sobie życzysz

Wyrażenie regularne też?

>> > Jeszcze raz: ZA POMOCĄ HIBERNATE NIE TWORZY SIĘ TABEL. Można to zrobić
>> > oddzielną biblioteką hibernate tools.
>>
>> No to zrób. Hibernate czy jego narzędzie. Potrafisz? Bo ja myślę, że  
>> nie. Musisz użyć SQL'a.
>
> Oczywiście. Aby zrobić coś co jest specyficzne dla jednego silnika
> robię to sql'em. A czym miałbym zrobić, młotkiem?

W SQLAlchemy mogłem sobie automatycznie zbudować klasy ORM'a na podstawie  
introspekcji MSSQL i mając model tabel mogłem wygenerować struktury dla  
innych baz, MySQL i PostgreSQL. Innymi słowy mogę bez większego napisać  
system synchronizujący struktury i dane między kompletnie różnymi bazami.  
Z tego co piszesz, to Hibernate raczej by się do tego nie nadał.

> Cały czas twierdzę, że nie są to platformy odpowiednie do porównań.

No to po co ta dyskusja? :)

> Ale Rails twierdzi, że Java umiera.

Coś ci się ubzdurało. Jak Rails może twierdzić cokolwiek? Kto tak  
twierdzi? DHH? Ktoś z core-team'u Railsów?

-- 
Jarosław Zabiełło
http://blog.zabiello.com

> Wyrażenie regularne też?

A jaki to problem gettera dla elementu klasy dać.

> W SQLAlchemy mogłem sobie automatycznie zbudować klasy ORM'a na podstawie
> introspekcji MSSQL i mając model tabel mogłem wygenerować struktury dla
> innych baz, MySQL i PostgreSQL. Innymi słowy mogę bez większego napisać
> system synchronizujący struktury i dane między kompletnie różnymi bazami.
> Z tego co piszesz, to Hibernate raczej by się do tego nie nadał.

Jeżeli używasz orma do migracji danych to twój problem. Nie do tego
służy orm.


> > Cały czas twierdzę, że nie są to platformy odpowiednie do porównań.
>
> No to po co ta dyskusja? :)

Środowisko Rails się domaga porównań.

> > Ale Rails twierdzi, że Java umiera.
>
> Coś ci się ubzdurało. Jak Rails może twierdzić cokolwiek? Kto tak
> twierdzi? DHH? Ktoś z core-team'u Railsów?

Oczywiście chodzi mi o środowisko. Ludzi zafascynowanych Railsem,
którzy po małym projekcie zrobionym w RoR krzyczą, ze Java umiera.

--
Climbus
http://blog.netstation.pl/

climbus wrote:

[...]
>> > Ale Rails twierdzi, że Java umiera.
>>
>> Coś ci się ubzdurało. Jak Rails może twierdzić cokolwiek? Kto tak
>> twierdzi? DHH? Ktoś z core-team'u Railsów?
> 
> Oczywiście chodzi mi o środowisko. Ludzi zafascynowanych Railsem,
> którzy po małym projekcie zrobionym w RoR krzyczą, ze Java umiera.

Zaraz, zaraz - ja tak nie twierdzę ;]

-- 
.:: Piter // phlawski$gmail,com // gg: 4534287 ::.
Chuck Norris jeżdzi lodziarką pokrytą ludzkimi czaszkami.

On 27 Maj, 20:03, "Jaroslaw Zabiello" <hipertrac...@gmail.com> wrote:
> Dnia 27-05-2007 o 16:57:27 climbus <clim...@gmail.com> napisał(a):
>
> > Po pierwsze: walidacja w frameworkach typu Spring jest oddzielną
> > warstwą nie będę tu dywagował nad wadami i zaletami takiego
> > rozwiązania.
>
> Oddzielną, tzn. gdzie ją schowali? Chyba nie wsadzili walidacji modelu do
> kontrolera?

A gdzie w Railsie zwalidujesz logikę biznesową? Też ściśle zwiążesz z
bazą danych?

W springu walidatory są obiektami pomiędzy controlerem a modelem.

Dnia 28-05-2007 o 13:48:44 climbus <climbus@gmail.com> napisał(a):

> A gdzie w Railsie zwalidujesz logikę biznesową? Też ściśle zwiążesz z
> bazą danych?

Skąd! Logiką biznesową zajmują się Kontroler a nie Model. Dane są  
zarządzane przez Model i dlatego reguły spójności tych danych są też  
częścią Modelu.

> W springu walidatory są obiektami pomiędzy controlerem a modelem.

Reguły walidacji powinny być ustawione w Modelu, a nie Kontrolerze.

-- 
Jarosław Zabiełło
http://blog.zabiello.com

Dnia 28-05-2007 o 13:36:02 climbus <climbus@gmail.com> napisał(a):

>> Wyrażenie regularne też?
>
> A jaki to problem gettera dla elementu klasy dać.

Jakiego znowu gettera? Mówimy o regule walidacyjnej a napisałeś że zajmuje  
tym się jakaś inna warstwa poza Modelem...

>> W SQLAlchemy mogłem sobie automatycznie zbudować klasy ORM'a na  
>> podstawie
>> introspekcji MSSQL i mając model tabel mogłem wygenerować struktury dla
>> innych baz, MySQL i PostgreSQL. Innymi słowy mogę bez większego napisać
>> system synchronizujący struktury i dane między kompletnie różnymi  
>> bazami.
>> Z tego co piszesz, to Hibernate raczej by się do tego nie nadał.
>
> Jeżeli używasz orma do migracji danych to twój problem. Nie do tego
> służy orm.

A dlaczego by nie? Skoro ORM dostarcza obiektowe wrappery (rzekomo)  
zasłaniające różnice między bazami, to chyba oczywiste, że jednym z jego  
zastosowń mogłaby być uniwersalna synchronizacja danych między serwerami,  
a na pewno możliwość stworzenia struktury tabel dla innej bazy na  
podstawie ogólnej definicji obiektowej.

A to że Hibernate tego nie potrafi tylko źle o nim świadczy. To całe  
gadanie o niezależności Hibernate od rodzaju bazy jest więc w  
rzeczywistości niewiele warte.

SQLAlchemy bardzo ładnie zasłania różnice między bazami i potrafi  
generować struktury wielu różnych baz na podstawie jednej, obiektowej  
definicji. Active Record potrafi to samo ale w troszkę mniejszym zakresie.  
Nie mój problem że Hibernate jest za cienki. ORM nie służy tylko do  
udawania że pracujesz z obiektową bazą danych.

>> > Cały czas twierdzę, że nie są to platformy odpowiednie do porównań.
>>
>> No to po co ta dyskusja? :)
>
> Środowisko Rails się domaga porównań.

Gdzie i z czym? Na razie to ty się domagasz. :)

>>> Ale Rails twierdzi, że Java umiera.
>>
>> Coś ci się ubzdurało. Jak Rails może twierdzić cokolwiek? Kto tak
>> twierdzi? DHH? Ktoś z core-team'u Railsów?
>
> Oczywiście chodzi mi o środowisko. Ludzi zafascynowanych Railsem,
> którzy po małym projekcie zrobionym w RoR krzyczą, ze Java umiera.

Znasz takich? Choć jednego? Bo ja znam tylko jednego, i to jest javowiec a  
nie railsowiec. :-D

-- 
Jarosław Zabiełło
http://blog.zabiello.com

climbus wrote:

>>> A jakie środowisko krzyczało, że jest Java killerem. Że Java umiera.
>> Kup sobie "Więcej niż Java" Helionu to będziesz wiedział co krytykujesz.
>> To teza z tej książki. Oczywiście że RoR jest wybawieniem od pogmatwanych
>> javowych rozwiązań w sytuacji średniej klasy złożoności gdzie masz
>> stworzyć lekki fronton operujący na relacyjnej bazie danych. Martin Fowler
>> i szereg znanych postaci ze świadka javowego nie bez powodu chwalą Rubiego.
> 
> Od dawna java nie jest mocna w tym obszarze. Po prostu nie było
> niczego lepszego więc używano na siłę Javę.

Hm, mam wrażenie że różne narzędzia oparte o Scheme czy Smalltalka istnieją
od dawna.

>> Do bardzo dużych, skomplikowanych, rozproszonych systemów, pewnie długo
>> nie będzie konkurencji dla Javy.

Erlang ? ;)

>> I tu Ruby i Rails jest jak powiew świeżego powietrza.
>> Wykosi Javę z takich projektów to pewne.
> 
> Skubnie trochę rynku. I tak sztucznie zajmowanego przez Javę bo oprócz
> PHP nie było alternatywy.

Hmm... Perl ? Python ? W perlu sam parę (6 ?) lat temu
napisałem kilka linijek (www). Lisp/Scheme, Smalltalk, Unicon ? ;>

>> Oni też zostali zarażeni pomyślami jakie wprowadził Rails. :) I dobrze.

Wczoraj zabrałem się za książkę o Railsach,
po przeczytaniu pierwszych 250 stron żadnych
rewelacji nie stwierdziłem ;>
Miejscami byłem zawiedziony.

.