Ответы:
PHP удобен и понятен для всех, кто когда то хотел и не мог программировать. На PHP можно делать много разных полезных вещей в отличие от вашего руби
PS: про ; не надо ляля они приняты везде и всюду
не все хосты его поддерживают. обычно только те, где стоит cPanel...
пхп более распространен, а с руби общается только узкий круг человеконаселения
ОС Гейтса тоже отличаются своей корявостью и бажностью, однако от этого она не менее популярна
это попса, как бы грусно и трагически это не звучало ))
Холивар, говорите? Java! Java! (а также всякая всячина типа grails)
Люди, о чем вы спорите? Я пишу на том, за что платят...
А вот основные достоинства этих 2-х языков:
РНР - Очень просто поднять сервер, и его поддерживает достаточно много хостеров.
Ruby - Ну автор вопроса сам всё написал)
Недостатки в РНР: Без фреймворка любой продукт с точки зрения безопасности становиться как швецарский сыр...
Сам факт, что вы подняли такой вопрос - явно говорит что вы не программист, вы именно "сторонник руби". Это не наезд на вас, просто констатирую факт. Отвечу вам на первые пункты:
Хорошо бы на 110mb.com добавили Ruby, глянул бы.
=Вы пишите "новичку проще с руби" и "ему не обязательно знать что вызван метод, пусть думает что так записываются циклы". То есть, сначала вы утверждаете что руби научится проще, а потом оказывается что проще, при условии что обучаемому не будет открыта суть работы его кода. "Замечательный" подход :)=
кхм... и что понятного в цикле
3.times do
puts "Hello World"
end
если вообще не представляешь программирование и английский плохо знаешь???? %)
кстати, а программировать на PHP вы судя по всему и не пытались... ибо синтаксис у вас и действительно ужасный - не найдешь где начало тела кода, где конец
ну когда оппонент занимается буквоедством, почему бы и не присоединиться ;)
1.что-то_там .... мда, извините, но такой способ вызывать методы мне кажется весьма опасным.
массовая объектизация всего что угодно может привести к таким глюкам... и ведь замучаешься искать.
тем более объекты в кавычках... давно существуют вполне удобные и понятные ассоциативные массивы... есть у них ряд минусов, но для "сгенерированных" имен подходят значительно лучше(читабельность выше).
далее глобальные объект, из которого растут остальные? это вещь хорошая, но почему-то в системных языках всячески стараются ограничить возможность изменить класс постфактум. это вообще противоречит ООП - хочешь изменений, создавай потомка.
для кого-то архаизмы, кому-то нужны.
WebCumo
> вы батенька в ООП не разбираетесь.
> а при процедурном программирование очень многое можно решать в разы проще и с большей экономией.
Пишите что хотите, но по мне, очевидность потребности в технологиях вроде ООП или РСУБД должна приходить с опытом. Можно и в обратном порядке: сначала загнать знания и надеяться, что они не вывалятся до поры, до времени. Надеяться, но и только.
Главное - чтобы работало.
Единственные достоинства PHP --
а) это относительная свобода, присущая интерпретируемуму языку (в некоторых случаях, это --- минус, когда злоупотребляют, а вообще, это почти ни зачем не нужно)
б) множество специфических функций, полезных в веб-приложении (это, видимо, обычно перевешивает)
в) множество дополнений PEAR и PECL, которые тоже просто устанавливать и изменять
г) opensource интерпретатор, возможность создавать расширения
д) "волшебные" (magic) функции. Реализация Property у объектов и др. (а в Руби такое есть?)
е) очень хорошо реализованные ассоциативные hash-массивы. Что (в некоторой степени) компенсирует многие недостатки
ж) доллар позволяет разделять идентификаторы функций и переменных, что кроме того, даёт свободу выбора идентификаторов переменных
=интерпретатор написан на C без плюсов=
это нельзя считать недостатком
PHP достаточно прост для освоения и достаточно гибок для решения большинства практических задач, стоящих перед web-программистом.
2Kazukin6
примеров множество :)
просто сейчас это достаточно нераспространенная категория :)
хотя например драйвера все еще пишутся процедурных языках и языках низкого уровня... ну не подходит там ООП из-за ресурсоемкости
естественно что сам процесс программирования таких вещей более сложен(не зря придумали ООП), т.к. в процедурном программировании многие вещи приходится вручную прописывать и учитывать.
>=интерпретатор написан на C без плюсов=
>это нельзя считать недостатком
Создание расширений и изменение исходного кода интерпретатора превращается в муку. ООП подход облегчил бы понимание кода и создание расширений раз 100, даже при такой отвратительной документации по Zend, как сейчас.
а заодно увеличил бы время(итак немалое) обработки скриптов... оно надо?
в других местах вполне может оправдывать себя, тут разработчики пришли к другому выводу.
>а заодно увеличил бы время(итак немалое) обработки скриптов... оно надо?
я Ноябрь, как выяснилось более 10 дополнений сделать нельзя..(
>>Не зная степени компетентности оппонента не рекомендую указывать на некомпетентность ;)
Если вы знаете ООП, то почему спрашиваете, чем пхп недООП, я вам привел яркий пример чем. Надо использовать - не надо, это второй вопрос.
И тем не менее расширять класс иногда приходиться, но, повторяю, целью было не сказать, что так нужно делать, а указать на явную недоработанность ООП в пхп. Так что я как и Kazukin6 сомневаюсь в вашей ООП продвинутости.
>>запись 3.times требует понимания что между 3 и times стоит именно точка, и понимания что пробелы недопустимы(или я неправ?)
пробелы допустимы. Объясните мне, почему все функции в пхп требуют скобок, кроме echo. Почему я самостоятельно не могу реализовать функцию foreach, for т.д.
Я думаю с точкой на пару дней можно смириться.
Насчёт ООП, рекомендую защитникам PHP прочитать определение полностью объектно ориентированного языка, чтобы убедиться, что PHP таковым не является.
>>1) правильного энкода URI, чтобы, например, пробел заменялся на %20
Не совсем понимаю какой функционал необходим методу. В раилс есть метод url_for, который генерирует адрес (в т.ч. с указателями).
Этот метот связан с соглашениями фрэймворка. В конечном счете направлен на то, чтобы без труда генерировать ссылки, для вызова методов.
Кроме того есть методы - адреса, для определенных методов контроллера. Т.е. еще более сокращенная запись адреса для ссылки.
>>2) энкода произвольного текста, для получения его точного представления в HTML
Снова не совсем понимаю о чем речь..
>>3) удобная поддержка web-специфичных возможностей, таких, как сессии и пр.
Есть в раилс session[:name]
>>4) он работает со всеми известными базами данных
ActiveRecord да.
>>5) есть довольно неплохая поддержка многобайтных кодировок, регулярных выражений
Есть, но у меня в 1.8.6 upcase для русских слов не работает, а в недавно вышедшей 1.9.1 должно работать. Т.к. я юзаю win, то пока не могу посмотреть..
>>6) В PHP есть ещё прекрасная возможность: назначить по имени класса файл, в котором он описан. Тогда в самом сценарии вообще не надо подключать никаких лишних файлов. При попытке использовать какой-то класс, файл его содержащий интерпретируется автоматически, а в Руби такое есть?
Кидается в папку libs рельсового приложения.
>>Например, можно описать процедуру конвертации в string произвольного объекта, но в int или bool уже нельзя, а в руби, я уверен, можно.
например так
>>2) энкода произвольного текста, для получения его точного представления в HTML
>Снова не совсем понимаю о чем речь..
Ну, скажем, у меня пользователь ввёл какую-нибудь ересь, типа, x < y, а мне надо это отобразить на странице. Тогда мне нужно написать такой HTML: x < y, иначе пользователь может написать вредоносный HTML код. Таких функций --- масса, без них веб-программирование во-первых превращается в кошмар, а во-вторых, скорее всего будут изъяны в безопасности. Имея на PHP массу таких функций я могу не вникать во всевозможные стандарты, что именно допускается в данном месте, а что нет и как это эскейпить. То же про URL, и про запрос к базе, и про выполнение команд shell и ещё про много чего. Это наверное именно то, почему я не пишу веб-приложения на C++.
>>2) энкода произвольного текста, для получения его точного представления в HTML
разумеется есть.[1](вывод хтмл)
использование ActiveRecord по сути исключает инъекции.
Вообще есть много всего: модули авторизации, страничные плагины (отличная штука).
Огромное количество библиотек под руби и раилс.
Если тебе что-то требуется, то обычно оно уже кем-то реализовано.
>>Это наверное не то. Там, если класс не используется, то файл не загружается, то есть время не тратится.
>в любом случае подгружаться будет все лишь единожды, во время старта сервера.
То есть как это? PHP при каждом запуске страницы интерпретирует все файлы по полной с нуля. Есть оптимизаторы типа APC, но это всё ерунда. Насколько я понимаю. В принципе, возможно производить синтаксический анализ только один раз, но, по крайней мере интерпретатор PHP этого не делает, насколько мне известно.
Неужели, руби позволяет выполнять какой-то предварительный анализ?
нет, все проще.
для раилс существует mongrel - сервер написанный на руби
т.е под каждое приложение запускается сервер, запускается единожды, соответственно файлы подгружает единожды.
у себя локально я использую просто mongrel,
однако все уже оптимизировано под апач и работает[1]
Ну тогда PHP по сравнению с Руби это просто детская игрушка. Это просто гигантская оптимизация, должно быть
===интерпретатор написан на C без плюсов===
==это нельзя считать недостатком==
=Создание расширений и изменение исходного кода интерпретатора превращается в муку. ООП подход облегчил бы понимание кода и создание расширений раз 100, даже при такой отвратительной документации по Zend, как сейчас.=
Дело не в языке программирования, а в компонентной технологии. Например, GObject. Из C++ компонентная технология не очень. От компилятора зависит, реализацию базовых классов менять сложно.
>Дело не в языке программирования, а в компонентной технологии. Например, GObject.
>Из C++ компонентная технология не очень
Не понимаю, о чём идёт речь, причём тут gobject. И смысл вот этой фразы, про то что ИЗ C++ что-то не очень. А из С, что,, очень?
>Насчёт ООП, рекомендую защитникам PHP прочитать определение полностью объектно ориентированного языка, чтобы убедиться, что PHP таковым не является.
Давайте ссылки на официальные стандарты, если таковые найдете. Иначе это всего лишь ВАШЕ мнение. ООП - не стандарт, а принцип.
объектная модель в руби значительно удобнее, из каких принципов не исходи.
>Давайте ссылки на официальные стандарты, если таковые найдете. Иначе это всего лишь ВАШЕ мнение. ООП - не стандарт, а принцип.
Это не моё мнение, а научный вопрос Computer Science, по которому достигнут консенсус. В этой науке есть такое понятие, как полностью объектно ориентированный язык программирования. Посмотрите, например, Wikipedi'ю, там они называются pure OO:
http://en.wikipedia.org/wiki/Object-oriented_programming_language
>Это не моё мнение, а научный вопрос Computer Science, по которому достигнут консенсус. В этой науке есть такое понятие, как полностью объектно ориентированный язык программирования. Посмотрите, например, Wikipedi'ю, там они называются pure OO:
http://en.wikipedia.org/wiki/Object-oriented_programming_language
еще раз попрошу ссылки в студию. а по поводу приведенного:
pure OO - не "полностью", а "чистый" ОО язык. И характерные особенности там, кстати, указали - языки, в которых все - объекты, в том числе символы и пунктуация.
это как бы не то чем обязательно стоит гордиться, если не фанат. Иначе это уже не профессиональный подход а детский сад.
и что это за "Computer Science"? и кто этой "наукой" правит? и где все-ж таки ссылки на официальные документы? википедия хороша для ознакомления теоретического, но не дает стопроцентной гарантии верности данных.
И заметьте, ни один широкораспространённый язык системного программирования не является pure OO. В то же время PHP вовсе не отмечен там как "недоООП"(с чего и начали, кстати). Обращаю внимание н_е_д_о_О_О_П, не надо съедать букву за просто-так.
Так что или приводите полноценные доводы или попрошу не оглашать это стандартами.
мне нравится недООП:) 3 о подряд трудно произнести..
>>Так что или приводите полноценные доводы
да сколько угодно
в пхп существуют не объектные типы,
- отсюда невозможность расширения их функционала,
в пхп отсутствует базовый класс,
- отсюда невозможность расширять основные классы
отсутствую функциональные модули (они же примеси, миксимы, нормальные интерфейсы)
- отсюда невозможность организовать код, тогда как в руби наследуются и инкапсулируются как классы так и модули
в пхп невозможно переопределять методы (что стало для меня неожиданностью).
полагаю что так же невозможно расширять класс.
Чтобы вы не говорили, но C# и Java навязывают определенную ООП модель. Их модели считаются как бы эталонными. Вы утверждаете, что используете ООП в "системных языках", как тогда модель пхп может вас устраивать и вообще являться предсказуемой. По ходу этого холивара я окончательно убедился, что в пхп ничего нельзя, а ООП _явно_ не доделано. И нет ни одной конструкции, ни одной библиотеки, ради которых стоило бы использовать этот язык.
А вот теперь вернемся к началу:)
>>На PHP можно делать много разных полезных вещей в отличие от вашего руби
очень интересно что:)
>мне нравится недООП:) 3 о подряд трудно произнести..
ничего не трудно. а уж написать-то еще проще, просто вы терминологию нарушаете таким написанием.
Я не хочу мучаться пытаясь подружить ruby и apache, а потом мучаться от собственной криворукости. Я не сисадмин, я программист. А то что ruby прекратили в свое время разработку mod_ruby для apache - это их дело. Значит не быть ruby таким же распространенным языком как php (по крайней мере до тех пор, пока mod_ruby не сделает кто-либо еще).
WebCumo:
>и где все-ж таки ссылки на официальные документы?
Приведите мне официальные документы, в котором написано, что 2+2=4, или что параллельными прямыми на плоскости называются те, которые не имеют общих точек.
==Дело не в языке программирования, а в компонентной технологии. Например, GObject.
Из C++ компонентная технология не очень==
=Не понимаю, о чём идёт речь, причём тут gobject. И смысл вот этой фразы, про то что ИЗ C++ что-то не очень. А из С, что,, очень?=
Из Objective-C, например, гораздо лучше, чем из C++. В Objective-C можно добавлять методы без перекомпиляции зависимых приложений. Собственно, в Mac OS X так и происходит: API добавляются, старые приложения работают. Недостаток Objective-C в том, что нельзя добавлять поля (впрочем, у C++ этот недостаток тоже есть, но C++ ведь и не проектировался как хорошая компонентная технология) без перекомпиляции, и поэтому в системных хедерах можно часто видеть место, зарезервированное на будущее.
Наконец, в GObject можно даже добавлять приватные поля, поэтому я и привёл эту компонентную модель в качестве образца.
>> в c++ существую необъектные типы, в java существуют необъектные типы... "фтопку" языки?
ну архаизмы - порождение консерватизма, что в этом хорошего..
с++ вообще древний язык, ему на смену давно пришел c# в котором все _реализовано_. Однако "настоящие" программисты по-прежнему советуют начинать с с,с++.. Не надо с++ новичкам советовать, мучаетесь - мучайтесь, остальные не при чем.
Вклцм
>> Я не сисадмин, я программист.
знания лишними не бывают.
вместо того чтобы стыдится глупости, вы ее выпячиваете и гордитесь - забавно:)
>с++ вообще древний язык, ему на смену давно пришел c# в котором все _реализовано_. Однако "настоящие" программисты по-прежнему советуют начинать с с,с++.. Не >надо с++ новичкам советовать, мучаетесь - мучайтесь, остальные не при чем.
Тем не менее, что-то я не видел ничего хоть сколько-нибудь такого-же великого, как C++. Где ещё можно проделать такие же чудеса, как в C++ с его шаблонами (разве что в придуманном гениальным Кнутом TeX'е и METAFONT'е, но это другая опера)?? С++ настолько универсален, что всё, что весь идиотизм и все преимущества любого другого языка может быть реализовано в нём (примерно также как в TeX, с помощью элементарных команд реализуются циклы, которых в Простой Системе TeX нету, и как к этому языку, который предназначался для удобного набора текстов добавили функциональность почти настоящего языка программирования, basic, разве это не удивительно?). Где ещё есть такая же открытая политика на ресурсы, где нет ничего лишнего, кроме как в C++. Сейчас C++ немного проигрывает некоторым язычкам в удобстве, это правда, но на подходе совершенно удивительный C++0x, который укажет всему остальному на своё место.
>>Так зачем тогда вообще нужно переопределение операторов?
как вариант, выше показывал вам способ совместного вызова методов, реализованного как раз через переопределение.
> нельзя добавлять поля (впрочем, у C++ этот недостаток тоже есть, но C++ ведь и не проектировался как хорошая компонентная технология)
Динамически?? Но это же немыслимо для C++, однако реализовать это всё равно просто, достаточно добавить map<string> в закрытое поле, а потом похитрить с оператором ->.
чем отличаются операции и методы?
зачем нужна множественная диспетчеризация и что это такое?
>как связаны перегрузка и переопределение операторов?
Функция называется перегруженной, если определено несколько функций с таким именем, отличающиеся типом аргументов. При этом транслятор автоматически должен выбрать какую версию нужно вызвать в каждом конкретном случае. Переопределение это синоним (в некоторой терминологии. Хотя, логично было бы предполагать, что переопределение запрещает вызывать старую версию).
в данном случае действительно удобно.
Но что если программисты будут писать функции в своих модулях.
А в классе будет или заглушка, или ничего (method_missing, что тоже заглушка).
Далее параметры будут переданы в программный (класс) транслятор, который определит метод из какого модуля нужен в данный момент.
всегда ли возможно обеспечить перекрывание методов..?
Не влечет ли это серьезные ограничения?
хм... а код в руби всегда похож на то что привел gaosipov?
если это так... то более нечитабельный код я видел только у первокурсников-программистов %)
ну и в с++ %)
>Далее параметры будут переданы в программный (класс) транслятор, который определит метод из какого модуля нужен в данный момент.
А кто будет разрабатывать этот программный транслятор? Он должен знать про всё, что может использовать данную операцию. Следовательно, если вы захотите добавить что-то новое вам придётся изменять старое, что нежелательно и неудобно.
>>Я в своё время вводил такое понятие, как штраф преобразования
разве это не примерно то же самое, о чем я написал выше?
>>Что значит перекрывание?
и то что вы сказали, и то что всегда ли возможно помещать все одноименные методы в один класс, на сколько это удобно.
>>Я в своё время вводил такое понятие, как штраф преобразования
>разве это не примерно то же самое, о чем я написал выше?
Что именно?
Я в своё время вводил такое понятие, как штраф преобразования
==
Далее параметры будут переданы в программный (класс) транслятор, который определит метод из какого модуля нужен в данный момент.
?
>>Для каждого случая мы определяем метод float::operator*
Мы получаем разросшиеся классы с одноименными методами, не могу сказать что это плохо.. но сомнения есть:)
>Мы получаем разросшиеся классы с одноименными методами, не могу сказать что это плохо.. но сомнения есть:)
отбросьте сомнения, это очень хорошо используется в C++. Кстати, все эти методы, по терминологии Руби принадлежат классу float.
угумс, теперь понятнее :-)
в последнем посте наконец-то появился читабельный программный текст
в таком варианте язык вполне удобен и употребим :-)
просто предыдущий кусок уже через одну минуту сливался перед глазами в один ужасный ком, не спасало абсолютно ничто.
по поводу моего высказывания - на с++ можно написать очень понятно, но на нем же можно написать так, что понять будет ничего невозможно. я имел в виду второй вариант.
==нельзя добавлять поля (впрочем, у C++ этот недостаток тоже есть, но C++ ведь и не проектировался как хорошая компонентная технология)==
=Динамически?? Но это же немыслимо для C++, однако реализовать это всё равно просто, достаточно добавить map<string> в закрытое поле, а потом похитрить с оператором ->=
Нет, не динамически. Добавить новые поля и методы в предке без перекомпиляции потомков.
>В D в явном виде присутствует run-time скриптинг. Это требует меньших ресурсов, меньших навыков сотворения чудес и даёт взамен больше возможностей и ясности. В D, например, можно написать программу, в которую компилятор зашьёт результат рейтрейсинга сцены. На шаблонах C++ такое тяжеловато будет исполнить.
>чем отличаются операции и методы?
Вообще ничем, просто операции по другому вызываются (в С++ операция не обязана быть методом класса, может быть просто функцией)
> зачем нужна множественная диспетчеризация и что это такое?
Эта возможность создавать функции, имеющие несколько виртуальных параметров (у обычной функции-члена класса только один виртуальный параметр -- this). Например, у вас есть несколько классов принтеров и несколько классов фигур --- каждые наследуют от своего потомка. Далее, пусть x обозначает принтер, а y фигуру, надо напечатать y на x. Тогда это решается с помощью диспетчерезации: для каждого принтера и каждой фигуры определена своя функция, которая выбирается автоматически.
>>Есть в Руби множественная дипетчеризация!! Но, реализованная видимо в ручную, на уровне языка, так, как вы написали. Вот пример кода (взят из Википедии:Мультиметод):
метапрограммирование в руби творит чудеса:)
вообще мне кажется, что перегрузка это лишь частный случай выбора методов, когда они находятся в одном "пространстве" и имеют одинаковые имена. В с++ походу всего одно пространство, а в руби модули. Т.е. вполне возможно, что метод придется вызывать Module::method, и о каком тогда перекрытии может идти речь.
>>угумс, теперь понятнее :-)
кстати на лоре читал мнение, что перегрузка методов это недоделанный именнованный вызов.
опять же, теоретически это можно было бы реализовать средствами языка.
Дело в том, что если хеш в руби является последним параметром метода, то запись скобок необязательна, т.е.
var.method {:a => 5, :b=> 6}
можно записать как
var.method :a => 5, :b=> 6
а в руби 1.9
var.method a: 5, b: 6
вот..
пздц вы сопли развели )))
лучшим считается тот язык, на котором пишутся легковесные и полноценные программы (апплеты и пр), который безопасен и легок в изучении
просто наберите две одинаковые проги-ака-Hello-World и посмотрите на то, где это проще сделать, ну и какая прога будет меньше по размерам ))
Я за Php. Потому-что я его знаю =)
> зачем люди используют php.
PHP появился раньше, чем Rails
просто тролль добрался ответов гугла
описание понравилось - над будет попробовать и Ruby ;) Вдруг понравится настолько, что перейду на него...
На PHP написано 70% сайтов в интернете. У PHP простая, понятная любому сишнику, очень гибкая система типов и классов. В PHP 5.0 поддерживается полная модель ООП, которая пришла взамен уродливой эмуляции, имеющейся в PHP4. Если взять C# за ориентир, то в PHP сейчас можно реализовать всё с той же простотой и наглядностью, как и в C#, даже я бы сказал, PHP в этом плане дружественнее. Чего только стоят индексные массивы, которые могут содержать внутри себя другие массивы.
Вопроса такого нет. И нет никакого смысла искать преимущества в конкретной технологии.
Всю дискуссию прочитать я не смог, но мое мнение такое.
Люди привыкли просто программить на PHP... боле привычный код... к новому привыкнуть сложнее..
hazggg
ruby 1.9.x не тормозной.
Обычно руби в вебе используется на основе фрэймворков, а там достаточно много соглашений, что бы не запутаться даже начинающему. В итоге почти всегда знаешь что делать, а код твоего приложения очевиден для других разработчиков.
Батенька, да Вы ничего не смыслите в программировании, круче всех брейнфак, вот хелло ворлд:
+++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++.+++++++++++++++++
++++++++++++.+++++++..+++.-------------------
---------------------------------------------
---------------.+++++++++++++++++++++++++++++
++++++++++++++++++++++++++.++++++++++++++++++
++++++.+++.------.--------.------------------
---------------------------------------------
----.-----------------------.
и заметте никаких лишних символов, никаких ужасных точек с запятой
php - язык достаточно человеческий, чтобы на нем написать движок MediaWiki, на котором работает Википедия. Что вам еще от языка надо? Рюшечки или ехать? На php можно ехать - вполне. Понятный код на нем тоже можно писать, так же как и на Ruby. И непонятный код можно написать и на том и на другом. Программист нужен с головой, а язык подойдет любой - php, Ruby, Python... Как правильно уже заметили, дело совсем не в синтаксисе, а в том, насколько эффективные и понятные для других решения может найти программист. Трудности преодоления синтаксиса ни когда не сравнятся с трудностями процесса становления программиста.
Единственное, что в php развито хуево - это классы.
Меня бесит $this->.... Не знаю как в этом руби.
Интересно, есть ли возможность использовать руби и php в одном скрипте или подключать руби в php-сценариях?
Косяк руби: Переменные. без $ это просто ужасно выглядит. Мне тяжко воспринимать такой код.
Я люблю синтаксис php. Он очень прост и удобен.
А какие можно вести разговоры об обучении языку? Где этому руби у нас учат?
for должны знать еще с паскалей. 3 таймс ду, как я понял, это цикл, который повториться 3 раза
3.times do
puts "Hello World"
end
Простите, хотя автор уже не сможет дополнить вопрос, а в чём смысл холивара?
Играйтесь на здоровье :)
Я пока ещё ни одной причины (даже шуточной или субъективной) воспринимать руби всерьёз здесь не увидел... Как говорится, 7.times read, 1.times post :-)
Я пишу на PHP потому что ненавижу ООП. Меня тошнит от словосочетания «статический метод». Меня бесит, когда редактор не находит имени метода внутри класса (потому что он определён в родительском классе). Я пишу функции.
Интересная тема... Этот "холивар", таки напоминает мне вечные вопросы: "что появилось раньше, курица или яйцо", "что круче, файэрфокс или эксплорер", "что лучше коммерческая CMS или собственная"....
Но вот касательно темы, "что лучше PHP или Ruby", скажу как программист, который когда-то встал перед выбором переходить с PHP на Руби или нет...
После того, как я немного познакомился с Руби, точно решил для себя - низачто. Руби это сырой язык, использующий все те же методы, но намешанные из разных языков в кучу - конечно, это удобнее, чем грубый-прегрубый синтаксис явы там или делфи, но ни разу не удобнее, чем PHP.
Руби я использовал для написания веб-приложений на Ruby on Rails, а это использование кучи гемов, специальный редактор, ява-фреймворки и что еще хуже - Active Record. С последним я и сейцас на PHP сижу и подумываю всерьез над тем, что бы избавить и от этого детища "революционеров" сети - так как этот незаменимый элемент Рейлса и в принципе удобный по своему назначению в PHP, является еще более сырым чем сам Руби. На Рекорд нет нормальной документации, не рассмотрены абсолютно проблемы связанные с кодировками... Вобщем, как человек выше написал - я лучше буду использовать свои функции, чем чужое ООП, да еще и корявое..
Поэтому, автору топика могу пожелать лишь творческих успехов в нашем деле и могу сказать - что Руби это не просто другой язык программирования, он просто хуже и меня например больше бесит писать что-то вроде: if(params[:search]) вместо if($search) ....
Не стоит забывать, что ооочень мало русской литературы по руби, соответственно, начинающий (даже есди и знает что он стоит перед альтернативой: руби или пхп) выберет пхп.
Это что касается популярности и почему люди выбирают"то. а не это".
А что касается технической точки зрения, то более компетентные люди уже высказались.
PYTHON! Поюзай Python с**а :) Вот там то тебе синтаксический сахар :)
Ребят, на php хорошая классовая модель и она не должна никого бесить) Я бы сказал, она достаточно полная, чтобы реализовывать проекты средней сложности. Да, всякие заморочки с переопределением операторов на нём не сделать, но зато абстракции, статические методы и интерфейсы - сколько угодно. Те кто говорит, что "я использую php, потому что ненавижу классы" меня по меньшей мере удивляют. Сила php именно в простой реализации классовой модели, а то, что Вы ещё не догадались объединить Ваши наработанные библиотеки функций в классы говорит о том, что у вас есть куда расти.
И ещё хотел сказать, что не надо начинать изучение классовой модели PHP с разбора движков а-ля MVC. MVC это страшная вещь, она была придумана на заре PHP, когда по-другому нельзя было написать. Сейчас на php уже можно использовать более простые и понятные подходы, и не нужно изучать эти архаизмы, лучше погулите по компонентно-ориентированным движкам.
Ничто не отменит того факта, что пхп страшный. Чтобы ты не сделал на пхп - оно будет страшным.
MVC - ужасна?! Это ваш mod_php ужасен, ваш smarty ужасен, ваши ЧПУ - вот где архаизмы!! Хотя MVC в пхп очевидно то же ужасно..
Пхп на столько беспомощный, что не может существовать без апача (как инструмент создания веб приложений).
После нормального фрэймворка, как rails, как merb, от всего этого тупо тошнит.
Я вообще не вижу смысла холивара между руби и пхп. РОР это высококлассный мощнейший фреймворк, высоты которого даже асп.нет недотягивает. По количеству усилий приложенных для создания сложных больших безопасных приложений у РОР конкурентов нет. Если взять самый адекватный фреймворк для пыха - ЗФ в разы слабее. Нет ОРМ, нет миграций и кучи всяких сладостей. Масштабные приложения при хорошем знании обоих языков быстрее пишутся на РОР. При этом я не отрицаю того что на пыхе можно писать так же очень масштабные и безопасные, но получится значительно медленнее для разработчика. Тут смотря у кого на чем акцент. Кто-то пишет на ассемблере, так как он даёт не сравнимое ни с чем быстродействие приложений, однако на нем невозможно написание больших приложений, только критических частей и драйверов, так как у него нет никаких возможностей для облегчения работы программиста.
Так же на пыхе - можно написать вконтакте. А на роре - твиттер. Но на руби получается значительно быстрее для программиста, а на пыхе возможно лучше быстродействие приложения и достоинства при выборе хостинга, нахождении программистов для разработки и т.д. Разные языки - разные приоритеты. Хотите писать просто и си-подобно как делает большинство и не заморачиваться - выбираете пых, хотите иметь непревзойденную производительность - выбираете рор. Знаете оба языка - еще лучше. Но для начинающих рекомендовал бы сначала идеально знать пых(и ЗФ) а только потом переходить на рор.
Автор уперся в то что php недООП потому что в нем нет возможности расширять базовый класс. Давайте вспомним когда появилось понятие ООП и была ли такая возможность в языках тех времен. Я не помню. Выходит что не в пхп недООП а в руби переООП).
Прр сколько еды для троллей развелось) Ноябрь зачем тебе нужны док-ва если ты и так не станешь на ПХП переучиваться?
Детсад, честно.
Такое ощущение, что сторонники PHP понятия не имеют, что такое Ruby. Собственно в этом и ответ на вопрос. Люби выбирают то, про что слышали. Но больше всего восхищает агрессивность. "Я про Ruby ничего не знаю, но PHP конечно лучше, потому что я на нем пишу".
В PHP очень низкий порог вхождения, отсюда больше проектов на PHP, больше говнокода.
Ruby не лучше не хуже оно другое, как в прочем и Python и Perl, однако PHP как бэ ориентирован только для вэба, поэтому сравнение тупое.
А зачем холиварить? PHP мне приносит определённый доход, так как в моём регионе заказчики знают о PHP, MySQL и нескольких CMS вроде Joomla, Wordpress, про фремворк Drupal да системы электронной коммерции Prestashop, OpenCart и Virtuemart. Если нужно заказчику выполнить определённый заказ на PHP - делаем на PHP.
все зависит от задачи, как бы это небыло для вас противно, но пхп - более популярнее, а это значит больше литературы, хостинг дешевле, больше наработок и примеров
А что на счет нового встраиваемого языка программирования ObjetcScript? Проект - opensource, располагается на github-е тут
https://github.com/unitpoint/objectscript, построен на базе таких языков, как JavaScript, Lua, Ruby, Python and PHP.
16 лет назад