Comments 192
как для «Бывший школьник, будущий студент» грамотно написано. :)
В качестве среды могу предложить NetBeans
В качестве среды могу предложить NetBeans
Я старался ;)
По секрету среду я уже выбрал :) Осталось только протолкнуть ее в массы начинающих и не очень
По секрету среду я уже выбрал :) Осталось только протолкнуть ее в массы начинающих и не очень
здоров получается, задорно и весело, я с вами :) хотя меня несколько расстраивает, что проблематично поставить PHP и Rails на одном сервере, а на счет производительности так вроде не сильно уступает пхп тем более это фреймворк. но это все только по- наслышке
С mod_passenger и mod_php можно на одном апаче запускать и php и rails приложения.
Не, кажись нельзя. Где-то встречал в обсуждениях, что мод_рельс использует что-то в апаче, что несовместимо с мод_пхп.
можно и если не знаете то стоит промолчать
Ну тогда вообще никто писать не будет, а и так читать нечего. Знаешь/не знаешь — какая разница? Все равно истина рождается в холиваре! :P
не встретил в приведенном тред сообщения в которых описано что mod_rails не работает с mod_php.
прежде чем повторять как попугай — протестируйте
прежде чем повторять как попугай — протестируйте
Тут речь идет о том что mod_php принуждает к использованию mpm_prefork, который не является самой удачной моделью.
Цитируя Алексея:
но на mpm_prefork все работает вполне неплохо.
Единственное что пока не дружило с mod_passenger (насколько мне известно) — это mod_vhost_alias.
Цитируя Алексея:
Это означает, что Вы не сможете использовать worker mpm, который наилучшим образом работает с passenger, потому что mod_php с ним работать нормально не в состоянии.
но на mpm_prefork все работает вполне неплохо.
Единственное что пока не дружило с mod_passenger (насколько мне известно) — это mod_vhost_alias.
>>Тут речь идет о том что mod_php принуждает к использованию mpm_prefork, который не является самой удачной моделью.
Потоковая модель нормально не работает в апаче. Мало того, что много чего приходится руками пересобирать (это касается пхп модулей нему), так еще и наблюдается мертвое виселово под нагрузкой через пару часов. Причину так и не нашел, решения — тоже. С похожими симптомами ребята сталкивались, но решить тоже не смогли.
Так что я бы сказал, что prefork на данный момент единственная модель для апача.
Потоковая модель нормально не работает в апаче. Мало того, что много чего приходится руками пересобирать (это касается пхп модулей нему), так еще и наблюдается мертвое виселово под нагрузкой через пару часов. Причину так и не нашел, решения — тоже. С похожими симптомами ребята сталкивались, но решить тоже не смогли.
Так что я бы сказал, что prefork на данный момент единственная модель для апача.
Так я же и говорю что mod_php нормально работает с mpm_prefork. Тредовый апач сам по себе работает весьма хорошо, но много чего написаного для него — хотя бы тот же mod_php — не thread-safe.
www.camelrichard.org/apache-prefork-vs-worker
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.
И почему же нельзя? И как же у меня ruby, python, php на одном апаче бегают бзе плясок с бубном?
нет никаких проблем. php через mod_php, рельсы через fcgi (и хотя это далеко не лучшее решение, работает достаточно быстро)
а где почитать и какое решение лучшее?
лучше использовать mongrel. но честно говоря, мне было лень что-либо настраивать, по-этому я даже не читал по этому поводу.
по поводу fcgi достаточно информации в интернетах.
по поводу fcgi достаточно информации в интернетах.
Посмотрите еще thin, как новую альтернативу монгрелу. На продакшене сами мы еще не пробовали, но по отзывам он обгоняет монгрел везде и основан на стабильных компонентах.
code.macournoyer.com/thin/
code.macournoyer.com/thin/
Почему Ruby?
* Язык предельно лёгок в изучении в сравнении с другими ЯП
* Полностью объектно-ориентированный
* Архитектура MVC
…
Прощу прощения, это у самого руби архитектура MVC или все-таки у Rails?
* Язык предельно лёгок в изучении в сравнении с другими ЯП
* Полностью объектно-ориентированный
* Архитектура MVC
…
Прощу прощения, это у самого руби архитектура MVC или все-таки у Rails?
«Возвращаясь к Руби, делаем вывод, что язык этот замечателен для разработки веб-приложений, скриптов, и совсем не подходит для создания программ, например, для Windows.»
Не соглашусь… руби как и питон замечательно подходит как для написания гуи фронтендов к консольным приложениям так и для написания небольших или нетребовательных к ресурсам (а точнее к скорости) утилит.
Не соглашусь… руби как и питон замечательно подходит как для написания гуи фронтендов к консольным приложениям так и для написания небольших или нетребовательных к ресурсам (а точнее к скорости) утилит.
браво! ждём продолжения!
И еще забыл сказать свою постоянную фразу про обучение программированию на синтаксически-сладких языках (руби к ним относится).
Это зло. Такие языки на начальном этапе развития человека как программиста дают определенную (и вполне нехилую) халяву, которая может выйти боком. Если же вначале пописать на таких языках как с или с++ (главное чтобы не было ГЦ и чтобы это был не паскаль), то это даст вам большое представление о том как надо писать программы. А потом уже можно переходить на сахар. При таком подходе ваши программы будут более эффективны. Это все ИМХО конечно, но ИМХО это ИМХО вполне обоснованно.
Это зло. Такие языки на начальном этапе развития человека как программиста дают определенную (и вполне нехилую) халяву, которая может выйти боком. Если же вначале пописать на таких языках как с или с++ (главное чтобы не было ГЦ и чтобы это был не паскаль), то это даст вам большое представление о том как надо писать программы. А потом уже можно переходить на сахар. При таком подходе ваши программы будут более эффективны. Это все ИМХО конечно, но ИМХО это ИМХО вполне обоснованно.
Как я понял, автор уже имеет представление о программировании, и интересует его сейчас именно ООП.
> И еще забыл сказать свою постоянную фразу про обучение программированию на синтаксически-сладких языках (руби к ним относится).
> Если же вначале пописать на таких языках как с или с++ (главное чтобы не было ГЦ и чтобы это был не паскаль), то это даст вам большое представление о том как надо писать программы.
Начали за здравие, закончили за упокой… Синтаксический сахар не относится к управлению памятью никаким боком.
Алсо, Си и Си++ не дадут никакого представления о том, как надо писать программы, скорее, дадут представление о том, как оно там внутре работает на низком уровне.
> Если же вначале пописать на таких языках как с или с++ (главное чтобы не было ГЦ и чтобы это был не паскаль), то это даст вам большое представление о том как надо писать программы.
Начали за здравие, закончили за упокой… Синтаксический сахар не относится к управлению памятью никаким боком.
Алсо, Си и Си++ не дадут никакого представления о том, как надо писать программы, скорее, дадут представление о том, как оно там внутре работает на низком уровне.
я может просто слегка сжато выразился… имлось в виду что и синтаксический сахар и ГЦ мешают пониманию того как надо писать программы оптимально…
«Алсо, Си и Си++ не дадут никакого представления о том, как надо писать программы, скорее, дадут представление о том, как оно там внутре работает на низком уровне.»
Опять же имелось в виду «писать программы оптимально», чему крайне помогает как раз знание о том как оно все работает изнутри
«Алсо, Си и Си++ не дадут никакого представления о том, как надо писать программы, скорее, дадут представление о том, как оно там внутре работает на низком уровне.»
Опять же имелось в виду «писать программы оптимально», чему крайне помогает как раз знание о том как оно все работает изнутри
«Оптимально» по какому критерию?
по критерию безглючность/скорость работы
Скорость работы — ага, но она не всегда критична, к тому же тут есть контр-аргумент — ассемблер :).
Безглючность… Ну-у-у! По критерию возможности наделать на ровном месте кучу фатальных для программы (а то и для системы) глюков, что си, что сипипи за тем же ассемблером в затылок выстроились :). Вряд ли это то, что называется «оптимальностью» :). По критерию безглючности, программирование на более высокоуровневых языках, всё-таки «оптимальнее».
Безглючность… Ну-у-у! По критерию возможности наделать на ровном месте кучу фатальных для программы (а то и для системы) глюков, что си, что сипипи за тем же ассемблером в затылок выстроились :). Вряд ли это то, что называется «оптимальностью» :). По критерию безглючности, программирование на более высокоуровневых языках, всё-таки «оптимальнее».
вы не поняли… я имел в виду отношение… и скорость работы в том же вебе критична достаточно… если у вас хай-лоад сервис то вам надо думать о скорости работы
Что есть «отношение»? Следить самому за указателями, вместо того, чтобы отдать это на откуп компилятору-рантайму — это отношение? Ну, а тогда, расписывать циклы на условия и гоуту, вместо использования высокоуровневых операторов цикла — тоже должно быть «отношение» :).
А учиться программированию (это в первую очередь способность к алгоритмизации и формулированию алгоритмов в виде формальной записи) на хай-лоад сервисах — это странно. Лучше тренироваться в этом, всё-таки, на кошечках. Сложно сказать пригоден ли для этого руби, лично я посоветовал бы яву (хотя корифеи советуют начинать с фунциональщины), но уж ни как не си плюс-плюс.
А вся эта арифметика указателей, освобождение памяти и прочая низкоуровневая оптимизация — это всего лишь частные проявления конкретной технологии, трюки. Им учиться нужно в последнюю очередь.
А учиться программированию (это в первую очередь способность к алгоритмизации и формулированию алгоритмов в виде формальной записи) на хай-лоад сервисах — это странно. Лучше тренироваться в этом, всё-таки, на кошечках. Сложно сказать пригоден ли для этого руби, лично я посоветовал бы яву (хотя корифеи советуют начинать с фунциональщины), но уж ни как не си плюс-плюс.
А вся эта арифметика указателей, освобождение памяти и прочая низкоуровневая оптимизация — это всего лишь частные проявления конкретной технологии, трюки. Им учиться нужно в последнюю очередь.
блин, отношение безглючности кода к скорости работы… ну как цена/качество…
я не говорю что надо учиться на хай-лоаде… но когда программист, который не осознает того что происходит «под капотом» той или иной функции в языке (хотя бы примерно) берется за хай-лоад то он может таких дел наворотить, что мало не покажется…
яву в качестве первого языка вообще нафиг… слишком она навороченная чтобы на ней учиться… даже для простейших задач иногда приходится писать такие дикие строки кода, что ужас просто… в то время как на сях это все пишется гораздо проще…
я не говорю что надо учиться на хай-лоаде… но когда программист, который не осознает того что происходит «под капотом» той или иной функции в языке (хотя бы примерно) берется за хай-лоад то он может таких дел наворотить, что мало не покажется…
яву в качестве первого языка вообще нафиг… слишком она навороченная чтобы на ней учиться… даже для простейших задач иногда приходится писать такие дикие строки кода, что ужас просто… в то время как на сях это все пишется гораздо проще…
Не очень понял про отношение всё-равно. Вы в сравнении с ассемблером, что ли? Тогда да, а в сравнении с более другими языками, мне кажется, тут пролёт полный.
>я не говорю что надо учиться на хай-лоаде… но когда программист, который не осознает того что происходит «под капотом» той или иной функции в языке (хотя бы примерно) берется за хай-лоад то он может таких дел наворотить, что мало не покажется…
Плохой программист может наворотить дел где угодно и хай-лоад здесь совершенно не при чём. Писать высоконагруженные приложения нужно учиться специально! Если вы ставите на хайлоад человека, который специально не учился этому, то почти наверное огребётесь, за очень редким исключением. Это не значит, что данный программист плох или он в каком-то «не том» порядке изучал языки, просто у него нет этого конкретного умения. Если посадить 3Д-гуру, знающего потроха языка и компиляторов досконально, за простейшую (даже не хайлоад) веб-разработку точно так же можно огрести и знания «подкапотного пространства» не помогут. Я о том, что начинать с такого уровня смысла нет. _Сначала_ надо учить другому. И только _потом_ этому. И то, только если понадобиться или ради интереса и расширения кругозора.
Это ява-то навороченная? Ява проще цпп раз в сто. Не, раз в двести! Хотя многословная, ага :).
С си сложно сравнивать, слишком разные у этих языков цели.
>я не говорю что надо учиться на хай-лоаде… но когда программист, который не осознает того что происходит «под капотом» той или иной функции в языке (хотя бы примерно) берется за хай-лоад то он может таких дел наворотить, что мало не покажется…
Плохой программист может наворотить дел где угодно и хай-лоад здесь совершенно не при чём. Писать высоконагруженные приложения нужно учиться специально! Если вы ставите на хайлоад человека, который специально не учился этому, то почти наверное огребётесь, за очень редким исключением. Это не значит, что данный программист плох или он в каком-то «не том» порядке изучал языки, просто у него нет этого конкретного умения. Если посадить 3Д-гуру, знающего потроха языка и компиляторов досконально, за простейшую (даже не хайлоад) веб-разработку точно так же можно огрести и знания «подкапотного пространства» не помогут. Я о том, что начинать с такого уровня смысла нет. _Сначала_ надо учить другому. И только _потом_ этому. И то, только если понадобиться или ради интереса и расширения кругозора.
Это ява-то навороченная? Ява проще цпп раз в сто. Не, раз в двести! Хотя многословная, ага :).
С си сложно сравнивать, слишком разные у этих языков цели.
я в сравнении с другими языками говорю… сравните код на руби и на цпп… сравните их по скорости… и вы увидите что цпп будет работать быстрее, хотя не спорю что вероятность ошибиться существенно выше… я вот про это отношение… так сказать баланс…
Сначала надо учиться думать и учиться надо начинать на простейших алгоритмах… ну там сортировка пузырьком и прочее… а это проще на языка уровня с/с++…
От того что ява многосложная и возникают навороты… согласитесь логичнее писать a+b чем a.add(b)
Сначала надо учиться думать и учиться надо начинать на простейших алгоритмах… ну там сортировка пузырьком и прочее… а это проще на языка уровня с/с++…
От того что ява многосложная и возникают навороты… согласитесь логичнее писать a+b чем a.add(b)
> Сначала надо учиться думать и учиться надо начинать на простейших алгоритмах… ну там сортировка пузырьком и прочее… а это проще на языка уровня с/с++…
Сказки Булонского леса? Quick sort на Хаскеле vs Си будем сравнивать? В первом можно без труда выяснить, что делается, и вообще узнать, как работает алгоритм. Второй будет менее понятен человеку в любом случае.
Сказки Булонского леса? Quick sort на Хаскеле vs Си будем сравнивать? В первом можно без труда выяснить, что делается, и вообще узнать, как работает алгоритм. Второй будет менее понятен человеку в любом случае.
Если зациклиться только на скорости, то вы правы на все сто и _в этом_ с вами никто не спорит, это очевидно. Пытаются объяснить, что есть случаи, когда скорость выполнения не настолько важная задача. Гораздо важнее скорость разработки, например (и стоимость, как производная), стоимость поддержки и цена ошибки. Так вот, судя по востребованности на рынке сишников и программистов на всех прочих языках, а так же стремительное развитие сектора динамических языков, баланс этот ваш далеко не в пользу си.
Я понимаю, что у сишников бзик на этой почве, но когда выбор стоИт скажем, руби скрипт за день или сишная программа за год даже при том, что скрипт будет считаться день, а сишная программа — две минуты, выбор, в большинстве случаев (не во всех, конечно!) будет очевиден. Даже если результат будет нужен всё-таки через две минуты, проще будет за малую копейку купить ресурсы в амазоновском облаке и крутнуть там этот скрипт. Тут на хабре подобную задачу описывали.
>Сначала надо учиться думать и учиться надо начинать на простейших алгоритмах… ну там сортировка пузырьком и прочее… а это проще на языка уровня с/с++
Да-а-а? Более чем неочевидное утверждение.
>От того что ява многосложная и возникают навороты… согласитесь логичнее писать a+b чем a.add(b)
И часто приходится складывать не числа и не строки? Я на яве лет 7 пишу. Приходится, но крайне редко (деньги). Наверное, это от того, что не я писал бухгалтерскую часть :), но кроме денежных операций как-то мало что в голову приходит, где оно могло бы широко использоваться? Научные расчёты и матрицы-шматрицы? Наверное, я сейчас от этого далёк, но чудится мне, что ява там не очень распространена, поэтому и проблемы такой нет :).
Я понимаю, что у сишников бзик на этой почве, но когда выбор стоИт скажем, руби скрипт за день или сишная программа за год даже при том, что скрипт будет считаться день, а сишная программа — две минуты, выбор, в большинстве случаев (не во всех, конечно!) будет очевиден. Даже если результат будет нужен всё-таки через две минуты, проще будет за малую копейку купить ресурсы в амазоновском облаке и крутнуть там этот скрипт. Тут на хабре подобную задачу описывали.
>Сначала надо учиться думать и учиться надо начинать на простейших алгоритмах… ну там сортировка пузырьком и прочее… а это проще на языка уровня с/с++
Да-а-а? Более чем неочевидное утверждение.
>От того что ява многосложная и возникают навороты… согласитесь логичнее писать a+b чем a.add(b)
И часто приходится складывать не числа и не строки? Я на яве лет 7 пишу. Приходится, но крайне редко (деньги). Наверное, это от того, что не я писал бухгалтерскую часть :), но кроме денежных операций как-то мало что в голову приходит, где оно могло бы широко использоваться? Научные расчёты и матрицы-шматрицы? Наверное, я сейчас от этого далёк, но чудится мне, что ява там не очень распространена, поэтому и проблемы такой нет :).
дык вы говорите про нормальных сформированных программистов, которые решают те или иные задачи;) тут я не буду спорить… инструмент нужно выбирать тот, который максимально подходит для данной задачи… я ведь тоже не только на си пишу… еще на пхп и на руби
раз неочевидное, тогда давайте оспаривать;)
«И часто приходится складывать не числа и не строки?»
именно складывать может и нет, но переопределение различных операторов (в основном у меня используются [], присваивание, сравнение) есть во многих написанных мною классах… данная возможность дает более высокий уровень абстракции… ведь согласитесь, что различные объекты вы сравниваете часто? а если условие многоэтажное, то тут гораздо лучше когда все состоит из <,>,==,!= чем из вызовов методов
вообще дискуссия переросла из того как лучше обучать программиста в дискуссию на тему «ява против с++ в разработке»… так что предлагаю закругляться.
раз неочевидное, тогда давайте оспаривать;)
«И часто приходится складывать не числа и не строки?»
именно складывать может и нет, но переопределение различных операторов (в основном у меня используются [], присваивание, сравнение) есть во многих написанных мною классах… данная возможность дает более высокий уровень абстракции… ведь согласитесь, что различные объекты вы сравниваете часто? а если условие многоэтажное, то тут гораздо лучше когда все состоит из <,>,==,!= чем из вызовов методов
вообще дискуссия переросла из того как лучше обучать программиста в дискуссию на тему «ява против с++ в разработке»… так что предлагаю закругляться.
>раз неочевидное, тогда давайте оспаривать;)
Написание простых учебных задач на более других, чем си, языках ничуть не сложнее, ничуть не менее педагогично, не менее полезно, не менее проще и неслонено ненужной для понимания алготирма, мутью с арифметикой указателей и слежением за памятью. А вот для изучения адресной арифметики и слежения за этой самой памятью, да, си вполне подходит. Но это малая часть того, чему нужно обучить программиста. И не всегда она нужна.
>а если условие многоэтажное, то тут гораздо лучше когда все состоит из ,==,!= чем из вызовов методов
Тоже неочевидно. Если с больше-меньше, ещё ладно, согласен (но тоже, а что сравниваем? Кроме денег, бестно приходят в голову разве что даты ещё), то у == и o1.equals(o2) в яве разная семантика, а переопределение одну из них уничтожит, что не всегда приемлимо. Но я о многословности явы спорить не буду — я в этом прекрасно осведомлён и тоже считаю, что многое там перебор. В разработке. А в обучении — ничего так.
Написание простых учебных задач на более других, чем си, языках ничуть не сложнее, ничуть не менее педагогично, не менее полезно, не менее проще и неслонено ненужной для понимания алготирма, мутью с арифметикой указателей и слежением за памятью. А вот для изучения адресной арифметики и слежения за этой самой памятью, да, си вполне подходит. Но это малая часть того, чему нужно обучить программиста. И не всегда она нужна.
>а если условие многоэтажное, то тут гораздо лучше когда все состоит из ,==,!= чем из вызовов методов
Тоже неочевидно. Если с больше-меньше, ещё ладно, согласен (но тоже, а что сравниваем? Кроме денег, бестно приходят в голову разве что даты ещё), то у == и o1.equals(o2) в яве разная семантика, а переопределение одну из них уничтожит, что не всегда приемлимо. Но я о многословности явы спорить не буду — я в этом прекрасно осведомлён и тоже считаю, что многое там перебор. В разработке. А в обучении — ничего так.
Каким опытом обучения, кроме личного, подкреплена «постоянная фраза» насчет обучения на Си?
По моему опыту как раз начавших с Си очень сложно потом сдвинуть с битов и указателей на что-либо более концептуальное. Тут был упомянут Си++, расскажите а на каком уровне Вы владете STL? А как Вы относитесь к таким вещам у обучении, как блоксхемы?
По моему опыту как раз начавших с Си очень сложно потом сдвинуть с битов и указателей на что-либо более концептуальное. Тут был упомянут Си++, расскажите а на каком уровне Вы владете STL? А как Вы относитесь к таким вещам у обучении, как блоксхемы?
«Каким опытом обучения, кроме личного, подкреплена «постоянная фраза» насчет обучения на Си?»
разговоры с коллегами и личные наблюдения за молодыми падаванами
«По моему опыту как раз начавших с Си очень сложно потом сдвинуть с битов и указателей на что-либо более концептуальное.»
Странно, я пишу на плюсах (и более того для меня это самая приятный язык программирования) и при этом спокойно отношусь к пыху, руби и питону (на первых двух пишу, третий могу спокойно читать)
«Тут был упомянут Си++, расскажите а на каком уровне Вы владете STL?»
На достаточном, чтобы спокойно на нем писать и представлять как оно работает
«А как Вы относитесь к таким вещам у обучении, как блоксхемы?»
положительно, но только на начальной стадии обучения, потом я считаю их излишком
разговоры с коллегами и личные наблюдения за молодыми падаванами
«По моему опыту как раз начавших с Си очень сложно потом сдвинуть с битов и указателей на что-либо более концептуальное.»
Странно, я пишу на плюсах (и более того для меня это самая приятный язык программирования) и при этом спокойно отношусь к пыху, руби и питону (на первых двух пишу, третий могу спокойно читать)
«Тут был упомянут Си++, расскажите а на каком уровне Вы владете STL?»
На достаточном, чтобы спокойно на нем писать и представлять как оно работает
«А как Вы относитесь к таким вещам у обучении, как блоксхемы?»
положительно, но только на начальной стадии обучения, потом я считаю их излишком
Заинтересовал, хотя, конечно, по такому описанию не сделать выводов, чем он лучше того же PHP для разработки веб-приложений и лучше ли вообще (сейчас заминусуют, наверное :) ). Пока единственный плюс вижу — полностью ОО, к PHP, как известно, OOP прикручено через одно место :(
В общем пиши, а мы почитаем, может действительно пора на руби и рельсы переходить, хотя его распространенность на хостингах явно ниже PHP и потому замена не всегда возможна, да и готовых продуктов типа форумов, блогов, CMS наверняка больше на пыхе.
В общем пиши, а мы почитаем, может действительно пора на руби и рельсы переходить, хотя его распространенность на хостингах явно ниже PHP и потому замена не всегда возможна, да и готовых продуктов типа форумов, блогов, CMS наверняка больше на пыхе.
рельсы лучше чем пых (а рассматривать надо именно рельсы или другие веб-фреймворки рубишные, на чистом руби пишутся десктопные приложения) тем что:
1. есть нормальный мвц
2. есть миграции
3. хтмл генерится кучей хелперов (в том числе и для аякса)
сам язык так же предоставляет нам кучу возможностей для обработки данных (в особых случаях код на руби в 20 строк можно заменить кодом на пыхе размером строк так в 150).
По поводу готовых cms, блогов и прочего. Если вам нужен контентный сайт, то лучше чем жумла, друпал и иже с ними нету ничего. Но если вам нужен некий уникальный функционал, то писать его вам придется самому хоть на пыхе, хоть на руби. Для рельсов есть куча всяких плагинов, которые упрощают разработку типовых задач, таких как текггирование, видео-контент, фото-галереи и прочее.
1. есть нормальный мвц
2. есть миграции
3. хтмл генерится кучей хелперов (в том числе и для аякса)
сам язык так же предоставляет нам кучу возможностей для обработки данных (в особых случаях код на руби в 20 строк можно заменить кодом на пыхе размером строк так в 150).
По поводу готовых cms, блогов и прочего. Если вам нужен контентный сайт, то лучше чем жумла, друпал и иже с ними нету ничего. Но если вам нужен некий уникальный функционал, то писать его вам придется самому хоть на пыхе, хоть на руби. Для рельсов есть куча всяких плагинов, которые упрощают разработку типовых задач, таких как текггирование, видео-контент, фото-галереи и прочее.
Опять сравниваем фреймворк с языком?
Сравнивали бы что ли с ZF, CodeIgniter, CakePHP, и прочим.
Сравнивали бы что ли с ZF, CodeIgniter, CakePHP, и прочим.
Во-во, как раз о том-же хотел написать :) Почему-то аргументация рубишников (рубчиков? рубовчан? :)) не идет дальше чистого php.
по долгу работы видел зенд (сразу скажу что видел мельком, поэтому могу быть и не прав)… спасибо мне хватило… когда обычный контроллер для КРУДа модели с двумя-тремя полями и без внешних ключей занимает строк так 130… когда на рельсах аналог вытягивает в 70-80 строк… и при этом рельсовый код интуитивно читаемее чем зендовский получается
А с чем вы предлагаете сравнивать этого уродца (пхп)? (быдлокодеры! фас! дана команда заминусовать меня!) Ничего, кроме уеб-приложений написать на нём, по большому счёту, нельзя (я в курсе, что есть в теории можно, только кто ж это будет всерьёз делать?), поэтому и сравнивать его кроме как с другими инструментами, предназначеными именно для написания уеб-приложений бессмыссленно. Так что всё нормально здесь. Ну, а то, что как фреймворк пхп убог — ну, так вы ведь сами себе выбрали такой убогий инструмент, что ж теперь жаловаться, что вас, блин, обижают. Сравнивают удобные и мощные инструменты с кривым шаблонизатором-переростком. (Быдлокодеры! Команда «фас» номер два! Ату меня, улю-лю!)
Так не сравнивайте. :) А если сравниваете сравнивайте с аналогами, а не холодное с мокрым.
А в чём проблема? Рельса и пхп — приблуды для изготовления уеб-приложений. И то и другое изначально предназначено и разработано для этого и только для этого и ни для чего более (извращения на побочные темы — множества меры ноль, поэтому не рассматриваются). Проблема в том, что пхп слишком убог при таком сравнении? Ну, так о том и речь!
Холодное с мокрым — это если бы кто-то стал сравнивать руби (ну, или пхп) с Qt, скажем :).
Холодное с мокрым — это если бы кто-то стал сравнивать руби (ну, или пхп) с Qt, скажем :).
пхп — язык, рельсы — фреймворк, сранивать нельзя :) сравнивайте или пхп с руби в какой-либо области (не забывая, что пхп изначально создавался именно как язык для веб-приложений), или рельсы с, например, симфони
Ну и как можно сравнивать пхп с руби? Шаблонизатор с языком? :)
Пхп — то же самое, что и рельсы, они играют на одном поле. Если называть рельсы фреймворком, то и пхп — фреймворк, просто очень убогий (и с этим пхп-only «программисты», видимо, ни как не могут смириться). Если называть пхп языком (в смысле DSL, это, конечно, язык), тогда и рельсы — тоже язык (в том же самом смысле — DSL). Только рельсы — мощный DSL, а пхп… Правильно, опять убогий :) (ну да, опять сравнение не в пользу пхп, ну, звиняйте, братва, так уж у вас получилось хреново...). То, что на убогом DSL можно написать не очень убогий DSL, — ну, да, это специфика такая, средствами рельс можно тоже написать ещё более высокоуровневый DSL, просто это пока никому не нужно. Я именно что сравниваю сущности, используемые для одного и того же. Что касается памяти :), то я не забываю, что пхп создавался для веб-приложений (для этого же создавалась и рельса, заметьте), только пхп создавался, всё-таки не как язык, а как шаблонизатор (если быть точнее — интерпретатор форм). Так что, по-моему, сравнение более чем адекватное. Если вы продолжаете считать инече, повторю вопрос — с чем, по вашему, нужно сравнивать пхп?
Пхп — то же самое, что и рельсы, они играют на одном поле. Если называть рельсы фреймворком, то и пхп — фреймворк, просто очень убогий (и с этим пхп-only «программисты», видимо, ни как не могут смириться). Если называть пхп языком (в смысле DSL, это, конечно, язык), тогда и рельсы — тоже язык (в том же самом смысле — DSL). Только рельсы — мощный DSL, а пхп… Правильно, опять убогий :) (ну да, опять сравнение не в пользу пхп, ну, звиняйте, братва, так уж у вас получилось хреново...). То, что на убогом DSL можно написать не очень убогий DSL, — ну, да, это специфика такая, средствами рельс можно тоже написать ещё более высокоуровневый DSL, просто это пока никому не нужно. Я именно что сравниваю сущности, используемые для одного и того же. Что касается памяти :), то я не забываю, что пхп создавался для веб-приложений (для этого же создавалась и рельса, заметьте), только пхп создавался, всё-таки не как язык, а как шаблонизатор (если быть точнее — интерпретатор форм). Так что, по-моему, сравнение более чем адекватное. Если вы продолжаете считать инече, повторю вопрос — с чем, по вашему, нужно сравнивать пхп?
>Ну и как можно сравнивать пхп с руби? Шаблонизатор с языком? :)
>только пхп создавался, всё-таки не как язык, а как шаблонизатор (если быть точнее — интерпретатор форм)
Вот именно, что создавался, 15 лет назад, однако за это время кое-что изменилось, никогда не слышали о переходе количества в качество? А тут не просто количественные (добавили функций) изменения были.
>в смысле DSL, это, конечно, язык
Все-таки согласны, что PHP язык? А значит сравнивать их можно ;) И не верю, что все сравнения будут в пользу руби, будут свои плюсы, будут свои минусы у каждого, а уж что кому важнее… даже если сравнивать жигули с бентли, то у жигули есть плюсы, иначе бы все давно уже пересели на бентли :)))
>То, что на убогом DSL можно написать не очень убогий DSL, — ну, да, это специфика такая, средствами рельс можно тоже написать ещё более высокоуровневый DSL, просто это пока никому не нужно.
Давайте-таки сравнивать, то что уже написано? Есть руби и пхп, мы уже договорились, что это языки, которые можно сравнивать. Есть рельсы и симфони (кейк, зенд, кодеигнитер, кохана… ). Если можно назвать рельсы языком, то почему не назвать и симфони или кейк языком?
>Я именно что сравниваю сущности, используемые для одного и того же.
php-фреймворки используются для того же, для чего и рельсы, почему вы их не хотите сравнивать?
>только пхп создавался, всё-таки не как язык, а как шаблонизатор (если быть точнее — интерпретатор форм)
Вот именно, что создавался, 15 лет назад, однако за это время кое-что изменилось, никогда не слышали о переходе количества в качество? А тут не просто количественные (добавили функций) изменения были.
>в смысле DSL, это, конечно, язык
Все-таки согласны, что PHP язык? А значит сравнивать их можно ;) И не верю, что все сравнения будут в пользу руби, будут свои плюсы, будут свои минусы у каждого, а уж что кому важнее… даже если сравнивать жигули с бентли, то у жигули есть плюсы, иначе бы все давно уже пересели на бентли :)))
>То, что на убогом DSL можно написать не очень убогий DSL, — ну, да, это специфика такая, средствами рельс можно тоже написать ещё более высокоуровневый DSL, просто это пока никому не нужно.
Давайте-таки сравнивать, то что уже написано? Есть руби и пхп, мы уже договорились, что это языки, которые можно сравнивать. Есть рельсы и симфони (кейк, зенд, кодеигнитер, кохана… ). Если можно назвать рельсы языком, то почему не назвать и симфони или кейк языком?
>Я именно что сравниваю сущности, используемые для одного и того же.
php-фреймворки используются для того же, для чего и рельсы, почему вы их не хотите сравнивать?
>А тут не просто количественные (добавили функций) изменения были.
По-моему, исключительно количественные. Экстенсивный язык. Отсутствие идеи, логики и бездумная свалка малосвязаных «фич» натасканых из разных мест. :( Ну, и про про то для чего создавался вы же сами просили вспомнить, я и вспомнил.
>Все-таки согласны, что PHP язык? А значит сравнивать их можно ;)
Язык. Домен-специфик. И рельса тоже — домен специфик язык. А значит сравнивать их можно. Руби — язык общего назначения.
>И не верю, что все сравнения будут в пользу руби, будут свои плюсы, будут свои минусы у каждого
Ну, так за чем дело стало? Приведите же, наконец, пример. Я уже устал задавать пхп-шникам этот простой вопрос — зачем пользоваться пхп при наличии руби или питона? Пока никто не ответил, возможно, вы станете первым.
>Есть руби и пхп, мы уже договорились, что это языки, которые можно сравнивать.
Есть DSL пхп и DSL рельса. Мы уже договорились, что это домен-специфичные языки, которые можно сравнивать… Сравнивать пхп с руби я не вижу смысла (из жалости к пхп).
>Есть рельсы и симфони (кейк, зенд, кодеигнитер, кохана… ). Если можно назвать рельсы языком, то почему не назвать и симфони или кейк языком?
Потому, что пхп в этой части слишком беден, чтобы на нём можно было написать сколько-нибудь полноценный DSL класса хотя бы рельс. Да, кое какие средства есть и с большой натяжкой, перечисленные вами фреймворки (их, всё же, предпочитают называть фреймворками, правда же? даже их создатели) можно, наверное, называть и частично DSL, и частично фреймворком. Вы в рельсы заглядывали? А загляните! Эти пхп-шные фреймворки — всё-таки больше можно назвать «закатом солнца вручную», нежели тем, что получилось из рельс :).
>php-фреймворки используются для того же, для чего и рельсы, почему вы их не хотите сравнивать?
Ну, например, я не хочу сравнивать пхп-фреймворки с рельсами, потому, что я не знаю хорошо пхп-фреймворков. Вы знаете и то и другое? Прекрасно! Сравнивайте! Лично я запрещать вам это не собираюсь. Это же вы отказываете мне в праве сравнения вполне сравнимых вещей, а я-то — отнюдь нет.
По-моему, исключительно количественные. Экстенсивный язык. Отсутствие идеи, логики и бездумная свалка малосвязаных «фич» натасканых из разных мест. :( Ну, и про про то для чего создавался вы же сами просили вспомнить, я и вспомнил.
>Все-таки согласны, что PHP язык? А значит сравнивать их можно ;)
Язык. Домен-специфик. И рельса тоже — домен специфик язык. А значит сравнивать их можно. Руби — язык общего назначения.
>И не верю, что все сравнения будут в пользу руби, будут свои плюсы, будут свои минусы у каждого
Ну, так за чем дело стало? Приведите же, наконец, пример. Я уже устал задавать пхп-шникам этот простой вопрос — зачем пользоваться пхп при наличии руби или питона? Пока никто не ответил, возможно, вы станете первым.
>Есть руби и пхп, мы уже договорились, что это языки, которые можно сравнивать.
Есть DSL пхп и DSL рельса. Мы уже договорились, что это домен-специфичные языки, которые можно сравнивать… Сравнивать пхп с руби я не вижу смысла (из жалости к пхп).
>Есть рельсы и симфони (кейк, зенд, кодеигнитер, кохана… ). Если можно назвать рельсы языком, то почему не назвать и симфони или кейк языком?
Потому, что пхп в этой части слишком беден, чтобы на нём можно было написать сколько-нибудь полноценный DSL класса хотя бы рельс. Да, кое какие средства есть и с большой натяжкой, перечисленные вами фреймворки (их, всё же, предпочитают называть фреймворками, правда же? даже их создатели) можно, наверное, называть и частично DSL, и частично фреймворком. Вы в рельсы заглядывали? А загляните! Эти пхп-шные фреймворки — всё-таки больше можно назвать «закатом солнца вручную», нежели тем, что получилось из рельс :).
>php-фреймворки используются для того же, для чего и рельсы, почему вы их не хотите сравнивать?
Ну, например, я не хочу сравнивать пхп-фреймворки с рельсами, потому, что я не знаю хорошо пхп-фреймворков. Вы знаете и то и другое? Прекрасно! Сравнивайте! Лично я запрещать вам это не собираюсь. Это же вы отказываете мне в праве сравнения вполне сравнимых вещей, а я-то — отнюдь нет.
>По-моему, исключительно количественные.
Ну у нас разные понятия о количестве и качестве просто. Для меня введение ООП даже в 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/С++, которые на то время были моими основными языками (после русского :) )
Ну у нас разные понятия о количестве и качестве просто. Для меня введение ООП даже в 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/С++, которые на то время были моими основными языками (после русского :) )
>Для меня введение ООП даже в 4-ке было качественным измением.
Уговорили. Одно качественное изменение было :). Как обычно, для этого языка, сначала не подумали даже в чём же там суть, в этом ООП и приделали, как обычно, кривее некуда… Это карма, безусловно.
>What is PHP? PHP is a widely-used general-purpose scripting language…
На заборе «Х..» написано, а там дрова лежат… И гиде он вайдли юзд, для скриптования генерала пёрпоза? На страничке пхп.нет?
>Да, можно изучить язык bash например, но зачем, если и все так работает?
Угу. Когда я говорю, что единственная причина — лень, пхп-шники, отчего-то, обижаются :).
>почему, рельсы ограничивают функциональность руби,
Ой!
>запрещают (на физическом, а не идеологическом) уровне использовать все его возможности?
О-о-о-ой! Где вы этого набрались???
>Или непонятным для меня образом расширяют его возможности?
Ну да. В том числе и языка. Дизайн языка позволяет расширять возможности языка в довольно широких пределах и рельсы этим активно пользуются.
>Можно что-то написать на чистом руби, чего нельзя написать на нем же в рельсах?
Можно ли написать что-то на чистом си, чего нельзя написать на плюсах? :)
Нет, даже не так — вот си, это по сути, чуть более удобный ассемблер. В большинстве компиляторов с си можно вставлять ассемблерные вставки. Вот это где-то близко :). Можно ли в таком случае (си, с ассемблерными вставками) говорить о том, что си и ассемблер являются одним и тем же языком? :)
>почему нельзя сравнивать руби с пхп?
Я же писал, что можно, только это не интересно и пхп сильно жалко становится :).
>Как вы можете судить как можно назвать PHP фреймворки если вы их не знаете хорошо?
Стоп-стоп! Я же не сравниваю и не сужу и прямым текстом говорю, что сравнивать не буду, поскольку не знаю их. Тем более не говорю, что они плохи. Фреймворки, безусловно, в некотором смысле, являются «расширением языка». Любая добавленная функция — не важно, в рантайм её добавили или вы в своей программе, является расширением языка. Одним из способов. Но такие расширения на основе функций, библиотек функций, библиотек классов, как раз принято называть фреймворками. В отличии от DSL. Руби позволяет расширить язык не только этим способом, но и другими. Тут как раз те количественные изменения, которые переходят в качество по закону диалектики :). Я не могу судить о самих этих пхп-фреймворках, но могу судить о том как, возможно, они построены, исходя из моих знаний о возможностях языка пхп. Так вот, на этом поле, руби предоставляет существенно больше возможностей. Речь не о функциональности — она может быть эквивалентной, а о дизайне и логике этих «расширений».
>То есть использовать PHP самая важная причина в современном мире — экономическая :)
Нет уж, договаривайте — не в современном мире, а в мире домашних страничек, для которых пхп изначально и разрабатывался (интрепретатор форм персональных домашних страничек — php-fi). Есть ещё, как минимум, явский мир (очень большой, кстати, и куда более интересный, чем пхп-мирок), которому, по большому счёту, насрать на первые 10 результатов вашего запроса :). Но… Что ж,… тут я, пожалуй, соглашусь — пхп рулит на такой мелочи, где даже рельсу разворачивать лень :).
Уговорили. Одно качественное изменение было :). Как обычно, для этого языка, сначала не подумали даже в чём же там суть, в этом ООП и приделали, как обычно, кривее некуда… Это карма, безусловно.
>What is PHP? PHP is a widely-used general-purpose scripting language…
На заборе «Х..» написано, а там дрова лежат… И гиде он вайдли юзд, для скриптования генерала пёрпоза? На страничке пхп.нет?
>Да, можно изучить язык bash например, но зачем, если и все так работает?
Угу. Когда я говорю, что единственная причина — лень, пхп-шники, отчего-то, обижаются :).
>почему, рельсы ограничивают функциональность руби,
Ой!
>запрещают (на физическом, а не идеологическом) уровне использовать все его возможности?
О-о-о-ой! Где вы этого набрались???
>Или непонятным для меня образом расширяют его возможности?
Ну да. В том числе и языка. Дизайн языка позволяет расширять возможности языка в довольно широких пределах и рельсы этим активно пользуются.
>Можно что-то написать на чистом руби, чего нельзя написать на нем же в рельсах?
Можно ли написать что-то на чистом си, чего нельзя написать на плюсах? :)
Нет, даже не так — вот си, это по сути, чуть более удобный ассемблер. В большинстве компиляторов с си можно вставлять ассемблерные вставки. Вот это где-то близко :). Можно ли в таком случае (си, с ассемблерными вставками) говорить о том, что си и ассемблер являются одним и тем же языком? :)
>почему нельзя сравнивать руби с пхп?
Я же писал, что можно, только это не интересно и пхп сильно жалко становится :).
>Как вы можете судить как можно назвать PHP фреймворки если вы их не знаете хорошо?
Стоп-стоп! Я же не сравниваю и не сужу и прямым текстом говорю, что сравнивать не буду, поскольку не знаю их. Тем более не говорю, что они плохи. Фреймворки, безусловно, в некотором смысле, являются «расширением языка». Любая добавленная функция — не важно, в рантайм её добавили или вы в своей программе, является расширением языка. Одним из способов. Но такие расширения на основе функций, библиотек функций, библиотек классов, как раз принято называть фреймворками. В отличии от DSL. Руби позволяет расширить язык не только этим способом, но и другими. Тут как раз те количественные изменения, которые переходят в качество по закону диалектики :). Я не могу судить о самих этих пхп-фреймворках, но могу судить о том как, возможно, они построены, исходя из моих знаний о возможностях языка пхп. Так вот, на этом поле, руби предоставляет существенно больше возможностей. Речь не о функциональности — она может быть эквивалентной, а о дизайне и логике этих «расширений».
>То есть использовать PHP самая важная причина в современном мире — экономическая :)
Нет уж, договаривайте — не в современном мире, а в мире домашних страничек, для которых пхп изначально и разрабатывался (интрепретатор форм персональных домашних страничек — php-fi). Есть ещё, как минимум, явский мир (очень большой, кстати, и куда более интересный, чем пхп-мирок), которому, по большому счёту, насрать на первые 10 результатов вашего запроса :). Но… Что ж,… тут я, пожалуй, соглашусь — пхп рулит на такой мелочи, где даже рельсу разворачивать лень :).
>Угу. Когда я говорю, что единственная причина — лень, пхп-шники, отчего-то, обижаются :).
Я предпочитаю называть это бритвой Оккама :) А если серьезно, то в свое время убил много времени (да и денег немало) на изучение некоторых языков, например Forth, dBase, Pascal, да и asm тоже just for fun, как потом оказалось. Удели я это время изучению того же PHP — было бы куда рациональней. И как-то юношеский энтузиазм иссяк и изучать что-то, причем довольно непростое, ради самих знаний уже как-то не прельщает.
>Ну да. В том числе и языка. Дизайн языка позволяет расширять возможности языка в довольно широких пределах и рельсы этим активно пользуются.
>Я же писал, что можно, только это не интересно и пхп сильно жалко становится :).
Не пойму я вашей позиции — сравнивать руби с пхп — пхп жалко, а сравнивать рельсы (которые расширяют возможности руби) с тем же пхп — не жалко.
>Нет уж, договаривайте — не в современном мире, а в мире домашних страничек,
Экономические причины они везде одинаковы, и в мире домашних страничек, и в мире транснациональных корпораций, все хотят минимум вложений и максимум дохода. И еще неизвестно каких «страничек» больше — «домашних» на php или «недомашних» на руби или питоне. Особенно если к категории «домашних» относить и, например, pepsi.ru
>Но… Что ж,… тут я, пожалуй, соглашусь — пхп рулит на такой мелочи, где даже рельсу разворачивать лень :).
Кто-то говорил про лень пхпшников? ;) Просто есть экономическая целесообразность и для заказчиков, и для разработчиков. Если у заказчика бюджет на сайт 200$ в год, то предлагать ему вдску даже за 10$ в месяц для разворачивания рельс (причем не давая никаких гарантий работоспособности сервера и его безопасности, т.к. на администрирование этого бюджета уже не хватит) для разработчика означает работать бесплатно, т. к. еще за дизайн надо заплатить из этих денег.
Я предпочитаю называть это бритвой Оккама :) А если серьезно, то в свое время убил много времени (да и денег немало) на изучение некоторых языков, например Forth, dBase, Pascal, да и asm тоже just for fun, как потом оказалось. Удели я это время изучению того же PHP — было бы куда рациональней. И как-то юношеский энтузиазм иссяк и изучать что-то, причем довольно непростое, ради самих знаний уже как-то не прельщает.
>Ну да. В том числе и языка. Дизайн языка позволяет расширять возможности языка в довольно широких пределах и рельсы этим активно пользуются.
>Я же писал, что можно, только это не интересно и пхп сильно жалко становится :).
Не пойму я вашей позиции — сравнивать руби с пхп — пхп жалко, а сравнивать рельсы (которые расширяют возможности руби) с тем же пхп — не жалко.
>Нет уж, договаривайте — не в современном мире, а в мире домашних страничек,
Экономические причины они везде одинаковы, и в мире домашних страничек, и в мире транснациональных корпораций, все хотят минимум вложений и максимум дохода. И еще неизвестно каких «страничек» больше — «домашних» на php или «недомашних» на руби или питоне. Особенно если к категории «домашних» относить и, например, pepsi.ru
>Но… Что ж,… тут я, пожалуй, соглашусь — пхп рулит на такой мелочи, где даже рельсу разворачивать лень :).
Кто-то говорил про лень пхпшников? ;) Просто есть экономическая целесообразность и для заказчиков, и для разработчиков. Если у заказчика бюджет на сайт 200$ в год, то предлагать ему вдску даже за 10$ в месяц для разворачивания рельс (причем не давая никаких гарантий работоспособности сервера и его безопасности, т.к. на администрирование этого бюджета уже не хватит) для разработчика означает работать бесплатно, т. к. еще за дизайн надо заплатить из этих денег.
>за 10$ в месяц для разворачивания рельс (причем не давая никаких гарантий работоспособности сервера и его безопасности
Ну, я и говорю про наколеночные домашние страницы. У пепси.ру разве 10 баксов бюджет? :)
А, кстати, вот не понял. Вы за 10 баксов в месяц даёте гарантию работоспособности сервера, его безопасность и администрирование? Пхп — это такая особая уличная магия, которая позволяет всё это предоставить и гарантировать(!) за 10 баксов? Круто, ага.
Ну, я и говорю про наколеночные домашние страницы. У пепси.ру разве 10 баксов бюджет? :)
А, кстати, вот не понял. Вы за 10 баксов в месяц даёте гарантию работоспособности сервера, его безопасность и администрирование? Пхп — это такая особая уличная магия, которая позволяет всё это предоставить и гарантировать(!) за 10 баксов? Круто, ага.
наколеночные домашние страницы делают вообще на бесплатных хостингах без всякого пхп :)
про бюджет пепси не знаю, привел пример что мир пхп это не только мир домашних страниц, как вы думаете (или делаете вид, что думаете ;) )
Я за 1,5 бакса в месяц даю гарантию, что за последний год аптайм был 99, 98% :) Если я посоветую заказчику какой-нибудь вдс за 10$ в месяц, то мало того, что мне самому все поднимать надо будет (если дебиан-базед, то подниму без проблем скорее всего, иначе гуглить придется, на виртуалку у себя ставить и т. п.), но главное отвечать за безопасность всего сервера. Вдски (и дски) обычно предоставляются как есть, на шаред хостинге я отвечаю только за «дырявость» скрипта, на выделенном мне (а кому еще?) надо будет отвечать и за безопасность ос, апача того же, реагировать, если не дай бог взломать кто-то попытается и т. п.), а бюджет не тот, чтобы я еще и сертификаты администратора *nix шел получать, да и не привлекало никогда администрирование особо, свою машину мучать — это одно, отвечать за чужие совсем другое
про бюджет пепси не знаю, привел пример что мир пхп это не только мир домашних страниц, как вы думаете (или делаете вид, что думаете ;) )
Я за 1,5 бакса в месяц даю гарантию, что за последний год аптайм был 99, 98% :) Если я посоветую заказчику какой-нибудь вдс за 10$ в месяц, то мало того, что мне самому все поднимать надо будет (если дебиан-базед, то подниму без проблем скорее всего, иначе гуглить придется, на виртуалку у себя ставить и т. п.), но главное отвечать за безопасность всего сервера. Вдски (и дски) обычно предоставляются как есть, на шаред хостинге я отвечаю только за «дырявость» скрипта, на выделенном мне (а кому еще?) надо будет отвечать и за безопасность ос, апача того же, реагировать, если не дай бог взломать кто-то попытается и т. п.), а бюджет не тот, чтобы я еще и сертификаты администратора *nix шел получать, да и не привлекало никогда администрирование особо, свою машину мучать — это одно, отвечать за чужие совсем другое
>Я за 1,5 бакса в месяц даю гарантию, что за последний год аптайм был 99, 98%
Сдаётся мне, что эта «гарантия» мало чего стоит, на самом деле. Это скорее способ уйти от отвественности — «за баги пхп, апача, ос, ддос и прочее я не отвечаю». Мило, и удобно для наколеночных проектов. Действительно, _тут_ рельсам делать пока нечего. Полуторабаксовых рельсовых хостингов, аналогичных таковым же пхп-шным я не знаю :).
Сдаётся мне, что эта «гарантия» мало чего стоит, на самом деле. Это скорее способ уйти от отвественности — «за баги пхп, апача, ос, ддос и прочее я не отвечаю». Мило, и удобно для наколеночных проектов. Действительно, _тут_ рельсам делать пока нечего. Полуторабаксовых рельсовых хостингов, аналогичных таковым же пхп-шным я не знаю :).
Ну суть в том, что я могу предложить заказчику несколько вариантов хостинга от бесплатного до собственного дата-центра с необходимой командой и рассказать про преимущества, недостатки и обоснование стоимости каждого из них (утрирую, конечно). В случае с Ruby/Python нижняя планка вариантов сильно повышается, даже если не принимать в расчет бесплатные.
И действительно уход от ответственности — я не *nix-администратор и не беру на себя обязательства, которые не могу выполнить, максимум беру на себя контакт с саппортом хостера. А VDS (и DS), сравнимые по цене с PHP-хостингами предоставляются (те, что я видел) или на условиях полной ответственности клиента или его персонала за безопасность, прежде всего (работу серверного софта из шелла я может не за 5 минут, особенно если не Debian-based, но настрою, но вот утверждать, что у меня открыт только необходимый минимум портов, и работают только необходимый набор демонов я не стану, а на месте хостера, естественно не предоставлял бы никаких гарантий, если дают рутовый доступ, может я там умудрюсь рутовый доступ без пароля открыть), или по цене не сравнимой с ценой PHP-хостингов. Максимум, что саппорт хостинга делает бесплатно, насколько я знаю, это по запросу клиента сбрасывает систему в исходное состояние или восстанавливает ее из бакапов (и то, думаю, если каждый день их просить, то или аккаунт закроют или предложат платить :) ). Так что заботясь о благе заказчика, я не могу рекомендовать ему использование VDS без оплаты стороннего (или силами хостера) администрирования, а VDS с таковой оплатой обычно выходит за рамки бюджета заказчика, зачастую в разы. А заказчиков, знающих что такое рутовый доступ по шеллу я не встречал :)
Естественно, если вы представляете фирму или команду, в составе, которой есть профессиональные админы, ну или сами таковым являетесь, то можно и нужно предлагать клиенту весь спектр услуг связанных с созданием, размещением и поддержкой сайта, но опять-таки делать вы это будете не бесплатно, пускай и не впишите отдельной строкой в счёт. Но я работаю один, и в областях выходящих за область моей компетенции или предлагаю типовые решения, или советую куда обратиться, максимум могу взять на себя общение с другим специалистом, хотя бы потому что знаю побольше заказчика, что собственно от этого специалиста нужно, что должно быть в ТЗ для него, что должно быть на выходе и как его работу контролировать. Но я ничего не решаю за заказчика, только рекомендую, решения принимает он сам, он же несет за них отвественность. Или вы считаете, что раз я посоветовал ему, например, зарегистрировать домен в Ру-Центре, то я должен брать на себя всю ответственность за работу всей их инфраструктуры?
И действительно уход от ответственности — я не *nix-администратор и не беру на себя обязательства, которые не могу выполнить, максимум беру на себя контакт с саппортом хостера. А VDS (и DS), сравнимые по цене с PHP-хостингами предоставляются (те, что я видел) или на условиях полной ответственности клиента или его персонала за безопасность, прежде всего (работу серверного софта из шелла я может не за 5 минут, особенно если не Debian-based, но настрою, но вот утверждать, что у меня открыт только необходимый минимум портов, и работают только необходимый набор демонов я не стану, а на месте хостера, естественно не предоставлял бы никаких гарантий, если дают рутовый доступ, может я там умудрюсь рутовый доступ без пароля открыть), или по цене не сравнимой с ценой PHP-хостингов. Максимум, что саппорт хостинга делает бесплатно, насколько я знаю, это по запросу клиента сбрасывает систему в исходное состояние или восстанавливает ее из бакапов (и то, думаю, если каждый день их просить, то или аккаунт закроют или предложат платить :) ). Так что заботясь о благе заказчика, я не могу рекомендовать ему использование VDS без оплаты стороннего (или силами хостера) администрирования, а VDS с таковой оплатой обычно выходит за рамки бюджета заказчика, зачастую в разы. А заказчиков, знающих что такое рутовый доступ по шеллу я не встречал :)
Естественно, если вы представляете фирму или команду, в составе, которой есть профессиональные админы, ну или сами таковым являетесь, то можно и нужно предлагать клиенту весь спектр услуг связанных с созданием, размещением и поддержкой сайта, но опять-таки делать вы это будете не бесплатно, пускай и не впишите отдельной строкой в счёт. Но я работаю один, и в областях выходящих за область моей компетенции или предлагаю типовые решения, или советую куда обратиться, максимум могу взять на себя общение с другим специалистом, хотя бы потому что знаю побольше заказчика, что собственно от этого специалиста нужно, что должно быть в ТЗ для него, что должно быть на выходе и как его работу контролировать. Но я ничего не решаю за заказчика, только рекомендую, решения принимает он сам, он же несет за них отвественность. Или вы считаете, что раз я посоветовал ему, например, зарегистрировать домен в Ру-Центре, то я должен брать на себя всю ответственность за работу всей их инфраструктуры?
>И действительно уход от ответственности
Вот-вот. Не обманывайте себя (и заказчика) словом «гарантия».
>сравнимые по цене с PHP-хостингами
По-моему, разница 10 или 20 (ну, даже пусть 50) баксов для оплаты хостинга для нормального заказчика, по-моему, исчезающе мала. Если он _даже_ на этом хочет съэкономить _такие_ гроши… Ну… Я уже говорил о наколеночных домашних страничках. Да, это сектор пхп и конкурентов там ему пока нет. Но… ведь это не интересно, бесконечно ваять хоумпейджи и сайты-визитки для нано-заказчиков, которые (готов поспорить), что большинство не вполне отдают себе отчёт — зачем им нужен сайт. «Шоб було». Иёп, тут пхп вне конкуренции.
Вот-вот. Не обманывайте себя (и заказчика) словом «гарантия».
>сравнимые по цене с PHP-хостингами
По-моему, разница 10 или 20 (ну, даже пусть 50) баксов для оплаты хостинга для нормального заказчика, по-моему, исчезающе мала. Если он _даже_ на этом хочет съэкономить _такие_ гроши… Ну… Я уже говорил о наколеночных домашних страничках. Да, это сектор пхп и конкурентов там ему пока нет. Но… ведь это не интересно, бесконечно ваять хоумпейджи и сайты-визитки для нано-заказчиков, которые (готов поспорить), что большинство не вполне отдают себе отчёт — зачем им нужен сайт. «Шоб було». Иёп, тут пхп вне конкуренции.
Ну «гарантия» слово я не употребляю в отношении хостингов и прочих вещей, которые не контролирую, гарантии даю только на результаты своей работы, то есть, в основном, на код пхп. Все остальное только рекомендую предоставляя альтернативы как минимум в виде ссылки на гугл :)
Действительно неинтересно, и спорить насчет того, что знают зачем сайт, не буду :) Интересные заказы редко встречаются, разве что какой-нибудь «сеошный»плагин для вордпресса, требующий и псевдомногопоточность реализовать, и работу со списком проксей с их автоматической проверкой на работу вообще, уровень анонимности и то, что они не в блеклисте какого-нибудь хоста. А так да. хоумпеджи, блоги, визитки, иногда партнерские «магазины» и т. п. И даже не прочь бы выйти на уровень повыше, и не важно на каком языке писать для этого придется, но что-то не встречал предложений на удаленную работу начинающих «рубистов», «питонщиков», «сишарпников» или «явистов», даже бесплатную, чисто на портфолио. Не показывать же в качестве портфолио примеры из туториалов и мануалов? :) А вот PHP-программист такую работу найти может.
Действительно неинтересно, и спорить насчет того, что знают зачем сайт, не буду :) Интересные заказы редко встречаются, разве что какой-нибудь «сеошный»плагин для вордпресса, требующий и псевдомногопоточность реализовать, и работу со списком проксей с их автоматической проверкой на работу вообще, уровень анонимности и то, что они не в блеклисте какого-нибудь хоста. А так да. хоумпеджи, блоги, визитки, иногда партнерские «магазины» и т. п. И даже не прочь бы выйти на уровень повыше, и не важно на каком языке писать для этого придется, но что-то не встречал предложений на удаленную работу начинающих «рубистов», «питонщиков», «сишарпников» или «явистов», даже бесплатную, чисто на портфолио. Не показывать же в качестве портфолио примеры из туториалов и мануалов? :) А вот PHP-программист такую работу найти может.
>Не пойму я вашей позиции — сравнивать руби с пхп — пхп жалко, а сравнивать рельсы (которые расширяют возможности руби) с тем же пхп — не жалко.
Ну, вот, с больной головы на здоровую. Я говорил о том, что рельсы с пхп вполне можно сравнивать. Они играют на одном поле. А сравнивать руби с пхп — какой смысл сравнивать язык с шаблонизатором? (кажется, я это уже говорил). Я вот как-то надысь писал конкурсный пропозал для подразделения одной из дочек дзайбацу мацусита (у нас она известна как производитель телевизоров, принтеров, фото-, видео- и прочей электроники) на разработку ПО для их девайса с помощью руби, qt и сей (для драйверов). Моё предложение не прошло, прошло альтернативное, самое большое отличие — вместо руби там был питон (питонистов найти у нас полегче). Ответьте, положа руку на сердце, стал бы кто-нибудь всерьёз рассматривать такого рода предложение с пхп в качестве основного языка для разработки десктопного кроссплатформенного графического приложения для работы со специализированным девайсом? И стал бы кто-нибудь всерьёз писать даже такой пропозал? После этого ещё раз задайте (себе) вопрос о смысле сравнения руби и пхп в общем случае :). Вот поэтому и жалко — если в вебе пхп и рельса хоть как-то конкурируют, то вне веба пхп смысла не имеет вообще. Можно тешить себя фразами с пхп.нет и вашей системой мониторинга (добавить сюда второго известного мне человека — болка с его периодом писания полезных утилит на пхп). Но это все не серьёзно.
Ну, вот, с больной головы на здоровую. Я говорил о том, что рельсы с пхп вполне можно сравнивать. Они играют на одном поле. А сравнивать руби с пхп — какой смысл сравнивать язык с шаблонизатором? (кажется, я это уже говорил). Я вот как-то надысь писал конкурсный пропозал для подразделения одной из дочек дзайбацу мацусита (у нас она известна как производитель телевизоров, принтеров, фото-, видео- и прочей электроники) на разработку ПО для их девайса с помощью руби, qt и сей (для драйверов). Моё предложение не прошло, прошло альтернативное, самое большое отличие — вместо руби там был питон (питонистов найти у нас полегче). Ответьте, положа руку на сердце, стал бы кто-нибудь всерьёз рассматривать такого рода предложение с пхп в качестве основного языка для разработки десктопного кроссплатформенного графического приложения для работы со специализированным девайсом? И стал бы кто-нибудь всерьёз писать даже такой пропозал? После этого ещё раз задайте (себе) вопрос о смысле сравнения руби и пхп в общем случае :). Вот поэтому и жалко — если в вебе пхп и рельса хоть как-то конкурируют, то вне веба пхп смысла не имеет вообще. Можно тешить себя фразами с пхп.нет и вашей системой мониторинга (добавить сюда второго известного мне человека — болка с его периодом писания полезных утилит на пхп). Но это все не серьёзно.
Это я все прекрасно понимаю, место пхп в вебе, максимум замена шеллового языка (уж по сравнению с языком cmd он явно мощнее), гуи на php писать следует только при очень серьезных причинах. Но все равно, сравнивать можно и нужно либо языки, либо продукты на них написанные. Говорим мы о веб-разработке. Вот я сейчас дома поставил руби как cgi модуль апача, «hello, world» выел на ruby.localhost, рельсы пока ставить не собираюсь. какие преимущества использования руби (а не рельсов) я получу, если, например, начну сейчас с нуля писать скрипт каталога сайтов и доски объявлений? без фреймворков, кмсок, только стандартные средства языка и библиотеки для работы с http и mysql, если таковых нет встроенных?
Cкажем вкратце описать почему для этого я буду использовать PHP, а не С я могу, хотя у С есть свои плюсы, но есть и минусы, а вот о плюсах и минусах использования чистого Ruby в качестве языка серверных веб-скриптов я не знаю ничего, кроме этой статьи:
* Язык предельно лёгок в изучении в сравнении с другими ЯП
* Полностью объектно-ориентированный
* Нет необходимости писать много кода
* Очень расширяемый
* Open Source
И то, как минимум в двух пунктах я сомневаюсь, насчет много кода (но не знаю относится это к рельсам или к самому руби, потому не считаю), предельной легкости и объектно-ориентированности (есть мнение, что руби объектный изначально, а не сменил ориентацию с процедурной :) )
Cкажем вкратце описать почему для этого я буду использовать PHP, а не С я могу, хотя у С есть свои плюсы, но есть и минусы, а вот о плюсах и минусах использования чистого Ruby в качестве языка серверных веб-скриптов я не знаю ничего, кроме этой статьи:
* Язык предельно лёгок в изучении в сравнении с другими ЯП
* Полностью объектно-ориентированный
* Нет необходимости писать много кода
* Очень расширяемый
* Open Source
И то, как минимум в двух пунктах я сомневаюсь, насчет много кода (но не знаю относится это к рельсам или к самому руби, потому не считаю), предельной легкости и объектно-ориентированности (есть мнение, что руби объектный изначально, а не сменил ориентацию с процедурной :) )
>какие преимущества использования руби (а не рельсов) я получу, если, например, начну сейчас с нуля писать скрипт каталога сайтов и доски объявлений? без фреймворков, кмсок, только стандартные средства языка и библиотеки для работы с http и mysql, если таковых нет встроенных?
Вот потому человек и сравнивает язык пхп с руби-фреймворком, потому что пхп сам по себе можно считать фреймворком — в него встроены средства для работы с cgi, бд, куками, сессиями и т.п. — все то что в языках общего назначения подключается через отдельные модули/фреймворки.
Вот потому человек и сравнивает язык пхп с руби-фреймворком, потому что пхп сам по себе можно считать фреймворком — в него встроены средства для работы с cgi, бд, куками, сессиями и т.п. — все то что в языках общего назначения подключается через отдельные модули/фреймворки.
Что-то мне подсказывает, что рельсы — это нечто большое, чем набор функций/классов для работы с бд, куками и сессиями.
А результат сравнения любого приличного веб-фреймворка с «голым» 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 (или другие) фреймворки с их аналогами?
А результат сравнения любого приличного веб-фреймворка с «голым» 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 (или другие) фреймворки с их аналогами?
>Давайте все-таки сравнивать языки с языками
Давайте, давайте ужо. Я у вас уже спрашивал — дадите ли вы зуб за то, что хоть кто-либо из разбирающихся в теме заказчиков не выкинет в корзину сразу нечитая «проект», который не веб и который предлагается написать на «языке» пхп? А «архитектора» такого проекта не занесёт в список людей с которыми не стоит иметь дело никогда по причине неадекватности? Нормальный проект, не вашу мониторилку (мир ей), не болковские утилиты на 20 строк для удаления мусора из жпегов (мир им), а что-то серьёзное. И пример, пожалуйста. Вот тогда, да, можно уже будет сравнивать языки с «языками» :). А так это будет похоже на избиение младенцев :).
Давайте, давайте ужо. Я у вас уже спрашивал — дадите ли вы зуб за то, что хоть кто-либо из разбирающихся в теме заказчиков не выкинет в корзину сразу нечитая «проект», который не веб и который предлагается написать на «языке» пхп? А «архитектора» такого проекта не занесёт в список людей с которыми не стоит иметь дело никогда по причине неадекватности? Нормальный проект, не вашу мониторилку (мир ей), не болковские утилиты на 20 строк для удаления мусора из жпегов (мир им), а что-то серьёзное. И пример, пожалуйста. Вот тогда, да, можно уже будет сравнивать языки с «языками» :). А так это будет похоже на избиение младенцев :).
Конечно не дам, но вообще разговор начинался в контексте веба (или у рельс другое основное назначение?), и предлагал я сравнивать в том же контексте (мне это казалось само собой разумеющимся, грубо говоря один и тот же апач с «прикрученными» пхп и руби, ну и мускул или другая БД), а если уж хочется рельсы сравнить (слышал тезисы типа «мы говорим руби в вебе — подразумеваем рельсы» :) ), то тогда и сравнивать надо не голый пхп с рельсами. а пхп с фреймворком (лично я бы выбрал симфони или кейкпхп для сравнения, ZF и CI мне не очень понравились, слишком, имхо, низкоуровневые и недостаточно абстрагируют и ненавязчиво принуждают к написанию простого, понятного, реюзабельного и т. п. кода) и руби с фреймворком
>но вообще разговор начинался в контексте веба (или у рельс другое основное назначение?)
Вот именно. В контексте веба. У рельс не другое назначение. А ровно то же, что и у пхп. Поэтому их можно сравнивать. Какой раз я это сказал? :)
Контекст идентичен. В чём проблема? Ах, в том, что пхп в этом сравнении проигрывает со свистом? Ну так это не проблема самого сравнения, а проблема исключительно пхп. Ну, такой вот он убогенький фреймворчок оказался. Об этом речь и только об этом.
>слышал тезисы типа «мы говорим руби в вебе — подразумеваем рельсы» :)
Это проблемы исключительно говорящих. На деле всё более интереснее и многообразнее. :)
>тогда и сравнивать надо не голый пхп с рельсами. а пхп с фреймворком
Да тоже можно, я и это уже более одного раза сказал :). Я о том, что нет причин не сравнивать пхп с рельсами :).
Вот именно. В контексте веба. У рельс не другое назначение. А ровно то же, что и у пхп. Поэтому их можно сравнивать. Какой раз я это сказал? :)
Контекст идентичен. В чём проблема? Ах, в том, что пхп в этом сравнении проигрывает со свистом? Ну так это не проблема самого сравнения, а проблема исключительно пхп. Ну, такой вот он убогенький фреймворчок оказался. Об этом речь и только об этом.
>слышал тезисы типа «мы говорим руби в вебе — подразумеваем рельсы» :)
Это проблемы исключительно говорящих. На деле всё более интереснее и многообразнее. :)
>тогда и сравнивать надо не голый пхп с рельсами. а пхп с фреймворком
Да тоже можно, я и это уже более одного раза сказал :). Я о том, что нет причин не сравнивать пхп с рельсами :).
>Я о том, что нет причин не сравнивать пхп с рельсами :).
Ну причину вы сами указывали :) дословно не помню, но смысл в том, что на базе Рельсов можно создать еще более абстрактный DSL для веба, но никому это не нужно, а раз для пхп создали, то и сравнивать, имхо, нужно самые высокие уровни абстракции из существующих ;) А то получается сравнение средневековой мастерской и современного цеха
Ну причину вы сами указывали :) дословно не помню, но смысл в том, что на базе Рельсов можно создать еще более абстрактный DSL для веба, но никому это не нужно, а раз для пхп создали, то и сравнивать, имхо, нужно самые высокие уровни абстракции из существующих ;) А то получается сравнение средневековой мастерской и современного цеха
>какие преимущества использования руби (а не рельсов) я получу, если, например, начну сейчас с нуля писать скрипт каталога сайтов и доски объявлений?
Большие и никаких :).
Никаких — потому, что, ну, язык, ну, можно писать, по сравнению с пхп — всё плохо, поскольку нет встроенного модуля, облегчающего работу с хттп, надо привыкать к остутствию нагромождения бессмысленных функций делающих одно и то же и отличающихся только порядком аргументов и скоростью работы (пропадёт часть тайного знания, отличающего пхп-гуру от непосвящённого) и руби медленнее. Ага, ещё нет встроенной возможности смешивать код с разметкой :). Ну и состояние mod_ruby в плане юзабельности в продакшене мне, например, неизвестно (некоторое время назад говорили, что оно малою пригодно к применению — ну, чего не в курсе, того не в курсе).
Большие — это приятный, продуманый, логически стройный и красивый язык. На нём приятно писать. Необходимость писания на пхп лично у меня вызывает тошноту — орочий язык, какой-то :), нелюдской.
По вашим пунктам — легкий, ага. Надо разобраться с замыканиями (блоками, в терминологии руби) — они широко используются и очень удобны, но для императивщика выглядят дико — это «превед» из функциональных языков. Очень удобный, но требует привыкания. Есть и ещё сложности, но на первых порах с ними ещё надо постараться столкнуться. Всё остальное — предельно просто. Язык создавался для людей, а не для лексического анализатора (как пхп). Несмотря на приветы из функциональщины — для императивщика язык всё-таки привычно прост, проще, чем смолток, например (раз уж о нём заходила речь).
«Полностью объектно-ориентированый» — это какая-то рекламная мантра :), несущая мало смысла. Да, в руби «всё есть объект» и можно писать — послать объекту класса такого-то, со значением еденица сообщение «прибавить» с агрументом — два, — есть для этого соответствующий синтаксис и есть случаи, когда он оправдан. Но, опять же, язык создан для людей, а не для лексических анализаторов, поэтому, в большинстве случаев, прокатывает привычная запись «1 + 2» :) (там есть некотороя тонкость с пробелами и в некоторых случаях выразение, валидное в других языках, может быть распознано неверно, поэтому лучше ставить пробелы с обеих сторон от знаков арифметических операций, ну, считайте это небольшой платой за «всё есть объект».
Код можно писать кратко. Да. И, при этом, красиво. В каком-то смысле руби — это улучшеный перл :) — от перла там осталось много и хорошего и чутка не очень, но этим «не очень» крайне редко пользуются (философия несколько другая) и, говорят, в будущем истребят.
Расширяемый — ну, да, на основе руби сделали несколько интересных DSL — в каком-то смысле это всё расширения языка. Те же рельсы, Rake (аналог make) и прочее.
Опен-сурс — ну, то, что я в генте могу собрать его в нужной мне комплектации — конечно, достоинство, в какой-то степени :).
Для серверных веб-скриптов голый руби вполне пригоден (с оговорками выше), разве что надо будет или выдрать откуда-нибудь или написать самому (благо это не сложно) модуль работы с хттп. А, да, и что-то для шаблонизаторства (ну, тут выбор уже готового велик, велосипед изобретать не надо). Можно, но большого смысла здесь нет — велосипеды уже изобретены и есть на свете уже немаленькая кучка существенно менее тяжёлых, чем рельсы, фреймворков. По сути — это наборы одних и тех же библиотек, сдобреных бОльшей или меньшей порцией «клея» — обвязкой, собирающей всё вместе для удобства, некоей идеологией и выполняющей однотипную рутину. Если не понравится существующий, можно поглядеть как это сделано (обём «клея» там невелик, как правило) и написать свой аналог по вкусу…
Большие и никаких :).
Никаких — потому, что, ну, язык, ну, можно писать, по сравнению с пхп — всё плохо, поскольку нет встроенного модуля, облегчающего работу с хттп, надо привыкать к остутствию нагромождения бессмысленных функций делающих одно и то же и отличающихся только порядком аргументов и скоростью работы (пропадёт часть тайного знания, отличающего пхп-гуру от непосвящённого) и руби медленнее. Ага, ещё нет встроенной возможности смешивать код с разметкой :). Ну и состояние mod_ruby в плане юзабельности в продакшене мне, например, неизвестно (некоторое время назад говорили, что оно малою пригодно к применению — ну, чего не в курсе, того не в курсе).
Большие — это приятный, продуманый, логически стройный и красивый язык. На нём приятно писать. Необходимость писания на пхп лично у меня вызывает тошноту — орочий язык, какой-то :), нелюдской.
По вашим пунктам — легкий, ага. Надо разобраться с замыканиями (блоками, в терминологии руби) — они широко используются и очень удобны, но для императивщика выглядят дико — это «превед» из функциональных языков. Очень удобный, но требует привыкания. Есть и ещё сложности, но на первых порах с ними ещё надо постараться столкнуться. Всё остальное — предельно просто. Язык создавался для людей, а не для лексического анализатора (как пхп). Несмотря на приветы из функциональщины — для императивщика язык всё-таки привычно прост, проще, чем смолток, например (раз уж о нём заходила речь).
«Полностью объектно-ориентированый» — это какая-то рекламная мантра :), несущая мало смысла. Да, в руби «всё есть объект» и можно писать — послать объекту класса такого-то, со значением еденица сообщение «прибавить» с агрументом — два, — есть для этого соответствующий синтаксис и есть случаи, когда он оправдан. Но, опять же, язык создан для людей, а не для лексических анализаторов, поэтому, в большинстве случаев, прокатывает привычная запись «1 + 2» :) (там есть некотороя тонкость с пробелами и в некоторых случаях выразение, валидное в других языках, может быть распознано неверно, поэтому лучше ставить пробелы с обеих сторон от знаков арифметических операций, ну, считайте это небольшой платой за «всё есть объект».
Код можно писать кратко. Да. И, при этом, красиво. В каком-то смысле руби — это улучшеный перл :) — от перла там осталось много и хорошего и чутка не очень, но этим «не очень» крайне редко пользуются (философия несколько другая) и, говорят, в будущем истребят.
Расширяемый — ну, да, на основе руби сделали несколько интересных DSL — в каком-то смысле это всё расширения языка. Те же рельсы, Rake (аналог make) и прочее.
Опен-сурс — ну, то, что я в генте могу собрать его в нужной мне комплектации — конечно, достоинство, в какой-то степени :).
Для серверных веб-скриптов голый руби вполне пригоден (с оговорками выше), разве что надо будет или выдрать откуда-нибудь или написать самому (благо это не сложно) модуль работы с хттп. А, да, и что-то для шаблонизаторства (ну, тут выбор уже готового велик, велосипед изобретать не надо). Можно, но большого смысла здесь нет — велосипеды уже изобретены и есть на свете уже немаленькая кучка существенно менее тяжёлых, чем рельсы, фреймворков. По сути — это наборы одних и тех же библиотек, сдобреных бОльшей или меньшей порцией «клея» — обвязкой, собирающей всё вместе для удобства, некоей идеологией и выполняющей однотипную рутину. Если не понравится существующий, можно поглядеть как это сделано (обём «клея» там невелик, как правило) и написать свой аналог по вкусу…
Спасибо за подробный экскурс, чего-то подобного я с самого начала этого «холивара» и хотел :)
Главный в минус руби по вашему описанию для меня лично — шаблонизатор. Хотя и привык разделять «бизнес»- логику и представление, но, видимо, придется для веба еще один «язык» изучать (или придумывать самому и регекспами гонять :), а может пхп прикрутить попробовать, раз уж он шаблонизатором создан :)))))) ), как-то не тру, по-моему, будет писать puts "<html… >\n", не для того я с Си ушел на пхп… ну или Smarty вспоминать, если есть шаблонизаторы с его синтаксисом (а наверняка есть, я даже на сях такой видел :) ). C http, наверное, проблем не будет, наверняка доступ к argc/argv в том или ином виде есть, а прикручивают, как я понял, руби к апачу чаще всего через cgi (fcgi).
Просто я привык использовать сторонние библиотеки/фреймворки после попытки изобретения велосипеда, больше понимания того, что внутри происходит, да и сравнение своего кода и кода опытных разработчиков показывает какие нюансы языка я упустил. А вызывать высокоабстрагированые функции/методы в режиме «черного ящика» не мой стиль :(
Главный в минус руби по вашему описанию для меня лично — шаблонизатор. Хотя и привык разделять «бизнес»- логику и представление, но, видимо, придется для веба еще один «язык» изучать (или придумывать самому и регекспами гонять :), а может пхп прикрутить попробовать, раз уж он шаблонизатором создан :)))))) ), как-то не тру, по-моему, будет писать puts "<html… >\n", не для того я с Си ушел на пхп… ну или Smarty вспоминать, если есть шаблонизаторы с его синтаксисом (а наверняка есть, я даже на сях такой видел :) ). C http, наверное, проблем не будет, наверняка доступ к argc/argv в том или ином виде есть, а прикручивают, как я понял, руби к апачу чаще всего через cgi (fcgi).
Просто я привык использовать сторонние библиотеки/фреймворки после попытки изобретения велосипеда, больше понимания того, что внутри происходит, да и сравнение своего кода и кода опытных разработчиков показывает какие нюансы языка я упустил. А вызывать высокоабстрагированые функции/методы в режиме «черного ящика» не мой стиль :(
Да нет там никакого минуса. Просто голый руби в качестве веб-скриптового языка какой смысл использовать, если там уже сделали десяток, а то и больше цельных вкусных штук и несколько десятков просто приблуд, которые подключаются к любому цельному фреймворку. «Шаблонизаторы» — от erb — как jsp и пхп, до xslt на любой вкус. Всякие костыли типа смарти, наверное, тоже есть, только это ведь костыль довольно непонятного назанчения, зачем его тащить в хорошее место… Велосипеды… Интересно, а xslt-трансформер вы ещё свой не писали? :)
Тоже мог бы сказать про голый пхп и вкусные штуки, но договорились прекратить «холивар» ;)
Ну синтаксис смарти де-факто очень распространен и при переезде сайта с пхп на руби было бы неплохо хотя бы на первое время оставить существующие шаблоны. Да и как про способ описания шаблонов ничего плохого сказать не могу, кроме того, что в связке с php он, имхо, излишен. Переменные выводит, ветвления и циклы есть, инклуды всяческие тоже, язык как язык :)
Еще хуже, когда я открыл для себя xml первая моя мысль была, что он идеально подходит для описания сайта (включая структуру СУБД), в том числе и как язык описания шаблонов :) так что я создал свое расширение XML (и написал для него трансформер, конечно на php :) ) и очень расстроился, когда узнал, что уже есть xslt и я не реализовал и четверти его возможностей, а встроенный в php трансформер работает на порядок быстрее моего :(
Ну синтаксис смарти де-факто очень распространен и при переезде сайта с пхп на руби было бы неплохо хотя бы на первое время оставить существующие шаблоны. Да и как про способ описания шаблонов ничего плохого сказать не могу, кроме того, что в связке с php он, имхо, излишен. Переменные выводит, ветвления и циклы есть, инклуды всяческие тоже, язык как язык :)
Еще хуже, когда я открыл для себя xml первая моя мысль была, что он идеально подходит для описания сайта (включая структуру СУБД), в том числе и как язык описания шаблонов :) так что я создал свое расширение XML (и написал для него трансформер, конечно на php :) ) и очень расстроился, когда узнал, что уже есть xslt и я не реализовал и четверти его возможностей, а встроенный в php трансформер работает на порядок быстрее моего :(
>из 9 хостинг-провайдеров (10-й результат вики) ни одна не поддерживает на виртуальном хостинге руби и толька одна питон, да даже perl не все поддерживают, php+mysql наиболее широко предлагающаяся на рынке окружение для разработки веб-приложений. То есть использовать PHP самая важная причина в современном мире — экономическая :) И. кстати, видимо по ней же до сих пор все не ездят на бентли :)
Глупые аргументы. Если в одном из десяти автосалонов вам предложат бентли, а в остальных — жигули (за сравнимую цену), вы конечно же купите жигули, не сомневаюсь. Миллионы мух не могут ошибаться.
Действительно, хостинг для руби/пайтона найти сложнее, но вполне реально. Тем более что никто вас не заставляет каждый раз искать нового хостера, да и свет клином не сошелся на виртуальном хостинге. Плюс даже если пхп-хостинг будет дешевле, вряд ли это окупит затраты на поддержку пхп-быдлокода, а ресурсов пхп ест побольше чем тот же пайтон. Хотя конечно, для домашних веб-страничек пхп — идеальный вариант. А еще на нем можно писать дорвеи и дейтинги :)
>Не говоря уж о том, что порог вхождения в php традиционно считается низким, да я и сам его выбрал лет 10 назад именно из-за большой схожестью с C/С++
Именно этот низкий порог вхождения обеспечил пхп славу языка быдлокодеров. Сомневаюсь что это преимущество пхп над руби/пайтоном. Вижуал бейсик что-то не в большом почете у программистов.
И никакой большой схожести с С/С++ у него нет — разве что синтаксис немного похож.
Глупые аргументы. Если в одном из десяти автосалонов вам предложат бентли, а в остальных — жигули (за сравнимую цену), вы конечно же купите жигули, не сомневаюсь. Миллионы мух не могут ошибаться.
Действительно, хостинг для руби/пайтона найти сложнее, но вполне реально. Тем более что никто вас не заставляет каждый раз искать нового хостера, да и свет клином не сошелся на виртуальном хостинге. Плюс даже если пхп-хостинг будет дешевле, вряд ли это окупит затраты на поддержку пхп-быдлокода, а ресурсов пхп ест побольше чем тот же пайтон. Хотя конечно, для домашних веб-страничек пхп — идеальный вариант. А еще на нем можно писать дорвеи и дейтинги :)
>Не говоря уж о том, что порог вхождения в php традиционно считается низким, да я и сам его выбрал лет 10 назад именно из-за большой схожестью с C/С++
Именно этот низкий порог вхождения обеспечил пхп славу языка быдлокодеров. Сомневаюсь что это преимущество пхп над руби/пайтоном. Вижуал бейсик что-то не в большом почете у программистов.
И никакой большой схожести с С/С++ у него нет — разве что синтаксис немного похож.
>Глупые аргументы. Если в одном из десяти автосалонов вам предложат бентли, а в остальных — жигули (за сравнимую цену), вы конечно же купите жигули, не сомневаюсь. Миллионы мух не могут ошибаться.
Немного не так — ко мне придет заказчик и скажет «вот тебе пачка денег, купи мне любую машину, главное чтобы ездила, закажешь тюнинг, чтоб тут был кондиционер, тут бар, тут магнитола и пульт ДУ общий, и вообще чтоб в веселнькую расцыеточку ее перкрасили, заводская окраска как у всех мне не нравится, потом машину обкатаешь, купишь страховку на год, заправишь полный бак и передашь мне с ключами, что останется — тебе за работу». Я прикину, что даже если у меня есть возможность взять бентли бесплатно 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 :)
Немного не так — ко мне придет заказчик и скажет «вот тебе пачка денег, купи мне любую машину, главное чтобы ездила, закажешь тюнинг, чтоб тут был кондиционер, тут бар, тут магнитола и пульт ДУ общий, и вообще чтоб в веселнькую расцыеточку ее перкрасили, заводская окраска как у всех мне не нравится, потом машину обкатаешь, купишь страховку на год, заправишь полный бак и передашь мне с ключами, что останется — тебе за работу». Я прикину, что даже если у меня есть возможность взять бентли бесплатно 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 :)
Лень уже отвечать на каждый пункт, спор будет бесконечным, предлагаю его закончить.
Отвечу только на P.S.
На мой взгляд основной недостаток PHP по сравнения с модными нынче Ruby/Python — это его дизайн. Язык изначально задумывался как некий вижуал бейсик для веба, и он продолжает им быть и сейчас. Начать заниматься веб-разработкой легче на PHP, точно так же как и начать «программировать» легче на вижуал бейсике. Но когда вы решите продвинуться дальше Personal Home Pages (или калькулятора на VB) — сам язык будет вас тормозить.
Не нужно ждать цикла статей о превосходстве чего-либо над PHP. Просто возьмите и попробуйте тот же Python. Решение практически любой задачи на нем будет выглядеть более лаконично, элегантно и понятно, чем на PHP. Просто потому что язык задумывался именно как лаконичный и легкочитаемый.
Если вы решаете определенную задачу на PHP за 5 часов и берете за это 50$ — на Python вы решите ее быстрее, а сколько денег за это брать уже ваше дело.
Отвечу только на P.S.
На мой взгляд основной недостаток PHP по сравнения с модными нынче Ruby/Python — это его дизайн. Язык изначально задумывался как некий вижуал бейсик для веба, и он продолжает им быть и сейчас. Начать заниматься веб-разработкой легче на PHP, точно так же как и начать «программировать» легче на вижуал бейсике. Но когда вы решите продвинуться дальше Personal Home Pages (или калькулятора на VB) — сам язык будет вас тормозить.
Не нужно ждать цикла статей о превосходстве чего-либо над PHP. Просто возьмите и попробуйте тот же Python. Решение практически любой задачи на нем будет выглядеть более лаконично, элегантно и понятно, чем на PHP. Просто потому что язык задумывался именно как лаконичный и легкочитаемый.
Если вы решаете определенную задачу на PHP за 5 часов и берете за это 50$ — на Python вы решите ее быстрее, а сколько денег за это брать уже ваше дело.
Согласен, что пора бы закончить :) Но напоследок отвечу, без задавания вопросов
Насчет дизайна спорить и не стал бы, особенно учитывая, что практически все развитие языка от 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, но, скорее всего, даже не смотря на то, что буду считать его уродским, работать с ним придется еще очень долго, пока мои потенциальные заказчики не будут считать также, а их хостеры не обеспечат поддержку этих языков.
Насчет дизайна спорить и не стал бы, особенно учитывая, что практически все развитие языка от 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, но, скорее всего, даже не смотря на то, что буду считать его уродским, работать с ним придется еще очень долго, пока мои потенциальные заказчики не будут считать также, а их хостеры не обеспечат поддержку этих языков.
Толсто!
То что вам не нравится php я вижу и переубеждать не собираюсь.
Стандартные доводы в пользу рельсов в отличии от пхп — нет mvc, нет хелперов и прочее, хотя они все есть в php-фреймворках.
Второе, то что пользователям и заказчикам по большей части абосолютно ровно на чем написан продукт, главное чтобы он был удобным, быстрым, расширяемым, etc. Думаете, это нерализуемо на php?
Если хотите поспорить давайте лучше поговрим на тему RoR vs. Django. Где большинство плюсов, все же на мой взгляд, у последнего. (Могу ошибаться с RoR работал мало — не очень понравилось, django оказался как-то ближе)
То что вам не нравится php я вижу и переубеждать не собираюсь.
Стандартные доводы в пользу рельсов в отличии от пхп — нет mvc, нет хелперов и прочее, хотя они все есть в php-фреймворках.
Второе, то что пользователям и заказчикам по большей части абосолютно ровно на чем написан продукт, главное чтобы он был удобным, быстрым, расширяемым, etc. Думаете, это нерализуемо на php?
Если хотите поспорить давайте лучше поговрим на тему RoR vs. Django. Где большинство плюсов, все же на мой взгляд, у последнего. (Могу ошибаться с RoR работал мало — не очень понравилось, django оказался как-то ближе)
>Думаете, это нерализуемо на php?
Отчего же? Это реализуемо даже на ассемблере. Разница «всего лишь» в количестве потребных для этого усилий :). Но я там о другом немного — о возможности сравнения говорил. У пхп-шников при слове «рельсы» модно принять позу эдакого обиженного и опущенного, — а чё вы, — типа, — «язык» с фреймворком сравниваете… Да был бы то язык!.. :)
Рельса против Джанги — тут я пас, пару раз пытался вникнуть в концепцию джанги, но времени не хватало, а из того, что осилил, не очень глянулось, поэтому мнение моё тут более чем субъективное и не составляет предмета для спора :).
Отчего же? Это реализуемо даже на ассемблере. Разница «всего лишь» в количестве потребных для этого усилий :). Но я там о другом немного — о возможности сравнения говорил. У пхп-шников при слове «рельсы» модно принять позу эдакого обиженного и опущенного, — а чё вы, — типа, — «язык» с фреймворком сравниваете… Да был бы то язык!.. :)
Рельса против Джанги — тут я пас, пару раз пытался вникнуть в концепцию джанги, но времени не хватало, а из того, что осилил, не очень глянулось, поэтому мнение моё тут более чем субъективное и не составляет предмета для спора :).
Каких возможностей не хватает PHP, по-вашему, чтобы считаться полноценным языком?
Из того, что в голову приходит, только отсутствие реальной многопоточности могу вспомнить. Отсутствие/наличие Си-подобных указателей не считаю достаточным признаком для определения является ли некая сущность языком :)
Из того, что в голову приходит, только отсутствие реальной многопоточности могу вспомнить. Отсутствие/наличие Си-подобных указателей не считаю достаточным признаком для определения является ли некая сущность языком :)
Это полноценный язык для веб-приложений. DSL. Безумно уродливый, но, таки да, полноценный. Тут дело в другом — существует ли хоть какая-то причина (относящаяся к языку, а не к проявлению воли работодателя), могущая побудить программистов, знающих кроме пхп ещё какой-нибудь язык, писать на пхп не веб приложения? Да, по большому счёту, и веб-приложения тоже :).
Ну вот я знаю ассемблер (правда забыл уже почти, но вспомню если что надеюсь быстро), С/С++, VB немного, ну и PHP :). Про веб-приложения просто — использовать эти языки на «моих» хостингах очень затруднительно, потому как шелл-доступа к ним нет, а на том который есть нет доступа к компиляторам, трансляторам, сборщикам и т. п. да и писать CMS, например, на асме для веба как-то слишком долго получится :) а готовых открытых решений не встречал :(
Ну а использование PHP в качестве скриптового языка для личных нужд — кроссплатформенность (windows/linux), бритва Оккама, да и просто лень разбираться в bash и powershell :)
Ну а использование PHP в качестве скриптового языка для личных нужд — кроссплатформенность (windows/linux), бритва Оккама, да и просто лень разбираться в bash и powershell :)
наркоман штоле?
>Ничего, кроме уеб-приложений написать на нём, по большому счёту, нельзя (я в курсе, что есть в теории можно, только кто ж это будет всерьёз делать?)
а много ли не веб приложений написано на руби, если уж на то пошло?
//не провокаций и флейма ради спрашиваю
а много ли не веб приложений написано на руби, если уж на то пошло?
//не провокаций и флейма ради спрашиваю
>а много ли не веб приложений написано на руби, если уж на то пошло?
Его большей частью как скриптовый язык используют, потому как очень просто встраивать.
Например в Google SketchUp.
Его большей частью как скриптовый язык используют, потому как очень просто встраивать.
Например в Google SketchUp.
Об этом лучше спрашивать у японцев, я думаю :)
Ну… А так, я вот, например, для производства рутинных действий, пишу небольшие скрипты на руби постоянно (в планах есть и поразвлекаться на десктопных приложениях). Делать это на пхп в голову вообще не приходило, даже когда я уже знал пхп и ещё не знал руби. Хотя, я слышал раз и о таком уникуме. Ого, даже о двух (и оба, если не ошибаюсь, тут на хабре где-то присутствуют).
Ну… А так, я вот, например, для производства рутинных действий, пишу небольшие скрипты на руби постоянно (в планах есть и поразвлекаться на десктопных приложениях). Делать это на пхп в голову вообще не приходило, даже когда я уже знал пхп и ещё не знал руби. Хотя, я слышал раз и о таком уникуме. Ого, даже о двух (и оба, если не ошибаюсь, тут на хабре где-то присутствуют).
Я делал курсовой по нейросетям.
ну тогда и рассматривать наверное надо не рор вс пхп, а, например, рор вс симфони (насколько я знаю из пхп-фреймворков симфони наиболее близок к рор идеологически, многие идеи заимствованы), где тоже есть и мвц, и куча хелперов, в том числе и для аякса, и встроенная поддержка json. и плагины к симфони есть (на оф сайте вроде под четыре сотни), да и других фреймворков полно, из наиболее именитых — зенд, кейк, кодеигнитер (кохана).
в общем, наверное, не стоит затевать холивар, тем более, что не люблю спорить о том, что не видел и не щупал :) если автор действительно потянет цикл статей для начинающих, то попробую с одной стороны разобраться в руби и рельсах в «лайв тайм», как говорится, а с другой буду сравнивать реализацию того же самого на симфони, который начал изучать недавно.
в общем, наверное, не стоит затевать холивар, тем более, что не люблю спорить о том, что не видел и не щупал :) если автор действительно потянет цикл статей для начинающих, то попробую с одной стороны разобраться в руби и рельсах в «лайв тайм», как говорится, а с другой буду сравнивать реализацию того же самого на симфони, который начал изучать недавно.
>(в особых случаях код на руби в 20 строк можно заменить кодом на пыхе размером
строк так в 150).
это вы о строках размером в несколько экранов? =)
на php тоже можно писать коротко ясно и лаконично
строк так в 150).
это вы о строках размером в несколько экранов? =)
на php тоже можно писать коротко ясно и лаконично
> чем он лучше того же PHP для разработки веб-приложений
Сам по себе язык более последовательный. Вот тем оно и лучше.
Сам по себе язык более последовательный. Вот тем оно и лучше.
Вы бы не писали про проблемы Твиттера из-за Ruby, не зная настоящего положения дел.
Я действительно не при делах твиттера :) Там такая небольшая ссылка на то, что это было мне подсказано «спецами». И, как я писал, для обучения (а это цель статеек) производительность не столь важна
>для обучения (а это цель статеек) производительность не столь важна
ну вот выучите вы язык и он вдруг в 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.
ну вот выучите вы язык и он вдруг в 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.
В php-скриптах могу чего-нить лишнее удалить, изменить, но написать что-то с чистого листа — это не ко мне. Неоднократно пытался научится мастерству создания программ, но обычно тормозил как только дело доходило до ООП
и вы действительно верите, что смена языка программирования научит вас «мастерству создания программ» (программировать)? ;)
Если интересно: habrahabr.ru/blogs/edu_2_0/48267/
В принципе я с одним человеком сейчас начал удаленно заниматься, еще осталось время на одного вполне.
В принципе я с одним человеком сейчас начал удаленно заниматься, еще осталось время на одного вполне.
<holywar enabled="false">А почему Ruby/Rails, а не более перспективный/быстрый/понятный Groovy/Grails?</holywar>
Потому что помимо CRuby есть еще и JRuby:)
и что?
В Groovy по сути больших отличий от Ruby нет, все таки ведь клон. Основная его фишка — это доступ к великой и могучей Java платформе.
А так как и Ruby, посредством JRuby, может использовать мощь Java платформы, то смысла в его клоне я не вижу. Естественно это субъективно, тут кому что нравиться:)
А так как и Ruby, посредством JRuby, может использовать мощь Java платформы, то смысла в его клоне я не вижу. Естественно это субъективно, тут кому что нравиться:)
К тому же в Ruby есть опция — таскать за собой Java платформу или нет, она ведь не всегда нужна.
А в Groovy нет:)
А в Groovy нет:)
Кхм… Не хочется развенчивать ваши предубеждения, но Groovy на столько же «клон» Ruby, на сколько он «клон» Java & Python. Тот же Ruby 1.9 заимствует некоторые фишки, которые есть в Groovy.
Интеграция с Java у Groovy на порядок выше.
Интеграция с Java у Groovy на порядок выше.
Ну клон Java, это вы конечно загнули, джава ниразу не динамическая. Просто большинство идей Groovy перенял именно от Ruby, например блоки, итераторы на них построенные, простое создание DSL. Даже не идеи(блоки например ведь не в руби впервые появились), а саму их реализацию.
>Интеграция с Java у Groovy на порядок выше.
В чем это выражается?
>Тот же Ruby 1.9 заимствует некоторые фишки, которые есть в Groovy.
Какие?(Правда очень интересно)
>Интеграция с Java у Groovy на порядок выше.
В чем это выражается?
>Тот же Ruby 1.9 заимствует некоторые фишки, которые есть в Groovy.
Какие?(Правда очень интересно)
>саму их реализацию.
это как? скопировал исходники что ли? 0_О
>В чем это выражается?
валидный java-код=валидный groovy-код (с минимальными ограничениями), как пример того, что groovy — это «почти» java
это как? скопировал исходники что ли? 0_О
>В чем это выражается?
валидный java-код=валидный groovy-код (с минимальными ограничениями), как пример того, что groovy — это «почти» java
>это как? скопировал исходники что ли? 0_О
Нет конечно. Я про то что синтаксически например блоки и итераторы на Ruby и Groovy практически идентичны.
>java-код=валидный groovy-код
В чем плюс для интеграции? То что мы можем использовать Java код в Groovy интерпретаторе не компилируя в байткод?
Нет конечно. Я про то что синтаксически например блоки и итераторы на Ruby и Groovy практически идентичны.
>java-код=валидный groovy-код
В чем плюс для интеграции? То что мы можем использовать Java код в Groovy интерпретаторе не компилируя в байткод?
>Нет конечно. Я про то что синтаксически например блоки и итераторы на Ruby и Groovy практически идентичны.
синтаксически практически groovy идентичен в первую очередь java, и лишь потом отсутствующие в java вещи, да и такого понятия как блоки/итераторы я что-то не припоминаю, там есть только closures.
>В чем плюс для интеграции? То что мы можем использовать Java код в Groovy интерпретаторе не компилируя в байткод?
использование java-классов/методов в groovy и наоборот. опять же простота миграции и бОльшая понятность кода.
синтаксически практически groovy идентичен в первую очередь java, и лишь потом отсутствующие в java вещи, да и такого понятия как блоки/итераторы я что-то не припоминаю, там есть только closures.
>В чем плюс для интеграции? То что мы можем использовать Java код в Groovy интерпретаторе не компилируя в байткод?
использование java-классов/методов в groovy и наоборот. опять же простота миграции и бОльшая понятность кода.
closures в Groovy и блоки в Ruby это одно и тоже.
а под итератором я имел ввиду функции типо Array.each, которым в качестве параметра передается блок.
>бОльшая понятность кода.
Всмысле для Java программиста?
а под итератором я имел ввиду функции типо Array.each, которым в качестве параметра передается блок.
>бОльшая понятность кода.
Всмысле для Java программиста?
>да и такого понятия как блоки/итераторы я что-то не припоминаю, там есть только closures.
Итераторы есть, конечно, они даже в яве есть :), а замыкания функцию блоков как раз и выполняют (это ж они и есть, просто терминология отличается).
Из айбиэмовского туториала…
Итераторы:
str = «uncle man, uncle man»
for (ch in str){
println ch
}
Блоки:
[2, 4, 6, 8, 3].find { x |
if (x == 3){
println x
}
}
Итераторы есть, конечно, они даже в яве есть :), а замыкания функцию блоков как раз и выполняют (это ж они и есть, просто терминология отличается).
Из айбиэмовского туториала…
Итераторы:
str = «uncle man, uncle man»
for (ch in str){
println ch
}
Блоки:
[2, 4, 6, 8, 3].find { x |
if (x == 3){
println x
}
}
> Ну клон 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 всё равно короче ;), ещё что-то было, не помню уже.
При чём здесь «динамика»?
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 всё равно короче ;), ещё что-то было, не помню уже.
Вобщем большая часть отличий — именно синтаксические, для тех же самых фич.
Только вот про Symbols не понял, это аналог :asdf или что то другое?
Кстати, а чем вам unless не нравиться?:)
А насчет Java-код = валидный Groovy-код
Практическое применение этому есть? Или только как облегчение перехода Java программистов.
Только вот про Symbols не понял, это аналог :asdf или что то другое?
Кстати, а чем вам unless не нравиться?:)
А насчет Java-код = валидный Groovy-код
Практическое применение этому есть? Или только как облегчение перехода Java программистов.
> Вобщем большая часть отличий — именно синтаксические, для тех же самых фич.
Что касается пунктов из 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(которому я душу продал) я бы сравнивать не пытался.
Что касается пунктов из 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(которому я душу продал) я бы сравнивать не пытался.
>Хотя вот меня лично(Java-guy) Groovy на себя не перетянул
везёт вам, я вот уже втянулся…
для человека, который хорошо знает Spring/Wicket/etc grails действительно не так привлекает, но вот если его(человека) сначала хорошенько напугать Spring+Hibernate+..., то от Grails он будет в восторге. Собственно, ровно таким же образом к себе и rails привлекали.
везёт вам, я вот уже втянулся…
для человека, который хорошо знает Spring/Wicket/etc grails действительно не так привлекает, но вот если его(человека) сначала хорошенько напугать Spring+Hibernate+..., то от Grails он будет в восторге. Собственно, ровно таким же образом к себе и rails привлекали.
Про (1-3) понятно, это больше про JRuby чем CRuby.
>2. Проще портировать в обратном направлении для улучшения производительности
Там же один и тот же байткод. Или груви компилятор менее оптимизированный?
>Я бы не называл Groovy в качестве конкурента Ruby.
Я бы даже сказал что для людей из империи Java Ruby бессмылен, и точно так же Groovy, для тех кто не на Java:)
Хотя, когда Rails набирал популярность, очень много именно Java программеров перешли на Ruby.
>2. Проще портировать в обратном направлении для улучшения производительности
Там же один и тот же байткод. Или груви компилятор менее оптимизированный?
>Я бы не называл Groovy в качестве конкурента Ruby.
Я бы даже сказал что для людей из империи Java Ruby бессмылен, и точно так же Groovy, для тех кто не на Java:)
Хотя, когда Rails набирал популярность, очень много именно Java программеров перешли на Ruby.
> Там же один и тот же байткод. Или груви компилятор менее оптимизированный?
Разный. Объяснять долго) Можете разок javap'нуть если интересно. Заодно глянуть как работает Joint Compiler: к примеру static type checking в Groovy работает только в run-time, а не в compile-time в отличие от Scala/Java. Производительности оно не добавляет, а наоборот — лишняя проверка.
> Я бы даже сказал что для людей из империи Java Ruby бессмылен, и точно так же Groovy, для тех кто не на Java:)
Да.
> Хотя, когда Rails набирал популярность, очень много именно Java программеров перешли на Ruby.
Статистики у меня нет, но если кто и перелезал — то и Java им толком была не нужна. Мы, к примеру используем кучу библиотек, которых в Ruby-мире нет, да и деплойменту Java равных пока мало. В остальном, если вы Java используете только для магазина на Struts 1, то действительно надо что-то менять.
Разный. Объяснять долго) Можете разок javap'нуть если интересно. Заодно глянуть как работает Joint Compiler: к примеру static type checking в Groovy работает только в run-time, а не в compile-time в отличие от Scala/Java. Производительности оно не добавляет, а наоборот — лишняя проверка.
> Я бы даже сказал что для людей из империи Java Ruby бессмылен, и точно так же Groovy, для тех кто не на Java:)
Да.
> Хотя, когда Rails набирал популярность, очень много именно Java программеров перешли на Ruby.
Статистики у меня нет, но если кто и перелезал — то и Java им толком была не нужна. Мы, к примеру используем кучу библиотек, которых в Ruby-мире нет, да и деплойменту Java равных пока мало. В остальном, если вы Java используете только для магазина на Struts 1, то действительно надо что-то менять.
>Там же один и тот же байткод. Или груви компилятор менее оптимизированный?
груви рантайм более медленный ввиду динамической типизации
>и точно так же Groovy, для тех кто не на Java:)
не факт, не факт
груви рантайм более медленный ввиду динамической типизации
>и точно так же Groovy, для тех кто не на Java:)
не факт, не факт
вот вы сами хоть раз пользовались JRuby и Groovy или же просто пытаетесь выдать желаемое за действительное?
JRuby достаточно много использовал и использую. Groovy смотрел с целью поиграться. Реальных проектов на нем не делал.
>пытаетесь выдать желаемое за действительное?
Поясните, пожалуйста, что я такого нереального сказал?
>пытаетесь выдать желаемое за действительное?
Поясните, пожалуйста, что я такого нереального сказал?
>JRuby достаточно много использовал и использую.
неужели всё сразу и всё заработало при переходе CRuby->JRuby?
что именно вы используете из «мощи java-платформы» кроме app-серверов?
>Поясните, пожалуйста, что я такого нереального сказал?
см. habrahabr.ru/blogs/ruby/48559/#comment_1261491
неужели всё сразу и всё заработало при переходе CRuby->JRuby?
что именно вы используете из «мощи java-платформы» кроме app-серверов?
>Поясните, пожалуйста, что я такого нереального сказал?
см. habrahabr.ru/blogs/ruby/48559/#comment_1261491
Я могу понять, что это трудно, но попытайтесь принять тот факт, что не всем людям нравится Java и все то, что с ней связано. Для этих людей Groovy/Grails не вариант.
не всем людям нравится программирование и всё то, что с ним связано, и что?
поймите, несмотря на весь хайп который пытаются поднимать вокруг руби заинтересованные люди, сама руби-платформа сейчас находится на спаде и предпосылок к подъёму я не вижу.
я ж ведь не зря написал именно «перспективный/быстрый/понятный»
поймите, несмотря на весь хайп который пытаются поднимать вокруг руби заинтересованные люди, сама руби-платформа сейчас находится на спаде и предпосылок к подъёму я не вижу.
я ж ведь не зря написал именно «перспективный/быстрый/понятный»
на спаде? серьезно? теже самые рельсы только сейчас стали более менее распространены и распространяются сейчас потихоньку все больше и больше… вы можете доказать этот самый спад?
>не всем людям нравится программирование и всё то, что с ним связано, и что?
Не программирование и все что с ним связано, а Java и все что с ней связано. Поэтому люди могут предпочитать другие языки и платформы.
>поймите, несмотря на весь хайп который пытаются поднимать вокруг руби заинтересованные люди, сама руби-платформа сейчас находится на спаде и предпосылок к подъёму я не вижу.
Хайпа нет. Никто никого не тянет в руби/рельсовое коммьнити. Никто не уговаривает начинать использовать этот язык. Если вы сами начинаете копать и разбираться и задаете (умные) вопросы то вам помогут. Силой вас никто тянуть не будет. Нравится Java — ваше право выбирать инструменты себе по вкусу.
Спад мне тоже как-то не сильно виден. Язык развивается. Постоянно создаются новые библиотеки. Регулярно появляются заказчики. Количество программистов за последний год сильно увеличилось. Создаются разнообразные средства разработки. Решаются проблемы с хостингом даже на мало кому нужных shared-аккаунтах.
>я ж ведь не зря написал именно «перспективный/быстрый/понятный»
Это ваше субъективное мнение. Мое — опять же субъективное — мнение по поводу вашего мнения :) такое: неизвестно/неизмеряемо/субъективно
Не программирование и все что с ним связано, а Java и все что с ней связано. Поэтому люди могут предпочитать другие языки и платформы.
>поймите, несмотря на весь хайп который пытаются поднимать вокруг руби заинтересованные люди, сама руби-платформа сейчас находится на спаде и предпосылок к подъёму я не вижу.
Хайпа нет. Никто никого не тянет в руби/рельсовое коммьнити. Никто не уговаривает начинать использовать этот язык. Если вы сами начинаете копать и разбираться и задаете (умные) вопросы то вам помогут. Силой вас никто тянуть не будет. Нравится Java — ваше право выбирать инструменты себе по вкусу.
Спад мне тоже как-то не сильно виден. Язык развивается. Постоянно создаются новые библиотеки. Регулярно появляются заказчики. Количество программистов за последний год сильно увеличилось. Создаются разнообразные средства разработки. Решаются проблемы с хостингом даже на мало кому нужных shared-аккаунтах.
>я ж ведь не зря написал именно «перспективный/быстрый/понятный»
Это ваше субъективное мнение. Мое — опять же субъективное — мнение по поводу вашего мнения :) такое: неизвестно/неизмеряемо/субъективно
>Язык развивается.
угу. а сколько времени прошло между 1.8.6 и 1.8.7, не напомните?
угу. а сколько времени прошло между 1.8.6 и 1.8.7, не напомните?
Не путайте. Ветка 1.8 не развиваеся, в ней только багфиксы(раз так долго 1.8.7 небыло, значит мало багов?:))
Основной упор сейчас на эксперементальную 1.9. Там кстати уже и виртуальная машина появилась, так что скоро руби ускориться:)
На 1.9 происходит обкатка идей, которые потом войдут в новый стабильный релиз 2.0
А 1.9 очень даже хорошо развивается.
Основной упор сейчас на эксперементальную 1.9. Там кстати уже и виртуальная машина появилась, так что скоро руби ускориться:)
На 1.9 происходит обкатка идей, которые потом войдут в новый стабильный релиз 2.0
А 1.9 очень даже хорошо развивается.
>Не путайте. Ветка 1.8 не развиваеся, в ней только багфиксы(раз так долго 1.8.7 небыло, значит мало багов?:))
Основной упор сейчас на эксперементальную 1.9.
окей. сколько лет уже пишут тестовую(!!!) ветку 1.9 и через сколько лет будет «стабильная» 2.0 (считая точкой отсчёта 1.8.0)?
>Там кстати уже и виртуальная машина появилась, так что скоро руби ускориться:)
ага, догонит JRuby ;)
Основной упор сейчас на эксперементальную 1.9.
окей. сколько лет уже пишут тестовую(!!!) ветку 1.9 и через сколько лет будет «стабильная» 2.0 (считая точкой отсчёта 1.8.0)?
>Там кстати уже и виртуальная машина появилась, так что скоро руби ускориться:)
ага, догонит JRuby ;)
М-м-м-м. Видимо, груви — на подъёме? Вы вправду в это верите? :)
Что касается «не зря» — перспективный, — ну да, новый и никому, по-большому счёту, не известный, поэтому новые пользователи непременно будут появляться, поэтому да, «перспективный». Быстрый? JRuby/JPython-ы сильно медленнее? В силу одного только их наличия, смысл груви совершенно неясен — ни рубисты, ни питонисты на груви ни с того ни с сего переходить не станут, а их ведь много (особенно питонистов). Явщики? Ну да, этих сильно много. Только бросят ли они яву в пользу динамического языка, даже если он слегка по синтаксису на яву и похож? Трудность перехода тут отнюдь не в синтаксисе. Понятный? Ну-у-у. Он, всё-таки, достаточно непохож на яву, чтобы разница в «понятности» (привычности синтаксиса?) была не так чтобы уж и велика.
Может я и неправ, но взявши было в руки книжку по груви, сейчас пока что передумал — при наличии руби и питона для меня изучение груви сильно сомнительно.
Что касается «не зря» — перспективный, — ну да, новый и никому, по-большому счёту, не известный, поэтому новые пользователи непременно будут появляться, поэтому да, «перспективный». Быстрый? JRuby/JPython-ы сильно медленнее? В силу одного только их наличия, смысл груви совершенно неясен — ни рубисты, ни питонисты на груви ни с того ни с сего переходить не станут, а их ведь много (особенно питонистов). Явщики? Ну да, этих сильно много. Только бросят ли они яву в пользу динамического языка, даже если он слегка по синтаксису на яву и похож? Трудность перехода тут отнюдь не в синтаксисе. Понятный? Ну-у-у. Он, всё-таки, достаточно непохож на яву, чтобы разница в «понятности» (привычности синтаксиса?) была не так чтобы уж и велика.
Может я и неправ, но взявши было в руки книжку по груви, сейчас пока что передумал — при наличии руби и питона для меня изучение груви сильно сомнительно.
>М-м-м-м. Видимо, груви — на подъёме? Вы вправду в это верите? :)
>Что касается «не зря» — перспективный, — ну да, новый и никому, по-большому счёту, не известный, поэтому новые пользователи непременно будут появляться, поэтому да, «перспективный».
покупка G2One'а SpringSource'ом вас убеждает в обратном? 0_О
более того, см. glaforge.free.fr/weblog/index.php?itemid=227 — статью годичной давности
>JRuby/JPython-ы сильно медленнее?
JPython очень сильно отстаёт от самого питона в развитии. JRuby по скорости почти сравним, но JRuby!=Ruby
>Он, всё-таки, достаточно непохож на яву, чтобы разница в «понятности» (привычности синтаксиса?) была не так чтобы уж и велика.
при постепенном переходе разницы в синтаксисе и работоспособности практически не будет.
>ни рубисты, ни питонисты
а почему переходить должны именно они? и почему именно переходить?
>Что касается «не зря» — перспективный, — ну да, новый и никому, по-большому счёту, не известный, поэтому новые пользователи непременно будут появляться, поэтому да, «перспективный».
покупка G2One'а SpringSource'ом вас убеждает в обратном? 0_О
более того, см. glaforge.free.fr/weblog/index.php?itemid=227 — статью годичной давности
>JRuby/JPython-ы сильно медленнее?
JPython очень сильно отстаёт от самого питона в развитии. JRuby по скорости почти сравним, но JRuby!=Ruby
>Он, всё-таки, достаточно непохож на яву, чтобы разница в «понятности» (привычности синтаксиса?) была не так чтобы уж и велика.
при постепенном переходе разницы в синтаксисе и работоспособности практически не будет.
>ни рубисты, ни питонисты
а почему переходить должны именно они? и почему именно переходить?
>при постепенном переходе разницы в синтаксисе и работоспособности практически не будет.
Ой. Мне так не показалось. Но это, конечно, сугубо личное мнение.
>>ни рубисты, ни питонисты
>а почему переходить должны именно они? и почему именно переходить?
А кто? Неужели пхп-шники? :)
Я догадываюсь, что имеются в виду явщики, но… матёрые явщики… на динамический язык… Как массовое явление — с большим трудом себе такое могу представить. Скорее даже не могу :).
Не, ну я всё понимаю, конечно и совсем не против груви (а кто бы меня спрашивал? :) ), просто вот эти «перспективный/быстрый/понятный» пока что большие сомнения вызывают у меня. Если сравнивать с уже имеющимися на рынке руби и, особенно, питоном.
Ой. Мне так не показалось. Но это, конечно, сугубо личное мнение.
>>ни рубисты, ни питонисты
>а почему переходить должны именно они? и почему именно переходить?
А кто? Неужели пхп-шники? :)
Я догадываюсь, что имеются в виду явщики, но… матёрые явщики… на динамический язык… Как массовое явление — с большим трудом себе такое могу представить. Скорее даже не могу :).
Не, ну я всё понимаю, конечно и совсем не против груви (а кто бы меня спрашивал? :) ), просто вот эти «перспективный/быстрый/понятный» пока что большие сомнения вызывают у меня. Если сравнивать с уже имеющимися на рынке руби и, особенно, питоном.
>Ой. Мне так не показалось. Но это, конечно, сугубо личное мнение.
учитывая то, что java-код превращается в groovy-код преобразованием внутренних классов и чуть изменённым синтаксисом для массивов — то вам действительно показалось. Впрочем, я не в курсе, насколько хорошо вы знаете java/groovy
>Если сравнивать с уже имеющимися на рынке руби и, особенно, питоном.
вся принципиальная разница в данном случае в том что руби/питон — это полный переход, а Groovy — это «плавная миграция»
учитывая то, что java-код превращается в groovy-код преобразованием внутренних классов и чуть изменённым синтаксисом для массивов — то вам действительно показалось. Впрочем, я не в курсе, насколько хорошо вы знаете java/groovy
>Если сравнивать с уже имеющимися на рынке руби и, особенно, питоном.
вся принципиальная разница в данном случае в том что руби/питон — это полный переход, а Groovy — это «плавная миграция»
>сама руби-платформа сейчас находится на спаде
Нда, это еще вопрос, кто из нас с вами желаемое за действительное выдать пытается:)
Похоже вы убежденный фанат Groovy(или антифанат Ruby):)
Нда, это еще вопрос, кто из нас с вами желаемое за действительное выдать пытается:)
Похоже вы убежденный фанат Groovy(или антифанат Ruby):)
а это, например, тоже не аргумент:
«So, it’s with great sadness that I agree with several recent Rubyist’s blog posts and say that Ruby is in a very bad place right now. It’s no longer cutting edge, it’s technically stagnant, is in implementation limbo, and just isn’t… well… fun, anymore.»
Первая мысль истинного рубиста — проплаченная статья!:)
С аргументами не в пользу рибивского интерпретатора я согласен. Идеальных инструментов к сожалению не бывает.
Но над исправлением этого и работают в версии 1.9. И не все с ним так мрачно как показанно в статье.
Ну вот, вы указали на минусы интерпретатора СRuby, ну а теперь, Groovy то чем лучше?
Не хотите CRuby используйте JRuby, там нет таких проблем.
А «and just isn’t… well… fun, anymore» — это уже личное мнение, и к вопросу плох руби или хорош большого отношения не имеет:)
Вобщем статья честно говоря напоминает какое-то унылое нытье что руби это уже никруто, притом совсем без аргументации.
С аргументами не в пользу рибивского интерпретатора я согласен. Идеальных инструментов к сожалению не бывает.
Но над исправлением этого и работают в версии 1.9. И не все с ним так мрачно как показанно в статье.
Ну вот, вы указали на минусы интерпретатора СRuby, ну а теперь, Groovy то чем лучше?
Не хотите CRuby используйте JRuby, там нет таких проблем.
А «and just isn’t… well… fun, anymore» — это уже личное мнение, и к вопросу плох руби или хорош большого отношения не имеет:)
Вобщем статья честно говоря напоминает какое-то унылое нытье что руби это уже никруто, притом совсем без аргументации.
>Первая мысль истинного рубиста — проплаченная статья!:)
кем? кому это нужно-то?
>Но над исправлением этого и работают в версии 1.9.
Дык про это я в статье прочитал. Как и про то, что 1.9 не предназначена для продакшена.
>Не хотите CRuby используйте JRuby
так вот сразу возникает вопрос — а нафига сначала мучаться с самим CRuby, потом переходить(наверняка не без проблем) на JRuby вместо того чтобы сразу использовать Groovy?
>Groovy то чем лучше?
java-платформой, энтерпрайз-поддержкой
>Вобщем статья честно говоря напоминает какое-то унылое нытье что руби это уже никруто, притом совсем без аргументации.
а многолетние серьёзные проблемы с CRuby без надежды на скорое исправление — это разве не аргументация? Ну или приведённый выше мною вопрос(который вытекает из поста) про развитие языка?
кем? кому это нужно-то?
>Но над исправлением этого и работают в версии 1.9.
Дык про это я в статье прочитал. Как и про то, что 1.9 не предназначена для продакшена.
>Не хотите CRuby используйте JRuby
так вот сразу возникает вопрос — а нафига сначала мучаться с самим CRuby, потом переходить(наверняка не без проблем) на JRuby вместо того чтобы сразу использовать Groovy?
>Groovy то чем лучше?
java-платформой, энтерпрайз-поддержкой
>Вобщем статья честно говоря напоминает какое-то унылое нытье что руби это уже никруто, притом совсем без аргументации.
а многолетние серьёзные проблемы с CRuby без надежды на скорое исправление — это разве не аргументация? Ну или приведённый выше мною вопрос(который вытекает из поста) про развитие языка?
>1.9 не предназначена для продакшена.
Естественно, это эксперементальная ветка.
Я и не говорю что нужно с CRuby на JRuby переходить, это если не устраивает скорость например. Скорость обычно основной аргумент не в пользу руби. Но это и не его задача.
Просто как я уже писал, Java платформа не во всех задачах нужна, например я пускаю Java приложение (будь то просто Java, Groovy или JRuby), на своем маленьком VDS с 256м памяти, и JVM половину(если не больше) этой памяти откушивает, а CRuby — 2-5м на ту же функциональность.
А если я пишу на Groovy, никуда я от JVM не денуся.
Enterprise только в больших задачах(я бы сказал даже в очень большиз) нужен.
Про серьезные проблеммы там не сказанно(опять же кроме скорости).
А если нашли bottleneck то можно написать для этого сишное расширение, или с помощью inline-ruby прямо сишный код в теле метода.
Кстати это еще один плюс руби, сишные расширение пишутся очень просто.
К томуже в конце статьи автор смотрит в сторону Sсheme, правда я бегло просматривал, может не так понял, но может у него вообще неудовлетворенность императивными языками а не руби в частности?:)
Развитие языка сейчас идет следующим образом, эксперементальная ветка 1.9, которая впоследствие станет стабильным релизом 2.0, затем JRuby, и виртуальная машина Rubinius.
Но с Rubinius и вправду сейчас глухо, там в связи с кризисом половину разработчиков поуволняли.
Естественно, это эксперементальная ветка.
Я и не говорю что нужно с CRuby на JRuby переходить, это если не устраивает скорость например. Скорость обычно основной аргумент не в пользу руби. Но это и не его задача.
Просто как я уже писал, Java платформа не во всех задачах нужна, например я пускаю Java приложение (будь то просто Java, Groovy или JRuby), на своем маленьком VDS с 256м памяти, и JVM половину(если не больше) этой памяти откушивает, а CRuby — 2-5м на ту же функциональность.
А если я пишу на Groovy, никуда я от JVM не денуся.
Enterprise только в больших задачах(я бы сказал даже в очень большиз) нужен.
Про серьезные проблеммы там не сказанно(опять же кроме скорости).
А если нашли bottleneck то можно написать для этого сишное расширение, или с помощью inline-ruby прямо сишный код в теле метода.
Кстати это еще один плюс руби, сишные расширение пишутся очень просто.
К томуже в конце статьи автор смотрит в сторону Sсheme, правда я бегло просматривал, может не так понял, но может у него вообще неудовлетворенность императивными языками а не руби в частности?:)
Развитие языка сейчас идет следующим образом, эксперементальная ветка 1.9, которая впоследствие станет стабильным релизом 2.0, затем JRuby, и виртуальная машина Rubinius.
Но с Rubinius и вправду сейчас глухо, там в связи с кризисом половину разработчиков поуволняли.
>1.9 не предназначена для продакшена.
итого «юзабельного» развития языка нету и не скоро будет — есть лишь багфиксы и бэкпорты из 1.9.
>Скорость обычно основной аргумент не в пользу руби.
это всего первый аргумент. второй — это проблемы с «хостингом» — сколько там уже апсерверов понаписали, явно ж ведь не от хорошей жизни. Или давайте вспомним библиотеки под ruby, драйвера к бд итд.
>на своем маленьком VDS с 256м памяти, и JVM половину(если не больше) этой памяти откушивает, а CRuby — 2-5м на ту же функциональность.
да ну? запустил «пустое» groovy-приложение под маком — съело 28 мегабайт, запустил под виндой — 19 мегабайт. может лучше кластер монгрелов с одним томкатом/jetty сравним?
>Про серьезные проблеммы там не сказанно(опять же кроме скорости).
скорость «doesn't matter»((с) 37_signals) если она (скорость есть). Когда руби — _самый медленный_ из всего списка — это уже заставляет серьёзно задуматься.
>А если нашли bottleneck то можно написать для этого сишное расширение, или с помощью inline-ruby прямо сишный код в теле метода.
>Кстати это еще один плюс руби, сишные расширение пишутся очень просто.
относительно java/groovy плюс это с большой натяжкой, скорее минус.
итого «юзабельного» развития языка нету и не скоро будет — есть лишь багфиксы и бэкпорты из 1.9.
>Скорость обычно основной аргумент не в пользу руби.
это всего первый аргумент. второй — это проблемы с «хостингом» — сколько там уже апсерверов понаписали, явно ж ведь не от хорошей жизни. Или давайте вспомним библиотеки под ruby, драйвера к бд итд.
>на своем маленьком VDS с 256м памяти, и JVM половину(если не больше) этой памяти откушивает, а CRuby — 2-5м на ту же функциональность.
да ну? запустил «пустое» groovy-приложение под маком — съело 28 мегабайт, запустил под виндой — 19 мегабайт. может лучше кластер монгрелов с одним томкатом/jetty сравним?
>Про серьезные проблеммы там не сказанно(опять же кроме скорости).
скорость «doesn't matter»((с) 37_signals) если она (скорость есть). Когда руби — _самый медленный_ из всего списка — это уже заставляет серьёзно задуматься.
>А если нашли bottleneck то можно написать для этого сишное расширение, или с помощью inline-ruby прямо сишный код в теле метода.
>Кстати это еще один плюс руби, сишные расширение пишутся очень просто.
относительно java/groovy плюс это с большой натяжкой, скорее минус.
>итого «юзабельного» развития языка нету
не понял как вы пришли к такому выводу:)
>второй — это проблемы с «хостингом»
Разве есть такая проблема? Всмысле с шаред хостингом? Покажите мне шаред хостинг для Groovy:) У Groovy гораздо больше проблем с этим:)
>Или давайте вспомним библиотеки под ruby, драйвера к бд итд.
С какими драйверами и библиотекаи там проблимы?
Это кстати еще один плюс руби, что все библиотеки лежат в репозитарии, и устанавливаются автоматический пакедж менеджером. Нужен драйвер для mysql? Пожалуйста:
gem install mysql
И у нас после этой простой комманды появился драйвер для myql:)
А в Groovy?
>съело 28 мегабайт
Ага, пустое приложение, а на CRuby 4м уже работающее.
>относительно java/groovy плюс это с большой натяжкой, скорее минус
Почему? Только не надо ссылаться на бенчмарки типо «Java 2 times Faster then C++»:)
не понял как вы пришли к такому выводу:)
>второй — это проблемы с «хостингом»
Разве есть такая проблема? Всмысле с шаред хостингом? Покажите мне шаред хостинг для Groovy:) У Groovy гораздо больше проблем с этим:)
>Или давайте вспомним библиотеки под ruby, драйвера к бд итд.
С какими драйверами и библиотекаи там проблимы?
Это кстати еще один плюс руби, что все библиотеки лежат в репозитарии, и устанавливаются автоматический пакедж менеджером. Нужен драйвер для mysql? Пожалуйста:
gem install mysql
И у нас после этой простой комманды появился драйвер для myql:)
А в Groovy?
>съело 28 мегабайт
Ага, пустое приложение, а на CRuby 4м уже работающее.
>относительно java/groovy плюс это с большой натяжкой, скорее минус
Почему? Только не надо ссылаться на бенчмарки типо «Java 2 times Faster then C++»:)
>не понял как вы пришли к такому выводу:)
1) stable 1.8.0 вышел 5 года назад (примерно)
2) latest stable (1.8.7) вышел полгода назад (примерно)
3) итого прошло уже 5(!!!) лет, а major новой версии не вышло.
с каким из этих пунктов вы не согласны?
>Разве есть такая проблема?
«хостинг» был взят в кавычки не случайно — это я намекаю на всякие монгрелы итд.
>С какими драйверами и библиотекаи там проблимы?
а вас не смущает, что бинарный драйвер mysql нужно компилять, а «нативный» — весьма тормозной? Ну это не считая того, что драйвер пишется всего одним человеком, насколько я знаю…
Да и вообще просто глупо спорить, что библиотеки у java лучше и их больше.
>А в Groovy?
maven/grape
>Ага, пустое приложение, а на CRuby 4м уже работающее.
работающее — (28/19)+4 в худшем случае. хотите провести бенчмарк?
>Почему? Только не надо ссылаться на бенчмарки типо «Java 2 times Faster then C++»:)
байткод куда удобнее/безопаснее нативного кода
1) stable 1.8.0 вышел 5 года назад (примерно)
2) latest stable (1.8.7) вышел полгода назад (примерно)
3) итого прошло уже 5(!!!) лет, а major новой версии не вышло.
с каким из этих пунктов вы не согласны?
>Разве есть такая проблема?
«хостинг» был взят в кавычки не случайно — это я намекаю на всякие монгрелы итд.
>С какими драйверами и библиотекаи там проблимы?
а вас не смущает, что бинарный драйвер mysql нужно компилять, а «нативный» — весьма тормозной? Ну это не считая того, что драйвер пишется всего одним человеком, насколько я знаю…
Да и вообще просто глупо спорить, что библиотеки у java лучше и их больше.
>А в Groovy?
maven/grape
>Ага, пустое приложение, а на CRuby 4м уже работающее.
работающее — (28/19)+4 в худшем случае. хотите провести бенчмарк?
>Почему? Только не надо ссылаться на бенчмарки типо «Java 2 times Faster then C++»:)
байткод куда удобнее/безопаснее нативного кода
Все равно не понял:) Зачем каждые полгода выпускать изменения для языка?
Наоборот, один раз хорошо продумали синтаксис, а дальше изменения на уровне сторонних библиотек и фреймворков.
Вон у си самый используемый стандарт C99, по вашей логике си отстой?:)
А что не так с монгрелом?
Если я делаю маленький сайтик, то я пускаю рельсы через fcgi под lighttpd например.
А если это высоконагруженная система — то кластер монгрелов, в чем тут проблема?
Меня должно смущять что драйвер частично написан на си? Почему?
>Да и вообще просто глупо спорить, что библиотеки у java лучше и их больше.
Ага? прямо так все больше и лучше?:) А конкретные примеры?
Мавен, это не репозитарий библиотек, а тулза для сборки приложений если я не ошибаюсь конечно.
Покажите например как вы jdom например поставите с помощью мавена?
Проведите, интересно будет посмотреть:) Но как не крути, этот оверхэд всеравно остается. Что для небольших проектов совсем не хорошо.
>куда удобнее/безопаснее нативного кода
Какое-то странное заявление, только если тем что сломать чтонибудь нативным кодом проще? Ну дак можно извернуться и через JNI также сделать:)
Наоборот, один раз хорошо продумали синтаксис, а дальше изменения на уровне сторонних библиотек и фреймворков.
Вон у си самый используемый стандарт C99, по вашей логике си отстой?:)
А что не так с монгрелом?
Если я делаю маленький сайтик, то я пускаю рельсы через fcgi под lighttpd например.
А если это высоконагруженная система — то кластер монгрелов, в чем тут проблема?
Меня должно смущять что драйвер частично написан на си? Почему?
>Да и вообще просто глупо спорить, что библиотеки у java лучше и их больше.
Ага? прямо так все больше и лучше?:) А конкретные примеры?
Мавен, это не репозитарий библиотек, а тулза для сборки приложений если я не ошибаюсь конечно.
Покажите например как вы jdom например поставите с помощью мавена?
Проведите, интересно будет посмотреть:) Но как не крути, этот оверхэд всеравно остается. Что для небольших проектов совсем не хорошо.
>куда удобнее/безопаснее нативного кода
Какое-то странное заявление, только если тем что сломать чтонибудь нативным кодом проще? Ну дак можно извернуться и через JNI также сделать:)
>Зачем каждые полгода выпускать изменения для языка?
а где вы увидели полгода? пять лет уже прошло, и ещё пять, видимо, пройдёт… Об этом, кстати, тоже речь идёт в статье — о том, что крупным полезных изменений в руби маловато.
>Ага? прямо так все больше и лучше?:) А конкретные примеры?
возможно, если хорошо-хорошо поискать, то найдётся пяток либ на руби, которые лучше java-аналогов.
>Мавен, это не репозитарий библиотек, а тулза для сборки приложений если я не ошибаюсь конечно.
не только. у мавена также есть зеркала с либами (+их сорцами и доками)
>Какое-то странное заявление, только если тем что сломать чтонибудь нативным кодом проще? Ну дак можно извернуться и через JNI также сделать:)
нуну, особенно учитывая шаред хостинг.
>Проведите, интересно будет посмотреть:) Но как не крути, этот оверхэд всеравно остается.
только для совсем маленьких приложений
а где вы увидели полгода? пять лет уже прошло, и ещё пять, видимо, пройдёт… Об этом, кстати, тоже речь идёт в статье — о том, что крупным полезных изменений в руби маловато.
>Ага? прямо так все больше и лучше?:) А конкретные примеры?
возможно, если хорошо-хорошо поискать, то найдётся пяток либ на руби, которые лучше java-аналогов.
>Мавен, это не репозитарий библиотек, а тулза для сборки приложений если я не ошибаюсь конечно.
не только. у мавена также есть зеркала с либами (+их сорцами и доками)
>Какое-то странное заявление, только если тем что сломать чтонибудь нативным кодом проще? Ну дак можно извернуться и через JNI также сделать:)
нуну, особенно учитывая шаред хостинг.
>Проведите, интересно будет посмотреть:) Но как не крути, этот оверхэд всеравно остается.
только для совсем маленьких приложений
ну опять 25, ну как вы не можете понять что не всем нравится java и ее платформа…
не считая 15-30 мегабайт оверхеда java-платформа куда лучше ruby.
чем, чем она лучше? или чем она лучше бесплатформенного (вернее нативного) си? или чем она лучше используемого мною Qt?
лично для меня ничем… для меня ява это неудобный монстр с претензией на общее применение, но без возможности спокойно работать одновременно и в низком и в высоком уровнях (что дает си или си с Qt).
А руби для меня лучше чем ява своим сахаром.
лично для меня ничем… для меня ява это неудобный монстр с претензией на общее применение, но без возможности спокойно работать одновременно и в низком и в высоком уровнях (что дает си или си с Qt).
А руби для меня лучше чем ява своим сахаром.
UFO just landed and posted this here
Лучше начать руби не с рельсов а именно с руби, так сказать с чистого руби:)
Потому как за однотипными действиями в рельсовых контролерах всей прелести руби и не поймешь.
Можно конечно повосхищаться эктиврекордским DSL'ом для создания таблиц, или же его хитрыми методами find_all_by_name и тд.
Но куда лучше делать такое самому используя рубивские метапрограммерские фичи типо method_missing и const_missing.
Так что если задача хорошо изучить язык, а не начать-клепать-сайты-на-рельсах-пачками-прямо-завтра, то лучше с языка и начинать;)
А вообще правильно toss говорит, программирование изучать лучше начать на с++ например.
Во-первых понимания работы всей этой кухни будит, а во-вторых до конца не прочуствуешь насколько это круто — руби! т.к. сильно не с чем сравнивать.
Потому как за однотипными действиями в рельсовых контролерах всей прелести руби и не поймешь.
Можно конечно повосхищаться эктиврекордским DSL'ом для создания таблиц, или же его хитрыми методами find_all_by_name и тд.
Но куда лучше делать такое самому используя рубивские метапрограммерские фичи типо method_missing и const_missing.
Так что если задача хорошо изучить язык, а не начать-клепать-сайты-на-рельсах-пачками-прямо-завтра, то лучше с языка и начинать;)
А вообще правильно toss говорит, программирование изучать лучше начать на с++ например.
Во-первых понимания работы всей этой кухни будит, а во-вторых до конца не прочуствуешь насколько это круто — руби! т.к. сильно не с чем сравнивать.
Так точно! Начнем именно с «чисто конкретного» Ruby, а до рельсов еще дожить надо ;)
Обычно люди сразу начинают учить Ruby on Rails а не Ruby:)
По руби, если с английским норм, можно начать с pickaxe(если еще сам не нагуглил;)) — www.ruby-doc.org/docs/ProgrammingRuby/
По-моему даже русский перевод где-то видел.
На русской викибук хороший учебник еще.
Вобщем удачи в изучении:)
По руби, если с английским норм, можно начать с pickaxe(если еще сам не нагуглил;)) — www.ruby-doc.org/docs/ProgrammingRuby/
По-моему даже русский перевод где-то видел.
На русской викибук хороший учебник еще.
Вобщем удачи в изучении:)
блин, и чо все мой ник коверкают? и так вроде проще некуда…
Приятно написано. Попробую «покорять» вместе с Вами ;)
> это полный ООП (что перспективно в дальнейшем покорении олимпа программирования)
И чего тут хорошего, спрашивается? ООП это божок что ли, которому надо молиться?
> В то же время язык — тормоз, нагружает систему
Ну дык излишки абстракции.
> twitter в нем барахтается, пытаясь удержаться на плаву
Это проблемы twitter'а, нефиг микроскопом забивать гвозди.
> Вроде бы как Хабр — это элита ИТ
Самовосхваление не надо.
> в ОС же его использование ограничено скоростью приложения
Большинство приложений в этой скорости не нуждаются. Алсо, многие приложения доказывают, что и на Си++ можно понаписать нечто совсем уж бегемотообразное.
И чего тут хорошего, спрашивается? ООП это божок что ли, которому надо молиться?
> В то же время язык — тормоз, нагружает систему
Ну дык излишки абстракции.
> twitter в нем барахтается, пытаясь удержаться на плаву
Это проблемы twitter'а, нефиг микроскопом забивать гвозди.
> Вроде бы как Хабр — это элита ИТ
Самовосхваление не надо.
> в ОС же его использование ограничено скоростью приложения
Большинство приложений в этой скорости не нуждаются. Алсо, многие приложения доказывают, что и на Си++ можно понаписать нечто совсем уж бегемотообразное.
ООП — это основа сегодняшнего мейнстрима (Ява и та часть С++, которая осталась в мейнстриме)
«Большинство приложений в этой скорости не нуждаются. Алсо, многие приложения доказывают, что и на Си++ можно понаписать нечто совсем уж бегемотообразное.»
Да вы что? а я люблю когда у меня различные утилиты делают свое дело быстро (относится конечно не ко всем, но примерно к половине).
И на асме можно написать бегемота, все зависит от программиста.
«Большинство приложений в этой скорости не нуждаются. Алсо, многие приложения доказывают, что и на Си++ можно понаписать нечто совсем уж бегемотообразное.»
Да вы что? а я люблю когда у меня различные утилиты делают свое дело быстро (относится конечно не ко всем, но примерно к половине).
И на асме можно написать бегемота, все зависит от программиста.
> а я люблю когда у меня различные утилиты делают свое дело быстро
Быстро или молниеносно? Разница между, скажем 100мс и 10мс для человека все равно почти незаметна.
Быстро или молниеносно? Разница между, скажем 100мс и 10мс для человека все равно почти незаметна.
а когда эти 100 мс повторяются тысячу раз, то разница уже ощутима
Мои соболезнования.
Садитесь и переписывайте. Возьмите Си, SISAL и еще что-нибудь. %)
Садитесь и переписывайте. Возьмите Си, SISAL и еще что-нибудь. %)
вы не поверите но я люблю писать на си
Если скажете еще, что Вы все подряд на нем пишете, то получите титул почетного Блабиста. :)
я не говорил что все подряд… для каждой цели есть свои языки… естественно я не буду писать веб-сервис на цпп… я его напишу на руби… точно так же я не буду писать контентный сайт на цпп и руби… я его быстренько скомпаную на той же Жумле…
я просто говорю что си это прекрасный язык, если понять в чем его соль
я просто говорю что си это прекрасный язык, если понять в чем его соль
> я просто говорю что си это прекрасный язык, если понять в чем его соль
Это прекрасный переносимый ассемблер.
Это прекрасный переносимый ассемблер.
да, на с++ (а я все же имею в виду с++, а не чистый си… чистый си сейчас все больше уходит к kernel-space) можно писать как на асме… но при необходимости рядом с этим кодом мы пишем абстракцию на стл…
может наоборот, главная прекрасность C++ в том, что пишем абрстакции на STL, а при необходимости (критические участки, как правило) пишем как на asm, а то и просто делаем asm вставки? :)
ну я честно говоря не хотел что-то ставить во главу угла, поэтому скажу более абстрактно:
мы с легкостью можем смешивать абстракции и системные вызовы
а asm вставки уже не так актуальны как раньше… так как компилеры продвинулись не хило вперед и без серьезного знания асма и серьезной причины вставки делать не стоит, так как выигрыша по скорости/памяти скорее всего не будет;)
мы с легкостью можем смешивать абстракции и системные вызовы
а asm вставки уже не так актуальны как раньше… так как компилеры продвинулись не хило вперед и без серьезного знания асма и серьезной причины вставки делать не стоит, так как выигрыша по скорости/памяти скорее всего не будет;)
Автору
>> это полноценный объектно-ориентированный
не объектно-ориентированный, а объектный
>> это полноценный объектно-ориентированный
не объектно-ориентированный, а объектный
Я с вами будем учить ченить новое! =))))))))))) Красавое описание
Sign up to leave a comment.
Покорим Ruby вместе! Капля первая