языки программирования

[crypto5]

Ну да, я же написал, эволюционный подход, слабые уходят, сильные остаются впитав сильные стороны слабых.

Они остаются абсолютно такими же. А цель каждого второго фреймворка - засунуть динмические типы в Жабу (если смотреть на все это с большой высоты).
Для примера, что в Spring MVC надо описывать в конфигурации и описывать в схеме базы ручкмми, в Rails делается одним db migrate.

вы я вижу великий специалист еще и в spring mvc. На самом деле оно конечно же о базе совсем ничего не знает. Spring это интеграционный конструктор, где компоненты абстрагированы от друга, и что вы к spring mvc прикрутите так оно и будет работать.
Если хочется все из коробки и convention over configuration смотрите grails и play.

Модель замечательно описывается самим языком.

А в джаве/спринге/хибернейте модель с каких то пор нельзя описать языком?

Амазон и ибей как раз начинались на другихплатформах, perl, c++, asp а потом уже переползли на джаву.

Ну замечательно. Когда им надо было развивать, писали значит на Perl и C++. А когда рынок завоевали, и умные люди ушли, стали тупых на Жабу сажать.
А серьезно, я уже по-моему раскрыл исторический контекст. В 2000-х Жабе особых конкурентов не было. Да и сейчас, как я писал выше, в болоте Жаба - safe choice. Ну и фиг с ним.

Извините, я такую ерундистику на веру не принимаю.

[crypto5]

IMHO Java завоевала популярность тем, что была целостной (no DLL nightmare, etc.) переносимой системой с объектной ориентацией, автоматическим управлением памятью и JavaDoc.

Ну да, променяли DLL hell на JAR hell.

Кстати не расскажете в чем он заключается? А то я вообще не вкурсе какие у меня джарники в проекте. Описал top level зависимости в maven, ivy, gradle и оно все само automagically самоорганизовалось.

[Интеррапт]

Кстати не расскажете в чем он заключается? А то я вообще не вкурсе какие у меня джарники в проекте. Описал top level зависимости в maven, ivy, gradle и оно все само automagically самоорганизовалось.

И никогда на dependency conflict не натыкались?

[crypto5]

Кстати не расскажете в чем он заключается? А то я вообще не вкурсе какие у меня джарники в проекте. Описал top level зависимости в maven, ivy, gradle и оно все само automagically самоорганизовалось.

И никогда на dependency conflict не натыкались?

Неа..

[mudi]

а C++ уже и не язык совсем?

"Совсем" язык. Просто он редко используется под web. И трудно его сравнить скажем с Ruby

А где в вопросе/опросе упоминался web?

[Интеррапт]

Кстати не расскажете в чем он заключается? А то я вообще не вкурсе какие у меня джарники в проекте. Описал top level зависимости в maven, ivy, gradle и оно все само automagically самоорганизовалось.

И никогда на dependency conflict не натыкались?

Неа..

Везет же. А я как сейчас помню всякие spring/hibernate/asm конфликты, которые выливались в мучения (еще не так много лет назад). Да и сейчас иной раз бяки случаются. Конечно нынче почти все можно починить при помощи exclusions.

[crypto5]

Кстати не расскажете в чем он заключается? А то я вообще не вкурсе какие у меня джарники в проекте. Описал top level зависимости в maven, ivy, gradle и оно все само automagically самоорганизовалось.

И никогда на dependency conflict не натыкались?

Неа..

Везет же. А я как сейчас помню всякие spring/hibernate/asm конфликты, которые выливались в мучения (еще не так много лет назад). Да и сейчас иной раз бяки случаются. Конечно нынче почти все можно починить при помощи exclusions.

Hibernate & spring помоему уже хорошо вылизаны от таких проблем.

[Интеррапт]

Hibernate & spring помоему уже хорошо вылизаны от таких проблем.

Уже да. Но случается иной раз с другими фреймворками. Просто удивило, что ни разу не сталкивались с такими проблемами.

[crypto5]

Hibernate & spring помоему уже хорошо вылизаны от таких проблем.

Уже да. Но случается иной раз с другими фреймворками. Просто удивило, что ни разу не сталкивались с такими проблемами.

Может быть. Но как можно сделать лучше?

[Интеррапт]

Hibernate & spring помоему уже хорошо вылизаны от таких проблем.

Уже да. Но случается иной раз с другими фреймворками. Просто удивило, что ни разу не сталкивались с такими проблемами.

Может быть. Но как можно сделать лучше?

Не вижу как. По большому счету - меня все устраивает. Конфликты всегда удается разруливать.

[dotcom]

Кстати не расскажете в чем он заключается? А то я вообще не вкурсе какие у меня джарники в проекте. Описал top level зависимости в maven, ivy, gradle и оно все само automagically самоорганизовалось.

На своем собственном проекте налететь на проблемы с dependencies - проблема разработчика. Разговор шел про DLL/JAR hell и конкретную проблему deployment'а модулей у кого-то еще. У себя на жестком диске каждый сам творец своего hell. Поэтому десктопные приложения на Жабе распространяются со всем комплектом барахла конкретной версии. Хотя вру. Все барахло идет в комплекте, потому что у клиента не факт, что есть вобще какие-то JAR'ы. Да, ну и с слову, dependency manager'ы в Жабе - это наше все. Еще один productivity tool, которого так все ждали в 95-м году.

[dotcom]

вы я вижу великий специалист еще и в spring mvc.

Нет, я не специалист в Spring'е, о чем и писал выше. Мне в отличие от вас нужны не детали, а результат и эффективность процесса.

На самом деле оно конечно же о базе совсем ничего не знает. Spring это интеграционный конструктор, где компоненты абстрагированы от друга, и что вы к spring mvc прикрутите так оно и будет работать.

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

Если хочется все из коробки и convention over configuration смотрите grails и play.

Grails - согласен, гут, потому как экономит время.

Извините, я такую ерундистику на веру не принимаю.

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

[crypto5]

вы я вижу великий специалист еще и в spring mvc.

Мне в отличие от вас нужны не детали, а результат и эффективность процесса.

Спасибо за еще один навешеный ярлык.

На самом деле оно конечно же о базе совсем ничего не знает. Spring это интеграционный конструктор, где компоненты абстрагированы от друга, и что вы к spring mvc прикрутите так оно и будет работать.

Так на фига конструктор-посредник, который требует массу времени на изучение, настройку, отладку,

Во первых в спринге есть тоже всякие способы бустстрапинга проектов в виде архетипов мавена, тимплейтов и визардов в spring tools suite. Во вторых это сильно зависит от задачи, кому то нужно делать мелкие проекты и тогда RoR подход Ок, а кому то сложные проекты с кучей подключаемых фреймворков, библиотек, разбивки на независимые интегрируемые компоненты и тогда спринг более удобен.

если есть средства, которые генерируют вам базу и недостающие рутинные компоненты по исходникам, написанным на одном и том же языке?

Здесь вы тоже неправы, в хибернейте есть и способ задачи модели на языке(наиболее распространенный подход на сегодняшний день), и возможность генерить схему базы и ее инкрементально апдейтить по заданой модели(http://docs.jboss.org/hibernate/orm/3.3 ... guide-s1-6). Последнее(инкрементальный апдейт) впрочем я лично не использовал, но первыми двумя пунктами вполне пользовался.

Извините, я такую ерундистику на веру не принимаю.

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

Я с джавой с 1998 года, jdk 1.1. и аплетов на awt.

[crypto5]

Если хочется все из коробки и convention over configuration смотрите grails и play.

Grails - согласен, гут, потому как экономит время.

К слову grails это обертка над spring, hibernate и некоторыми другими фреймворками.

[Palych]

Разговор шел про DLL/JAR hell и конкретную проблему deployment'а модулей у кого-то еще. ...Жабе распространяются ... Все барахло идет в комплекте, потому что у клиента не факт, что есть вобще какие-то JAR'ы.

Я как раз имел в виду что жаба сама по себе монолитна, с минимальными зависимостями от системы.
Это сделало её поведение предсказуемым (на серверах).