размышляю тут над очередным проектом, встает вопрос на чем его делать (оригинально, да?).
Проект, понятно, ориентированный на 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>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, CrazyPit, Вы писали:
CP>Да да. Тока под немерл нету такого веб-фрэймворка, как и к сожалению под коммон лисп...
То-то на КомонЛиспе сколько сайтов отгрохано. Не чита какому-то там ASP.NET.
CP> Так что юзаем лучшее что есть.
Внушаете себе эту мысль.
CP> Что ни говори руби держиться на более высоком уровне относительно других подобных языков(perl, python, php(ну про ЭТО вообще лучше не упоминать)),
Питон? Спорно. Но даже если и так, то на них свет клином не сошелся.
CP> да и метапрограммирование/dsl в него намного лучше вписываеться, а это очень о многом говорит.
О DSL можно говорить когда основной язык предоставляет нужные средства контроля. А так... просенькие слабо связанные странички в общем-то по барабану на чем писать. В массе своей не умудренный опытом программирования народ вообще выбирает ПХП.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>А что так?
Лично не знаю, не видел, не хочу связываться. Будет VDS — Linux или FreeBSD (сейчас) — хостинг.
По работе у меня есть несколько систем на ASP/.NET, впечатление очень негативное. Конечно, может
всему виной кривые руки поставщиков — но осадок остается, связываться с этим я не хочу.
VD>Да, и намекнуть на это можно было бы в теме. А то странно выглядит все это.
Ну я перечислил, что я рассматриваю. Со всем перечисленным или был опыт (C++, Java, PHP), или хотя
бы примерно представляю, как оно из себя выглядит (Python, Ruby).
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dmz, Вы писали: dmz>>Не, ну я не против Nemerle, равно как и Erlang. "Но как?!" — вот этого я не представляю. VD>Что как?
Он прав. Нужно в команде иметь хотя бы одного "компетента" по соответсвующей технологии.
Иначе (какая бы технология ни была), первое время — это хождение по граблям.
Мы когда начинали с Erlang-ом, специально небольшой (и не очень ответсвенный) проект под "собирание граблей" запустили...
Не стану говорить, что это обошлось дорого (даже этот "подопытный кролик" самоокупается), но время все равно требуется.
Здравствуйте, VladD2, Вы писали:
VD>В массе своей не умудренный опытом программирования народ вообще выбирает ПХП.
Конечно, и этим ламерам удалось сделать Yahoo и SourceForge только по чистой случайности. По теории вероятностей эти две попытки просто должны были оказаться удачными среди миллионов проваленных на PHP проектов
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, VladD2, Вы писали:
VD>>В массе своей не умудренный опытом программирования народ вообще выбирает ПХП.
E>Конечно, и этим ламерам удалось сделать Yahoo и SourceForge только по чистой случайности. По теории вероятностей эти две попытки просто должны были оказаться удачными среди миллионов проваленных на PHP проектов
man history. Yahoo во многом подняли лисп-хакеры (не Пол Грэм, хотя он тоже вложился) и не какого пхп там сначала не было. У них даже была интегрерованная система совместной работы полностью написанная на Emacs Lispе, но потом когда денег стало много они стали выбирать попсовые технологии (переписали эту систему на джаве и люди много лет плевались от джавовской поделки вспоминая добрыми словами старую систему; переписали т.к. многие те лисп-хакеры либо ушли, либо поднялись что им не стало дело до коддинга). Так же и с яху стор...
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, CrazyPit, Вы писали:
CP>>Да да. Тока под немерл нету такого веб-фрэймворка, как и к сожалению под коммон лисп...
VD>То-то на КомонЛиспе сколько сайтов отгрохано. Не чита какому-то там ASP.NET.
Я же написал что нет фрэймворка такого причём тут коммон лисп мы про RoR говорим. А у лиспа вообще одна из основных ниш такая -- создавать программы которые до этого ещё никто не писал, когда область очень тумманна и сложна. Смотрим на первые системы символьной математики, некоторые сложные биологические системы, то же яху стор, те же статистические спам-фильтры...
CP>> Так что юзаем лучшее что есть.
VD>Внушаете себе эту мысль.
А что таки вы предлогаете для веб разработки? Seaside или может SISCWeb? Да тоже хорошие штуки но комьюнити далеко не так развито.
CP>> Что ни говори руби держиться на более высоком уровне относительно других подобных языков(perl, python, php(ну про ЭТО вообще лучше не упоминать)),
VD>Питон? Спорно. Но даже если и так, то на них свет клином не сошелся.
Ну так что же предложите вы?
CP>> да и метапрограммирование/dsl в него намного лучше вписываеться, а это очень о многом говорит.
VD>О DSL можно говорить когда основной язык предоставляет нужные средства контроля. А так... просенькие слабо связанные странички в общем-то по барабану на чем писать. В массе своей не умудренный опытом программирования народ вообще выбирает ПХП.
Как раз для Веба очень нужен DSL, и если почитать рельсовское API, при этом хорошо представляя что такое DSL, можно увидеть что Рельсы — это большой набор хоршо взаимодействующих DSL, и руби как язык с этим нормально справляется.
Здравствуйте, CrazyPit, Вы писали:
CP>man history. Yahoo во многом подняли лисп-хакеры (не Пол Грэм, хотя он тоже вложился) и не какого пхп там сначала не было. У них даже была интегрерованная система совместной работы полностью написанная на Emacs Lispе, но потом когда денег стало много они стали выбирать попсовые технологии (переписали эту систему на джаве и люди много лет плевались от джавовской поделки вспоминая добрыми словами старую систему; переписали т.к. многие те лисп-хакеры либо ушли, либо поднялись что им не стало дело до коддинга). Так же и с яху стор...
Здравствуйте, CrazyPit, Вы писали:
CP>>> да и метапрограммирование/dsl в него намного лучше вписываеться, а это очень о многом говорит.
VD>>О DSL можно говорить когда основной язык предоставляет нужные средства контроля. А так... просенькие слабо связанные странички в общем-то по барабану на чем писать. В массе своей не умудренный опытом программирования народ вообще выбирает ПХП.
CP>Как раз для Веба очень нужен DSL, и если почитать рельсовское API, при этом хорошо представляя что такое DSL, можно увидеть что Рельсы — это большой набор хоршо взаимодействующих DSL, и руби как язык с этим нормально справляется.
Кстати, здесь можно привести в качестве примера твой код с обсуждения RoR 1.1 на linux.org.ru:
Здравствуйте, CrazyPit, Вы писали:
CP>... У них даже была интегрерованная система совместной работы полностью написанная на Emacs Lispе, но потом когда денег стало много они стали выбирать попсовые технологии (переписали эту систему на джаве и люди много лет плевались от джавовской поделки вспоминая добрыми словами старую систему; переписали т.к. многие те лисп-хакеры либо ушли, либо поднялись что им не стало дело до коддинга)...
Имхо, это история не про Yahoo, а про Amazon. См. Tour de Babel (ссылка была предоставлена Mamut-ом, здесь
Shel wrote Mailman in C, and Customer Service wrapped it in Lisp. Emacs-Lisp. You don't know what Mailman is. Not unless you're a longtime Amazon employee, probably non-technical, and you've had to make our customers happy. Not indirectly, because some bullshit feature you wrote broke (because it was in C++) and pissed off our customers, so you had to go and fix it to restore happiness. No, I mean directly; i.e., you had to talk to them. Our lovely, illiterate, eloquent, well-meaning, hopeful, confused, helpful, angry, happy customers, the real ones, the ones buying stuff from us, our customers. Then you know Mailman.
Mailman was the Customer Service customer-email processing application for ... four, five years? A long time, anyway. It was written in Emacs. Everyone loved it.
People still love it. To this very day, I still have to listen to long stories from our non-technical folks about how much they miss Mailman. I'm not shitting you. Last Christmas I was at an Amazon party, some party I have no idea how I got invited to, filled with business people, all of them much prettier and more charming than me and the folks I work with here in the Furnace, the Boiler Room of Amazon. Four young women found out I was in Customer Service, cornered me, and talked for fifteen minutes about how much they missed Mailman and Emacs, and how Arizona (the JSP replacement we'd spent years developing) still just wasn't doing it for them.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Конечно, и этим ламерам удалось сделать Yahoo и SourceForge только по чистой случайности. По теории вероятностей эти две попытки просто должны были оказаться удачными среди миллионов проваленных на PHP проектов
Все, убедил. ПХП рулиз и форева. Выбрасывай свой мудреный Руби и С++ и переходи на ПХП. Ну, а я упрямый идиот и не хочу проникнуться щастьем ПХП.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>>А что так? dmz>Лично не знаю, не видел, не хочу связываться. Будет VDS — Linux или FreeBSD (сейчас) — хостинг. dmz>По работе у меня есть несколько систем на ASP/.NET, впечатление очень негативное. Конечно, может dmz>всему виной кривые руки поставщиков — но осадок остается, связываться с этим я не хочу.
Виной кривые руки поставщиков. Вот есть крупный местный Win хостинг (>10 серверов под полную завязку).
Самые беспроблемные, надежные, контролируемые и быстрые приложения это ASP.NET, особенно после перевода хостинга на .NET 2. На последнем месте из популярных с большим отрывом Perl...
Но если постараться, можно на чем угодно гадости наваять...
VD>>Да, и намекнуть на это можно было бы в теме. А то странно выглядит все это. dmz>Ну я перечислил, что я рассматриваю. Со всем перечисленным или был опыт (C++, Java, PHP), или хотя dmz>бы примерно представляю, как оно из себя выглядит (Python, Ruby).
PHP позволяет быстрее писать...
А потом выясняется, что в нем невозможно работать с файлами > 2Гб и куча тому подобных вещей...
Джависты, да, дорогие... Но вообще хорошие программисты дорогие.
На .NET переехали некоторые VBшники... Так что есть шанс незадорого...
Но вообще надо понимать Java и .NET имеют реальный JIT. Т.е. из них получается реально процессорный код. .NET в среднем быстрее, но не на порядок (раза в полтора). Остальное (то что не имеет компилятора в машинный код) в любом случае курит — так как интерпретатор.
Питон и Руби... Ну, не знаю много ли хороших программистов на них свободных...
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dmz, Вы писали:
dmz>>Не, ну я не против Nemerle, равно как и Erlang. "Но как?!" — вот этого я не представляю.
VD>Что как?
У меня вот тоже вопрос — как? ГДЕ VSIP? Ну дайте VSIP (+версию 1.0) — завтра сяду на нем писать...
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, dmz, Вы писали:
VD>Ну, говорить ничего не буду. Все кто хотели те уже все поняли.
-- Анекдот номер 3
-- Ха ха ха ха!!! Анекдот номер 8
-- Ха ха ха ха!!! Анектод номер 5
-- Эй, эй, полегче! Не при детях!
Здравствуйте, CrazyPit, Вы писали:
CP>>>Да да. Тока под немерл нету такого веб-фрэймворка, как и к сожалению под коммон лисп...
VD>>То-то на КомонЛиспе сколько сайтов отгрохано. Не чита какому-то там ASP.NET.
CP>Я же написал что нет фрэймворка такого причём тут коммон лисп мы про RoR говорим.
Выделено жирным (выше) в твоих словах.
CP> А у лиспа вообще одна из основных ниш такая -- создавать программы которые до этого ещё никто не писал, когда область очень тумманна и сложна.
Что же такого невероятного есть в Лиспе и нет в остальных языках? Я вот почему-то все время пишу код который до этого не писал. И что?
CP>А что таки вы предлогаете для веб разработки? Seaside или может SISCWeb? Да тоже хорошие штуки но комьюнити далеко не так развито.
ASP.NET.
CP>Ну так что же предложите вы?
Лично я бы взял Nemerlr или C# в паре с ASP.NET, XSLT и т.п. И уверен, что ни проиграл бы никому ни по скорости, ни по возможностям, ни темболее по производительности.
CP>Как раз для Веба очень нужен DSL, и если почитать рельсовское API, при этом хорошо представляя что такое DSL, можно увидеть что Рельсы — это большой набор хоршо взаимодействующих DSL, и руби как язык с этим нормально справляется.
Для веба как такового ДСЛ-ни не нужы. ДСЛ-и нужны для прикладных задач. Другое дело, что и веб и делается для их решения. Но ведь не только вэб.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, CrazyPit, Вы писали:
CP>> А у лиспа вообще одна из основных ниш такая -- создавать программы которые до этого ещё никто не писал, когда область очень тумманна и сложна.
VD>Что же такого невероятного есть в Лиспе и нет в остальных языках?
Что опять? Не в этой же теме.
?> Я вот почему-то все время пишу код который до этого не
писал. И что?
Одно дело код которое до этого никто не писал, другое дело код работающий с какой-нибудь новой не изученной областью. Тем более я писал что лисп для этого очень хорошо подходит, а не то что такие вещи нужно писать только на нём.
VD>Для веба как такового ДСЛ-ни не нужы. ДСЛ-и нужны для прикладных задач. Другое дело, что и веб и делается для их решения. Но ведь не только вэб.
Если говорить про MVC веб то пожалуйста DSL нужен для ORM, DSL нужен для связи логики с представлением, DSL нужен собственно для генерации HTML/XML/JS инерфейса, а уж внутренняя логика программы тоже может быть реализована уже на специально сделанном DSL, так что для веба нужны общие DSLи, которые именно отвечают за web сущность приложения.
Здравствуйте, CrazyPit, Вы писали:
VD>>Что же такого невероятного есть в Лиспе и нет в остальных языках?
CP>Что опять? Не в этой же теме.
А что кто-то это показал или доказал?
CP>Одно дело код которое до этого никто не писал, другое дело код работающий с какой-нибудь новой не изученной областью.
Никакой разницы. Для меня любоая неизвестная мне область является "новой не изученной областью".
CP> Тем более я писал что лисп для этого очень хорошо подходит, а не то что такие вещи нужно писать только на нём.
Хм. Лисп это ряд решений. Одни из них впечатляют. Другие удручают. Вот макросы впечатляют. А синтаксис удручает. Все же странно иметь язык на котором можно создать другой язык, но при этом нельзя пользоваться им самим без самодрисеровки.
CP>Если говорить про MVC веб то пожалуйста DSL нужен для ORM,
1. ORM не имеет прямой связи с вебом.
2. Сам по себе ORM мне кажется сомнительным достижением. Особенно в области веба.
CP> DSL нужен для связи логики с представлением,
Ну, если ДСЛ-ем назвать ASP, XSLT или JSP, то несомненно. Но эти ДСЛ-и уже давно сделаны и работают. Так что смыса о них говорить нет.
CP> DSL нужен собственно для генерации HTML/XML/JS инерфейса,
См. выше.
CP>а уж внутренняя логика программы тоже может быть реализована уже на специально сделанном DSL,
Может. А может и на универсашльном. А может на ДСЛ, но без веб и т.п.
CP> так что для веба нужны общие DSLи, которые именно отвечают за web сущность приложения.
Нет никакой связи между вебом и дсл-ями. В конце концов XAML тоже ДСЛ. И Формат проктов студии или Annt-а тоже...
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Max.Subpixel, Вы писали:
MS>>Я о поддержке в VS2005.
VD>Серьезной поддержки пока нет. А то что есть обходится без VSIP-а. А реализация на VSIP пока просто никакая.
Ну вот поэтому и не беремся. Потому что работать без студии это как-то медленно.
Здравствуйте, CrazyPit, Вы писали:
CP>А у лиспа вообще одна из основных ниш такая -- создавать программы которые до этого ещё никто не писал, когда область очень тумманна и сложна. Смотрим на первые системы символьной математики, некоторые сложные биологические системы, то же яху стор, те же статистические спам-фильтры...
Имхо, не столько Lisp подходит для новых областей, сколько Lisp подходит тем людям, которым интересно влазить в совершенно новые области программостроения.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, VladD2, Вы писали:
VD>Хм. Лисп это ряд решений. Одни из них впечатляют. Другие удручают. Вот макросы впечатляют.
А я думал это палка о двух концах, либо мощные мактосы\примитивный синтаксис либо ни того ни другого.
VD>А синтаксис удручает. Все же странно иметь язык на котором можно создать другой язык, но при этом нельзя пользоваться им самим без самодрисеровки.
Хм... где-то я видел библиотеку немного меняющую reader чтоб даже в REPL можно было использовать традиционный способ записи арифметических выражений.
Так что синтаксис ой как можно покорежить... видно это просто никому н нужно.
-- Главное про деструктор копирования не забыть --
Здравствуйте, mishaa, Вы писали:
M>Здравствуйте, VladD2, Вы писали:
VD>>Хм. Лисп это ряд решений. Одни из них впечатляют. Другие удручают. Вот макросы впечатляют. M>А я думал это палка о двух концах, либо мощные мактосы\примитивный синтаксис либо ни того ни другого.
Ну, вот, как видишь, на свете существуют:
1. Caml4p.
2. Template Haskel.
3. Nemerle.
Все эти языки обладают макросами мало чем уступающими Лиспам (а то и привосходящие их кое где), но при этом имеют четкий синтаксис.
M>Так что синтаксис ой как можно покорежить... видно это просто никому н нужно.
А зачем пытаться что-то сделать получая кучу побочных проблем, если уже есть языки с синтаксисом и макро-возможностями Лиспов?
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, dmz, Вы писали:
dmz>размышляю тут над очередным проектом, встает вопрос на чем его делать (оригинально, да?). dmz>Проект, понятно, ориентированный на web. В презентейшн-части предполагается весьма dmz>интенсивно использовать XML/XSL.
dmz>>Проект, понятно, ориентированный на web. В презентейшн-части предполагается весьма dmz>>интенсивно использовать XML/XSL.
B>Скажи мне одно, а зачем тебе XML/XSL?
Удобно, просто, стандартно, отработано в других проектах, довольно быстро, особенно если
кэшировать шаблоны,и главное, полностью отвязывает презентейшн от ядра. Вплоть до того,
что можно полностью сменить технологию/средства, при этом вообще не трогая презентейшн.
Кстати, поигравшись с руби, питоном и остальным, технологию я выбрал, но какую — не скажу,
что бы не забили тапками.
dmz wrote: > Вплоть до того, > что можно полностью сменить технологию/средства, при этом вообще не > трогая презентейшн.
До тех пор, пока нужно только выводить данные.
Обработчики форм, понятно, придется переписывать. Но это не так убойно и дорого (для меня), как переверстывать
под другой шаблонный движок. В любом случае, вдвое меньше работы. Учитывая, что ORM способен генерить код под
разные языки, переписывать придется только контроллеры, а они максимально отвязаны от реалий конкретного
инструментария.
Впрочем, если удасться придумать какой-нибудь путевый DSL для генерации обработчиков форм,
то может количество кода получится еще сократить. Но тут уже некий конфклит ресурсов, к сожалению.
Здравствуйте, dmz, Вы писали:
dmz>Кстати, поигравшись с руби, питоном и остальным, технологию я выбрал, но какую — не скажу, dmz>что бы не забили тапками.
Ну тогда скажи только мне. icq: 99934676, jabber: burchik@gmail.com
Здравствуйте, dmz, Вы писали:
dmz>>>Проект, понятно, ориентированный на web. В презентейшн-части предполагается весьма dmz>>>интенсивно использовать XML/XSL.
B>>Скажи мне одно, а зачем тебе XML/XSL?
dmz>Удобно, просто, стандартно, отработано в других проектах, довольно быстро, особенно если dmz>кэшировать шаблоны,и главное, полностью отвязывает презентейшн от ядра. Вплоть до того, dmz>что можно полностью сменить технологию/средства, при этом вообще не трогая презентейшн.
B>А на XSL не напрягает писать?
XSL — клёвый! Единственное что в нем плохо — это громоздкий XML синтаксис.
А сам язык очень приятный для решения своих задач.
Здравствуйте, CrazyPit, Вы писали:
CP>Здравствуйте, dmz, Вы писали:
dmz>>Кстати, поигравшись с руби, питоном и остальным, технологию я выбрал, но какую — не скажу, dmz>>что бы не забили тапками.
CP>PHP?
Вы будете смеяться, но в итоге python. web.py + SQLAlchemy + nginx (или lighttpd)
Здравствуйте, dmz, Вы писали:
CP>>PHP? dmz>Вы будете смеяться, но в итоге python. web.py + SQLAlchemy + nginx (или lighttpd)
Я полтора месяца назад переписал часть под web.py, для шаблонов использовал Cheetah.
А щас переписал все на Django v0.95. Кайфую.
B>А щас переписал все на Django v0.95. Кайфую.
А зачем, кстати? Мне что в TG, что в Django не нравятся их ORMы — по сравнению с
SQLAlchemy это... просто примитив. А что бы открутить ORM от фреймворка и прикрутить
другой — надо его хорошо изучить, да и что останется?
В web.py и изучать нечего — простой и надежный. И с nginx заработал сразу.
B>>А щас переписал все на Django v0.95. Кайфую. dmz>А зачем, кстати? Мне что в TG, что в Django не нравятся их ORMы — по сравнению с dmz>SQLAlchemy это... просто примитив. А что бы открутить ORM от фреймворка и прикрутить dmz>другой — надо его хорошо изучить, да и что останется?
А у меня Berkeley DB для большинства данных, потому что данные очень мелкие (слова и наборы слов).
И еще очень популярный запрос — дать N-е слово в таблице (одно) или N-й список слов.
Лучше я уж его руками сделаю, чем через SQL гонять. Глядишь, производительность в 100 раз поднимется
Хотя эту реализацию тоже наверное передизайнить надо будет при случае. dmz>В web.py и изучать нечего — простой и надежный. И с nginx заработал сразу.
А систему шаблонов ты какую используешь? Это еще одна весьма религиозная вещь. Я видел почти все, какие есть. Django-шаблоны для меня показались самыми удобными в использовании (за исключением ifequal из Django)
Мне не нравилось, что логика web-UI написана на питоне. Ужасно некрасивый код получался. Похуже, чем в php.
B>А систему шаблонов ты какую используешь? Это еще одна весьма религиозная вещь. Я видел почти все, какие есть.
cheetah + xsl
если есть что-то сильно лучше, хочется увидеть, конечно. Но мне показалось, что они все примерно одинаковые,
хоть и пыжаться быть разными.
B>Мне не нравилось, что логика web-UI написана на питоне. Ужасно некрасивый код получался. Похуже, чем в php.
а в остальных с этим лучше? Я имею ввиду kid и django прежде всего.
Здравствуйте, dmz, Вы писали:
B>>А систему шаблонов ты какую используешь? Это еще одна весьма религиозная вещь. Я видел почти все, какие есть. dmz>cheetah + xsl dmz>если есть что-то сильно лучше, хочется увидеть, конечно. Но мне показалось, что они все примерно одинаковые, dmz>хоть и пыжаться быть разными.
посмотри pymeld, он совсем другой
задачи-то одни и те же, поэтому системы шаблонов похожие. но не все шаблоны решают все задачи.
разные в них следующие вещи:
1 — подстановка локальных переменных (возможно/нет/автоматическая)
2 — возможен ли изнутри вызов питоновских функций и как это сделать
3 — как делается размножение нужных элементов ну и например чередование 2х стилей по ним
4 — есть ли внутренняя установка переменных
5 — есть ли внутренние циклы
6 — есть ли внутренняя подгрузка данных откуда-нибудь, например, из web-services (как-то мой товарищ xsl расширял этой фенькой)
7 — xml-based: плюсы — валидация, минусы — древовидность.
B>>Мне не нравилось, что логика web-UI написана на питоне. Ужасно некрасивый код получался. Похуже, чем в php. dmz>а в остальных с этим лучше? Я имею ввиду kid и django прежде всего.
kid — xml-based, мне это не понравилось. я считаю, что xml и xsl — не для людей, даже если есть удобный редактор. например, когда я недавно хотел поработать с xsl, меня очень смущала невозможность заиспользовать функции моего любимого языка программирования...
django — наподобие smarty и cheetah, но есть пара наворотов:
1) (от smarty) вызов питоновских функций-шаблонов таким образом: {{ var | wordwrap:70 | linebreaks }}
2) именованные области документа — blocks. наследование документов для цели переписывания именованных областей. для web-а самое то. создал базовый шаблон и поехал. простые вещи остаются простыми, и это круто.
B>например, когда я недавно хотел поработать с xsl, меня очень смущала невозможность заиспользовать функции моего B>любимого языка программирования...
Кстати, можно — для питона еще и довольно просто. По-моему, примеры есть в документации к python-libxslt
B>django — наподобие smarty и cheetah, но есть пара наворотов: B> 1) (от smarty) вызов питоновских функций-шаблонов таким образом: {{ var | wordwrap:70 | linebreaks }}
не понял, в чем прикол.
B> 2) именованные области документа — blocks. наследование документов для цели переписывания именованных областей. для web-а самое то. создал базовый шаблон и поехал. простые вещи остаются простыми, и это круто.
B>>например, когда я недавно хотел поработать с xsl, меня очень смущала невозможность заиспользовать функции моего B>любимого языка программирования...
dmz>Кстати, можно — для питона еще и довольно просто. По-моему, примеры есть в документации к python-libxslt
B>>django — наподобие smarty и cheetah, но есть пара наворотов: B>> 1) (от smarty) вызов питоновских функций-шаблонов таким образом: {{ var | wordwrap:70 | linebreaks }}
dmz>не понял, в чем прикол.
wordwrap и linebreaks — функции питона, var — переменная, переданная шаблонам. {{ ... }} — выполнить подстановку результата. впрочем, если проблема безопасности шаблонов тебя не волнует, то аналог из cheetah — прямой вызов функций — еще удобнее.
B>> 2) именованные области документа — blocks. наследование документов для цели переписывания именованных областей. для web-а самое то. создал базовый шаблон и поехал. простые вещи остаются простыми, и это круто.
dmz>Это есть в cheetah
А этого я не знал. Неудобно потому что...
3) Интернационализация специальным тегом
{% trans %} текст {% endtrans %}