Re: ruby on rails vs php фреймвоки

не пробегался

Re: ruby on rails vs php фреймвоки

Единственно что меня смущает в ROR так это то, что материалов мало, для php конечно наработано очень много. Но с другой стороны всем понятно, что php рано или поздно уйдет в историю как это уже благополучно случилось с perl. Сейчас Вилфред будет бешено негодовать. ))) Мне кажется php держится за счет массы всего, что к нему есть и того, что приходится не столько разрабатывать сколько поддерживать уже существующее. Понятно дело, что для серьезных разработок java, .net, а для менее серьезных ROR по-моему это перспектива.

Re: ruby on rails vs php фреймвоки

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

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

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

Re: ruby on rails vs php фреймвоки

Заглянул в вики:

}

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

Re: ruby on rails vs php фреймвоки

>ruby on rails vs php фреймвоки
>В общем пробежался бегло. Показалось более продвинутым что-ли, ну видно что писался сразу как ООП фреймвок для web-разработки, а не просто препроцессор гипертекста и подтянутые за уши к нему фреймвоки.
Так ты языки сравниваешь или фреймворки? На пхп есть ror-style фреймворки.

Re: ruby on rails vs php фреймвоки

А в чём специфика ROR-стиля?

Re: ruby on rails vs php фреймвоки

>На пхп есть ror-style фреймворки.
Ну да cakephp вроде один из них, самый вменяемый php-фреймворк кстати. :)

Re: ruby on rails vs php фреймвоки

Самые вменяемые, говорят, это kohana и yii :-)

Re: ruby on rails vs php фреймвоки

ruby - тормоз и гавно. Писать надо на Lisp.

Re: ruby on rails vs php фреймвоки

Можно посмотреть на примеры CMS-ок и фотогалерей сделанных на Lisp?

Re: ruby on rails vs php фреймвоки

>А в чём специфика ROR-стиля?
Всякие там MVC, классы-контроллеры и общая внешняя похожесть.

Re: ruby on rails vs php фреймвоки

> Всякие там MVC, классы-контроллеры
Да это у всех вроде бы есть

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

Re: ruby on rails vs php фреймвоки

>Да это у всех вроде бы есть
Да нет, массово MVC стали в пхп использовать относительно недавно - как раз по мотивам RoR. Даже сейчас полно кода, где html смешан с пхп и всё раскидано по проекту случайным образом. Да что далеко ходить - исходники лор-нг, например, именно такие.

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

Re: ruby on rails vs php фреймвоки

> массово MVC стали в пхп использовать относительно недавно
Ой, да давно уже меряются у кого фреймворк эмвэцовее..

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

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

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

Re: ruby on rails vs php фреймвоки

 http://www.core.gen.tr/#coretal

Re: ruby on rails vs php фреймвоки

Чевоэта? Пишет "Loading, please hold..." и ничего не происходит. Это на Лиспе сделано, да?

Re: ruby on rails vs php фреймвоки

Coretal Content Management System

Re: ruby on rails vs php фреймвоки

>Ой, да давно уже меряются у кого фреймворк эмвэцовее..
А вот понятия "давно" и "недавно" - уж точно субъективны:)

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

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

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

Re: ruby on rails vs php фреймвоки

> Coretal Content Management System
И?

Re: ruby on rails vs php фреймвоки

> А вот понятия "давно" и "недавно" - уж точно субъективны:)
Ну так :)

> Ну идеи рождаются одновременно, но появление многих пхп-фреймворков точно связаны с появлением 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 вполне приличная, а
Дык в чём оригинальность его идеи?

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

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

Re: ruby on rails vs php фреймвоки

CMS на CL, как ты и просил.

Re: ruby on rails vs php фреймвоки

Бугога, CMS на других языках обычно просто отдают контент, а не пишут вместо этого "Loading, please hold..."

Re: ruby on rails vs php фреймвоки

Да чего-то тормозит сайтик, нет все таки сайт на лиспе это из разряда "хочется странного". Да и какая ситуация с хостингами под CL, небось не найдешь? Кстати с ruby с хостингами нет проблем как я посмотрел уж не говоря про php/perl-хостинги.

Re: ruby on rails vs php фреймвоки

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

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

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

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

Re: ruby on rails vs php фреймвоки

>Я имел в виду скорее MVC-образные фреймворки, а не концепцию вообще. Вот фреймворков старше 2005-го на пхп я сходу и не вспомню, кроме zend-а. Но он какой-то не такой.
Действительно zend framework это что-то с чем-то, такой монстр - громоздкий, большой, медленный.

Re: ruby on rails vs php фреймвоки

> Я имел в виду скорее MVC-образные фреймворки, а не концепцию вообще. Вот фреймворков старше 2005-го на пхп я сходу и не вспомню, кроме zend-а. Но он какой-то не такой.
Drupal же например. Да и другие были.

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

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

Re: ruby on rails vs php фреймвоки

>С таким же успехом можно и головой об стенку биться - почему бы и нет.
Да нет, ну ни в какое сравнение. Вот perl или lisp это да головой об стенку. А ruby не такой уж страшный, я не знаток ruby пока, но мне он показался логичнее и красивее языка php, в общем просто почему бы и нет, если хочется что-то свежее освоить, нет если конечно не хочется и через не могу, то не надо, дело-то добровольное.

Re: ruby on rails vs php фреймвоки

В красивом языке ты можешь определить строку. В уродском языке ты можешь определить строку пятью-шестью разными способами.

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

Re: ruby on rails vs php фреймвоки

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

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

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

Re: ruby on rails vs php фреймвоки

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

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

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

Re: ruby on rails vs php фреймвоки

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

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

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

Re: ruby on rails vs php фреймвоки

>Ну опять же - задаёмся вопросом, а ЗАЧЕМ CMS будет делать ещё 100 дополнительных запросов?
Посмотри это же п*ц 311 запросов на одну страницу  http://www.drupal.ru/node/52027 , может он и сам там чего-то не того, но большое количество запросов для классических CMS это вообще обычное явление.

Re: ruby on rails vs php фреймвоки

> Как не одно и тоже если именно одно и то же, фреймворк это набор библиотек
 http://en.wikipedia.org/wiki/Software_framework - ищешь подстроку "key distinguishing features that separate them from normal libraries" и читаешь начиная с неё :-P

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

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

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

Re: ruby on rails vs php фреймвоки

> Посмотри это же п*ц 311 запросов на одну страницу  http://www.drupal.ru/node/52027 , может он и сам там чего-то не того, но большое количество запросов для классических CMS это вообще обычное явление.
А на рубях бы из астрала добывалась информация об алиасах?

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

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

Re: ruby on rails vs php фреймвоки

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

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

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

Re: ruby on rails vs php фреймвоки

> werkzeug
О! Вспомнил, что программистов на петоне тоже надо закрывать в камере с мягкими стенками и лечить. Забыл о них в предыдущем посте.

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

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

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

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

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

Re: ruby on rails vs php фреймвоки

>О! Вспомнил, что программистов на петоне тоже надо закрывать в камере с мягкими стенками и лечить. Забыл о них в предыдущем посте.
Именно, причем их - в первую очередь.

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

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

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

Re: ruby on rails vs php фреймвоки

> Там кроме WSGI сервера почти ничего своего нет.
Ну и зачем он нужен :)

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

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

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

Re: ruby on rails vs php фреймвоки

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

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

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

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