Покорим Ruby вместе! Капля первая

    Дабы сразу определить целевую аудиторию этого цикла заметок-статей-поучений пару слов о себе. Бывший школьник, будущий студент, в программинге толком ничего не смыслю, хотя есть пара сайтиков на готовых движках. В php-скриптах могу чего-нить лишнее удалить, изменить, но написать что-то с чистого листа — это не ко мне. Неоднократно пытался научится мастерству создания программ, но обычно тормозил как только дело доходило до ООП (видел в коде эти многочисленные классы, в пособиях всякие «объекты», «инкапсуляции» и т.п. и зависал...)

    Собственно точно такое же желание появилось и сейчас. Порыскав по сети в поисках «чего-бы такого интересного выучить» наткнулся именно на Ruby с его рельсами. По словам спецов разного качества Руби сейчас актуален, программировать на нем быстро, это полный ООП (что перспективно в дальнейшем покорении олимпа программирования), синтаксис несложен… В то же время язык — тормоз, нагружает систему, twitter в нем барахтается, пытаясь удержаться на плаву, постоянные проблемы с хостингом. Но я вроде как стартапить в многомиллионную аудиторию не собираюсь, а для общего образования всегда подойдет.

    Так что стоит признаться, что и Ruby я знаю совсем каплю, но уверен, что и мои «капли» будут интересны некоторым индивидам, подобным мне. Я могу (и буду) часто ошибаться в каких-то понятиях, методах, но мы ведь готовы помогать друг другу? Вроде бы как Хабр — это элита ИТ, но я думаю, что местные спецы не будут против, если мы тут с начинающими ребятами немного «потусим» :)

    Собственно в этой серии статей мы будем капля за каплей наполнять стаканчик знаниями о Руби, наполнять будем вместе — для меня это также станет дополнительным стимулом не бросать занятия. Надеюсь, что и вам будет интересно! Начнем?

    Руби, Рельсы...


    Что такое Ruby? Руби — это полноценный интерпретируемый язык программирования высокого уровня для объектно-ориентированного программирования. Интерпретируемый — значит что код программы хранится в виде обычного текста, который передается исполняющему его интерпретатору. Можно сравнить с PHP и C++ — как и в PHP достаточно написать код, условно загрузить его на сервер-хостинг, где его будет выполнять интерпретатор. В противовес C++ необходимо компилировать, но зато мы получаем готовое приложение, которое выполняется само по себе, никуда код передавать не надо, но и посмотреть в исходники, заглянуть в программу, увы, не выйдет — там нечитаемый бинарный код. Возвращаясь к Руби, делаем вывод, что язык этот замечателен для разработки веб-приложений, скриптов, в ОС же его использование ограничено скоростью приложения (как подсказали ниже, для фронтендов и небольших утилит Ruby очень даже подходит).

    Что такое Ruby on Rails? Дословно: «Руби на Рельсах». На какие такие рельсы поставили этот ЯП? Rails — это наиболее известный фрэймворк для языка Ruby. Мы можем писать скрипты и на «чистом» Ruby (подобно большинству скриптов на PHP), однако рельсы позволяют повысить скорость, производительность написания кода, кроме того, этот фрэймворк реализует архитектуру MVC (Model — View — Controller) — о том, что это такое и как это использовать, поговорим позже.

    Концепции Ruby и Rails



    Ruby и Ruby on Rails следуют паре принципов для того, чтобы помочь писать код чище и красивее. Первый: DRY (Don't repeat yourself). Это означает, что мы должны писать необходимый код только один раз и только в строго определенном месте. Второй: CoC (Conventions over Configuration) — общие соглашения важнее собственной конфигурации. Для большинства необходимых в кодинге методов уже есть замечательные автоматические установки, которые и следует использовать, а в крайних случаях, если умолчания нас не устраивают, мы просто переписываем их под себя. Всё, для того, чтобы код был чистым и лаконичным, и при этом мы затрачивали минимум усилий.

    Почему Ruby?

    • Язык предельно лёгок в изучении в сравнении с другими ЯП
    • Полностью объектно-ориентированный
    • Архитектура MVC у Rails
    • Нет необходимости писать много кода
    • Очень расширяемый
    • Open Source
    • Несмотря на то, что фрэймворк Rails молодой, он многофункционален и содержит совсем немного багов

    Эпилог


    Надеюсь, я вас смог заинтересовать :) Возможно всё это вы уже знаете. Однако если вам интересно, то мы продолжим. В следующей капле мы выберем среду разработки и напишем пару программ-малюток. Жду ваших комментариев!

    Вторая капля уже ждет вас здесь, третья здесь!
    Метки:
    Поделиться публикацией
    Комментарии 192
    • +4
      как для «Бывший школьник, будущий студент» грамотно написано. :)
      В качестве среды могу предложить NetBeans
      • 0
        Я старался ;)

        По секрету среду я уже выбрал :) Осталось только протолкнуть ее в массы начинающих и не очень
        • 0
          здоров получается, задорно и весело, я с вами :) хотя меня несколько расстраивает, что проблематично поставить PHP и Rails на одном сервере, а на счет производительности так вроде не сильно уступает пхп тем более это фреймворк. но это все только по- наслышке
          • +1
            С mod_passenger и mod_php можно на одном апаче запускать и php и rails приложения.
            • 0
              Не, кажись нельзя. Где-то встречал в обсуждениях, что мод_рельс использует что-то в апаче, что несовместимо с мод_пхп.
              • 0
                можно и если не знаете то стоит промолчать
                • +4
                  Ну тогда вообще никто писать не будет, а и так читать нечего. Знаешь/не знаешь — какая разница? Все равно истина рождается в холиваре! :P
                    • 0
                      не встретил в приведенном тред сообщения в которых описано что mod_rails не работает с mod_php.
                      прежде чем повторять как попугай — протестируйте
                      • 0
                        Тут речь идет о том что mod_php принуждает к использованию mpm_prefork, который не является самой удачной моделью.
                        Цитируя Алексея:
                        Это означает, что Вы не сможете использовать worker mpm, который наилучшим образом работает с passenger, потому что mod_php с ним работать нормально не в состоянии.

                        но на mpm_prefork все работает вполне неплохо.

                        Единственное что пока не дружило с mod_passenger (насколько мне известно) — это mod_vhost_alias.
                        • 0
                          >>Тут речь идет о том что mod_php принуждает к использованию mpm_prefork, который не является самой удачной моделью.

                          Потоковая модель нормально не работает в апаче. Мало того, что много чего приходится руками пересобирать (это касается пхп модулей нему), так еще и наблюдается мертвое виселово под нагрузкой через пару часов. Причину так и не нашел, решения — тоже. С похожими симптомами ребята сталкивались, но решить тоже не смогли.
                          Так что я бы сказал, что prefork на данный момент единственная модель для апача.
                          • 0
                            Так я же и говорю что mod_php нормально работает с mpm_prefork. Тредовый апач сам по себе работает весьма хорошо, но много чего написаного для него — хотя бы тот же mod_php — не thread-safe.
                            www.camelrichard.org/apache-prefork-vs-worker
                            For now, on Linux (and even UNIX) you should only use the (default) prefork module with PHP. This is specified at compile time. Other MPM modules (any involving threads) break PHP. This is partly because PHP uses a great number of external libraries, and many or most of them are not thread-safe or thread-aware.
                    • 0
                      И почему же нельзя? И как же у меня ruby, python, php на одном апаче бегают бзе плясок с бубном?
                  • +1
                    нет никаких проблем. php через mod_php, рельсы через fcgi (и хотя это далеко не лучшее решение, работает достаточно быстро)
                    • 0
                      а где почитать и какое решение лучшее?
                      • 0
                        лучше использовать mongrel. но честно говоря, мне было лень что-либо настраивать, по-этому я даже не читал по этому поводу.
                        по поводу fcgi достаточно информации в интернетах.
                        • 0
                          Посмотрите еще thin, как новую альтернативу монгрелу. На продакшене сами мы еще не пробовали, но по отзывам он обгоняет монгрел везде и основан на стабильных компонентах.

                          code.macournoyer.com/thin/
                • 0
                  Почему Ruby?

                  * Язык предельно лёгок в изучении в сравнении с другими ЯП
                  * Полностью объектно-ориентированный
                  * Архитектура MVC


                  Прощу прощения, это у самого руби архитектура MVC или все-таки у Rails?
                  • 0
                    Вы правы — всё в кучку получилось — исправляем!
                    • 0
                      Архитектура MVC? Мм, случаем не паттерн ли программирования MVC?
                      • 0
                        А может проектирования? :)
                        • 0
                          хотя да, и архитектурой, наверно, правильно называть тоже…
                      • +1
                        «Возвращаясь к Руби, делаем вывод, что язык этот замечателен для разработки веб-приложений, скриптов, и совсем не подходит для создания программ, например, для Windows.»

                        Не соглашусь… руби как и питон замечательно подходит как для написания гуи фронтендов к консольным приложениям так и для написания небольших или нетребовательных к ресурсам (а точнее к скорости) утилит.
                        • 0
                          А я соглашусь… С вами соглашусь :) Подправим ;)
                        • 0
                          браво! ждём продолжения!
                          • +3
                            И еще забыл сказать свою постоянную фразу про обучение программированию на синтаксически-сладких языках (руби к ним относится).

                            Это зло. Такие языки на начальном этапе развития человека как программиста дают определенную (и вполне нехилую) халяву, которая может выйти боком. Если же вначале пописать на таких языках как с или с++ (главное чтобы не было ГЦ и чтобы это был не паскаль), то это даст вам большое представление о том как надо писать программы. А потом уже можно переходить на сахар. При таком подходе ваши программы будут более эффективны. Это все ИМХО конечно, но ИМХО это ИМХО вполне обоснованно.
                            • 0
                              Как я понял, автор уже имеет представление о программировании, и интересует его сейчас именно ООП.
                              • +2
                                я писал на основе его слов «в программинге толком ничего не смыслю»
                              • 0
                                > И еще забыл сказать свою постоянную фразу про обучение программированию на синтаксически-сладких языках (руби к ним относится).

                                > Если же вначале пописать на таких языках как с или с++ (главное чтобы не было ГЦ и чтобы это был не паскаль), то это даст вам большое представление о том как надо писать программы.

                                Начали за здравие, закончили за упокой… Синтаксический сахар не относится к управлению памятью никаким боком.

                                Алсо, Си и Си++ не дадут никакого представления о том, как надо писать программы, скорее, дадут представление о том, как оно там внутре работает на низком уровне.
                                • 0
                                  я может просто слегка сжато выразился… имлось в виду что и синтаксический сахар и ГЦ мешают пониманию того как надо писать программы оптимально…

                                  «Алсо, Си и Си++ не дадут никакого представления о том, как надо писать программы, скорее, дадут представление о том, как оно там внутре работает на низком уровне.»

                                  Опять же имелось в виду «писать программы оптимально», чему крайне помогает как раз знание о том как оно все работает изнутри
                                  • 0
                                    «Оптимально» по какому критерию?
                                    • 0
                                      по критерию безглючность/скорость работы
                                      • +1
                                        Скорость работы — ага, но она не всегда критична, к тому же тут есть контр-аргумент — ассемблер :).
                                        Безглючность… Ну-у-у! По критерию возможности наделать на ровном месте кучу фатальных для программы (а то и для системы) глюков, что си, что сипипи за тем же ассемблером в затылок выстроились :). Вряд ли это то, что называется «оптимальностью» :). По критерию безглючности, программирование на более высокоуровневых языках, всё-таки «оптимальнее».
                                        • 0
                                          вы не поняли… я имел в виду отношение… и скорость работы в том же вебе критична достаточно… если у вас хай-лоад сервис то вам надо думать о скорости работы
                                          • +1
                                            Что есть «отношение»? Следить самому за указателями, вместо того, чтобы отдать это на откуп компилятору-рантайму — это отношение? Ну, а тогда, расписывать циклы на условия и гоуту, вместо использования высокоуровневых операторов цикла — тоже должно быть «отношение» :).
                                            А учиться программированию (это в первую очередь способность к алгоритмизации и формулированию алгоритмов в виде формальной записи) на хай-лоад сервисах — это странно. Лучше тренироваться в этом, всё-таки, на кошечках. Сложно сказать пригоден ли для этого руби, лично я посоветовал бы яву (хотя корифеи советуют начинать с фунциональщины), но уж ни как не си плюс-плюс.
                                            А вся эта арифметика указателей, освобождение памяти и прочая низкоуровневая оптимизация — это всего лишь частные проявления конкретной технологии, трюки. Им учиться нужно в последнюю очередь.
                                            • 0
                                              блин, отношение безглючности кода к скорости работы… ну как цена/качество…
                                              я не говорю что надо учиться на хай-лоаде… но когда программист, который не осознает того что происходит «под капотом» той или иной функции в языке (хотя бы примерно) берется за хай-лоад то он может таких дел наворотить, что мало не покажется…
                                              яву в качестве первого языка вообще нафиг… слишком она навороченная чтобы на ней учиться… даже для простейших задач иногда приходится писать такие дикие строки кода, что ужас просто… в то время как на сях это все пишется гораздо проще…
                                              • +1
                                                Не очень понял про отношение всё-равно. Вы в сравнении с ассемблером, что ли? Тогда да, а в сравнении с более другими языками, мне кажется, тут пролёт полный.
                                                >я не говорю что надо учиться на хай-лоаде… но когда программист, который не осознает того что происходит «под капотом» той или иной функции в языке (хотя бы примерно) берется за хай-лоад то он может таких дел наворотить, что мало не покажется…
                                                Плохой программист может наворотить дел где угодно и хай-лоад здесь совершенно не при чём. Писать высоконагруженные приложения нужно учиться специально! Если вы ставите на хайлоад человека, который специально не учился этому, то почти наверное огребётесь, за очень редким исключением. Это не значит, что данный программист плох или он в каком-то «не том» порядке изучал языки, просто у него нет этого конкретного умения. Если посадить 3Д-гуру, знающего потроха языка и компиляторов досконально, за простейшую (даже не хайлоад) веб-разработку точно так же можно огрести и знания «подкапотного пространства» не помогут. Я о том, что начинать с такого уровня смысла нет. _Сначала_ надо учить другому. И только _потом_ этому. И то, только если понадобиться или ради интереса и расширения кругозора.

                                                Это ява-то навороченная? Ява проще цпп раз в сто. Не, раз в двести! Хотя многословная, ага :).
                                                С си сложно сравнивать, слишком разные у этих языков цели.
                                                • 0
                                                  я в сравнении с другими языками говорю… сравните код на руби и на цпп… сравните их по скорости… и вы увидите что цпп будет работать быстрее, хотя не спорю что вероятность ошибиться существенно выше… я вот про это отношение… так сказать баланс…

                                                  Сначала надо учиться думать и учиться надо начинать на простейших алгоритмах… ну там сортировка пузырьком и прочее… а это проще на языка уровня с/с++…

                                                  От того что ява многосложная и возникают навороты… согласитесь логичнее писать a+b чем a.add(b)
                                                  • 0
                                                    > Сначала надо учиться думать и учиться надо начинать на простейших алгоритмах… ну там сортировка пузырьком и прочее… а это проще на языка уровня с/с++…

                                                    Сказки Булонского леса? Quick sort на Хаскеле vs Си будем сравнивать? В первом можно без труда выяснить, что делается, и вообще узнать, как работает алгоритм. Второй будет менее понятен человеку в любом случае.
                                                    • 0
                                                      мы разве говорим про функциональную парадигму? вроде нет… вроде речь шла про императив…
                                                      • 0
                                                        Мы говорим о понятности кода. В этом конкретном случае quick sort на Хаскеле помогает понять суть алгоритма, помогает думать.
                                                        • 0
                                                          мы также говорим и об обучении программиста, причем программиста общего назначения, следовательно парадигма может быть только императивная
                                                    • 0
                                                      Если зациклиться только на скорости, то вы правы на все сто и _в этом_ с вами никто не спорит, это очевидно. Пытаются объяснить, что есть случаи, когда скорость выполнения не настолько важная задача. Гораздо важнее скорость разработки, например (и стоимость, как производная), стоимость поддержки и цена ошибки. Так вот, судя по востребованности на рынке сишников и программистов на всех прочих языках, а так же стремительное развитие сектора динамических языков, баланс этот ваш далеко не в пользу си.
                                                      Я понимаю, что у сишников бзик на этой почве, но когда выбор стоИт скажем, руби скрипт за день или сишная программа за год даже при том, что скрипт будет считаться день, а сишная программа — две минуты, выбор, в большинстве случаев (не во всех, конечно!) будет очевиден. Даже если результат будет нужен всё-таки через две минуты, проще будет за малую копейку купить ресурсы в амазоновском облаке и крутнуть там этот скрипт. Тут на хабре подобную задачу описывали.

                                                      >Сначала надо учиться думать и учиться надо начинать на простейших алгоритмах… ну там сортировка пузырьком и прочее… а это проще на языка уровня с/с++
                                                      Да-а-а? Более чем неочевидное утверждение.

                                                      >От того что ява многосложная и возникают навороты… согласитесь логичнее писать a+b чем a.add(b)
                                                      И часто приходится складывать не числа и не строки? Я на яве лет 7 пишу. Приходится, но крайне редко (деньги). Наверное, это от того, что не я писал бухгалтерскую часть :), но кроме денежных операций как-то мало что в голову приходит, где оно могло бы широко использоваться? Научные расчёты и матрицы-шматрицы? Наверное, я сейчас от этого далёк, но чудится мне, что ява там не очень распространена, поэтому и проблемы такой нет :).
                                                      • 0
                                                        дык вы говорите про нормальных сформированных программистов, которые решают те или иные задачи;) тут я не буду спорить… инструмент нужно выбирать тот, который максимально подходит для данной задачи… я ведь тоже не только на си пишу… еще на пхп и на руби

                                                        раз неочевидное, тогда давайте оспаривать;)

                                                        «И часто приходится складывать не числа и не строки?»
                                                        именно складывать может и нет, но переопределение различных операторов (в основном у меня используются [], присваивание, сравнение) есть во многих написанных мною классах… данная возможность дает более высокий уровень абстракции… ведь согласитесь, что различные объекты вы сравниваете часто? а если условие многоэтажное, то тут гораздо лучше когда все состоит из <,>,==,!= чем из вызовов методов

                                                        вообще дискуссия переросла из того как лучше обучать программиста в дискуссию на тему «ява против с++ в разработке»… так что предлагаю закругляться.
                                                        • 0
                                                          >раз неочевидное, тогда давайте оспаривать;)
                                                          Написание простых учебных задач на более других, чем си, языках ничуть не сложнее, ничуть не менее педагогично, не менее полезно, не менее проще и неслонено ненужной для понимания алготирма, мутью с арифметикой указателей и слежением за памятью. А вот для изучения адресной арифметики и слежения за этой самой памятью, да, си вполне подходит. Но это малая часть того, чему нужно обучить программиста. И не всегда она нужна.

                                                          >а если условие многоэтажное, то тут гораздо лучше когда все состоит из ,==,!= чем из вызовов методов
                                                          Тоже неочевидно. Если с больше-меньше, ещё ладно, согласен (но тоже, а что сравниваем? Кроме денег, бестно приходят в голову разве что даты ещё), то у == и o1.equals(o2) в яве разная семантика, а переопределение одну из них уничтожит, что не всегда приемлимо. Но я о многословности явы спорить не буду — я в этом прекрасно осведомлён и тоже считаю, что многое там перебор. В разработке. А в обучении — ничего так.
                                  • 0
                                    Каким опытом обучения, кроме личного, подкреплена «постоянная фраза» насчет обучения на Си?

                                    По моему опыту как раз начавших с Си очень сложно потом сдвинуть с битов и указателей на что-либо более концептуальное. Тут был упомянут Си++, расскажите а на каком уровне Вы владете STL? А как Вы относитесь к таким вещам у обучении, как блоксхемы?
                                    • 0
                                      «Каким опытом обучения, кроме личного, подкреплена «постоянная фраза» насчет обучения на Си?»

                                      разговоры с коллегами и личные наблюдения за молодыми падаванами

                                      «По моему опыту как раз начавших с Си очень сложно потом сдвинуть с битов и указателей на что-либо более концептуальное.»
                                      Странно, я пишу на плюсах (и более того для меня это самая приятный язык программирования) и при этом спокойно отношусь к пыху, руби и питону (на первых двух пишу, третий могу спокойно читать)

                                      «Тут был упомянут Си++, расскажите а на каком уровне Вы владете STL?»
                                      На достаточном, чтобы спокойно на нем писать и представлять как оно работает

                                      «А как Вы относитесь к таким вещам у обучении, как блоксхемы?»
                                      положительно, но только на начальной стадии обучения, потом я считаю их излишком

                                  • –1
                                    Заинтересовал, хотя, конечно, по такому описанию не сделать выводов, чем он лучше того же PHP для разработки веб-приложений и лучше ли вообще (сейчас заминусуют, наверное :) ). Пока единственный плюс вижу — полностью ОО, к PHP, как известно, OOP прикручено через одно место :(

                                    В общем пиши, а мы почитаем, может действительно пора на руби и рельсы переходить, хотя его распространенность на хостингах явно ниже PHP и потому замена не всегда возможна, да и готовых продуктов типа форумов, блогов, CMS наверняка больше на пыхе.
                                    • 0
                                      рельсы лучше чем пых (а рассматривать надо именно рельсы или другие веб-фреймворки рубишные, на чистом руби пишутся десктопные приложения) тем что:
                                      1. есть нормальный мвц
                                      2. есть миграции
                                      3. хтмл генерится кучей хелперов (в том числе и для аякса)

                                      сам язык так же предоставляет нам кучу возможностей для обработки данных (в особых случаях код на руби в 20 строк можно заменить кодом на пыхе размером строк так в 150).

                                      По поводу готовых cms, блогов и прочего. Если вам нужен контентный сайт, то лучше чем жумла, друпал и иже с ними нету ничего. Но если вам нужен некий уникальный функционал, то писать его вам придется самому хоть на пыхе, хоть на руби. Для рельсов есть куча всяких плагинов, которые упрощают разработку типовых задач, таких как текггирование, видео-контент, фото-галереи и прочее.
                                      • +4
                                        Опять сравниваем фреймворк с языком?
                                        Сравнивали бы что ли с ZF, CodeIgniter, CakePHP, и прочим.
                                        • +3
                                          Во-во, как раз о том-же хотел написать :) Почему-то аргументация рубишников (рубчиков? рубовчан? :)) не идет дальше чистого php.
                                          • 0
                                            Это аргументация плохих рубистов, есть и хорошие. :)
                                          • 0
                                            по долгу работы видел зенд (сразу скажу что видел мельком, поэтому могу быть и не прав)… спасибо мне хватило… когда обычный контроллер для КРУДа модели с двумя-тремя полями и без внешних ключей занимает строк так 130… когда на рельсах аналог вытягивает в 70-80 строк… и при этом рельсовый код интуитивно читаемее чем зендовский получается
                                            • +2
                                              А с чем вы предлагаете сравнивать этого уродца (пхп)? (быдлокодеры! фас! дана команда заминусовать меня!) Ничего, кроме уеб-приложений написать на нём, по большому счёту, нельзя (я в курсе, что есть в теории можно, только кто ж это будет всерьёз делать?), поэтому и сравнивать его кроме как с другими инструментами, предназначеными именно для написания уеб-приложений бессмыссленно. Так что всё нормально здесь. Ну, а то, что как фреймворк пхп убог — ну, так вы ведь сами себе выбрали такой убогий инструмент, что ж теперь жаловаться, что вас, блин, обижают. Сравнивают удобные и мощные инструменты с кривым шаблонизатором-переростком. (Быдлокодеры! Команда «фас» номер два! Ату меня, улю-лю!)
                                              • 0
                                                Так не сравнивайте. :) А если сравниваете сравнивайте с аналогами, а не холодное с мокрым.
                                                • 0
                                                  А в чём проблема? Рельса и пхп — приблуды для изготовления уеб-приложений. И то и другое изначально предназначено и разработано для этого и только для этого и ни для чего более (извращения на побочные темы — множества меры ноль, поэтому не рассматриваются). Проблема в том, что пхп слишком убог при таком сравнении? Ну, так о том и речь!
                                                  Холодное с мокрым — это если бы кто-то стал сравнивать руби (ну, или пхп) с Qt, скажем :).
                                                  • 0
                                                    пхп — язык, рельсы — фреймворк, сранивать нельзя :) сравнивайте или пхп с руби в какой-либо области (не забывая, что пхп изначально создавался именно как язык для веб-приложений), или рельсы с, например, симфони
                                                    • 0
                                                      Ну и как можно сравнивать пхп с руби? Шаблонизатор с языком? :)
                                                      Пхп — то же самое, что и рельсы, они играют на одном поле. Если называть рельсы фреймворком, то и пхп — фреймворк, просто очень убогий (и с этим пхп-only «программисты», видимо, ни как не могут смириться). Если называть пхп языком (в смысле DSL, это, конечно, язык), тогда и рельсы — тоже язык (в том же самом смысле — DSL). Только рельсы — мощный DSL, а пхп… Правильно, опять убогий :) (ну да, опять сравнение не в пользу пхп, ну, звиняйте, братва, так уж у вас получилось хреново...). То, что на убогом DSL можно написать не очень убогий DSL, — ну, да, это специфика такая, средствами рельс можно тоже написать ещё более высокоуровневый DSL, просто это пока никому не нужно. Я именно что сравниваю сущности, используемые для одного и того же. Что касается памяти :), то я не забываю, что пхп создавался для веб-приложений (для этого же создавалась и рельса, заметьте), только пхп создавался, всё-таки не как язык, а как шаблонизатор (если быть точнее — интерпретатор форм). Так что, по-моему, сравнение более чем адекватное. Если вы продолжаете считать инече, повторю вопрос — с чем, по вашему, нужно сравнивать пхп?
                                                      • 0
                                                        >Ну и как можно сравнивать пхп с руби? Шаблонизатор с языком? :)
                                                        >только пхп создавался, всё-таки не как язык, а как шаблонизатор (если быть точнее — интерпретатор форм)

                                                        Вот именно, что создавался, 15 лет назад, однако за это время кое-что изменилось, никогда не слышали о переходе количества в качество? А тут не просто количественные (добавили функций) изменения были.

                                                        >в смысле DSL, это, конечно, язык

                                                        Все-таки согласны, что PHP язык? А значит сравнивать их можно ;) И не верю, что все сравнения будут в пользу руби, будут свои плюсы, будут свои минусы у каждого, а уж что кому важнее… даже если сравнивать жигули с бентли, то у жигули есть плюсы, иначе бы все давно уже пересели на бентли :)))

                                                        >То, что на убогом DSL можно написать не очень убогий DSL, — ну, да, это специфика такая, средствами рельс можно тоже написать ещё более высокоуровневый DSL, просто это пока никому не нужно.

                                                        Давайте-таки сравнивать, то что уже написано? Есть руби и пхп, мы уже договорились, что это языки, которые можно сравнивать. Есть рельсы и симфони (кейк, зенд, кодеигнитер, кохана… ). Если можно назвать рельсы языком, то почему не назвать и симфони или кейк языком?

                                                        >Я именно что сравниваю сущности, используемые для одного и того же.

                                                        php-фреймворки используются для того же, для чего и рельсы, почему вы их не хотите сравнивать?

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

                                                          >Все-таки согласны, что PHP язык? А значит сравнивать их можно ;)
                                                          Язык. Домен-специфик. И рельса тоже — домен специфик язык. А значит сравнивать их можно. Руби — язык общего назначения.

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

                                                          >Есть руби и пхп, мы уже договорились, что это языки, которые можно сравнивать.
                                                          Есть DSL пхп и DSL рельса. Мы уже договорились, что это домен-специфичные языки, которые можно сравнивать… Сравнивать пхп с руби я не вижу смысла (из жалости к пхп).

                                                          >Есть рельсы и симфони (кейк, зенд, кодеигнитер, кохана… ). Если можно назвать рельсы языком, то почему не назвать и симфони или кейк языком?
                                                          Потому, что пхп в этой части слишком беден, чтобы на нём можно было написать сколько-нибудь полноценный DSL класса хотя бы рельс. Да, кое какие средства есть и с большой натяжкой, перечисленные вами фреймворки (их, всё же, предпочитают называть фреймворками, правда же? даже их создатели) можно, наверное, называть и частично DSL, и частично фреймворком. Вы в рельсы заглядывали? А загляните! Эти пхп-шные фреймворки — всё-таки больше можно назвать «закатом солнца вручную», нежели тем, что получилось из рельс :).

                                                          >php-фреймворки используются для того же, для чего и рельсы, почему вы их не хотите сравнивать?
                                                          Ну, например, я не хочу сравнивать пхп-фреймворки с рельсами, потому, что я не знаю хорошо пхп-фреймворков. Вы знаете и то и другое? Прекрасно! Сравнивайте! Лично я запрещать вам это не собираюсь. Это же вы отказываете мне в праве сравнения вполне сравнимых вещей, а я-то — отнюдь нет.
                                                          • 0
                                                            >По-моему, исключительно количественные.
                                                            Ну у нас разные понятия о количестве и качестве просто. Для меня введение ООП даже в 4-ке было качественным измением.

                                                            >Руби — язык общего назначения.
                                                            What is PHP? PHP is a widely-used general-purpose scripting language… php.net/
                                                            И я его активно использую как язык общего назначения. Единственное, что php-gtk пока не пробовал, cli хватает для ежедневных задач вполне. Да, можно изучить язык bash например, но зачем, если и все так работает?

                                                            >Вы в рельсы заглядывали? А загляните!
                                                            Заглядывал, ничего не понял, потому-то эти топики и читаю :)

                                                            >Сравнивать пхп с руби я не вижу смысла (из жалости к пхп).… Это же вы отказываете мне в праве сравнения вполне сравнимых вещей, а я-то — отнюдь нет.

                                                            Я вот чисто логически не пойму, почему нельзя сравнивать один язык и язык (по вашему мнению) на первом написанный? Или можно сравнивать руби с рельсами? если нельзя то почему, рельсы ограничивают функциональность руби, запрещают (на физическом, а не идеологическом) уровне использовать все его возможности? Или непонятным для меня образом расширяют его возможности? Когда я говорю «возможности» я имею в виду принципиальную осуществимость, а не количество написанного кода. Можно что-то написать на чистом руби, чего нельзя написать на нем же в рельсах? Могут рельсы сделать что-то, что не может чистый руби? Если возможности руби и рельс равны, значит они равны, как языки :) и раз можно сравнивать рельсы с пхп, то почему нельзя сравнивать руби с пхп? Или операции сравнения языков не обладает транзитивностью? :)

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

                                                            Как вы можете судить как можно назвать PHP фреймворки если вы их не знаете хорошо? Я вот не берусь называть руби плохим языком или рельсы плохим фремворком лишь потому что с ними пока не знаком. Может быть познакомлюсь поближе и буду плакать и кусать локти делая очередной сайт на пхп-шном фреймворке (причину смотри ниже). А пока только задаю вопросы. почему вы не сравниваете два фреймворка и ничего конретного кроме общих слов об ущербности пхп из-за его происхождения от шаблонизатора не слышу.

                                                            >зачем пользоваться пхп при наличии руби или питона?
                                                            www.google.ru/search?hl=ru&q=%D1%85%D0%BE%D1%81%D1%82%D0%B8%D0%BD%D0%B3

                                                            из 9 хостинг-провайдеров (10-й результат вики) ни одна не поддерживает на виртуальном хостинге руби и толька одна питон, да даже perl не все поддерживают, php+mysql наиболее широко предлагающаяся на рынке окружение для разработки веб-приложений. То есть использовать PHP самая важная причина в современном мире — экономическая :) И. кстати, видимо по ней же до сих пор все не ездят на бентли :)
                                                            Не говоря уж о том, что порог вхождения в php традиционно считается низким, да я и сам его выбрал лет 10 назад именно из-за большой схожестью с C/С++, которые на то время были моими основными языками (после русского :) )

                                                            • +1
                                                              >Для меня введение ООП даже в 4-ке было качественным измением.
                                                              Уговорили. Одно качественное изменение было :). Как обычно, для этого языка, сначала не подумали даже в чём же там суть, в этом ООП и приделали, как обычно, кривее некуда… Это карма, безусловно.

                                                              >What is PHP? PHP is a widely-used general-purpose scripting language…
                                                              На заборе «Х..» написано, а там дрова лежат… И гиде он вайдли юзд, для скриптования генерала пёрпоза? На страничке пхп.нет?
                                                              >Да, можно изучить язык bash например, но зачем, если и все так работает?
                                                              Угу. Когда я говорю, что единственная причина — лень, пхп-шники, отчего-то, обижаются :).

                                                              >почему, рельсы ограничивают функциональность руби,
                                                              Ой!
                                                              >запрещают (на физическом, а не идеологическом) уровне использовать все его возможности?
                                                              О-о-о-ой! Где вы этого набрались???
                                                              >Или непонятным для меня образом расширяют его возможности?
                                                              Ну да. В том числе и языка. Дизайн языка позволяет расширять возможности языка в довольно широких пределах и рельсы этим активно пользуются.
                                                              >Можно что-то написать на чистом руби, чего нельзя написать на нем же в рельсах?
                                                              Можно ли написать что-то на чистом си, чего нельзя написать на плюсах? :)
                                                              Нет, даже не так — вот си, это по сути, чуть более удобный ассемблер. В большинстве компиляторов с си можно вставлять ассемблерные вставки. Вот это где-то близко :). Можно ли в таком случае (си, с ассемблерными вставками) говорить о том, что си и ассемблер являются одним и тем же языком? :)
                                                              >почему нельзя сравнивать руби с пхп?
                                                              Я же писал, что можно, только это не интересно и пхп сильно жалко становится :).

                                                              >Как вы можете судить как можно назвать PHP фреймворки если вы их не знаете хорошо?
                                                              Стоп-стоп! Я же не сравниваю и не сужу и прямым текстом говорю, что сравнивать не буду, поскольку не знаю их. Тем более не говорю, что они плохи. Фреймворки, безусловно, в некотором смысле, являются «расширением языка». Любая добавленная функция — не важно, в рантайм её добавили или вы в своей программе, является расширением языка. Одним из способов. Но такие расширения на основе функций, библиотек функций, библиотек классов, как раз принято называть фреймворками. В отличии от DSL. Руби позволяет расширить язык не только этим способом, но и другими. Тут как раз те количественные изменения, которые переходят в качество по закону диалектики :). Я не могу судить о самих этих пхп-фреймворках, но могу судить о том как, возможно, они построены, исходя из моих знаний о возможностях языка пхп. Так вот, на этом поле, руби предоставляет существенно больше возможностей. Речь не о функциональности — она может быть эквивалентной, а о дизайне и логике этих «расширений».

                                                              >То есть использовать PHP самая важная причина в современном мире — экономическая :)
                                                              Нет уж, договаривайте — не в современном мире, а в мире домашних страничек, для которых пхп изначально и разрабатывался (интрепретатор форм персональных домашних страничек — php-fi). Есть ещё, как минимум, явский мир (очень большой, кстати, и куда более интересный, чем пхп-мирок), которому, по большому счёту, насрать на первые 10 результатов вашего запроса :). Но… Что ж,… тут я, пожалуй, соглашусь — пхп рулит на такой мелочи, где даже рельсу разворачивать лень :).
                                                              • 0
                                                                >Угу. Когда я говорю, что единственная причина — лень, пхп-шники, отчего-то, обижаются :).
                                                                Я предпочитаю называть это бритвой Оккама :) А если серьезно, то в свое время убил много времени (да и денег немало) на изучение некоторых языков, например Forth, dBase, Pascal, да и asm тоже just for fun, как потом оказалось. Удели я это время изучению того же PHP — было бы куда рациональней. И как-то юношеский энтузиазм иссяк и изучать что-то, причем довольно непростое, ради самих знаний уже как-то не прельщает.

                                                                >Ну да. В том числе и языка. Дизайн языка позволяет расширять возможности языка в довольно широких пределах и рельсы этим активно пользуются.
                                                                >Я же писал, что можно, только это не интересно и пхп сильно жалко становится :).
                                                                Не пойму я вашей позиции — сравнивать руби с пхп — пхп жалко, а сравнивать рельсы (которые расширяют возможности руби) с тем же пхп — не жалко.

                                                                >Нет уж, договаривайте — не в современном мире, а в мире домашних страничек,
                                                                Экономические причины они везде одинаковы, и в мире домашних страничек, и в мире транснациональных корпораций, все хотят минимум вложений и максимум дохода. И еще неизвестно каких «страничек» больше — «домашних» на php или «недомашних» на руби или питоне. Особенно если к категории «домашних» относить и, например, pepsi.ru

                                                                >Но… Что ж,… тут я, пожалуй, соглашусь — пхп рулит на такой мелочи, где даже рельсу разворачивать лень :).
                                                                Кто-то говорил про лень пхпшников? ;) Просто есть экономическая целесообразность и для заказчиков, и для разработчиков. Если у заказчика бюджет на сайт 200$ в год, то предлагать ему вдску даже за 10$ в месяц для разворачивания рельс (причем не давая никаких гарантий работоспособности сервера и его безопасности, т.к. на администрирование этого бюджета уже не хватит) для разработчика означает работать бесплатно, т. к. еще за дизайн надо заплатить из этих денег.

                                                                • 0
                                                                  >за 10$ в месяц для разворачивания рельс (причем не давая никаких гарантий работоспособности сервера и его безопасности
                                                                  Ну, я и говорю про наколеночные домашние страницы. У пепси.ру разве 10 баксов бюджет? :)
                                                                  А, кстати, вот не понял. Вы за 10 баксов в месяц даёте гарантию работоспособности сервера, его безопасность и администрирование? Пхп — это такая особая уличная магия, которая позволяет всё это предоставить и гарантировать(!) за 10 баксов? Круто, ага.
                                                                  • 0
                                                                    наколеночные домашние страницы делают вообще на бесплатных хостингах без всякого пхп :)

                                                                    про бюджет пепси не знаю, привел пример что мир пхп это не только мир домашних страниц, как вы думаете (или делаете вид, что думаете ;) )

                                                                    Я за 1,5 бакса в месяц даю гарантию, что за последний год аптайм был 99, 98% :) Если я посоветую заказчику какой-нибудь вдс за 10$ в месяц, то мало того, что мне самому все поднимать надо будет (если дебиан-базед, то подниму без проблем скорее всего, иначе гуглить придется, на виртуалку у себя ставить и т. п.), но главное отвечать за безопасность всего сервера. Вдски (и дски) обычно предоставляются как есть, на шаред хостинге я отвечаю только за «дырявость» скрипта, на выделенном мне (а кому еще?) надо будет отвечать и за безопасность ос, апача того же, реагировать, если не дай бог взломать кто-то попытается и т. п.), а бюджет не тот, чтобы я еще и сертификаты администратора *nix шел получать, да и не привлекало никогда администрирование особо, свою машину мучать — это одно, отвечать за чужие совсем другое

                                                                    • 0
                                                                      >Я за 1,5 бакса в месяц даю гарантию, что за последний год аптайм был 99, 98%
                                                                      Сдаётся мне, что эта «гарантия» мало чего стоит, на самом деле. Это скорее способ уйти от отвественности — «за баги пхп, апача, ос, ддос и прочее я не отвечаю». Мило, и удобно для наколеночных проектов. Действительно, _тут_ рельсам делать пока нечего. Полуторабаксовых рельсовых хостингов, аналогичных таковым же пхп-шным я не знаю :).
                                                                      • 0
                                                                        Ну суть в том, что я могу предложить заказчику несколько вариантов хостинга от бесплатного до собственного дата-центра с необходимой командой и рассказать про преимущества, недостатки и обоснование стоимости каждого из них (утрирую, конечно). В случае с Ruby/Python нижняя планка вариантов сильно повышается, даже если не принимать в расчет бесплатные.

                                                                        И действительно уход от ответственности — я не *nix-администратор и не беру на себя обязательства, которые не могу выполнить, максимум беру на себя контакт с саппортом хостера. А VDS (и DS), сравнимые по цене с PHP-хостингами предоставляются (те, что я видел) или на условиях полной ответственности клиента или его персонала за безопасность, прежде всего (работу серверного софта из шелла я может не за 5 минут, особенно если не Debian-based, но настрою, но вот утверждать, что у меня открыт только необходимый минимум портов, и работают только необходимый набор демонов я не стану, а на месте хостера, естественно не предоставлял бы никаких гарантий, если дают рутовый доступ, может я там умудрюсь рутовый доступ без пароля открыть), или по цене не сравнимой с ценой PHP-хостингов. Максимум, что саппорт хостинга делает бесплатно, насколько я знаю, это по запросу клиента сбрасывает систему в исходное состояние или восстанавливает ее из бакапов (и то, думаю, если каждый день их просить, то или аккаунт закроют или предложат платить :) ). Так что заботясь о благе заказчика, я не могу рекомендовать ему использование VDS без оплаты стороннего (или силами хостера) администрирования, а VDS с таковой оплатой обычно выходит за рамки бюджета заказчика, зачастую в разы. А заказчиков, знающих что такое рутовый доступ по шеллу я не встречал :)

                                                                        Естественно, если вы представляете фирму или команду, в составе, которой есть профессиональные админы, ну или сами таковым являетесь, то можно и нужно предлагать клиенту весь спектр услуг связанных с созданием, размещением и поддержкой сайта, но опять-таки делать вы это будете не бесплатно, пускай и не впишите отдельной строкой в счёт. Но я работаю один, и в областях выходящих за область моей компетенции или предлагаю типовые решения, или советую куда обратиться, максимум могу взять на себя общение с другим специалистом, хотя бы потому что знаю побольше заказчика, что собственно от этого специалиста нужно, что должно быть в ТЗ для него, что должно быть на выходе и как его работу контролировать. Но я ничего не решаю за заказчика, только рекомендую, решения принимает он сам, он же несет за них отвественность. Или вы считаете, что раз я посоветовал ему, например, зарегистрировать домен в Ру-Центре, то я должен брать на себя всю ответственность за работу всей их инфраструктуры?
                                                                        • 0
                                                                          >И действительно уход от ответственности
                                                                          Вот-вот. Не обманывайте себя (и заказчика) словом «гарантия».

                                                                          >сравнимые по цене с PHP-хостингами
                                                                          По-моему, разница 10 или 20 (ну, даже пусть 50) баксов для оплаты хостинга для нормального заказчика, по-моему, исчезающе мала. Если он _даже_ на этом хочет съэкономить _такие_ гроши… Ну… Я уже говорил о наколеночных домашних страничках. Да, это сектор пхп и конкурентов там ему пока нет. Но… ведь это не интересно, бесконечно ваять хоумпейджи и сайты-визитки для нано-заказчиков, которые (готов поспорить), что большинство не вполне отдают себе отчёт — зачем им нужен сайт. «Шоб було». Иёп, тут пхп вне конкуренции.
                                                                          • 0
                                                                            Ну «гарантия» слово я не употребляю в отношении хостингов и прочих вещей, которые не контролирую, гарантии даю только на результаты своей работы, то есть, в основном, на код пхп. Все остальное только рекомендую предоставляя альтернативы как минимум в виде ссылки на гугл :)

                                                                            Действительно неинтересно, и спорить насчет того, что знают зачем сайт, не буду :) Интересные заказы редко встречаются, разве что какой-нибудь «сеошный»плагин для вордпресса, требующий и псевдомногопоточность реализовать, и работу со списком проксей с их автоматической проверкой на работу вообще, уровень анонимности и то, что они не в блеклисте какого-нибудь хоста. А так да. хоумпеджи, блоги, визитки, иногда партнерские «магазины» и т. п. И даже не прочь бы выйти на уровень повыше, и не важно на каком языке писать для этого придется, но что-то не встречал предложений на удаленную работу начинающих «рубистов», «питонщиков», «сишарпников» или «явистов», даже бесплатную, чисто на портфолио. Не показывать же в качестве портфолио примеры из туториалов и мануалов? :) А вот PHP-программист такую работу найти может.
                                                                            • 0
                                                                              >но что-то не встречал предложений на удаленную работу начинающих «рубистов», «питонщиков», «сишарпников» или «явистов»

                                                                              Что касается конкретно руби, то в гугловской группе по РоРу такие предложения периодически встречаются.
                                                                              • 0
                                                                                Спасибо за наводку. пойду подпишусь :)
                                                                  • 0
                                                                    >Не пойму я вашей позиции — сравнивать руби с пхп — пхп жалко, а сравнивать рельсы (которые расширяют возможности руби) с тем же пхп — не жалко.
                                                                    Ну, вот, с больной головы на здоровую. Я говорил о том, что рельсы с пхп вполне можно сравнивать. Они играют на одном поле. А сравнивать руби с пхп — какой смысл сравнивать язык с шаблонизатором? (кажется, я это уже говорил). Я вот как-то надысь писал конкурсный пропозал для подразделения одной из дочек дзайбацу мацусита (у нас она известна как производитель телевизоров, принтеров, фото-, видео- и прочей электроники) на разработку ПО для их девайса с помощью руби, qt и сей (для драйверов). Моё предложение не прошло, прошло альтернативное, самое большое отличие — вместо руби там был питон (питонистов найти у нас полегче). Ответьте, положа руку на сердце, стал бы кто-нибудь всерьёз рассматривать такого рода предложение с пхп в качестве основного языка для разработки десктопного кроссплатформенного графического приложения для работы со специализированным девайсом? И стал бы кто-нибудь всерьёз писать даже такой пропозал? После этого ещё раз задайте (себе) вопрос о смысле сравнения руби и пхп в общем случае :). Вот поэтому и жалко — если в вебе пхп и рельса хоть как-то конкурируют, то вне веба пхп смысла не имеет вообще. Можно тешить себя фразами с пхп.нет и вашей системой мониторинга (добавить сюда второго известного мне человека — болка с его периодом писания полезных утилит на пхп). Но это все не серьёзно.
                                                                    • 0
                                                                      Это я все прекрасно понимаю, место пхп в вебе, максимум замена шеллового языка (уж по сравнению с языком cmd он явно мощнее), гуи на php писать следует только при очень серьезных причинах. Но все равно, сравнивать можно и нужно либо языки, либо продукты на них написанные. Говорим мы о веб-разработке. Вот я сейчас дома поставил руби как cgi модуль апача, «hello, world» выел на ruby.localhost, рельсы пока ставить не собираюсь. какие преимущества использования руби (а не рельсов) я получу, если, например, начну сейчас с нуля писать скрипт каталога сайтов и доски объявлений? без фреймворков, кмсок, только стандартные средства языка и библиотеки для работы с http и mysql, если таковых нет встроенных?

                                                                      Cкажем вкратце описать почему для этого я буду использовать PHP, а не С я могу, хотя у С есть свои плюсы, но есть и минусы, а вот о плюсах и минусах использования чистого Ruby в качестве языка серверных веб-скриптов я не знаю ничего, кроме этой статьи:

                                                                      * Язык предельно лёгок в изучении в сравнении с другими ЯП
                                                                      * Полностью объектно-ориентированный
                                                                      * Нет необходимости писать много кода
                                                                      * Очень расширяемый
                                                                      * Open Source
                                                                      И то, как минимум в двух пунктах я сомневаюсь, насчет много кода (но не знаю относится это к рельсам или к самому руби, потому не считаю), предельной легкости и объектно-ориентированности (есть мнение, что руби объектный изначально, а не сменил ориентацию с процедурной :) )
                                                                      • 0
                                                                        >какие преимущества использования руби (а не рельсов) я получу, если, например, начну сейчас с нуля писать скрипт каталога сайтов и доски объявлений? без фреймворков, кмсок, только стандартные средства языка и библиотеки для работы с http и mysql, если таковых нет встроенных?

                                                                        Вот потому человек и сравнивает язык пхп с руби-фреймворком, потому что пхп сам по себе можно считать фреймворком — в него встроены средства для работы с cgi, бд, куками, сессиями и т.п. — все то что в языках общего назначения подключается через отдельные модули/фреймворки.
                                                                        • 0
                                                                          Что-то мне подсказывает, что рельсы — это нечто большое, чем набор функций/классов для работы с бд, куками и сессиями.

                                                                          А результат сравнения любого приличного веб-фреймворка с «голым» php я вполне могу представить:
                                                                          — для реализации простейшего одностраничного сайта с выводом полей одной таблицы БД в… понадобилось 3 строчки кода, на php — 33, причем без абстракции от БД, обработки ошибок, поддержки шаблонов и макетов, валидации, легкой расширяемости для поддержки чего-то кроме html, авторизации и аутенфикации и т. п.
                                                                          — для добавления базового CRUD функционала на… понадобилось, еще 3 строчки, на PHP еще 50
                                                                          и т. д.
                                                                          А потом сделают вывод, что php для разработки веб-приложений если и годится, то с написанием мегабайтов кода, а вот фреймворк… позволяет решать 90% типовых задач только путем конфигурирования и указания источника данных. Причем самое интересное, что если описывать решения, не приводя конкретного кода, а словами вроде «одной строкой кода в контроллере из url формата /article/%artice-title-slug% мы получаем из БД (с поддержкой абстракции на нескольких уровнях, контроле прав доступа, автоматической санитазацией параметра для исключения sql-injection атак и прочим „сахаром“) соответствующий объект Article и этой же строкой передаем его в отображение с автоматическим выбором нужного формата (html, xml, json и т.п.) в зависимости от http заголовков запроса», то всем будет понятно, что PHP отстой, а вот этот фреймворк очень удобен для разработки приложений, кроме одного маленького «но» — этот фреймворк может быть написан на этом отстойном языке.

                                                                          Давайте все-таки сравнивать языки с языками, библиотеки функций/классов с библиотеками, а MVC (или другие) фреймворки с их аналогами?

                                                                          • 0
                                                                            >Давайте все-таки сравнивать языки с языками
                                                                            Давайте, давайте ужо. Я у вас уже спрашивал — дадите ли вы зуб за то, что хоть кто-либо из разбирающихся в теме заказчиков не выкинет в корзину сразу нечитая «проект», который не веб и который предлагается написать на «языке» пхп? А «архитектора» такого проекта не занесёт в список людей с которыми не стоит иметь дело никогда по причине неадекватности? Нормальный проект, не вашу мониторилку (мир ей), не болковские утилиты на 20 строк для удаления мусора из жпегов (мир им), а что-то серьёзное. И пример, пожалуйста. Вот тогда, да, можно уже будет сравнивать языки с «языками» :). А так это будет похоже на избиение младенцев :).
                                                                            • 0
                                                                              Конечно не дам, но вообще разговор начинался в контексте веба (или у рельс другое основное назначение?), и предлагал я сравнивать в том же контексте (мне это казалось само собой разумеющимся, грубо говоря один и тот же апач с «прикрученными» пхп и руби, ну и мускул или другая БД), а если уж хочется рельсы сравнить (слышал тезисы типа «мы говорим руби в вебе — подразумеваем рельсы» :) ), то тогда и сравнивать надо не голый пхп с рельсами. а пхп с фреймворком (лично я бы выбрал симфони или кейкпхп для сравнения, ZF и CI мне не очень понравились, слишком, имхо, низкоуровневые и недостаточно абстрагируют и ненавязчиво принуждают к написанию простого, понятного, реюзабельного и т. п. кода) и руби с фреймворком
                                                                              • 0
                                                                                >но вообще разговор начинался в контексте веба (или у рельс другое основное назначение?)

                                                                                Вот именно. В контексте веба. У рельс не другое назначение. А ровно то же, что и у пхп. Поэтому их можно сравнивать. Какой раз я это сказал? :)
                                                                                Контекст идентичен. В чём проблема? Ах, в том, что пхп в этом сравнении проигрывает со свистом? Ну так это не проблема самого сравнения, а проблема исключительно пхп. Ну, такой вот он убогенький фреймворчок оказался. Об этом речь и только об этом.

                                                                                >слышал тезисы типа «мы говорим руби в вебе — подразумеваем рельсы» :)
                                                                                Это проблемы исключительно говорящих. На деле всё более интереснее и многообразнее. :)

                                                                                >тогда и сравнивать надо не голый пхп с рельсами. а пхп с фреймворком
                                                                                Да тоже можно, я и это уже более одного раза сказал :). Я о том, что нет причин не сравнивать пхп с рельсами :).
                                                                                • 0
                                                                                  >Я о том, что нет причин не сравнивать пхп с рельсами :).

                                                                                  Ну причину вы сами указывали :) дословно не помню, но смысл в том, что на базе Рельсов можно создать еще более абстрактный DSL для веба, но никому это не нужно, а раз для пхп создали, то и сравнивать, имхо, нужно самые высокие уровни абстракции из существующих ;) А то получается сравнение средневековой мастерской и современного цеха
                                                                        • 0
                                                                          >какие преимущества использования руби (а не рельсов) я получу, если, например, начну сейчас с нуля писать скрипт каталога сайтов и доски объявлений?

                                                                          Большие и никаких :).
                                                                          Никаких — потому, что, ну, язык, ну, можно писать, по сравнению с пхп — всё плохо, поскольку нет встроенного модуля, облегчающего работу с хттп, надо привыкать к остутствию нагромождения бессмысленных функций делающих одно и то же и отличающихся только порядком аргументов и скоростью работы (пропадёт часть тайного знания, отличающего пхп-гуру от непосвящённого) и руби медленнее. Ага, ещё нет встроенной возможности смешивать код с разметкой :). Ну и состояние mod_ruby в плане юзабельности в продакшене мне, например, неизвестно (некоторое время назад говорили, что оно малою пригодно к применению — ну, чего не в курсе, того не в курсе).
                                                                          Большие — это приятный, продуманый, логически стройный и красивый язык. На нём приятно писать. Необходимость писания на пхп лично у меня вызывает тошноту — орочий язык, какой-то :), нелюдской.
                                                                          По вашим пунктам — легкий, ага. Надо разобраться с замыканиями (блоками, в терминологии руби) — они широко используются и очень удобны, но для императивщика выглядят дико — это «превед» из функциональных языков. Очень удобный, но требует привыкания. Есть и ещё сложности, но на первых порах с ними ещё надо постараться столкнуться. Всё остальное — предельно просто. Язык создавался для людей, а не для лексического анализатора (как пхп). Несмотря на приветы из функциональщины — для императивщика язык всё-таки привычно прост, проще, чем смолток, например (раз уж о нём заходила речь).
                                                                          «Полностью объектно-ориентированый» — это какая-то рекламная мантра :), несущая мало смысла. Да, в руби «всё есть объект» и можно писать — послать объекту класса такого-то, со значением еденица сообщение «прибавить» с агрументом — два, — есть для этого соответствующий синтаксис и есть случаи, когда он оправдан. Но, опять же, язык создан для людей, а не для лексических анализаторов, поэтому, в большинстве случаев, прокатывает привычная запись «1 + 2» :) (там есть некотороя тонкость с пробелами и в некоторых случаях выразение, валидное в других языках, может быть распознано неверно, поэтому лучше ставить пробелы с обеих сторон от знаков арифметических операций, ну, считайте это небольшой платой за «всё есть объект».
                                                                          Код можно писать кратко. Да. И, при этом, красиво. В каком-то смысле руби — это улучшеный перл :) — от перла там осталось много и хорошего и чутка не очень, но этим «не очень» крайне редко пользуются (философия несколько другая) и, говорят, в будущем истребят.
                                                                          Расширяемый — ну, да, на основе руби сделали несколько интересных DSL — в каком-то смысле это всё расширения языка. Те же рельсы, Rake (аналог make) и прочее.
                                                                          Опен-сурс — ну, то, что я в генте могу собрать его в нужной мне комплектации — конечно, достоинство, в какой-то степени :).
                                                                          Для серверных веб-скриптов голый руби вполне пригоден (с оговорками выше), разве что надо будет или выдрать откуда-нибудь или написать самому (благо это не сложно) модуль работы с хттп. А, да, и что-то для шаблонизаторства (ну, тут выбор уже готового велик, велосипед изобретать не надо). Можно, но большого смысла здесь нет — велосипеды уже изобретены и есть на свете уже немаленькая кучка существенно менее тяжёлых, чем рельсы, фреймворков. По сути — это наборы одних и тех же библиотек, сдобреных бОльшей или меньшей порцией «клея» — обвязкой, собирающей всё вместе для удобства, некоей идеологией и выполняющей однотипную рутину. Если не понравится существующий, можно поглядеть как это сделано (обём «клея» там невелик, как правило) и написать свой аналог по вкусу…
                                                                          • 0
                                                                            Спасибо за подробный экскурс, чего-то подобного я с самого начала этого «холивара» и хотел :)
                                                                            Главный в минус руби по вашему описанию для меня лично — шаблонизатор. Хотя и привык разделять «бизнес»- логику и представление, но, видимо, придется для веба еще один «язык» изучать (или придумывать самому и регекспами гонять :), а может пхп прикрутить попробовать, раз уж он шаблонизатором создан :)))))) ), как-то не тру, по-моему, будет писать puts "<html… >\n", не для того я с Си ушел на пхп… ну или Smarty вспоминать, если есть шаблонизаторы с его синтаксисом (а наверняка есть, я даже на сях такой видел :) ). C http, наверное, проблем не будет, наверняка доступ к argc/argv в том или ином виде есть, а прикручивают, как я понял, руби к апачу чаще всего через cgi (fcgi).

                                                                            Просто я привык использовать сторонние библиотеки/фреймворки после попытки изобретения велосипеда, больше понимания того, что внутри происходит, да и сравнение своего кода и кода опытных разработчиков показывает какие нюансы языка я упустил. А вызывать высокоабстрагированые функции/методы в режиме «черного ящика» не мой стиль :(
                                                                            • 0
                                                                              Да нет там никакого минуса. Просто голый руби в качестве веб-скриптового языка какой смысл использовать, если там уже сделали десяток, а то и больше цельных вкусных штук и несколько десятков просто приблуд, которые подключаются к любому цельному фреймворку. «Шаблонизаторы» — от erb — как jsp и пхп, до xslt на любой вкус. Всякие костыли типа смарти, наверное, тоже есть, только это ведь костыль довольно непонятного назанчения, зачем его тащить в хорошее место… Велосипеды… Интересно, а xslt-трансформер вы ещё свой не писали? :)
                                                                              • 0
                                                                                Тоже мог бы сказать про голый пхп и вкусные штуки, но договорились прекратить «холивар» ;)

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

                                                                                Еще хуже, когда я открыл для себя xml первая моя мысль была, что он идеально подходит для описания сайта (включая структуру СУБД), в том числе и как язык описания шаблонов :) так что я создал свое расширение XML (и написал для него трансформер, конечно на php :) ) и очень расстроился, когда узнал, что уже есть xslt и я не реализовал и четверти его возможностей, а встроенный в php трансформер работает на порядок быстрее моего :(

                                                                  • 0
                                                                    >из 9 хостинг-провайдеров (10-й результат вики) ни одна не поддерживает на виртуальном хостинге руби и толька одна питон, да даже perl не все поддерживают, php+mysql наиболее широко предлагающаяся на рынке окружение для разработки веб-приложений. То есть использовать PHP самая важная причина в современном мире — экономическая :) И. кстати, видимо по ней же до сих пор все не ездят на бентли :)

                                                                    Глупые аргументы. Если в одном из десяти автосалонов вам предложат бентли, а в остальных — жигули (за сравнимую цену), вы конечно же купите жигули, не сомневаюсь. Миллионы мух не могут ошибаться.

                                                                    Действительно, хостинг для руби/пайтона найти сложнее, но вполне реально. Тем более что никто вас не заставляет каждый раз искать нового хостера, да и свет клином не сошелся на виртуальном хостинге. Плюс даже если пхп-хостинг будет дешевле, вряд ли это окупит затраты на поддержку пхп-быдлокода, а ресурсов пхп ест побольше чем тот же пайтон. Хотя конечно, для домашних веб-страничек пхп — идеальный вариант. А еще на нем можно писать дорвеи и дейтинги :)

                                                                    >Не говоря уж о том, что порог вхождения в php традиционно считается низким, да я и сам его выбрал лет 10 назад именно из-за большой схожестью с C/С++

                                                                    Именно этот низкий порог вхождения обеспечил пхп славу языка быдлокодеров. Сомневаюсь что это преимущество пхп над руби/пайтоном. Вижуал бейсик что-то не в большом почете у программистов.
                                                                    И никакой большой схожести с С/С++ у него нет — разве что синтаксис немного похож.
                                                                    • 0
                                                                      >Глупые аргументы. Если в одном из десяти автосалонов вам предложат бентли, а в остальных — жигули (за сравнимую цену), вы конечно же купите жигули, не сомневаюсь. Миллионы мух не могут ошибаться.

                                                                      Немного не так — ко мне придет заказчик и скажет «вот тебе пачка денег, купи мне любую машину, главное чтобы ездила, закажешь тюнинг, чтоб тут был кондиционер, тут бар, тут магнитола и пульт ДУ общий, и вообще чтоб в веселнькую расцыеточку ее перкрасили, заводская окраска как у всех мне не нравится, потом машину обкатаешь, купишь страховку на год, заправишь полный бак и передашь мне с ключами, что останется — тебе за работу». Я прикину, что даже если у меня есть возможность взять бентли бесплатно 9как и жигули, впрочем), то на покраску, тюнинг, страховку и бензин для бентли у меня уйдет все что он мне дал, а суетиться я получается буду бесплатно, только чтоб потом показывать фотографию этого бентли (а по внешнему виду и не поймешь, бентли там или жигули после тюнинга и покраски) другим потенциальным клиентам, ну фотки «начинки» тем. кто разбирается (да еще рискуя получить промблемы из-за показа этих фоток). не говоря уж о том, что заказчик может просто попросить поковыряться в его машине, магнитолу там прикрутить, и таких заказчиков на жигулях на порядки больше, чем на бентли. если каждому желающему чуть-чуть подтюнинговать жигули предлагать их выкинуть, сесть на бентли (который и бензина больше жрет, и бензин качественный нужен, на каждом углу не продается) и заплатить за тюнинг бентли с нуля, то и с голоду можно помереть, пока дождешься того, кто согласится хотя бы с тем, что теперь ему за бензин нужно будет дороже платить, причем только на определнных бензоколонках, даже если приспичит где попало не заправишься.

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

                                                                      Повторю, речь идет не о моем личном сайте, для которого я выбираю средства реализации, а о сайтах заказчиков с весьма ограниченным бюджетом, им важна общая стоимость владения и каждый доллар, который я им предложу потратить на что-то кроме собственно разработки будет по сути или из моего кармана, или уменьшением конкурентоспособности моего предложения, а рынок тесный в сегменте SOHO, как это модно говорить, конкурентов много, а в Индии теплее :(. А дорвеи, точнее доргены, сплоги, грабберы и прочий «сео» софт писать на php говорят не очень, нет многопоточности нормальной прежде всего, чтобы работать одновременно с сотнями хостов через десятки проксей :) А насчет того, что на виртуальном хостинге свет клином не сошелся, так даже вдску надо админить, и не просто поднять апач, бд, PHP/Perl/Python/Ruby, но и обеспечить безопасность. На кого эти заботы возложить индивидуальному веб-разработчику — сказать вот я вам сайт сделал, вдс за 5$ в месяц нашел, вот пароли для ssh доступа, ищите админа, чтоб следил за безопасностью, ну или хостеру платите, всего 10$ в час обойдется, если проблемы будут (а они будут, потому что я не администратор и прежде всего безопасность даже не возьмусь настраивать, домашний дев-сервер за двумя, даже тремя натами — это одно, а рабочий сервер в паблике совсем другое),… куда меня это заказчик пошлет если у него бюджет годовой на сайт 200$?

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

                                                                      Низкий порог вхождения — плюс языка, а быдлокод — минус быдлокодеров. PHP просто не ставит жестких границ — хочешь забивать на приведение типов, объявление и инициализацию переменных, поддержку принятых стандартов, паттернов, форматов и т. п. проектирования, архитектуры, оформления кода и т. д. — пожалуйста. Хочешь писать хороший, качественный, переносимый, легко поддерживаемый, в конце-концов просто красивый код — пиши. Да, есть определенные ограничения, та же многопоточность, или привычные с других языков средства ООП, но типовые задачи веб-разработки для SOHO PHP спосбен решать, имхо, не хуже основных конкурентов, а совокупная стоимость решения меньше (если не допускать появления быдлокода в проекте). В общем я считаю, что на настоящем этапе развития веб-рынка в России для сегмента SOHO LAMP (где P — PHP, а не Perl или Python :) ) пока еще остается предпочтительной платформой, про энтерпрайз, битуби и т. п. уровень не говорю, предложи мне кто разработать движок с нуля для того же pepsi.ru я бы скорее стал его на С разрабатывать, чем на PHP, или стал бы изучать Java или Python, но лишь потому что уверен, что для заказчика такого уровня выделенный сервер, а то и кластер, и «выделенный» для него админ, а то и команда админов не проблема, скорее они посмеются над предложением даже вдску взять.

                                                                      >И никакой большой схожести с С/С++ у него нет — разве что синтаксис немного похож.
                                                                      Схожесть синтаксиса я и имею в виду, у программиста на C не вызовет шока операция += или ++ или присваивание внутри выражения, в принципе еще у Java схожий из известных мне, но платформа не так распространена, шаред хостинг с поддержкой Java найти, наверное, еще сложнее, чем с питоном/руби

                                                                      P.S. Устал что-то доказывать, точнее просить, чтобы мне объяснили недостатки PHP по сравнению с Ruby/Python важные для SOHO без ссылок на быдлокод, а то странно я буду выглядить перед заказчиками, аргументируя необходимость увеличения их постоянных накладных расходов в разы (если считать, что время разработки не изменится сильно, от того что я выберу RoR, а не symfony или CakePHP) тем, что на PHP моя разработка будет написана быдлокодом, а на Ruby будет соответсвовать даже самым строгим требованиям :)
                                                                      Послежу за этим циклом статей, почитаю комменты, попрактикуюсь на домашней машине, в холивары попробую не ввязываться (хотя и сложно это для меня), может «просветлюсь» или просто увижу, что решение одной и той же задачи, например создание сайта-визитки или блога на Ruby занимает в разы меньше времени, чем на PHP и за счет этого можно будет предлагать более выгодные для заказчика условия по сравнению с php-быдлокодерами, предлагать движок «стандартной» визитки не за 10 часов и 100$, а за 5 и 50 :)
                                                                      • +1
                                                                        Лень уже отвечать на каждый пункт, спор будет бесконечным, предлагаю его закончить.
                                                                        Отвечу только на P.S.
                                                                        На мой взгляд основной недостаток PHP по сравнения с модными нынче Ruby/Python — это его дизайн. Язык изначально задумывался как некий вижуал бейсик для веба, и он продолжает им быть и сейчас. Начать заниматься веб-разработкой легче на PHP, точно так же как и начать «программировать» легче на вижуал бейсике. Но когда вы решите продвинуться дальше Personal Home Pages (или калькулятора на VB) — сам язык будет вас тормозить.

                                                                        Не нужно ждать цикла статей о превосходстве чего-либо над PHP. Просто возьмите и попробуйте тот же Python. Решение практически любой задачи на нем будет выглядеть более лаконично, элегантно и понятно, чем на PHP. Просто потому что язык задумывался именно как лаконичный и легкочитаемый.
                                                                        Если вы решаете определенную задачу на PHP за 5 часов и берете за это 50$ — на Python вы решите ее быстрее, а сколько денег за это брать уже ваше дело.
                                                                        • 0
                                                                          Согласен, что пора бы закончить :) Но напоследок отвечу, без задавания вопросов

                                                                          Насчет дизайна спорить и не стал бы, особенно учитывая, что практически все развитие языка от PHP3 до PHP6 (только по докам) на моих глазах происходило. А программировать я начинал на ассемблере 8080, когда он начал меня тормозить открыл для себя BASIC (никаких Visual или хотя бы Quick), потом так же Си и т.п. А для веба начинал на Си, потом открыл PHP3, удивительно вовремя (когда я понял, что в pHP 3 мне не хватает ООП) вышел (вернее, стал доступен на массовых хостингах) PHP4; когда и он стал меня тормозить, открыл CMS, относительно недавно PH5 и одновременно PHP-фреймворки, как раз когда понял, что CMS меня сильно ограничивают и заставляют писать ужасный код.

                                                                          Почти наверняка я еще просто не почувствовал ограничений моих текущих (и осваиваемых) инструментов, но сдается мне, что к тому времени PHP6 и новые фреймвоки на его основе их снимут :) С одной стороны не очень хорошая тенденция, что фактически язык (стабильные, получившие широкое распространение «мажорные» версии) меня догоняет постоянно, вдруг вообще пути разойдутся, а с другой — большое количество популярных готовых решений и приложений на их основе, зачастую используемых людьми вообще далекими от программирования, которым сразу или через некоторое время требуется разовая (или периодическая с довольно большим периодом) «доработка напильником».

                                                                          Насколько мне известно в мире Ruby/Python пользователи (серверные так сказать) или сами поддерживают решения (полностью свои, или «полуфабрикаты» на базе фреймворков, или готовые на базе CMS), или связаны уже постоянным сотрудничество с теми, кто им устанавливал, настраивал. Объявления на какой-нибудь бирже фрилансеров типа «Need to minor fix our Ruby script» вижу довольно редко. То есть спрос на этом рынке меньше намного, можно сказать на порядки (причем десятичные) и переходить на новые (для меня) языки мне кажется несколько опрометчиво.

                                                                          Хотя совету попробовать последую, точнее уже следую, следя за этими топиками, и не просто читая, а и экспериментируя на локальном машине. Возможно и сменю мнение о PHP, но, скорее всего, даже не смотря на то, что буду считать его уродским, работать с ним придется еще очень долго, пока мои потенциальные заказчики не будут считать также, а их хостеры не обеспечат поддержку этих языков.
                                                          • 0
                                                            Толсто!
                                                            То что вам не нравится php я вижу и переубеждать не собираюсь.
                                                            Стандартные доводы в пользу рельсов в отличии от пхп — нет mvc, нет хелперов и прочее, хотя они все есть в php-фреймворках.
                                                            Второе, то что пользователям и заказчикам по большей части абосолютно ровно на чем написан продукт, главное чтобы он был удобным, быстрым, расширяемым, etc. Думаете, это нерализуемо на php?

                                                            Если хотите поспорить давайте лучше поговрим на тему RoR vs. Django. Где большинство плюсов, все же на мой взгляд, у последнего. (Могу ошибаться с RoR работал мало — не очень понравилось, django оказался как-то ближе)
                                                            • 0
                                                              >Думаете, это нерализуемо на php?
                                                              Отчего же? Это реализуемо даже на ассемблере. Разница «всего лишь» в количестве потребных для этого усилий :). Но я там о другом немного — о возможности сравнения говорил. У пхп-шников при слове «рельсы» модно принять позу эдакого обиженного и опущенного, — а чё вы, — типа, — «язык» с фреймворком сравниваете… Да был бы то язык!.. :)
                                                              Рельса против Джанги — тут я пас, пару раз пытался вникнуть в концепцию джанги, но времени не хватало, а из того, что осилил, не очень глянулось, поэтому мнение моё тут более чем субъективное и не составляет предмета для спора :).
                                                              • 0
                                                                Каких возможностей не хватает PHP, по-вашему, чтобы считаться полноценным языком?

                                                                Из того, что в голову приходит, только отсутствие реальной многопоточности могу вспомнить. Отсутствие/наличие Си-подобных указателей не считаю достаточным признаком для определения является ли некая сущность языком :)
                                                                • +1
                                                                  Это полноценный язык для веб-приложений. DSL. Безумно уродливый, но, таки да, полноценный. Тут дело в другом — существует ли хоть какая-то причина (относящаяся к языку, а не к проявлению воли работодателя), могущая побудить программистов, знающих кроме пхп ещё какой-нибудь язык, писать на пхп не веб приложения? Да, по большому счёту, и веб-приложения тоже :).
                                                                  • 0
                                                                    Ну вот я знаю ассемблер (правда забыл уже почти, но вспомню если что надеюсь быстро), С/С++, VB немного, ну и PHP :). Про веб-приложения просто — использовать эти языки на «моих» хостингах очень затруднительно, потому как шелл-доступа к ним нет, а на том который есть нет доступа к компиляторам, трансляторам, сборщикам и т. п. да и писать CMS, например, на асме для веба как-то слишком долго получится :) а готовых открытых решений не встречал :(
                                                                    Ну а использование PHP в качестве скриптового языка для личных нужд — кроссплатформенность (windows/linux), бритва Оккама, да и просто лень разбираться в bash и powershell :)

                                                        • 0
                                                          наркоман штоле?
                                                          • –2
                                                            >Ничего, кроме уеб-приложений написать на нём, по большому счёту, нельзя (я в курсе, что есть в теории можно, только кто ж это будет всерьёз делать?)

                                                            а много ли не веб приложений написано на руби, если уж на то пошло?
                                                            //не провокаций и флейма ради спрашиваю
                                                            • 0
                                                              >а много ли не веб приложений написано на руби, если уж на то пошло?
                                                              Его большей частью как скриптовый язык используют, потому как очень просто встраивать.
                                                              Например в Google SketchUp.
                                                              • –3
                                                                на этом примеры практически заканчиваются, ага.
                                                                во втором амароке от руби уже вроде отказались
                                                              • 0
                                                                Об этом лучше спрашивать у японцев, я думаю :)
                                                                Ну… А так, я вот, например, для производства рутинных действий, пишу небольшие скрипты на руби постоянно (в планах есть и поразвлекаться на десктопных приложениях). Делать это на пхп в голову вообще не приходило, даже когда я уже знал пхп и ещё не знал руби. Хотя, я слышал раз и о таком уникуме. Ого, даже о двух (и оба, если не ошибаюсь, тут на хабре где-то присутствуют).
                                                                • 0
                                                                  Я тут присутствую :) Самой простой пример такого скрипта — по крону запускается раз в сутки и обходит ФС на предмет удаления всяких резервных и временных файлов, старше недели. Изучать для этого питон, руби или еще что-то мне кажется излишним
                                                                  • 0
                                                                    Если мне раз в 10 лет надо будет забить гвоздь — я может и возьму для этого лежащий под рукой микроскоп. Но если я забиваю гвозди немного чаще — я все-таки постараюсь делать это молотком.
                                                                • 0
                                                                  Я делал курсовой по нейросетям.
                                                            • +1
                                                              ну тогда и рассматривать наверное надо не рор вс пхп, а, например, рор вс симфони (насколько я знаю из пхп-фреймворков симфони наиболее близок к рор идеологически, многие идеи заимствованы), где тоже есть и мвц, и куча хелперов, в том числе и для аякса, и встроенная поддержка json. и плагины к симфони есть (на оф сайте вроде под четыре сотни), да и других фреймворков полно, из наиболее именитых — зенд, кейк, кодеигнитер (кохана).

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

                                                              • –2
                                                                >(в особых случаях код на руби в 20 строк можно заменить кодом на пыхе размером
                                                                строк так в 150).
                                                                это вы о строках размером в несколько экранов? =)
                                                                на php тоже можно писать коротко ясно и лаконично
                                                                • 0
                                                                  если вы про ниндзя-стайл, то на нем эти 20 строк превратятся в 3-5....20 строк я имею в виду нормальной понимаемой длины
                                                                  • 0
                                                                    строка строке рознь, давайте мерить попугаями ;)
                                                                    а если серьезно:
                                                                    1) то алгоритм алгоритму рознь
                                                                    2) все люди пишут по разному (можно в 20, можно в 150) и код одинакого хорошо будет решать задачу
                                                                    3) нормально понимаемая длинна на мониторах разных размеров совершенна различна
                                                              • +1
                                                                > чем он лучше того же PHP для разработки веб-приложений

                                                                Сам по себе язык более последовательный. Вот тем оно и лучше.
                                                                • 0
                                                                  Тут не спорю, за то время, что я пишу на PHP (начинал с php3) чего в него только не добавили, причем часто через одно место :)
                                                              • +3
                                                                Вы бы не писали про проблемы Твиттера из-за Ruby, не зная настоящего положения дел.
                                                                • 0
                                                                  Я действительно не при делах твиттера :) Там такая небольшая ссылка на то, что это было мне подсказано «спецами». И, как я писал, для обучения (а это цель статеек) производительность не столь важна
                                                                  • 0
                                                                    >для обучения (а это цель статеек) производительность не столь важна
                                                                    ну вот выучите вы язык и он вдруг в 50 раз ускорится?

                                                                    зы
                                                                    kirindave.tumblr.com/post/60776407/the-opposite-of-momentum

                                                                    And let’s be honest, Ruby is one of the slowest choices in the scripting language market. The Ruby interpreter is dead last in the GCLS. Now, I know the GLCS is synthetic and not very useful, but it’s still worth noting that Ruby is so slow that the primary defense for its speed is the 37signals-esque “It Just Doesn’t Matter™”. And on top of all this, the implementation is quirky and buggy and all sorts of little gaffs show up. For example, inline blocks don’t establish a new scope, so iteration variables are left behind in the enclosing scope, making for some weird artifacts.
                                                                • 0
                                                                  В php-скриптах могу чего-нить лишнее удалить, изменить, но написать что-то с чистого листа — это не ко мне. Неоднократно пытался научится мастерству создания программ, но обычно тормозил как только дело доходило до ООП

                                                                  и вы действительно верите, что смена языка программирования научит вас «мастерству создания программ» (программировать)? ;)
                                                                  • 0
                                                                    Скажем так, что просто не было особого желания и времени — по крайней мере статьи о ходе своего обучения я писать еще не решался ;) А тут такая затея — хочешь, нет, а надо — люди ждут :))
                                                                  • 0
                                                                    Если интересно: habrahabr.ru/blogs/edu_2_0/48267/
                                                                    В принципе я с одним человеком сейчас начал удаленно заниматься, еще осталось время на одного вполне.
                                                                    • –2
                                                                      <holywar enabled="false">А почему Ruby/Rails, а не более перспективный/быстрый/понятный Groovy/Grails?</holywar>
                                                                      
                                                                      • 0
                                                                        Потому что помимо CRuby есть еще и JRuby:)
                                                                        • 0
                                                                          и что?
                                                                          • –2
                                                                            В Groovy по сути больших отличий от Ruby нет, все таки ведь клон. Основная его фишка — это доступ к великой и могучей Java платформе.
                                                                            А так как и Ruby, посредством JRuby, может использовать мощь Java платформы, то смысла в его клоне я не вижу. Естественно это субъективно, тут кому что нравиться:)
                                                                            • 0
                                                                              К тому же в Ruby есть опция — таскать за собой Java платформу или нет, она ведь не всегда нужна.
                                                                              А в Groovy нет:)
                                                                              • 0
                                                                                Кхм… Не хочется развенчивать ваши предубеждения, но Groovy на столько же «клон» Ruby, на сколько он «клон» Java & Python. Тот же Ruby 1.9 заимствует некоторые фишки, которые есть в Groovy.

                                                                                Интеграция с Java у Groovy на порядок выше.
                                                                                • 0
                                                                                  Ну клон Java, это вы конечно загнули, джава ниразу не динамическая. Просто большинство идей Groovy перенял именно от Ruby, например блоки, итераторы на них построенные, простое создание DSL. Даже не идеи(блоки например ведь не в руби впервые появились), а саму их реализацию.

                                                                                  >Интеграция с Java у Groovy на порядок выше.
                                                                                  В чем это выражается?

                                                                                  >Тот же Ruby 1.9 заимствует некоторые фишки, которые есть в Groovy.
                                                                                  Какие?(Правда очень интересно)
                                                                                  • 0
                                                                                    >саму их реализацию.
                                                                                    это как? скопировал исходники что ли? 0_О

                                                                                    >В чем это выражается?
                                                                                    валидный java-код=валидный groovy-код (с минимальными ограничениями), как пример того, что groovy — это «почти» java
                                                                                    • 0
                                                                                      >это как? скопировал исходники что ли? 0_О
                                                                                      Нет конечно. Я про то что синтаксически например блоки и итераторы на Ruby и Groovy практически идентичны.

                                                                                      >java-код=валидный groovy-код
                                                                                      В чем плюс для интеграции? То что мы можем использовать Java код в Groovy интерпретаторе не компилируя в байткод?
                                                                                      • 0
                                                                                        >Нет конечно. Я про то что синтаксически например блоки и итераторы на Ruby и Groovy практически идентичны.

                                                                                        синтаксически практически groovy идентичен в первую очередь java, и лишь потом отсутствующие в java вещи, да и такого понятия как блоки/итераторы я что-то не припоминаю, там есть только closures.

                                                                                        >В чем плюс для интеграции? То что мы можем использовать Java код в Groovy интерпретаторе не компилируя в байткод?
                                                                                        использование java-классов/методов в groovy и наоборот. опять же простота миграции и бОльшая понятность кода.
                                                                                        • 0
                                                                                          closures в Groovy и блоки в Ruby это одно и тоже.
                                                                                          а под итератором я имел ввиду функции типо Array.each, которым в качестве параметра передается блок.

                                                                                          >бОльшая понятность кода.
                                                                                          Всмысле для Java программиста?
                                                                                          • 0
                                                                                            >closures в Groovy и блоки в Ruby это одно и тоже.
                                                                                            >а под итератором я имел ввиду функции типо Array.each, которым в качестве параметра передается блок.

                                                                                            итого в руби 2 сущности, в groovy — одна. и где тут клонирование?
                                                                                            • 0
                                                                                              Не понял, какие две сущности?
                                                                                              Итератор — это просто пример использования блока.
                                                                                          • 0
                                                                                            >да и такого понятия как блоки/итераторы я что-то не припоминаю, там есть только closures.
                                                                                            Итераторы есть, конечно, они даже в яве есть :), а замыкания функцию блоков как раз и выполняют (это ж они и есть, просто терминология отличается).
                                                                                            Из айбиэмовского туториала…
                                                                                            Итераторы:
                                                                                            str = «uncle man, uncle man»
                                                                                            for (ch in str){
                                                                                            println ch
                                                                                            }
                                                                                            Блоки:
                                                                                            [2, 4, 6, 8, 3].find { x |
                                                                                            if (x == 3){
                                                                                            println x
                                                                                            }
                                                                                            }
                                                                                      • +1
                                                                                        > Ну клон Java, это вы конечно загнули, джава ниразу не динамическая.

                                                                                        При чём здесь «динамика»?
                                                                                        1) Groovy поддерживает опциональное статическое типизирование: если у вас есть def a(String b) и вы сделаете вызов a(1) — вам вылетит ошибка.
                                                                                        2) GDK = JDK + дополнительные методы
                                                                                        3) Любой Java-код = валидный Groovy-код, поддержка Generics, Annotations, Enums — у JRuby этого всего нет к примеру.

                                                                                        > Просто большинство идей Groovy перенял именно от Ruby, например блоки, итераторы на них построенные, простое создание DSL. Даже не идеи(блоки например ведь не в руби впервые появились), а саму их реализацию.

                                                                                        1. Ну у Groovy это более целостно, вместо понятий procs, lambda, blocks — есть одно: closures, с простым объявлением: closure = { it*it }, есть implicit «it» для одного параметра.
                                                                                        2. ООП, MOP & Closures к нам пришли действительно из Smalltalk, хотя Groovy & Ruby частично имеют схожие реализации
                                                                                        3. Symbols что есть в Groovy нет в Ruby
                                                                                        4. Code-flow структуры однозначны как в Java&Python, нет никаких «unless» и прочего

                                                                                        > Какие?(Правда очень интересно)
                                                                                        : вместо => для хешей, более короткий синтаксис для лямбд(хотя у groovy всё равно короче ;), ещё что-то было, не помню уже.
                                                                                        • 0
                                                                                          Вобщем большая часть отличий — именно синтаксические, для тех же самых фич.
                                                                                          Только вот про Symbols не понял, это аналог :asdf или что то другое?
                                                                                          Кстати, а чем вам unless не нравиться?:)

                                                                                          А насчет Java-код = валидный Groovy-код
                                                                                          Практическое применение этому есть? Или только как облегчение перехода Java программистов.
                                                                                          • 0
                                                                                            > Вобщем большая часть отличий — именно синтаксические, для тех же самых фич.

                                                                                            Что касается пунктов из Java-списка(1-3), тот тут именно функциональные различия: даже в JRuby вы это не получите. Ruby-список(1-4) — да, тут синтаксические различия.

                                                                                            > Только вот про Symbols не понял, это аналог :asdf или что то другое?

                                                                                            Наоборот хотел написать — символов в Groovy нет)

                                                                                            > Кстати, а чем вам unless не нравиться?:)

                                                                                            Я за TOOWTDI и против наследий Perl.

                                                                                            > Практическое применение этому есть? Или только как облегчение перехода Java программистов.

                                                                                            1. Переход, как вы сказали
                                                                                            2. Проще портировать в обратном направлении для улучшения производительности
                                                                                            3. Читабельность проекта Java/Groovy выше чем Java/JRuby или Ruby/C
                                                                                            4. Есть ещё много вещей на уровне компиляторов — JRuby должен идти на определённые уступки в угоду совместимости с CRuby.

                                                                                            Я бы не называл Groovy в качестве конкурента Ruby. Всё же основные конкуренты Ruby — PHP & Python, которым он пока проигрывает. Groovy же сориентирован в первую очередь на Java-разработчиков и тут ему равных нет:
                                                                                            1. Сейчас он разрабатывается SpringSource
                                                                                            2. Groovy — JSR
                                                                                            3. Grails, базирующиеся на Spring, Griffon для Swing

                                                                                            Ruby в свою очередь имеет лёгкий Rails с хорошим API, который заведётся на слабом VPS, а теперь даже и на Shared-хостинге, более низкий порог вхождения, большую востребованность на Free-lance рынке, чем Groovy.

                                                                                            Хотя вот меня лично(Java-guy) Groovy на себя не перетянул, хотя некоторые вещи из него я бы хотел увидеть в Java. Grails тоже бесспорно лучше Spring MVC, но немногим лучше Stripes, а уж с Wicket(которому я душу продал) я бы сравнивать не пытался.
                                                                                            • 0
                                                                                              >Хотя вот меня лично(Java-guy) Groovy на себя не перетянул
                                                                                              везёт вам, я вот уже втянулся…

                                                                                              для человека, который хорошо знает Spring/Wicket/etc grails действительно не так привлекает, но вот если его(человека) сначала хорошенько напугать Spring+Hibernate+..., то от Grails он будет в восторге. Собственно, ровно таким же образом к себе и rails привлекали.