Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 387
Вообще конечно для домохозяек видимо прикольно...
Но вообще немного смешно, особенно первый ролик. RoR vs PHP :D
Вообще-то RoR - это фреймворк для языка Ruby, а PHP - язык программирования. Они еще и с Java себя сравнивают - это вообще жесть (с Oracle забыли)
И есть для PHP5 такая же фишка - Symfony. Только это все узкоспециализированные инструменты, а не "новая эра программирования"
Ну а вообще если сравнивать Ryby и PHP5 - это одного поля ягоды.
Вот вам нормальный разрабатываемый проект на PHP5 (MVC, Zend Framework, AJAX):
Так что не надо.
Но вообще немного смешно, особенно первый ролик. RoR vs PHP :D
Вообще-то RoR - это фреймворк для языка Ruby, а PHP - язык программирования. Они еще и с Java себя сравнивают - это вообще жесть (с Oracle забыли)
И есть для PHP5 такая же фишка - Symfony. Только это все узкоспециализированные инструменты, а не "новая эра программирования"
Ну а вообще если сравнивать Ryby и PHP5 - это одного поля ягоды.
Вот вам нормальный разрабатываемый проект на PHP5 (MVC, Zend Framework, AJAX):
Так что не надо.
Почему, очень даже ничего. Вобще-то нет плохих языков/инструментов, есть плохие порограмисты. Весь прикол в том, что RoR склоняет к правильной разработке. Programming should be fun. Естественно то-же самое можно написать на PHP, но сообщество разработчиков разрознено. Если в RoR очень многие улучьшаю то что уже создано, то в PHP изобретают велосипед. Достаточно посмотреть на PHPClasses.org
О буме PHP frameworks даже говорить не хочется.
Резюмирую: ИМХО смысл роликов не зафукать другие языки, а показать как можно програмировать если большая часть комьюнити работает в одном направлении.
О буме PHP frameworks даже говорить не хочется.
Резюмирую: ИМХО смысл роликов не зафукать другие языки, а показать как можно програмировать если большая часть комьюнити работает в одном направлении.
Ну сами ролики конечно прикольные...
Но опять же, хочется подчеркнуть, что PHP5 и Ruby - в общем одно и то же. И оба конечно рядом с Java не валялись (но это другая ниша).
В PHP-сообществе конечно слишком много шлака (в процентах от общего числа), но думаю серьезных PHP5-девелоперов (в численнм отношении) в разы больше, чем их коллег, использующих Ruby и тем более RoR.
Но опять же, хочется подчеркнуть, что PHP5 и Ruby - в общем одно и то же. И оба конечно рядом с Java не валялись (но это другая ниша).
В PHP-сообществе конечно слишком много шлака (в процентах от общего числа), но думаю серьезных PHP5-девелоперов (в численнм отношении) в разы больше, чем их коллег, использующих Ruby и тем более RoR.
> И оба конечно рядом с Java не валялись (но это другая ниша).
Сам на яве никогда не писал, но знаю как минимум 3-х веб-разработчиков, которые отказались от нее в пользу РоР. Говорят, ужасно неповоротливая штука. Вообще, было бы интересно почитать комментарии людей, которые писали и на Яве, и на Руби.
Сам на яве никогда не писал, но знаю как минимум 3-х веб-разработчиков, которые отказались от нее в пользу РоР. Говорят, ужасно неповоротливая штука. Вообще, было бы интересно почитать комментарии людей, которые писали и на Яве, и на Руби.
Ява - тяжелая артиллерия для крупных бюджетов. Если хочется быстро и без претензий - можно выбрать что-то еще.
зы: сейчас набегут явисты и скажут, что им лучше что угодно на ней писать (не буду с ними спорить:)
зы: сейчас набегут явисты и скажут, что им лучше что угодно на ней писать (не буду с ними спорить:)
"Ява - тяжелая артиллерия для крупных бюджетов"
Если хочется быстро уничтожить крупный бюджет...
Ява для веб разработки - как пушка по воробьях.
Если хочется быстро уничтожить крупный бюджет...
Ява для веб разработки - как пушка по воробьях.
веб вебу рознь. Попробуйте поработать в сильно крупном проекте - может быть поменяете мнение
Иногда конечно бывают совсем крупные проекты, но забавно, что вещи, которые на Java получаются уже весьма крупными проектами, на более высокоуровневых языках иногда остаются маленькими проектами. Хотя верно, что это может стать проблемой, если надо зохавать "крупный бюджет".
Каждая технология имеет свою нишу. Большие нагруженные проекты - ниша Java.
Гм. Мелкие проекты влёт пишутся на явских гибернейт + жабафейсы. Очень мало знаю про рельсы, но, вроде бы, это сравнимо. А вот с пхп вообще сравнивать невозможно.
Причем они ни чуть не тяжелее ПХП-шных.
Я не работал на рельсах, но делал проекты на Java и Python. Для мелких проектов я бы даже не стал Java рассматривать, оверхед не окупится. Для больших — другой разговор, хотя последнее время мне стало казаться, что раньше я недооценивал пределы Python'а.
Про PHP не знаю, я его пробовал лет 5 назад, до сих пор тошнит от любого упоминания. Может, конечно, я и не прав (вот с анти-JavaScript-овой болезнью я вроде успешно справился, теперь с удовольствием на нём пишу), но мне сама идеология не близка, кусочки кода, запиханные в страницы — это верный путь к свалке IMHO. Наверно если очень стараться и иметь светлую голову, можно этого избежать, но по мне языки, которые тебе помогают (в том числе и с архитектурой) лучше чем те, которые мешают.
Про PHP не знаю, я его пробовал лет 5 назад, до сих пор тошнит от любого упоминания. Может, конечно, я и не прав (вот с анти-JavaScript-овой болезнью я вроде успешно справился, теперь с удовольствием на нём пишу), но мне сама идеология не близка, кусочки кода, запиханные в страницы — это верный путь к свалке IMHO. Наверно если очень стараться и иметь светлую голову, можно этого избежать, но по мне языки, которые тебе помогают (в том числе и с архитектурой) лучше чем те, которые мешают.
пять лет назад всех тошнило от ООП-модели. Советую вам оценить, что же Zend нового привнесло в ядро. Ну и тамошний фрэймворк попробовать.
А что вас не устраивает в ООП 5-ой версии?
о чем речь? ядро переписано было. "приделать"
и итераторы в Руби шикарнее чем примитивные циклы. речь ведь о рельсах идет?
А оно надо - любую сущность объектом делать?
Но руби и по скорости проигрывает у PHP.
Java тоже проигрывает, но её популярности, ПОКА ЧТО, можно позавидовать
Вы вообще в курсе разработки веб-проектов на J2EE???
проигрывает php? хм... сравнивал в свое время два простеньких приложения на php и java с использованием LoadRunner. нифига. особых расхождений в performance не было. опыта сравнения больших приложений нет, но... представляю себе Lucene на PHP... страншый сон
До ООП там ещё далеко. Это кажеться признает всё РНР комьюнити. Но тем не менее все проекты пишуться с использованием ООП =)
Вы аргументировать можете? В каких местах там до ООП далеко? И вообще, когда кажется...
В таких местах. Попишите на нормальном ООП-языке вроде Smalltalk или С++, если у вас к Руби классовая ненависть.
опять без аргументов. очень конструктивный спор. а на С++ я писал. и Руби мне очень понравился.
Тогда как мне сделать конкатенацию строк в ПХП по оператору "+" вместо "."? Никак. ПХП не позволяет перегружать операторы даже у пользовательских типов, не то что у встроенных. О каком нормальном ООП тут может идти речь?
Не хочу сказать, что в ПХП хороший ООП, но не вижу связи между наличием ООП и перегрузкой операторов. В Питоне и Джаве нет перегрузки, но никто не отрицает, что там есть ООП.
Да как же это нет. Есть перегрузка и там, и там.
А, верно, извините, торможу. В Python'е-то есть конечно. А в Java где? Они ведь по-моему специально даже его там не сделали, так как считали что перегрузка в C++ — зло.
В любом случае я не очень понимаю связь между перегрузкой и ООП. Перегрузка — это же чисто синтаксическая вещь, к возможностям ООП она ничего не добавляет.
В любом случае я не очень понимаю связь между перегрузкой и ООП. Перегрузка — это же чисто синтаксическая вещь, к возможностям ООП она ничего не добавляет.
Да - если считать что операторы это какие-то особые синтаксические сущности.
Нет - если думать про операторы как просто про методы вызываемые у объектов (ну или сообщения отправляемые объектам - если использовать терминологию смалтолка).
Тогда видно, что отсутствие перегрузки это просто запрещение переопределять методы с некоторыми именами. Совершенно непонятное ограничение и немотивированное ограничение
Нет - если думать про операторы как просто про методы вызываемые у объектов (ну или сообщения отправляемые объектам - если использовать терминологию смалтолка).
Тогда видно, что отсутствие перегрузки это просто запрещение переопределять методы с некоторыми именами. Совершенно непонятное ограничение и немотивированное ограничение
Операторы — это особые синтаксические сущности. Кроме Лиспов что-то не припомню языков, где это не так. Иногда операторы заменяются вызовами методов в процессе обработки кода транслятором, но это не имеет значения, если мы говорим о синтаксисе.
Отсутствие перегрузки операторов — это отсутствие конвертации операторов в вызовы методов. Некоторые не реализуют перегрузку, чтобы язык был проще, другие реализуют, чтобы писать более красивые, с их точки зрения, программы. Обе точки зрения имеют право на существование.
Отсутствие перегрузки операторов — это отсутствие конвертации операторов в вызовы методов. Некоторые не реализуют перегрузку, чтобы язык был проще, другие реализуют, чтобы писать более красивые, с их точки зрения, программы. Обе точки зрения имеют право на существование.
Синтаксическая вещь? Здрасте приехали! А если ты применяешь оператор к объекту класс которого заранее.
...класс которго заранее не известен.
Синтаксис у операторов и вызовов методов разный, иначе говоря, с точки зрения синтаксиса это разные конструкции. То что одно в некоторых случаях превращается компилятором в другое к синтаксису отношения не имеет.
А известен класс или не известен — это к синтаксису не относится.
А известен класс или не известен — это к синтаксису не относится.
>В Питоне и Джаве нет перегрузки, но никто не отрицает, что там есть ООП.
Насколько я помню - Matz начал писать руби именно потому что ООП в питоне его не устраивало )
Насколько я помню - Matz начал писать руби именно потому что ООП в питоне его не устраивало )
Мне вообще не совсем понятно, как вы писали на С++ и Руби, если не чувствуете разницы между их ООП и ПХП-шным.
я не говорил что не чувствую разницы. не генерируйте предрассудки. я в курсе что ООП модель не идеальна, но хотел увидеть конкретный пример.
теперь понятно. но для каких задач вам нужно точку перегружать?
теперь понятно. но для каких задач вам нужно точку перегружать?
По моему говорить о поддержке ООП в языке можно только в том случае если ООП интегрированно в ядро языка. А не как у вас - пхп отдельно - ООП отдельно.
Вот скажите - какое отношение к объектам имеет в пхп строка ? а число ? А массив? А в рамках какого класса выполняется код который вы просто включите в
А теперь сравните в том-же аспекте яву и руби.
ООП это не там где пишут class MyClass - вас обманули. ООП гораздо глубже.
Да и то сказать - пхпперы даже и свою ООП модель не смогли реализовать прилично. Вот скажите - как в пхп узнать из статического метода - в каком из классов его вызвали ? Никак ? А это означает что половину применений одного из самых популярных паттернов - синглтона, придется делать через непонятное место.
Вот скажите - какое отношение к объектам имеет в пхп строка ? а число ? А массив? А в рамках какого класса выполняется код который вы просто включите в
А теперь сравните в том-же аспекте яву и руби.
ООП это не там где пишут class MyClass - вас обманули. ООП гораздо глубже.
Да и то сказать - пхпперы даже и свою ООП модель не смогли реализовать прилично. Вот скажите - как в пхп узнать из статического метода - в каком из классов его вызвали ? Никак ? А это означает что половину применений одного из самых популярных паттернов - синглтона, придется делать через непонятное место.
Если вы пишете в PHP - пишите согласно идеологии PHP, а не так как вы привыкли, например, на Си++. Если ООП в PHP чего-то не умеет, то либо это сделали специально, либо это еще сделают. Но никак не потому что, как Вы выразились, не смогли реализовать прилично.
Кстати, строке не обязательно быть объектом. Вы удивитесь, но Perl-программисты живут десяток лет и не страдают от этого ^_^
Кстати, строке не обязательно быть объектом. Вы удивитесь, но Perl-программисты живут десяток лет и не страдают от этого ^_^
"либо это еще сделают" - да я не спорю. Вот когда сделают, тогда и будем говорить что пхп поддерживает ООП.
Не забывайте - мы говорим о ООП. Перл - мягко говоря не идеал в этой области. Но ему-то простительно. Первая версия перл вышла в 87 году(а вы говорите десяток). Пятая версия появилась в 94 году. И к этому времени на шее перла висел тяжеленный камень обратной совместимости.
Первая же версия пхп вышла в 95 - когда уже были и ява и питон и руби только вышел и тот-же перл с какими-никакими, но классами.
Я уже не упоминаю о том, что в 97 пхп полностью переписали.
Не забывайте - мы говорим о ООП. Перл - мягко говоря не идеал в этой области. Но ему-то простительно. Первая версия перл вышла в 87 году(а вы говорите десяток). Пятая версия появилась в 94 году. И к этому времени на шее перла висел тяжеленный камень обратной совместимости.
Первая же версия пхп вышла в 95 - когда уже были и ява и питон и руби только вышел и тот-же перл с какими-никакими, но классами.
Я уже не упоминаю о том, что в 97 пхп полностью переписали.
debug_backtrace(); не то?
В 5.3 Версии костыль добавлен и теперь помимо parent:: и self:: у нас есть static:: , который относится к вызвавшему классу.
хабр ест любое упоминание пхпшных скобок )
в сове время писал на php немного. я так и не нашел полиморфизма. что-то изменилось с того времени?
Ого, какой флейм разгорелся!
Rev, спасибо за предложение, но мне сейчас как-то неинтересно смотреть, что же там нового привнёсло Zend. На работе у меня Python, иногда Java и это вряд-ли в ближайшее время изменится (так как мой начальник вообще PHP за язык не считает :), а для общего развития я лучше поучу Erlang, со стороны выглядит значительно интереснее.
Rev, спасибо за предложение, но мне сейчас как-то неинтересно смотреть, что же там нового привнёсло Zend. На работе у меня Python, иногда Java и это вряд-ли в ближайшее время изменится (так как мой начальник вообще PHP за язык не считает :), а для общего развития я лучше поучу Erlang, со стороны выглядит значительно интереснее.
Brainfuck посмотрите). Мне понравился)
Erlang — не эзотерический язык. Да, для того, чтобы на нём эффективно писать нужно больше мозгов, чем для ПХП (не минусуйте, ну правда ведь это так), но это следствие скорее мощности языка, чем его преднамеренной усложнённости.
Да, Scheme уже учил, пропёрся от языка безумно. Правда потом осознал почему он широко не используется — у среднего программиста не хватает мозгов, а значит масштабируемость технологии низкая, ну и все вытекающие...
Сейчас выбрал Erlang потому, что кажется, что в нём продвинутость функциональных языков совмещена с большой стандартной библиотекой и рантаймом, проверенными на реальных задачах.
Сейчас выбрал Erlang потому, что кажется, что в нём продвинутость функциональных языков совмещена с большой стандартной библиотекой и рантаймом, проверенными на реальных задачах.
Ваш выбор). Не стану орать и кричать что php круче всех, прям как фанатики RoR о своих рельсах)
Я сам скоро начну питон изучать). Правда для других целей - друзья нашли трехмерный движок на нем.
Я сам скоро начну питон изучать). Правда для других целей - друзья нашли трехмерный движок на нем.
На PHP уже давно никто не смешивает программный код с языком разметки, все как у людей - MVC, шаблоны... ^_^
Ну, если для вас веб-разработка - это гостевая книга и phpBB, то да. К счастью, бывают куда как более интересные проекты :).
У вас слишком поверхностное мнение (и наверное знание) о PHP.
Ну, как поверхностное...
Я понимаю, что даже стоя в гамаке можно заниматься весьма неожиданными вещами, даже не снимая при этом лыж... Но разве это повод? :)
Что касается знания-незнания...
А чего там в языке не знать? Он ведь весьма примитивен, хотя и достаточно сильно запутан в некоторых местах из за отсутсвия какой-бы то ни было концепции и логики. Развивается весьма экстенсивно, примерно как бейсик в своё время.
Вы на руби, даже без рельс хоть мельком смотрели? Посмотрите - и больше вам на этом уродстве пхп не захочется программировать :)
А так, я-то, в принципе, и на фортране-4 могу писать, в том числе и для веба, в том числе и большие проекты. Но существенно проще, быстрее, приятнее и дешевле делать это на чём-нибудь более приспособленном для этого :).
Я понимаю, что даже стоя в гамаке можно заниматься весьма неожиданными вещами, даже не снимая при этом лыж... Но разве это повод? :)
Что касается знания-незнания...
А чего там в языке не знать? Он ведь весьма примитивен, хотя и достаточно сильно запутан в некоторых местах из за отсутсвия какой-бы то ни было концепции и логики. Развивается весьма экстенсивно, примерно как бейсик в своё время.
Вы на руби, даже без рельс хоть мельком смотрели? Посмотрите - и больше вам на этом уродстве пхп не захочется программировать :)
А так, я-то, в принципе, и на фортране-4 могу писать, в том числе и для веба, в том числе и большие проекты. Но существенно проще, быстрее, приятнее и дешевле делать это на чём-нибудь более приспособленном для этого :).
Мы же о фреймворках говорим. Я просмотрел документацию Рельсов. Во многом возможности описанные там совпали с тем что уже доступно среди РНР фреймворков (Лично я испоьзую два фреймворка для разных проектов). Да, стиль "голого" РНР ужасный, но ведь есть и другие подходы. Возможно в чем-то Рельсы помощнее, но в общем суть фреймворков и там и там одинакова и там и там можно добиться красивого простого структурированого и эффективного кода.
С радостью перешел бы на Ruby, но пока мои проекты требуют именно РНР.
С радостью перешел бы на Ruby, но пока мои проекты требуют именно РНР.
+1. Люди опять сравнивают фрэймворк и язык программирования. Это очень глупо со стороны рельсоманов.
Насчет перехода, полностью согласен - у нас в Томске иногда хостер не может 5-ую версию MySQL поставить, а вы тут о Руби говорите.
Насчет перехода, полностью согласен - у нас в Томске иногда хостер не может 5-ую версию MySQL поставить, а вы тут о Руби говорите.
Я посмотрел. И на руби и на рельсу. Больше на этом уродстве лично мне программировать не хочется. Только уродством как раз руби оказался :)
О! Это интересно! Расскажите, пожалуйста, что вы там нашли уродливого. Особенно по сравнению с пхп? :) Правда интересно.
Да, кстати, вам, вероятно, будет полезно посмотреть ещё на бейсик. Желательно на старенький какой-нибудь, ещё с номерами строк. По сравнению с уродским руби вам наверняка понравится! :)
Да, кстати, вам, вероятно, будет полезно посмотреть ещё на бейсик. Желательно на старенький какой-нибудь, ещё с номерами строк. По сравнению с уродским руби вам наверняка понравится! :)
Я думаю не совсем вероное утверждение. Количество ничего не значит. Очень много моих знакомых перешли на RoR когда "уткнулись" в ограничения PHP. Для меня RoR следующая ступень эволюции. Опять таки если вязть соотношение серьезных девелоперов и начинающих в RoR, и сделать тоже самов в PHP перевес будет явно в сторону RoR. В основном r RoR'у приходят програмисты которые знают что и как они хотят писать, которые поняли глубину наших глубин. Но это не отменяет поулярность и распространенность PHP.
Make programming not holywar :)
Make programming not holywar :)
В целом мысль ясна, и не согласиться трудно.
Но думаю, если человек выжал все из PHP5 - ему прямая дорога в Java/C++. (Ну или C#, .NET если платформа/философия позволяет.)
Imho там больше красоты программирования, а бабла, респекта и карьеры там объективно больше (и намного:)
А изучать все технологии - жизни не хватит. Лучше например паттерны интересные пообкатывать.
Но думаю, если человек выжал все из PHP5 - ему прямая дорога в Java/C++. (Ну или C#, .NET если платформа/философия позволяет.)
Imho там больше красоты программирования, а бабла, респекта и карьеры там объективно больше (и намного:)
А изучать все технологии - жизни не хватит. Лучше например паттерны интересные пообкатывать.
CPAN - это не framework, поверьте
cpan — всего лишь барахолка перловых классов. Такой же есть и у php (PEAR).
Все равно суть от этого не меняется. Фрэймворк – это zend framework, ror, django, cakephp, symphony, webobjects, etc. А какой-то "велосипед" не даст мне возможности разрабатывать мое приложение быстрее и проще.
Другое дело – фрэймворк. В нем обычно реализована модель MVC, friendly-URL, работа с различными базами данных, есть наработки готовых классов и всегда можно посмотреть как надо писать код, чтобы он был удобным и читаемым (не всегда, конечно).
Другое дело – фрэймворк. В нем обычно реализована модель MVC, friendly-URL, работа с различными базами данных, есть наработки готовых классов и всегда можно посмотреть как надо писать код, чтобы он был удобным и читаемым (не всегда, конечно).
Поверьте/проверьте, для Perl это не так. Например, модули File::Find::* позволяют значительно сократить время и код для работы с файловой системой. И это только один из многих десятков полезнейших модулей на CPAN. Их там больше, просто там еще и узкоспециализированные есть.
Если работодатель берёт вас на проект в котором используется какой-то конкретный фреймворк, не важно, перловый или хоть пхп-шный, то странным было бы, как минимум, не поинтересоваться знаете ли вы этот фреймворк. А при широком предложении на рынке труда даже и потребовать - почему нет?
Django ничем не хуже касательно гибкости, тестов и прочего.
MVC - это фетиш. И ничего более :)
приехали. а все остальные дураки, да?
Какой-то у вас сложный ассоциативный ряд.
Ладно, черезчур экспрессивно выразился. Идем на Википедию и читаем про MVC. Осмысливаем прочитанное. Вспоминаем Smalltalk, MFC, .NET и все фреймворки, которые тут всплывали. И еще раз думаем, можно ли называть это просто фетишем (или очередным сиюминутным трендом, если я правильно уловил Вашу иронию).
Так пойдет?
Так пойдет?
Да я знаю, что такое MVC. Просто года три назад был себе обычный термин. Нынче все носятся, как дурень с писаной торбой - "Ах, MVC", "Ах, AJAX", "Ах, рельсы".
Пляшут не от задачи, а от средства и за технологиями конечного уже пользователя не видят.
Пляшут не от задачи, а от средства и за технологиями конечного уже пользователя не видят.
MVC - это не термин и не технология, это паттерн, по которому с незапамятных времен проектируются приложения. Просто на веб его догадались перенести только сейчас, и всем это жутко понравилось, потому что мешанины в коде стало в разы меньше. Если вы не понимаете, что MVC - это хорошо, то мне вас искренне жаль.
PS: Если уж говорить о конечных пользователях, то прикрутили бы на БОР-е AJAX-голосование. Народ ведь мучается.
PS: Если уж говорить о конечных пользователях, то прикрутили бы на БОР-е AJAX-голосование. Народ ведь мучается.
Я и не говорю, что MVC - это плохо. Да, это хорошо. Но икону то зачем делать из обычной, по сути, практики программирования?
Программированием БОРа и принятием решений по его развитию занимаюсь не я.
Программированием БОРа и принятием решений по его развитию занимаюсь не я.
Пока никакого аякс-голосования я прикручивать не буду.
Не знаю, кто там его догадался перенести только сейчас, нормальные люди давным давно всю обработку представления делали на шаблонах, а бизнес логику упаковывали в классы.
Это где же с MVC носятся как с писаной торбой? В среде пхп-шников? Ну, так с этим всё понятно - на этом языке персональных хомепейджей чтобы сколько-нибудь приличную реализацию мвц сделать надо хорошо подумать, а это пхп-шникам, видимо, было не очень свойственно. Поняли они это только сейчас, вот и носятся с мвц, как дурни с писаной торбой. Не первый раз встречаю в пхп-комьюнити замечания о том, что мвц стали широко обсуждать (в их среде) примерно с год. А весь остальной мир смотрит на эту возню удивлённо - термин, как термин, всем давно знаком (когда там книга банды четырёх вышла? когда явабинсы появились? не говоря уж о возрасте смолтока :) ).
офигеть.
давайте же код на страницы,
и без модели мы проживем!
даешь переменных две тыщи
и разделяемый код!
давайте же код на страницы,
и без модели мы проживем!
даешь переменных две тыщи
и разделяемый код!
Потом они уткнуться в ограничения РоР и вернутся на PHP :)
Кстати, во что именно они уткнулись?
Кстати, во что именно они уткнулись?
В первую очередь гибкость и ООП.
Например то что мне не хватает в PHP - namespaces, nested exceprions, operator overloading.
Это мелочи, можно обойтись без них, но с ними жизнь становится лучьше. Можно много чего перечислить. Можно сделать много возражений, но фак налицо - на данный момент Ruby как язык, культура и его комьюнити лучьше PHP.
А вот уткнутся в ограничение в РоРе это надо постаратся :)
Например то что мне не хватает в PHP - namespaces, nested exceprions, operator overloading.
Это мелочи, можно обойтись без них, но с ними жизнь становится лучьше. Можно много чего перечислить. Можно сделать много возражений, но фак налицо - на данный момент Ruby как язык, культура и его комьюнити лучьше PHP.
А вот уткнутся в ограничение в РоРе это надо постаратся :)
Опечатка по фрейду - "фак на лицо". Прошу прощения :)
И в каком web приложении понадобились namespaces и так далее?
Подозреваю, что в большом :))))
Да в любых :) Все что может упростить тебе жизь может быть использовано. Подключая калссы я не задумываюсь о соглашении имен. У меня не вывалится ошибка о том что метод уже определен. Я точно знаю какой метод вызвать. Я могу перекрывать типовые операции для достижения наибольшей эфективности. Просто ради интереса посмотрите движок для блогов mephisto. Его код говорит сам за себя
Namespaces действительно очень нужны, сильно уж они помогают в изоляции кода. В PHP пока два способа изоляции - четкая структура проекта (проверять, чтобы инклудились нужные файлы в нужном порядке и т.д.) и использование статических членов классов, то есть классы играют роль namespace.
а-а-а. только не мой моск. вы кроме homepage что-то писали?
Ну вот Twitter наткнулись на ограничения RoR. Если не читали, то здесь: http://www.codinghorror.com/blog/archive…
вы оооочень сильно ошибаетесь. php5 невероятно далеко от Ruby. И от Python, например.
А мне говорили, что Паскаль склоняет к правильной разработке, а потом тоже самое про Яву, и тем не менее найдутся те, про чей код на любом языке можно будет сказать WTF.
Конечно, все прекрасно понимают, что RoR - это фреймворк. Но сравнение RoR и PHP вполне уместно, т.к. PHP изначально разрабатывался (и применяется сейчас) для одной цели: быстро плеваться HTMLем с веб-сервера. Ребята, которые пытаются использовать его как general-purpose language, вызывают у меня удивление как минимум.
Даже если проводить сравнение Ruby и PHP (путь даже пятой версии, хехе), то оно будет явно не в пользу последнего. Систематический подход к языку, который есть в Руби, в ПХП начисто отсутствует. С самой первой версии он тащит за собой все эти промахи в дизайне, и ПХП-программисты имеют то, что имеют. Они используют точку для конкатенации строк только потому, что их язык не предоставляет возможности перегрузить оператор + у строки (т.к. она даже не является классом). И, как следствие, методы вызываются через эту идиотскую стрелочку. Объектная модель ПХП5 - это костыль. Плюс в ПХП нет (и в ближайшее время не планируется, судя по всему) элементарных closures. А про такие тонкости, как метапрограммирование и BDD я уже вообще молчу. Попробуйте реализовать синтаксис RSpec на PHP. Так что не надо говорить, что эти языки одного поля ягоды. Разница огромная.
Symfony - клон RoR на PHP, причем убогий (как следствие убогости самого языка). И если Вы его используете, то это значит, что пора переходить на Ruby. Потратьте один выходной на знакомство и, я уверен, Вам понравится :).
Даже если проводить сравнение Ruby и PHP (путь даже пятой версии, хехе), то оно будет явно не в пользу последнего. Систематический подход к языку, который есть в Руби, в ПХП начисто отсутствует. С самой первой версии он тащит за собой все эти промахи в дизайне, и ПХП-программисты имеют то, что имеют. Они используют точку для конкатенации строк только потому, что их язык не предоставляет возможности перегрузить оператор + у строки (т.к. она даже не является классом). И, как следствие, методы вызываются через эту идиотскую стрелочку. Объектная модель ПХП5 - это костыль. Плюс в ПХП нет (и в ближайшее время не планируется, судя по всему) элементарных closures. А про такие тонкости, как метапрограммирование и BDD я уже вообще молчу. Попробуйте реализовать синтаксис RSpec на PHP. Так что не надо говорить, что эти языки одного поля ягоды. Разница огромная.
Symfony - клон RoR на PHP, причем убогий (как следствие убогости самого языка). И если Вы его используете, то это значит, что пора переходить на Ruby. Потратьте один выходной на знакомство и, я уверен, Вам понравится :).
Спасибо, я уже перешел на C++, PHP5 остался для быстромаленьких ненагруженных web-сервисов.
Еще упускается из виду вся сопутствующая инфраструктура. Просто изучить синтаксис нового языка - это день, но в целом переход на новую технологию - многие месяцы, бессонные ночи, битые сроки и куча нервов.
Еще упускается из виду вся сопутствующая инфраструктура. Просто изучить синтаксис нового языка - это день, но в целом переход на новую технологию - многие месяцы, бессонные ночи, битые сроки и куча нервов.
Да, Вы конечно правы. Просто я считаю, что чем больше языков знает программист, тем лучше. Более широкий кругозор предлагает больший ассортимент решений для конкретной задачи. Умные люди советуют изучать как минимум по одному языку в год ;)
Да, согласен.
Но думаю полезно изучать языки именно для разных задач, например
1) Js - скриптовой язык для клиентской стороны web
2) PHP5, Ruby, Python, Perl - легкие скриптовые языки серверов/общих задач
3) C++, Java - тяжелые сильно типизированные высокопроизводительные языки серверов/общих задач
По одному из категории думаю хватит :)
Не могу придумать объективную причину, по которой стоило бы мешать в одном проекте Perl и Python или PHP и Ruby например
Но думаю полезно изучать языки именно для разных задач, например
1) Js - скриптовой язык для клиентской стороны web
2) PHP5, Ruby, Python, Perl - легкие скриптовые языки серверов/общих задач
3) C++, Java - тяжелые сильно типизированные высокопроизводительные языки серверов/общих задач
По одному из категории думаю хватит :)
Не могу придумать объективную причину, по которой стоило бы мешать в одном проекте Perl и Python или PHP и Ruby например
>Спасибо, я уже перешел на C++
Веб-программинг на Ц++ ??? Ахренеть!
Или вы не вебовские дела программили на пхп??? Ещё больше ахренеть!
Веб-программинг на Ц++ ??? Ахренеть!
Или вы не вебовские дела программили на пхп??? Ещё больше ахренеть!
C++, веб. Не надо хренеть, это же не ассемблер :)
непонятен смысл этого действа.
Да и процесс. CGI? Вообще глупо. Свой веб-контейнер? Гм... Гвозди бы делать из этих людей :)
Да и процесс. CGI? Вообще глупо. Свой веб-контейнер? Гм... Гвозди бы делать из этих людей :)
Зачем так категорично? Я уверен, 
AirWorker не CMS и не форум на C++ пишет :). Там где производительность критична, FastCGI-процесс на С/С++ - самое то. Я одно время поддерживал такую штуку (кишки веб-счетчика), хотя ту работу добрым словом никогда не вспоминал.
AirWorker не CMS и не форум на C++ пишет :). Там где производительность критична, FastCGI-процесс на С/С++ - самое то. Я одно время поддерживал такую штуку (кишки веб-счетчика), хотя ту работу добрым словом никогда не вспоминал.А вот угадайте, на каком языке написан поиск у Яндекса например :)
Судя по их листу вакансий - на С++.
Ну, если AirWorker работает в яндексе, то я всё понял. Но сколько других проектов подобного масштаба вы знаете? :)
Ну, если AirWorker работает в яндексе, то я всё понял. Но сколько других проектов подобного масштаба вы знаете? :)
Да, C++. Проектов таких, пожалуй, и правда немного, но зато какие это проекты! :)
Я знаю, что у поисковика webalta.ru свой виртуальный веб-сервер, написан на C++. Это не извращение, я ради интереса писал когда-то web-приложение на C++, вполне сносно. Согласен по трудозатратам быстрее на интерпретируемом языке.
навсякий случай скажу что к Яндексу я никакого отношения не имею...
вообще-то все и начиналось у ms с isapi. на C++.
жаль не могу плюсануть.
К 5й версии PHP стал вполне себе general-purpose, не уступающим ни Перлу, ни Руби, ни Питону.
Какой знак использовать для конкатенации строк - дело десятое.
Про closures, BDD и прочие умные слова спорить не буду, не применяю.
А вот один хороший аргумент за PHP - по скорости RoR ему безбожно сливает.
Какой знак использовать для конкатенации строк - дело десятое.
Про closures, BDD и прочие умные слова спорить не буду, не применяю.
А вот один хороший аргумент за PHP - по скорости RoR ему безбожно сливает.
1) Точку используют для конкатенации по совсем другой причине. Это другой, отличный от плюса оператор. 2 . 2 != 2 + 2.
2) Перегрузку операторов - если так уж хочется - в ПХП тоже можно использовать: http://pecl.php.net/package/operator
3) Руби в плане операторов тоже не слишком систематичен. Добавить число к числу - +=, добавить строку к строке- += ИЛИ <<. Последнее мало того, что выпадает из стандартного для операторов присваивания синтаксиса, так еще и работает контринтуитивно.
4) "Объектная модель ПХП5 - это костыль" - а что КОНКРЕТНО хромает в реализации обьектности в ПХП5 ?
p.s. Я тоже считаю ПХП убогим языком с кучей архитектурных косяков. Но критика должна быть обьективной.
2) Перегрузку операторов - если так уж хочется - в ПХП тоже можно использовать: http://pecl.php.net/package/operator
3) Руби в плане операторов тоже не слишком систематичен. Добавить число к числу - +=, добавить строку к строке- += ИЛИ <<. Последнее мало того, что выпадает из стандартного для операторов присваивания синтаксиса, так еще и работает контринтуитивно.
4) "Объектная модель ПХП5 - это костыль" - а что КОНКРЕТНО хромает в реализации обьектности в ПХП5 ?
p.s. Я тоже считаю ПХП убогим языком с кучей архитектурных косяков. Но критика должна быть обьективной.
3) А разобраться сначала? += для строк создает новую строку, старые убираются сборкой мусора.
Блин. Хабр съел << - модифицирует существующую строку.
А вообще ПХП - это набор знаков препинания, разделенных словами. Откиньтесь на спинку кресла и взгляните на код ПХП. Разве я не прав?
А вообще ПХП - это набор знаков препинания, разделенных словами. Откиньтесь на спинку кресла и взгляните на код ПХП. Разве я не прав?
"ПХП - это набор знаков препинания, разделенных словами" - для европейцев естественно использовать пунктуацию для структурирования текста. Руби с его "end" вместо "}" выглядит так же неуместно, как если бы вместо точки в конце предложения принято было писать точка
Правы, но то же самое можно сказать про любой язык программирования ^_^ У PHP практичный, очень простой синтаксис.
Знакомый Java-программист, когда впервые столкнулся с Perl, воскликнул: "Да это же набор символов!" ^_^
Знакомый Java-программист, когда впервые столкнулся с Perl, воскликнул: "Да это же набор символов!" ^_^
набор тезисов:
php - невероятная дрянь
zend framework - невероятная дрянь
на php5 можно писать хорошие вещи. но от этого он не перестает быть дрянью.
RoR это фреймворк, да. Сравнивать надо с Symfony, да. Так вот - Symfony штука хорошая. Но из-за того, что она на PHP - получается опять дрянь.
php - невероятная дрянь
zend framework - невероятная дрянь
на php5 можно писать хорошие вещи. но от этого он не перестает быть дрянью.
RoR это фреймворк, да. Сравнивать надо с Symfony, да. Так вот - Symfony штука хорошая. Но из-за того, что она на PHP - получается опять дрянь.
Вполне логичное замечание о некорректном сравнении. Кстати говоря, фреймворки, о которых здесь упомяналось (Symfony, Cakephp, PHP on rails) брали в свою основу идеи RoR и вполне успешно (конечно, точную копию создать сложно :) с этим справились.
А разве не это говорит о возможностях PHP? Ведь эти проекты появились как грибы после дождя, подхватив хорошую идею. Что уж тут говорить о CakePHP, который умудрился создать аналог RoR на PHP4!
А разве не это говорит о возможностях PHP? Ведь эти проекты появились как грибы после дождя, подхватив хорошую идею. Что уж тут говорить о CakePHP, который умудрился создать аналог RoR на PHP4!
RoR - это отличное пособие для изучение современного ООП, паттернов проектирования и многих других полезных вещей. Даже если вы не пишите на Ruby (как я, например), RoR все равно обязателен для ознакомления.
1. сравнивают языки (PHP,Java) с надстройками на них (RoR это надстройка над Ruby)
2. к большому сожалению миграции даже идеологически не нацелены на upgrade/downgrade моделей, а лишь на _внутреннюю_ часть этих моделей, а именно на структуру таблиц.
в продолжение к пункту 2. :
3. не пора ли задуматься откуда в RoR вся эта болезненная борьба за DRY ?
4. кто нибудь уже видел, что их ролики говорят про вражеские *надстройки*, например питоновские?
но, сказав все это, подчеркнем, что все же пока RoR — лучший фреймворк для прототипирования DB-driven web app.
2. к большому сожалению миграции даже идеологически не нацелены на upgrade/downgrade моделей, а лишь на _внутреннюю_ часть этих моделей, а именно на структуру таблиц.
в продолжение к пункту 2. :
3. не пора ли задуматься откуда в RoR вся эта болезненная борьба за DRY ?
4. кто нибудь уже видел, что их ролики говорят про вражеские *надстройки*, например питоновские?
но, сказав все это, подчеркнем, что все же пока RoR — лучший фреймворк для прототипирования DB-driven web app.
1. PHP и Java — это _языки_, а RoR — это надстройка над языком. об этом кстати уже писали выше. и тут сравнивая, как вы сами правильно заметили, "Не нужно смешивать валенки с котлетами."
2. таблицы — это часть модели. ныне — самая, заметим, неудобная её часть. ибо очень плохо синхронизируется с контролем версий. миграции несколько улучшают ситуацию но до конца выесть эту плошку так никому толком и не удаётся.
3. в контексте migration и моделей? — это очевидно, если вы пробовали RoR миграции. всё что вы пишете в миграциях вам приходится дописывать в моделях, где нумерация схемы базы больше не работает как в файлах-миграциях. и вам приходится думать о том, как привязывать схемы базы к версиям модели. и наоборот, то что вы допишете в моделях вам придется докручивать в миграциях. типичный пример — ассоциации (belongs_to, has_many, & etc). сегодня им идеологически нет места в миграциях, а народ их туда всё равно пропихивает — пока только при миграции данных, "потому что так удобно" :)
мой 3. пункт немного сумбурен, но прецедент, надеюсь виден. лучше тут суть выразит тот, кто давно "рубит".
2. таблицы — это часть модели. ныне — самая, заметим, неудобная её часть. ибо очень плохо синхронизируется с контролем версий. миграции несколько улучшают ситуацию но до конца выесть эту плошку так никому толком и не удаётся.
3. в контексте migration и моделей? — это очевидно, если вы пробовали RoR миграции. всё что вы пишете в миграциях вам приходится дописывать в моделях, где нумерация схемы базы больше не работает как в файлах-миграциях. и вам приходится думать о том, как привязывать схемы базы к версиям модели. и наоборот, то что вы допишете в моделях вам придется докручивать в миграциях. типичный пример — ассоциации (belongs_to, has_many, & etc). сегодня им идеологически нет места в миграциях, а народ их туда всё равно пропихивает — пока только при миграции данных, "потому что так удобно" :)
мой 3. пункт немного сумбурен, но прецедент, надеюсь виден. лучше тут суть выразит тот, кто давно "рубит".
"Задача миграции — поддерживать базу данных в том состоянии, в котором от неё ожидает модель."
нахожу ваше определение более удачным/точным, чем то, которое дает RoR-комьюнити.
"Насчет ассоциаций, не совсем понятно откуда в миграции берутся ассоциации?"
сегодня — это вроде табу. но берутся же.
"Если вы о том, что rails должны автоматом обрабатывать в моделях ассоциации"
я о том, что заговорив о "belongs_to", "has_many" они (т.е. RoR) уже неявно вызвались вводить DB-ассоциации в языковую надстройку. но де факто выдержать планку (на мой убежденный взгляд) не смогли. Magic Models тоже ведь не зря появился.
«У вас изменилась ассоциация с habtm на hmt? Сделайте руками migration, который приведет базу в ожидаемое моделью состояние и почистит хвосты.»
Я правильно мысль уловил? :)
да. и действительно, а почему бы и нет?
ведь всё крутится вокруг инкрементальности и тут либо надо делать ставку на migration, либо на svn, либо на нечто что уровнем выше объединит эти два рукова в одну одежку, но последнего пока не существует.
впрочем, у вас должно быть опыта значительно больше. и пока не вижу что мы что-то приобретем из этого интересного, но бесполезного разговора. пожалуй самое лучшее финиширование этой ветки — это зафрендить вас, как толкового спеца по руби.
нахожу ваше определение более удачным/точным, чем то, которое дает RoR-комьюнити.
"Насчет ассоциаций, не совсем понятно откуда в миграции берутся ассоциации?"
сегодня — это вроде табу. но берутся же.
"Если вы о том, что rails должны автоматом обрабатывать в моделях ассоциации"
я о том, что заговорив о "belongs_to", "has_many" они (т.е. RoR) уже неявно вызвались вводить DB-ассоциации в языковую надстройку. но де факто выдержать планку (на мой убежденный взгляд) не смогли. Magic Models тоже ведь не зря появился.
«У вас изменилась ассоциация с habtm на hmt? Сделайте руками migration, который приведет базу в ожидаемое моделью состояние и почистит хвосты.»
Я правильно мысль уловил? :)
да. и действительно, а почему бы и нет?
ведь всё крутится вокруг инкрементальности и тут либо надо делать ставку на migration, либо на svn, либо на нечто что уровнем выше объединит эти два рукова в одну одежку, но последнего пока не существует.
впрочем, у вас должно быть опыта значительно больше. и пока не вижу что мы что-то приобретем из этого интересного, но бесполезного разговора. пожалуй самое лучшее финиширование этой ветки — это зафрендить вас, как толкового спеца по руби.
2-3: Миграция коммитится в репозиторий вместе с изменениями модели, по-другому никак (иначе у других разработчиков после апдейта все сломается). Соответственно, любой changeset всегда дает модели и актуальный набор миграций для них.
Кроме того, для рельсовых миграций существует ряд плагинов, которые вроде бы даже с ассоциациями разбираются. Хотя на мой взгляд, это дело вкуса.
Кроме того, для рельсовых миграций существует ряд плагинов, которые вроде бы даже с ассоциациями разбираются. Хотя на мой взгляд, это дело вкуса.
вот тут ещё пара моих центов о том, куда можно бы расти RoR'у.
Для прототипирования да. Вот для реальной работы - все горааааааааздо хуже. Начиная с интеграции с Apache.
кст, а что именно в апачи плохо соединяется с RoR? — тут конечно интересует лишь из того, чего нет в lighttpd и прочих легковесных альтернативах
В чем? Я пока не сталкивался с проблемами интеграции
Осталось сравнить количество модулей к Апачу и mongrel+nginx вместе взятым.
Вы забыли один аспект, в котором PHP заруливает RoR по всем пунктам. Что это? Правильно, хостинг! Сколько провайдеров предоставляют хостинг на РНР? А сколько на RoR? Чтобы нормально ставить Ruby нужно брать как минимум виртуальный хостинг и самому всё настраивать. А что, если, у клиента есть свой хостинг и свой хостер который поставил ему только РНР?
Можно долго вести холиворы, но если заказчику нужен быстрый эффективный сайт - он вряд ли согласится платить за Ruby-хостинг. PHP легче в deployment'е, особенно у нас. А насчет фреймворков - полностью согласен, в РНР нету стандарта. В своей работе я использую Seagull и Symfony и более менее удоволетворен ими. Но всё время сталкиваюсь с тем, что встречаешь отличную реализацию, которую хотелось бы добавить в проект, а потом неделю тратишь на интеграцию.
ЗЫ: А про Python-on-Django кто-то что-то скажет?
Можно долго вести холиворы, но если заказчику нужен быстрый эффективный сайт - он вряд ли согласится платить за Ruby-хостинг. PHP легче в deployment'е, особенно у нас. А насчет фреймворков - полностью согласен, в РНР нету стандарта. В своей работе я использую Seagull и Symfony и более менее удоволетворен ими. Но всё время сталкиваюсь с тем, что встречаешь отличную реализацию, которую хотелось бы добавить в проект, а потом неделю тратишь на интеграцию.
ЗЫ: А про Python-on-Django кто-то что-то скажет?
Перешел с PHP на Django. Безумно доволен. RoR не стал трогать, потому что уже был опыт работы на Python'e. Может чуть позже посмотрю :)
Да, вот я как раз в комменте выше упоминал сложность миграции на другую инфраструктуру. Хостинг туда тоже входит.
А насчет фреймворков и стандарта в PHP - он есть. Это Zend Framework. Возможно, о нем еще мало знают, но скоро узнают.
А насчет фреймворков и стандарта в PHP - он есть. Это Zend Framework. Возможно, о нем еще мало знают, но скоро узнают.
Занют он нем, знают. И трубят на всех углах. Но ИМХО не сможет он стать стандартом дефакто. Просто политика сделай сам, пекл, пир итд не могут спостобствовать введение "едного" фреймворка. У пхп комьюнити ярко выраженый синдром Not Invented By Us/Not Invented Here. Плюс отстутсвие "политики партии" не приведет к устойчивом доминированию одного фрейморка. А это очень хорошо сказалось как на развитии языка вцелом так и на повышении качественного уровня среднестатистического пхп програмиста
Да, но только ZF пока сложно назвать фреймворком. Пока это набор библиотек на все случаи жизни.
Не скоро. По инсайдерской информации ZF в полной готовности будут выкатывать к релизу PHP6. А пока так, обкатывают идеи.
На нем уже крутится много хороших серверов.
Неправда. Такие гиганты как BlueHost и Dreamhost давно предоставляют хостинг RoR. Да на рыке есть некоторый недостаток в хостингах для RoR, но чтоб заруливал по всем пунктам? Сумневаюсь. Количество хостингов соответствует спросу. На РоР он не большой, но они есть. Буде больший спрос будут и хостинги, я в этом не сомневаюсь. Я еще не слышал чтоб была проблема нейти хороший РоР хостинг ....
Хостинг под руби есть. Как у нас, так и на Западе. Цены от ПХП отличаются на 10-ок баксов, либо не отличаются вовсе. Shared-хостинга на том же site5.com вполне хватит, чтобы держать чье-нибудь "интернет-представительство" на РоР с посещаемостью < 1000 уников в сутки.
В более крупных проектах (уровня того же Хабра, например) хостинг роли не играет, т.к. в любом случае приходится покупать дедики и настраивать все вручную.
В более крупных проектах (уровня того же Хабра, например) хостинг роли не играет, т.к. в любом случае приходится покупать дедики и настраивать все вручную.
А почему и Seagull и Symfony? В обоих чего-то не хватает?
Конечно :). Просто у них разные возможности. Я бы сказал так: первый для разработки комплексных веб-сайтов, а второй для веб-приложений. Просто Seagull наряду с фреймворком предлгает довольно мощную CMS, модули навигации, комментариев и пр. Симфония обходится без этого, но она мне намного нравится в ORM-подходе и в Ajax'е.
хех, было бы инетересно посмотреть такой же клипец ROR Vs Python + Django
ага, или RoR vs Symfony :)
У меня такое ощущение, что такой клип могут сделать фаны именно Django, потому что чисто субъективно - у Django прозрачнее идеология подстать идеалогии самого Python - "Simple is better than complex. Complex is better than complicated". Посему Django практичнее.
Извините, если это напоминает заявку на холивар.
Извините, если это напоминает заявку на холивар.
Можно почитать статистику текстом:) http://wiki.rubyonrails.com/rails/pages/…
Интерпретатор медленный, спору нет, но все гуру в голос твердят, что выч. мощности окупаются дешевизной и скоростью разработки. Плюс кеширование в помощь. Короче, как всегда все решает прямота рук разработчиков.
я про скорость побоялся говорить...
А насчет дешевизны - смотря с чем сравнивать...
А насчет дешевизны - смотря с чем сравнивать...
Ну, в идеальном варианте должно быть так :). Хотя я пока в своей практике с этим не сталкивался: программисты стоят дороже, ресурсов нужно больше. Скорость разработки конечно выше, но не настолько, чтобы компенсировать эти затраты.
Мне кажется, сейчас заказчики в основном переплачивают за более высокое качество кода, которые выдают команды на РоР, плюс за удобный обоим сторонам agile процесс разработки. Ну и за модный бренд, само собой :).
Мне кажется, сейчас заказчики в основном переплачивают за более высокое качество кода, которые выдают команды на РоР, плюс за удобный обоим сторонам agile процесс разработки. Ну и за модный бренд, само собой :).
Плохо у него все.
Некий проектик с 50к посетителей в сутки пробовали с PHP перевести на RoR (рор версию писал вполне себе профессионал). Сервер просто сдох, вернули обратно.
Некий проектик с 50к посетителей в сутки пробовали с PHP перевести на RoR (рор версию писал вполне себе профессионал). Сервер просто сдох, вернули обратно.
Не так все плохо как вы описываете. Я бы назвал скорость RoR неудовлетворительно. Это значит что сам по себе это не самый шустрый зверь. Но при правильной компоновке он ничем не уступает аналогам. Например использование встроеного в RoR кеширования.
подойдет )
и для 100-500к подойдет
для 99% веб-приложений подойдет или нет вопрос не только и даже не столько фреймворка сколько аппаратной части
и для 100-500к подойдет
для 99% веб-приложений подойдет или нет вопрос не только и даже не столько фреймворка сколько аппаратной части
если тебе нужен реальный опыт то странны твои речи о "10-50к уников в сутки"
ты же сам понимаешь что важна не средняя нагрузка, а пиковая. да и "просмотр страницы" понятия очень растяжимое. это может быть скачка файла или просмотр галереи фоток или отчет с непростой логикой, а может быть страничка из 5 запросов
ты же сам понимаешь что важна не средняя нагрузка, а пиковая. да и "просмотр страницы" понятия очень растяжимое. это может быть скачка файла или просмотр галереи фоток или отчет с непростой логикой, а может быть страничка из 5 запросов
А если в PHP использовать кеширование - РоР вообще близко не подойдет :)
У меня от РоР впечатление "средство разработки, но не работы".
У меня от РоР впечатление "средство разработки, но не работы".
а там пробовали руби-код перегонять потом в с++?
спрашиваю чисто из любопытства, т.к. руби-разрабы утверждают что это спасение от медлительности
спрашиваю чисто из любопытства, т.к. руби-разрабы утверждают что это спасение от медлительности
А зачем писать на Руби, если перегонять в C++? Извращение какое то.
Вернули на PHP, работает как и работал.
Новая версия тоже на PHP пишется.
Вернули на PHP, работает как и работал.
Новая версия тоже на PHP пишется.
почему извращение? С начала решаем задачу на руби, что без сомнения проще чем решить её на С, а затем перегоняем результат в С. В самом руби есть средства для перегонки своего кода в С код. Вот пример:
require 'rubygems'
require 'inline'
module Math
inline do |builder|
builder.c "
long fib (long n) {
long x = 0, y = 1, i, temp;
for (i=2; i < n; i++) {
temp = y; y = x + temp; x = temp;
}
return y;
}"
end
end
require 'rubygems'
require 'inline'
module Math
inline do |builder|
builder.c "
long fib (long n) {
long x = 0, y = 1, i, temp;
for (i=2; i < n; i++) {
temp = y; y = x + temp; x = temp;
}
return y;
}"
end
end
Только я это замечаю или действительно в плохом свете PHP-разработчиков хотят выставить только сторонники языка Ruby? Почему-то не видел такой, с позволения сказать, агресивности от Python- и Perl-программистов.
PHP - практичный язык. Субъектив: минусов у него больше, чем плюсов, особенно если сравнивать с другими скриптовыми языками. Но это инструмент, который позволяет делать дело. Дешево и сердито.
PHP - практичный язык. Субъектив: минусов у него больше, чем плюсов, особенно если сравнивать с другими скриптовыми языками. Но это инструмент, который позволяет делать дело. Дешево и сердито.
Это чистой воды стеб, такой же как и PC(WIndows) vs Mac. Идея не в том что пхп говно а руби крут как якут. Идея в том что можно делать луьше/проще/быстрее/удобней. Такая "антиреклама" может подстегнуть кого-то сдлеать лучьше в PHP/Java/Python ......
плюсанул бы.
Кстати, так называемый "индийский код" может быть написан на любом языке. Язык PHP не провоцирует писать некачественный код, потому что качество кода зависит только от практических навыков и/или таланта программиста - так всегда было и так всегда будет. На Pascal хороший программист напишет хороший (и красивый) код, плохой программист - плохой код. То же самое и на PHP, Perl, Java и Basic.
Да, Ruby и Python склоняют к написанию правильного кода и я на данном этапе своего развития мало себе представляю, как например, можно на Python написать совсем уж кривой код. Но это ни в коем случае не повод писать про PHP-программистов так, как пишете про них Вы. Профессионал всегда найдет для себя достойную работу, даже если он пишет на PHP.
PS: Я одинаково много (и, смею надеяться, хорошо) пишу на Perl, PHP и Python. Осваивал эти языки именно в таком порядке. Я крайне не согласен с Вами в том, что PHP прививает какое-то либо кривописание или какое-либо особое мышление.
Да, Ruby и Python склоняют к написанию правильного кода и я на данном этапе своего развития мало себе представляю, как например, можно на Python написать совсем уж кривой код. Но это ни в коем случае не повод писать про PHP-программистов так, как пишете про них Вы. Профессионал всегда найдет для себя достойную работу, даже если он пишет на PHP.
PS: Я одинаково много (и, смею надеяться, хорошо) пишу на Perl, PHP и Python. Осваивал эти языки именно в таком порядке. Я крайне не согласен с Вами в том, что PHP прививает какое-то либо кривописание или какое-либо особое мышление.
На perl сейчас довольно много людей пишут качественные web-приложения. И во многом благодаря PHP, в Perl среде процент хороших программистов сейчас очень высок.
По поводу Perl согласен. use strict заставляет пораскинуть мозгами и пробежаться еще раз по коду ^_^
Пардон, вот за что я люблю РНР - за то что там можно разработать сайт за 100$. Сидя и кушая бутерброд не печатая ни строчки кода. Можно поставить Друпал, или Мамбу, и сделать все нужные конфигурации. Огромное количество модулей, которые могут создать сайт фирмы, интернет-магазин или что-то другое без программирования как такового.
Даже голодному студенту есть чем питаться и не заниматься "кодингом".
Даже голодному студенту есть чем питаться и не заниматься "кодингом".
Хамить не надо по телефону (с) Булгаков
Шутка была.
А минусуют за то, что вы проблемы программистов переносите на язык.
Умные люди на PHP пишут мощные и красивые вещи. А криворукие пионеры пишут кривое дерьмо на всем - от РоР до Явы.
А минусуют за то, что вы проблемы программистов переносите на язык.
Умные люди на PHP пишут мощные и красивые вещи. А криворукие пионеры пишут кривое дерьмо на всем - от РоР до Явы.
Ну посидит клиент годик с тем, что ему пионеры за сто баксов наваяли - все равно обратно в серьезную контору придет. И тут с него со спокойной совестью можно будет взять в два раза больше :)
Мне попадал в руки один проект на PHP - конструктор веб-сайтов - так вот его функциональность наращивается набегами, причем каждый раз разными фрилансерами. Полагаю, что и всякими студентами и индусами. Разобраться в структуре проекта - уже подвиг, код понятно какой - какой попало, смесь стилей. Но! Проект работает на удивление стабильно, уже долгое время принося прибыль заказчику. А что еще надо? ^_^
Вот люди, которым надоело делать дешево и сердито, и снимают такие ролики. Про то, как делать дорого и дОбро.
Пока я и моя компания будем делать всё на PHP, ибо на PHP опыта больше, да и разработчиков Руби в регионе нет. Да и на перспективу — джанго. Ибо быстрее и матёрей.
Наш проект http://mmm-tasty.ru полностью сделан на рельсах и andy (http://andy.mmm-tasty.ru) очень хорошо отзывается о нем. Я ему верю ;)
не так много, чтобы можно было судить о работе при больших нагрузках.
Сдается мне, что если для Вас решающим фактором является кол-во уников в сутки, то Вы не видите всей картины в целом.
Я понимаю, о чем вы. Но мы же тут обсуждаем не собственные проекты и не их посещаемость, а фреймворк(и), у которых производительность - всего лишь одна из характеристик. Если вам нужно узнать, какую нагрузку может выдержать тот или иной фреймворк - проведите бенчмарк самостоятельно или поищите результаты в гугле. Всего делов.
Скажу честно, с посещаемостью больше 5к в день я никогда не имел дела, и в этом вам по-хорошему завидую. Но. В большинстве случаев 10-50к не упадут на ресурс сразу же. Для этого надо приложить усилия (раз) и должно пройти определенное время (два). Проблему производительности надо решать по мере ее возникновения.
Скажу честно, с посещаемостью больше 5к в день я никогда не имел дела, и в этом вам по-хорошему завидую. Но. В большинстве случаев 10-50к не упадут на ресурс сразу же. Для этого надо приложить усилия (раз) и должно пройти определенное время (два). Проблему производительности надо решать по мере ее возникновения.
советую LoadRunner или SilkPerformer. хорошие средства, чтобы проверить свой сайт на выносливость.
Как уже сказали выше, на PHP можно писать грамотно и в ус не дуть - тут проблема исключительно рук и голов. Меня никогда не напрягали точки для конкатенации и стрелочки для вызова методов, но аргумент выше порадовал, спасибо ) на самом деле, как это ни удивительно, эти точки помогают быстро отделять a + b от a . b и без знания контекста отделять строки от цифр - а значит увеличивают в какой-то мере читаемость.
с точки зрения красивости языка меня вот гораздо больше настораживает JavaScript к примеру - возможность создавать объекты и определять функции, в том числе анонимные, кучей разных способов делает неюзабельной функцию парсинга кода (для создания навигации по файлу) в моем любимом pspad, да и код становится малочитабельный - вот это объективный аргумент против языка, я понимаю.
Я потратил некоторое время на изучение и анализ Python и Ruby, и если припрет переходить на что-то с PHP, это пожалуй все же будет Python. В наше время процы не так дороги как мозги девелопера, но разница на типовых задачах в ТРИ раза по скорости ( http://shootout.alioth.debian.org/gp4/be… ) (python > Ruby) - это слишком. Сомневаюсь что на питоне писать серьезные приложения НАСТОЛЬКО сложнее :) Память, судя по словам хостеров, у Руби заметно течет.
Да и код в Python гораздо более лаконично-читаемый - тут субъектив, конечно.
с точки зрения красивости языка меня вот гораздо больше настораживает JavaScript к примеру - возможность создавать объекты и определять функции, в том числе анонимные, кучей разных способов делает неюзабельной функцию парсинга кода (для создания навигации по файлу) в моем любимом pspad, да и код становится малочитабельный - вот это объективный аргумент против языка, я понимаю.
Я потратил некоторое время на изучение и анализ Python и Ruby, и если припрет переходить на что-то с PHP, это пожалуй все же будет Python. В наше время процы не так дороги как мозги девелопера, но разница на типовых задачах в ТРИ раза по скорости ( http://shootout.alioth.debian.org/gp4/be… ) (python > Ruby) - это слишком. Сомневаюсь что на питоне писать серьезные приложения НАСТОЛЬКО сложнее :) Память, судя по словам хостеров, у Руби заметно течет.
Да и код в Python гораздо более лаконично-читаемый - тут субъектив, конечно.
К тому же Python гораздо популярнее на Западе. И к нему есть мощные фреймворки. Мы обдумывали переход на Питон еще 3 года назад, но пока в регионе не ни спецов по питону, ни клиентов, готовых за него платить.
Так в этом все и дело. О достоинствах языка программеры могут спорить до потери пульса, однако тут дело не только в языке, а в ЦЕЛОСТНОМ_РЕШЕНИИ.
IMHO
не важно на чем писать. Каждый язык достаточен для достижения цели. Да, возможно что какие то языки лучше подходят для конкретных целей. Но УНИВЕРСАЛЬНОГО языка, который подходил бы для решения ВСЕХ типов задач пока нет. Так что, спор по сути дела сводиться к фразе "мое кунфу круче твоего". Хотя информация тут проскакивает и ценная, но все таки все скатилось к обмену упрёками. ;) Прямо как при банальном разводе
не важно на чем писать. Каждый язык достаточен для достижения цели. Да, возможно что какие то языки лучше подходят для конкретных целей. Но УНИВЕРСАЛЬНОГО языка, который подходил бы для решения ВСЕХ типов задач пока нет. Так что, спор по сути дела сводиться к фразе "мое кунфу круче твоего". Хотя информация тут проскакивает и ценная, но все таки все скатилось к обмену упрёками. ;) Прямо как при банальном разводе
"УНИВЕРСАЛЬНОГО языка, который подходил бы для решения ВСЕХ типов задач пока нет."
Sun Microsystems так не думает =)
Sun Microsystems так не думает =)
SUN для веб-сайта как слон в посудной лавке.
Я это сказал чуть выше =)
уважаемые специалисты слышали что-то о JRuby? или познания уважаемых специалистов дальше слов Sun и Java не идут?
Все разговоры о том, что Java — это для Бальших Решений, руби — для гибких, перл — еще для каких-то, попахивают рекламной проброшуренностью. В Бальших Проектах (там, где Ява, SAP и другие so called гиганты) есть одна проблема: бюрократическая неповоротливость. Это недостаток. И иногда этот недостаток является тем, на что ориентируются продукты и услуги. Те продукты, что смягчают эффект от этого недостатка, — это одно; те, что призваны лишь перекачивать немыслимые деньги из одного виртуального бюджета в другой — другое.
Конкретно Джава — это на 10% смягчение бюрократизированности, на 90% — жесткая эксплуатация её. В чем это проявляется? Если у вас, несчастного, богатая компания с 20 000 тупых программистов в индии, то вам пригодится технология, которая помешает тупым программистам сделать совсем, непоправимо, "плохо". Но в то же время, те, кто стоят за этой технологией без стыда впаривают свои далекие от реального мира идеи, которые будут проглочены "индусами", а вы, менеджер, зато получите красивый буклет и отстегнете еще десяток штук баксов на прилет агента по продажам с румяной презентацией.
Исправлять проблему нужно не в компьютерах, а "в консерватории". Вместо тыщ индусов и закрученных в петлю раздутых контрактов, поставить простую цель, нанять десять гениев и работать в приятной компании, как вам нравится. Ведь те, кто работают на "крупных проектах" делают продукт не для людей, а для воспаленного воображения какого-то одного менеджера предпенсионного возраста.
Конкретно Джава — это на 10% смягчение бюрократизированности, на 90% — жесткая эксплуатация её. В чем это проявляется? Если у вас, несчастного, богатая компания с 20 000 тупых программистов в индии, то вам пригодится технология, которая помешает тупым программистам сделать совсем, непоправимо, "плохо". Но в то же время, те, кто стоят за этой технологией без стыда впаривают свои далекие от реального мира идеи, которые будут проглочены "индусами", а вы, менеджер, зато получите красивый буклет и отстегнете еще десяток штук баксов на прилет агента по продажам с румяной презентацией.
Исправлять проблему нужно не в компьютерах, а "в консерватории". Вместо тыщ индусов и закрученных в петлю раздутых контрактов, поставить простую цель, нанять десять гениев и работать в приятной компании, как вам нравится. Ведь те, кто работают на "крупных проектах" делают продукт не для людей, а для воспаленного воображения какого-то одного менеджера предпенсионного возраста.
«Точно заработает» — это миф. «Дороже» — это не просто дороже, это огромнейший оверхэд. Такие вот индусские продукты живут исключительно потому, что пользователям (клеркам) пикнуть не дают. И потому еще, что компания-поставщик, как правило, является монополистом для компании-заказчика.
Про производительность разговор простой: она должна соответствовать задаче. Поэтому начинать обсуждение надо не с абстрактных бенчмарков, а с конкретных задач и изучения bottleneck-ов.
А про «покажет время» — читайте мой последний комментарий (#comment144195).
Про производительность разговор простой: она должна соответствовать задаче. Поэтому начинать обсуждение надо не с абстрактных бенчмарков, а с конкретных задач и изучения bottleneck-ов.
А про «покажет время» — читайте мой последний комментарий (#comment144195).
для домашней странички - да.
для web приложения, которое автоматизирует работу - нет.
для web приложения, которое автоматизирует работу - нет.
:) жаль закончились плюсы.
ведь так и есть. у меня на мобильном виртуальная машина java. я использую среду разработки, написанную на java. я использую application server, написанный на java.
ведь так и есть. у меня на мобильном виртуальная машина java. я использую среду разработки, написанную на java. я использую application server, написанный на java.
да да .. вон даже скрипты в Цивилизации на питоне :)
Меня никогда не напрягали точки для конкатенации и стрелочки для вызова методов, но аргумент выше порадовал, спасибо ) на самом деле, как это ни удивительно, эти точки помогают быстро отделять a + b от a . b и без знания контекста отделять строки от цифр - а значит увеличивают в какой-то мере читаемость.
Это не аргумент, а пример кривого design decision, которые в PHP встречаются на каждом шагу. Этот маленький, казалось бы, ньюанс, отражает саму суть языка. Ну не могу я после C++/C#/Ruby писать на языке, у которого разница между конкатенацией строк и сложением инт-ов заложена в дизайн и синтаксис.
Ничего этот "нюанс" не отражает. Контантенация и сложение - это два абсолютно разных оператора. Как в Perl, так и в PHP:
$a = "2" + "2"; // $a == 4
$b = 2 . 2; // $b == "22"
Напоминаю, что оба языка dynamic-typed и конвертирвоание происходит автоматически. После C++, где конкантенация строк реализуется путем перегрузки оператора + для класса string, конечно трудно привыкнуть к новому оператору.
$a = "2" + "2"; // $a == 4
$b = 2 . 2; // $b == "22"
Напоминаю, что оба языка dynamic-typed и конвертирвоание происходит автоматически. После C++, где конкантенация строк реализуется путем перегрузки оператора + для класса string, конечно трудно привыкнуть к новому оператору.
Ага, и сложение флоатов отличается от сложения интов, поэтому давайте-ка для сложения флоатов тоже отдельный оператор введем.
Вы не задумывались вообще, почему в Яве, С++, С#, Ruby, Python для конкатенации строк используется +, и только в Perl и PHP точка? Потому что в языках, которые изначально разрабатывались как объектно-ориентированные, учтено, что конкатенация - это операция сложения для строк. И строка - всего лишь один из существующих типов, а не какая-то особенная сущность языка. Более того, там учтено, что в зависимости от задачи программист может ввести свой собственный тип (например, геометрический вектор), и там уже оператор "+" будет вести себя совсем по-другому.
Вообще, рассказать Вам, откуда взялась точка для конкатенации?
Сидит Ларри, разрабатывает Перл и думает: нет, мол, не хочу я строгую типизацию. Мне нужно, чтобы любая переменная могла в себе хранить и строку, и число. Подумал и реализовал тут же. Так у нас появился скаляр, не имеющий конкретного типа. Конечно, ни о каком ООП у Ларри тогда и мыслей не было.
Едем дальше: пропарсил Ларри лог и давай отчет генерить. Смотрит, а у него в скаляре число лежит (которое на самом деле строка), и когда он его к другому скаляру лепит +-ом, получается непонятно что. Т.е. Ларри хочет строки конкатенировать, а Перл ему числа складывает. Ну Ларри не долго думая и добавил в язык еще один оператор - их ведь еще много свободных, на все случаи хватит. Так и появилась в Перле точка, чтобы неоднозначность разъяснить.
А вот если бы Ларри немножко подумал или посмотрел на объектно-ориентированный язык, он бы понял, что пускай язык и динамический, но тип у скаляра всеравно должен быть. Тогда объект может сам решить, что ему делать при сложении, вычитании, умножении и т.д. Ларри конечно понял это, но поздно, когда ПХП уже переняли точку по наследству, перлисты вообще с ней срослись, а на горизонте замаячили Питон и Руби.
Вы не задумывались вообще, почему в Яве, С++, С#, Ruby, Python для конкатенации строк используется +, и только в Perl и PHP точка? Потому что в языках, которые изначально разрабатывались как объектно-ориентированные, учтено, что конкатенация - это операция сложения для строк. И строка - всего лишь один из существующих типов, а не какая-то особенная сущность языка. Более того, там учтено, что в зависимости от задачи программист может ввести свой собственный тип (например, геометрический вектор), и там уже оператор "+" будет вести себя совсем по-другому.
Вообще, рассказать Вам, откуда взялась точка для конкатенации?
Сидит Ларри, разрабатывает Перл и думает: нет, мол, не хочу я строгую типизацию. Мне нужно, чтобы любая переменная могла в себе хранить и строку, и число. Подумал и реализовал тут же. Так у нас появился скаляр, не имеющий конкретного типа. Конечно, ни о каком ООП у Ларри тогда и мыслей не было.
Едем дальше: пропарсил Ларри лог и давай отчет генерить. Смотрит, а у него в скаляре число лежит (которое на самом деле строка), и когда он его к другому скаляру лепит +-ом, получается непонятно что. Т.е. Ларри хочет строки конкатенировать, а Перл ему числа складывает. Ну Ларри не долго думая и добавил в язык еще один оператор - их ведь еще много свободных, на все случаи хватит. Так и появилась в Перле точка, чтобы неоднозначность разъяснить.
А вот если бы Ларри немножко подумал или посмотрел на объектно-ориентированный язык, он бы понял, что пускай язык и динамический, но тип у скаляра всеравно должен быть. Тогда объект может сам решить, что ему делать при сложении, вычитании, умножении и т.д. Ларри конечно понял это, но поздно, когда ПХП уже переняли точку по наследству, перлисты вообще с ней срослись, а на горизонте замаячили Питон и Руби.
Вы крайне правильно сказали про то, что Ларри Уолл пытался добиться от языка однозначной трактовки скаляра в разных случаях. Для того, чтобы оперировать скаляром как строкой, даже если в переменной хранится числовое значение, он и создал операторы . (точка), eq, ne и cmp. Это часть идеологии Perl. С появлением Perl6 точка будет использоваться для обращения к элементам объектов. Но знаете что? Оператор конкантенации сохранится! Это будет уже не точка, а знак подчеркивания.
Может кому-то и нужна четкая типизация, но не языку Perl и его сообществу. Ключевое слово в этом посте - идеология. Идеологии языков Python и Ruby не лучше, они просто другие.
Может кому-то и нужна четкая типизация, но не языку Perl и его сообществу. Ключевое слово в этом посте - идеология. Идеологии языков Python и Ruby не лучше, они просто другие.
:) А я надеялся что обойдется без холиворз. :) Не обошлось :)))
Как я устал от этих фанатов Ruby. Пишите вы на своем Божьем языке, но незачем нос задирать! Как будто все сообщество рельсоманов состоит из 15-летних "дарований"
Вот хорошая выдержка из Getting Real от 37signals (которая, кстати, недавно была полностью переведена на русский, что является еще одним поводом прочитать ее от начала и до конца):
У вас пока нет проблемы расширения
«Каким будет мое приложение, когда им будут пользоваться миллионы людей?»
Что? Ждите, пока это фактически не случится. Если вы достигли того, что огромное число людей, перегружают вашу систему — тогда ура! Это очень красивая проблема. Правда — подавляющее большинство сетевых приложений никогда не достигают этой стадии. И даже, когда вы достигните этого — обычно ничего страшного не происходит. У вас будет достаточно времени, чтобы приспособиться к проблеме. Плюс, вы будете иметь более реальные данные и эталонные тесты, чтобы выяснить к каким конкретно областям приложения требуются улучшения.
Например, у нас был запущен Basecamp на одном сервере в первый год. Поскольку мы шли с такой простой установкой, это потребовало всего неделю на осуществление планов. Мы не начинали с кластера в 15 боксов и не тратили месяцы на волнения о вычислениях и на подсчеты.
У нас были проблемы? Нисколько. Но мы также осознали, что большинство проблем, которых мы боялись, действительно не существовало, с чем были согласны и наши клиенты. Будьте честны с ними, они поймут. Вспоминая прошлое, мы рады тому, что не стали делать «совершенную установку» с задержкой во многие месяцы.
В начале, сделайте основу продукта, вместо масштабируемости. Создайте большое приложение, а затем тревожьтесь о том, что делать, как только оно стало успешным. Иначе вы, возможно, расточаете энергию, время, и деньги, фокусируетесь на том, что может никогда не случиться.
Поверьте, это не большая проблема расширяться, когда в этом есть необходимость.
MediaWiki, движок Википедии, достаточно тяжелый. Но в его сердце аж три варианта кэширования внешними средствами, на выбор. Помню только, есть memcached. То есть, это как раз пример хорошего проектирования и программирования на PHP. Можно сказать, что это показательно качественное PHP-приложение.
Я пытаюсь сделать какой-то вывод из этого холивора. Если можно, хотелось бы услышать какой-то итог.
1. Про Руби было сказано много, и самая существенная кртика это его медлительность. Насколько реально с ней бороться и сайты с каким уровнем посещаемости можно создавать на Руби. Желательно услышать цифры, ссылки на подобные ресурсы, и рекомендации по настройке.
2. В чем принципиальное отличие Django от Rails. Интересно услышать мнение людей которые реально работали с этими фреймворками.
3. Примеры известных и популярных проектов на Rails или Django. Если не рассматривать корпоративные сайты, а вот именно сайты которые известны широкому кругу и хорошо работают.
Я конечно понимаю, что это довольно узкие вопросы, которые не раскрывают всех вожможностей и потребностей Ruby. Но тем не менее просьба ответить.
1. Про Руби было сказано много, и самая существенная кртика это его медлительность. Насколько реально с ней бороться и сайты с каким уровнем посещаемости можно создавать на Руби. Желательно услышать цифры, ссылки на подобные ресурсы, и рекомендации по настройке.
2. В чем принципиальное отличие Django от Rails. Интересно услышать мнение людей которые реально работали с этими фреймворками.
3. Примеры известных и популярных проектов на Rails или Django. Если не рассматривать корпоративные сайты, а вот именно сайты которые известны широкому кругу и хорошо работают.
Я конечно понимаю, что это довольно узкие вопросы, которые не раскрывают всех вожможностей и потребностей Ruby. Но тем не менее просьба ответить.
1, 3: На Рельсах сделаны (навскидку): http://www.wakoopa.com, http://twitter.com, http://43things.com, http://mywishlist.ru, http://www.mmm-tasty.ru + все продукты 37signals. Твиттер и Вакупа могут являться примерами действительно "нагруженых" приложений из-за своей специфики (в блоги твиттера люди пишут каждые 5-10 минут, а у вакуповский трекер постоянно шлет отчеты на сервер).
На 2-й пункт отвечать не буду, т.к. не хочу сталкивать эти фреймворки лбами. Они разные. Так что тут решают исключительно вкусовые предпочтения. У меня сердце больше лежит к Руби.
На 2-й пункт отвечать не буду, т.к. не хочу сталкивать эти фреймворки лбами. Они разные. Так что тут решают исключительно вкусовые предпочтения. У меня сердце больше лежит к Руби.
И девелоперы твиттера теперь плачут в своем блоге про проблемы с производительностью :)
Ну и что. Девелоперы твиттера не дураки, со временем решат проблему, если уже не решили.
Вы так говорите, как будто ПХП гарантирует стабильную работу любого сайта на нем, а Rails - проблемы с производительностью.
Еще раз вольно процитирую Getting Real: "Сперва сделай такой ресурс, чтобы он валился от наплыва пользователей, и только потом занимайся масштабированием. Не нужно решать проблему, которой на данный момент нет."
Ну или Кнута: "Premature optimisation is the root of all evil".
Вы так говорите, как будто ПХП гарантирует стабильную работу любого сайта на нем, а Rails - проблемы с производительностью.
Еще раз вольно процитирую Getting Real: "Сперва сделай такой ресурс, чтобы он валился от наплыва пользователей, и только потом занимайся масштабированием. Не нужно решать проблему, которой на данный момент нет."
Ну или Кнута: "Premature optimisation is the root of all evil".
А чем вас не устраивает в качестве примера проект из которого и родился RoR ?
http://www.37signals.com/
Там так и написано - Work Well ;)
http://www.37signals.com/
Там так и написано - Work Well ;)
Вывод такой - надо выбрать себе язык на котором приятно писать. Не Васе из Урюпинска а тебе (Вам).
Злую штуку Apple придумали=) Скоро появятся ролики - "Hi, I'm Mersedes" "And I am BMW"; "Hi, I'm pork" "And I'm beef" и так далее=)
Начали за здравие, закончили за упокой. Почитайте второй комент. НЕТ плохих и хороших. Есть суровая реальность. Каждый язык в чем-то хорош и плох одновременно. Нельзя с пеной у рта доказывать что что-то говно и завалится на 10к. Каждый случай уникален. Просто нужно смотреть шире а не говорить все говно, кроме того что мне нравится. Почему php фреймворки пытаются копировать рельсу. Почему руби пытается достичь скорости пхп. Да потомучто там умные люди, которые понимают свои ошибки и недостатки, а также умеют достойно их признавать. А кто не умеет видеть дальше своего носа, тот никогда не станет програмистом, а будет просто кодером......
Ну осилил перечитал весь флуд.
Заметил что тут крик только от рубистов и питоновцев. Не буду повторяться о неумесности приведенных сравнений. Скажу только что заметил такую закономерность: PHP программистов намного больше чем руби и питон. Наверно они(мы) тихонько сидят и зарабатывают деньги. Взглянуть например на RentACoder, GetAFreelancer, Elance и сравнить количество проектов по языкам. Это тоже самое что выставить машины прототипы, которые только на выставках показывают и которые не пригодны для езды по улицам. Есть такое понятие - рынок не готов.
Как мне кажется вся шумиха вокруг ROR проплачена 37 сигналами дабы продвинуть это дело в массы. Реально руби а темболее в реализации RoR по производительности очень проигрывает PHP(http://shootout.alioth.debian.org/gp4/be…) а темболее Python-у (http://shootout.alioth.debian.org/gp4/be…).
На самом деле последние пару дней я и занялся вопросом чтобы изучить такое новое потому что хочется чего то нового. Пока что всё что я делал на PHP, мне хватало для всего его возможностей. Сейчас стоит вопрос Python или Ruby.
Пол гугли на питоне висит и это должно о чем то говорить.
Руби может привлекать только своей красотой кода и реализацией OOP.
Но как то я больше пока склоняюсь к питону. Конечно лучше и то и другое, но это не студенческие времена когда на пожрать мамапапа дает и времени полно свободного.
Заметил что тут крик только от рубистов и питоновцев. Не буду повторяться о неумесности приведенных сравнений. Скажу только что заметил такую закономерность: PHP программистов намного больше чем руби и питон. Наверно они(мы) тихонько сидят и зарабатывают деньги. Взглянуть например на RentACoder, GetAFreelancer, Elance и сравнить количество проектов по языкам. Это тоже самое что выставить машины прототипы, которые только на выставках показывают и которые не пригодны для езды по улицам. Есть такое понятие - рынок не готов.
Как мне кажется вся шумиха вокруг ROR проплачена 37 сигналами дабы продвинуть это дело в массы. Реально руби а темболее в реализации RoR по производительности очень проигрывает PHP(http://shootout.alioth.debian.org/gp4/be…) а темболее Python-у (http://shootout.alioth.debian.org/gp4/be…).
На самом деле последние пару дней я и занялся вопросом чтобы изучить такое новое потому что хочется чего то нового. Пока что всё что я делал на PHP, мне хватало для всего его возможностей. Сейчас стоит вопрос Python или Ruby.
Пол гугли на питоне висит и это должно о чем то говорить.
Руби может привлекать только своей красотой кода и реализацией OOP.
Но как то я больше пока склоняюсь к питону. Конечно лучше и то и другое, но это не студенческие времена когда на пожрать мамапапа дает и времени полно свободного.
Вы уже пятый по счету человек, который сегодня "присоединился" ко мне и решил начать осваивать питон)
>Пол гугли на питоне висит и это должно о чем то говорить
Пф... Можно подумать гугль принимал стратегическое решение - питон или руби. Он нанял кучку хакеров и сказал - сделайте мне красиво. У кучки хакеров любимым языком оказался питон. Вот и вся загадка.
Питон постарше и более известен в европе-штатах. Руби - мегапопулярен в японии.
Между питоновцами и рубиистами намного меньше разница чем между ними и пхпшниками :)
После того как попробовал любой из этих языков кодирование на пхп превращается в мучение :)
Пф... Можно подумать гугль принимал стратегическое решение - питон или руби. Он нанял кучку хакеров и сказал - сделайте мне красиво. У кучки хакеров любимым языком оказался питон. Вот и вся загадка.
Питон постарше и более известен в европе-штатах. Руби - мегапопулярен в японии.
Между питоновцами и рубиистами намного меньше разница чем между ними и пхпшниками :)
После того как попробовал любой из этих языков кодирование на пхп превращается в мучение :)
После того, как я начал использовать Python для большинства задач, возвращение к PHP-проектам для меня не только не превращается в мучение, но даже малейшего дискомфорта не вызывает. Пожалуйста, не обобщайте.
Может вы ещё скажете что гугл использует исключительно дешевое оборудование (сервера) из-за того что незнал что существуют дорогие и "надежные"?
> Руби может привлекать только своей красотой кода и реализацией OOP.
если говорить о РОР, то ещё и удивительная гибкость при работе с БД и разработке WS (как REST, так и SOAP).
А ещё, не надо с фонариком ходить, чтоб найти необходимый кусок кода.
А ещё, когда кодишь не нужно задумываться как/куда/что писать - соглашения вместо настроек!
А Гугл выбрал Питон скорее за его опробованность(читать зарекомендованность или надёжность) - Руби молод и многие просто ему не доверяют - мол свеж, молод, наверняка кучу косяков ещё не исправили/не нашли, может даже вообще в нём переделают,...
Но это скоро пройдёт.
если говорить о РОР, то ещё и удивительная гибкость при работе с БД и разработке WS (как REST, так и SOAP).
А ещё, не надо с фонариком ходить, чтоб найти необходимый кусок кода.
А ещё, когда кодишь не нужно задумываться как/куда/что писать - соглашения вместо настроек!
А Гугл выбрал Питон скорее за его опробованность(читать зарекомендованность или надёжность) - Руби молод и многие просто ему не доверяют - мол свеж, молод, наверняка кучу косяков ещё не исправили/не нашли, может даже вообще в нём переделают,...
Но это скоро пройдёт.
Ещё стоит отметить на разработку JRuby
Sun и IBM уже вплотную занялись Ruby
(это по поводу выбора Гуглом питона)
Sun и IBM уже вплотную занялись Ruby
(это по поводу выбора Гуглом питона)
Да сколько можно говорить что RoR и Ruby это разные вещи, вы же не сравниваете кучу метала с машиной BMW и не говорите что лучше. Чем дальше тем больше меня эта шумиха насчёт RoR начинает раздражать и тем больше желание работать в питоне возникает.
Насколько я знаю - руби и питон появились с разницей в 2-3 года всего. Опять же вы путаете Ruby и RoR который появился в 2003-2004 году.
>А ещё, когда кодишь не нужно задумываться как/куда/что писать - соглашения вместо настроек!
Может там вообще не надо задумываться что писать? "соглашения вместо настроек!" - а это что уже как религия?
Насколько я знаю - руби и питон появились с разницей в 2-3 года всего. Опять же вы путаете Ruby и RoR который появился в 2003-2004 году.
>А ещё, когда кодишь не нужно задумываться как/куда/что писать - соглашения вместо настроек!
Может там вообще не надо задумываться что писать? "соглашения вместо настроек!" - а это что уже как религия?
Почитал сколько было сил...
Есть простой тезис. Все участники игры в песочнице под названием «IT» (да, впрочем, и в других областях) делятся на две категории. Первая — это те, кто смотрят чуть дальше собственного носа, знают что «правильно в перспективе» и, преодолевая препятствия, двигают свою идею вперед. Идея может быть не верная, но суть не в том. Вторая категория («большинство») — это догоняющие. Они идут туда, куда (sic!) авторитет сказал, реклама направила, или «большинство» уже поползло по одной из двух перечисленных причин. Игроки из второй категории никогда не сорвут большой куш, но перестраховываются, ползя где-то в середине. Те, кто в авангарде, могут попасть «в яблочко» и стать историческими персонами, а могут и промахнуться.
Главное в споре RoR vs. World — не технические характеристики, а подход к жизни. Я и мои товарищи, делающие РоР верим в то, что за нашими идеями (не либами и плагинами, а идеями) — будущее. Мы встречаем проблемы со скоростью, хостингом, проблемами интеграции и прочим как должное. И мы решаем их, чтобы нам самим было удобно. Мы не ждем, пока придёт дядя и продаст нам версию 7.0, в которой "фичу, наконец, добавили", мы сами её делаем. У нас недостаток людей? Мы пишем статьи, спорим, даём бесплатные тренинги. Лично я научил руби и рельсам, для себя, пять человек. И это окупилось.
Да, мы считаем, что мы правы. Нет, мы не считаем, что нужно ждать, пока 80% народа будет думать одинаково чтобы и нам сменить направление. Смотрите на это так: каждый из нас — акционер, вкладывающий в технологию время, силы и деньги. Если вы впереди — у вас внушительная доля, вы имеете возможность влиять на развитие технологии в том ключе, который вам нравится. Если вы идете туда, куда уже ушло большинство — вы не имеете и доли процента, все разобрано до вас. А раз так, то, если ошиблись с выбором догоняющие, то у них нет ни малейшего шанса на исправление. Джава de facto не принадлежит джавистам (посмотрите как медленно и криво продвигаются нововведения) и уже очевидно, что язык (не платформа!) Джава — это «не то». Руби и Рельсы, пока что, принадлежат всем нам в равной степени. И, забив тревожный звонок, реально направить работу в нужном направлении.
Есть простой тезис. Все участники игры в песочнице под названием «IT» (да, впрочем, и в других областях) делятся на две категории. Первая — это те, кто смотрят чуть дальше собственного носа, знают что «правильно в перспективе» и, преодолевая препятствия, двигают свою идею вперед. Идея может быть не верная, но суть не в том. Вторая категория («большинство») — это догоняющие. Они идут туда, куда (sic!) авторитет сказал, реклама направила, или «большинство» уже поползло по одной из двух перечисленных причин. Игроки из второй категории никогда не сорвут большой куш, но перестраховываются, ползя где-то в середине. Те, кто в авангарде, могут попасть «в яблочко» и стать историческими персонами, а могут и промахнуться.
Главное в споре RoR vs. World — не технические характеристики, а подход к жизни. Я и мои товарищи, делающие РоР верим в то, что за нашими идеями (не либами и плагинами, а идеями) — будущее. Мы встречаем проблемы со скоростью, хостингом, проблемами интеграции и прочим как должное. И мы решаем их, чтобы нам самим было удобно. Мы не ждем, пока придёт дядя и продаст нам версию 7.0, в которой "фичу, наконец, добавили", мы сами её делаем. У нас недостаток людей? Мы пишем статьи, спорим, даём бесплатные тренинги. Лично я научил руби и рельсам, для себя, пять человек. И это окупилось.
Да, мы считаем, что мы правы. Нет, мы не считаем, что нужно ждать, пока 80% народа будет думать одинаково чтобы и нам сменить направление. Смотрите на это так: каждый из нас — акционер, вкладывающий в технологию время, силы и деньги. Если вы впереди — у вас внушительная доля, вы имеете возможность влиять на развитие технологии в том ключе, который вам нравится. Если вы идете туда, куда уже ушло большинство — вы не имеете и доли процента, все разобрано до вас. А раз так, то, если ошиблись с выбором догоняющие, то у них нет ни малейшего шанса на исправление. Джава de facto не принадлежит джавистам (посмотрите как медленно и криво продвигаются нововведения) и уже очевидно, что язык (не платформа!) Джава — это «не то». Руби и Рельсы, пока что, принадлежат всем нам в равной степени. И, забив тревожный звонок, реально направить работу в нужном направлении.
господа - знатоки Ruby и RoR. посоветуйте какой-нить текст для newbie. желательно на русском, чтобы проникнуться идеей. желательно без воды.
Getting Started with Ruby on Rails - Google вам поможет
Учебник по Ruby на русском – толковый, компактный
http://ru.wikibooks.org/wiki/Ruby
http://ru.wikibooks.org/wiki/Ruby
Автору топика респект.
Благодаря этому хабратопику многие смогут расширить свои взгляды относительно PHP vs RoR vs Perl [vs Java [vs the World]]
Возникла настоящая дискуссия, а как известно, в споре рождается истина.
Благодаря этому хабратопику многие смогут расширить свои взгляды относительно PHP vs RoR vs Perl [vs Java [vs the World]]
Возникла настоящая дискуссия, а как известно, в споре рождается истина.
не так уж и много из основной массы кодят на яве, имхо
А зачем нам это делать? Сразу видно, что спор идеологический. Можно много говорить о плюсах и минусах кнкретных технологий, подходов, фреймворков, языков, идеешек, процессоров и пр. Но сути дела это не меняет. Я считаю, что каждому проекту - свою технологию. И всегда будут прверженцы каждой из технологий. И всегда будут криворучки, способные испоганить любой светлый подход в разработке чего-либо. И всегда найдутся люди, которые попробовав что-то новое (например, пхпист попробует руби - не в обиду никому, просто опыт такой был в моей организации) и, не разобравшись до конца (в силу то ли лени, то ли отсутствия интереса), начнет говорить, что "что-то меня не вставило на нем писать. наверно отстой какой-то.".
Эх, поздно наткнулся. :)
У хороших разработчиков такого спора не должно быть. "Плюсы" и "минусы" языков - это абстракции, полученные из-за программирования "на" языке, а не "с использованием" оного. Мы разрабатываем в голове или на бумаге архитектуру решения и затем отражаем ее в терминах того языка, который мы знаем лучше всего. Это получается быстрее, кроме того, мы можем быстрее модифицировать решение в случае необходимости. Инвестировать время в изучение нового языка? Зачем? Он дает принципиально новые методы решения задач? Нет, конечно. Наше время ценно и лучше углубить знания уже известного языка, чтобы быть экспертом в одном, а не Jack of all trades в разных.
Может быть, другой язык учит нас парадигме некоего мистического дисциплинированного программирования, но что, если мы уже научились ему, но пишем на другом языке: более популярном (читай, дешевом в плане найма разработчиков), расширяемом 3rd-party-компонентами (опять дешевом!) и документированном (снова дешевом...). Нам не нужны перевороты, нам нужна эффективная по критерию ROI работа.
Словесные конструкции, вроде того, что из-за такого подхода мы "тащимся в хвосте" и "не видим дальше своего носа" - софистическое жонглирование увлеченных евангелистов, не более того. Мы изучаем новые технологии, смотрим, где они могут пригодиться, возможно, базируем на них какие-то экспериментальные решения, чтобы оценить, насколько технология подходит для решения тех или иных задач. Если она дает реальный и ощутимый прирост некоего (измеримого!) качества, мы ее применяем.
Мне в этом плане очень нравится история:
Когда Банкей преподавал дзен в храме Рёмон, священник, который верил в спасение через повторение имени Будды Любви, позавидовал его большой аудитории и решил поспорить с ним. Банкей дошел до середины беседы, когда появился священник и произвел столько беспорядка, что Банкей прекратил проповедь и спросил о причине шума. «Основатель нашей секты», – хвастливо начал священник: «Обладал такой сверхестественной властью, что стоя на одном берегу реки с кистью в руке, он мог через воздух написать имя Амиды на листе бумаги, который держал его помощник на другом берегу реки. Можешь ли ты совершить такое чудо?» Банкей легко ответил: «Очень возможно, что ваша лиса могла проделывать такой трюк, но это не в обычае дзен. Мое чудо в том, что если я голоден, я ем, а если я хочу пить – пью.»
Переведите ее в термины этого разговора. :)
У хороших разработчиков такого спора не должно быть. "Плюсы" и "минусы" языков - это абстракции, полученные из-за программирования "на" языке, а не "с использованием" оного. Мы разрабатываем в голове или на бумаге архитектуру решения и затем отражаем ее в терминах того языка, который мы знаем лучше всего. Это получается быстрее, кроме того, мы можем быстрее модифицировать решение в случае необходимости. Инвестировать время в изучение нового языка? Зачем? Он дает принципиально новые методы решения задач? Нет, конечно. Наше время ценно и лучше углубить знания уже известного языка, чтобы быть экспертом в одном, а не Jack of all trades в разных.
Может быть, другой язык учит нас парадигме некоего мистического дисциплинированного программирования, но что, если мы уже научились ему, но пишем на другом языке: более популярном (читай, дешевом в плане найма разработчиков), расширяемом 3rd-party-компонентами (опять дешевом!) и документированном (снова дешевом...). Нам не нужны перевороты, нам нужна эффективная по критерию ROI работа.
Словесные конструкции, вроде того, что из-за такого подхода мы "тащимся в хвосте" и "не видим дальше своего носа" - софистическое жонглирование увлеченных евангелистов, не более того. Мы изучаем новые технологии, смотрим, где они могут пригодиться, возможно, базируем на них какие-то экспериментальные решения, чтобы оценить, насколько технология подходит для решения тех или иных задач. Если она дает реальный и ощутимый прирост некоего (измеримого!) качества, мы ее применяем.
Мне в этом плане очень нравится история:
Когда Банкей преподавал дзен в храме Рёмон, священник, который верил в спасение через повторение имени Будды Любви, позавидовал его большой аудитории и решил поспорить с ним. Банкей дошел до середины беседы, когда появился священник и произвел столько беспорядка, что Банкей прекратил проповедь и спросил о причине шума. «Основатель нашей секты», – хвастливо начал священник: «Обладал такой сверхестественной властью, что стоя на одном берегу реки с кистью в руке, он мог через воздух написать имя Амиды на листе бумаги, который держал его помощник на другом берегу реки. Можешь ли ты совершить такое чудо?» Банкей легко ответил: «Очень возможно, что ваша лиса могла проделывать такой трюк, но это не в обычае дзен. Мое чудо в том, что если я голоден, я ем, а если я хочу пить – пью.»
Переведите ее в термины этого разговора. :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Hi, I'm Ruby on Rails