php vs perl
Лично мне более удобен php. Но жду ваших каментов, в частности пианистаСейчас он тебе окажет помощь в уменьшении самооценки.
Да мне пох. Я знаю кто я, и примерно представляю, кто он.
Мне действительно интересны преимущества пера перед с пхп. Честно говоря я их не вижу.
Мне действительно интересны преимущества пера перед с пхп. Честно говоря я их не вижу.
Мне действительно интересны преимущества пера перед с пхп. Честно говоря я их не вижуНу, если не видишь, значит просто PHP для тебя лучше. Ты ведь наверное рассматриваешь их больше с позиций веб-программирования? И на PHP легче начать заниматься веб-программированием. А потом просто привыкаешь и не видишь ничего хорошего в других языках.
Perl хорош тем, что это универсальный язык, на нем можно написать и сервер, и посчитать что-нибудь тоже можно и много чего еще можно сделать.
Еще у Perl'а очень сильное сообщество, http://cpan.org тому подтверждение.
В PHP много странных вещей, например php.ini. Насколько я помню, там есть несколько параметров, отвечающих за поведение самого языка!
P. S. С позиций веб-программирования Perl тоже выигрывает
. Извини, если несколько эмоционально.Perl хорош тем, что это универсальный язык, на нем можно написать и сервер, и посчитать что-нибудь тоже можно и много чего еще можно сделать.На php тоже можно.
В PHP много странных вещей, например php.ini. Насколько я помню, там есть несколько параметров, отвечающих за поведение самого языка!А где ещё могут находиться параметры, отвечающие за поведение языка?
Пианист перл не знает, а пхп не любит. 
ЗЫ: Чтобы получить исчерпывающий ответ, спроси у Глеба чем Линукс от Фрибизди отличается.
ЗЫ: Чтобы получить исчерпывающий ответ, спроси у Глеба чем Линукс от Фрибизди отличается.
просто из форума, по пьяни попалось .
Разве этого мало чтобы не юзать ПХП?
Разве этого мало чтобы не юзать ПХП?
Извини, если несколько эмоционально.Да не, нормально. В общем-то я и рассматриваю ПХП и перл исключительно для веб-приложений. Думаю, что перл любят юзать в основном линуксойды. Перл для них привычный язык, по этому почему бы не писать на родном языке?
Чтобы получить исчерпывающий ответ, спроси у Глеба чем Линукс от Фрибизди отличается
Ну да, я так и думаю - вопрос религии.
На данном этапе моего развития, мой выбор PHP+MySQL+Smatry.
PHP+MySQL+SmatrySmarty все же...
> А где ещё могут находиться параметры, отвечающие за поведение языка?
В самой программе, если язык транслируемый.
В самой программе, если язык транслируемый.
Для веба пишу на пхп. Если в системе надо что-то кодить, то перл. Ну это привычка.
Те опции, которые ещё не поздно указывать в самой программе - можно указать в ней, есть ini_set
А те опции, которые в самой программе указывать уже поздно, типа всяких там magic_quotes_gpc итп - ты хочешь, чтобы вообще нигде указать нельзя было?
А те опции, которые в самой программе указывать уже поздно, типа всяких там magic_quotes_gpc итп - ты хочешь, чтобы вообще нигде указать нельзя было?
хочешь, чтобы вообще нигде указать нельзя было?Зная Глеба, могу предположить, что он хочет, чтоб было можно, но чтобы указать, нужно было бы поставить кучу патчей и прочитать мегабайты манов
Как это понимать: "в программе указывать уже поздно"? 
Примеры:
1) Всякие там allow_url_fopen, enable_dl и safe_mode - теряют всякий смысл, если любой может их отключить в скрипте.
2) arg_separator_input, magic_quotes_gpc, register_long_arrays, register_globals - и что предлагаешь делать, если последние два были выключены, вход распарсился, мы чего-то поделали (изменили) с массивами типа _POST, HTTP_REQUEST_VARS итп, а потом как-нибудь поменяли эти настройки? Писать многокилометровый мануал насчёт поведения интерпретатора при изменении каждой настройки в каждом случае, и чтобы пользователю (ie кодеру) надо было бы помнить весь этот мануал наизусть или постоянно с ним сверяться? Да, и ещё надо не забыть функцию ini_restore, которая брала бы из стека предыдущее значение последней изменённой настройки, чтобы можно было писать переносимые куски, меняющие эти настройки, да?
3) asp_tags, short_tags итп - то же самое, что и для предыдущего пункта, возможность изменения этих настроек из скриптов просто вынудит нормальных кодеров никогда не писать ни <%...%>, ни <?...?> (неважно в каком значении). И вообще, как это надо будет писать,
4) mysql_default_host и куча прочих настроек в том же духе. Можно, конечно, дать скрипту возможность задавать их, но зачем? Неужели кто-то будет писать
(ЗЫ: Сейчас заметил, для mysql эти настройки действительно можно изменить через ini_set, нельзя для некоторых других БД - но смысл от этого не меняется)
5) Больше ничего не нашёл, вроде бы, все настройки, не изменяемые через ini_set, относятся к одному из этих четырёх типов.
Так что:
1) Всякие там allow_url_fopen, enable_dl и safe_mode - теряют всякий смысл, если любой может их отключить в скрипте.
2) arg_separator_input, magic_quotes_gpc, register_long_arrays, register_globals - и что предлагаешь делать, если последние два были выключены, вход распарсился, мы чего-то поделали (изменили) с массивами типа _POST, HTTP_REQUEST_VARS итп, а потом как-нибудь поменяли эти настройки? Писать многокилометровый мануал насчёт поведения интерпретатора при изменении каждой настройки в каждом случае, и чтобы пользователю (ie кодеру) надо было бы помнить весь этот мануал наизусть или постоянно с ним сверяться? Да, и ещё надо не забыть функцию ini_restore, которая брала бы из стека предыдущее значение последней изменённой настройки, чтобы можно было писать переносимые куски, меняющие эти настройки, да?
3) asp_tags, short_tags итп - то же самое, что и для предыдущего пункта, возможность изменения этих настроек из скриптов просто вынудит нормальных кодеров никогда не писать ни <%...%>, ни <?...?> (неважно в каком значении). И вообще, как это надо будет писать,
<? ini_set('asp_tags','On'); %>? Получается, после каждого include надо будет на всякий случай писать кучу ini_set, чтобы ничего не сломалось?
4) mysql_default_host и куча прочих настроек в том же духе. Можно, конечно, дать скрипту возможность задавать их, но зачем? Неужели кто-то будет писать
<??
ini_set('mysql_default_host','localhost');
ini_set('mysql_default_port','3306');
ini_set('mysql_default_user','user');
ini_set('mysql_default_pw','password');
$link=mysql_connect;
?>
(ЗЫ: Сейчас заметил, для mysql эти настройки действительно можно изменить через ini_set, нельзя для некоторых других БД - но смысл от этого не меняется)
5) Больше ничего не нашёл, вроде бы, все настройки, не изменяемые через ini_set, относятся к одному из этих четырёх типов.
Так что:
Получается, после каждого include надо будет на всякий случай писать кучу ini_set, чтобы ничего не сломалось?Что хотели, то и получили. Сделали движок шаблонов частью языка (чуть ли не его основой
) - ограничили возможности. Нет чтобы как у людей - подключаемым модулем...mysql_default_hostмда, вот такое назвать "параметром, отвечающим за поведение языка" - это только в PHP
А я и не говорил, что это параметр, отвечающий за поведение языка.
Ну так это другой пост 
Сначала сказал, что константам, отвечающим за поведение языка, место только в php.ini, потом в ответ на недовольство глебиуса показал, что вообще все константы, задаваемые только в php.ini, правильно делают, что там находятся. Что тебе не нравится-то, что слишком много пунктов в моём посте
Сначала сказал, что константам, отвечающим за поведение языка, место только в php.ini, потом в ответ на недовольство глебиуса показал, что вообще все константы, задаваемые только в php.ini, правильно делают, что там находятся. Что тебе не нравится-то, что слишком много пунктов в моём посте
Что тебе не нравится-тотут вроде обсуждается PHP vs Perl - вот я и написал об ограничениях PHP, которых в Perl нет.
Что-то я тебя никак не пойму, тебе что не нравится-то?
Я вот все эти константы вроде перечислил, и никакого ограничения функциональности не увидел. Если ты увидел - ну так говори не какие-то там общие фразы, а скажи, какое именно ограничение функциональности ты заметил.
Я вот все эти константы вроде перечислил, и никакого ограничения функциональности не увидел. Если ты увидел - ну так говори не какие-то там общие фразы, а скажи, какое именно ограничение функциональности ты заметил.
какое именно ограничение функциональностину например движок шаблонов заменить в PHP можно?
Я использую из ПХП совершенно левый шаблонизатор.
У ПХП есть возможность расширять АПИ, так что всё возможно.
У ПХП есть возможность расширять АПИ, так что всё возможно.
Всякие там allow_url_fopen, enable_dl и safe_mode - теряют всякий смысл, если любой может их отключить в скрипте.
Бля, пиздец! Ну ведь только пидорасы из ПХП смогли придумать эти совершенно невменяемые вещи! Регистар_Глобалз — ещё одна из них.
Это то, что НИКОГДА НЕЛЬЗЯ ВЛЮЧАТЬ!
Ну так они и говорят "ни в коем случае не включайте, в случае, если у вас кривой код, вас взломают, и вообще, возможность включить мы оставили только для обратной совместимости".
Я думаю, если повспоминать какой-нибудь perl версии 1, там не менее ужасные вещи будут
Я думаю, если повспоминать какой-нибудь perl версии 1, там не менее ужасные вещи будут
Чтоза тупой вопрос? А вот программу на php написать можно?
У ПХП есть возможность расширять АПИ, так что всё возможно.Мда? Ну ладно, это хорошо. У меня теперь одним предрассудком меньше
На ПХП писать можно и нужно, если знаешь в совершенстве какой-то ещё язык.
Опасность для общества представляют так называемые "ПХП-программисты", которые знают ТОЛЬКО ПХП, вот они-то и плодят основной говнокод...
Опасность для общества представляют так называемые "ПХП-программисты", которые знают ТОЛЬКО ПХП, вот они-то и плодят основной говнокод...
Оставить комментарий
mr82
Хочется услышать мнение форумчан, которые работали и с тем и с другим для разработки веб-приложений. В каких задачах выигрывает php, а в каких perl.Это вопрос религии, что ли?
Лично мне более удобен php. Но жду ваших каментов, в частности пианиста