>Думаю, что при грамотной как раз сложна и затратна. Шаблонизатор ничего не знает про логику приложения, поэтому фреймворк или приложение должны управлять такими вещами как кеширование, например, чтобы пресечь или сократить обработку запроса на ранних стадиях если уже есть готовый результат, т.е. управлять работой шаблонизатора, обслуживать его коллбэки за отдельными блоками (откуда шаблонизатор знает что приложение хочет вывести в этом блоке и нет ли уже закешированного результата - надо сходить обратно в приложение чтобы узнать). Ну и там ещё приложение может представлять свой сервис для кеширования данных - оно общается с акселераторами и разделяемой памятью, так что темплетной машине логичнее работать с этими ресурсами через него. Т.е. движок темплейтов либо сильно привязан к остальному фреймворку, либо менее эффективен.. Как-то так, я думаю.
Ну так и получается - кэшированием занято приложение, оно же и дёргает функции шаблонизатора, передавая в них данные, которые получаются в результате работы приложения. Оно же и отдаёт потом отрендеренный хтмл пользователю. И, соответственно, перед основной работой контроллера проверяется, есть ли в кэше нужный результат, или надо рендерить заново. А шаблонизатор вообще не в курсе всяких там кэшей и прочего. И достаточно просто заменить вызовы одного шаблонизатора другим. Вообще, конечно, тут есть нюансы, связаные с особенностями конкретного шаблонизатора.

И, кстати, пхп - отличный шаблонизатор сам по себе:)

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

> При грамотной архитектуре смена, например, движка шаблонов проста и незатратна.
Думаю, что при грамотной как раз сложна и затратна. Шаблонизатор ничего не знает про логику приложения, поэтому фреймворк или приложение должны управлять такими вещами как кеширование, например, чтобы пресечь или сократить обработку запроса на ранних стадиях если уже есть готовый результат, т.е. управлять работой шаблонизатора, обслуживать его коллбэки за отдельными блоками (откуда шаблонизатор знает что приложение хочет вывести в этом блоке и нет ли уже закешированного результата - надо сходить обратно в приложение чтобы узнать). Ну и там ещё приложение может представлять свой сервис для кеширования данных - оно общается с акселераторами и разделяемой памятью, так что темплетной машине логичнее работать с этими ресурсами через него. Т.е. движок темплейтов либо сильно привязан к остальному фреймворку, либо менее эффективен.. Как-то так, я думаю.

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

> Правда уже это мало имеет отношения к конкретным языкам программирования, и руби тут совершенно непричём.
Ну я бы не сказал - ведь находятся те, кто интересуется этим самым Руби.. А это уже симптомчик!

>И непривычно как-то - неужели каждая страничка должна делать это сама? Почему бы по умолчанию не биндить сразу во фреймворке?
Это вопрос к авторам этого фреймворка. Это действительно напоминает кучу слабосвязанных библиотек. Там кроме WSGI сервера почти ничего своего нет.

>Будут накладные расходы на универсальность.
При грамотной архитектуре смена, например, движка шаблонов проста и незатратна.

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

> почти набор библиотек
Ага. Смотрю в пример на ихнем сайту:

И непривычно как-то - неужели каждая страничка должна делать это сама? Почему бы по умолчанию не биндить сразу во фреймворке?

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

> Специализированное решение часто бывает быстрее.
Почему часто? Всегда. Другое делое, что многие люди по неграмотности своей до сих пор предпочитают велосипедам фреймворки..

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

>Ну опять же - задаёмся вопросом, а ЗАЧЕМ CMS будет делать ещё 100 дополнительных запросов? Если она делает потому, что "а почему бы и нет" - то ну её нах такую CMS. К счастью они вроде так бесцельно вроде не поступают.
Она делает это потому, что так получилось:) Например из-за кривоты архитектуры - из-за ориентации на мышевозительство некоторые строят ужасные и сложные системы подключения модулей. Вместо того, чтобы заимпортить модуль силами языка и зарегистрировать его одной функцией, система лезет в БД, делает кучу вычислений, подключает дополнительные файлы. А всё потому, что где-то заложена слишком большая универсальность. Специализированное решение часто бывает быстрее.

>А нельзя. Биясь головой об стенку ты можешь нанести себе вред, и как следствие ты нанесёшь вред обществу - ведь из полноценного работника ты превратишься в овоща с отбитыми мозгами, которого ещё и кормить надо из гуманизма. Так что общество скорее всего примет меры чтобы ты не смог нанести себе вред - закроет в камере с мягкими стенками, будет пытаться вылечить и вернуть в строй. Так же нужно поступать и с программистами на Руби, Перле и Лиспе.
А может человек полезнее в виде овоща с отбитыми мозгами, чем в виде полноценного работника? Работники бывают разные.

Обрати внимание, что Drupal проверяет не был ли алиас уже подгружен в $map[$path_language][$path] и обращается в базу только когда встретился новый алиас за время обработки запросов. Не знаю, как так можно спроектировать приложение, чтобы за время обработки единственного запроса требовалось бы отрезолвить несколько сотен алиасов.. Может это, конечно, что-то друпалоспецифичное, но не верится.

А вот фреймворк Yii, кстати, умеет кешировать запросы в БД.

> а cms это по сути готовый сайт,
Это "default behaviour" (см.в статье упомянутой выше)

> который теоретически чуть-чуть доводишь до ума и у тебя проект готов.
А это, наверное, "extensibility" (см.в статье упомянутой выше)

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

>Ну опять же - задаёмся вопросом, а ЗАЧЕМ CMS будет делать ещё 100 дополнительных запросов? Если она делает потому, что "а почему бы и нет" - то ну её нах такую CMS. К счастью они вроде так бесцельно вроде не поступают.
Это уж к разработчикам вопросы, найди хоть одну адекватную CMS, которая не делает по 100 запросов по каждой мелочи, что joomla, что drupal они такие мнстрообразные и есть, уж не говоря про некоторые отечественные CMS. )))

>Биясь головой об стенку ты можешь нанести себе вред, и как следствие ты нанесёшь вред обществу - ведь из полноценного работника ты превратишься в овоща с отбитыми мозгами, которого ещё и кормить надо из гуманизма. Так что общество скорее всего примет меры чтобы ты не смог нанести себе вред - закроет в камере с мягкими стенками, будет пытаться вылечить и вернуть в строй. Так же нужно поступать и с программистами на Руби, Перле и Лиспе.
А если я для себя делаю причем тут вообще общество? Пусть оно что хочет то и делает в соответствии со стадными инстинктами. А у нас особый путь. :)

> Ну да. Но одно дело написать "модуль" на фреймворке, который будет по сути одним классом, дёргающим БД и отдающим ответ, а другое - написать модуль для толстой CMS, которая в процессе его выполнения будет делать ещё 100 дополнительных запросов by-design.
Ну опять же - задаёмся вопросом, а ЗАЧЕМ CMS будет делать ещё 100 дополнительных запросов? Если она делает потому, что "а почему бы и нет" - то ну её нах такую CMS. К счастью они вроде так бесцельно вроде не поступают.

>> С таким же успехом можно и головой об стенку биться - почему бы и нет.
> Можно. Почему нет?:) Не хочешь - не изучай руби бейся головой
А нельзя. Биясь головой об стенку ты можешь нанести себе вред, и как следствие ты нанесёшь вред обществу - ведь из полноценного работника ты превратишься в овоща с отбитыми мозгами, которого ещё и кормить надо из гуманизма. Так что общество скорее всего примет меры чтобы ты не смог нанести себе вред - закроет в камере с мягкими стенками, будет пытаться вылечить и вернуть в строй. Так же нужно поступать и с программистами на Руби, Перле и Лиспе.

>Тормозят имхо модули. Ты их куда ни навешай перехватывать события - там они и будут тормозить.
Ну да. Но одно дело написать "модуль" на фреймворке, который будет по сути одним классом, дёргающим БД и отдающим ответ, а другое - написать модуль для толстой CMS, которая в процессе его выполнения будет делать ещё 100 дополнительных запросов by-design.

>С таким же успехом можно и головой об стенку биться - почему бы и нет.
Можно. Почему нет?:) Не хочешь - не изучай руби бейся головой.

> если хочется что-то свежее освоить
А если хочется что-то свежее освоить, то лучше задать себе вопрос "ЗАЧЕМ мне осваивать руби" и освоить что-нибудь другое, более полезное.

> Фреймворк, который не настолько низкоуровневый, чтобы мучаться, и не настолько высокоуровневый, чтобы тормозить.
Тормозят имхо модули. Ты их куда ни навешай перехватывать события - там они и будут тормозить.

> А почему бы и нет?
С таким же успехом можно и головой об стенку биться - почему бы и нет.

>Дык в чём оригинальность его идеи?
Фреймворк, который не настолько низкоуровневый, чтобы мучаться, и не настолько высокоуровневый, чтобы тормозить.

>Т.е. не я один такой, кому руби представляются сомнительным есыком :)
Мне тоже:)

>Но нас-то интересует вопрос о том, какое право на существование в современном мире имеет ещё один язык, такой как Руби. Чем он лучше? Почему кто-то стал бы терять время на его освоение, зачем?
А почему бы и нет?

> Ну идеи рождаются одновременно, но появление многих пхп-фреймворков точно связаны с появлением RoR-а. Например cakephp и symfony точно сделаны под влиянием RoR-а, про это даже в википедии написано.
Согласно Вики, "David Hansson first released Ruby on Rails as open source in July 2004". А слово "MVC" я слышал значительно раньше. Вот например первый релиз Drupal'а, исповедующего MVC, был в 2001. Но слово "MVC" я слышал и до Drupal'а.. И Не только в связи с пыхом. То, что кого-то там вдохновил RoR на создание cakephp и symfony говорит лишь о склонности создателей упомянутых фреймворков черпать вдохновение в чужих проектах, ну и о том, что RoR даже им не подёш и им пришлось делать свои велосипеды.

> Просто идея у RoR вполне приличная, а
Дык в чём оригинальность его идеи?

> писать на руби никто не хочет.
Т.е. не я один такой, кому руби представляются сомнительным есыком :)

> Тогда уж все фреймворки похожи. Но некоторые более похожи, чем другие.
Но нас-то интересует вопрос о том, какое право на существование в современном мире имеет ещё один язык, такой как Руби. Чем он лучше? Почему кто-то стал бы терять время на его освоение, зачем?

>В первые слышу о том, RoR свяк-то с этим связан
Ну идеи рождаются одновременно, но появление многих пхп-фреймворков точно связаны с появлением RoR-а. Например cakephp и symfony точно сделаны под влиянием RoR-а, про это даже в википедии написано. Просто идея у RoR вполне приличная, а писать на руби никто не хочет.

>Надо бы, кстати, заставить тюксоеда заюзать какой-нибудь фреймворк под сайт, кстати. По идее должно упростить поддержку и совместную разработку.
Надо просто найти того, кто это сделает, вряд ли Туксоид будет этим заниматься. В принципе можно и код лорнг привести в приличный вид, благо проект некрупный. Я, кстати, пробовал как-то поднять дома движок, чтобы потыкать, но отсутствие структуры БД меня остановило.

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

> как раз по мотивам RoR
В первые слышу о том, RoR свяк-то с этим связан

> Да что далеко ходить - исходники лор-нг, например, именно такие.
Ну оно и не позицируется как фреймворк. Надо бы, кстати, заставить тюксоеда заюзать какой-нибудь фреймворк под сайт, кстати. По идее должно упростить поддержку и совместную разработку.

> Ну почему, очень даже объективная:) Фреймворк можно сделать по-разному в рамках всех этих MVC. Например, вместо контроллеров в виде классов использовать функции
Так можно утверждать, что все фреймворки, задействующие объектно-ориентированные возможности языка, чем-то смахивают на руби..

>Это какая-то слишком субъективная оценка :)
Ну почему, очень даже объективная:) Фреймворк можно сделать по-разному в рамках всех этих MVC. Например, вместо контроллеров в виде классов использовать функции, как в django. Суть, правда, особо не меняется.

> общая внешняя похожесть.
Это какая-то слишком субъективная оценка :)

}

Нифига себе, на этих выражениях даже подсветку выносит нах.

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

> Сейчас Вилфред будет бешено негодовать. )))
Вилфред хитрый, он открыто не негодует, он берёт публику измором время от времени публикуя всякие перловые однострочники :-)

Что по этому поводу скажет стая?