размышляю тут над очередным проектом, встает вопрос на чем его делать (оригинально, да?).
Проект, понятно, ориентированный на web. В презентейшн-части предполагается весьма
интенсивно использовать XML/XSL.
Очевидные плюсы руби: Очень приятный язык. Наверное, лучший из императивных, по крайней мере единственный, не вызывающий отвращения
Модная тема — можно нагнать хайпа
Рельсы довольно удобный (на первый взгляд) фреймфорк
Приложение можно (и удобно) разворачивать отдельно от апача, ценно для standalone инсталляций
Очевидные минусы руби:
Тормозмной тупой интерпретатор, наверное самый тормозной из популярных, даже байт-кодов не умеет
Непонятно, насколько удобно использовать рельсы в паре с XML/XSL
Судя по всему, рубистов маловато — могут быть траблы с последующей поддержкой
Из минусов руби меня более всего, конечно, беспокоит пункт (2). Если использгование XML красиво не
вписывается в рельсы, то это полный привет.
Очевидные плюсы питона:
Довольно быстрый, умеет байткоды, жрет мало памяти. mod_python, говорят, раза в два быстрее mod_perl (фантастика?)
Есть py2exe, что дает некоторые приятные в перспективы для распространения продукта (в отдаленном будущем)
Очевидные минусы питона:
Синтаксис довольно отвратительный. Все эти self, __init__ и отступы, которые могут переколбашиваться излишне умными редакторами.
По поводу остальных — перл, понятно, сразу нафиг.
Java... Java.
Из минусов — жависты сейчас наиболее закушавшиеся и дорогие разработчики, нужен сразу довольно мощный хостинг, что
ведет к большим издержкам на начальном этапе проекта. Язык сам довольно противный, полное отсутствие syntax sugar...
Кстати, может кто сравнивал или хотя бы слышал, по производительности жаба сильно рвет питона на веб-приложениях?
C++ . Наверное, не катит, потому как надо очень-очень быстро, пусть даже в ущерб производительности.
PHP надоел до тошноты, ну его в баню. Тормозит одинаково с Руби, лучше уж тогда Руби.
Идеи? Только не сносите в войны, это не война, а действительно насущный вопрос.
В принципе, основной вопрос — убедите, что руби использовать на продакшене не стремно и не придется потом
все переписывать на чем-то другом
Здравствуйте, dmz, Вы писали:
dmz>Очевидные плюсы руби: dmz> Очень приятный язык. Наверное, лучший из императивных, по крайней мере единственный, не вызывающий отвращения dmz> Модная тема — можно нагнать хайпа dmz> Рельсы довольно удобный (на первый взгляд) фреймфорк
Это не столь однозначно, как кажется на первый взгляд. По опыту создания небольшого Web-приложения у меня сложилось не очень благоприятное впечатление. Из-за того, что в RoR все разделено на
уровни после некоторого перерыва в работе начинаешь забывать, какие именно данные ты имеешь на
конкретном уровне (скажем на уровне View). Ведь Ruby динамически типизированный язык, деклараций типов
возвращаемых значений нет -- что именно возвращает какой-то метод уже не помнишь. Без наличия
исходников соответствующего уровня уже не разберешься... В общем как раз тот случай, когда начинаешь
скучать по статической типизации
Но нужно добавить, что под Web я больше практически не программировал (не считая некоторого опыта на JSP). Поэтому не могу сказать, насколько RoR удобнее других фреймворков.
dmz> Приложение можно (и удобно) разворачивать отдельно от апача, ценно для standalone инсталляций
Это так. Но нужно понимать, что если RoR разворачивается через Webrick, то Webrick синхронизирует все параллельные запросы к RoR из-за чего могут наблюдаться тормоза.
Кроме Webrick сейчас еще Mongrel HTTP-сервер писанный на Ruby развивается. Так по слухам он может позволить разворачивать RoR без FastCGI.
dmz>Очевидные минусы руби: dmz> Тормозмной тупой интерпретатор, наверное самый тормозной из популярных, даже байт-кодов не умеет
Скорость 1.8 существенно повысили по сравнению с 1.6. А в грядущей версии 2.0 обещают еще быстрее Ruby сделать. Есть основание этому верить. Кроме того, как любят говорить RoR-овцы, основные тормоза в Web-приложениях отнюдь не Ruby-код создает.
dmz> Непонятно, насколько удобно использовать рельсы в паре с XML/XSL
А что именно? RoR поддерживает AXAJ, поддерживает WebServices, позволяет генерировать страницы в XML (через xml-builder-ы) /правда сам не пробовал, но что-то читал на эту тему/. Сейчас в RoR добавляют поддержку REST.
dmz> Судя по всему, рубистов маловато — могут быть траблы с последующей поддержкой
Зато Rubyist-ы очень доброжелательные и любят помогать друг другу
Если серьезно, то Ruby и особенно RoR -- это сейчас горячая тема и по ней появляется много информации в RSS-новостях. Так что есть надежда, что возрастающая популярность Ruby позволит от этого минуса избавиться.
Кстати, есть RubyScript2Exe -- утаптывает ruby, библиотеки и твои скрипты в один EXE-шник.
dmz>В принципе, основной вопрос — убедите, что руби использовать на продакшене не стремно и не придется потом dmz>все переписывать на чем-то другом
и стал продавать ее напрямую через собственный сайт. Сайт, естественно, под RoR и поддержка on-line платежей книги была добавлена в этот сайт всего за день.
Так что попробуй. Прототипы на RoR действительно создаются ОЧЕНЬ быстро. Если столкнешься с какими-то проблемами поддержки XML, то не страшно будет выбросить Rubyновый прототип, т.к. он будет очень дешев.
dmz wrote: > размышляю тут над очередным проектом, встает вопрос на чем его делать > (оригинально, да?). > Проект, понятно, ориентированный на web. В презентейшн-части > предполагается весьма интенсивно использовать XML/XSL.
Мое имхо — для web идеальна Java. Лучше _ничего_ пока нет.
Для Java есть: IDE с поддержкой редактирования JSP/XSL с автокомплитом,
_мощнейшие_ web-framework'и, классные ORM.
RoR по моим впечатлениям — сборник buzzword'ов, нормально решающий
только те задачи, которые укладываются в его не особо гибкую
архитектуру. Нечто типа VB, только для Web'а.
Python — для него я не нашел нормальных framework'ов.
Здравствуйте, Cyberax, Вы писали:
C>Мое имхо — для web идеальна Java. Лучше _ничего_ пока нет.
C>Для Java есть: IDE с поддержкой редактирования JSP/XSL с автокомплитом, C>_мощнейшие_ web-framework'и, классные ORM.
ASP.NET тоже ничего. Но по части фреймворков и ORM дотнет, конечно, активно сливает... Остаётся только надеяться, что платформа "повзрослеет" и ситуация изменится (хотя пока что в основном происходят только порты с Java).
С другой стороны, мы вот педалим на ASP.NET и ничего. Правда, используем тот же NHibernate, например (который порт Hibernate 2.1)...
Oyster wrote: > ASP.NET тоже ничего. Но по части фреймворков и ORM дотнет, конечно, > активно сливает... Остаётся только надеяться, что платформа > "повзрослеет" и ситуация изменится (хотя пока что в основном происходят > только порты с Java).
Я бы сказал, что web-фреймоворки в Java уже значительно опередили
ASP.NET по функциональности. Особенно те фреймворки, которые изначально
ориентировались на максимальную гибкость (Tapestry, например).
Тут имеет значение намного более короткий release cycle в большинстве
OpenSource Java-систем
Здравствуйте, Cyberax, Вы писали:
C>Я бы сказал, что web-фреймоворки в Java уже значительно опередили C>ASP.NET по функциональности. Особенно те фреймворки, которые изначально C>ориентировались на максимальную гибкость (Tapestry, например).
Согласен. У Java было больше времени для "разгона".
C>Тут имеет значение намного более короткий release cycle в большинстве C>OpenSource Java-систем
Разве это так? Я не слышал, чтобы язык автоматически гарантировал более короткое время разработки. Хотя если это связано с тем, что много чего уже написано и может быть использовано + сформировано более массивное OpenSource-сообщество, тогда понятно.
В общем, опять же время играет против .NET. И именно поэтому я говорю, что у .NET community есть шансы повзрослеть.
Ух, сейчас скатимся до священных войн.
C>Для Java есть: IDE с поддержкой редактирования JSP/XSL с автокомплитом, C>_мощнейшие_ web-framework'и, классные ORM.
IDE в лучшем случае компенсируют убожество языка. Дело личных предпочтений, но из
мощной IDE и мощного языка — я выбираю мощный язык.
Плюс, в данной задаче приоритеты — дешевизна setup и скорость разработки.
Например, у меня хостинг под FreeBSD — как там с жабой? Думаю, что все плохо.
В любом случае, для моей задачи Java я думаю — оверкил. Как по стоимости разработки (время, деньги),
так и по стоимости хостинга, на котором все должно работать.
C>RoR по моим впечатлениям — сборник buzzword'ов, нормально решающий C>только те задачи, которые укладываются в его не особо гибкую C>архитектуру. Нечто типа VB, только для Web'а.
Вот как раз хочу понять, так это или не так. На первый взгляд — вполне нормальный фреймворк,
хоть и очень непривычно всё.
C>Python — для него я не нашел нормальных framework'ов.
Да в общем, мне не много и надо, если подумать — libxslt (есть),
да ORM (есть third-party, есть и собственный, к которому приделать кодогенерацию для питона —
вопрос максимум дня на три)
Здравствуйте, dmz, Вы писали:
dmz>Привет,
dmz>размышляю тут над очередным проектом, встает вопрос на чем его делать (оригинально, да?). dmz>Проект, понятно, ориентированный на web. В презентейшн-части предполагается весьма dmz>интенсивно использовать XML/XSL.
dmz>Очевидные плюсы руби: dmz> Очень приятный язык. Наверное, лучший из императивных, по крайней мере единственный, не вызывающий отвращения dmz> Модная тема — можно нагнать хайпа dmz> Рельсы довольно удобный (на первый взгляд) фреймфорк dmz> Приложение можно (и удобно) разворачивать отдельно от апача, ценно для standalone инсталляций
dmz>Очевидные минусы руби: dmz> Тормозмной тупой интерпретатор, наверное самый тормозной из популярных, даже байт-кодов не умеет
Тут не все так однозначно, на некоторых задачах RoR оказывается быстрее PHP
А вот самый на мой взгляд минус RoR — жрет очень много RAM ты забыл
dmz> Непонятно, насколько удобно использовать рельсы в паре с XML/XSL dmz> Судя по всему, рубистов маловато — могут быть траблы с последующей поддержкой
XML идет в стандарной библиотеке, pure Ruby (ReXML)
Ничего не мешает добавить поддержку libxml/libxslt
Пример создания xml документа
xml = Builder::XmlMarkup.new(:target => File.open(path, "w"), :indent => 2)
xml.table("name" => table_name) do |row|
row.title("lang" => "ru") do |sub|
sub.subtitle = "subtitle"
end
row.data = row.cdata!("cdata section")
end
----
<table name="table_name">
<title lang="ru">
<subtitle>subtitle</subtitle>
</title>
<data><[!CDATA[cdata section]]>
</table>
Oyster wrote: > Разве это так? Я не слышал, чтобы язык автоматически гарантировал более > короткое время разработки. Хотя если это связано с тем, что много чего > уже написано и может быть использовано + сформировано более массивное > OpenSource-сообщество, тогда понятно.
Нет, я о другом. Предидущий релиз ASP.NET был в 2003 году, с этого
времени прошло 3 года.
В Tapestry за это время успели сделать несколько релизов, учитывая в
каждом из них пожелания пользователей. Вот и получается, что
Java-фреймворки более продвинутые.
> В общем, опять же время играет против .NET. И именно поэтому я говорю, > что у .NET community есть шансы повзрослеть.
Ага.
dmz wrote: > IDE в лучшем случае компенсируют убожество языка. Дело личных > предпочтений, но измощной IDE и мощного языка — я выбираю мощный язык.
Попробуйте несколько дней поработать с IDEA — тогда поймете как ошибались.
> Плюс, в данной задаче приоритеты — дешевизна setup и скорость разработки. > Например, у меня хостинг под FreeBSD — как там с жабой? Думаю, что все > плохо.
Нормально работает. Хотя не так быстро как в Линуксе.
Про скорость разработки — в Java у профессионалов она _больше_ чем в
ASP.NET. Сказывается лучшая поддержка IDE и более продуманная архитектура.
> C>RoR по моим впечатлениям — сборник buzzword'ов, нормально решающий > C>только те задачи, которые укладываются в его не особо гибкую > C>архитектуру. Нечто типа VB, только для Web'а. > Вот как раз хочу понять, так это или не так. На первый взгляд — вполне > нормальный фреймворк, хоть и очень непривычно всё.
Не знаю, мне он просто показался сборкой всех попсовых buzzword'ов. В
нем "все есть", но на деле оно работает только в рамках, предусмотреных
разработчиками.
> C>Python — для него я не нашел нормальных framework'ов. > Да в общем, мне не много и надо, если подумать — libxslt (есть), > да ORM (есть third-party, есть и собственный, к которому приделать > кодогенерацию для питона — вопрос максимум дня на три)
А обработка форм, валидация, навигация и т.п. не нужно?
C>Попробуйте несколько дней поработать с IDEA — тогда поймете как ошибались.
Мы уже бодались на эту тему — не будем повторяться. Я в IDEA проработал минимум два года.
C>Нормально работает. Хотя не так быстро как в Линуксе.
Там вечная проблема с версиями; появляются намного позже.
И потом медленнее чем на линуксе — это само по себе печально,
ведь жаба и так штука не быстрая.
C>Про скорость разработки — в Java у профессионалов она _больше_ чем в C>ASP.NET. Сказывается лучшая поддержка IDE и более продуманная архитектура.
Ну, ASP.NET я даже не рассматриваю.
C>Не знаю, мне он просто показался сборкой всех попсовых buzzword'ов. В C>нем "все есть", но на деле оно работает только в рамках, предусмотреных C>разработчиками.
Исследую вопрос. Пока этот пессимизм не разделяю.
>> кодогенерацию для питона — вопрос максимум дня на три) C>А обработка форм, валидация, навигация и т.п. не нужно?
Проблем с навигацией я вообще не вижу, обработка форм, валидация — привык ручками. В принципе, питон скорее
всего пролетает, дюже уж он противный. А в рельсах это вроде есть, хотя вопрос насколько юзабельно.
Вскрытие покажет.
Здравствуйте, dmz, Вы писали:
dmz>Да в общем, мне не много и надо, если подумать — libxslt (есть), dmz>да ORM (есть third-party, есть и собственный, к которому приделать кодогенерацию для питона — dmz>вопрос максимум дня на три)
Кстати о птичках. ActiveRecord не единственный ORM для Ruby. Так же как RoR не единственный Web-framework.
Еще еще Nitro у которого есть собственный ORM: Og.
А так же IOWA и cerise
Т.е. есть из чего выбирать. Только по RoR информации больше.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
VD>Ну, говорить ничего не буду. Все кто хотели те уже все поняли.
Не, ну я не против Nemerle, равно как и Erlang. "Но как?!" — вот этого я не представляю.
Здравствуйте, dmz, Вы писали:
dmz>Привет,
dmz>Очевидные минусы руби: dmz> Тормозмной тупой интерпретатор, наверное самый тормозной из популярных, даже байт-кодов не умеет
Ждём ruby2
dmz> Непонятно, насколько удобно использовать рельсы в паре с XML/XSL
Всё ок вот в 1.1 сделали например такую штуку для объектов:
dmz> Судя по всему, рубистов маловато — могут быть траблы с последующей поддержкой
Зато посмотри какое централизованное и мощное комьюнити на rubyonrails.com, оно не разрабосано по разным фрэймворкам, как у питона или джавы.
dmz>Очевидные плюсы питона: dmz> Есть py2exe, что дает некоторые приятные в перспективы для распространения продукта (в отдаленном будущем)
Не поможет декомпилеры востанавливают код на раз, это только для stand alone использовать.
dmz>Очевидные минусы питона: dmz> Синтаксис довольно отвратительный. Все эти self, __init__ и отступы, которые могут переколбашиваться излишне умными редакторами.
Да уж, тоже ненавижу
dmz>В принципе, основной вопрос — убедите, что руби использовать на продакшене не стремно и не придется потом dmz>все переписывать на чем-то другом
Посмотри на примеры реальных приложений на rubyonrails.com и оцени.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dmz, Вы писали:
VD>Ну, говорить ничего не буду. Все кто хотели те уже все поняли.
Да да. Тока под немерл нету такого веб-фрэймворка, как и к сожалению под коммон лисп... Так что юзаем лучшее что есть. Что ни говори руби держиться на более высоком уровне относительно других подобных языков(perl, python, php(ну про ЭТО вообще лучше не упоминать)), да и метапрограммирование/dsl в него намного лучше вписываеться, а это очень о многом говорит.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Будеш теперь просто отправлять пустые сообщения? Типа "я еще живой, но все вы и так знаете, что я скажу"?
Ну, а что делать если люди перед тем как создавать темы не читают другие темы?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
