Технологии, которые задавят Java

>Пользую Ruby в реальном аналитическом проекте уже год. 
7 девероперов разной квалификации стали писать в течение недели без проблем под Linux+Ruby+FXRuby, до этого у них был опыт Windows + Delphi. 

Отважный у вас руководитель проекта.
Писать большой проект на языке который не позиционируется как язык для написания больши проектов даже теми кто его любит.
Нанять 7 людей, которые до этого не писали на ruby да ещё и под linux. 

>Сейчас размер кодов 2.5M, все тип-топ.
366кб кода в год в среднем писал один программист? ;-)

>Под Java так бы не получилось. 
Да уж, под java такое.... хотя если найти 7 delphi программистов, неделю  учить java, то за год 366кб кода думаю лего напишут ;-)

PS Вот что делает с людьми статья вроде этой.

>>Пользую Ruby в реальном аналитическом проекте уже год. 7 девероперов разной квалификации стали писать в течение недели без проблем под Linux+Ruby+FXRuby, до этого у них был опыт Windows + Delphi.

>Конкретнее, что анализируете?
anonymous (*) (14.11.2005 21:01:14)

Телеметрическая информация, до миллиона отсчетов. MCBC.
Больше ничего сказать не могу :(

------------
>Пользую Ruby в реальном аналитическом проекте уже год.
7 девероперов разной квалификации стали писать в течение недели без проблем под Linux+Ruby+FXRuby, до этого у них был опыт Windows + Delphi.

Отважный у вас руководитель проекта.
Писать большой проект на языке который не позиционируется как язык для написания больши проектов даже теми кто его любит.
Нанять 7 людей, которые до этого не писали на ruby да ещё и под linux.

>Сейчас размер кодов 2.5M, все тип-топ.
366кб кода в год в среднем писал один программист? ;-)

>Под Java так бы не получилось.
Да уж, под java такое.... хотя если найти 7 delphi программистов, неделю учить java, то за год 366кб кода думаю лего напишут ;-)

PS Вот что делает с людьми статья вроде этой.
----------------

Часть кода создана автогенерацией, которую можно применять в runtime.
Да и 1 кб в день это очень хорошая производительность для группы разработчиков. Код на Ruby раза в 3 компактнее Delphi, если не считать UI.

При правильной декомпозиции и организации размеры имеют не первостепенное значение.

Слюшай, вэришь, нет - практически полный аналог Hibernate на Scheme написал за неделю не напрягаясь, всего около 3000 строк кода вышло. Это только на Жабе такие примитивные вещи такими тяжелыми получаются, а когда у тебя в языке есть define-macro, то его даже сравнивать с "плоскими" языками как-то стыдно, подло бить маленьких и слабых...

>Слюшай, вэришь, нет - практически полный аналог Hibernate на Scheme написал за неделю не напрягаясь, всего около 3000 строк кода вышло.

Нет не верю. Может поделишся с народом? ;-)

Недели через две - поделюсь. Скорее всего - в составе siscweb, или как отдельный проект. Пока что это часть коммерческой разработки.

Ну вот, понеслась... =)

За что так эту жабу... Ну в некоторых случаях питон или раби лучше, в системах символьной математики вообще один лисп (maxima и axiom)... И жаба где-то, наверно, удобна, по крайней мере библиотек для нее сейчас огромное количество. Просто ее пытаюца засунуть весде где только можно, вплоть до замены Ады в системах реального времени... Смешно конешно. Еще бы в микроконтроллерах применить попробовали.

>Недели через две - поделюсь. Скорее всего - в составе siscweb, или как отдельный проект.

Я бы тоже взглянул и тоже не верю ;-)

Right outer join с условием умеет делать? Кэш объектов есть? Как с наследованием обстоят дела? С отношениями Many to Many? С репликацией данных из разных источников данных? Lazy initialization? На каких СУБД пробовал?

> Right outer join с условием умеет делать?

Да. Там вообще весьма полный свой собственный SQL получился.

> Кэш объектов есть?

Да.

> Как с наследованием обстоят дела?

Наследованием чего?!? Не догнал.

> С отношениями Many to Many?

Не поддерживается, но добавить - не проблема. Просто не вижу необходимости в этой гадости. Кстати о птичках - one to one тоже считаю гадостью, хоть оно и поддерживается.

> С репликацией данных из разных источников данных?

Без проблем.

> Lazy initialization?

От рождения. Всё, что можно, заворачивается в delay и в continuation-ы.

> На каких СУБД пробовал?

А вот тут, пардоньте, стыдно признаваться... В основной БД, под которую шла разработка, есть тип данных unique_identifier. Я не виноват. Я не хотел!

Выкладывай, потестируем. BTW, siscweb что-то выглядит не вполне живым, пару месяцев уже наблюдаю - в списке рассылки висят неотвеченные вопросы , коммитов в dev не густо, на сайте: "Development branch in state of flux" и т.п. Ты какой веткой пользуешься?

Да у нас своя ветка, от стабильной давно отпочковавшаяся, уже куча изменений, но, как всегда, руки не доходят патч послать...

>MHO Текст программы должен легко читаться.
>Рассмотрим пример:
>
>x1,x2,x3,x4,x5,x6,x7,x8,x9 = 1, 0, 0, 1, 0, 1, 0, 1, 0 ,1
>
>вопрос, чему равно значение x6? Ответ, - надо считать (а за такой >код, мягко говоря, -ругать).
>

Python 2.3.5 (#2, May 4 2005, 08:51:39)
[GCC 3.3.5 (Debian 1:3.3.5-12)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> x1,x2,x3,x4,x5,x6,x7,x8,x9 = 1, 0, 0, 1, 0, 1, 0, 1, 0 ,1
Traceback (most recent call last):
File "<stdin>", line 1, in ?
ValueError: unpack tuple of wrong size

>Ах да, еще есть плагин RDT для Eclipse Тут (в контектсе) гораздо интереснее другой плагин - IDE для RoR http://www.radrails.org/.

>> Right outer join с условием умеет делать? >Да. Там вообще весьма полный свой собственный SQL получился. Молодцы! ORM без нормального языка запросов - просто погремушка.

>> Кэш объектов есть? >Да. А по какому принципу(пам) работает, и какие настройки позволяет?

>> Как с наследованием обстоят дела? >Наследованием чего?!? Не догнал. Есть иерархия классов с одним общим предком. всех надо персистить - вопрос как? есть 3 варианта. 1) Если дети отличаются только реализацией методов - то всех в одну таблицу с полем указывающим какой класс тут лежит. 2) Дети отличаются но не сильно (например парой полей). Тогда выгодней сделать одну общую таблицу под предка, а все новые поля в отдельные таблицы выносить. 3) Все классы в иерархии отличаются очень сильно. Тогда под каждый класс нужно создавать свою таблицу.

>> С отношениями Many to Many? >Не поддерживается, но добавить - не проблема. Просто не вижу необходимости в этой гадости. Есть некие Item которые могут фигурировать в Order причем в каждом Order может быть более чем один Item и один Item может быть более чем в одном Order. В недоделанных ORM для этого приходится создавать промежуточный класс отношение - и делать два отношения 1 к N. В доделанных - это делает за тебя ORM.

>Кстати о птичках - one to one тоже считаю гадостью, хоть оно и поддерживается. Очень знаете зря ;-)

> С репликацией данных из разных источников данных? Без проблем. Из разных источников, это когда из более чем одной БД.

>> Lazy initialization? >От рождения. Всё, что можно, заворачивается в delay и в continuation-ы. А если мне это всегда не нужно? Отключить можно? Если нет, у вас система под реальной нагрузкой может просто встать. То что делается в один запрос - будет делать в N.

>> На каких СУБД пробовал? >А вот тут, пардоньте, стыдно признаваться... В основной БД, под которую шла разработка, есть тип данных unique_identifier. Я не виноват. Я не хотел! Грустно. А диалект другой субд можно прикрутить (если написать)?

Никто не задавит жабу - всем лень пачкаться :) Жабу пропихивают во все щели, лишь бы хоть кто-то ею занимался. Весомых резонов её использовать нет, окромя "шеф платит - я делаю". Поэтому она будет ещё долго трепыхаться, пока SUN не поймёт, что последние 10 лет выкидывала деньги на помойку.

Динамические языки - да, это очень интересно, но как таковая динамика не очень сильно востребована. Калькулятор с четырьмя операциями бессмысленно делать с плагинами функций - проще добавить новые и перекомпилять, СОХРАНЯЯ ПРЕЖНЮЮ СТАБИЛЬНОСТЬ И СКОРОСТЬ.

Язык "D" рулит! :)

> Весомых резонов её использовать нет, окромя "шеф платит - я делаю". Поэтому она будет ещё долго трепыхаться, пока SUN не поймёт, что последние 10 лет выкидывала деньги на помойку.

Хорошо сказано! Бимеры тоже с VAST выкидывали деньги на ветер. 12.31.2005 можно панихиду заказывать.:)

Впрочем, учитывая, что большинство юзверей сидит на офтопике и, как стая леммингов, пойдет на Vista, то благодаря Aero Swing просто сдохнет. А дальше и Жаба будет как Ленин - не жив и не хоронят.

И чем же это Aero задавит Swing? Гы. или просто перегрелся/перечитал Microsoft бюллютеней?

Поставьте офтоп, Жабу и посмотрите сами. Мне лично не интересна ни Vista, ни Жаба. Мне фиолетовы дела как M$, так и сантехников. Я занимаюсь OSS.

А Perl, Perl почему никто не вспоминает? Переносимый, мультиплатформенный язык с богатыми возможностями. Задолго до жабы уже все ее прелести были реализованы.

Многие думают, что большие проекты нельзя делать на Perl, но разруха она не в языке программирования, а в головах. Perl позволяет писать очень структурный, модульный и красивый код. В языке есть все средства для этого и их просто применять. Но он не запрещает идиотам писать по-идиотски.

Кстати, Perl и достаточно быстрый, если правильно его применять.

А Perl, Perl почему никто не вспоминает? Переносимый, мультиплатформенный язык с богатыми возможностями. Задолго до жабы уже все ее прелести были реализованы.

Многие думают, что большие проекты нельзя делать на Perl, но разруха она не в языке программирования, а в головах. Perl позволяет писать очень структурный, модульный и красивый код. В языке есть все средства для этого и их просто применять. Но он не запрещает идиотам писать по-идиотски.

Кстати, Perl и достаточно быстрый, если правильно его применять.

А Perl, Perl почему никто не вспоминает? Переносимый, мультиплатформенный язык с богатыми возможностями. Задолго до жабы уже все ее прелести были реализованы.

Многие думают, что большие проекты нельзя делать на Perl, но разруха она не в языке программирования, а в головах. Perl позволяет писать очень структурный, модульный и красивый код. В языке есть все средства для этого и их просто применять. Но он не запрещает идиотам писать по-идиотски.

Кстати, Perl и достаточно быстрый, если правильно его применять.

>А Perl, Perl почему никто не вспоминает? Переносимый, мультиплатформенный язык с богатыми возможностями. Задолго до жабы уже все ее прелести были реализованы.

Чего мне не хватает в perl:
Приличного ORM
Приличного RPC
Приличной библиотеки для создания UI
Приличной производительности
Приличного IDE
Объектно-ориентированным он стал совсем недавно, и большинство по написано по прежнему без применения ООП по этому избыточность кода порой просто пугает.

Perl неплох как Practical Extraction and Report Language &#8211; кесарю кесарево.

Отличный перевод, в стиле ЛОР. Если, по-вашему, "may challenge" - это "задавят" или "могут пошатнуть", то мое вам почтение.

Я не перловщик, но все же...

> Приличной библиотеки для создания UI

Чем не устраивает Perl-GNOME2?

> Приличного IDE

ActiveState Komodo?

> Perl неплох как Practical Extraction and Report Language
> кесарю кесарево.

Я бы сказал, перл неплох там, где вышеперечисленные фичи не нужны, и
где в CPAN есть соответствующий пакадж под задачу =)

>Я бы сказал, перл неплох там, где вышеперечисленные фичи не нужны, и где в CPAN есть соответствующий пакадж под задачу =)

Ну, наконец-то! Вот за это джаву и любят :)

А всякие языковые изыски не более чем бонус, так как основное внимание разработчика приковано к application domain и ее заморочкам, а не к тому, как это выразить на языке программирования.

> А всякие языковые изыски не более чем бонус, так как основное
> внимание разработчика приковано к application domain и ее заморочкам,
> а не к тому, как это выразить на языке программирования.

Просто многие domains намного удобней выражаются именно с применением
тех самых "языковых изысков". О чем обычно и идет речь.

>Я не перловщик, но все же...
>> Приличной библиотеки для создания UI
>Чем не устраивает Perl-GNOME2?
Перносимость (автор говорил о perl как о переносимом, ультиплатформенном языке) и тормознутость(кто тут пинал Swing? ;-) ) низкая функциональность (до JFace как до луны).


>> Приличного IDE
>ActiveState Komodo?
Refactoring? Subversion поддержка там без году неделя.
(ты кажется Eclipse ругал за скорость? как тебе Komodo?)


>> Perl неплох как Practical Extraction and Report Language
>> кесарю кесарево.

>Я бы сказал, перл неплох там, где вышеперечисленные фичи не нужны

Написание продвинутых shell скриптов - ДА!

> >Чем не устраивает Perl-GNOME2?
> Перносимость (автор говорил о perl как о переносимом,
> ультиплатформенном языке)

А что, ее нет? Да, оно выглядит кривовато под виндой. Ну дык Swing
выглядит криво вообще везде =)

> и тормознутость(кто тут пинал Swing? ;-) )

Я пинал. Gtk-софт _намного_ быстрей, в т.ч. и тот, который написан на
Perl/Python/Ruby.

> Refactoring? Subversion поддержка там без году неделя.

Не в курсе, если честно. Я же сказал, не перловщик =)
Просто вспомнилась такая вещь.

> (ты кажется Eclipse ругал за скорость? как тебе Komodo?)

Когда я его в последний раз видел, оно тормозило изрядно, да.

Хотя все рекорды побила Zend Studio, не помню какой версии (давно дело
было). На Java+Swing. Какой там Eclipse...

> Написание продвинутых shell скриптов - ДА!

Я бы сказал - написание большей части десктопного софта, которым я (и,
уверен, вы тоже) пользуюсь. Хотя питон для этого и лучше.

На сколько я представляю, сейчас вообще наблюдается сдвиг в DSL. Разнообразные кодогенераторы, декларативное программирование, информационная интеграция, грануляризация и всё такое. На долю, собсно, языка программирования здесь приходится 1%.

Java - мир очень прагматичен. Если какая-то фича действительно необходима, она появится и будет представлять из себя общее среднее между интересами активных участников рынка.

По сабжу: JSR 241: The Groovy Programming Language

Groovy is an agile, dynamic programming language for the Java Virtual Machine. Groovy includes features found in Python, Ruby, and Smalltalk, but uses syntax similar to the Java programming language.

Так что всё не так уж плохо в нашем королевстве ... :)

> На сколько я представляю, сейчас вообще наблюдается сдвиг в DSL.
> Разнообразные кодогенераторы, декларативное программирование,
> информационная интеграция, грануляризация и всё такое. На долю,
> собсно, языка программирования здесь приходится 1%.

Неправда ваша. В Java-мире, действительно так - но по-хорошему DSL надо
интегрировать с собственно языком (см. Lisp, Nemerle, да даже те же
динамические языки типа Ruby). А в Java это именно костыли - правильно
вы отметили кодогенераторы...

> Java - мир очень прагматичен. Если какая-то фича действительно
> необходима, она появится и будет представлять из себя общее среднее
> между интересами активных участников рынка.

Не прагматичен, а консервативен. Это не одно и то же. Фичи появляются,
но очень медленно и со скрипом. Напомнить, сколько Sun отбивалась от
тех же enum'ов, утверждая, что они "не объектно-ориентированны"? Или вы
хотите сказать, что они, да и дженерики, стали нужны только к выходу
1.5? ;)

>but uses syntax similar to the Java programming language.

>Так что всё не так уж плохо в нашем королевстве ... :)

Дык это... Синтаксис у нее тоже не ахти...:-)

>А что, ее нет? Да, оно выглядит кривовато под виндой. Ну дык Swing
выглядит криво вообще везде =)
А SWT сможешь отличить на windows/linux от натива?

>> и тормознутость(кто тут пинал Swing? ;-) )
>Я пинал. Gtk-софт _намного_ быстрей, в т.ч. и тот, который написан на
Perl/Python/Ruby.
Сравни с SWT. (я Swing долго сам не жаловал, хотя последний Swing практически догнал SWT (это даже сами SWT'овцы признают))
Как может более медленный язык(ruby,perl,python) + Gtk binding давать большую производительность чем более быстрый язык(java) + Gtk binding?

>Хотя все рекорды побила Zend Studio, не помню какой версии (давно дело
было). На Java+Swing. Какой там Eclipse...
Ключевое слово - _давно_.
Сейчас Swing стал почти таким же шустрым как SWT.


>Я бы сказал - написание большей части десктопного софта, которым я (и, уверен, вы тоже) пользуюсь. Хотя питон для этого и лучше.

А что у тебя за софт стоит?
Eclipse,Azureus,RSSOwl,OpenOffice,Firefox,Thunderbird/Evolution,QNEXT/GAIM/PSI - что из этого ты бы предложил написать на perl и зачем?!

> Не догнал. Есть иерархия классов с одним общим предком. всех надо персистить - вопрос как?

Нет иерархии классов. Это ж Схема, какие там на фиг классы (они там и не нужны никому). Отображается всё, на выбор, либо в функционально заданный граф (семантически, в общем-то, классы и есть - через замыкания реализованные) - типа, scheme way, либо - но только для деревьев без зацикливания - в ленивый SXML.

> В недоделанных ORM для этого приходится создавать промежуточный класс отношение - и делать два отношения 1 к N. В доделанных - это делает за тебя ORM.

Не вижу проблемы в наличии дополнительного узла графа. Это ж Схема, тут обработка графовых структур - легка и приятна, никаких там тебе классов описывать не надо, всё динамически генерится. Да и классов, собственно, нет. Поскольку возможности и методики этого языка сильно отличны от того, что есть в Java, то и ORM не должен и не может полностью повторять те ORM, которые есть для Java. Более гибкому языку костыли не нужны. :)

> Из разных источников, это когда из более чем одной БД.

Угу. Я так и понял. БД сколько угодно, с перекрёстными ссылками между ними.

> А если мне это всегда не нужно? Отключить можно?

Можно. Но не нужно.

> То что делается в один запрос - будет делать в N.

Это никак не связано с ленивостью. Запросы оптимизируются.

> Грустно. А диалект другой субд можно прикрутить (если написать)?

Ну, Postgres тоже работает, например. Новые БД прикручиваются легко (тем более что в основном оно под SISC разрабатывалось, так что пользуюсь просто JDBC). Фичи, специфичные для SQL Server можно просто не использовать, достаточно прописать таблицу для преобразования типов данных и таблицу функций, поддерживаемых в SQL. BLOB-ов нет и не надо.

Да, действительно. Излишне консервативен. А своеобразная религиозность идеологов Java создает плодородную почву для насмешек и является предметом объективной критики. На мой взгляд, если что и может сослужить очень плохую службу SUN (но не Java), так это игнорирование пожеланий разработчиков. Так как именно они, в конечном итоге, определяют всё.

Однако, мы не так завязаны на SUN, как это пытаются показать. Если я хочу использовать язык 'A' и его интерпретатор/компилятор уже кто-то написал, я его буду использовать, не спрашивая разрешения у SUN. И, используя Groovy, я не чувствую себя в худшем пложении, чем программисты на Ruby. А java-подобный синтаксис является очень приятным бонусом. Java предлагает очень богатый набор качесвенных решений, имеющих усойчивую поддержку со стороны community и именно это держит меня на данной _платформе_, тогда как в выборе языка я досточно свободен.

> Дык это... Синтаксис у нее тоже не ахти...:-)

Это дело вкуса :-)

> Отображается всё, на выбор, либо в функционально заданный граф
> (семантически, в общем-то, классы и есть - через замыкания
> реализованные)

С этого места можно поподробней, или хотя бы ссылок накидать? Что из
себя представляют "семантически ... классы - через замыкания
реализованные", и как выглядит процесс подобной их реализации?

> Однако, мы не так завязаны на SUN, как это пытаются показать. Если я
> хочу использовать язык 'A' и его интерпретатор/компилятор уже кто-то
> написал, я его буду использовать, не спрашивая разрешения у SUN. И,
> используя Groovy, я не чувствую себя в худшем пложении, чем
> программисты на Ruby. А java-подобный синтаксис является очень
> приятным бонусом. Java предлагает очень богатый набор качесвенных
> решений, имеющих усойчивую поддержку со стороны community и именно
> это держит меня на данной _платформе_, тогда как в выборе языка я
> досточно свободен.

На Groovy я еще посмотрю, спасибо. Все равно, сколько я ни ругай эту
платформу, но писать под нее мне все равно придется - так озаботимся
же приобретением костылей заранее! ;)

А в чем бонус Java-подобного синтаксиса, кстати? Чем он для таких задач
лучше, например, Smalltalk (по синтаксису - имхо, один из языков,
приближенных к идеалу)? Если только привычка - это не достоинство.

BTW, в java 6 Mustang *уже* запихнули Rhino, реализацию ecmascript от Mozilla

> А SWT сможешь отличить на windows/linux от натива?

Визуально - нет (в отличие от wxWidgets, кстати, который хоть на это и
претендует, но ожиданий не оправдывает). Однако же SWT в конечном счете
суть надстройка над тем же Gtk (в линухе, где оно только меня как
end-user'а и интересует), а потому быстрей быть не может по
определению. Что характерно, она "на глазок" заметно медленней. Хотя
по сравнению с Swing это, конечно, очень большой прогресс. Во всяком
случае, Eclipse и Azureus вполне можно пользоваться, что я успешно и
делаю =)

Кстати, Azureus, как запустится, работает неотличимо от нативной
проги, но вот грузится (не VM, а именно сам Azureus - он прогрессбар
рисует в процессе) что-то уж больно долго.

> Сравни с SWT. (я Swing долго сам не жаловал, хотя последний Swing
> практически догнал SWT (это даже сами SWT'овцы признают))

Догнал ли? Под виндой не - знаю, может быть. Там вроде и JVM побыстрей
работает =) в линухе все еще тормоза, к сожалению. Заметные. На JDK 1.5.

> Как может более медленный язык(ruby,perl,python) + Gtk binding давать
> большую производительность чем более быстрый язык(java) + Gtk binding?

Дык, SWT - это не биндинг, а именно надстройка. Т.е. там и своего кода
немало, тот же layout management. А вот PyGTK, cкажем - это именно
биндинг.

> >Я бы сказал - написание большей части десктопного софта, которым я
> >(и, уверен, вы тоже) пользуюсь. Хотя питон для этого и лучше.
>
> А что у тебя за софт стоит?
> Eclipse,Azureus,RSSOwl,OpenOffice,Firefox,Thunderbird/Evolution,QNEXT/GAIM/PSI
> - что из этого ты бы предложил написать на perl и зачем?!

Я бы все же писал на питоне, но это не принципиально, можно и на перле,
разница невелика =)

Из вышеперечисленного - как минимум Evolution. Для Mozilla (и, как
следствие, Firefox/Thunderbird) тоже подошел бы куда лучше, чем JS, а
движок для скорости оставить на плюсах. Мой софт? Пожалуйста: Sylpheed,
X-Chat, aMule, gThumb, Quod Libet, OrnamentBook - это навскидку с
лончбара. Кстати, два последних из списка и написаны на питоне, и не
могу сказать, что это хоть как-то заметно.

Вообще же имхо для практически любого нераспределенного десктопного
приложения, не завязанного на БД, Java - это overkill. Просто потому,
что вот как раз с этим тот же питон справляется идеально, и делать это
на нем намного проще, приятней и быстрей.

>А в чем бонус Java-подобного синтаксиса, кстати?

Мне приходится много думать над application domain, такие у нас задачи. И это отнимает львиную долю когнитивных ресурсов. Java-подобный синтаксис означает, что я могу использовать уже имеющийся skillset и не тратить время на изучение нового синтаксиса. Мелочь, если честно, но всё равно приятно. Я ведь получаю fun, зарплату и пробие бонусы не за крастоту и изящество кода, а за работоспособность моего продукта. А реализовать невостребованный творческий потенциал можно и в каком-нить OSS-проекте.

Звучит очень здорово, но скажи пожалуйста, это точно будет в siscweb? А то я сейчас собираюсь писать что-то похожее - а мог бы помочь вам, потестировать на Oracle например.

> Звучит очень здорово, но скажи пожалуйста, это точно будет в siscweb?

Вряд ли оно там будет полностью, только некоторые компоненты. Я всё же хочу это сделать более портабельным, SISC всё ж не самая быстрая Схема.

> А то я сейчас собираюсь писать что-то похожее - а мог бы помочь вам, потестировать на Oracle например.

Было бы круто. Как я уже сказал, недели через две смогу выложить то, что будет сочтено достойным публикации. Контора весьма щепетильна по поводу качества и красоты публикуемого Open Source. :)

Почему ж не вспоминаем Perl? Вспоминаем! Добрым, тихим словом. :) И я бы хоть сейчас писал всё на нём, но проблемы у него действительно есть - как популяризационные, так и технические.

1. Пугающий новичков синтаксис. Как таковой, он не сложен и программер со стажем быстро его освоит. НО! Программируют не только профи, поэтому априорно Перл боятся => стараются не использовать.

2. Отсутствие как ГУЯ, так и удобной среды для его создания. Никому нах... не нужен ваш ГыТыка-Кьют, если интерфейс приходится делать через зад. Komodo, как вы понимаете, здесь не спасает, "внешние" дизайнеры сосут.

3. Слабый коммерческий интерес, вытекающий из предыдущих пунктов и архаичная природа OSS мешают расширять Perl модулями для поддержки серьёзных коммерческих продуктов. Скажем, нафига какой-нть фирме делать модуль для кодировки mp3 под Perl? Или коннектор к MS SQL 2005... Как результат, Perl остаётся обвешанным всякими перделками, а широкого использования в серьёзных продуктах не получает.

А как мощный, высокоуровневый язык он подходит для ааагромной кучи софта, так что не всё ещё потеряно.

Предварительное замечание 1:

Я пишу код от случая к случаю, иногда бывают перерывы до нескольких месяцев. В основном это автоматизация прикладных задач, для которых нет устраивающего готового софта, или средства интеграции существующих приложений.

Предварительное замечание 2:

Считаю, что писать прикладной код лучше тем, кто понимает собственно прикладную область, чем тем, кто умеет только хорошо писать код. Коддинг - в массы!

Предварительное замечание 3:

Писал (в том числе и достаточно большие проекты) на Fortran, Pascal, assembler, C/C++, Perl, Java, PHP, Ruby и нескольких специализированных языках.

Почему Ruby для меня привлекательней Java:

1. Более стройный синтаксис с меньшим количеством "навесных" механизмов. Легче "входить" в коддинг после перерывов по сравнению с Java.

2. Очень большой набор функциональности реализуется на уровне конструкций языка (у Java - библиотеки). Меньшая зависимость от внешних библиотек.

3. Более емкие и краткие языковые конструкции.

4. Более "читабельный" код.

5. Меньшие затраты на разработку классов.

6. Большая толлерантность к ошибкам в проектировании классов.

7. Возможность динамически изменять свойсва и методы часто спасают при расширении функциональности объектов в процессе жизни кода.

8. Отсутствие строгой типизации объектов упрощает разработку и, как не странно, уменьшает количество ошибок (по крайней мере у меня).

9. Динамическое порождение кода (а-la eval) существенно упрощает жизнь в некоторых случаях.

10. Иттераторы позволяют многие задачи решать существенно проще. В некоторых случаях - просто меняют взгляд на структуру кода.

Чего не хватает в Ruby по сравнению с Java:

1. Хорошего и полноценного IDE (например, пользуемый мной eclipse пока не дотягивает с поддержкой Ruby до Java).

2. Большого набора готовых решений и компонент, как в Java.

3. Библиотек маловато.

4. Почти невозможно работать с низкоуровневыми устройствами и библиотеками (впрочем Ruby в эту сферу и не позиционируется).

5. Литературы хотелось бы побольше.

6. Хотелось бы иметь вариант с прекомпилированным и хранимым байт-кодом.

7. Community маловато.

8. Скорости выполнения.

9. Хотелось бы иметь поддержку диалекта языка в виде скриптов для браузеров (мечта почти несбыточная).

Каждому своё, но последние года два кроме Ruby почти ничего не пользую (разве С иногда или правка чужого кода).

Думаю, что со временем (годиков через 3-5), если не сам Ruby, то нечто на него очень похожее станет достаточно массовым (Python на эту роль не предлагать!!!).

Массам нужен очень простой язык, желательно с возможностью декларативной графической нотации в виде диаграмм. Плюс к этому -- развитую компонентную платформу, предоставляющую решения на все случаи жизни в своем application domain. ВыжуалБэйсик рулит.

Только, пожалуйста, не надо считать этих людей быдлом. Среди них много настоящих Специалистов в своей области, вот только их стиль мышления далек от последовательностно-процедурной парадигмы современных языков программирования. Прикладник согласиться писать на том языке, на котором он думает.

Извиняюсь, если не по адресу :)

> ВыжуалБэйсик рулит.

Сосёт. Потому как ни разу не является простым языком, не имеет "декларативной графической нотации", и не предоставляет развитую компонентную платформу. То, что M$ гонит, что VB якобы всё это имеет - оставим на их чёрненькой совести.

> вот только их стиль мышления далек от последовательностно-процедурной парадигмы современных языков программирования

И потому VB ни разу не для них. Как и Java...

> Прикладник согласиться писать на том языке, на котором он думает.

Как будто все другие должны поступать иначе.

У меня 2 года опыта разработки фронтэндов к БД на VB. В 1999-2000, когда современная джава только начиналась, ВБ уже всё что надо умел. И умел неплохо. Другое дело, что "шаг в сторону - расстрел на месте", но мало кто хотел этот шаг совершать. Из VB было доступно всё: базы данных, все средства оффиса, куча сторонних компонентов, ДиректИкс для любителей, а автокомплит позволял интроспектировать библиотеки типов прямо in place во время написания кода. И в то же время юзание всех этих прелестей из Delphi было более затруднительным -- требовалось геренить обертки для КОМ-типов и потом отлавливать глюки при падении офиса. Ох, сколько народа вокруг пИсало кипятком тогда от этих фич, ощущая себя разработчиком приложений уровня предприятия.

МС, кста, так и позиционировала ВБ - как язык для "склейки" компонентов в приложение, а для разработки самих компонентов предлапгался VC, который вызывал у VB-разработчиков сложные чувства что-то между страхом и благоговением: "На VC можно написать Что Угодно, но это удел Избранных". Но, поскольку пользоваться VC могли только единицы, написать что-то большое на VB было весьма проблематично.

> Не догнал. Есть иерархия классов с одним общим предком. всех надо персистить - вопрос как?

Какая разница как называть. У тебя есть некая структура с дестью полями и такаяже + одно поле. Как будешь сохранять их в БД?

>> В недоделанных ORM для этого приходится создавать промежуточный класс отношение - и делать два отношения 1 к N. В доделанных - это делает за тебя ORM.

>Не вижу проблемы в наличии дополнительного узла графа. Это ж Схема, тут обработка графовых структур - легка и приятна, никаких там тебе классов описывать не надо, всё динамически генерится. Да и классов, собственно, нет. Поскольку возможности и методики этого языка сильно отличны от того, что есть в Java, то и ORM не должен и не может полностью повторять те ORM, которые есть для Java. Более гибкому языку костыли не нужны. :)

Дык твой лишний узел и есть костыль ;-) В Hibernate это делается без него.

>> Из разных источников, это когда из более чем одной БД.

>Угу. Я так и понял. БД сколько угодно, с перекрёстными ссылками между ними.

Хорошо. Если правда ;-)

> А если мне это всегда не нужно? Отключить можно? > То что делается в один запрос - будет делать в N. >Можно. Но не нужно. Это никак не связано с ленивостью. Запросы оптимизируются.

Lazy initialization - дергает подгрузку поля только когда дергается значение поля. Так что если ты я вынул объект с N полями и по одному начал с ними работать, будет N запросов.

>> Грустно. А диалект другой субд можно прикрутить (если написать)?

>Ну, Postgres тоже работает, например. Слоны идут на ...й, Штирлиц живет этажем выше.

>BLOB-ов нет и не надо.

Во что ты складываешь большие массивы бинарных данных? ;-)

На самом деле ORM сейчас - не проблема. Еще совсем недавно под .Net их не было, а теперь вагон и маленькая тележка. Если сейчас кто-то захочет переписать Hibernate заново, выкинув "ненужную" функциональность, то получит модульный, компактный и достаточно шустрый тулкит. Технология-то отработана и разработчик сейчас достаточно точно знает, что он должен получить в результате, что ему надо, а что - нет.

Легко писать тулкит "под себя", когда точно знаешь, что тебе понадобится, а что - нет. И совсем другое дело - писать такую вещь, которая будет полезна многим.